Subject: Re: [MMUSIC] A replacement for ANAT

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 7 Aug 2009 11:51:45 +0200

Hi,

This is what I said at the mic: we already do "replace" ICE.

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.

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.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Thursday, July 30, 2009 12:15 PM
To: Roni Even; [email-masked]; [email-masked]
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:[email-masked]]
> Sent: Thursday, July 30, 2009 3:43 AM
> To: [email-masked]; Hadriel Kaplan; [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: <[email-masked]>
Date: Wed, 12 Aug 2009 10:02:41 +0200

>From: ext Christer Holmberg [mailto:[email-masked]] 
>Sent: 07 August, 2009 12:52
>To: Hadriel Kaplan; Roni Even; Veikkolainen Simo 
>(Nokia-D/Helsinki); [email-masked]

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. 

>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

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Hadriel Kaplan
>I'm confused by this - how does offering different *addresses* 
>in sdp-cap not "replace" ICE, but offering different ports 
>does replace it?
>
>-hadriel
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 12 Aug 2009 11:18:03 +0200

Hi, 

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

Well, we "partly" replace ICE, then :)

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

Well, that is the problem, if I only want to provide alternative
addresses/ports.

ANAT was not a NAT traversal mechanism, and AFAIK ICE was supposed to
replace ANAT. 

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

Well, in that case you can't offer alternative IP addresses/ports.

Regards,

Christer

> >From: [email-masked] [mailto:[email-masked]] On 
> >Behalf Of Hadriel Kaplan