Re: BUNDLE nightmare when first media section becomes inactive

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

Best regards,
Byron Campen

Received on Thursday, 24 August 2017 14:45:28 UTC