Re: BUNDLE nightmare when first media section becomes inactive

We've been operating under the assumption that "bundle-only" isn't
necessary for subsequent offers though:


>    NOTE: Once the offerer BUNDLE address has been selected, the offerer
>    does not need to include the 'bundle-only' attribute in subsequent
>    offers.  By associating the offerer BUNDLE address with an "m=" line
>    of a subsequent offer, the offerer will ensure that the answerer will
>    either keep the "m=" line within the BUNDLE group, or the answerer
>    will have to reject the "m=" line.


Of course, this has the same problem in that it relies on the "shared vs
unique BUNDLE address" concept.

I'm starting to think this is something we may need to resolve before
completing WebRTC 1.0. Previously, rejecting m= sections was only possible
if talking to a non-JSEP endpoint, but now it's possible with
RTCRtpTransceiver.stop, so it should have well-defined behavior. I filed an
issue here, and suggest adding it to the upcoming virtual interim agenda if
time allows: https://github.com/w3c/webrtc-pc/issues/1563

On Mon, Aug 28, 2017 at 10:07 AM, Byron Campen <docfaraday@gmail.com> wrote:

> On 8/25/17 6:05 PM, Taylor Brandstetter wrote:
>
> It does work for the most part. But how do you suggest handling the
> scenario where the answerer rejects the current BUNDLE-tag m-section (
> https://bugs.chromium.org/p/webrtc/issues/detail?id=6704)? It looks like
> this works in Firefox because the offering PeerConnection always gathers
> ICE candidates for every m= section (even if they're currently being
> bundled), so it's prepared in advance for the BUNDLE-tag to change. But
> that doesn't seem ideal since it requires a bunch of extra candidates to be
> gathered for every offer/answer, right? And I think it goes against JSEP:
>
>    Note that gathering phases only gather the candidates needed by
>>    new/recycled/restarting m= sections; other m= sections continue to
>>    use their existing candidates.  Also, if an m= section is bundled
>>    (either by a successful bundle negotiation or by being marked as
>>    bundle-only), then candidates will be gathered and exchanged for that
>>    m= section if and only if its MID is a BUNDLE-tag, as described in
>>    [I-D.ietf-mmusic-sdp-bundle-negotiation].
>
>
>     It is inefficient, yes, but if we want to address that inefficiency by
> forbidding m-sections to go from bundled to non-bundled, the JSEP spec
> needs to make use of a=bundle-only.
>
> Best regards,
> Byron Campen
>