Subject: [MMUSIC] 10 BUNDLE questions

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Mar 2013 13:51:04 -0700

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)
   4. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use
   same c=, add rtcp-mux, same a=fingerprint)
   5. From 6.1, list 2 - is condition 6 right? Why would we use different
   SDES keys for a single RTP session?
   6. 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)
   7. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the
   offer, what happens? (assume fail)
   8. If you add a m= line to an existing BUNDLE, can the recipient reject
   that BUNDLEing (assume no)
   9. 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?
   10. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
   that were previously BUNDLEd (assume no)

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 17 Mar 2013 09:01:51 +0100

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Sun, 17 Mar 2013 20:19:49 -0700

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

>    2. From 6.1, list 2 - is condition 6 right? Why would we use different
> 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.

>    1. If you start with a m= line with one SDES config (e.g. 32-bit MAC),

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.

> Turns out 5888 spells out the behavior here, namely the mids do not
appear.

> 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
> 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 [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Mar 2013 08:08:22 +0100

On 03/18/2013 04:19 AM, Justin Uberti wrote:
>
>
>>      1. If the BUNDLE mids in the answer doesn't match the BUNDLE
>>         mids in the offer, what happens? (assume 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.

The important phrase from 9.1 is

    If a media stream that contained a particular "mid" identifier in the
    offer contains a different identifier in the answer, the application
    ignores all of the "mid" and "group" lines that might appear in the
    session description.  The following example illustrates this
    scenario.

So if there's any mismatch, we don't get BUNDLE negotiated. Negotiation 
might not fail, but we don't get BUNDLE (or any other form of grouping).

---

From: Justin Uberti <[email-masked]>
Date: Mon, 18 Mar 2013 08:59:22 -0700

You're looking at the handling of a=mid, not a=group.

Section 9.2 indicates the handling of a=group, which seems to indicate a
subset is allowed:

   A SIP entity that receives an offer that contains an "a=group" line
   with semantics that are understood MUST return an answer that
   contains an "a=group" line with the same semantics.  The
   identification-tags contained in this "a=group" line MUST be the same
   as those received in the offer, or a subset of them (zero
   identification-tags is a valid subset).  When the identification-tags
   in the answer are a subset, the "group" value to be used in the
   session MUST be the one present in the answer.

On Mon, Mar 18, 2013 at 12:08 AM, Harald Alvestrand <[email-masked]>wrote:

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

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Mar 2013 12:18:41 -0400 (EDT)

> From: Harald Alvestrand <[email-masked]>
> 

I think what Justin means is that if an m= line does not have any
candidates at the time of the offer (candidates will be supplied
during trickle ICE), then the m= line is given a dummy port of 9.
>From draft-ivov-mmusic-trickle-ice-01 section 5.1:

   As mentioned earlier in this section, Offers and Answers can contain
   any set of candidates, which means that a trickle ICE session
   description MAY contain no candidates at all.  In such cases the
   agent would still need to place an address in the "c=" line(s).  If
   the use of a host address there is undesirable (e.g.  for privacy
   reasons), the agent MAY set the connection address to IP6 ::. In this
   case it MUST also set the port number to 9 (Discard).  There is no
   need to include a fictitious candidate for the IP6 :: address when
   doing so.

If there are multiple such lines, port 9 can appear in multiple m=
lines, and if the offerer is not hiding its address, the corresponding
c= lines could contain the host address.

Dale

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Mar 2013 22:05:37 +0100

On 03/18/2013 04:59 PM, Justin Uberti wrote:
> Section 9.2 indicates the handling of a=group, which seems to indicate 
> a subset is allowed:
>

Aha, I misinterpreted the phrase "BUNDLE mids in the answer doesn't match".

This is, in some sense, a subset of the question "is unbundling 
possible". I don't have a strong opinion on this.

>
>
>
> On Mon, Mar 18, 2013 at 12:08 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>>          1. If the BUNDLE mids in the answer doesn't match the
>>>             BUNDLE mids in the offer, what happens? (assume 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.
>
>     So if there's any mismatch, we don't get BUNDLE negotiated.
>     Negotiation might not fail, but we don't get BUNDLE (or any other
>     form of grouping).
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 18 Mar 2013 17:17:23 -0700

On Mon, Mar 18, 2013 at 2:05 PM, Harald Alvestrand <[email-masked]>wrote:

> This is, in some sense, a subset of the question "is unbundling possible".
> I don't have a strong opinion on this.
>
> The key issue here is whether the remote side can reject a BUNDLE. IOW, if
caller has A and B bundled, and adds m= line C (BUNDLEd), does the caller
need to allocate a new port, so that it can handle the case where the
callee decides only A and B should be BUNDLEd? Or can the caller offer C on
the existing A+B BUNDLEd port?

I think life would be simpler if we enforced the rule that the callee could
only accept C as BUNDLEd, or reject C entirely. IOW, any difference in the
a=group answer (other than removal of rejected mids) is fatal.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Fri, 22 Mar 2013 01:52:05 +0000

Hi Justin,
I have comments on items 4 and 10 in your original list.

4: In 6.1, list 1, if the answerer chooses to bundle and selects the 5-tuple from the first m line for the group, then it must also assume the use of the c=, rtcp-mux and a=fingerprint (all transport related attributes) from that m line for the group.  Then according to the rules, the 2nd offer must then include the same value for c=, rtcp-mux and a=fingerprint for all m lines in the group.  If you relax conditions 2, 5 and 7 for the 1st offer, it would seem a little strange and would require extra work to clean up all the m lines in the 2nd offer if the 1st offer had different values for c=, rtcp-mux and a=fingerprint in all the m lines of the group.  As I see it, it’s easier to have this rule from the beginning unless there are some use cases where you might want different values for c=, rtcp-mux and a=fingerprint if bundle cannot be negotiated.  Do you (or anyone else) see any reason to have this capability?  It probably isn’t that important a rule (except for convenience) since any middlebox will get straightened out with the 2nd offer and any peer agreeing to bundle knows to ignore the transport related information from the other lines (except as discussed below).

10: I think we have to have the ability to unbundle within a PeerConnection.  For the error case described (twice) at the mike in Orlando, if the first answer comes back asking to bundle but signaling different ports, it is because of an intermediary forwarding bundle attributes without understanding them while remapping ports.  There seemed to be agreement in this case (or at least the opinion was expressed) that the offerer needs to detect this condition and send a 2nd offer with different ports and without bundle (else the answerer will continue to assume bundle while the intermediary will not).  Note that this case appears (to the answerer) as if bundle is successfully negotiated but then it is immediately removed with the 2nd offer.

I think we also have the 3pcc use case where a mid-call bundled offer goes to a different endpoint that chooses not to bundle.  As long as it removes the bundle attributes and returns different ports, why should we disallow this?  It only requires an ICE restart.  This will even work with most (new) intermediaries except those that choke on seeing the same port in multiple m lines.  Which brings me to why I think we also need to be able to indicate via the API whether a mid-call offer is to be signaled with the same or different ports for a bundle group (as I also requested at the mike).

Richard

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Friday, March 15, 2013 3:51 PM
To: [email-masked]
Subject: [MMUSIC] 10 BUNDLE questions

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)
  4.  From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use same c=, add rtcp-mux, same a=fingerprint)
  5.  From 6.1, list 2 - is condition 6 right? Why would we use different SDES keys for a single RTP session?
  6.  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)
  7.  If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the offer, what happens? (assume fail)
  8.  If you add a m= line to an existing BUNDLE, can the recipient reject that BUNDLEing (assume no)
  9.  If m= lines are rejected, should their mids show up in the BUNDLE answer? (assume yes?)

     *   If not, how does remote side indicate BUNDLE support if it rejects the m= lines that are BUNDLEd?

  1.  Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd (assume no)