Re: BUNDLE nightmare when first media section becomes inactive

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