Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

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

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

On 05/20/2013 02:15 AM, Lorenzo Miniero wrote:
> Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo García <[e-mail]>
> ha scritto:
> 
>> I agree that TURN over websockets doesn't solve much more scenarios than
>> TURN/TLS.   If trying to fix HTTP Proxy traversal why not doing it over
>> HTTP that aside of philosophical discussions would be the solution with
>> better success rate?  Otherwise we will have to continue answering for
>> another 10 years "why is this app not working if skype does".
>> 
>> Something like this draft sent some months ago but perhaps for TURN 
>> instead of direct connections: 
>> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt
>> 
> 
> 
> When I submitted that draft this summer, I had that exact purpose in mind,
> that is taking care of corner edge cases like restrictive proxies and the
> like. Of course it was not meant to be a solution, just a way to foster
> discussion in that direction. In that discussion I also mentioned some work
> we did about this in the past, which in part apparently ended up in
> draft-hutton-rtcweb-nat-firewall-considerations:
> 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html
> 
> At the time most people in the ML thought it was either too useless, too
> complex or even harmful, considering it could be considered as a "sneaky"
> way to circumvent rules added by a network administrator, and so
> unacceptable. Anyway, as I said back then, a solution like this doesn't
> have to be sneaky, and it could very well be conceived in order to be
> admin-friendly rather than have a parrot and a wooden leg.

About circumventing rules added by a network administrator, I do think that
using TURN over Websocket or HTTP is doing in fact the opposite:  It is the
only way to obey the wish of the network administrator, as long as you
classify Webrtc is a *web* technology and not as a VoIP technology.

Think about it this way:  An administrator restricting UDP but authorizing
HTTP is basically saying: All web applications are fine, and Webrtc being a
Web application, it should just work fine, and should not be a collateral
damage of restricting UDP.  So TURN over Websocket/HTTP should be a mandatory
part of Webrtc.

Now the administrator should also have access to tools to restrict some
classes of web applications, and Webrtc should be one of these classes.  But
that should not be done as a side-effect of closing the UDP ports.

- -- 
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.12 (GNU/Linux)

iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9
dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr
oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2
9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a
zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv
WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH
0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n
78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8
tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe
Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw
xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53
HJsMG1MkVKRwRBgLsM9S
=HTew
-----END PGP SIGNATURE-----