- 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