Subject: [MMUSIC] RTP TS/SN NPT rehash

From: "Mike Severa" <[email-masked]>
Date: Mon, 15 Sep 2008 18:22:53 -0700

Hi. First off, let me apologize if this was already clarified.. I havent
been able to find another thread that clarified this.. 
 
In this archived message
http://osdir.com/ml/ietf.mmusic/2003-05/msg00048.html there is a
comment:
 
RTP spec is very clear about how time stamps should increase within a
session. Since the same RTP session is still being used after PAUSE
(i.e. it has the same SSRC and unique end-points) and RTP says that
timestamps as well as sequence numbers should increase monotonically and
linearly with respect to realtime 
 
My first question is how do sequence numbers increase linearly with
respect to time when even during streaming their "rate" will be
dependent on access unit size, and not real time?  In addition, RFC 3550
(5.1) says in its definition of sequence number: "The sequence number
increments by one for each RTP packet sent".  This text seems to imply
that SN will not increase if the session happens to be paused (unlike
the TS).  There are even examples in the RTSP spec showing the sequence
number not increasing during pause.  
 
Since the thread above seems to have been the consensus in the group
related to RTP header information as it relates to paused sessions, can
someone clarify whether quoted comment may have unintentionally included
SN in group of things that increase in this way, or maybe whether there
is other text in the RFC that specifies a different behavior for
sequence numbers that is being reflected by this comment?  
 
In addition, in 2326bis there is a sentence in C.2.3: "Thus, both RTP
sequence numbers and RTP timestamps MUST be continuous and monotonic
across jumps of NPT.".  While the context of this sentence is describing
behavior in light of jumps in the media layer NPT as a result of
something like multiple NPT values in a PLAY request's Range header, it
seems like this sentence contradicts an implication that was also made
in the thread above as it applies to live data, although its not
entirely clear given that a live-specific example wasnt given.
Specifically, one of the other messages in that thread implied that one
difference between VOD and live was that a client pausing the RTSP
session will pause NPT for VOD, however it will not pause NPT for live
(the live session continues to exist irrespective of the RTSP client's
behavior). If a client were to issue a PAUSE on a live session, it seems
the Range header in the PLAY response to resume should indicate a jump
in NPT. It is clear from the above thread that the timestamps cannot be
monotonic in this case (that was the whole point of that thread, if I'm
not mistaken), and if so, wouldnt that contradict the sentence in
2326bis? At a minimum it seems sequence numbers and timestamps shouldnt
be treated the same way here unless there is a field-specific meaning of
"continuous and monotonic"..   Perhaps some simple context clarification
could fix this? 
 
I think adding a live pause example to 2326bis C.2.4 would be helpful
(including description of TS, SN and NPT). It may even be necessary to
clarify whether any servers that allow sequence number to increase for
paused live data are in fact non-compliant (seems so based on 3550), or
whether behavior in live cases is ambiguous enough (eg. what does PAUSE
really mean for live content?) to maybe allow this to occur. 
 
thanks,
 
Mike

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Sep 2008 13:31:00 +0200

Mike Severa skrev:
> In this archived 
> message http://osdir.com/ml/ietf.mmusic/2003-05/msg00048.html there is a 
> comment:
>  
> timestamps *as well as sequence numbers* should increase monotonically 
> and linearly with respect to realtime.
>  

I think you are over interpreting that quote. The timestamp will 
increase lineraly in respect to real-time. The sequence number will 
increase monotonically, for each RTP data packet sent.

> sequence numbers that is being reflected by this comment? 

Yes, SN was unintentionally included in the linear part.

> "continuous and monotonic"..   Perhaps some simple context clarification 

I don't see what the issue is. It might be that we are not clear in the 
text in C.2.3 to which scale we are continous and monotonic, it is the 
world time and not NPT. So in your live example when the NPT jumps 
forward when resuming the playback as indicated in the PLAY response a 
new media (NPT) to RTP timestamp synchronization is established. The 
fact that it actually is likely to match the previouos one (unless clock 
drift has been indicated) is not an issue.

> really mean for live content?) to maybe allow this to occur.

It seems to me that the only real issue that you do bring up is the RTP 
sequence number increase that happens if one simply forwards the 
packets. I think this needs more discussion and I will log a bug in the 
tracker.

Cheers

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: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Mike Severa" <[email-masked]>
Date: Tue, 23 Sep 2008 07:55:50 -0700

Thanks for the responses, my primary concern was that while TS behavior
was fairly clearly defined, SN behavior still seemed somewhat ambiguous.
It appears there will be an attempt to clarify that.
 
thanks,
 
Mike

________________________________

From: Jaehwan Kim [mailto:[email-masked]] 
Sent: Sunday, September 21, 2008 11:11 PM
To: Mike Severa
Cc: [email-masked]
Subject: RE: [MMUSIC] RTP TS/SN NPT rehash

Hi,

I think most of answers were already made by Magnus.

I just want to ask one thing.

When you talk about live PAUSE, did you consider RTP-Info?

BTW, I hope you consider below as well.

1)      RTP timestamp should reflect realtime. So, ideally just put the
current server time into header looks ok regardless of media timestamp.

2)      We assume that RTP layer is independent from RTSP layer.

Regards,

Jaehwan