Subject: Re: [MMUSIC] Question about RTSP proxy

From: "Y.J. Gu" <[email-masked]>
Date: Thu, 13 Aug 2009 10:20:18 +0800

I would like to compose a draft, in order to clarify the problem clearly. I
feel that there might be other scenarios that we haven't noticed.

Regards

Yingjie Gu

  _____  

From: Jaehwan Kim [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2009 6:13 PM
To: Y.J. Gu; [email-masked]
Subject: RE: [MMUSIC] Question about RTSP proxy

Hi Yingjie,

It looks that the current 2326bis specification is not crystal clear to this
problem although we have a workaround. Then, we might introduce an
identifier which is only used between proxy and server. Probably this is why
a proprietary RTSP solution requires client driven Session ID from Describe
which is not allowed in the current specification. 

And two different servers mean two different TCP sessions. When I consider
non-permanent connection case, it is still no issue. Therefore, this issue
could be limited only to the case you use one TCP connection for two
different RTSP sessions for the same resource but this is not common(case
2/). Or maybe you could provide some usecases?

Regards,

Jaehwan

From: Y.J. Gu [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2009 3:34 PM
To: Jaehwan Kim; [email-masked]
Subject: RE: [MMUSIC] Question about RTSP proxy

Hi Jaehwan

well, for the above 2 examples, I am considering the second case. Two
requests/responses on one TCP connection.

By the latest above example, I meant when the two SETUP requests for same
resource transmitted through one TCP connection, server will have difficult
to differentiate them. 

By the example in my first email, I meant when two responses sent by one
server through one TCP connection to Proxy, Proxy 

may have difficult to differentiate them.

Surely, RTSP proxy, when implemented, can handle the problem by compromised
solutions, e.g. CSeq. While proxy has to guarantee to generate different
initial CSeq for each session by, e.g. ,comparing the current CSeq with
those generated before. How many concurrent sessions can a proxy support,
maybe 10000, then comparing CSeq would be a huge burden, because that will
be a large order of magnitude. 

Here is another assumption. Proxy send 2 RTSP requests to 2 servers, but,
unfortunately,  the 2 servers response the same session ID, by what mean
will the proxy handle the following messages of the 2 sessions?  Maybe take
session ID and TCP connection together into consideration. Proxy has to do
this every time it receive a message from the servers. That will be a huge
workload. Besides, that will tie RTSP closely toTransport protocol, however
RTSP 2.0 is in no way tied to a Transport protocol according to RFC2326.

Basically, I think the existing solutions to proxy can work but are very
much compromised and result in complexity. We should find a easy and  clear
way to resolve the problem.  

BTW,Multicast is just an example, the problem doesn't limit to multicast.

 

Regards

Yingjie Gu

  _____  

From: Jaehwan Kim [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2009 1:09 PM
To: Y.J. Gu; [email-masked]
Subject: RE: [MMUSIC] Question about RTSP proxy

Hi Yingjie,

On P<->S side, there would be two cases:

1/ using two different TCP sessions(typical case): Although the same cseq is
found, Proxy should be able to handle different TCP sessions. And Proxy
should map two different Client requests with these.

2/ using just one TCP session for two different RTSP sessions: Simple
solution is to manage cseq well because proxy assign the value.

Which one do you consider?

And you may consider also non-permanent connection case, but still proxy
could manage them and deliver Session ID generated from the server from my
understanding.

Anyway it looks not multicast issue. And there are already many
off-the-shelf RTSP proxy handle this matter without any problem.

Regards,

Jaehwan

---

From: "Y.J. Gu" <[email-masked]>
Date: Thu, 20 Aug 2009 11:58:10 +0800

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?