[MMUSIC] RTSP: Proxies and handling of unknown methods, headers and transport parameters

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

This is an email concerning the following tracked bug:
https://sourceforge.net/support/tracker.php?aid=1898828

Note, this is a fairly long email, but there is suggestion to also
change the server behavior in this email!

We have several types of RTSP proxies, but one fundamental difference is
between the ones that insert themselves or some other entity in the
media transport or the ones that only concern themselves with the
signalling. The fact that we have several type makes the rules for how
proxies shall handle unknown RTSP methods, headers and transport
parameters a bit more difficult.

Methods:

The current text that regulates this is the following from section 13:

   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.

As RTSP agents include proxies also, the current documented rule is that
a proxy needs to support the method it is forwarding. I think this
mostly makes sense, I can only see it be lessened for a specific type of
RTSP proxy which only function is to allow for logging of the RTSP
messages. But, even that is not certain to work, although likely. Thus I
suggest that we leave this as currently specified. Any objections?

Headers:

Headers are more problematic because a proxy can't really know what
purpose an unknown header is for. But it shouldn't be directly related
to the setup of media transport as these parameters all should be in the
transport header. Thus Access proxies or Security proxies does not need
to understand unknown headers and could forward them. An Caching proxy
may very well not have that luxury. But as a Caching proxy anyway need
to have full understanding of the media, a chaching proxy could be
required to understand all headers a server needs to understand.

My proposal for proxies is that they forward unknown headers and when
defining a header that a proxy needs to understand one uses a feature
tag that is put in the Proxy-Require header. When performing the
evaluation one should consider Access proxies and Security proxies. A
caching proxy has the choice to act as caching proxy and also ensure it
understands all feature tag in both the proxy-require and require header
or fallback to be an access proxy or similar and forward unknown header.
This seems to be in line with how servers treat unknown headers that
also should be ignored.

Transport specifications:

Now we are getting into the real problems. Servers that receive unknown
parameters are currently specified to ignore them. And if the client
requires the server to understand a parameter it is to add a feature tag
in require. Consider what this policy result in the proxy-require header
case makes this really unattractive. For proxies that don't insert
itself into the path this proxy-require prevents processing the message
at all. For proxies that pins the transport or translates it in any
fashion this is also causing extra round trips while it informs the
client about what it doesn't support. Similar issue do exist on the
server side causing unnecessary churn when requesting potentially
unsupported transports.

To resolve the above issue I suggest a general change in the handling of
unknown Transport header parameters. A RTSP agent receiving a request
with a Transport header SHALL ignore all transport specifications that
contains unknown transport parameters. That way in case there are
multiple transport specifications in the header the entity can strip
away the ones that contains unknown things. Please notice that it still
may be smart to define a feature tag for certain transport level
functionality so that one can learn support in OPTIONS request or other
methods including the supported header. But if one is using transport
parameters to get a certain functionality one can also specify a fall
back version that is expected to work with lower priority.

Comments?

Cheers

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