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

["Y.J. Gu" <guyingjie at huawei.com>]

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:magnus.westerlund at ericsson.com] 
> Sent: Monday, September 07, 2009 10:22 PM
> To: Y.J. Gu
> Cc: schulzrinne at cs.columbia.edu; mmusic at ietf.org
> 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
> > mmusic at ietf.org
> > 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: magnus.westerlund at ericsson.com
> --------------------------------------------------------------
> --------