Re: [MMUSIC] RTP TS/SN NPT rehash

["Mike Severa" <Mike.Severa at alcatel-lucent.com>]

Thanks Magnus, this is definitely clearer. 

Two comments (just comments, not implications that anything should change):
- this will make simply forwarding of live content (and supporting pause) not possible without modification of the RTP header (SN) on a client by client basis. Probably not a common use case though, and not unreasonable to assume supporting pause in such a case should imply some work.
- regarding congestion control impact of allowing SNs to jump, since RTP-Info unambiguously states where SN will resume, even if RTCP reported losses they would always be implied to have happened back at pause time and feedback for congestion control that has that kind of delay shouldn't be useful to a server. However, treating the RTSP and RTP layers independently means reliance on something like RTP-Info knowledge may not be possible for the RTP source.

Regardless, I agree that this text is more in-line with what is implied by 3550 and is now clear wrt SN behavior. Thanks for the clarification.

Mike

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com] 
Sent: Thursday, October 16, 2008 6:24 AM
To: Mike Severa
Cc: Jaehwan Kim; mmusic at ietf.org
Subject: Re: [MMUSIC] RTP TS/SN NPT rehash

Hi,

I have now edited the text around this. I have expanded it quite significantly as it was a bit unclear. After some thinking I think we should stick even in live cases with RTP sequence number that increase by one across the pause duration. The reason is after all the impact on RTP and RTCP. So suggested text is the below one. I haven't added any more example.


C.2.3.  Handling Media Clock Time Jumps in the RTP Media Layer

   RTSP allows media clients to control selected, non-contiguous
   sections of media presentations, rendering those streams with an RTP
   media layer[RFC3550].  Such control allows jumps to be created in
   media clock (e.g.  NPT) timeline of the RTSP session.  The simple
   case of jumps in media clock time is caused by multiple ranges in the
   range specifier of a PLAY request.  This allows the media layer
   rendering the RTP stream without being affected by jumps in media
   clock time.  The RTP timestamps for the next media segment is set so
   that they become continuous with the previous media segment in the
   request.  The RTP sequence number for the first packet in the new
   segment will be the next following the last packet in the previous
   segment, i.e. monotonically increasing.  The goal is to allow the
   media rendering layer to work without interruption or reconfiguration
   across the jumps in media clock.  This should be possible in all
   cases of multiple ranges in a PLAY request for media that has random-
   access properties.  It is also possible when one PLAY request



Schulzrinne, et al.      Expires April 19, 2009               [Page 214]

Internet-Draft   Real Time Streaming Protocol 2.0 (RTSP)    October 2008


   replaces another ongoing for media with random-access properties.  In
   both cases care to align frames or similar media dependent structures
   are need but likely possible.

   In cases where jumps in media clock time are a result of RTSP
   signalling operations arriving during or after an PLAY operation, the
   processing delay or request timing can result in that media becomes
   non-continuous.  The server becomes unable to send the media so that
   it arrive timely and still carry timestamps to make the media stream
   continuous.  In these cases the server will produce RTP streams where
   there are gaps in the RTP timeline for the media.  In such cases, if
   the media has frame structure, aligning the timestamp for the next
   frame with the previous structure reduces the burden to render this
   media.  The gap should represent the time the server hasn't been
   serving media, e.g. the time between the end of the media stream or a
   PAUSE request and the new PLAY request.  In these cases the RTP
   sequence number would normally be monotonically increasing across the
   gap.

   For RTSP sessions with media that lacks random access properties,
   like live streams, any media clock jump is commonly result of
   correspondingly long pause of delivery.  The RTP timestamp will have
   increased in direct proportion to the duration of the paused
   delivery.  Not also that in this case the RTP sequence number should
   be the next packet number.  If not, the RTCP packet loss reporting
   will indicate as loss all packets not received between the point of
   pausing and later resuming.  This may trigger congestion avoidance
   mechanisms.

   The goal when handling jumps in media clock time is that the provided
   stream is continuous without gaps in RTP timestamp or sequence
   number.  However, when delivery has been halted for some reason the
   RTP timestamp when resuming SHALL represent the duration the delivery
   was halted.  RTP sequence number MUST be the next number.  A client
   can not rely on that a server will align when resuming playing even
   if it is RECOMMENDED.  The RTP-Info header will provide information
   if this have occurred or not.


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic