Subject: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 5 Oct 2011 15:52:20 +0200

This is to announce a 2 week Working Group Last Call for

     draft-ietf-mmusic-media-loopback-16

as Proposed Standard. Please review and provide any comments you may have 
on the document before Thursday, October 20th, 2011. Comments should be 
sent to the document authors and the MMUSIC WG list.

Thanks

     Miguel & Flemming
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 5 Oct 2011 20:10:58 +0000

When looking at the diff between this version of the draft and the previous, I note the majority of the changes are around removing the "priming" mechanism in its entirety.  And there is only one small paragraph about making this work behind NATs, which basically says "SHOULD use" ICE/STUN/TURN.

What surprises me about this is I don't recall any WG consensus to make the change to pull out the priming mechanism entirely this way.  I only recall discussion around saying one SHOULD use ICE but MAY use the priming mechanism if ICE isn't supported; and keeping the priming mechanism defined in the loopback draft to explain how it works.

So... (1) why was this significant change made without apparent WG consensus, and (2) how do we expect the priming mechanism to interoperate if we don't define how it works?  Or have we decided making loopback calls to SIP UA's behind NATs is no longer important/relevant?

-hadriel

On Oct 5, 2011, at 9:52 AM, Miguel A. Garcia wrote:

> as Proposed Standard. Please review and provide any comments you may have on the document before Thursday, October 20th, 2011. Comments should be sent to the document authors and the MMUSIC WG list.
> 
> Thanks
> 
>    Miguel & Flemming
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Sat, 08 Oct 2011 08:54:15 -0400

Hi Hadriel

The issue was discussed on the mailing list in August, where the authors 
suggested it as a path forward and the chairs asked the WG for feedback 
on this approach, see e.g.

http://www.ietf.org/mail-archive/web/mmusic/current/msg08857.html

