Re: [MMUSIC] 10 BUNDLE questions

[Justin Uberti <[e-mail]>]

On Thu, Mar 21, 2013 at 6:52 PM, Ejzak, Richard P (Richard) <
[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *Justin Uberti
> *Sent:* Friday, March 15, 2013 3:51 PM
> *To:* [e-mail]
> *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)****
>
>