Re: RTCIceCandidate has no component

I missed that. I think think this should also be mentioned in the normative
part.

Whether the gatherer should set the component if it has been associated to
an ice transport is another question.

Maybe we can just ditch the non-rtcpmux usecase as well? :-)

On Wed, Jul 29, 2015 at 4:28 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> That is why we add the component in the non-RTP/RTCP mux examples and the
> “kind” in the non-A/V  mux examples.
>
>
>
> Turns out that wasn’t enough for the forking examples, so we’ll be adding
> the ufrag as well in the next Editor’s draft.
>
>
>
>
>
> *From:* Philipp Hancke [mailto:fippo@andyet.net]
> *Sent:* Tuesday, July 28, 2015 9:17 PM
> *To:* public-ortc@w3.org
> *Subject:* RTCIceCandidate has no component
>
>
>
> http://ortc.org/wp-content/uploads/2015/06/ortc.html#rtcicecandidate*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fortc.org%2fwp-content%2fuploads%2f2015%2f06%2fortc..html%23rtcicecandidate*&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c01fb7f8fb72648547f4608d29865957c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xAZE9So3y9CS7AQXBObzJYwv9gxm5pTd6RIm%2b%2bdo6QA%3d>
>
> One thing worth pointing out here is that the candidate has no component.
>
> That is fine conceptually, the component comes from the RTCIceTransport.
>
>
>
> However, naive approaches might forget to add the component in the
> onlocalcandidate event (or mangling getLocalCandididates) before signaling
> it to the peer.
>
>
>
> A note pointing that out would be helpful.
>

Received on Friday, 31 July 2015 04:05:04 UTC