The issue was also discussed in the last IETF MMUSIC meeting (see 
http://www.ietf.org/proceedings/81/minutes/mmusic.txt)

To date, we have only seen opposition to this proposal from you (on both 
the mailing list and in the meeting), and we are lacking an alternative 
path forward that can satisfy all involved parties, including the 
general AD and WG chair concerns around definining an alternative NAT 
traversal mechanism in this draft without proper discussion and general 
considerations around the need for an alternative to ICE (per the above 
thread). To recap, the proposal we made was:

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

If you do not find this path forward acceptable, can you please suggest 
an alternative that satisfies the general concerns around defining an 
alternative NAT traversal mechanism in this draft ?

Thanks

-- Flemming & Miguel

On 10/5/11 4:10 PM, Hadriel Kaplan wrote:
>>     Miguel&  Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Oct 2011 14:59:17 +0000

On Oct 8, 2011, at 8:54 AM, Flemming Andreasen wrote:

> The issue was discussed on the mailing list in August, where the authors suggested it as a path forward and the chairs asked the WG for feedback on this approach, see e.g.
> 
> The issue was also discussed in the last IETF MMUSIC meeting (see http://www.ietf.org/proceedings/81/minutes/mmusic.txt)
> 
> To date, we have only seen opposition to this proposal from you (on both the mailing list and in the meeting), and we are lacking an alternative path forward that can satisfy all involved parties, including the general AD and WG chair concerns around definining an alternative NAT traversal mechanism in this draft without proper discussion and general considerations around the need for an alternative to ICE (per the above thread).

In the email thread you referenced above there was in fact someone else who was for keeping the priming mechanism, and it wasn't me.

In fact, in that whole thread there was only one other person than yourself who was in favor of only having ICE in the draft.  Of course there was only one other person than myself who was in favor of keeping the primer mechanism.

My point is that there has been no consensus either way.  The authors only changed the draft due to your objections, afaict, not due to some large consensus to do so.

> If you do not find this path forward acceptable, can you please suggest an alternative that satisfies the general concerns around defining an alternative NAT traversal mechanism in this draft ?

There have been no "general concerns" as far as I can tell, other than "we have ICE defined so why not use it".   My concerns with mandating *only* ICE as opposed to having a SHOULD use ICE but MAY use primer are detailed here: 
http://www.ietf.org/mail-archive/web/mmusic/current/msg08611.html

There was no feedback/response to that, afaict.

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 17 Oct 2011 21:58:13 -0400

> My point is that there has been no consensus either way.  The authors only changed the draft due to your objections, afaict, not due to some large consensus to do so.

To be clear, the author(s), myself, and our responsible AD did send a 
note to the list suggesting this as a path forward. I asked the WG 
members to speak up if they disagreed with the suggested path forward, 
and you are the only person to argue against subsequently. While I'll 
agree there is not unanimous agreement in the group with the direction, 
I think we need to hear from more than 1 person to declare a lack of 
(rough) concensus. Having said that, it would be better if we could 
reach an agreement that is satisfactory to all.

> There have been no "general concerns" as far as I can tell, other than "we have ICE defined so why not use it".
Yes - we have a Standards Track and general solution available, so we 
should use it.

>    My concerns with mandating *only* ICE as opposed to having a SHOULD use ICE but MAY use primer are detailed here:
You are referencing a ~6 month old e-mail, and there has since then been 
several more e-mail exchanges on this subject, an explanation of the 
issues with the old approach, and a thread plus WG meeting discussion on 
the need for an ICE alternative (like latching), which didn't garner any 
takers so far. If you believe those arguments still stand and offer a 
viable path forward, then please resurrect them (either in the context 
of this e-mail thread or as a new thread), and we (and hopefully other 
members of the WG) can discuss further. Again, to recap the concerns 
with the old approach:
- We have a general and Standards Track NAT traversal solution in the 
form of ICE so we should use it
- If there is a need for an ICE alternative, then we need to discuss 
that more generally and come up with a proper solution
- If latching is indeed needed as an alternative solution to ICE, then 
it needs to be properly documented and the limitations of it spelled out 
clearly. Furthermore, the loopback draft does not seem like the right 
place for this.

Thanks

-- Flemming

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 19 Oct 2011 16:51:18 -0400

I would like to echo concerns voiced by Hadriel (in the linked e-mail
below) and particularly that loopback call should look as much similar
to regular calls as possible. Forcing deployments, which do not use ICE
for regular calls to use ICE for loopback calls, does not sound like a
good idea to me. 

Thanks,
Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Flemming Andreasen
> Sent: Monday, October 17, 2011 9:58 PM
> To: Hadriel Kaplan
> Cc: mmusic; <[email-masked]>
> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16
> 
> 
> 
> >> The issue was discussed on the mailing list in August, where the
> authors suggested it as a path forward and the chairs asked the WG for
> feedback on this approach, see e.g.
> >>
> >> To date, we have only seen opposition to this proposal from you (on
> both the mailing list and in the meeting), and we are lacking an
> alternative path forward that can satisfy all involved parties,
including
> the general AD and WG chair concerns around definining an alternative
NAT
> thread).
> > In the email thread you referenced above there was in fact someone
else
> who was for keeping the priming mechanism, and it wasn't me.
> >
> > In fact, in that whole thread there was only one other person than
> yourself who was in favor of only having ICE in the draft.  Of course
> there was only one other person than myself who was in favor of
keeping
> the primer mechanism.
> >
> > My point is that there has been no consensus either way.  The
authors
> only changed the draft due to your objections, afaict, not due to some
> large consensus to do so.
> >
> 
> > There have been no "general concerns" as far as I can tell, other
than
> "we have ICE defined so why not use it".
> >    My concerns with mandating *only* ICE as opposed to having a
SHOULD
> use ICE but MAY use primer are detailed here:

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Oct 2011 18:06:08 +0000

On Oct 17, 2011, at 9:58 PM, Flemming Andreasen wrote:
[snip]
>  Again, to recap the concerns with the old approach:
> - We have a general and Standards Track NAT traversal solution in the form of ICE so we should use it

And we are - the loopback draft explicitly says to do ICE if both sides can do so.  It doesn't ignore ICE.  The question is if the loopback draft can also say what to do if ICE isn't supported. (and no, saying "well then go support ICE" isn't an option for the reasons explained previously in the email threads)

> - If there is a need for an ICE alternative, then we need to discuss that more generally and come up with a proper solution
> - If latching is indeed needed as an alternative solution to ICE, then it needs to be properly documented and the limitations of it spelled out clearly. Furthermore, the loopback draft does not seem like the right place for this.

You make it sound like latching is some new thing - it's not - it's been around since long before ICE.  I don't disagree it's not documented in an RFC, though it is somewhat documented in draft-ietf-mmusic-media-path-middleboxes.

But I'm not sure latching even needs to be documented for loopback-draft to state something like "send packet out".  Something like what Dan Wing suggested here:
http://www.ietf.org/mail-archive/web/mmusic/current/msg08865.html

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Oct 2011 11:22:58 -0400

> And we are - the loopback draft explicitly says to do ICE if both sides can do so.  It doesn't ignore ICE.  The question is if the loopback draft can also say what to do if ICE isn't supported. (an…
I'm not sure which previous part you are referring to since many 
different points have been made by different people.

However, can we change the above to say that loopback implementations 
MUST still support ICE, but then add text/procedures around what to do 
in case ICE procedures cannot be used per the points made by Emil in 
http://www.ietf.org/mail-archive/web/mmusic/current/msg08788.html, or 
are you objecting to the "MUST support ICE" part ?

> You make it sound like latching is some new thing - it's not - it's been around since long before ICE.  I don't disagree it's not documented in an RFC, though it is somewhat documented in draft-iet…
We'll need more than that I think. As I've stated before, we have asked 
the working group on multiple occasions if there is interest in 
exploring alternatives to the ICE NAT traversal mechanisms (e.g. 
latching) and then get those discussed and documented properly. So far, 
we haven't seen any takers (and no, the loopback draft is not the right 
place to put it since it needs proper attention and discussion).

> http://www.ietf.org/mail-archive/web/mmusic/current/msg08865.html
We are going in circles here. Dan's proposed text was:
<quote>

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

</quote>

Again, media latching needs to be discussed and documented properly if 
you want to reference it, and it cannot be part of the loopback draft. 
Example questions that come to mind here:
- How does an endpoint know the "network" is using latching and hence 
whether to send this UDP packet or not ?
- Is the remote endpoint involved in this latching operation, and if so 
what does it need to do ?
- Under what circumstances should you use this media latching mechamism ?

We need something more solid to reference to move us forward, or some 
alternative concrete text proposal to the above that doesn't lead to 
open questions, e.g. along the lines of Emil's proposal, (however I'm 
not sure it goes to the extent that you are looking for in terms of 
removing ICE dependencies, but you tell me).

Thanks

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Oct 2011 03:36:07 +0000

Hi Flemming,
Sorry about the length of this email.
I think we are either talking past each other, or going in circles as you said.  :(
It would probably be better to discuss this in person in Taipei, but here's an attempt at a reset:

1) My goal is to be enable a SIP-domain administrator to make loopback test-calls from a testing system (phone or server SIP UAC) to SIP clients; whether those SIP clients be behind NATs or not.  To achieve that goal, I believe we need an RFC that we can reference the SIP client vendors to implement against.

2) To make it useful, I believe such an RFC needs to:
	a) Be likely to be implemented: the easier it is to implement, the likelier to be implemented.
	b) Be as close to normal calls as possible, both from a signaling and media-path perspective: if regular calls use ICE, media-loopback calls need to use ICE; if regular calls don't use ICE, media-loopback calls should not either... because we don't want a different media-path used for them or else the purpose of media-loopback test calls is negated.
	c) Not require changing the deployed SIP and media-handling architecture, whatever it may be; media-loopback is a testing tool, not new service/revenue, so people won't be willing to change their whole infrastructure just to make a test call.

