[pjsip] Symmetric RTP

Benny Prijono bennylp at pjsip.org
Wed May 7 17:36:23 EDT 2008


On Wed, May 7, 2008 at 7:03 PM, Alan J. Bond <alan.bond at wintology.com> wrote:
> Hi Nanang,
>
> Good!  It's already symmetric then (by my definition anyway).  I just

Yep, we always do symmetric since the beginning, and by default the
UDP transport will switch to the source address of the RTP packet,
unless this feature is turned off.

> noticed pjsua opened 4 ports at start up.  I can see now that's directly
> related to the --max-calls default.
>

Yes.

> A lot of UAs default to two lines,  I saw 4 ports and alarm bells went off
> in my head.  Here's why ...
>
> An early attempt at NAT traversal (now non-compliant) used a technique of
> fiddling with the address  in Contact: headers on registration (replacing
> internal with external on reply) in conjunction with an RTP relay on a
> public IP to eliminate NAT-to-NAT scenarios.  That is I think the origin of
> the fix_nated_contact() option in (Open)SER. However, that's SIP.  For media

Yes again. We're also fiddling with the Contact of our REGISTER
request to make it work with symmetric NAT, but there's nothing
non-compliant in there.

> streams the RTP proxy part only works with symmetric RTP on some NATs (most
> domestic ADSL routers these days).  Wherever the client outgoing stream
> appears to the proxy is where the incoming stream gets sent back.  No STUN
> or similar required in theory, but very heavy traffic hit on the provider's
> infrastructure.  Some carrier class RTP relays use megabucks hardware built
> specifically to handle the load, which won't get scrapped in a hurry
> (especially with core bandwidth getting ever cheaper).
>

Sorry I don't quite get you. If the provider is using RTP relay (with
some sort of B2BUA), then it's supposed to work with plain SIP
clients. So what do we (client) need to worry about here?

> While ICE will be wonderful anytime soon, some commercial platforms will
> carry on using this method regardless - well after ICE has been ratified and
> adopted.  It's therefore perhaps important for widespread adoption that we
> try hard to accommodate this sort of thing as long as it doesn't compromise
> anything compliant in any way.  No worries on this issue anyway :-)
>

One of the purpose of ICE is to reduce the bandwidth required for the
RTP relay, since with ICE, relay is only used as the last resort. Some
says that only less than 10% of client to client traffic needs to be
relayed (due to symmetric NATs), so there's a big benefit there to use
ICE for providers.

> Anyone with other non-compliant behaviours we ought to be thinking about?
> Any  thoughts on UPnP support (no rants please)?
>

My personal opinion, uPnP (and probably SOCKS) is nice to have, but it
doesn't really attack the problem. I mean, how many people have uPnP
turned on (probably most likely by factory default) in their home NAT
router? I have a feeling that probably the number is small, but this
is just a pure guess.

ICE, STUN, and TURN combo is the best solution that we have for now IMO.

Cheers
 Benny




More information about the pjsip mailing list