Re: [pntaw] New version of TURN over websockets draft

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/2013 11:19 AM, Oleg Moskalenko wrote:
> Thank you Marc for your comments and suggestions.
> 
> RFC 6062 is a relatively seldom used specs, this new draft is directed
> mostly toward extension of RFC 5766 for WebRTC users. They will be using
> TURN in RFC 5766 manner, with a single Websocket connection per Allocation.
> RFC 6062 is a rather exotic use case and it is not used in WebRTC. So I'd
> not complicate this draft with a new subprotocol.

Yes, after sending my email, I realized that it was not necessary.

> 
> In practice, even in the case of a few RFC 6062 users, in most cases a
> TURN allocation is created with a single or a few connections, so there
> will be no significant flood of TCP connections if we will keep a new
> Websocket connection for each new peer.
> 
> I'd suggest to keep it as simple as possible and as close to RFC 5766 and
> RFC 6062 as possible for most practical purposes. This draft originated
> mostly out of WebRTC requirements and as I said before the WebRTC
> allocations will be using a single Websocket connection.
> 
> If there will be a significant demand for RFC 6062-style communications
> with Websockets, then we can consider an extension.
> 
> So, I'd suggest to keep a new Websocket connection for every new peer, for
> RFC 6062 - style communications.

OK so I suggest to say in the draft that a new Websocket connection will be
created for each TCP peer, because that have an impact on implementation design.

> 
> Regards, Oleg
> 
> 
> 
> 
> 
> On Fri, Sep 20, 2013 at 10:54 AM, Marc Petit-Huguenin
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
> I read the draft and I have some questions:
> 
> After TCP allocation over TURN Websocket, what is the Websocket equivalent
> of initiating a new TCP connection (RFC 6062) after sending a
> ConnectionBind or receiving a ConnectionAttempt?  Is a new Websocket
> connection opened and if it is the case, shouldn't it require a different
> subprotocol?  Perhaps a better alternative would be to use multiplexing 
> (draft-ietf-hybi-websocket-multiplexing) to not have to create multiple 
> Websocket connections to one TURN server?
> 
> See these links for a alternate way of multiplexing data exchanged with 
> multiple TCP peers over one connection:
> 
> http://www.ietf.org/proceedings/74/slides/behave-17.pdf 
> http://tools.ietf.org/html/draft-petithuguenin-turn-tcp-variant-01
> 
> On 09/13/2013 12:41 AM, Sergio Garcia Murillo wrote:
>> Hi all
> 
>> We have been working on a new version of the TURN over Websocket draft 
>> originally proposed by Xin, which is now available at:
> 
>> http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt
> 
>> We believe that it is very well aligned with the spirit of 
>> draft-hutton-rtcweb-nat-firewall-considerations and should be considered
>> to be endorsed by WebRTC.
> 
>> Also, in order to address the concerns about the impact on TURN servers
>> we will be working in providing a working prototype over the following
>> weeks by adding a preliminary support of TURN over websockets into the 
>> rfc5766-turn-server.
> 
>> Any kind of feedback would be very welcome.
> 
> 
> 

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJSPJsBAAoJECnERZXWan7Ea18P/0ZPrHem1l6IEO2HZ2xAo1sY
d4/S7RXLJBoqnPILtkKHZZHCUDZ6rjz4tqWY0+jXx1oNpBSoL5Pt9D3r1ZRBlBnQ
FdO8XVm54ICnBEYFsm1izeXv2bvmnEdWgKgEzcsIWibhJkhad7kppccNrCtoOayE
+/mlVVEwaw62Jn5uHu1lIeZRUkrTQ1CeMKnNO6YVKrU0iVAKqp4w5zA4l+CIbTg4
CjfZzwxRlE9plrRI1R5y+Fqzg+u0L1+A8XtLLA30ic+je1BsHsw58cCqFopQXT05
0icMundpmSsxoONIyHMECHirwrG56PG62tjhj75XRXbR4kV5z3hL7mHDUUSgFnDg
f5CCkRhp7KshdME75jAGqFev21hpblYLK/6sAXL59F50c908Nz+u96o00ODtR7g9
3++xqY/GRjQmVO638v5bUTsm0Iw6qajKGbNTiu/dEFGUloNpGUgMInEJMifQW6vs
+wMp3jrJAZFXiCy3K/6kMdl8lirSn3aUu0K023A0KYHr4c78z06rurj3K/JHaBNP
/vFsQZ7LGgraiOs+lj/t4zB2+coRue9J6KhujRrsBbH5G6YLCtBZIC6VuED7PqEo
9mtJmWuB812MZ7HOwVNaJulnV/+srPSvpJOc/ayQ2TB/klsiKzRZDcp1oyXjwtO2
MnOsj48NoHab/MqZjZob
=Jz+U
-----END PGP SIGNATURE-----