Expose protocol used to communicate with TURN server about webrtc-stats HOT 6 CLOSED

From https://tools.ietf.org/html/rfc5928#section-3 it seems that a TURN client-server link can indeed resolve to any protocol (if unspecified), so you can't tell from the URI scheme, which was my first thought.

I'm not clear on when in the process of resolving a candidate this field can be populated - can you help in describing that?

from webrtc-stats.

this would basically have to expose the local type preference (which is priority >> 24) and then turn that into the transport protocol using a browser-specific mapping.

But wasn't the URL the candidate was gathered from for exactly that purpose? I agree though that this is a more direct solution.

from webrtc-stats.

It turns out a turn url without a transport modifier can end up using any protocol depending on dns config and local capabilities so no, in general you cannot know from the url. Complex stuff!

from webrtc-stats.

pinging @jan-ivar -- iirc you have a mozlocaltransport already?

from webrtc-stats.

Yes we have mozLocalTransport. You can see it in a dump here.

I found this old comment on it.

from webrtc-stats.

@alvestrand

I'm not clear on when in the process of resolving a candidate this field can be populated - can you help in describing that?

Well, it needs to happen before the candidate is allocated ("gathered"), so there's never a situation where it could be unknown at the time of appearing in a stats report.

Of course, this field would only be present for local candidates, not remote candidates.

from webrtc-stats.