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

From: "Y.J. Gu" <[email-masked]>
Date: Thu, 10 Sep 2009 09:35:37 +0800

Thanks Jaehwan.
Here is my implementation. In order to be compatible to those servers who
may maintain session states and check client IP Add, I did not set up single
RTSP to server multiple clients.

Insead, e.g., Proxy set up 2 TCP connections with 2 servers, each TCP
connection carries aggregate RTSP sessions with sequent CSeq series start
with 0. 

During implementation, I find that Proxy will receives responses with same
Cseq from these 2 servers. So I have to take TCP sessionID into
consideration when I try to distinguish these responses. So my CSeq matching
table on Proxy is as following. 
-------------------------------------------
TCP SID  |  CSeq  |  Client info.
-------------------------------------------
Proxy can work in this way, however RTSP relies too much on transport
protocol in this case.

Regards

Yingjie Gu

> -----Original Message-----
> From: Jaehwan Kim [mailto:[email-masked]] 
> Sent: Thursday, September 10, 2009 8:46 AM
> To: Magnus Westerlund
> Cc: [email-masked]; [email-masked]; Y.J. Gu
> Subject: RE: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.
> 
> Hi Magnus,
> Yingjie is trying to implement aggregated RTSP sessions in 
> the same TCP session between Proxy and Server.
> 
> Regards,
> Jaehwan
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Y.J. Gu
> Sent: Tuesday, September 08, 2009 11:18 AM
> To: 'Magnus Westerlund'
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.
> 
> Thank you for your explanation.
> This is an excellent draft, I did not mean to question it. 
> Just because I'm in the implementation of an RTSP proxy, I 
> found that Cseq text is ambiguous when considering proxy.  
> 
> The first paragraph of your post has made the issue very clear. 
> There are still some implementations in which proxy may set 
> up several RTSP sessions, with a particular server, for 
> several clients, in order to be compatible to servers who 
> check clients' IP Adds before replying.  So an added 
> indication, "to a particular server", will help people to 
> understand the text without confused.
> 
> I.e. " For each new RTSP request to a particular server, 
> either in one or several RTSP sessions of the same 
> client/proxy, the CSeq value MUST be incremented by one." 
> This is a coarse example.
> 
> An illustration, especially for proxy, also helps people to 
> get the meaning at a first glance.
> 
> 
>  
> Regards
> 
> Yingjie Gu
> 
>  
> 
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:[email-masked]]
> > Sent: Monday, September 07, 2009 10:22 PM
> > To: Y.J. Gu
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need 
> clarification.
> > 
> > Hi,
> > 
> > The intention in this case was 1). That the proxy will have 
> to ensure 
> > that the requests is sends towards a particular server has a joint 
> > sequence number space.
> > 
> > Because there are no strong indication to the server that different 
> > requests are from different clients. Especially as a proxy may 
> > actually send only have a single RTSP session with the 
> server despite 
> > serving multiple clients.
> > 
> > Do you have a proposal for how to make the text clearer?
> > 
> > Cheers
> > 
> > Magnus
> > 
> > Best Regards.
> > 
> > Y.J. Gu skrev:
> > >  In RFC2326bis-22
> > >  16.19.  CSeq
> > >  
> > >    The CSeq general-header field specifies the sequence
> > number for an
> > >    RTSP request-response pair.  This field MUST be present in all
> > >    requests and responses.  For every RTSP request
> > containing the given
> > >    sequence number, the corresponding response will have the same
> > >    number.  Any retransmitted request MUST contain the 
> same sequence
> > >    number as the original (i.e. the sequence number is not
> > incremented
> > >    for retransmissions of the same request).  For each new
> > RTSP request
> > >    the CSeq value MUST be incremented by one.  The 
> initial sequence
> > >    number MAY be any number, however it is RECOMMENDED to
> > start at 0.
> > >    Each sequence number series is unique between each 
> requester and
> > >    responder, i.e. the client has one series for its
> > request to a server
> > >    and the server has another when sending request to the
> > client.  Each
> > >    requester and responder is identified with its network address.
> > >  
> > >    Proxies that aggregate several sessions on the same
> > transport will
> > >    regularly need to renumber the CSeq header field in 
> requests and
> > >    responses to fulfill the rules for the header.
> > >  
> > > I am not very clear about the colored words.
> > >  For each new RTSP request
> > >    the CSeq value MUST be incremented by one. 
> > > When Proxy aggregate serveral sessions, it can be understanded in 
> > > different way:
> > > 1) Without regard of different sessions, proxy increase 
> the CSeq by 
> > > one for each request it transmits.
> > >      +-----+           +-----------+                        
> >           
> > > +----------+
> > >       | C1  | ---------|   proxy   |      C1 setup, CSeq=1  
> > |  server  |
> > >      +-----+          /+-----------+    C1 play,   CSeq=2 
> > +----------+
> > >                         /                          C2 
> setup, CSeq=3 
> > >      +-----+    /                              C1 pause, CSeq=4
> > >       | C2  |  /
> > >      +-----+
> > > 2) CSeq is incremented by one for each request of a
> > particular session. 
> > >      +-----+           +-----------+                        
> >           
> > > +----------+
> > >       | C1  | ---------|   proxy   |      C1 setup, CSeq=1  
> > |  server  |
> > >      +-----+          /+-----------+    C1 play,   CSeq=2 
> > +----------+
> > >                         /                          C2 
> > setup, CSeq=101
> > >      +-----+    /                              C1 pause, CSeq=3
> > >       | C2  |  /                                 C2 play, 
>   CSeq=102
> > >      +-----+
> > > I guess it should be 2), but I am not sure, 'cause there can be 
> > > various explanations.
> > > Each sequence number series is unique between each requester and
> > >    responder, i.e. the client has one series for its
> > request to a server
> > >    and the server has another when sending request to the client.
> > > What does unique mean? Are {0,1,2,3} and {1,2,3,4} unique, or 
> > > {0,1,2,3} and {101,102,103,104} unique?
> > >  
> > > 
> > > 
> > > 
> > 
> ----------------------------------------------------------------------
> > > --
> > > 
> > > _______________________________________________
> > > mmusic mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mmusic
> > 
> > 
> > --
> > 
> > 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: [email-masked]
> > --------------------------------------------------------------
> > --------
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Joe Pallas <[email-masked]>
Date: Thu, 10 Sep 2009 16:28:30 -0700

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.
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.

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?

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.

joe

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Sep 2009 14:48:53 +0200

Hi Joe,

Joe Pallas skrev:
> 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:

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

> 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