[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt
Hi Christian,
The sessionId might be helpful for multiple sessions (Section 4.3. Session Identifiers). To pipeline multiple requests you can use the pipelining (Section 12. Pipelining Support).
Martin
stiemerling at nw.neclab.eu
NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of Christian Haas
> Sent: Monday, December 08, 2008 9:26 AM
> To: mmusic at ietf.org
> Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt
>
> 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
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic