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

From: Flemming Andreasen <[email-masked]>
Date: Wed, 02 Nov 2011 16:54:21 -0400

That might be another option (multiplex RTP and RTCP with RTCP as the 
keep-alive mechanism), however I think you still have the issue of 
sending the intial packets to punch a hole.

-- Flemming

On 11/1/11 2:13 AM, Gunnar Hellström wrote:
> Can rfc6263   RTP Keep-alive be referenced for the non-ICE case?
>
> /Gunnar
>
>
> Flemming Andreasen skrev 2011-10-31 20:26:
>>
>>
>> On 10/27/11 11:36 PM, Hadriel Kaplan wrote:
>>> On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote:
>>>
>>>>> 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:
>>> 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.
>> 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.
>>>
>>> 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.
>>>
>>>
>>>>> 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.
>>>>>
>>>> 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.
>>>
>>
>> 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).
>>
>>>>> 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.  :(
>> 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
>>
>>
>>> -hadriel
>>>
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 02 Nov 2011 22:52:23 +0100

With the reasoning about why the keep-alive according to RFC6263 is 
needed, I would expect that it would transmit first keep-alive 
immediately, so that the hole is punched.

RFC6263 is intended for example for payloads that may have long pauses 
between transmissions. The "pause" may be from the beginning. For such 
payloads, an initial priming through NAT is needed, and RFC6263 can 
provide that.  But that might be up for interpretation...

Gunnar

Flemming Andreasen skrev 2011-11-02 21:54:
>>>> 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.
>>>> market where the IT guys want to force the media to go through 
>>>> their VPNs or stay inside and never reach the public Internet.
>>>>
>>>> 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."
>>>>
>>>> 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.
>>>>
>>>
>>> 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).
>>>
>>> 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
>>>
>>>
>>>> -hadriel
>>>>
>>>>
>>>