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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Sep 2009 16:21:56 +0200

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

---

From: "Y.J. Gu" <[email-masked]>
Date: Tue, 08 Sep 2009 10:18:11 +0800

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.
> 
> > 1) Without regard of different sessions, proxy increase the CSeq by 
> > one for each request it transmits.
> >      +-----+           +-----------+                        
>           
> > +----------+
> >                         /                          C2 
> setup, CSeq=101 
> > I guess it should be 2), but I am not sure, 'cause there can be 
> > various explanations.
> > 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?
> >  
> > 
> > 
> >

---

From: "Roni Even" <[email-masked]>
Date: Tue, 15 Sep 2009 09:51:14 +0300

Magnus,
I also agree that the intention is for number 1.
I thought that the proxy will have separate sessions for each client based
on
section 16.47:
"However, multiple "user" sessions for the same URI from the same client
will require use of different session identifiers.
      The session identifier is needed to distinguish several delivery
      requests for the same URI coming from the same client.
"
Do you think that we should try to make this text stronger

Roni Even

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Monday, September 07, 2009 5:22 PM
> To: Y.J. Gu
> Each
> various

---

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

> Do you think that we should try to make this text stronger

RTSP sessions and TCP connections are not the same.

I think this confusions comes from that the information is spread out in
multiple places. For example the text in 10.2 is relevant:

>    A persistent connection is RECOMMENDED to be used for all
>    transactions between the server and client, including messages for
>    multiple RTSP sessions.  However, a persistent connection MAY be
>    closed after a few message exchanges.  For example, a client may use
>    a persistent connection for the initial SETUP and PLAY message
>    exchanges in a session and then close the connection.  Later, when
>    the client wishes to send a new request, such as a PAUSE for the
>    session, a new connection would be opened.  This connection may
>    either be transient or persistent.
> 
>    An RTSP agent SHOULD NOT have more than one connection to the server
>    at any given point.  If a client or proxy handles multiple RTSP
>    sessions on the same server, it SHOULD use only one connection for
>    managing those sessions.
> 
>       This saves connection resources on the server.  It also reduces
>       complexity by and enabling the server to maintain less state about
>       its sessions and connections.

It might be that we should expand on the Proxies chapter to discuss
aggregation of RTSP sessions from multiple client in that context.

Cheers

Magnus Westerlund