Re: [MMUSIC] 10 BUNDLE questions

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

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

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

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