HTTP Tunneled protocol for RTP

[Kirill Ratkin]

Hi,

There is technology to transfer RTP/RTSP over HTTP tunnel.

Just Links:

http://www.cardinalpeak.com/blog/the-many-ways-to-stream-video-using-rtp-and-rtsp/

http://www.rfc-editor.org/rfc/rfc2326.txt

http://pdn.pelco.com/content/rtp-video-streaming-over-http

http://www.opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf

Flash has same protocol called RTMPT.

 

It would be nice to do something like that in WebRTC.

What do you think?

Yes, yes. STUN/TURN, ICE exist to pass traffic over NAT. But I know many corporative networks where almost all ports closed, but RTMPT (just for example) works because it works over HTTP.

If WebRTC would allow to establish media streams with some media relay (like Turn Server) over HTTP tunnel it could make WebRTC applications available for many office workers. Just because such media relay looks like just HTTP server (nginx for example) from particular office network point of view.

[Oleg Moskalenko]

Kirill, there is a significant opposition to this kind of approach. You are asking to implement a solution that looks like one thing but behaves like other thing. The network administrators are often against this approach. Some IETF people are against that approach, too, for the same security reasons.

Another similar way to achieve the same outcome would be to add the WebSockets to the list of protocols supported by TURN. There is a draft specs document for that:

http://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-01

but I do not think that it will be easy to standardize - for exactly the same reason - many people are uncomfortable by the idea of a TURN server posing as a Web server. There are ways to address those concerns, but the initial reaction to the idea is often unfavorable.

Oleg

[bryand...@gmail.com]

Also, since a TURN/TLS server can be run over port 443, and could use an HTTP proxy if configured, there would be little reason to tunnel over WS or HTTP.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Oleg Moskalenko]

There are cases which can be handled by WebSockets but they are more difficult for 443/HTTP proxy combinations. For example, when an enterprise network uses a "transparent" hidden HTTP proxy.

[pablo]

TURN over websockets will allow us to use NGINX to proxy both RTP and HTTPS.
With raw TURN/TLS over 443 we need another layer to split HTTPS from RTP.

Why can't it just be added as an option?
Network administrators will be able to choose between raw TCP and wss.

[Lorenzo Miniero]

Pablo,

as Oleg explained a couple of posts ago, we tried to propose a simple solution for TURN-over-WSS, but we met with high resistance within the IETF. The reason was basically that this could be seen as an attempt to circumvent policies imposed by a network admin, effectively pin-holing the restrictions. While I agree that this maybe an issue, it's not something that cannot be solved by extending the proposal, especially considering that for instance we already negotiate a specific sub-protocol that could be used for the purpose. That said, for what I understood there are people there that wouldn't accept this approach no matter what, so I'm afraid it's a no-go, sorry. I also proposed a pure HTTP encapsulation a couple of years ago, that had pretty much the same luck :-)

I don't think we'll get anything else than TURN on 80/443 or HTTP CONNECT based solutions to let TURN pass through.

Lorenzo

[pablo platt]

So the IETF intention is that NGINX won't be able to proxy TURN?

That's just going to make the setup for small scale apps much harder.

For more options, visit https://groups.google.com/d/optout.

[Lorenzo Miniero]

Il giorno venerdì 14 marzo 2014 16:47:13 UTC+1, pablo ha scritto:

So the IETF intention is that NGINX won't be able to proxy TURN?

That's just going to make the setup for small scale apps much harder.

