Subject: Re: [MMUSIC] 10 BUNDLE questions

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Apr 2013 17:05:34 -0700

On Thu, Mar 21, 2013 at 6:52 PM, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

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

Agreed.

>  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 2ndoffer and any peer agreeing to bundle knows to ignore the transport related
> information from the other lines (except as discussed below).
>

We already need to deal with this for a=candidate, a=crypto and
a=ice-ufrag/pwd, so I don't see why having to also do this for these other
attributes makes things any harder. It's not super important, but it seems
odd to prohibit things that would seem to be mostly unrelated to BUNDLE.

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

I think this is harder than you say. It's more than an ICE restart, it also
requires re-keying of SRTP (since we now need unique crypto per m-line) and
dealing with the sort-of-BUNDLEd case where we need to be able to receive
BUNDLEd and non-BUNDLEd media potentially simultaneously during the
transition. I'd really like to avoid having to deal with this.

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

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 4 Apr 2013 20:36:09 +0000

> From: Justin Uberti [mailto:[email-masked]] 
> Sent: Wednesday, April 03, 2013 7:06 PM

>> On Thu, Mar 21, 2013 at 6:52 PM, Ejzak, Richard P (Richard) <[email-masked]> wrote:
>> Hi Justin,
>> I have comments on items 4 and 10 in your original list.

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

> We already need to deal with this for a=candidate, a=crypto and a=ice-ufrag/pwd, so I don't see why having to also do this for these other attributes makes things any harder. It's not super important, but it seems odd to prohibit things that would seem to be mostly unrelated to BUNDLE.

I now agree with you.
 
>> 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. 
>> u
>> 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).

> I think this is harder than you say. It's more than an ICE restart, it also requires re-keying of SRTP (since we now need unique crypto per m-line) and dealing with the sort-of-BUNDLEd case where we need to be able to receive BUNDLEd and non-BUNDLEd media potentially simultaneously during the transition. I'd really like to avoid having to deal with this.

There are two things being described here (being able to unbundle and being able to request new offers with same or different ports), and it seems that you are most concerned about the former.  I am a little surprised that Hadriel (one of the individuals who spoke at the mike about the error case described above) and Magnus/others (with whom I also spoke privately about it) have not chimed in on this, as it was provided as a key justification for the need to have two different offer formats (same/different ports) rather than the simpler scheme I proposed with a single offer format (all different ports).  I unfortunately don't see any good alternative to "dealing" with this.  As I've said before, dealing with the old and new media formats during the transition triggered by offer/answer is a lot like cloning - which could have also solved other issues.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Apr 2013 08:35:06 +0800

Replying to Justin,

(For some reason I got Richard's replies to Justin, but not the messages 
from Justin!)

>> I think this is harder than you say. It's more than an ICE restart, it also requires re-keying of SRTP (since we now need unique crypto per m-line) and dealing with the sort-of-BUNDLEd case where…

There are lots of things that I would really like to avoid dealing with.
(E.g. income taxes.)

But just because I would like to doesn't mean I can.
3pcc scenarios break a lot of first proposals for how to do things.
The solution is to fix the proposal so it still works.
You can't control whether this happens to you.

	Thanks,
	Paul

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 19 Apr 2013 16:19:13 +0000

On Mar 15, 2013, at 2:51 PM, Justin Uberti <[email-masked]> 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.
> 	• Can you create a BUNDLE with a single m= line? (assuming yes)

yes, have to to add more later 

> 	• Can you create multiple BUNDLEs? (assuming yes)

yes but a given m line can only be in one 

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

I think we should change bundle to allow the null port 
- it really needs to be all the parameters related to transport / crypto need to be different, or at least as different as they would be required to be if you were not doing bundle. Key thing is if other side does not understand bundle, this looks like an "normal" offer with no bundle. 

> 	• From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use same c=, add rtcp-mux, same a=fingerprint)

on rtcp-mux, I think it simplifies thing to mandate rtcp-mux. So if far side accepts bundle but rejects rtcp-mux, this is a fail. 

