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.
This will result in the need for edits in:
- Clarification of header ignore for all RTSP agents
- Rewrite Transport header text on handling of parameters and especially unknowns
- Reword when feature-tags are need in relation to this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
This will result in the need for edits in:
- Clarification of header ignore for all RTSP agents
- Rewrite Transport header text on handling of parameters and especially unknowns
- Reword when feature-tags are need in relation to this.
A proposal has been checked in CVS and also sent to WG mailing list. Awaiting feedback.