Subject: [MMUSIC] RTSP 2.0: [ 1701558 ] Pause response to live streams

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Oct 2007 11:32:41 +0200

Xavier asked more than a year ago the following question:

"when a client sends a PAUSE request for a live content,
which value is sent back in the Range header by the server?"

This is in regards to the following text from section 11.5 Pause on page
63 in draft version 15:

  "The pause point after any PAUSE request SHALL be returned to the
   client by adding a Range header with what remains unplayed of the
   PLAY request's ranges, i.e. including all the remaining ranges part
   of multiple range specification.  If one desires to resume playing a
   ranged request, one simply includes the Range header from the PAUSE
   response."

To me it should indicate the point the server is ceasing to deliver
media on. Also the live media have some time line. Either expressed in
UTC or in NPT since session start. What ever is used needs to be
reported. I don't think "now-" would be particular good answer. For that
reason a clearer text on this would be good.

However, this leads me to another issue related to the content being
played back. It might be time to be more explicit about the content
properties related to playback. I don't think the RTSP specification is
particular clear regarding how to handle the different playback
properties that exist. To my knowledge there are major 3 types of
content currently available.

A. On-demand content: Can be freely played from any point in time of the
content.

B. Live: Can only be played at the currently served point.

C. Live with recording: Where you can't play beyond what has been served
and which advances in real-time during the sessions progress. However,
the client can request to jump back in time, or pause for a while and
then resume at the playback point it was at, rather then the sessions
"now" point.

I think there are a few additional restrictions for the content type
that would need to be expressed to provide better support for how
content can be handled in the client. But that I think is for future
discussion.

However, my question is: Should we define a new SDP attribute that
expresses the contents major properties to allow RTSP clients to know
what to handle?

I know this means more work, however I believe it would make the general
text more clear when one can refer to this different behaviors in the
specification text.

For example to tie it back into the original question: By having these
attributes we could define more clearly when time-line times should be
used. And for example when "now-" is to be converted into the actual
time-line point in the session.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: "Mike Severa" <[email-masked]>
Date: Tue, 23 Oct 2007 08:09:12 -0700

I agree it would be good to be more explicit. I think this is
particularly important with something like 'live with recording' because
a PAUSE on such content should allow a client to behave differently upon
restarting (not with reposition) than for normal live (media data that
the streaming server has already sent, and thus is still in the
client-side jitter buffer, is still valid (contiguous in presentation
time), whereas in a 'true live' scenario that will not be the case). 
I also tend to believe that there is a 4th type of content and that is
On-Demand content with an unknown end-time. However, from the standpoint
of distinction from the other content types, its properties are likely
no different than live with recording (unknown end time but still
randomly accessible). 

Would the proposed new attribute also imply that the properties for
something like live vs On-Demand will no longer be distinguished by the
format of the range header? Or would the goal to be to try to add
something 'on top of' the current semantics?

Thanks,

Mike

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2007 2:33 AM
To: mmusic (E-mail); Xavier Marjou
Subject: [MMUSIC] RTSP 2.0: [ 1701558 ] Pause response to live streams

"when a client sends a PAUSE request for a live content, which value is
sent back in the Range header by the server?"

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Oct 2007 17:21:27 +0200

> no different than live with recording (unknown end time but still

Please consider if this fourth type really is having different
properties than live with recording. Now that you mention it I think
there is this other type of content where it could be dynamically
updated. Consider content that represents a playlist that is controlled
by some other protocol. That length could at any point in time be
changed. But I don't know if I really like to go there, because this
type of content has other implications.

> something 'on top of' the current semantics?

I would propose to be explicit, I think both in request and in SDP to
indicate what properties the content actually have. That way the most
correct Range format and usage can be applied without consideration for
carrying extra semantics.

cheers

Magnus Westerlund