Re: BUNDLE nightmare when first media section becomes inactive

On Thu, Aug 24, 2017 at 6:55 PM, Byron Campen <docfaraday@gmail.com> wrote:
>> Why a new transport? The same transport was already used by audio and
>> video. We've just removed audio, why should we alter the alter the
>> transport at all?
>
>
>     Because by doing so you open a can of worms. If a transport doesn't
> necessarily follow its m-section, what happens when:
>
> * The previous bundle tag is removed from the bundle group, but is still
> active, as a new bundle tag on some other group?

Such a "remove a bundle tag from its previous bundle group" just
exists in the BUNDLE draft. Yes, we can mangle a text (so a SDP) in
any way, but that does not mean that any change makes sense. In fact,
there is no API in WebRTC to remove a m= section from its BUNDLE
group.

> * The previous bundle tag is removed from the bundle group, but is still
> active, as a standalone m-section?
> * The previous bundle tag is removed from the bundle group, but is still
> active, as slave m-section on another?
> * m-sections from a collection of bundles are randomly assigned to new
> bundles?
> etc.

Idem. Those are not even reasonable cases to consider. In fact, the
`transport` attribute in RTCRtpSender and RTCRtpReceiver in WebRTC 1.0
are read-only.

Said that, I understand your rationale below (it may happen due to a
remote exotic SDP re-offer that changes things).


>> Opps, are you suggesting that every time a new "remote peer" joins a
>> conference (so we get new m= sections in the remote SDP) the ICE+DTLS
>> should be restarted? Don't take me wrong, but that's insane. Just
>> imagine a Hangouts session with all the remote videos black for a
>> while just because a peer joins or leaves the conference...
>
>
>     If those new m-sections are added to a pre-existing bundle, they will
> use the pre-existing bundle transport, unless they are not marked
> bundle-only, and the answerer refuses to put them in the bundle for some
> reason (ie; they may have their own transports until O/A concludes, just in
> case).

Not sure if I understand. How does that fix my simple scenario above? I mean:

- pcA uses BUNDLE for audio and video.

- Also pcB.

- pcA removes its audio track.

- Now what? A new transport?


>> That's a too much "advanced" use case IMHO. I don't think there is
>> even a way (via WebRTC API) to "remove a m=section from a bundle
>> group".
>
>
>     It is something that can happen with SDP negotiation. Unless we
> explicitly make rules restricting what can and cannot be done with bundle by
> webrtc gateways and such, we need to be mindful of scenarios like this. How
> to handle stuff like this is a great big gaping hole in the specs, sadly.

Oh, right...



>> AFAIR, the BUNDLE spec allows something like a=bundle-only which means
>> that just the first m= section contains transport params. It's not
>> implemented anywhere, of course, but even when implemented, the same
>> problem as stated in my description may happen. This is, just imagine
>> that the first m= becomes inactive/disabled.
>
>
>     If that is done by the offerer in a renegotiation, it would make sense
> to create a new transport for the bundle. However, if the answerer rejects
> the bundle tag, stuff just breaks. The guidance over at the IETF group is
> "Don't do that." Hooray.


If you don't mind, I still would like to know how Google Hangouts
(assuming it moves to Unified Plan) would behave when a new
participant joins or leaves the conference. If you say that "ICE+DTLS
should be renegotiated again for all the remaining senders/receivers,
then I just cannot agree at all".




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

Received on Thursday, 24 August 2017 17:08:10 UTC