3) Current SIP-domain media-handling architectures differ, but we don't need to go define what all of them are or could be to enable media-loopback; all we have to do is point 2(b) above: keep them doing what they do for normal calls, except in a loopback mode.  The only problem with that is that in normal calls the SIP UA sends RTP without waiting to receive RTP, for a sendrecv mode call.  Because of RFC 4787, we know that if the UA is behind a NAT then not sending some packets out first means the loopback packets won't be let in. In order to make the loopback call appear as close to a normal call as possible, therefore, we need to have the UA send some packets out first. (luckily we have RFC 4787 or we'd be having an argument about having to publish that before publishing media-loopback! ;)

4) We don't need to describe latching to specify in a media-loopback RFC that a SIP UA needs to mimic what is does in a normal call.  Al we have to say is: use ICE if you support ICE and the incoming SDP offer indicated ICE as per RFC 5245, or just send some primer RTP packets if what you would do in a normal call is send RTP without ICE.  Frankly, it won't hurt anything if a SIP UAC *always* sends primer RTP packets in a loopback call, even if it also does ICE.  Whether NAT traversal works by latching, or by some wireshark script, or by reading tea leaves doesn't matter.  We just need to follow 2(b): act like a normal call as much as possible.

5) My original email was to indicate my belief that the change from draft-15 to draft-16 is a bad one: both because it makes the situation worse not better, and because I feel it was taken without real consensus in this WG.  I wouldn't care much about the lack of consensus for some editorial nit, but I think this is a big deployment-impacting change for a vote of 3 vs. 2 to be called "rough consensus".

