[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.
Magnus,
I also agree that the intention is for number 1.
I thought that the proxy will have separate sessions for each client based
on
section 16.47:
"However, multiple "user" sessions for the same URI from the same client
will require use of different session identifiers.
The session identifier is needed to distinguish several delivery
requests for the same URI coming from the same client.
"
Do you think that we should try to make this text stronger
Roni Even
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of Magnus Westerlund
> Sent: Monday, September 07, 2009 5: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