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

[Oleg Moskalenko <[e-mail]>]

RFC 6062 is not very important but I cannot say that it is not relevant.
For the purpose of the new proposal we do not make a distinction between
RFC 5766 and RFC 6062 - this new proposal is about a new TURN transport
(Websockets). This transport is supposed to work universally in all
accepted TURN RFCs. So it would be unnatural and illogical to remove RFC
6062 from the draft.




On Fri, Sep 20, 2013 at 1:46 PM, Marc Petit-Huguenin <
[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 09/20/2013 01:33 PM, Sergio Garcia Murillo wrote:
> > El 20/09/2013 22:14, Marc Petit-Huguenin escribió:
> >> On 09/20/2013 12:57 PM, Oleg Moskalenko wrote:
> >>> On Fri, Sep 20, 2013 at 11:59 AM, Marc Petit-Huguenin
> >>> <[e-mail] <mailto:[e-mail]>> wrote:
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>> ... for RFC 6062 TURN TCP, of course. The key key words here are "TCP
> >>> peers" (as in RFC 6062, unlike "UDP peers" in RFC 5766). That may be
> >>> worth mentioning, indeed.
> >>>
> >>> This draft is mostly driven by the necessity of enhanced connectivity
> >>> of the clients (browsers) in WebRTC environment. So the question of
> >>> multiplicity of TCP / Websocket connections is not very important in
> >>> this context.
> >> If having TCP peers is not important, then remove RFC 6062 from this
> >> draft.
> >>
> >> Also, the draft does not explain the procedures related to SRV and NAPTR
> >> RRs:
> >>
> >> example.net. IN NAPTR 100 10 "" RELAY:turn.ws "" websocket.example.net.
> >>
> >> websocket.example.net. IN NAPTR 100 10 S RELAY:turn.ws ""
> >> _turn._ws.example.net.
> >>
> >> _turn._ws.example.net. IN SRV   0 0 80 a.example.net.
> >>
> >> a.example.net. IN A     192.0.2.1
> >>
> >>
> >
> > Hi Marc
> >
> > It was my error to keep the websocket support  for RFC 6062 in the draft
> > (against Oleg recommendations, by the way).  I agree with both of you
> that
> > it will be better to remove it from the draft, as it is causing most of
> > the discussions and will not provide anything to webrtc.
> >
> > Regarding the SRV and NAPTR RRs, for webrtc are not needed AFAIK, but we
> > could add it to the draft for completeness. Would you be willing to
> > collaborate in order to write that chapter?
>
> Sure, I'll send you a patch this week-end.
>
> >
> > Also, I would like to introduce in next draft version how HTTP
> > authentication/authorization (oAuth, cookies, etc) mechanisms could be
> used
> > in the TURN over websocekt connection on top of the standard TURN
> > authentication. That would remove the need for the current REST API fro
> > access to TURN services. If anyone would be willing to collaborate on
> this
> > (or any other subject) will be very welcome.
>
> I think that this is a very good idea to do that.  Not sure I'll have the
> time
> to help on the draft itself, but I certainly will try find the time to
> review it.
>
> - --
> 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)
>
> iQIcBAEBCAAGBQJSPLQ0AAoJECnERZXWan7ExzgQALZo/mdZqeGH3IdRzIflKAa9
> TnpU7SF/L3hOdyizgw7ftpzG1FDHfXrS12APmBOAt7F7ec5Q7p4W2tscXebTeSO4
> uQ/gYb50ekbGkVOVWHwzPP7k3lMNe3FnNnycYO9JJc/qpF9XeBKNnCaVPKbjW74K
> dIX/i+YeCqjoY0E2YQNeCzq2uX18Ygeals6/C+XOyxO+31GQPWLcIXr3ME8LZnAS
> QwUmL3+6/17kDdfK0xhtXl4oB44rpDhUNAodaxr6FUY0SOvp5GqsKKxOESSA3ltn
> K6ZpWuRBVBuaPdaQDrNT0xbNHjiA6WKnyjKfd0/8F0xZe13Sd3WTR2r6S9+QWS44
> TM3y4er4P7ISc11p5HHMwN3xf7kxCwwRbU3lK7Rq0M5Nlw69QXA/D2HY1txioumW
> fBbtAVwhx9M88bj4/sqViV0LIDPo/h/OVrkYncD7aJgISSKApuZMAjYegC/iYufz
> C4M5dZRub6PHoljTSFAs72bGC+yyvStsJxnrYN8pPF33MHRfbNdBdLZOpJq0ynU/
> ku0arxu6LwNBedno/B77WvUPG/x2ilKDcfDgxHSwkm3e/sWggZgkR1E7R/cXyFNK
> cO172tJlQPGF68QRjj1y7ulQb60cAscn51LRo5iTH6Xd8LcGxun+jWa09opuBtNo
> eRxWcQ3hI897vUZUzWMO
> =KM9Z
> -----END PGP SIGNATURE-----
>