on c=, I can't think of any good reason to require this. Need more thought on this. 

on fingerprint, I don't think this impacts the bundle but it seems like it make simplify the code that matches the fingerprint to the DTLS connection. Be interested in hearing EKR's thoughts. 

> 	• From 6.1, list 2 - is condition 6 right? Why would we use different SDES keys for a single RTP session?

This is confusing in what you do in first is this, but once you know what you are doing, you put what you are using which will result in same not different keys. This needs series review from crypto experts. 

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

Lets say can not do that and if you do it, it is a fail. 

> 	• If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the offer, what happens? (assume fail)

fail

> 	• If you add a m= line to an existing BUNDLE, can the recipient reject that BUNDLEing (assume no)

agree it should be no

> 	• If m= lines are rejected, should their mids show up in the BUNDLE answer? (assume yes?)

don't care but we need to be clear should happen. 

> 		• If not, how does remote side indicate BUNDLE support if it rejects the m= lines that are BUNDLEd?
> 	• Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd (assume no)

In SIP terminology, I think we would do this with an "INVITE with replaces". If you want to do this, you just start a whole new offer that is not an evolution of the previous set of offer/answers. So basically I am saying not to do this at the bundle level but instead support it at the signaling level. 

> _______________________________________________

Also imagine case where 

Alice offers A, B, and C and offers to bundle them all 

Bob wants to accept A and B in a bundle and C separate

