The big picture with SIP and RTP

The big picture with SIP and RTP
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.voice-over-ip  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
The big picture with SIP and RTP Vincent Delporte 08-21-2006
Posted by Vincent Delporte on August 21, 2006, 3:13 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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)

2. 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

3. B proxy rings the extension

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

5. 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)?

Spring Sale Save 20% Banner - Sale Ended 5/3/07 So Updated to NonPromo Ad
Posted by Lonewolf on August 21, 2006, 7:04 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
The RTP requires two ports, one in each direction.


> 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)
>
> 2. 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
>
> 3. B proxy rings the extension
>
> 4. B negotiates with its proxy by receiving A's address and RTP port,
> opens its own port for RTP, and sends i
>
> 5. 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)?



Posted by Vincent Delporte on August 21, 2006, 8:58 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
wrote:
>The RTP requires two ports, one in each direction.

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...

Posted by Lonewolf on August 21, 2006, 10:04 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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!

> wrote:
>>The RTP requires two ports, one in each direction.
>
> 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...



Posted by Lonewolf on August 21, 2006, 10:36 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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



Similar ThreadsPosted
no video picture in Skype 2.5 (latest Update) August 8, 2006, 10:05 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map