W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2017

Re: BUNDLE nightmare when first media section becomes inactive

From: Byron Campen <docfaraday@gmail.com>
Date: Thu, 24 Aug 2017 14:07:09 -0500
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <ce7fda29-fa45-b796-ef31-7be08ecef4fc@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC