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.
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com