Re: RTCIceCandidate transport field is ambiguous

On 2/25/14 7:36 PM, Harald Alvestrand wrote:
> 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.
    That's right.
> 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.
>
    That would only work for the currently selected local candidate, and 
apps are likely to want to know the details of every candidate that was 
gathered. So, we might want to add in another DOMString that covers the 
local transport. In fact, there may be some value in providing the full 
local IP address/port/transport tuple.

Best regards,
Byron Campen

Received on Wednesday, 26 February 2014 03:50:20 UTC