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

Re: BUNDLE nightmare when first media section becomes inactive

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Thu, 24 Aug 2017 20:26:35 +0200
Message-ID: <CALiegfnwf6KStNyYN-V5++7=9KodF3GOPG4yEsFeHAAd=OD9Bw@mail.gmail.com>
To: Byron Campen <docfaraday@gmail.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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?

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


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.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Thursday, 24 August 2017 18:27:18 UTC

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