If NGINX supports HTTP CONNECT, it can proxy TURN that way, even though I think this means setting a proxy configuration in the browser accordingly (I haven't tried this).

Lorenzo

[pablo platt]

NGINX supports websockets so it expects a URL.

http://nginx.org/en/docs/http/websocket.html

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Can this somehow work for TURN?

[Justin Uberti]

I don't understand why TURN/TLS is a problem for NGINX. After decryption of TLS, you have the raw RTP bytes.

[pablo platt]

I don't think NGINX can proxy raw TCP out of the box.

After terminating TLS, NGINX expects HTTP.

Isn't the whole point of secure Websockets that they behave like HTTPS so most proxies will let them pass through?

Do you think that I can proxy TURN with NGINX right now?

[Justin Uberti]

If it is proxying HTTPS, it won't terminate TLS, but will just pass it through. You should be able to do the same for TURN/TLS.

[Patrick Marques]

Correct me if I'm wrong, but AFAIK nginx have to terminate the TLS and then "only proxy HTTP". Some time ago, to do something like that , I used this: https://github.com/yaoweibin/nginx_tcp_proxy_module that is listed on 3rd party modules (wiki.nginx.org/3rdPartyModules)

PM

[Justin Uberti]

I see. It's not clear to me though why NGINX is even needed in a deployment given that the user could connect directly to the TURN server on 443.

[pablo platt]

For small deployments and development, it's easier to have all the components on the same machine.

If WebRTC will support TURN over secure Websockets, an HTTP proxy such as NGINX will be able to accept both HTTPS and TURN requests on port 443.

When TURN is using raw TCP, we need another component such as HAProxy.

It's even more complicated because you need to terminate SSL before you know if the packet is TURN or HTTPS.

HAProxy can terminate SSL but it's usually better to do it in NGINX.

TURN over secure Websockets will make things much easier.

[Andy Hutton]

Within the IETF opinion is divided on whether the IETF should specify how WebRTC browsers behave in the presence of proxies and firewalls some people think it is controversial because it might be a way of bypassing policies and might break some proxies personally I don't agree and believe that specifying the browser behaviour is needed so that policy based systems can be built and proxies know what to expect. 

Because it is controversial to some a non working group mailing list was established to discuss http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03 in the IETF the mailing list info can be found at: (https://www.ietf.org/mailman/listinfo/pntaw).  This list has gone dormant over the last few months as it was not clear how to proceed but this probably be the place to restart the discussion in the IETF on things like TURN over websockets etc.

Andy

[Justin Uberti]

You need to run a TURN server anyway, and that can be done on the same machine. I don't know why you would want to run media traffic over TCP in a development environment.

[pablo platt]

I'm building MCU and trying to avoid a TURN server.

If the browser will be able to send RTP over secure Websocket, the TURN server won't be needed for the MCU.

I want my dev environment to match production.

[Justin Uberti]

You will not be happy with your media quality if you use Websockets. This does not seem like a sensible approach.

[pablo platt]

The benefits of using WebRTC over secure Websockets:

- Work with most Firewalls.

- Work with HTTP proxy servers like Nginx.

- MCU doesn't need additional TURN server.

The media quality over Websockets will be exactly like raw TCP.

TCP is used only as a fallback when UDP doesn't work.

SSL is used only when TCP doesn't work.

This is not relevant to a connection between two browsers but is very useful for servers (MCU).

[SProgrammer]

@pablo: please make a DRAWING what you are trying to do and what is not giving you to do. 

on DRAWING with your goal and another DRAWING which is blocking you cause its out of your knowledge perhaps.

- Have you tried: HTTP CONNECT http://httpd.apache.org/docs/current/mod/mod_proxy.html#allowconnect ? or use BASH with Socat / Stunnel

- if i understand you good, You want something like: end point (A) connecting over HTTP and HTTPS to media server (B) and media server (B) is then sending back the media to the end point (A) using same HTTP session? like inject Media over HTTP or HTTPS session (same as YouTube, instead of pre-recorded content you want some live People sharing the live stream) ?

* And what is wrong using rfc5766-turn-server if i may ask, which is already giving you so much + it works perfectly + its stable and robust + standard followed no tricks which is safe for security people and will be easily maintained by network admins.

reg

shamun

[pablo platt]

How can I use something like HAProxy to separate TURN/TLS packets from HTTPS?