Re: TURN returning multiple MAPPED-ADDRESSes

inline.

Jon Ringle wrote:
> If TURN provided a mechanism to return multiple MAPPED-ADDRESSes (for each 
> address that the TURN server knows is a potential address that a client could 
> use to reach it) from a single Allocate request, these are the pros and cons 
> that I see:
> 
> Pros:
> 1) It increases the likelihood that a remote address (RA) will be successful 
> in contacting one of the public address (PA) (aka MAPPED-ADDRESS) associated 
> with the source address (SA). This solves the problem of reaching a TURN 
> server behind a "no hairpin" NAT from a client that is behind the same NAT.

Right. That benefit is also obtained using the two-queries approach in 
my other email. In both cases, you need to get multiple addresses.

> 
> 2) It provides a shorter route thru the TURN server by avoiding a hairpin hop 
> on a NAT that does allow hairpinning.

Right. Same as above.

> 
> Cons:
> 1) When an ICE enabled client gets multiple addresses from a TURN server, it 
> may not be clear which address should be used for the benefit of non-ICE 
> peers. The TURN server configuration may be able to provide a priority hint 
> to the ICE client for each address it returns.
> 
> For instance, a TURN server administrator may know that all SIP devices on one 
> side of a NAT are all ICE-enabled. If this is true, then the ICE client 
> should set the m= and c= SDP parameters to the address that has a greater 
> likelihood of having non-ICE enabled clients. The TURN Allocate response 
> could convey this information in some way to help the ICE enabled client with 
> this descision.
> 
> The problem could also be worked around by changing the network topology, so 
> that the TURN server is not located behind a "no hairpin" NAT, but located on 
> the public side of the NAT with it's own public IP address.

Excellent observation. You are right, and I believe I had identified 
this issue in some version of the sipping nat-scenarios draft.

The essence of the problem is that, when the turn server is effectively 
multi-homed (which is more or less what is happening here), you run into 
the issue that its not obvious which address is most likely to work with 
a peer. The prime use case I saw for this multi-homing was the 
enterprise deploying a turn server that was must-use for external 
communications. Now, in this case, its highly likely that the enterprise 
would deploy voip so that all of the clients are ice-capable. Thus, you 
would be worried about non-ice capable clients outside of the 
enterprise. Thus, the address you put in the m/c line would be the 
public IP address from the TURN server, not the private one.

Now, in terms of how to know which one is the public and private one, I 
think that is something that is part of the policy input of ICE. That 
is, an ICE client makes a policy decision about how it prioritizes its 
addresses. There needs to be a way for the provider to tell the client 
what the policies are for this. We have a spec that covers that broadly:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-session-indep-policy-00.txt

basically, the information would be included as part of the 
configuration profile of the UA.

TURN itself doesn't provide a way to say, "this is the public IP" and 
"this is the private IP". It can be more complicated than that, in more 
complex multi-homed topologies. As such, it is my preference to leave 
the configuration of policy to the policy framework above, rather than 
try and push a piece of it through TURN.

Opinions and comments welcome.

Thanks,
Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com