6) The current loopback draft-16 says this and only this with respect to handling loopback calls and NATs:
Section 5.7:
    ICE/STUN/TURN provide a general solution to establishing media
    sessions between entities that are behind NATs. Loopback sessions
    that involve one or more end points behind NATs SHOULD use these
    general solutions wherever possible.

That's it, in the ENTIRE document.  That's approaching 'useless' on the Richter scale of RFC mandates.  How do you know if you're "behind NATs"?  If it's a "SHOULD", what's the exception/alternative?  What if you're not in "wherever possible"?
The previous draft version-15, on the other hand, told you what to do if not ICE. We can argue about whether what it said to do was good or not, but at least it did something. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Oct 2011 08:10:40 +0000

Howdy,
Before you read the insanely long email I just sent, I have a proposed solution which may satisfy you, the authors, and the Working Group as a whole.  Or maybe this solution is what the loopback draft actually means and I'm just dumb as a stump.

As I understand it, your concern is we (1) don't have an RFC defining how NAT traversal works if not with ICE, (2) don't want to define a "primer" thingy just for this one loopback draft, and (3) are dizzy from of going around in circles. :)

Well... there is an escape clause in ICE RFC 5245, section 5.1, for what to do if there's an ICE mismatch or a received Offer doesn't indicate ICE.  In theory an ICE-supporting UA must follow that behavior.  The rationale for this is explained in section 18, with regards to ALGs and SBCs.  

Note that when the other side doesn't do ICE or there is an ALG, section 5.1 instructs the UA to do section 10.  Per section 10, if the peer supports ICE at all (even if ICE is mismatched and not being used), the local UA sends STUN Binding Indications as the keepalives.  If the peer doesn't support ICE at all, then what the local UA sends is its choice.  Examples the ICE RFC gives is Comfort Noise, or draft-ietf-avt-rtp-no-op (which I believe was written by someone named Flemming Andreasen :)

My point in all this is to propose the following high-level straw-man:

1) We use the STUN Binding Indications as our primer packet format, by referencing STUN RFC.
2) We put in text that a UA loopback-mirror MUST either support ICE, or at least section 10 of ICE.
3) We specify that the media-loopback indication in SDP means the loopback-source supports receiving and ignoring STUN Binding Indications, so that following Section 10 of RFC 5245 the mirror MUST send STUN not no-op or comfort noise.
4) We put some text in the loopback-source about sources MUST support ignoring received STUN Binding Indications, not depend on getting them, etc.
5) We fix all of Magnus' comments and publish this as an RFC before our Sun becomes a red giant and dies out.
6) Profit?

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 27 Oct 2011 21:40:29 -0400

> Before you read the insanely long email I just sent, I have a proposed solution which may satisfy you, the authors, and the Working Group as a whole.  Or maybe this solution is what the loopback dr…
I don't think either is really the case (or at least it's far from 
obvious :-)

> As I understand it, your concern is we (1) don't have an RFC defining how NAT traversal works if not with ICE, (2) don't want to define a "primer" thingy just for this one loopback draft, and (3) a…
Right, and
(4) If we are not happy with ICE as our IETF NAT traversal mechanism, 
for whatever reason, then we as WG need to be explicit about that and 
figure out a way of addressing it in general - not just in the form of 
and as part of some loopback specific discussion (or we'll have another 
one of these threads when the next draft comes along that needs to work 
behind NATs, but doesn't really want to do ICE).

> Well... there is an escape clause in ICE RFC 5245, section 5.1, for what to do if there's an ICE mismatch or a received Offer doesn't indicate ICE.  In theory an ICE-supporting UA must follow that…
Right - I think this was Emil's point as well (further noting that even 
when ICE is supported, a media latching SBC may lead to these procedures 
being invoked).

> Note that when the other side doesn't do ICE or there is an ALG, section 5.1 instructs the UA to do section 10.  Per section 10, if the peer supports ICE at all (even if ICE is mismatched and not b…
:-)
> 1) We use the STUN Binding Indications as our primer packet format, by referencing STUN RFC.
Any reason we can't reference the ICE RFC and make it a "SHOULD" 
implement ?
> 2) We put in text that a UA loopback-mirror MUST either support ICE, or at least section 10 of ICE.
Ok - I think we can reference ICE in 1) then (right ?)

> 4) We put some text in the loopback-source about sources MUST support ignoring received STUN Binding Indications, not depend on getting them, etc.
This seems like a way forward that would keep us consistent with current 
ICE procedures. We probably need to explore it in more detail (and I'd 
welcome more comments on this as well), but it seems promising. One 
question is the frequency with which these STUN Binding Requests would 
be sent ?

