|
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 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 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:jhkim at vidiator.com] Sent: Tuesday, August 11, 2009 7:48 PM To: Y.J. Gu; mmusic at ietf.org 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:
mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of
Y.J. Gu 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. The
interactive messages are listed as following. Session
issued by Client A:
P->S: SETUP rtsp://live.example.com/concert/audio
RTSP/2.0 Session
issued by Client A:
S->P: RTSP/2.0 200 OK 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 |