Symmetric RTP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Benny,

> it's supposed to work with plain SIP clients.
> So what do we (client) need to worry about here?
My understanding is it doesn't if the client is doing asymmetric RTP (which you aren't, great!).  If I've got that wrong, please elaborate if you have time.

> So there's a big benefit there to use ICE for providers.
Agreed (10% SymNATS is probably high, depends on market sector). IMO commercial reality says providers with turnkey rigs like this will get hung out to dry by supplier feet dragging and lock-in for as long as possible.  Suppliers don't pay for bandwidth.  Hope I'm just being paranoid.

> 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

Depends where you are in the world. Router manufacturers seem to have
different defaults for different countries but there's no consistency.
IMO the number is rising fast, despite all the security blogs.

Good post Benny, a lot of insight into what PJSIP is doing here.
Apologies if it's all buried somewhere else in 4 years of archives.
Thanks,
Alan.

-----Original Message-----
From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Benny Prijono
Sent: 07 May 2008 22:36
To: pjsip list
Subject: Re: Symmetric RTP

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

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip at lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux