Re: TURN returning multiple MAPPED-ADDRESSes

Thanks for taking the time to respond to my questions.
Inline.

On Tuesday 05 October 2004 10:58 pm, Jonathan Rosenberg wrote:
> 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.

Our current sip endpoints do not have a nat traversal solution (which is why I 
am so interested in ICE :) Currently, with our sip endpoints, multi-site 
locations must acheive ip routing without traversing NAT (usually by 
establishing site-to-site VPN with route tables set up). So, I guess in my 
mind I was equating non-ICE to non-NAT traversal. 

I know there are third party products that can help non-NAT traversal sip 
endpoints traverse NATs (SIP ALGs for instance).
Perhaps even a SIP ICE Proxy (though the acronym for it would get confusing :)

>
> 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.

Sorry, I meant in this case that ICE peer detects that it is communicating 
with a non-ICE peer (by virtue of the lack of alt attributes in the SDP). 
Then the ICE peer derives a turn address (which it communicates to the 
non-ICE peer via m/c). Then the ICE peer begins sending media packets to the 
turn server, assuming that eventually the non-ICE peer will cause lockdown to 
occur when the non-ICE peer sends media to the turn derived address (of 
course the non-ICE peer has no idea it is sending to a turn derived address). 
There would be no connectivity checks in this case.

>
>   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

I would be interested to know why.

> 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 guess it comes down my naive assumptions and that non-ICE doesn't mean 
non-NAT traversal. However, in a properly deployed environment, sending media 
to the TURN server should always work. right? It might be more expensive if 
the address provided by the non-ICE peer would have worked too. Perhaps this 
could be a part of the policy of the ICE client?

>
> 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.