When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can either accept the bundle or not. (and separate accept or reject each m line in the bundle but can't refactor the bundling).

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Apr 2013 14:05:54 -0700

This clarifies things for me.  I hope that these are captured effectively.

> on fingerprint, I don't think this impacts the bundle but it seems like it make simplify the code that matches the fingerprint to the DTLS connection. Be interested in hearing EKR's thoughts.

I'm not EKR, but I don't see any way that having multiple sets of
credentials would be useful.  That implies multiple handshakes.

a=fingerprint pertains to the transport and as such needs to be the same.

You *could* add fingerprints from different lines as alternative valid
(in the same way that two a=fingerprint can be added to a single
line).  Since this is more likely to be mistake than something
intentional, better to require that every block in a bundle have the
same a=fingerprint.

> This is confusing in what you do in first is this, but once you know what you are doing, you put what you are using which will result in same not different keys. This needs series review from crypt…

In theory you can use multiple keys.  And it doesn't have any real
consequences.  That's not necessarily a useful property though.

> Lets say can not do that and if you do it, it is a fail.

See above - it's *possible* to have this particular example work.  But
not useful and therefore inadvisable.

I think that a good requirement is that new m= lines are entered into
a bundle when they are added to the session and that bundle can't
change.  That means you can't move m= lines in and out of bundles.
That also keeps the rules with respect to properties constant for any
given m= line.

Sure, you could make a complicated system where this was possible, but
it probably wouldn't interoperate.

>>       • If you add a m= line to an existing BUNDLE, can the recipient reject that BUNDLEing (assume no)

On first impressions, I was inclined to agree that it makes no sense
to allow for unbundling on new m= lines, but this is exactly the same
sort of scenario that an initial offer has to deal with.  Offer the
addition of a stream in a bundle, but allow for the fact that peer
might not support bundling.  So, I'm actually inclined to disagree
here.

That said, without a use case, such a capability complicates things.
I'll get to the use case below.

> When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can…

This is actually the same sort of problem as the above.  The question
is whether the bundle is negotiated as a whole, or whether answers can
differentiate on per-line basis.  I can appreciate the desire to
simplify, but you have to examine use cases.

Example: Alice offers A and B bundled, Bob accepts the bundling.
Later, Alice adds C to the bundle.  How can Bob get that m= line
routed over a different path?  Do we require that Bob reject the line
and offer the same line, potentially inverted, without bundling in a
subsequent offer?

I'm thinking here about a case where a session escalates from audio to
audio+video and there might be a middlebox involved.  I guess in that
case the middlebox needs to drive the addition.

I can probably live with the simplification, but this needs to be
crystal clear.  A more complete discussion of the implications of this
particular choice would be really helpful.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 22 Apr 2013 15:25:55 +0000

> credentials would be useful.  That implies multiple handshakes.

well, this would only be for the initial offer and if bundle is not selected, there will be multiple handshakes. I can't think of a reason that the multiple handshakes can't have the same certificate so I think I agree with you

> consequences.  That's not necessarily a useful property though.

I just want to make sure there is not chance for a two time pad problem but I assume that will not be a problem and we can use the same sdes key when bundle does not get negotiated 

> it probably wouldn't interoperate.

+1

> particular choice would be really helpful.

+1 on we need to be crystal clear. 

I think I am leaning towards once a bundle is set up, a new update to it can offer things in the bundle or not it the bundle. And if offered in the bundle, the answer can choose to put it in the bundle or not. But I want to avoid all things like the answer can move a m-line from one one bundle to another bundle or something like that. It's too complicated and I don't see the need for it. 

> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Apr 2013 08:55:11 -0700

> I just want to make sure there is not chance for a two time pad problem but I assume that will not be a problem and we can use the same sdes key when bundle does not get negotiated

The two time pad problem only arises if you have the same SSRC.
That's only possible with a shim, not if you have streams sharing the
same session.

There is a problem with SSRC collisions (in SSRC space only, even if
the collision isn't contemporaneous).  SRTP has always had that
problem and it's rare enough that no attacker could rely on it
happening.

> I think I am leaning towards once a bundle is set up, a new update to it can offer things in the bundle or not it the bundle. And if offered in the bundle, the answer can choose to put it in the bu…

That was my thought too.  That means that bundling is negotiated in
two ways: one to turn bundling on or off as a whole.  The second is
the choice to add a new stream - or allow a new stream to be added -
to a bundle, or not.  Once negotiated, you can't move them around.  If
you need that, drop the line and make another one.  That's not
especially difficult.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Apr 2013 12:47:04 -0400

> - it really needs to be all the parameters related to transport / crypto need to be different, or at least as different as they would be required to be if you were not doing bundle. Key thing is if…

When you say "null" port, do you mean *zero* port?

There is a technical problem with this. RFC5888, section 9.2, says:

    SIP entities refuse media streams by setting the port to zero in the
    corresponding "m" line. "a=group" lines MUST NOT contain
    identification-tags that correspond to "m" lines with the port set to
    zero.

This means you can't initially establish a bundle group including 
m-lines with zero ports and then negotiate a non-zero port later. To 
work around this we would either need to use some other port (e.g. 9 - 
discard) to indicate no media is initially to be sent, or else change 
RFC5888. Even then it would be necessary to change allow bundle to allow 
multiple bundled m-lines to have the same port in this case.

> don't care but we need to be clear should happen.

See above. This is currently specified by 5888. IMO what is specified by 
5888 is unfortunate. I'm undecided whether its better to try to work 
around it or change it.

> In SIP terminology, I think we would do this with an "INVITE with replaces". If you want to do this, you just start a whole new offer that is not an evolution of the previous set of offer/answers.…

IMO it would be better to allow bundling to be changed in a subsequent 
O/A, just as anything else it.

> When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can…

This is a subcase of "splitting" a bundle, which I posted on earlier:

http://www.ietf.org/mail-archive/web/mmusic/current/msg10683.html

IMO it *must* be permissible to accomplish this in some way.
For the case of splitting one bundle into two bundles, I concluded that 
it will take another O/A. Just leaving some of the proposed bundle 
candidates out of single bundle seems to be acceptable to 5888. I see no 
reason to circumvent that for bundle groups.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Apr 2013 19:16:25 -0700

After reading the thread, here are my proposed answers...

> Can you create a BUNDLE with a single m= line? (assuming yes)

Yes.

> Can you create multiple BUNDLEs? (assuming yes)

Yes.

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

I think it's ok for the null port to not be equal.

> From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>  use same c=, add rtcp-mux, same a=fingerprint)

I don't know if rtcp-mux is necessary, but it seems stupid not to
have it.

I think we do need to have matching fingerprints because we can
only have one DTLS-SRTP association and it's hard to understand
what the security properties are if the two associations
in principle might have different credentials.

> From 6.1, list 2 - is condition 6 right? Why would we use different
> SDES keys for a single RTP session?

So, I note that this list requires that the other side *support*
bundle not that he accept it. So, there's still some chance
of getting things unbundled, no?

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

So, this seems like an argument for using distinct SDES lines
since then you can just keep the SDES line associated with its
associated m-line.

> If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the
> offer, what happens? (assume fail)

That sounds right to me.

> If you add a m= line to an existing BUNDLE, can the recipient reject
> that BUNDLEing (assume no)

I think life would be simpler if this just caused a negotiation
fail if the other side was sad about it.

> If m= lines are rejected, should their mids show up in the BUNDLE
> answer? (assume yes?)

That sounds easiest.

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

I would say no.

After all, you can always discard those lines and offer new lines.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Apr 2013 09:44:27 -0400

On 4/22/13 11:25 AM, Cullen Jennings (fluffy) wrote:

[snip]

The second o/a I proposed for splitting a bundle would not be allowed by 
what the two of you are proposing. There are real use cases for this, 
where the offerer processes all the streams at a single network access 
point, but the other endpoint processes them at multiple access points.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Apr 2013 10:35:37 -0400

inline, trimming

> I think it's ok for the null port to not be equal.

What is a "null" port?

In any case, ISTM this reply isn't responsive to the question.
IIUC, the question was:

- the current spec says that the initial bundle offer must have
   *different* addr/port for each m-line;

- but if, in conjunction with trickle ice, you want to make the
   initial offer have *null* port, then multiple m-lines will have
   the *same* null port.

This seems to require that the bundle spec acknowledge and permit this case.

>  > offer, what happens? (assume fail)

Exactly what does "fail" mean here?
It is the receiver of the answer that detects this issue.
Presumably the answerer didn't consider it an error, and
so won't know the offerer thinks it is.

So does "fail" mean that the offerer should tear down the 
PeerConnection? Or what?

> fail if the other side was sad about it.

If the change was to add a new m-line, that previously was not present, 
to the SDP *and* to the bundle, then answerer could potentially either:

1) accept the m-line (non-zero port) and accept the bundling
    (matching mid-line to what was in the offer)

