Subject: RTP in HTTP

From: [email-masked]
Date: Tue, 24 Jul 2001 10:42:50 +0200

A week ago I submitted a draft for discussion in London
about tunneling RTP in HTTP (since it is small I also attach it here).

I though that this would be discussed in AVT but was told that
the subject would better be discussed in MMUSIC, hence the announcement here...

(See attached file: draft-gentric-avt-RTP-HTTP-00.txt)

Regards,

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
[email-masked]
http://www.mpeg-4player.com

Internet Engineering Task Force                         Gentric-Philips 
Internet Draft                                              Jones-Apple 
                                                              July 2001 
                                                      Expires Jan. 2002 
Document: draft-gentric-avt-RTSP-HTTP-00.txt                            

                         Tunneling RTSP in HTTP 

Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by other 
   documents 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 at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
   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 the 
   requirements for a solution and outline what a solution could be. 
    
  2. Motivation 
    
   RTSP [1, 10.12] clearly defines how RTP stream data can be embedded 
   with RTSP methods. It also recommends that RTSP should be 
   transported using TCP. 
    
   Note that tunneling RTSP (only) in HTTP would not be useful since 
   the RTP data transported using UDP would be blocked. 

Gentric, Jones           Expires January 2002                        1 

                        Tunneling RTSP in HTTP               July 2001 

   With this TCP based transport of RTP-inside-RTSP, firewalls 
   configured to exclude UDP traffic can be traversed, which is already 
   very useful. 
    
   However for many end users the situation is even worse; indeed some 
   ISPs and many corporate Internet access are protected by strict 
   firewalls. Typically these firewalls are configured to exclude all 
   traffic except 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 should 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 an 
   issue we need to discuss here since transporting RTP inside RTSP on 
   TCP (as described in [1]) suffers from the same problem.  
    
   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 many cases the reason why a 
   corporate or ISP firewall is configured for HTTP only is pure 
   paranoia, there are cases when suppressing media streaming is a 
   genuine concern for an IT administrator. In this last case providing 
   a standard technology that makes it possible to filter RTSP in HTTP 
   would 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 decision makers and knowledgeable technical 
   people. In such environments firewalls 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 firewalls otherwise it will be a very little value since we 
   cannot expect this key target population to upgrade their firewalls 
   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 firewalls 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 the 
   emergence of a standard technology enabling to deploy firewalls that 
   can also block tunneling of media in HTTP will be well received. 
   Therefore the solution we seek should also provide the ability to 
   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 the 
   following: 
   Requirement 1: to traverse existing (deployed) HTTP-only firewalls 
   Requirement 2: to allow the development of new HTTP-level firewalls 
   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 the 
   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 firewalls 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 as 
   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 performed on very large scales by 
   a number of proprietary solutions and firewall administrators are 
   actually lacking standard-based solutions to recover control upon 
   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 could detect this 
   scenario by looking for an Accept or Content-Type header containing 
   "application/x-rtsp-tunnelled". Classical filtering techniques could 
   then be applied. 
    
   Alternatively other marking schemes could 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 of 
   this forum for raising interesting points. 
    
   8. References 
 
   [1] Schulzrinne, Rao, Lanphier, RTSP: Real Time Streaming Protocol 
   RFC 2326, Internet Engineering Task Force, April 1998. 
   [2] Schulzrinne, Casner, Frederick, Jacobson 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: [email-masked] 
    
   anne jones  
   Apple 
   1 Infinite Loop 
   Cupertino, CA 95014 
   e-mail: [email-masked] 

Gentric, Jones           Expires January 2002                        4