[whatwg] PeerConnection constructor: Init string format

Harald Alvestrand harald at alvestrand.no
Fri Apr 8 01:58:51 PDT 2011

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.
> ------------------------------------------------------------------------------------ 

More information about the whatwg mailing list