2) accept the m-line and reject the bundling (mid value
    for the rejected m-line omitted from the bundle group)

3) reject the m-line (zero port) and reject the bundling. For better
    or worse, RFC5888 requires this behavior in the group line for
    rejected m-lines.

I guess you are suggesting that (2) be unacceptable. Again, what do you 
expect to happen in that case?

>  > If m= lines are rejected, should their mids show up in the BUNDLE

I think RFC5888 requires this. (But it may be arguable.)

But it also requires that the group in the answer not reference the mid 
tag of the rejected m-line.

> After all, you can always discard those lines and offer new lines.

ISTM there are more details to be worked out:

* When is an m-line considered to have been "previously bundled"?

   - Is it when it was first offered with a mid tag referenced by
     a bundle group line?

   - Or is it the first time the mid tag appears in a bundle group
     in an answer?

   ISTM it should be the latter, not the former. That means m-lines
   that were offered but rejected in the answer are not bundled,
   and so can be reused in a subsequent offer to propose a separate
   bundle.

* When "offering new lines", must those lines really be *new*,
   or can they include the recycling of m-lines that were previously
   rejected?

   Precedent says that these are functionally equivalent.

* Is there any requirement for preservation of mid tags from
   one O/A cycle to the next? IOW, is the *value* of the mid tag
   for each m-line part of the persistent state of the session?

   - I think there is a requirement that the *bundling* be
     preserved;

   - But the mid tags are merely a means to an end for describing
     the grouping. It is not important that the specific tags
     be preserved.

   - There could be a difference between what is required here
     for 3264 usage and what is required for JSEP, since the
     usage for JSEP is not a wire protocol.

Thanks,
Paul