On Fri, May 9, 2008 at 6:37 AM, Alan J. Bond <alan.bond at wintology.com> wrote: > 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. > No you don't get that wrong. And it doesn't work on multicast either. Hence we have PJMEDIA_UDP_NO_SRC_ADDR_CHECKING flag which can be specified when creating the UDP media transport to disable switching the sending to source address of the RTP packet. > > > 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. > Yeah my router also had uPnP turned on by factory default, so probably that contributes to the larger picture. But what is interesting to discuss is what uPnP can do that ICE/STUN/TURN combo cannot. I'm clueless about uPnP but somehow I feel that it doesn't add much more, if at all. I mean, even when uPnP is turn on by factory default and everyone has it, all (home) routers by default will not block VoIP traffic anyway, so what's the incentive on supporting it. > 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. This has been useful for me too. Any infos about what's happening in real world are always useful. :) Cheers Benny > 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 > > _______________________________________________ > 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 >
