RE: RTCIceCandidate has no component

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.