| Feature | Correct behavior | |||||
|---|---|---|---|---|---|---|
| Both Support | Client Doesn't Support | Server Doesn't Support | ||||
| Client | Server | Client | Server | Client | Server | |
| Feature | yes/no on support of each feature | |||||
| Feature | Explanation |
|---|---|
| 1-1-n | 1-1-n refers to one DESCRIBE message resulting in one RTSP session (defined by the "Session:" header), which may have multiple streams in it. If the server supports this feature, then the client should be able to issue SETUP messages with "Session:" headers which map to existing sessions. Furthermore, the client should be able to issue PLAY and PAUSE messages that play and pause all streams associated with a particular session. |
| Null SETUP | Null SETUP is the ability to send a SETUP without a "Transport" field defined. This allows a client to pipeline DESCRIBE and SETUP, saving a roundtrip in 1-1-n situations. Servers should either return a session id, or error XXX. |
| Audio only | Given an A/V clip, the client may only support the audio type given. Against servers that support individual streaming of aggregate streams, the client should be able to request the audio portion only. If the stream is an aggregate stream and the server does not support sending only one part of an aggregate resource, then the client must be able to handle error 460 Only aggregate operation allowed. |
| Video only | Given an A/V clip, the client may only support the video type given. Against servers that support individual streaming of aggregate streams, the client should be able to request the video portion only. If the stream is an aggregate stream and the server does not support sending only one part of an aggregate resource, then the client must be able to handle error 460 Only aggregate operation allowed. |
| Response codes | Tests should be done to determine if RTSP entities properly support the following response codes: |
| 100 Continue | XXX |
| 200 OK | One would hope that "OK" doesn't throw implementations too far afield. |
| 201 Created | XXX Presumably for recording. Should be supported for ANNOUNCE method from client to server. |
| 300 Multiple Choices | XXX |
| 301 Moved Permanently | Ye olde redirect message. If the client or proxy caches redirects, this should be the only redirect that is cached. |
| 302 Moved Temporarily | These are redirect message that should never be cached. |
| 303 See Other | XXX |
| 305 Use Proxy | Specialized redirect for proxies. The client is not expected to use this as a permanent proxy. |
| 400 Bad Request | XXX There are any number of tests that will probably result in this response. Perhaps there should be a list of tests in place of this. |
| 401 Unauthorized | All clients should try to access authenticated content. |
| 402 Payment Required | XXX Reserved for future use. |
| 403 Forbidden | Try getting a piece of content for which the permissions are not set for access by the server process. |
| 404 Not Found | Try accessing an URL which is not on the server. |
| 405 Method Not Allowed | Try using a method which the server does not recognize. For instance, try recording to a server which only supports playback (and hence, doesn't support the RECORD method). |
| 406 Not Acceptable | This is in response to a DESCRIBE request for a session description in formats not recognized by the server. |
| 407 Proxy Authentication Required | Try hooking up to via a proxy which requires authentication. |
| 408 Request Timeout | XXX |
| 409 Conflict | XXX |
| 410 Gone | XXX |
| 411 Length Required | XXX |
| 412 Precondition Failed | XXX |
| 413 Request Entity Too Large | XXX |
| 414 Request-URI Too Long | XXX |
| 415 Unsupported Media Type | This response code should only be in response to the ANNOUNCE method. |
| 451 Invalid parameter | XXX |
| 452 Illegal Conference Identifier | XXX |
| 453 Not Enough Bandwidth | XXX |
| 454 Session not found | XXX |
| 455 Method Not Valid In This State | XXX |
| 456 Header Field Not Valid | XXX |
| 457 Invalid Range | XXX |
| 458 Parameter Is Read-Only | XXX |
| 459 Aggregate operation not allowed | XXX |
| 460 Only aggregate operation allowed | XXX |
| 500 Internal Server Error | XXX |
| 501 Not Implemented | XXX |
| 502 Bad Gateway | XXX |
| 503 Service Unavailable | XXX |
| 504 Gateway Timeout | XXX |
| 505 RTSP Version Not Supported | This is going to be a very important behavior to nail down. Clients and servers should behave consistantly on this method when version numbers do not match. |
| Header Fields | Applicability to each of the RTSP methods. Server to reply with "Header invalid" when the header does not make sense for the method per table in Section 12 of draft-04. |
| Accept | Server should parse and honor if possible i.e. return a description of the correct type. |
| Accept-Encoding | Server should parse and honor if possible i.e. return a description of the correct encoding. |
| Accept-Language | Server should parse and honor if possible i.e. return a description of the correct language. |
| Allow | Server may include in a reply to a request that fails when the method is not allowed on the resource. Clients that parse it should reattempt only one of the allowed methods. |
| Authorization | Clients that support authentication must include when challenged by a 401 Unauthorized status. |
| Bandwidth | Client may include as a hint to the server. Servers that parse it may base a selection on it. |
| Blocksize | Client may include as a hint to the server. Servers that parse it use it as a hint for the transport packet size. |
| Cache-Control | |
| Conference | Servers that support it must maintain a mapping of identifiers to conference details, comply with the RTSP request and reply with "Conference not found" when appropriate. |
| Connection | Client : Include keep-alive if it wants a persistent connection. If
not, be prepared for Connection:close.
Server: Respect client requested keep-alive. Include Connection:close if it does not intend to keep the connection persistent. |
| Content-Base | Servers to include if necessary when urls in Session descriptions are relative. Client to recognize and construct absolute urls. |
| Content-Encoding | Server to include, client to parse and then handle message body. Reverse in case of ANNOUNCE. |
| Content-Language | Server to include, client to parse and then handle message body.Reverse in case of ANNOUNCE. |
| Content-Length | Server to include, client to parse and then handle message body.Reverse in case of ANNOUNCE. |
| Content-Location | Servers to include if necessary when urls in Session descriptions are relative. Client to recognize and construct absolute urls. |
| Content-Type | Server to include, client to parse and then handle message body.Reverse in case of ANNOUNCE. |
| CSeq | Request originator to include, responder to include the same header in the response. |
| Date | Included by either side, informational. Must follow the format in RFC2068. |
| Expires | May be included by the server. If the client supports it, it must not send a request for the same URL after the expire time. |
| From | XXX |
| Host | Not required, to be ignored. |
| If-Match | Requester may include, responder must make the request conditional and respond with 3xx as necessary. On receipt of a 3xx, the requester may use a local copy of the resource. |
| If-Modified-Since | Requester may include, responder must make the request conditional and respond with 3xx as necessary. On receipt of a 3xx, the requester may use a local copy of the resource. |
| Last-Modified | Responder to include if it supports it. |
| Location | To be included with redirect responses or requests. |
| Proxy-Authenticate | XXX |
| Proxy-Require | Proxies to necessarily parse and respond negatively if the feature requested is not supported. |
| Public | Included by responder to indicate methods that are valid for the resource or the server(for OPTIONS). |
| Range | Client may include it supports seeks or random access. If it supports random-access, server should parse and respond properly i.e. if correct, comply and if incorrect, reply with 457. Support for npt units is mandatory. |
| Referer | XXX |
| Retry-After | Server to inlcude if the resource will be available after a while. Client to retry the request only at the appropriate time. |
| Require | Client to include if it needs support for a certain feature. Server to necessarily parse and respond negatively if the feature in question is not supported. |
| RTP-Info | Server to necessarily include when all of the following are true:
-Transport chosen is RTP -It is the very first play for a resource or the first play after a pause. In case of queued PLAY, the server may choose not to include it. |
| Scale | Client may include it to support features such as fast-forward. Server to reply with "Not implemented" if the feature is not supported, or reply back with the exact chosen Scale that may be slightly different from the requested scale. |
| Speed | Client may include it to support features such as fast-forward. Server to reply with "Not implemented" if the feature is not supported, or reply back with the exact chosen speed that may be slightly different from the requested speed. |
| Server | May be included by the server for informational purposes only. |
| Session | Pretty core and fundamental behaviour. Client should inlcude this header. Server to use it to reference sessions and their state and respond with "Session not found" when necssary. Client should be prepared for this error message. |
| Timestamp | Client may include if it desires to perform RTT calculation. At minimum, server to echo back the header. |
| Transport | Both sides need to support it per the letter of draft-04. |
| Unsupported | Server must include if it does not support the feature specifed in a Require: request header. Same applies to proxies, but with the Proxy-Require request header. |
| User-Agent | Client may include on an informational basis. |
| Vary | XXX |
| Via | XXX |
| WWW-Authenticate | Server must include with 401 responses.If it supports authentication, the client must resend the request with a Authorization header containing credentials in the right realm. |
| Client and server match datatypes on some, but not all streams on 1-1-n | Server must send 460/461 as appropriate. Client must understand the "aggregate/no-aggregate" status codes. |
| Client and server don't match any datatypes on 1-1-n | Client should gracefully refuse. |
| Proxy | XXX |
| Connection header/Keep-alive. | Clients may inlcude Connection headers, in which case server is expected to comply. If the server does not wish to keep a persistent connection, it must include the Connection: close header. |
| Test per header | Test servers for header applicability on a per method basis. |
| Different permutations of supported transports | Check support for RTP/AVP/UDP with unicast/multicast flags.
Check support or lack of support for RTP/AVP/TCP. |
| Minimal test case: | XXX |
| RTSP control over TCP with support for PLAY mode
RTP transport over UDP, unicast only |
|
| Datatypes(compliant with RFC 1890) | Note that this is not a "minimal" set of data types required to be supported for the bakeoff. However, attendees are expected to support atleast one or more of these in order to make the tests useful. |
| ulaw | XXX |
| Motion JPEG | XXX |
| H.261 | XXX |
| GSM | XXX |
| alaw | XXX |
| L8 | XXX |
| L16 | XXX |
| G.723 | XXX |