[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP: Proxies and handling of unknown methods, headers and transport parameters
Hi,
Here is the text parts that I suggest to change to address this issue.
Please comment.
5.2. Message Headers
See [H4.2].
Unknown message headers SHALL be ignored by a RTSP server or client.
An RTSP Proxy SHALL forward unknown message headers. Message headers
defined outside of this specification that are required to be
interpret by the RTSP agent will need to use feature tags
(Section 4.7) and include it in the appropriate Require
(Section 16.42) or Proxy-Require (Section 16.35) header.
13. Last paragraph:
If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination.
An RTSP proxy whos main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note, the proxy stil needs to perform the minimal
required processing, like adding the Via header.
16.35:
End of section before example:
See discussion in the Proxies section (Section 17.1) about when to
consider that a feature requires proxy support.
16.42:
Part of First paragraph:
This header does not apply to proxies, for the same functionality in
respect to proxies see Proxy-Require header (Section 16.35) with the
exception of media modifying proxies. Media modifying proxies due to
their nature of handling media in a way that is very similar to what a
server, do need to understand also the server features to correctly
serve the client.
At end of section
See discussion in the Proxies section (Section 17.1) about when to
consider that a feature requires proxy support.
16.51. Transport
The Transport request and response header field indicates which
transport protocol is to be used and configures its parameters such
as destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not
already determined by a presentation description.
A Transport request header field MAY contain a list of transport
options acceptable to the client, in the form of multiple transport
specification entries. Transport specifications are comma separated,
listed in decreasing order of preference. Parameters may be added to
each transport specififcation, separated by a semicolon. The server
MUST return a Transport response-header field in the response to
indicate the values actually chosen if any. If not transport
specification is supported an empty header is returned and the
request SHALL be responded using the status code 461 (Unsupported
Transport) (Section 15.4.13). In case more than one transport
specification was present in the request, the server MUST return the
single (transport-spec) which was actually chosen if any. The number
of transport-spec entries is expected to be limited as the client
will get guidance on what configurations that are possible from the
presentation description.
The Transport header field MAY also be used in subsequent SETUP
requests to change transport parameters. A server MAY refuse to
change parameters of an existing stream.
A transport specification may only contain one of any given parameter
within it. Parameters MAY be given in any order. Additionally, it
may only contain either of the unicast or the multicast transport
type parameter. All parameters needs to be understood in a transport
specification, if not the transport specification SHALL be ignored.
RTSP proxies of any type that uses or modifies the transport
specification, e.g. acces proxy or security proxy, SHALL remove
specifications with unknown parameters before forwarding the RTSP
message. If that result in no remaing transport specification the
proxy shall send a 461 (Unsupported Transport) (Section 15.4.13)
response with an empty Transport header.
17. Proxies
RTSP Proxies are RTSP agents that sit in between a client and a
server. A proxy can take on both the role as a client and as server
depending on what it tries to accomplish. Proxies are also
introduced for several different reasons and the below are often
combined.
Caching Proxy: This type of proxy is used to reduce the workload on
servers and connections. By caching a presentation, both
description and media streams the proxy can serve a client
content without requesting it from the server once it has been
cached and hasn't become stale. See the caching Section 18.
This type of proxy is expected to also understand RTSP end-
point 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 a RTSP
client get access to servers and content on an external network
or 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 to also
understand RTSP end-point 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 a RTSP
client get 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 proxies are required to redirect the media to
themselves or a controlled gateway that perform 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 when having a
firewalled network, the security proxy request that the
necessary pinholes in the firewall is opened when a client in
the protected network want to access media streams on the
external side.This proxy can also limit the clients access to
certain type of content. This proxy can perform its function
without redirecting the media between the server and client.
However, in deployements with private address spaces this proxy
is likely to be combined with the access proxy. Anyway, the
functionality of this proxy is usually closely tied into
understand all aspects of how the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for
corporations that tracks 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 type of proxies can be used also 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 type of
deployment, and instead secured sessions do by-pass of 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
NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason 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. Thus resulting in blocking further development of
RTSP and its usage.
17.1. Proxies and Protocol Extensions
The existence of proxies must always be considered when developing
new RTSP extensions. Most type of proxies will need to implement any
new method to operate correct in the presence of that extension. New
headers will be possible to introduce without being blocked by
proxies not yet updated. However, it is important to consider if
this header and its function is required to be understood by the
proxy or can be forwarded. If the header needs to be understood a
feature-tag representing the functionality needs to be included in
the Proxy-Require header. Below are guidelines for analysis if the
header needs to be understood. The transport header and its
parameters also shows that headers that are extensible and requires
correct interpretation in the proxy also requires handling rules.
When defining a new RTSP header it needs to be considered if RTSP
proxies are required to understand them to achieve correct
functionality. Determining this is not easy as the functionality for
proxies are widely varied as can be understood from the above list of
functionality. When evaluating this one can dived the functionality
into three main categories:
Media modifying: The caching and translator proxies are modifying
the actual media and therefore needs to understand also request
directed to the server that affects how the media is rendered.
Thus this type of proxies needs to also understand the server side
functionality.
Transport modifying: The access and the security proxy both need to
understand the how the transport is performed, either for opening
pinholes or to translate the outer headers, e.g. IP and UDP.
Non-modifying: The audit proxy is special in that it do not modify
the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP message that
contains different type of unknown methods, headers or header
parameters.
Based on the above classification one should evaluate if ones
functionality requires the Transport modifying type of proxies to
understand it or not.
--
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Färögatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic