Subject: Re: [MMUSIC] RTSP discussion today

From: Geetha Srikantan <[email-masked]>
Date: Wed, 16 Jul 2003 02:45:19 -0700 (PDT)

hi Magnus,

I have been thinking about how 'playlists' may be supported with RTSP/RTP.
Playlists are what one might use in an internet radio session for instance, 
pre-program a set of songs that are to be played out in sequence on the same
RTP session.
Would it be possible to discuss this topic at the meeting today?

From what I gather, there are multiple constraints on how playlists might work:
for instance, the RTP timescales between multiple consecutive streams on the
same RTP session cannot change, even thr the encoding rate and type can change - 
and is indicated by the Payload type of the RTP packets.

From RTSP - there are complications when PAUSE is issued.
If the RTP timestamps are allowed to advance while in a PAUSE state,
then let us look at the impact of this:

SETUP <stream a on RTP session 1>
SETUP <stream b on RTP session 1>
PLAY <stream a on RTP Session 1>
PLAY <stream b on RTP Session 1 after stream a's npt range is completed>

Now assume that a RTSP PAUSE is issued.
This PAUSE can occur at the time of playing stream a or stream b or
just at the point of switching from stream a to b. In the last case,
if timestamps are allowed to advance during PAUSE, it means all of
the packet timestamps need to be recalculated after the PAUSE point,
(as for other PAUSE cases) even though
the PLAY issued earlier would have used a different timestamp.
This seems very awkward.

I'm wondering if the decisions to allow RTP timestamps to advance during a
PAUSE is such a good idea, after all. The only motivation seemed to be that
this is the way it worked for conferencing. However the RTSP spec is relevant
to other applications too, so it would be desirable to have a spec that
defines a base-line, that is like a 'least common denominator'. After that
other specs can define what is to be done for specifc applications.
This seems to be the approach followed wrt Mute/Unmute. I would urge that
we revisit the discussion with RTP timestamps.

thanks
geetha

> Date: Wed, 16 Jul 2003 11:11:43 +0200
> X-Sybari-Space: 00000000 00000000 00000000 00000000
> From: Magnus Westerlund <[email-masked]>
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) 
Gecko/20030624 Netscape/7.1 (ax)
> X-Accept-Language: en-us, en
> To: [email-masked]
> Content-Transfer-Encoding: 7bit
> Content-Transfer-Encoding: 7bit
> Subject: [MMUSIC] RTSP discussion today
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.12
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, 
<mailto:[email-masked]?subject=unsubscribe>
> List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, 
<mailto:[email-masked]?subject=subscribe>
> 
> Hi,
> 
> There where no room available at the conference center so we will have 
> to make this an ad-hoc. Please meet at 17.30 in the main foyer near the 
> registration desk. We will then go down to the riverside (5 min walk) 
> and have the discussion at one of the fast food places there. Based on 
> yesterdays sightings there will be rather plenty of room there. We will 
> continue until it is time to go to the IAB plenary.
> 
> Please don't be late, we will not wait long. Any person late can call me 
> on +46 70 211 48 44 for information on where we are.
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> A issue list for the discussions are:
> 
> RTSP discussions topics
> 
> RTSP & NAT
> 
> - Goals
> - Select solution
> - FW
> - ALGs
> 
> 
> RTSP Core
> 
>  - Session and control URL definitions
> 
>  - Proposal for detecting live streams via SDP 'range' attribute.  I
>    think Magnus will have an updated proposal since last week?
> 
>  - Possible methods for signalling end of stream in RTP (both RTP/RTCP
>    extensions and RTSP extensions are possibilities).
> 
>  - RTP extensions to make multibitrate files more cache-friendly.  The
>    most important piece of information that a proxy needs is a bitrate
>    field, but there are other issues as well.
> 
>  - Should REDIRECT automatically close session?
>  
>  - How to handle implicit redirection through session description protocol.
>    Majority favors allowing it per default.
> 
>  - How to detect the updated spec? Version number change 1.1 or 2.0, or
>    only use require and tag when necessary.
> 
>  - Request to Response timeout. The time a request takes until any 
> response is
>    received is not bound. Look at SIP solution?
> 
> RTSP MUTE/UNMUTE
> 
> - Need for it, revisit requirements advantages.
> 
> 
> RTSP stream switching
> 
> - Requirements
> 
> - Way forward?
> 
> RTSP TLS
> 
> -into main spec if small enough!
> 
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Jul 2003 11:57:30 +0200

Hi Geetha,

>Would it be possible to discuss this topic at the meeting today?

Sure, lets see how long we can come in the discussion.

Regarding playlists, why not treat it as a live station and use HTTP to 
program the station. It does not seem suitable to perform this type of 
control in RTSP without further extensions for media resource control.

>we revisit the discussion with RTP timestamps.

The REASON for having this clarification of the usage of RTP timestamps 
are RTP and RTCP itself. The RTCP based synchronization and reporting 
would be very confused if you did not have continuos timestamp space. IF 
you would go stop the RTP timestamp space during pause while RTCP keeps 
advancing it at the defined rate parts of the TS space will be reused 
and the RTCP synchronization information will be impossible to match 
against the RTSP synchronization information.

I know that people think this clarification creates some problems. 
However as having implemented this I know that it is not very many lines 
of code for the server. The client has only one significant problem 
which is to synchronize buffered data prior to pause with the data 
arriving after a pause. However this is a small practicality which have 
a solution.

Best Regards

Magnus

---

From: Tom Marshall <[email-masked]>
Date: Wed, 16 Jul 2003 04:29:05 -0700

> >Playlists are what one might use in an internet radio session for 
> >instance, pre-program a set of songs that are to be played out in sequence 
> >on the same
> >RTP session.

It seems to me there are two types of playlists: those created on the server
side (pre-set) and those created on the client side (dynamic).  Which are
you interested in?  I can see ways of supporting both today without any RTSP
or RTP extensions.

> against the RTSP synchronization information.

I have observed in conversations that opinions vary as to whether RTCP
should continue to be sent during the PAUSE period.  Perhaps this issue
deserves clarification?

-- 
Under any conditions, anywhere, whatever you are doing, there is some
ordinance under which you can be booked.
        -- Robert D. Sprecht, Rand Corp.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Jul 2003 16:13:28 +0200

>should continue to be sent during the PAUSE period.  Perhaps this issue

Yes, this should be clarified in the specification. It is expected that 
RTCP is sent at all time during session from SETUP to TEARDOWN. I have 
logged a tracking bug for this.

Best Regards

Magnus