Re: BUNDLE nightmare when first media section becomes inactive

On 8/24/17 11:07 AM, Iñaki Baz Castillo wrote:
> On Thu, Aug 24, 2017 at 4:45 PM, Byron Campen <docfaraday@gmail.com> wrote:
>>      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.
> 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?
* 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.


>>> 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?
> It's the same. I see pc.oniceconnectionstatechage moving to "checking"
> and then "connected" again, but I own the ICE+DTLS transport on the
> remote side (a WebRTC server) and I do know that no new DTLS handshake
> has taken place.

     Ok, that is probably not what we should be doing.


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


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

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

Best regards,
Byron Campen

Received on Thursday, 24 August 2017 16:56:24 UTC