rtcicecandidate: add relayProtocol #2763
Conversation
|
This is mostly a consistency issue between the candidate object and the candidate stats, see here for details. I did consider (and actually implemented) .url as well but that is already defined to be part of the icecandidate event. |
based on the hardcoded mapping of local type preference. Polyfill for w3c/webrtc-pc#2763
|
Editors meeting: Seems uncontroversial. |
which is already defined in webrtc-stats https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatestats-relayprotocol for local candidates
webrtc.html
Outdated
| @@ -5976,6 +5976,7 @@ <h4> | |||
| readonly attribute DOMString? relatedAddress; | |||
| readonly attribute unsigned short? relatedPort; | |||
| readonly attribute DOMString? usernameFragment; | |||
| readonly attribute DOMString? relayProtocol; | |||
There was a problem hiding this comment.
Since this is a readonly attribute with predefined values it should probably be an enum.
There was a problem hiding this comment.
How would you define the possible values? https://www.rfc-editor.org/rfc/rfc5928#section-3 is the closest one I could find (Table 1) but that is hardly normative
There was a problem hiding this comment.
Right now the PR defines the possible values in prose: "Valid values are "udp", "tcp", or "tls". " which seems equivalent to:
enum RTCIceTransportPolicy {
"udp",
"tcp",
"tls",
};
interface RTCIceCandidate {
...
readonly attribute RTCIceTransportPolicy? relayProtocol;
};If those are the only valid values then we generally prefer expressing things in WebIDL when possible.
If those are not the only values then we should rephrase.
There was a problem hiding this comment.
If those are the only valid values then we generally prefer expressing things in WebIDL when possible.
Or at least that's been my impression. These are only ever used as output, not input so I guess it doesn't matter a whole lot (do we get any free idlharness wpt tests)? I see the stats spec is just using DOMString, and I couldn't find any design principles on this. The WebIDL spec showed no examples of a readonly attribute using enum... YMMV
There was a problem hiding this comment.
Yes but for the other enums we have normative references from which we can draw the values (e.g. https://w3c.github.io/webrtc-pc/#rtciceprotocol-enum but note that while two of the values are the same the semantics is very different)
For stats this is actually a TODO hidden here: https://github.com/w3c/webrtc-stats/blob/main/webrtc-stats.html#L2964
There was a problem hiding this comment.
RTCIceTcpCandidateType is sort of similar here.
Having WebIDL enum is a small UA developer improvement as it can automate some binding generated code.
There was a problem hiding this comment.
RTCIceServerTransportProtocol won against RTCIceTurnRelayProtocol and variants thereof.
|
Reference should be to RFC 8656 Section 3.1 (which also defines DTLS transport); RFC 5766 is obsolete. |
* editorial: clarify relayProtocol stats following w3c/webrtc-pc#2763 * use RTCIceServerTransportProtocol
which is already defined in webrtc-stats
https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatestats-relayprotocol
for local candidates
Preview | Diff