Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

[Bernard Aboba <[e-mail]>]

Sergio said: 

      

      "Why are you leaving out of scope the case when the WebRTC service
      is not deployed by the corporate organization and/or the HTTP
      proxy has DPI validation? "
 
[BA ]  My reading of the document is that it is attempting to respect the restrictions set by the firewall administrator.   If UDP and TCP to ports other than 80/443 is denied, and in addition DPI is deployed, then you often will only have a subset of HTTP functionality available to speak to port 80 and maybe a subset of TLS which you can speak to port 443. 
 
This can significantly restrict the choices available.  In my experience, customers denying UDP in/out and only allowing TCP destined to selected ports (e.g. 80/443) as well as deploying DPI validation typically will not allow HTTP CONNECT (or even WebSockets).  
 
We are sometimes successful in making TURN allocation requests over TCP to port 80 or over TLS to port 443 in these scenarios, but TURN over TCP/TLS requests to other ports can fail.  Similarly, one should not expect TURN over WebSockets to work in these kind of installations; the DPI box probably hasn't been updated to handle WebSockets, or if it was, is configured to prevent WebSocket use.