Re: RTCIceCandidate transport field is ambiguous

On 02/26/2014 12:20 AM, Byron Campen wrote:
> (referring to the text on http://www.w3.org/2011/04/webrtc/wiki/Stats)
>
>    Is this field intended to refer to the transport presented to the
> other end, or the transport we have open locally? These two will be
> different if we're using TURN TCP, for example (it will be TCP from
> the local end to the TURN server, but the remote end will send to the
> TURN server over UDP). If it is the transport presented to the other
> end, the stats API still can't indicate which flavor of relayed
> candidate (tcp or udp) we're using.

The intention was to mirror the "transport" field of the a=candidate
attribute.

I'm not sure how to answer your question given the grammar of that:
https://tools.ietf.org/html/rfc5245#section-15.1

I *think* it is intended to be the TURN-server-to-other-end protocol,
not the client-to-TURN-server protocol, but ICE experts may be more sure
than I am.

TURN can be distinguished from non-TURN by having the attribue "relay"
in the candidateType field, The transport protocol used to the TURN
server might be inferrable from the URL of the currently-selected TURN
server for that transport; I don't think we have that in the stats yet,
though.

>
> Best regards,
> Byron Campen
>


-- 
Surveillance is pervasive. Go Dark.