[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] A replacement for ANAT



 

>-----Original Message-----
>From: ext Christer Holmberg [mailto:christer.holmberg at ericsson.com] 
>Sent: 07 August, 2009 12:52
>To: Hadriel Kaplan; Roni Even; Veikkolainen Simo 
>(Nokia-D/Helsinki); mmusic at ietf.org
>Subject: RE: [MMUSIC] A replacement for ANAT
>
>
>Hi,
>
>This is what I said at the mic: we already do "replace" ICE.

Well, not quite. ICE is currently the only WG document that defines how to indicate alternative transport addresses (IP address and port for a particular transport protocol). Just indicating alternative IP addresses is not enough - unless you assume that the port is always the same.


>However, even with ICE, I think one problem is that it is not 
>very clear how to use ICE for pure 
>offering-of-alternative-IP-addresses, when you don't use NAT 
>traversal - or you use another mechanism for NAT traversal.

ICE does not consider this case, since it *is* the NAT traversal mechanism. 

>Let's take a simple example:
>
>Alice sends an offer, with a single IPv4 and a single IPv6 
>address, using ICE candidates. There are no STUN or TURN candidates.
>
>Bob only supports IPv4, so he sends back an IPv4 candidate. 
>Bob doesn't provide any STUN or TURN candidates either.
>
>Now, is it is possible for Alice and Bob to start using the 
>IPv4 addresses at this point (I guess a new offer may be 
>required to indicate which candicate was chosen), or are they 
>required (by ICE) to initiate connectivity checks? What if the 
>checks fail, e.g. due to the usage of some other NAT traversal 
>mechanism, or because there is no end-to-end media path yet - 
>which may be the reason that another NAT traversal mechanism 
>in the first place.

Full ICE implementations do connectivity checks. If there is "some other NAT traversal mechanism", then I guess ICE is not needed.

Simo


>Regards,
>
>Christer
> 
>
>-----Original Message-----
>From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] 
>On Behalf Of Hadriel Kaplan
>Sent: Thursday, July 30, 2009 12:15 PM
>To: Roni Even; Simo.Veikkolainen at nokia.com; mmusic at ietf.org
>Subject: Re: [MMUSIC] A replacement for ANAT
>
>
>I'm confused by this - how does offering different *addresses* 
>in sdp-cap not "replace" ICE, but offering different ports 
>does replace it?
>
>-hadriel
>
>> -----Original Message-----
>> From: Roni Even [mailto:ron.even.tlv at gmail.com]
>> Sent: Thursday, July 30, 2009 3:43 AM
>> To: Simo.Veikkolainen at nokia.com; Hadriel Kaplan; mmusic at ietf.org
>> Subject: RE: [MMUSIC] A replacement for ANAT
>> 
>> Simo,
>> The reason for not offering different ports in cap 
>negotiation work is
>
>> to not replace ICE Roni Even
>> 
>_______________________________________________
>mmusic mailing list
>mmusic at ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic
>