Re: [MMUSIC] 10 BUNDLE questions

On 03/15/2013 09:51 PM, Justin Uberti wrote:
> The list below is a set of questions (some marked as OPEN ISSUE 
> already) regarding the new BUNDLE proposal. If you agree with my 
> suggested answers, I'm willing to contribute text accordingly.
>
>  1. Can you create a BUNDLE with a single m= line? (assuming yes)
>  2. Can you create multiple BUNDLEs? (assuming yes)
>  3. When creating an initial offer, how should we deal with the case
>     where a "null" port is to be used with trickle ICE (since 6.1:1
>     indicates the ports MUST be different)
>
Tangential, sort of - when creating an initial offer, when would one 
need to use a null port?
We're creating the offer, if we don't want the m-line, we can omit it 
altogether.
(This was one of the things that simplified the problem when Christer, 
Cullen and I were discussing this version).

>  1. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>     use same c=, add rtcp-mux, same a=fingerprint)
>  2. From 6.1, list 2 - is condition 6 right? Why would we use
>     different SDES keys for a single RTP session?
>
Having the same SDES keys for two RTP sessions runs the risk of a 
two-time pad attack, I think (needs some other things to be the same 
too, but I don't think there's a guard against that anywhere). So this 
is a fatal flaw if the negotiation results in non-BUNDLE.

The lists could be better formatted - only 1, 3 and 4 are different 
between the lists, I think it's good to keep the differences between 
"before BUNDLE" and "after BUNDLE" minimal, but one should call out the 
differences.

>  1. If you start with a m= line with one SDES config (e.g. 32-bit
>     MAC), and then BUNDLE with another SDES line with a different (non
>     overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume
>     fail)
>
I assume so too. This should be noted.
>
>  1. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in
>     the offer, what happens? (assume fail)
>
I think this violates RFC 5888 section 9.1, so it should be a FAIL.
>
>  1. If you add a m= line to an existing BUNDLE, can the recipient
>     reject that BUNDLEing (assume no)
>  2. If m= lines are rejected, should their mids show up in the BUNDLE
>     answer? (assume yes?)
>      1. If not, how does remote side indicate BUNDLE support if it
>         rejects the m= lines that are BUNDLEd?
>  3. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
>     that were previously BUNDLEd (assume no)
>

Syntactically, it's easy (omit the mid from the a=group:bundle line); 
semantically, I think it hurts my mind to think about what should happen 
in the RTP session(s) and when, so let's just outlaw it.

>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic