Mon, Sep 25, 2006 at 17:29:39, kjcsb wrote about "Re: [Serusers] NAT: minimise media proxying whilst maximising usability":
I think the key unanswered question I have is this: in the (seemingly) most common scenario of two symmetric (signalling and RTP) UAs behind two different (port) restricted cone NATs, can two-way audio be established without the use of a media proxy? I had previously thought that was possible but the latest reading I have done indicates not. Why? Because one side must initiate the audio part of the call and the other side's NAT device will not know where to send that audio on the LAN side of the network. Could someone put me out of my misery and confirm one way or the other?
Creating working stream without mediaproxy or rtpproxy is possible with all cone NATs if UA is able to use STUN, interpret the NAT is cone-like and update its SDP announces appropriately. Otherwise it begins to be chicken-and-egg problem: UA2 needs external address of UA1's RTP port to send packets to UA1; OTOH, UA1 needs external address of UA2's RTP port to send packets to UA2. If SDP announces contain external address of RTP port (with SER, it's possible only when UAs use STUN), this will work. If SDP announces contain address of intermediate port (of rtpproxy or possible mediaproxy), this will work. But SER can't fix only SDP because real RTP stream begins after exchanging announces, but SDP shall be sent in this exchanging. A kind of B2BUA could fix it, but an approach with such special B2BUA is toooooo complex as to be used in production.
Additional complication is that cone-like NATs are inapproproate for large networks and almost inappropriate for commercial production. To work, they shall map internal addresses (address as pair <host, port>) to external ones statically. But internal address set size is much more than external one (except for marginal cases) and such mapping will definitely cause conflicts. That's why symmetric NATs are preferred in large networks, opposed to cone NATs. And with symmetric NAT, no technique will give you external address for particular connection; so only real connect will give such address.
That's why I say STUN in its form according to RFC3489 (as separate server) is generally useless for SIP+RTP. A bunch of other techniques can help to detect external address stably; rtpproxy (1); ICE (which is IETF draft now and, in general, is adding of STUN capability to each UA's port, either signaling or media one) (2); of course SOCKS or similar approach will help, but it is too expensive for large networks (3).
I had thought another alternative was to map the RTP ports on the NAT device. This would mean forwarding ranges of ports to specific IP addresses (each different port range relating to a specific UA) on the NAT device. Each UA would then be configured to send RTP traffic on the port range relating to its IP address. But if both sides are behind NAT then am I right in thinking that this won't work either because the callees NAT device still doesn't know where to send it?
Your idea is good, but useless:) If you have such mapping (from internal address to external one independently of remote address) it's identical to cone NAT. If you have cone NAT, it's much simple to use STUN than invent some home-grown algorithm for port range selection and patch UAs to support it.