Re: BUNDLE nightmare when first media section becomes inactive

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?



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



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



>> * Should the currently inactive m=audio section still contain its
>> previous DTLS/ICE parameters/candidates?
>
>     Probably not, but nothing should care.


>> * Should a=group:BUNDLE still exist and contain MID1 (now inactive) and
>> MID2?
>
>     No. We should not be putting a dead mid in a group attribute.


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



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Thursday, 24 August 2017 16:08:21 UTC