Re: [rtcweb] rtcweb-transports reference to TRAM discovery

["Pal Martinsen (palmarti)" <[e-mail]>]

> On 16 Dec 2014, at 20:16, Dan Wing (dwing) <[e-mail]> wrote:
> 
> 
> On Dec 16, 2014, at 9:40 AM, Justin Uberti <[e-mail]> wrote:
> 
>> Given that TURN servers can be used for STUN, is there a need to autodiscover STUN-only servers?
> 
> I am not aware of spec encouraging such implementations, and I don't know if everyone implementing WebRTC clients is going to be aware that TURN servers can provide useful information about the mapped IP address.  Perhaps it just needs a few sentences in an appropriate spec?
> 
The information is buried deep down in the TURN RFC 5766 Section 6.2. It states that the allocation success response contains a XOR-MAPPED-ADDRESS attribute. (No use of SHOULD or MUST).

It also have a nice note:
"NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response
 as a convenience to the client.  TURN itself does not make use of
 this value, but clients running ICE can often need this value and
 can thus avoid having to do an extra Binding transaction with some
 STUN server to learn it.”

Stating the above in some overview document will help people deploying WebRTC understand the requirements. The text in the TUNR RFC will probably only be read by TURN developers.

More importantly what is missing is text stating that deployed WebRTC turn servers should also send appropriate responses to Binding Requests; in other words act as a STUN server. Not sure about the appropriate spec, but it can go into TURNbis or some WebRTC overview document. 

.-.
Pål-Erik



> -d
> 
> 
>> 
>> On Mon, Dec 15, 2014 at 5:23 PM, 🔓Dan Wing <[e-mail]> wrote:
>> 
>> On Dec 15, 2014, at 7:56 AM, Hutton, Andrew <[e-mail]> wrote:
>> 
>>> +1 Also wondering why it is not appropriate?
>>>  
>>> F20 in the requirements draft states:
>>>  
>>> F20     The browser must support the use of STUN and TURN
>>>            servers that are supplied by entities other than
>>>            the web application (i.e. the network provider).
>>>  
>>> So I was thinking the need for specifying the discovery method would not be controversial.
>> 
>> Note that draft-ietf-tram-turn-server-discovery only discovers TURN servers.  If we need to discover STUN servers, too -- and I think we do -- we need that document to expand its scope or a second document.
>> 
>> I recently attended a talk where Matt Peterson presented Burning Man's network.  That network assigns RFC6598 addresses to each Burning Man "camp", and their ISP provides CGN'd addresses to Burning Man.  Each camp operates its own WiFi network, and we can all reasonably assume they are using typical consumer or SMB NAPT devices for those networks (e.g., D-Link, Linksys, Ubiquity, etc.).  To avoid tromboning camp-to-camp WebRTC traffic to their ISP's CGN, they would benefit from a STUN and a TURN server within the Burning Man network.  His presentation can be found at https://www.nanog.org/meetings/nanog62/agenda (PDF and video).
>> 
>> -d
>> 
>> 
>>>  
>>> Andy
>>>  
>>>  
>>> From: Simon Perreault [mailto:[e-mail]] 
>>> Sent: 15 December 2014 15:49
>>> To: Eric Rescorla
>>> Cc: Hutton, Andrew; [e-mail]
>>> Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
>>>  
>>>  
>>> On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <[e-mail]> wrote:
>>> I do not believe that this is an appropriate requirement
>>> 
>>> Care to say why?
>>>  
>>> Thanks,
>>> Simon
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb