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: Thu, 24 Aug 2017 09:45:04 -0500
To: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <df9e1b94-57e7-a31c-3926-d50f5d429a14@gmail.com>
On 8/24/17 6:32 AM, Iñaki Baz Castillo wrote:
> Hi,
> A PeerConnection in a browser (let's call it Mozilla XXXXXXX or
> XXXXXXX Firefox to keep it anonymous) is sending audio and video using
> BUNDLE (a single ICE+DLTS transport).
> Eventually, the app removes/closes/stops the audio RtpSender. The app
> may (or not) does the SDP O/A ceremony (createOffer,
> setLocalDescription, setRemoteDescription). Same happens:
> The PeerConnection stops sending video RTP packets.
     Yeah, that shouldn't happen. Stopping the audio sender should only 
stop RTP/RTCP. The transport should not be affected in any way until 
renegotiation happens, and then we should establish a new transport and 
switch over to it.

> The ICE+DTLS remains connected (pc.iceConnectionState did not change
> at all and remains "completed"). So this must be a BUNDLE
> implementation issue. My question is, how is this supposed to work?
> Initially, when both audio and video are being sent,
> pc.localDescription.sdp has 2 m= lines with a=mid=MID1 and a=mid=MID2,
> both a=sendrecv. And the SDP has a global "a=group:BUNDLE MID1 MID2".
> The SDP answer looks similar.
> However, once the audio sender is stopped/closed/removed, and the SDP
> O/A is done, pc.localDescription.sdp has no "a=group:BUNDLE" line, the
> m=audio section no longer has a=mid, has a=inactive and port 0.
> Well, that's expected. However the m=video remains with a=sendrecv and
> the ICE+DTLS stuff remains connected. I assume this is a bug in this
> browser, which terribly makes the transport depend on active m=
> sections (although the SDP semantics do not help here).
    Is it still using the old transport? Or has it created a new one?

> Anyhow, what should happen in this scenario?:
> * Should the browser realize that its new local offer should use the
> previous BUNDLED transport even if now there is no bundle stuff in the
> SDP?
     I don't think this is a good thing to do. We may be doing this, and 
if so should stop. I think the rule we should be following is "the 
transport follows the m-section". In other words, if the bundle tag 
changes (either because the bundle tag is disabled, or another m-section 
is made the bundle tag), we stop using that transport once O/A is done. 
If a bundle tag is removed from a bundle group, but not disabled, it 
will keep the old bundle transport, and the stuff remaining in the 
bundle will need to create a new transport.

> * Should the currently inactive m=audio section still contain its
> previous DTLS/ICE parameters/candidates?
     Probably not, but nothing should care.

> * Should a=group:BUNDLE still exist and contain MID1 (now inactive) and MID2?
     No. We should not be putting a dead mid in a group attribute.

> * Why the hell do we still place *shared* transport parameters within
> each media sender/receiver section?
     I think this might be a holdover from an earlier version of the 
bundle spec? Or maybe an interop workaround? I would have to do some 

Best regards,
Byron Campen
Received on Thursday, 24 August 2017 14:45:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC