> > It cannot unless there is spec language that says it needs to be different > for each transport. It's not very clear, but there is: When an offerer associates a unique address with a bundled "m=" line > (excluding any bundle-only "m=" line), the offerer MUST associate SDP > 'candidate' attributes (and other applicable ICE-related media-level > SDP attributes), containing unique ICE properties (candidates etc), > with the "m=" line, according to the procedures in > [I-D.ietf-mmusic-ice-sip-sdp]. In other words, an initial offer that offers fallback to not being bundled MUST use unique ICE properties per m= section. Chrome doesn't do this either. But again, I consider that a bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=6351 On Fri, Aug 25, 2017 at 6:50 AM, Byron Campen <docfaraday@gmail.com> wrote: > On 8/24/17 5:58 PM, Taylor Brandstetter wrote: > > 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. > > > Yeah, the BUNDLE spec is written with the assumption that the transport > can be identified by an address, which is not true for ICE, where it's > identified by a ufrag instead. I tried to fix this and other problems here ( > https://github.com/cdh4u/draft-sdp-bundle/pull/19), but unfortunately I > got involved too late and my proposed changes didn't make it into the spec. > > 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. > > > I assumed the ufrag could be used as this "tag". > > > It cannot unless there is spec language that says it needs to be > different for each transport. There is no such language, to my knowledge. > There's also interop to worry about; Firefox does not use a different ufrag > for each transport, and I doubt many other implementations do either. Keep > in mind that interoperating with gateways and such is the likeliest time to > see bundle shenanigans... > > Best regards, > Byron Campen >Received on Friday, 25 August 2017 16:45:27 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:36 UTC