W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] PeerConnection constructor: Init string format

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 08 Apr 2011 10:58:51 +0200
Message-ID: <4D9ECE4B.2060407@alvestrand.no>
BTW, I haven't been on this list that long... if anyone has advice on 
whether such discussions are better as buganizer threads or as whatwg 
mailing list threads, please give it!


On 04/08/11 10:41, Harald Alvestrand wrote:
> Adding this to the public archive:
> The current (April 8) version of section 9.4 says that the config 
> string for a PeerConnection object is this:
> ---------------------------
> The allowed formats for this string are:
> "TYPE"
> Indicates a specific IP address and port for the server.
> "TYPE relay.example.net:3478"
> Indicates a specific host and port for the server; the user agent will 
> look up the IP address in DNS.
> "TYPE example.net"
> Indicates a specific domain for the server; the user agent will look 
> up the IP address and port in DNS.
> The "TYPE" is one of:
> Indicates a STUN server
> Indicates a STUN server that is to be contacted using a TLS session.
> Indicates a TURN server
> Indicates a TURN server that is to be contacted using a TLS session.
> -------------------------------
> I believe this is insufficient, for a number of reasons:
> - For future extensibility, new forms of init data needs to be passed 
> without invalidating old implementations. This indicates that a 
> serialized JSON object with a few keys of defined meaning is a better 
> basic structure than a format string with no format identifier.
> - For use with STUN and TURN, we need to support the case where we 
> need a STUN server and a TURN server, and they're different.
> - The method of DNS lookup is not specified. In particular, it is not 
> specified whether SRV records are looked up or not.
> - We have no evaluation that shows that we'll never need the 
> unencrypted TCP version of STUN or TURN, or that we need to support 
> the encrypted STUN version. We should either support all formats that 
> the spec can generate, or we should get a reasonable survey of 
> implementors on what they think is needed.
> My alternate proposal:
> --------------------------------------------------------------
> The initialization string looks like this:
> {
>  ?stun_service?: { ?host?: ?stun.example.com?,
>                    ?service?: ?stun?,
>                    ?protocol?: ?udp?
>                  },
>  ?turn_service?: { ?host?: ?turn.example.com? }
> }
> The STUN server may either be an IP address:port literal, or be a 
> domain name. If it is a domain name, the procedure in section 9 of RFC 
> 5389 (SRV record lookup, with fallback to port 3478 (STUN) or 5349 
> (STUN over TLS)) is used to establish the IP address and port to use 
> for STUN and TURN.
> If ?service? and ?protocol? are omitted, they are assumed to be ?stun? 
> and ?udp? for stun_service, and ?turn? and ?udp? for turn_service.
> For TURN, the procedure is defined in RFC 5766 section 6.1. The 
> procedure of RFC 5928 (using S-NAPTR applications) is not used.
> ------------------------------------------------------------------------------------ 
Received on Friday, 8 April 2011 01:58:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:05 UTC