[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
----------------------------------------------------------------------