Re: TURN returning multiple MAPPED-ADDRESSes

inline.

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.

In the naive deployment, perhaps.

I think the more likely case is that there is an ICE client talking to a 
non-ICE client using some other nat traversal technique, including stun 
or a session border controller. In both cases, what apepars in the m/c 
lines in the SDP would be reachable by the ICE client.


  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.

I disagree with that assessment, based on the above. non-ICE does not 
mean non-NAT traversal. In practice nothing is really deployed without 
some kind of nat traversal solution, unless its in an environment where 
its known to be a total non-issue.

Jon also wrote:
> Unless, the ICE peer ignores the address provided by the non-ICE peer, and 
> instead sends media to the TURN derived address.

What turn derived address? THe ICE-capable element has its own 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.

Lockdown is being removed from the next rev of turn. In any case, what 
you are saying is that an ICE capable client will learn another address 
for its peer through the TURN indications of the sender address. That 
could be worked into the ICE algorithm, but the problem is that the 
ice-capable client has no way to do the connectivity checks. How then 
can it determine whether it should send media to the advertised address 
in the SDP, as opposed to what is learned by TURN?

I don't really think its important to handle this case. As I mentioned 
above, the assumption I am making is that, if a client is not doing ICE, 
it is doing something else that allows its IP/port in the m/c lines of 
the SDP to be valid. If this assumption holds, the current ICE fallback 
behavior is the right thing.

-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