BUNDLE nightmare when first media section becomes inactive

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.

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

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?

* Should the currently inactive m=audio section still contain its
previous DTLS/ICE parameters/candidates?

* Should a=group:BUNDLE still exist and contain MID1 (now inactive) and MID2?

* Why the hell do we still place *shared* transport parameters within
each media sender/receiver section?

* Should we drop SDP from WebRTC? (rhetorical question).


Thanks a lot.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Thursday, 24 August 2017 11:33:03 UTC