Re: RTCIceCandidate transport field is ambiguous

On 2/28/14 3:48 AM, Harald Alvestrand wrote:
> 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.
    The approach of inferring the local transport for a relayed 
candidate via the currently selected TURN server.

> 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?

    This would be useful for debugging at the very least. Keep in mind 
that the candidate pair stats have booleans for indicating how well 
they're working, which implies that they are not necessarily active, but 
only an opaque ID referring to the candidates; if only successful (ie; 
in an active pair) candidates are reported, there is a lot of missing data.

>
> 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?

    The ICE stack they're using tells them both the candidate address 
and the local address.

Best regards,
Byron Campen

Received on Friday, 28 February 2014 16:10:48 UTC