Subject: [Wish] STUN/TURN server configuration

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 21 Sep 2021 12:41:56 +0200

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 21 Sep 2021 13:30:18 +0200

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

> 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.
> 
>    1a- Using a well known url based on the domain of the whip
> endpoint url, that is if the url of the endpoint is
>    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:
> 
> 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
>    2a - return the url for gathering the http config on a Link header
> in the 202 response to the HTTP PUT request
>    2c-  return each turn server url + params each one on a different
> link header like :
> 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

---

From: Adam Roach <[email-masked]>
Date: Thu, 23 Sep 2021 13:58:41 -0500

Thanks, Sergio, for the extensive analysis.

I'm a little hesitant to embrace 1a, mostly because we aren't operating 
in the kind of "limited information bootstrap" environment that 
".well-known" was designed for. We have a complete URL configured, and 
there are straightforward ways to use it to achieve our goals. It's not 
a showstopper for me, but it's just a slight mismatch of mechanism.

I agree with you about the elegance of 2c, but am very sympathetic to 
the point that some (many? most?) WebRTC libraries would make this 
tricky to actually make use of, at least as they exist today. (In a 
better future world, where implementations match the spec, I think 2c 
would be the obvious right answer).

So what I'd like to propose is a hybrid model that allows for clients to 
do 2c if their WebRTC implementation reasonably allows it, but which 
otherwise has the properties of 1 (really, 1b). This would look like:

  * WHIP servers return the set of "Link" header fields like you
    describe in 2c below to every authenticated POST and every
    authenticated OPTIONS request sent to the WHIP endpoint URL.
  * WHIP clients that support reconfiguration of TURN information after
    generating an offer can simply perform a POST with the offer, get
    the TURN servers in the response, and add them to the PeerConnection.
  * WHIP clients that don't support such reconfiguration can instead
    sent an OPTIONS (with an auth token), get the TURN servers in *that*
    response, and then create their PeerConnection offer for inclusion
    in a POST.

I think this is basically the same level of complexity to implement on 
the server as the other options below, and it gives clients both a 
practical solution that can be used today, as well as a more elegant 
long-term solution that they can employ once WebRTC libraries catch up 
to the spec.

/a

On 9/21/21 05:41, Sergio Garcia Murillo wrote:
>     https://whip.example.org/enpoint/ the url would be something like
>        1c- Using a GET request to the whip resource to retrieve
>     directly the turn server config
>
>
> and according to JSEP 
> (https://datatracker.ietf.org/doc/html/rfc8829#section-4.1.18) it 
>        2a - return the url for gathering the http config on a Link
>     header in the 202 response to the HTTP PUT request
>        2c-  return each turn server url + params each one on a
>     different link header like :
>               Link: turn:turn.example.net <http://turn.example.net>;
>     rel="urn:ietf:params:whip:ice-server"; username="user";
>     credential: "myPassword"; credential-type: "password";
>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 28 Sep 2021 18:57:30 +0200

I like the idea, I will include it in an updated version of the draft.
Probably also do a CL to libwebrtc to fix the behaviour when updating the
ice server configuration without triggering an ice restart.. :)

Best regards
Sergio

El jue, 23 sept 2021 a las 20:58, Adam Roach (<[email-masked]>) escribió:

> I'm a little hesitant to embrace 1a, mostly because we aren't operating in
> the kind of "limited information bootstrap" environment that ".well-known"
> was designed for. We have a complete URL configured, and there are
> straightforward ways to use it to achieve our goals. It's not a showstopper
> for me, but it's just a slight mismatch of mechanism.
>
> I agree with you about the elegance of 2c, but am very sympathetic to the
> point that some (many? most?) WebRTC libraries would make this tricky to
> actually make use of, at least as they exist today. (In a better future
> world, where implementations match the spec, I think 2c would be the
> obvious right answer).
>
>    - WHIP servers return the set of "Link" header fields like you
>    describe in 2c below to every authenticated POST and every authenticated
>    OPTIONS request sent to the WHIP endpoint URL.
>    - WHIP clients that support reconfiguration of TURN information after
>    generating an offer can simply perform a POST with the offer, get the TURN
>    servers in the response, and add them to the PeerConnection.
>    - WHIP clients that don't support such reconfiguration can instead
>    response, and then create their PeerConnection offer for inclusion in a
>    POST.
>
> I think this is basically the same level of complexity to implement on the
> server as the other options below, and it gives clients both a practical
> solution that can be used today, as well as a more elegant long-term
> solution that they can employ once WebRTC libraries catch up to the spec.
>
> /a
>
> 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.
>
>    1a- Using a well known url based on the domain of the whip endpoint
> url, that is if the url of the endpoint is
> shouldn't trigger a ice restart as the ice gathering has not been started.
> so it is possible to do the following steps:
>