Re: [MMUSIC] 10 BUNDLE questions

[Justin Uberti <[e-mail]>]

On Sun, Mar 17, 2013 at 1:01 AM, Harald Alvestrand <[e-mail]>wrote:

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

If you are hiding your source address when doing trickle, some non-zero
port # needs to be put into the offer. The current thinking was to use port
9 for this, but this would mean all m= lines would share port 9, although
their ICE info would be different.

This is a corner case, but I think we should specify the behavior exactly.

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

I was referring to 6.1, list 2, which indicates the behavior to be used
when we know we are BUNDLEing (i.e. one RTP session). List 2 says to use
different SDES keys in this case.

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

According to 9.2, the only restriction is the answer mids must be a subset
of the offer, so we would have to specify an exact match directly. But I
think we do want to impose this restriction, or else we can't BUNDLE a new
m-line until we know the other side wants to BUNDLE it as well.

>
>
>    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?)
>
> Turns out 5888 spells out the behavior here, namely the mids do not
appear.

>
>     1. If not, how does remote side indicate BUNDLE support if it rejects
>       the m= lines that are BUNDLEd?
>
> 5888 also says an empty a=group:BUNDLE line is permissible, so this is a
non-issue.

>
>     1. 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.
>

SGTM

>
>
>
> _______________________________________________
> mmusic mailing [e-mail]://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>