Re: [MMUSIC] 10 BUNDLE questions

["Ejzak, Richard P (Richard)" <[e-mail]>]

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: [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?)

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