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

[Oleg Moskalenko <[e-mail]>]

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.

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.

Regards,
Oleg





On Fri, Sep 20, 2013 at 10:54 AM, Marc Petit-Huguenin <
[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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)
>
> iQIcBAEBCAAGBQJSPIvbAAoJECnERZXWan7E5ukP/jHhs1I4I3GIXoRfvPPNHsFZ
> CuGUwg/4cXKb0FPzeMkjNL8rv13DutWydt5nJcKrNcypMbnIj8uzRBFD/ZboEap0
> RxkX56QmNGhhhFMcnEIrSMfFbX83m9Y9IHFJIEUtginLygIJJkjwaS++PoFK2WGA
> wmVaXJwgrEJyeDPCiW4i9ukhZcQk4/pVCLMvyDY0g5L0BEEeYUJrufLWorUztDFD
> gtASRVMdO5EyyRM0Z23xuOyf5oBd7nqWFhoiA15BxLeodfss0g5Gx9sW6IDPWdXn
> vVguNbB4fKe/C0+bjN8FkXrziKaf9/wsWeuXMrDnh5lvjAtnP//n9DBEl1iFlHrf
> DIZRC0Wr0HOIsVAl2iczzaB73Ds53KYRzzuPlTlkocW0yhKd4eJEB4LC1UkBmrV0
> O8N88G2jpQCF2VR4D9Ut0kxhg35bARtYZwcZ45z4Vc6vDRUwBKeI7TQOjYwcA8e9
> ySea2gIhtB+A1dxTOX8Ynk5I39imiRUiU3MuNmdWK+FHPB6TLYbjBk57sVN5+ZKj
> Ts4UL1b+E15WA4aEAFitH4ptnXSF80mmRg9Bp5VHDUWYqnIloha52g+RBa0bgCrM
> ksIb86D1GJo8c4kVnStPZ/Q8lvomeM9IVtOFUpuV6QZJ9FwYvYaWaLinH9cQHcw9
> CrANHoFIUigxL4mtdOwc
> =zjII
> -----END PGP SIGNATURE-----
>