Re: RTCIceCandidate transport field is ambiguous

On 02/26/2014 04:49 AM, Byron Campen wrote:
> 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.

I'm not sure what the antedecent for "that" is in that sentence.
The candidateType field is a per-candidate field.

I'm not sure apps want to know the details of every candidate that was
gathered; under what situations would the app change its behaviour based
on that information?

It seems logical that current SIP implementations know how to associate
a candidate with the TURN server that is to be used for relaying of that
candidate - how do they do it?

--
Surveillance is pervasive. Go Dark.

Received on Friday, 28 February 2014 11:49:04 UTC