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
