Re: BUNDLE nightmare when first media section becomes inactive

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

     If we're talking about RTCRtpTransceiver.stop(), then initially 
nothing happens to the transport. However, a subsequent O/A will need to 
create a new transport, unless we have explicit spec language that says 
different.


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

     Not just that, but these problems exist in the base spec; anything 
that uses bundle has to worry about this, especially if it uses trickle 
ICE (non-trickle implementations could potentially get away with more 
shenanigans, since the address in the c-line explicitly indicates what 
the offerer is doing wrt transports, and the answerer need only play 
along). Webrtc is not the only spec that trips over this stuff.

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

     As long as you don't call stop() on the bundle-tag, you should be 
fine. If you're using the bundle tag to send media, you won't be doing 
this if/when a participant leaves. However, if you're going to do 
something like put all of the receive streams in their own 
PeerConnection, then yes this could be problematic.

Best regards,
Byron Campen

Received on Thursday, 24 August 2017 17:29:46 UTC