Re: [Wish] STUN/TURN server configuration

[Lorenzo Miniero <[e-mail]>]

On Tue, 21 Sep 2021 12:41:56 +0200
Sergio Garcia Murillo <[e-mail]> wrote:

> Hi all,
> 
> One of the topics not covered yet on the draft is what to do with the
> stun/turn server configuration for the whip client.
> 
> Ideally, we don't want to have to configure a new set of url
> credentials in order to do so, and we definitely want to avoid having
> to configure them manually on the client.
> 
> The options that we have available are:
> 
> 1- Retrieving it before the SDP offer is generated and the HTTP PUT
> is sent:
> 
>    1a- Using a well known url based on the domain of the whip
> endpoint url, that is if the url of the endpoint is
> https://whip.example.org/enpoint/ the url
> would be something like
> https://whip.example.org/.well-known/ice-server-config as per rfc5785
>    1b- Using a prefetch request to the resource url (either an
> OPTIONS or GET) to retrieve the url of the turn server configuration
>    1c- Using a GET request to the whip resource to retrieve directly
> the turn server config
> 
> 
> 2-Retrieving the info after the SDP offer is generated and  HTTP PUT
> is sent. This is in theory supported  by the w3c spec (by updating
> the pc configuration via
> https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-setconfiguration)
> and according to JSEP (
> https://datatracker.ietf.org/doc/html/rfc8829#section-4.1.18) it
> shouldn't trigger a ice restart as the ice gathering has not been
> started. so it is possible to do the following steps:
> 
>  create pc without ice server config
>  create offer
>  send HTTP PUT with sdp offer
>  get response with sdp answer
>  retrieve turn server config
>  update pc config
>  set local description
>  set remote description
> 
> 
> However, I am not sure if the implementation of the setconfiguration
> is available on all browsers and other webrtc implementations. FWIW,
> chrome actually requires an ice restart if you update the turn server
> configuration regardless of the ice gathering phase.
> If we go that route we could either
> 
>    2a - return the url for gathering the http config on a Link header
> in the 202 response to the HTTP PUT request
>    2b - return directly the configuration in a mixed-type body
>    2c-  return each turn server url + params each one on a different
> link header like :
>           Link: turn:turn.example.net;
> rel="urn:ietf:params:whip:ice-server"; username="user"; credential:
> "myPassword"; credential-type: "password";
> 
> 
> I am personally in favor of option 1a in order to reduce roundtrip
> times, although I like the elegance of option 2c (even if it could
> cause problems to implement)
> 
> What are your views?
> 
> Best regards
> Sergio


I prefer 1a as well, as ideally we'll want to have STUN and TURN
addresses available before we start. I guess that, for the most
flexibility, we may want to allow different STUN/TURN servers for
different available endpoints, rather than a single well known endpoint
valid for all of them.

Lorenzo 

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero