Re: BUNDLE nightmare when first media section becomes inactive

On 8/24/17 1:26 PM, Iñaki Baz Castillo wrote:
> On Thu, Aug 24, 2017 at 7:29 PM, Byron Campen <docfaraday@gmail.com> wrote:
>
>>> 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.
> Let me insist on this, please.
>
> * When you say "stop() on a bundle-tag", do you mean
> transceiver.stop() and/or rtpsender.stop()? If rtpsender.stop() is
> included, would things change if there is an active receiving track on
> its same transceiver?

     I mean transceiver.stop(). rtpsender.stop() would not cause an 
m-section to be disabled, only transceiver.stop() (or things like 
negotiation failure) will cause that.

>
> * The scenario I mean is simple:
>
> 1) A single peerconnection. Bundle everything in the same transport.
>
> 2) I add my mic and webcam.
>
> 3) Later a new participant joins so I call setRemoteDescription etc.
> to get his remote tracks.
>
> 4) Later another participant joins, so seRemoteDescription again.
>
> 5) Later the first remote participant leaves, so seRemoteDescription again.
>
> 6) Later I want to shutdown my mic so I call audioRtpSender.stop().
> Not sure if I need to do SDP O/A again.
>
> 7) Later I add my mic track again via pc.addTrack(micTrack). I call
> createOffer, setLocalDescription, etc.
>
> 8) Later a new participant joins, so seRemoteDescription again.
>
> NOTE: The remote endpoint (a SFU) does not do exotic things in its
> SDP. It uses BUNDLE for all the tracks it sends to me.
>
>
> So my question is simple: Would the initially established and already
> connected ICE+DTLS transport be closed and restarted after any bullet
> above?

     Since the first two m-sections contain your audio/video send 
tracks, and at no point are you calling transceiver.stop(), I would not 
expect those to be disabled at any point in the above steps. The SFU 
_might_ disable them in an offer for some reason, but that would cause 
more problems than just forcing new ICE/DTLS. In the latest spec, the 
only time a browser will disable an m-section is after 
transceiver.stop() is called, or SDP negotiation completely fails on 
that m-section (eg; no codecs in common). What a gateway/middlebox does 
is anyone's guess.

> And now my two cents:
>
> If any of the bullets above involves closing and restarting the
> already connected ICE+DTLS stuff, then the spec is just crazy. No
> sense at all.
>
> In ORTC I create Transport and then assign it to
> RtpSenders/RtpReceivers, period. Different comm layers so different JS
> classes and separate signaling for each of them. I understand that SDP
> is "what it is" but, definitely, the 8 bullets above should NOT cause
> a transport restart.
>
>
> Extra note:
>
> I want to remind that there is also DataChannels and, if the transport
> is closed, the DataChannel is closed too (or restarted or whatever),
> so data messages can be lost. I understand that "ice restart" does
> exist and makes sense for certain use cases (WiFi -> 4G) but in the
> scenario above my DataChannel should NOT be closed/restarted.

     A note; if you want to have a bundle tag that is likely to stick 
around regardless of transceiver.stop() and SFUs deciding to disable 
m-sections due to track changes, DataChannel is not a bad choice.

Best regards,
Byron Campen

Received on Thursday, 24 August 2017 19:07:34 UTC