W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2017

[webrtc-pc] RTCIceCandidate: how is extensibility handled?

From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
Date: Sat, 13 May 2017 08:51:54 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-228459525-1494665512-sysbot+gh@w3.org>
fippo has just created a new issue for https://github.com/w3c/webrtc-pc:

== RTCIceCandidate: how is extensibility handled? ==
http://w3c.github.io/webrtc-pc/#rtcicecandidate-interface
defines a number of attributes of the RTCIceCandidate that should be pre-parsed from the candidate string. While implementing a shim for this I noticed that my parser was emitting two additional attributes, generation and [network-cost](https://tools.ietf.org/html/draft-thatcher-ice-network-cost-01)
```
Candidate:3805835391 1 udp 2113937151 192.168.0.107 57917 typ host generation 0 ufrag 7POS network-cost 50```

https://tools.ietf.org/html/rfc5245#section-15.1 allows extensibility (extension-att-name and extension-att-value) so this section should at the very least mention what happens with those extra attributes.

This might be somewhat tricky since e.g. when Firefox does not implement network-cost and therefore parsing a candidate from Chrome in the constructor will at best return a string network cost "50" while a browser that understands this will return an integer 50.
This might imply that this parsing is easier to be done in a javascript library which will give a consistent answer across browsers. So far nobody has implemented this even though I have a [PR for adapter.js to shim it](https://github.com/webrtc/adapter/pull/527).

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1211 using your GitHub account
Received on Saturday, 13 May 2017 08:52:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:50 UTC