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 15:46:21 -0500
To: Taylor Brandstetter <deadbeef@google.com>
Cc: IƱaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <b39fdb1f-30ea-1132-e711-fff7627b052a@gmail.com>
On 8/24/17 3:14 PM, Taylor Brandstetter wrote:
>
>     If you stopped the _transceiver_, then the offerer and answerer
>     would need to recognize that the original bundle transport was
>     gone, and to establish a new one, in the same manner as they would
>     with an initial offer/answer, or adding a new m-section that isn't
>     bundled.
>
>
> I don't think this is correct. From the perspective of the BUNDLE 
> spec, this is "Disabling A Media Description In A BUNDLE Group" 
> (section 8.5.4). There's a note that specifically addresses this scenario:
>
>      NOTE: If the removed "m=" line is associated with the previously
>        selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag
>        [Section 8.2.1].
>
>
> Note that this only says you need to select a new BUNDLE-tag, not a 
> new address.

     Right, the bundle spec does not tell us what to do here, which is a 
hole in that spec. When you have trickle ICE, it is currently impossible 
for the offerer to indicate which ICE transport it intends to reuse 
where, because the c-line is not necessarily stable. Therefore, we need 
one of two things:

1. Specific rules about what transports are reused when. Absent any such 
rules, "transport follows m-section" is the simplest assumption.

or

2. Some way for the offerer to unambiguously signal which transport it 
wants to use for each bundle/lone m-section, that does not rely on the 
c-line. Maybe some sort of tag for each transport.

Best regards,
Byron Campen
Received on Thursday, 24 August 2017 20:46:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:36 UTC