Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.

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

Hi Joe,

Joe Pallas skrev:
> Once again I will assert that CSeq is both unnecessary and, as we see
> from this discussion, confusing.  It should be removed.  (Some
> replacement may be needed for the Request-Status header of PLAY_NOTIFY,
> however. The existing NOTIFY extension used with RTSP 1.0 does not have
> an equivalent, so it's not clear it is necessary.)
> 
> To recap:
> 1. CSeq was originally included in RTSP 1.0 to support unreliable
> protocols such as UDP.
> 2. UDP support in RTSP 1.0 was never fully specified and no one has
> claimed to have an implementation.

I know of one that has implemented RTSP 1.0 over UDP.

> 3. RTSP now explicitly assumes a reliable, connection-oriented stream
> protocol such as TCP.
> 4. CSeq serves no purpose with a reliable transport layer.
> 5. HTTP seems to have achieved a modest degree of success in the field,
> including proxy support, without any equivalent to CSeq; it uses
> transport connections to distinguish conversations.

We are actually using CSeq for something these days. PLAY_NOTIFY's
Request-Status header uses CSeq to refer to previous request.

But I agree due to the strict ordering and the usage of reliable
byte-stream oriented transport an RTSP agent can match the responses to
the requests based on order.

I think the proxy would need to keep track of things basically in the
same way. Because if you aggregate together requests then you anyway
need to keep track of which message in the order relates to which
client. CSeq can be used or you can implement your own sequencing with
local queue numbers.

> 
> The only argument I've heard for keeping CSeq is backward compatibility
> with existing implementations.  I don't think that's very strong,
> because the draft explicitly denies compatibility with RTSP 1.0.  For it
> to matter, there would need to be an existing implementation that
> assumes responses can arrive out of order and relies on CSeq to match
> responses to requests.  Does anyone know of such?

The draft currently says:

   Certain RTSP headers, such as the CSeq header (Section 16.19), which
   may appear to be relevant only to connectionless transport scenarios
   are still retained and must be implemented according to the
   specification.  In the case of CSeq, it is quite useful for matching
   responses to requests if the requests are pipelined (see Section 12).
   It is also useful in proxies for keeping track of the different
   requests when aggregating several client requests on a single TCP
   connection.



> 
> If we really can't remove it, can we at least deprecate it—include some
> text that clearly informs the reader that CSeq has no meaning and should
> not be relied upon for anything?  The rules would be something like
> this: CSeq is not required on a request. If a server receives a request
> with CSeq, it must include CSeq in the response.
> 

I think the compromise is problematic and as we actually are using CSeq
for inter message references in the current spec I think removing it is
less good. Sure you could do another solution for that, but I don't see
it becoming easier than CSeq.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------