Subject: RTSP question.

From: Ethendra Bommaiah <[email-masked]>
Date: 3 May 2001 17:10:50 PDT

Can/Should the RTSP server send RTP-Info (with RTP timestamp and sequence
number info) in the response for every PLAY request as and when it
receives the request (with pipelining, for example) ? This would mean that
the server would use the RTP timestamp and sequence number from its
RTP-Info response whenever it starts streaming data for a new PLAY
request. In this case, RTP timestamps and RTP sequence numbers will not be
continuous across jumps of NPT as required in appendix B of RFC 2326.

In appendix B, it is also stated that the RTSP client and media agent need
not communicate with each other -- in this case, it seems to me that
RTP-Info has no significance. If RTP-Info header is not sent, how does the
client know the beginning of a Range in case of pipelined PLAY requests ?

In light of the above, what is the significance of the RTP-Info header ?

Thanks,
Ethen

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

---

From: Jonathan Sergent <[email-masked]>
Date: Thu, 03 May 2001 17:59:27 -0700

/// Ethendra Bommaiah <[email-masked]>:
 ] Can/Should the RTSP server send RTP-Info (with RTP timestamp and sequence
 ] number info) in the response for every PLAY request as and when it
 ] receives the request (with pipelining, for example) ? This would mean that
 ] the server would use the RTP timestamp and sequence number from its
 ] RTP-Info response whenever it starts streaming data for a new PLAY
 ] request. In this case, RTP timestamps and RTP sequence numbers will not be
 ] continuous across jumps of NPT as required in appendix B of RFC 2326.

The only way you can implement the spec as is is if the server is smart
enough to know at PLAY response time what the sequence number and
timestamp of the first packet it will send is.  Timestamp should not be
too hard to calculate, since you know the NPT time when the current
PLAY will end, the current NPT time, the current RTP time, and how to
convert from NPT to RTP.  But determining the sequence number of the
first packet to be sent is clearly not possible (or very expensive) in
some cases.

My recollection is that this was identified as a problem at the RTSP
bakeoff.  At that point I don't believe anyone had implemented the
protocol feature in question.

 ] In appendix B, it is also stated that the RTSP client and media agent need
 ] not communicate with each other -- in this case, it seems to me that
 ] RTP-Info has no significance. If RTP-Info header is not sent, how does the
 ] client know the beginning of a Range in case of pipelined PLAY requests ?

RTP-Info is only useful for integrated RTSP/RTP clients, so you can't
if they aren't communicating.  The client needs it to map RTP
timestamps to NPT (including the jump in NPT that happens during a
seek) for things like user interface controls.  You might want accurate
determination of pre-seek and post-seek packets for some payload
types.  You can't do this with RTSP if you have separate RTSP and RTP
clients.

There's a payload under development (Harrison, "RTP Payload Format for
Timing Information Stream (TIS)"; see message sent to the AVT alias in
March) for sending timing information streams as separate RTP packets.
This would seem to address the problem in yet another way.

-- 
Jonathan Sergent / [email-masked]