Section 15. Proxies

RTSP Proxies are RTSP agents that are located in between a client and
   a server.  A proxy can take on the roles of both client and server
   depending on what it tries to accomplish.  RTSP proxies use two
   transport-layer connections: one from the RTSP client to the RTSP
   proxy and a second from the RTSP proxy to the RTSP server.  Proxies
   are introduced for several different reasons; those listed below are
   often combined.
   Caching Proxy:  This type of proxy is used to reduce the workload on
         servers and connections.  By caching the description and media
         streams, i.e., the presentation, the proxy can serve a client
         with content, but without requesting it from the server once it
         has been cached and has not become stale.  See Section 16.
         This type of proxy is also expected to understand RTSP endpoint
         functionality, i.e., functionality identified in the Require
         header in addition to what Proxy-Require demands.
   Translator Proxy:  This type of proxy is used to ensure that an RTSP
         client gets access to servers and content on an external
         network or gets access by using content encodings not supported
         by the client.  The proxy performs the necessary translation of
         addresses, protocols, or encodings.  This type of proxy is
         expected also to understand RTSP endpoint functionality, i.e.,
         functionality identified in the Require header in addition to
         what Proxy-Require demands.
   Access Proxy:  This type of proxy is used to ensure that an RTSP
         client gets access to servers on an external network.  Thus,
         this proxy is placed on the border between two domains, e.g., a
         private address space and the public Internet.  The proxy
         performs the necessary translation, usually addresses.  This
         type of proxy is required to redirect the media to itself or a
         controlled gateway that performs the translation before the
         media can reach the client.
   Security Proxy:  This type of proxy is used to help facilitate
         security functions around RTSP.  For example, in the case of a
         firewalled network, the security proxy requests that the
         necessary pinholes in the firewall are opened when a client in
         the protected network wants to access media streams on the
         external side.  This proxy can perform its function without
         redirecting the media between the server and client.  However,
         in deployments with private address spaces, this proxy is
         likely to be combined with the access proxy.  The functionality
         of this proxy is usually closely tied into understanding all
         aspects of the media transport.
   Auditing Proxy:  RTSP proxies can also provide network owners with a
         logging and auditing point for RTSP sessions, e.g., for
         corporations that track their employees usage of the network.
         This type of proxy can perform its function without inserting
         itself or any other node in the media transport.  This proxy
         type can also accept unknown methods as it doesn't interfere
         with the clients' requests.
   All types of proxies can also be used when using secured
   communication with TLS, as RTSP 2.0 allows the client to approve
   certificate chains used for connection establishment from a proxy;
   see Section 19.3.2.  However, that trust model may not be suitable
   for all types of deployment.  In those cases, the secured sessions do
   bypass the proxies.
   Access proxies SHOULD NOT be used in equipment like NATs and
   firewalls that aren't expected to be regularly maintained, like home
   or small office equipment.  In these cases, it is better to use the
   for these recommendations is that any extensions of RTSP resulting in
   new media-transport protocols or profiles, new parameters, etc., may
   fail in a proxy that isn't maintained.  This would impede RTSP's
   future development and usage.
15.1.  Proxies and Protocol Extensions
   The existence of proxies must always be considered when developing
   new RTSP extensions.  Most types of proxies will need to implement
   any new method to operate correctly in the presence of that
   extension.  New headers can be introduced and will not be blocked by
   older proxies.  However, it is important to consider if this header
   and its function are required to be understood by the proxy or if it
   can be simply forwarded.  If the header needs to be understood, a
   feature tag representing the functionality MUST be included in the
   Proxy-Require header.  Below are guidelines for analysis whether the
   header needs to be understood.  The Transport header and its
   parameters are extensible, which requires handling rules for a proxy
   in order to ensure a correct interpretation.
   Whether or not a proxy needs to understand a header is not easy to
   determine as they serve a broad variety of functions.  When
   evaluating if a header needs to be understood, one can divide the
   functionality into three main categories:
   Media modifying:  The caching and translator proxies modify the
      actual media and therefore need also to understand the request
      directed to the server that affects how the media is rendered.
      Thus, this type of proxy also needs to understand the server-side
      functionality.
   Transport modifying:  The access and the security proxy both need to
      understand how the media transport is performed, either for
      opening pinholes or translating the outer headers, e.g., IP and
      UDP or TCP.
   Non-modifying:  The audit proxy is special in that it does not modify
      the messages in other ways than to insert the Via header.  That
      makes it possible for this type to forward RTSP messages that
      contain different types of unknown methods, headers, or header
      parameters.
   An extension has to be classified as mandatory to be implemented for
   a proxy, if an extension has to be understood by a "Transport
   modifying" type of proxy.
15.2.  Multiplexing and Demultiplexing of Messages
   RTSP proxies may have to multiplex several RTSP sessions from their
   clients towards RTSP servers.  This requires that RTSP requests from
   multiple clients be multiplexed onto a common connection for requests
   outgoing to an RTSP server, and, on the way back, the responses be
   demultiplexed from the server to per-client responses.  On the
   protocol level, this requires that request and response messages be
   handled in both directions, requiring that there be a mechanism to
   correlate which request/response pair exchanged between proxy and
   server is mapped to which client (or client request).
   This multiplexing of requests and demultiplexing of responses is done
   by using the CSeq header field.  The proxy has to rewrite the CSeq in
   requests to the server and responses from the server and remember
   which CSeq is mapped to which client.  The proxy also needs to ensure
   that the order of the message related to each client is maintained.
   Section 18.20 defines the handling of how requests and responses are
   rewritten.