[Wish] Issue: WISH and TURN servers

[Adam Roach <[e-mail]>]

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