[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.
Thanks Jaehwan.
Here is my implementation. In order to be compatible to those servers who
may maintain session states and check client IP Add, I did not set up single
RTSP to server multiple clients.
Insead, e.g., Proxy set up 2 TCP connections with 2 servers, each TCP
connection carries aggregate RTSP sessions with sequent CSeq series start
with 0.
During implementation, I find that Proxy will receives responses with same
Cseq from these 2 servers. So I have to take TCP sessionID into
consideration when I try to distinguish these responses. So my CSeq matching
table on Proxy is as following.
-------------------------------------------
TCP SID | CSeq | Client info.
-------------------------------------------
Proxy can work in this way, however RTSP relies too much on transport
protocol in this case.
Regards
Yingjie Gu
> -----Original Message-----
> From: Jaehwan Kim [mailto:jhkim at vidiator.com]
> Sent: Thursday, September 10, 2009 8:46 AM
> To: Magnus Westerlund
> Cc: schulzrinne at cs.columbia.edu; mmusic at ietf.org; Y.J. Gu
> Subject: RE: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.
>
> Hi Magnus,
> Yingjie is trying to implement aggregated RTSP sessions in
> the same TCP session between Proxy and Server.
>
> Regards,
> Jaehwan
>
> -----Original Message-----
> From: mmusic-bounces at ietf.org
> [mailto:mmusic-bounces at ietf.org] On Behalf Of Y.J. Gu
> Sent: Tuesday, September 08, 2009 11:18 AM
> To: 'Magnus Westerlund'
> Cc: schulzrinne at cs.columbia.edu; mmusic at ietf.org
> Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.
>
> 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:magnus.westerlund at ericsson.com]
> > Sent: Monday, September 07, 2009 10:22 PM
> > To: Y.J. Gu
> > Cc: schulzrinne at cs.columbia.edu; mmusic at ietf.org
> > 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.
> >
> > 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
> > > mmusic at ietf.org
> > > 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: magnus.westerlund at ericsson.com
> > --------------------------------------------------------------
> > --------
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic