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

[Flemming Andreasen <[e-mail]>]

On 10/27/11 4:10 AM, Hadriel Kaplan wrote:
> 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.
>    
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) 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).

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

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


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

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

Thanks

-- Flemming

> -hadriel
>
>
>