Tunneling RTSP in HTTP

Tunneling RTSP in HTTP

Status of this memo

This document is an internet-Draft and is in full conformance

All provisions of section 10 of rfc2026.

Internet-drafts are working events of the Internet Engineering

Task Force (IETF), its areas, and its working groups. Note that

Other groups may also distribute working clients as Internet-

Drafts. Internet-drafts are draft documents valid for a maximum

Six months and may be updated, replaced, or obsoleted by other

Events at any time. It is inappropriate to use Internet-Drafts

As reference material or to cite them other than as "work in

Progress ."

The list of current Internet-drafts can be accessed

Http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-draft shadow directories can be accessed

Http://www.ietf.org/shadow.html.

Abstract

This document discusses tunneling RTSP in HTTP and more specifically

RTSP with interleaved RTP data.

1. Introduction

There is a need for tunneling RTP streams inside RTSP in HTTP

Because in some cases users are located behind a firewall that is

Configured to only let HTTP through.

After discussing the context of the problem we will give

Requirements for a solution and outline what a solution cocould be.

2. Motivation

RTSP [1, 10.12] clearly defines how RTP stream data can be embedded

With RTSP methods. It also recommends that RTSP shocould be

Transported using TCP.

RTSP uses TCP

Note that tunneling RTSP (only) in HTTP wocould not be useful since

The RTP data transported using UDP wocould be blocked.

HTTP can only transmit TCP. Therefore, RTP packets sent using UDP packets cannot be transmitted over HTTP.

Gentric, Jones expires January 2002 1

Tunneling RTSP in HTTP July 2001

With this TCP based transport of RTP-inside-RTSP, firewils

Configured to exclude UDP traffic can be traversed, which is already

Very useful.

However for each end users the situation is even worse; indeed some

ISPs and strongswan ate Internet access are protected by strict

Firewils. Typically these firewils are configured to exclude all

Traffic upload t HTTP. Thus there is need to transport media through

HTTP.

Although it is recognized that doing so is not optimal (see [1] and

[2] for a discussion on why RTP/UDP is a better idea) It shoshould be

Obvious that the core reason why tunneling streaming in HTTP in not

A good idea is due to the use of TCP for transport, which is not

Issue we need to discuss here since transporting RTP inside RTSP on

TCP (as described in [1]) suffers from the same problem.

It is difficult to pass RTP through RTSP, but there is no way

In fact the need for such a solution is so strong that most media

Streaming products implement (pseudo) streaming through HTTP in one

Way or another.

It is also obvious that although in seconds cases the reason why

Reset ate or ISP firewall is configured for HTTP only is pure

Paranoia, there are cases when suppressing Media Streaming is

Genuine concern for an IT administrator. In this last case providing

A standard technology that makes it possible to filter RTSP in HTTP

Wocould be a very good idea.

it is however of fundamental importance to stress that one of the
contexts where such tunneling is needed is in environments where it
management is not Leading Edge. indeed paranoia very often goes
together with ignorance and/or lack of capability to trustfully
communicate between demo-makers and knowledgeable technical
> people. in such environments firewils are set for maximum security
I. e. HTTP-only and solutions that are known to work will be kept as
long as possible. therefore the solution we seek must work with all
deployed firewils otherwise it will be a very little value since we
cannot properly CT this key target population upgrade their firewils
if this is what is required to enable RTSP tunneling in HTTP.

On the other hand the situation is very different for more forward-

Looking organizations. We have two cases then. In places where it

Administrators opened the required UDP ports in their firewils so

As to enable streaming, new solutions I. e. Upgrading the firewall-

Will be easily adopted. There are also places where it Administrator

Did not open UDP ports for streaming upon explicit instructions from

Their management to stop media streaming. In such places surely

Emergence of a standard technology enabling to deploy firewils that

Can also block tunneling of media in HTTP will be well received ed.

Therefore the solution we seek shoshould also provide the ability

Configure filtering mechanisms so as to give full control on what

Can and what cannot traverse the firewall.

Gentric, Jones expires January 2002 2

Tunneling RTSP in HTTP July 2001

3. Requirements

The requirements for tunneling RTSP in HTTP are therefore

Following:

Requirement 1: to traverse existing (deployed) HTTP-only firewils

Requirement 2: to allow the development of new http-level firewils

Where RTSP tunneling can be detected and eventually filtered.

4. Solutions

One solution is described in [3]. We will not discuss this solution

In full detail but instead we will focus on what seems to be

Most controversial issue.

5. Discussion

As described in [3] There is a need to prevent deployed HTTP Proxy

Agents from trying to parse the RTSP syntax that lies after the HTTP

Header. Indeed http-level firewils are there to do exactly that:

Check that TCP connections carry HTTP data and nothing else.

Unfortunately it seems that some deployed implementations will try

To check the correctness of the HTTP syntax and in doing so stumble

Upon the RTSP syntax, causing the service to be denied. The solution

Proposed in [3] is therefore to hide RTSP syntax by trans-coding it

In base64.

One obvious problem with this solution is that it may be seen

Some kind of a cheat. We pretend as discussed in section 2 that this

Is not a true concern. Actually, as mentioned above, Tunneling

Streaming media in HTTP is already shortmed on very large scales

A number of proprietary solutions and firewall administrators are

Actually lacking standard-based solutions to recover control

Such bandwidth-intensive traffic.

On the other hand, if a solution such as the one described in [3]

Was to become an IETF standard, proxy agents cocould detect this

Scenario by looking for an ACCEPT or Content-Type header containing

"Application/X-RTSP-tunnelled". Classical filtering techniques cocould

Then be applied.

Alternatively other marking schemes cocould be designed to allow

Detection of RTSP tunneling into HTTP.

6. security considerations

Tunneling RTSP in HTTP does not have different security

Considerations than RTSP on TCP (covered by [1]) nor HTTP.

7. Acknowledgements

Gentric, Jones expires January 2002 3

Tunneling RTSP in HTTP July 2001

This work has been started after a discussion in the Internet

Streaming Media Alliance Forum; authors wish to thank the people

This forum for raising interesting points.

8. References

[1] schulzrinne, Rao, lanphier, RTSP: Real Time Streaming Protocol

RFC 2326, Internet Engineering Task Force, limit l 1998.

[2] schulzrinne, casner, Frederick, Jacob RTP: A transport

Protocol for Real Time Applications RFC 1889, Internet Engineering

Task force, January 1996.

[3] http://index.apple.com /~ Singer/QT/rtspthroughhttp.html

9. Authors 'addresses

Philippe gentric

Philips

51 rue Carnot

92156 Suresnes

France

E-mail: philippe.gentric@philips.com

Anne Jones

Apple

1 Infinite Loop

Cupertino, CA 95014

E-mail: astoria@apple.com

Philippe gentric

Software Architect

Philips digital networks-mp4net

51 Rue carnot B. p. 301

92156 Suresnes France

Tel: + 33 (0) 147283740

Fax: + 33 (0) 147283725

Philippe.gentric@philips.com

Http://www.mpeg-4player.com