> 5) We fix all of Magnus' comments and publish this as an RFC before our Sun becomes a red giant and dies out.

Let's explore the details further and get more comments on this.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 27 Oct 2011 21:42:41 -0400

Hi Hadriel

Per your other subsequent e-mail 
(http://www.ietf.org/mail-archive/web/mmusic/current/msg08979.html), 
I'll defer on this one. If your other proposal ends up not moving 
forward, then please resurrect this one again.

Thanks

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 03:36:34 +0000

On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote:

> (4) If we are not happy with ICE as our IETF NAT traversal mechanism, for whatever reason, then we as WG need to be explicit about that and figure out a way of addressing it in general - not just in the form of and as part of some loopback specific discussion (or we'll have another one of these threads when the next draft comes along that needs to work behind NATs, but doesn't really want to do ICE).

While I and some others have noted on multiple occasions that ICE isn't the utopian solution it's cracked up to be, it appears so far we're still in the minority in the WG.

I did put in text in:
http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00
in Appendix A.2, of an example why ICE can't be used for some people - but that's sort of an obscure reference because the point of the draft is about IPv4/v6 not NATs.  There're other ICE-problem examples too, like in the Enterprise market where the IT guys want to force the media to go through their VPNs or stay inside and never reach the public Internet.

But essentially media-loopback is the only case I've seen where there's a NAT problem to solve that isn't auto-handled by just normal RTP behavior and latching.  The IPv4/v6 case isn't a NAT traversal problem per se, nor a latching one, but more of a need to indicate multiple address families in SDP, competing with the desire by some others in the WG that a connectivity check type thing happens because IPv6 isn't stable.

> Any reason we can't reference the ICE RFC and make it a "SHOULD" implement ?

How about this: "A UAC compliant with this document SHOULD implement [RFC5245], but MAY only implement section 10 of [RFC5245] with the additional rules noted in section X of this document if it does not use ICE for normal media sessions."

And section X would have something like this:
When a UAS loopback mirror receives an SDP Offer with media-loopback, if the UAS implements [RFC5245] then it follows ICE procedures, including fallback to just sending STUN Binding Indications per Section 10 of ICE if the received Offer did not indicate ICE or there is an ICE mismatch condition.  If the UAS does not implement [RFC5245], then it MUST at least follow the procedures of Section 10 of [RFC5245] and send STUN Binding Indications.  In all cases, even if ICE is not actively used, the existence of the media-loopback indication in SDP indicates the far-end is capable of receiving and ignoring STUN Binding Indications, and the local UAS MUST send such as per Section 10 of [RFC5245] as if the SDP contained a candidate line.  This is to ensure some initial packets gets sent to the loopback source, to create NAT bindings or open Firewall pinholes along the path, since RTP is not generated by the loopback mirror until RTP is received.

> This seems like a way forward that would keep us consistent with current ICE procedures. We probably need to explore it in more detail (and I'd welcome more comments on this as well), but it seems promising. One question is the frequency with which these STUN Binding Requests would be sent ?

The frequency is in section 10, but I assume you mean when "inactive" mode is used in media-loopback?  That's a tough one.  In a normal call there would be no RTP in that mode, and since the tester may want to test that mode to see if it is causing problems then I think the mirror shouldn't send STUN even then.  :(

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 31 Oct 2011 15:26:37 -0400

On 10/27/11 11:36 PM, Hadriel Kaplan wrote:
> in Appendix A.2, of an example why ICE can't be used for some people - but that's sort of an obscure reference because the point of the draft is about IPv4/v6 not NATs.
Would it make sense to include this as part of John Elwells ICE draft ?

>   There're other ICE-problem examples too, like in the Enterprise market where the IT guys want to force the media to go through their VPNs or stay inside and never reach the public Internet.
>

I'd like to hear more people commenting on this. My understanding of ICE 
Section 5.1/10 in this case is that it's for keep-alives and hence you 
wouldn't send these messages initially (which is not to say that 
couldn't be changed when used with loopback - the question is how it 
differs from "real" ICE then).

> The frequency is in section 10, but I assume you mean when "inactive" mode is used in media-loopback?  That's a tough one.  In a normal call there would be no RTP in that mode, and since the tester…
I believe Section 10 would only apply to keep-alives in the scenario 
being considered here (and hence inactive mode is fine). The issue, I 
believe, is that you need these STUN binding packets sent initially to 
punch a hole through the NAT, and I don't believe the current RFC 5245 
by itself will give you that.

-- Flemming

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 01 Nov 2011 07:13:21 +0100

Can rfc6263   RTP Keep-alive be referenced for the non-ICE case?

/Gunnar

Flemming Andreasen skrev 2011-10-31 20:26:
>>>> As I understand it, your concern is we (1) don't have an RFC 
>>>> defining how NAT traversal works if not with ICE, (2) don't want to 
>>>> define a "primer" thingy just for this one loopback draft, and (3) 
>>>> are dizzy from of going around in circles. :)
>>>>
>>> Right, and
>>> (4) If we are not happy with ICE as our IETF NAT traversal 
>>> mechanism, for whatever reason, then we as WG need to be explicit 
>>> about that and figure out a way of addressing it in general - not 
>>> just in the form of and as part of some loopback specific discussion 
>>> (or we'll have another one of these threads when the next draft 
>>> comes along that needs to work behind NATs, but doesn't really want 
>>> to do ICE).
>> While I and some others have noted on multiple occasions that ICE 
>> isn't the utopian solution it's cracked up to be, it appears so far 
>> we're still in the minority in the WG.
>>
>> I did put in text in:
>> in Appendix A.2, of an example why ICE can't be used for some people 
>> - but that's sort of an obscure reference because the point of the 
>> draft is about IPv4/v6 not NATs.
>>   There're other ICE-problem examples too, like in the Enterprise 
>> market where the IT guys want to force the media to go through their 
>> VPNs or stay inside and never reach the public Internet.
>>
>> But essentially media-loopback is the only case I've seen where 
>> there's a NAT problem to solve that isn't auto-handled by just normal 
>> RTP behavior and latching.  The IPv4/v6 case isn't a NAT traversal 
>> problem per se, nor a latching one, but more of a need to indicate 
>> multiple address families in SDP, competing with the desire by some 
>> others in the WG that a connectivity check type thing happens because 
>> IPv6 isn't stable.
>>
>>
>> How about this: "A UAC compliant with this document SHOULD implement 
>> [RFC5245], but MAY only implement section 10 of [RFC5245] with the 
>> additional rules noted in section X of this document if it does not 
>> use ICE for normal media sessions."
>>
>> When a UAS loopback mirror receives an SDP Offer with media-loopback, 
>> if the UAS implements [RFC5245] then it follows ICE procedures, 
>> including fallback to just sending STUN Binding Indications per 
>> Section 10 of ICE if the received Offer did not indicate ICE or there 
>> is an ICE mismatch condition.  If the UAS does not implement 
>> [RFC5245], then it MUST at least follow the procedures of Section 10 
>> of [RFC5245] and send STUN Binding Indications.  In all cases, even 
>> if ICE is not actively used, the existence of the media-loopback 
>> indication in SDP indicates the far-end is capable of receiving and 
>> ignoring STUN Binding Indications, and the local UAS MUST send such 
>> as per Section 10 of [RFC5245] as if the SDP contained a candidate 
>> line.  This is to ensure some initial packets gets sent to the 
>> loopback source, to create NAT bindings or open Firewall pinholes 
>> along the path, since RTP is not generated by the loopback mirror 
>> until RTP is received.
>>
>
> I'd like to hear more people commenting on this. My understanding of 
> ICE Section 5.1/10 in this case is that it's for keep-alives and hence 
> you wouldn't send these messages initially (which is not to say that 
>>>> 3) We specify that the media-loopback indication in SDP means the 
>>>> loopback-source supports receiving and ignoring STUN Binding 
>>>> Indications, so that following Section 10 of RFC 5245 the mirror 
>>>> MUST send STUN not no-op or comfort noise.
>>>> 4) We put some text in the loopback-source about sources MUST 
>>>> support ignoring received STUN Binding Indications, not depend on 
>>>> getting them, etc.
>>>>
>>> This seems like a way forward that would keep us consistent with 
>>> current ICE procedures. We probably need to explore it in more 
>>> detail (and I'd welcome more comments on this as well), but it seems 
>>> promising. One question is the frequency with which these STUN 
>>> Binding Requests would be sent ?
>> The frequency is in section 10, but I assume you mean when "inactive" 
>> mode is used in media-loopback?  That's a tough one.  In a normal 
>> call there would be no RTP in that mode, and since the tester may 
>> want to test that mode to see if it is causing problems then I think 
>> the mirror shouldn't send STUN even then.  :(