1. Home
  2. Voice-Over-IP
  3. The big picture with SIP and RTP

The big picture with SIP and RTP

Hi

To investigate the issue I'm having with uni-directional sound, I'd like to make sure I understood things correctly as to how SIP and RTP work together to achieve VoIP conversations ((A = caller, B = callee, B proxy = proxy server used by the callee to register):

  1. Both SIP devices register with a proxy to make themselves known and reachable by connecting to their respective proxies, each by connecting to UDP 5060 (or checking out SRV records in a dynamic DNS)

  1. SIP Caller connects to UDP 5060 on callee's proxy and dials the extension on B proxy (eg. sip:101@remote_proxy.com), opens a port locally to exchange RTP voice data, and sends this information to the B proxy

  2. B proxy rings the extension

  1. B negotiates with its proxy by receiving A's address and RTP port, opens its own port for RTP, and sends i

  2. Once A and B know each other's port available for RTP, the actual voice conversation can begin.

In other words, SIP + RTC require one port on a proxy to register (usually 5060), one port on SIP clients to receive INVITEs (usually

5070), and one RTP on SIP clients to exchange voice data (any port will do)?
Reply to
Vincent Delporte
Loading thread data ...

The RTP requires two ports, one in each direction.

Reply to
Lonewolf

OK. And apparently, it chooses n and n+1, at random starting from one port given in the client configuration. That must be a bitch to use when the two clients are located behind NATed routers...

Reply to
Vincent Delporte

I'm not aware of any particular method for assigning the ports. I suggest you look at rfc2543. Around page 120 you'll see some sample calls and an explanation of SDP, I think.

I've seen SIP clients using NAT with no real problems. The key here is to make sure none of the potential ports are being blocked. The vendor should be able to supply you with a list of TCP and UDP ports their system uses.

Ethereal's statistics/voip is a pretty effective way to troubleshoot a SIP call. Select the call and graph it and you'll see what's going one. From there you should also see what's not going on.

Good Luck!

Reply to
Lonewolf

Below is the message body of the SIP (183) in progress message. See the Media Description field (the first one). This is where the UDP port is assigned for the RTP stream (audio stream). In this case the caller will use port 50006 (from the invite message) as it's source port and the 41890 as the destination port to the callee. The callee will have a similar SDP message telling it to use port 50006.

I hope this helps more than it confuses.

Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): AudiocodesGW 15554 85374 IN IP4

0.0.0.157 Owner Username: AudiocodesGW Session ID: 15554 Session Version: 85374 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 0.0.0.157 Session Name (s): Phone-Call Connection Information (c): IN IP4 0.0.0.157 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 0.0.0.157 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 41890 RTP/AVP 0 Media Type: audio Media Port: 41890 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU Media Attribute (a): rtpmap:0 pcmu/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 0 pcmu/8000 Media Attribute (a): ptime:20 Media Attribute Fieldname: ptime Media Attribute Value: 20 Media Attribute (a): sendrecv Media Description, name and address (m): video 0 RTP/AVP 96 Media Type: video Media Port: 0 Media Proto: RTP/AVP Media Format: 96
Reply to
Lonewolf

Defiinitely :-) I'll check out Ethereal and its support for SIP.

Thank you.

Reply to
Vincent Delporte

Ethereal _does_ support SIP

Reply to
ldemsp

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.