Re: [webrtc-pc] STUN/TURN Auto Discovery handling

Please consider that Your approach may works well only in case if TURN
 server is in-house and you don't need to get credential for 
authentication from an external AUTH server. 

So if TURN service is inside LAN and no Auth required then it could be
 handled like the RETURN server or a proxy severs.

But AFAIK you couldn't treat the same way, if WebRTC App works with an
 external global TURN service that needs Auth.

E.g. The browser discovers  the closest TURN server (from domain name 
through DNS lookup, or make an Anycast STUN request and receive 
closest server IP/HOST /in alternate-server/), 
furthermore in case OAuth may every TURN server requires different 
credential.

( In this case it does not exists a general TURN global domain level 
credential that is valid for every server, the TURN service use 
different credential for every server. 
Why? To harden the service and this way the credential is not only 
time limited but also only valid on the exact discovered TURN server. 
/or TURN server group in the closest region/)

Only the App knows where is the Auth server for the global external 
TURN service that App use, where it can request a credential for the 
exact recently discovered TURN server (Hostname/IP).

The App needs to get  a credential (exactly for the discovered 
IP/HOST) and on the usual way configure PC, so pass the discovered 
TURN server with the appropriate (requested) credential to PC.

I don't see how your approach could deal with such a case. 
I am not sure it is suitable to handle it at all.

@juberti  
**What do you think?**
How should we handle such a case?

**All in all**
- I still believe that we need an event to handle such case.
- And flag may also needed to indicate and control  ICE 
agent(STUN/TURN client) that STUN/TURN auto discovery is 
needed/appropriate or not for this PC instance.

-- 
GitHub Notification of comment by misi
Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/941#issuecomment-262908798 
using your GitHub account

Received on Friday, 25 November 2016 08:55:17 UTC