Subject: [Wish] Issue: WISH and TURN servers

From: Adam Roach <[email-masked]>
Date: Fri, 30 Jul 2021 18:10:47 -0500

During today's meeting, there were a couple of topics relating to TURN 
server provisioning that came up.

The first issue was which mechanism we should use for conveying TURN 
server addresses & credentials. One proposal was to re-use the mechanism 
described in draft-uberti-behave-turn-rest. Justin made it clear that, 
with the publication of RFC 7635, he was no longer interested in 
progressing that mechanism as an independent document; however, it was 
proposed that we could instead roll the mechanism into WHIP itself.

In practice, the mechanism described in that document is quite simple at 
its core: clients sent a GET to an HTTP server, and receive a JSON 
object containing TURN URIs, a username, a password, and an expiration 
time. It also talks about query parameters for this request, but my 
initial analysis is that they may be useful for general-purpose use, but 
aren't really applicable to WHIP's use.

Adding text to the base WHIP document that documents a simplified form 
of this mechanism would be a straightforward exercise, and I'd be happy 
to put together the necessary text.

The second issue was discovery (bootstrapping) of the aforementioned 
mechanism. Today's discussion had two proposals for how this might be 
performed:

 1. Add a ".well-known" URL to the WHIP server that can be used to
    retrieve credentials
 2. Define behavior for OPTIONS (or possibly HEAD?) on the WHIP endpoint
    such that the response contains a "Location" header field with a
    link that the client uses to retrieve the information.

Option 1 has the benefit of using one fewer round trips prior to 
starting a broadcast (GET to the ".well-known" endpoint, and then POST 
to the WHIP endpoint, versus OPTIONS to the WHIP endpoint, then GET to 
the TURN endpoint, then POST to the WHIP endpoint).

Option 2 is architecturally cleaner and keeps all of the WHIP behavior 
nicely contained.

It should be noted that clients that don't wish to use TURN won't have 
to perform the additional operations, and can still start a session in a 
single HTTP operation, so the extra RTT only applies to those clients 
that wish to use TURN.

There was also a short discussion of sending the TURN Location header 
field back in the response to the offer PUT. I missed the exact nature 
of the objection for doing so, although it seemed to be based on 
information that we needed to have available to create the offer. I'm 
trying to work out whether this is true: I /think/ all of the 
information relating to the TURN server can be sent in a trickle ICE 
candidate. So you'd have something that looks like this:

Unless I've overlooked something that makes this infeasible, I think I 
like this approach the best, since it allows ICE checks to start on 
non-relayed candidates with the same amount of latency as without this 
mechanism.

/a

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 31 Jul 2021 10:20:03 +0200

El sáb., 31 jul. 2021 1:11, Adam Roach <[email-masked]>

> candidate. So you'd have something that looks like this:

"this" part of the message seems to be missing.

> non-relayed candidates with the same amount of latency as without this

If we get the URL of the turn server config in the response of the sdp
offer, it means that we need to update the configuration of the PC to set
them, which would trigger an ice restart.

I think we should avoid that,  so the turn servers have to be retrievable
before the http post with the sdp o/a.

Best regards
Sergio

---

From: Tim Panton <[email-masked]>
Date: Sat, 31 Jul 2021 10:52:49 +0200

One thing I have done elsewhere, is to flip the relationship around, the client sends an essentially empty get request, and the server sends an offer -and- turn credentials. The client sends a post with the answer based on the offer+turn. 

I should say that I think we should probably not do this here, but I mention it for completeness.  

Tim

Sent from my iPad

> On 31 Jul 2021, at 10:20, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> 
> 
> 
> If we get the URL of the turn server config in the response of the sdp offer, it means that we need to update the configuration of the PC to set them, which would trigger an ice restart. 
> 
> I think we should avoid that,  so the turn servers have to be retrievable before the http post with the sdp o/a.
> 
> Best regards 
> Sergio 
> 
> 
> 
> -- 
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish