W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2017

Re: BUNDLE nightmare when first media section becomes inactive

From: Byron Campen <docfaraday@gmail.com>
Date: Mon, 28 Aug 2017 12:07:31 -0500
To: Taylor Brandstetter <deadbeef@google.com>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <54560151-e988-0771-7c31-591765f2be63@gmail.com>
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
Received on Monday, 28 August 2017 17:07:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:36 UTC