Subject: Re: [MMUSIC] Question about RTSP proxy

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 12 Aug 2009 12:02:25 +0800

Hi Jaehwan,
RTSP may try to match CSeqs in (P->S) and (S->P) messages to differentiate,
but CSeq is used to arrange messages, changing CSeq's semantics may be
confusing. Besides, Proxy may generate a same CSeq for different requests,
then matching CSeq is not feasible in this scenario.  
Below is another example, in which server may not works correctly.
RTSP proxy receives two requests from different clients to the same resource
on one server.
 
   +----------+                      +--------------+          +--------+ 
   | Client A |                      | RTSP proxy |           | Server |
   +----------+                      +--------------+          +--------+
        |                                             |
|
        |    +----------+                       |
|
        |    | Client B |                        |
|
        |    +----------+                       |
|
        |         |                                   |
|
        |         |    Setup                      |
| 
        |==================>|                               |
        |         |                                   |
|
        |         |                                   |      Setup
|
        |         |                                   |============>|\
        |         |                                   |
| \ 
        |         |    Setup                      |
|  \  ???
        |         |****************>|                                |  /
what's difference?
        |         |                                   |      Setup
| /
        |         |                                   |**************>|/
        |         |                                   |
|

   The interactive messages of the above scenario is as following.
 
   Session issued by Client A:
 
   C->P: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 111
         Transport: RTP/AVP;multicast 

   P->S: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 333
         Transport: RTP/AVP;multicast

   Session issued by Client B:
   C->P: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 222
         Transport: RTP/AVP;multicast

   P->S: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 444

         Transport: RTP/AVP;multicast

Typically, RTSP server differentiates sessions by client IP address and
client port. But in this case, there is only one transport connection
bewteen RTSP proxy and RTSP server, so server can not find the difference
between the two requests. As a result, server regards them as the same
repeated request and I don't know how this abnormity will be dealed in RTSP
2.0.  
Maybe, server can differentiate by CSeq also, but there introduce at least
two matters.
1) proxy has to guarantee no repeated initial CSeq is generated
2) things become complicated when different proxy generate same CSeq, server
has to check both the IP/Port and CSeq in order to differentiate.

Regards

Yingjie Gu

  _____  

From: Jaehwan Kim [mailto:[email-masked]] 
Sent: Tuesday, August 11, 2009 7:48 PM
To: Y.J. Gu; [email-masked]
Subject: RE: [MMUSIC] Question about RTSP proxy

Hi,

I think Proxy should handle different CSeq on Server side, while it can do
different TCP sessions on Client side.

Regards,

Jaehwan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Y.J. Gu
Sent: Tuesday, August 11, 2009 3:04 PM
To: [email-masked]
Subject: [MMUSIC] Question about RTSP proxy

Hi all,

In RTSP 2.0, it is permitted to transmit several client requests in one
Transport Connection. 

I think this may introduce new problems when RTSP proxy is intervened, and
existing RTSP can not deal with the scenario correctly.

The following is an example. To display the figure correctly, please
maximize this email window.

   Suppose that client A and client B wants to join different multicast
groups on the same server.
   +----------+                      +--------------+
+--------+ 
   | Client A |                       | RTSP proxy|
| Server |
   +----------+                      +--------------+
+--------+
        |                                              |
|
        |    +----------+                        |
|
        |    | Client B |                         |
|
        |    +----------+                        |
|
        |         |                                    |
|
        |         |    Setup                       |
| 
        |==================>  |
|
        |         |                                    |
|
        |         |                                    |      Setup
|
        |         |
|====================> |
        |         |                                    |
|  
        |         |    Setup                       |
|
        |         |*****************>|
|
        |         |                                   |      Setup
|
        |         |
|************************> |
        |         |                                   |
|
        |         |                                   |
|
        |         |
|<=====================|
        |         |                                   | 200 OK
(SessionID=12345678)|
        |         |
|<************************ |
        |         |                                   | 200 OK
(SessionID=23456789)| 
        |         |                    ?????????|
|
        |         |                                   |
|

                          Fig.2  Multicast 

   The interactive messages are listed as following.

   Session issued by Client A:
   C->P: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 111
         Transport: RTP/AVP;multicast

   P->S: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
         CSeq: 333
         Transport: RTP/AVP;multicast

   Session issued by Client A:
   C->P: SETUP rtsp://live.example.com/anotherconcert/audio RTSP/2.0
         CSeq: 222
         Transport: RTP/AVP;multicast
   P->S: SETUP rtsp://live.example.com/anotherconcert/audio RTSP/2.0
         CSeq: 444
         Transport: RTP/AVP;multicast

   Proxy will receive the following responses from server:
   S->P: RTSP/2.0 200 OK
         CSeq: 333
         Server: PhonyServer/1.0
         Date: Thu, 23 Jan 2009 15:35:06 GMT
         Transport: RTP/AVP;multicast;
              dest_addr="224.2.0.1:3456"/"224.2.0.1:3457";ttl=16
         Session: 12345678

   S->P: RTSP/2.0 200 OK
         CSeq: 444
         Server: PhonyServer/1.0
         Date: Thu, 23 Jan 2009 15:35:06 GMT
         Transport: RTP/AVP;multicast;
              dest_addr="224.2.0.2:1234"/"224.2.0.2:1235";ttl=16
         Session: 23456789

In this case, RTSP proxy can not distinguish the responses, then it may
respond client with wrong message and induce client to join a wrong
mutlicast group. 

Do anybody think this is an possible trap/deficiency, and RTSP should try to
resolve?

Thanks.

Regards

Yingjie Gu

---

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 12 Aug 2009 14:33:34 +0800

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: Wed, 12 Aug 2009 16:09:13 +0800

Hi Remi, see in line please.

Regards

Yingjie Gu

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Wednesday, August 12, 2009 2:50 PM
> To: Y.J. Gu
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Question about RTSP proxy
> 
> 
>     Hello,
> 
> On Tue, 11 Aug 2009 14:04:20 +0800, "Y.J. Gu" 
> <[email-masked]> wrote:
> > In RTSP 2.0, it is permitted to transmit several client requests in 
> > one Transport Connection.
> > I think this may introduce new problems when RTSP proxy is 
> intervened,
> and
> I fail to see why.
> >    Suppose that client A and client B wants to join different 
> > multicast groups on the same server.
> (...) 
> > In this case, RTSP proxy can not distinguish the responses, then it 
> > may respond client with wrong message and induce client to join a 
> > wrong mutlicast group.
> 
> The RTSP proxy can (and in fact probably MUST) pair requests 
> and responses from the CSeq and/or from the ordering. As far 
> as I know, the RTSP server must send responses in the same 
> order as it receives requests (although it may interleave 
> some server-to-client requests).

If I understand correctly, you mean if RTSP proxy send Request A earlier
than Request B, then server must response A earlier than B. By this order,
RTSP proxy can pair the requests&responses. 
But what if server receive B earlier than A when traffic congest. Server
will response B earlier than A.

> Besides, I fail to see how this would be specific to multicast.

Yes, Multicast is an example, it is not specific to multicast. 

> --
> Rémi Denis-Courmont