Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

From: Flemming Andreasen <[email-masked]>
Date: Sat, 06 Aug 2011 11:10:32 -0400

Hi Kaynam

I think this is a good path forward.

If anybody in the WG feels otherwise, please let us know.

Thanks

-- Flemming (as MMUSIC co-chair)

On 7/26/11 12:01 PM, Kaynam Hedayat wrote:
>
> Flemming, et. al,
>
> Given the amount of argument and the importance of ICE I suggest 
> removing the alternative mechanism from the draft (sections 5.7, 8, 
> 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new 
> section that requires use of ICE for calls behind NAT. I believe this 
> is the best path forward.
>
> Please let me know if the group agrees and we will change the draft 
> accordingly.
>
> Regards,
> Kaynam
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Emil Ivov
> Sent: Thursday, July 07, 2011 12:31 PM
> To: Flemming Andreasen
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE 
> alternative ?
>
> Hey Flemming,
>
> На 07.07.11 16:49, Flemming Andreasen написа:
>
> <snip>
>
> >> How are these "irregular" SDP and what reason would a middle box 
> have to
> >> remove them?
> >>
> > My point is that they are just as regular or irregular as any other SDP,
> > including ICE. The one difference I do see at this point is that by the
> > middle box changing address information in the SDP, it will effectively
> > turn off ICE based on the ice-mismatch procedure you pointed out. The
> > loopback mechanism will not suffer from this problem, as long as the
> > middle box passes through the SDP with whatever parameters it contains
> > (i.e. the middle box does not insist on understanding the SDP itself; if
> > it did, it would have to support the loopback mechanism including its
> > defined SDP extensions and loopback primer payload).
>
> Wel does it really need to support the payload or any loopback-specific
> mechanisms? I apologise if I am missing something but, as long as the
> middle box is not planning on absolutely decoding media, it should be
> OK. According to my experience, it is reasonable to expect that most SIP
> proxies would handle this properly.
>
> I am of course only talking about the NAT traversal/latching aspects of
> the draft. Obviously the echo-related params may be more exposed to
> pruning.
>
> <snip>
>
> >> Well again, I don't see anything in this draft that would allow two
> >> clients, both of which are behind a NAT, to talk to each other. The
> >> relay in the middle does. In that respect I don't see how anyone can
> >> pretend that the loopback primer is an "alternative to ICE". It is not.
> >>  It does not provide means for clients to discover a direct path to 
> each
> >> other. It does not provide relaying. It only helps to resolve a
> >> starvation in the echo use case and in a scenario where a regular
> >> bi-directional voip call would have worked anyway because of the
> >> latching that middle boxes are doing.
> >>
> > I agree with your point above, however it does also provide a limited
> > alternative to ICE inasmuch as it defines an alternative NAT traversal
> > mechanism that can be used in certain limited deployment scenarios
> > (without relays), and the way the draft is written currently, that's the
> > way this mechanim is positioned as well. Again, you are bringing up
> > another real-life use case that has merit IMO. It would be good to know
> > if there are others.
>
> Well, there's also the case of UDP-only SIP proxies. I have yet to see a
> real-life audio/video INVITE that can fit into a single ethernet MTU
> together with an ICE candidate lists. In such cases clients may again
> wish to fall back to an ICEless leap of faith and hope for latching.
>
> Of course, UDP-only proxies being prohibited by 3261, this case may be
> considered irrelevant. Still, I thought I' mention it anyway given that
> many providers out there choose not to enable TCP regardless of what
> 3261 says.
>
> Cheers,
> Emil
>
>
> --
> http://jitsi.org
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 9 Aug 2011 10:26:57 +0300

Hi,

if you could summarize what is the plan, just to be clear, that would be
great. With respect to the ICE fallback discussion, if we are defining
something that is specific to the loopback mechanism, it might make
sense to include it in the draft. However, if we are thinking of
defining a general ICE fallback mechanism, its scope would be wider than
the draft's.

Cheers,

Gonzalo

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 10 Aug 2011 14:02:38 -0400

To summarize, the current latching mechanism and the associated payload 
type definitions for it will be removed, and ICE will be the only NAT 
traversal mechanism specified for loopback in this draft. The loopback 
payload types that are needed in general (i.e. without latching) will 
remain in the draft and the PAYLOAD WG will review them as part of this 
draft.

If the authors and/or the WG believe that we should continue working on 
the latching (or other) NAT traversal mechanisms different from ICE, 
then that is something that will be discussed and/or developed outside 
of the media loopback work.

Thanks

-- Flemming

PS: I have few other nits that I will forward to the draft authors 
separately.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 10 Aug 2011 21:35:36 +0300

Hi Flemming,

thanks for the summary. Yes, this sounds like a good way forward.

Cheers,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Aug 2011 10:57:31 -0400

Howdy,
I object to this change, fwiw.

This draft was started before there was such a thing as ICE, and requiring ICE at this stage is a significant hurdle/barrier.  ICE is a huge amount of work to implement simply to get NAT traversal for media-loopback.  Obviously if the UAC and UAS already use ICE for normal calls, then all is well - and the draft allows for that - but *requiring* UAs that don't have any ICE support to support ICE simply to be able to receive/answer media-loopback calls is crazy.

Furthermore, the entire point of a media loopback mechanism is to make test calls - to verify the signaling and media paths work, as if a "real" call had been made.  Since "real" calls may not use ICE (and in fact most often do not today), mandating it be used for a media-loopback call is a mistake.  For example, it could find media paths that would not be used for actual calls, fail when it otherwise would have succeeded, or succeed when it would otherwise have failed.  That defeats the purpose of the media loopback mechanism.

-hadriel

On Aug 6, 2011, at 11:10 AM, Flemming Andreasen wrote:

Hi Kaynam

Thanks

Flemming, et. al,

Given the amount of argument and the importance of ICE I suggest removing the alternative mechanism from the draft (sections 5.7, 8, 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new section that requires use of ICE for calls behind NAT. I believe this is the best path forward.

Please let me know if the group agrees and we will change the draft accordingly.

Regards,
Kaynam

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: Thursday, July 07, 2011 12:31 PM
To: Flemming Andreasen
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

Hey Flemming,

<snip>

>> How are these "irregular" SDP and what reason would a middle box have to
>> remove them?
>>

<snip>

>>  It does not provide means for clients to discover a direct path to each

Cheers,
Emil

--
http://jitsi.org<http://jitsi.org/>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Aug 2011 11:12:24 -0700

> Behalf Of Hadriel Kaplan
> Sent: Tuesday, August 16, 2011 7:58 AM
> To: Flemming Andreasen
> Cc: Kaynam Hedayat; [email-masked]

There are two changes:  (1) removing the loopback-specific NAT traversal,
and (2) the requirement to use ICE.  I believe you are objecting to (2),
but you are okay with (1)?

> This draft was started before there was such a thing as ICE, and
> requiring ICE at this stage is a significant hurdle/barrier.  ICE is a
> huge amount of work to implement simply to get NAT traversal for media-
> loopback.  Obviously if the UAC and UAS already use ICE for normal
> calls, then all is well - and the draft allows for that - but
> *requiring* UAs that don't have any ICE support to support ICE simply
> to be able to receive/answer media-loopback calls is crazy.
> 
> Furthermore, the entire point of a media loopback mechanism is to make
> test calls - to verify the signaling and media paths work, as if a
> "real" call had been made.  Since "real" calls may not use ICE (and in
> fact most often do not today), mandating it be used for a media-
> loopback call is a mistake.  For example, it could find media paths
> that would not be used for actual calls, fail when it otherwise would
> have succeeded, or succeed when it would otherwise have failed.  That
> defeats the purpose of the media loopback mechanism.

How about something like:

  "When performing a media loopback, the endpoints MUST use the same 
   NAT traversal and the same IPv6 transition mechanism employed 
   by the network for normal call setup (e.g., ICE [RFC5245],
   media latching [I-D.ietf-mmusic-media-path-middleboxes])."

(Yes, I threw IPv6 transition into the mix, because ICE is also
the official IPv6 transition mechanism.  ICE isn't just for NAT44.)

-d

> 		Given the amount of argument and the importance of ICE I
> suggest removing the alternative mechanism from the draft (sections
> 5.7, 8, 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add
> a new section that requires use of ICE for calls behind NAT. I believe
> this is the best path forward.
> 
> 		From: [email-masked] [mailto:mmusic-
> [email-masked]] On Behalf Of Emil Ivov
> 		http://jitsi.org <http://jitsi.org/>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Aug 2011 16:04:14 -0400

On Aug 16, 2011, at 2:12 PM, Dan Wing wrote:

>> From: Hadriel Kaplan

Nope - I object to both. :)  
The current draft already supports using ICE, but doesn't mandate it be used. 

> the official IPv6 transition mechanism.  ICE isn't just for NAT44.)

I'm ok with the sentence, but the draft needs to specify how to "prime the pump" (i.e., what's in section 5.7 and 8)... since there is no such thing specified elsewhere and media-loopback has the unusual property of being one-way forever.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Aug 2011 13:15:18 -0700

> Sent: Tuesday, August 16, 2011 1:04 PM
> To: Dan Wing
> Cc: Flemming Andreasen; Kaynam Hedayat; [email-masked]
> I'm ok with the sentence, but the draft needs to specify how to "prime
> the pump" (i.e., what's in section 5.7 and 8)... since there is no such
> thing specified elsewhere and media-loopback has the unusual property
> of being one-way forever.

So an additional sentence added to my suggested paragraph above,
such as:

  "If the network is using media latching, the endpoint MUST emit
   a UDP packet (in order for media latching to work) towards the 
   remote endpoint and it SHOULD send several packets to accommodate
   packet loss.  If the network is using ICE or media latching, the
   endpoint SHOULD emit packets every 15 seconds to accommodate
   stateful middleboxes (e.g., NATs) [RFC6263]."
   
would suffice?

-d