- From: misi via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Dec 2016 12:41:36 +0000
- To: public-webrtc-logs@w3.org
Reasons to implement in PC Spec: - AFAIK "draft-ietf-tram-turn-server-discovery" is about server discovery only. And so there is no such API defined (Yet or under consideration) that discovers both credential and servers. - Furthermore there are multiple ways and big variety how a TURN Service Provider could (authenticate and interact with an App) and release Credential info, may it is not easy to define such API. Moving this duty to App level gives more flexibility and freedom, than to hard config few methods in browser frame for getting credentials. - WebApp is normally configuring the TURN service during PC creation on App level (or latter on..) - Actually in general AFAIU provisioning and getting credential happens on App level. - but TURN server discovery happen in ICE Agent, browser level So some communication between the two is probably desired. - We need to notify App about newly discovered servers. IMHO polling the read only ice server list is not the right approach. (Network change/roaming) - Think about a use-case when more then one TURN server discovered and may App could detect that they are from different TURN Provider, and may App has also some in-house TURN service. - Then how to choose the right one? May browser (the trust base) should control this preference, but maybe we leave the control of this to the web App. - even the browser has the control and define a preference the browser may still could leave up to the App to get credential for the preferred TURN server. - The App may have preference (trusted/untrusted service, having a contract with the TURN SP, etc.) to choose the appropriate TURN service. - (Corporate) IP Network Operators could provide more then one trusted closely located TURN services and leave the decision up the App or the browser. - The App may or not have the freedom to choose what TURN service to use from the list of closest discovered Servers but getting the credential for the browser preferred could be still handled by the App. (And may the App is trusted and has the freedom to pick one.) - Why in PC and not a new separated API? - The PC controls ICE agent, so it should control TURN discovery case to. - The discovery happens low level, inside ICE agent WebRTC engine, but App is the best position to implement a way to negotiate and get a credential for the server.. @alvestrand I hope it makes some sense to you.. -- GitHub Notification of comment by misi Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/941#issuecomment-264445890 using your GitHub account
Received on Friday, 2 December 2016 12:41:43 UTC