Re: TURN returning multiple MAPPED-ADDRESSes

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.

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

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.

Jon

On Wednesday 22 September 2004 12:47 am, Jonathan Rosenberg wrote:
> Discussions have occurred on this list, yes. I'm behind on mail as
> always and will try and respond shortly.
>
> Thanks,
> Jonathan R.
>
> Jon Ringle wrote:
> > Is this the wrong list to pose this question? If so, could someone please
> > point me to the appropriate mailing list.
> >
> > Thanks,
> >
> > Jon
> >
> > _______________________________________________
> > midcom mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/midcom