Hi!I'm just skimming through the spec and didn't find any reference to some functionality I hope that is not forbidden and requires the usage of reference numbers (i.e. CSeq):
In our case of a RTSP server, a 'client' will have one TCP connection that controls several RTSP sessions; Without such reference numbers, this client would have to serialize all requests and wait for each response until it may proceed with any next request. When 20 sessions need to be created and for some reason the 10th resource needs some time to be set up, having a reference number this one doesn't affect the others since the responses can come back in any order and are properly assigned to the original requests. In some of our cases having the client open up a dedicated TCP connection per RTSP session is not an option (the client being a small embedded host). By the way, this would then also nullify the reason for having session identifiers at all.
I may have missed the point of your discussion whether a CSeq is useful or not [with only one session], but I don't see how to handle several sessions between one client and one server without.
Regards, ch Rémi Denis-Courmont wrote:
Le mardi 2 décembre 2008 11:01:55 Magnus Westerlund, vous avez écrit :But is it doing anything useful? HTTP proxies function perfectly well without any equivalent. The rules for RTSP pipelining are the same as non-pipelined requests: that responses must be delivered in the same order as requests, so there is nothing that the CSeq field adds. I think there is a strong case to be made that CSeq only ever made sense for unreliable transports, and there is no value that it adds for reliable transports. While it does not do much harm, it really seems to be unnecessary.I agree that the header is not necessary for the functioning of the protocol. I think the main argument for keeping it is debugging and handling error cases, like lost message boundaries requiring resynchronization of the message flow.If message boundaries are "broken", only one of the fragment will contain CSeq, so it's hardly of any help.Please do remember that TCP is not guaranteed free from errors.I don't understand this argument at all. If a TCP session suffers packet loss (whether it's recovered or not) or re-ordering, the applications layer will NOT see it, so CSeq does not help in any meaningful way. HTTP does not have CSeq, yet we have no problem debugging it.As for packet captures, we have the TCP sequence number already. Wireshark has long since learnt how to re-assemble TCP.
_______________________________________________ mmusic mailing list mmusic at ietf.org https://www.ietf.org/mailman/listinfo/mmusic