Re: TURN returning multiple MAPPED-ADDRESSes

On Friday 01 October 2004 12:41 am, Jonathan Rosenberg wrote:
> 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.

It took some time to analyze the non-ICE <-> ICE scenario. My conclusion on 
this is as follows:

It seems to me that using the TURN derived address for the benefit on non-ICE 
peers will almost always result in media only flowing from the non-ICE peer 
to the ICE peer (via the TURN server). The media from the ICE peer to the 
non-ICE peer would usually not go anywhere becuase the non-ICE peer provided 
the ICE peer with it's local interface address, which the ICE peer cannot 
reach when traversing a NAT. This is a half-dead conversation which isn't 
much better that a dead one :) In fact, in the cases where two way 
communication would occur successfully between a ICE and non-ICE peer, the 
communication would also be successful if the ICE peer had provided the 
non-ICE peer with the local interface address instead of the TURN derived 
address. So, I believe that it is better for an ICE peer to advertise the 
local interface in the m/c lines.


Jon