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

[Bernard Aboba <[e-mail]>]

> > [BA] Not sure whether "should be successful" is trying to imply that
> > statistically this is expected to succeed in the majority of RTP over
> > TCP cases.  That is not my experience - "simultaneous open" isn't
> > supported widely enough for that to be the case.

[AndyH] - Agree and this was included for completeness my preference is for using TCP to the TURN server and possible we don't even need to use ICE-TCP.
[BA] As Harald has mentioned, support for ICE-TCP (RFC 6544) and TCP extensions to TURN (RFC 6062) is probably only needed for TCP peer-to-peer use.   However, many of the applications that could be implemented using P2P TCP (e.g. peer-to-peer chat, whiteboards, etc. ) can also be supported via the WebRTC data channel, and if done that way will be less likely to require a relay.  So while I can think of some things that might require TCP P2P (e.g. P2P websockets), it's hard to argue that these justify a MUST.   Overall, the recommendation in Section 5 requires more justification: 
   o  support ICE-TCP for TCP-based direct media connection to the
      RTCWEB peer.

> [AndyH] I am not sure sure I understand your comment or why this means that TURN/TCP might be needed could you expand on that?
[BA]  TURN over TCP/TLS with a UDP allocation (RFC 5766) can handle cases where the host cannot get UDP through the firewall, except perhaps in situations where the TURN allocations don't have UDP connectivity to each other (e.g. a firewall between them). 
However, if a WebRTC application hands out the same TURN server to both peers,  then you may end up with two TURN allocations on the same TURN server, so that a blockage is very unlikely. 

> > Section 2.3

> > [BA] At least in my experience, attempting to contact the TURN server
> > over the HTTP port tends to run afoul of DPI.  So while I don't object
> > to this as a requirement, I've not found it particularly useful.
> 
> [AndyH] - It could do and we don't want to try to get around this if DPI is deployed. However I believe that this provides a very significant increase to the chances of a successful webrtc connection. With regard to using the HTTP port then the port to be used is under the control of the webrtc application so any port could be used.
[BA]   Section 5 is entitled "Recommendations for RTCWEB-enabled browsers", but I think it needs to be a bit more specific about exactly what the browser needs to support.  For example:    o  connect to a TURN server via a HTTP proxy using the HTTP connect
      method,
[BA] How is the browser to know when it should do this? Is this to be configured in the API, or is it triggered automatically in certain conditions?   
   o  connect to a TURN server via the HTTP(s) ports 80/443 instead of
      the default STUN ports 3478/5349,
Through use of the turn/turns URIs, the browser can be pointed to a different port.  Is this sufficient?  Are there implications for the TURN server as well?  As noted in RFC 5766, there are several ways to run TURN on a port different from the default:  
   By default, TURN runs on the same ports as STUN: 3478 for TURN over
   UDP and TCP, and 5349 for TURN over TLS.  However, TURN has its own
   set of Service Record (SRV) names: "turn" for UDP and TCP, and
   "turns" for TLS.  Either the SRV procedures or the ALTERNATE-SERVER
   procedures, both described in Section 6, can be used to run TURN on a
   different port.



> > Section 4.3> [AndyH] Understood limited testing that we have done shows success with the HTTP Connect based mechanism but I would really like to hear from anybody with good stats.
[BA] In my experience, the kind of customers who block UDP and TCP but allow HTTP are less permissive and therefore they also often deploy DPI as well.  So I am wondering whether that kind of customer is likely to support HTTP Connect.