Re: TURN returning multiple MAPPED-ADDRESSes

On Saturday 02 October 2004 12:49 pm, Jon Ringle wrote:
> 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.

Unless, the ICE peer ignores the address provided by the non-ICE peer, and 
instead sends media to the TURN derived address. The assumption is that the 
non-ICE peer will lockdown the TURN binding when it sends media to the TURN 
derived address provided by the ICE peer. Then the media sent from the ICE 
peer to the TURN server will therefore be sent to the lockdown address (which 
should be the non-ICE peer's NAT assigned address).

Is this the expected result of providing a TURN derived address to a non-ICE 
peer?

Jon