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

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

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