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:guyingjie at huawei.com]
Sent: Wednesday, August 12, 2009
3:34 PM
To: Jaehwan Kim; mmusic at ietf.org
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:jhkim at vidiator.com]
Sent: Wednesday, August 12,
2009 1:09 PM
To: Y.J. Gu; mmusic at ietf.org
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