Re: [Wish] Issue: WISH and TURN servers

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 <sergio.garcia.murillo@gmail.com> wrote:
> 
> 
> 
> 
> El sáb., 31 jul. 2021 1:11, Adam Roach <adam@nostrum.com>  
>> 
>> 
>> 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:
> 
> 
> "this" part of the message seems to be missing.
> 
>> 
>> 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.
> 
> 
> 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 
> 
> 
> 
> <Screenshot_20210731-101756_Chrome.jpg>
> -- 
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish