Subject: [MMUSIC] RTSP: SETUP with new url in Play state

From: Geetha Srikantan <[email-masked]>
Date: Thu, 11 Sep 2003 16:41:12 -0700

Hello,

I'd like to clarify a few items about the SETUP request, when used to
add a new piece of content to an
existing session that is in Play state.

1. Is this intended for adding new media to an existing track? That is,
an active track whose transport end-points
were established during a previous SETUP. If so, what happens to the
media/url that was on the track earlier?
What is the mechanism to switch over to the new media? What time instant
in the old and new media?

2. If the above is allowed, then this would appear to be one mechanism
for client-driven playlists.
Now that queued play is not allowed, is this the only mechanism for
playlists from the client?
(Other than the case where a PLAY request with multiple Range header
values can be used
to create a playlist based on a single url.)

3. If SETUP in Play state is intended for adding new  media to a new
track ,it looks like there is an implicit PLAY request here. Are there
any restrictions on when the track begins, beyond having to synchronize
with other tracks in the session?

4. Section 11.4 says that 'A client MUST NOT issue a PLAY request until
any outstanding SETUP requests have been
acknowledged as successful.' This seems to contradict (3) above...where
the SETUP has an implicit PLAY.

thanks
geetha

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Sep 2003 09:26:01 +0200

Hi Geetha,

I don't know what you mean with track. This is not in the standard 
vocabulary we have used when discussing RTSP. We normally talks about 
RTSP sessions which consists of one or more media streams. In some cases 
people might have used "media track" as being the same as a "media stream".

In the previous mails I on transport negotation I was discussing the 
usage of SETUP to change transport parameters. One is changing transport 
parameters when a client sends SETUP request using the URL that 
identifies a media already present within the session.

The other usage of SETUP is to add a media to a session, either in 
aggregate form or to create a new session. In the case the clients sends 
a SETUP request to the server with a session ID for an existing session 
which are in PLAY state, the server if supporting this shall setup this 
media in synch with the already present medias. With synch I mean that 
if the session was at npt=46.7 when the setup request is received the 
new media shall be played from 46.7. To accomplish client side 
synchronization there must be a Range and RTP-Info header present.

More comments inline

> in the old and new media?

Please clarify what you mean with adding media to a track. As I pointed 
out above this is to add a media to a session.

> to create a playlist based on a single url.)

No, I don't think this is a mechanism for playlists. Each SETUP tells 
the server which media object that it desires to have delivered, as 
identified by the URL. In my view a playlist is a collection of media 
objects that one desires to be played after another. There are better 
ways with RTSP to accomplish this then to try to change the content in a 
session with SETUP and TEARDOWN. I can at least think of two ways to 
accomplish this.

1. Use one session per media object in the playlist. The client can 
start with the first object in the list, create a session, start playing 
it. When the end comes closer, the client creates a new session for the 
next object. When the first object has come to an end, the next session 
is played. And so on. This would allow a client to use multiple servers, 
etc.

2. To achive a client controlled playlists would be to have a web 
interface for controlling what items are part of the playlist. Then this 
playlist is identified by a generated URL. The user then clicks, copies 
this RTSP url to invoke the media player. The media player then set up 
the media streams and RTSP PLAY and PAUSE can be used to navigate in the 
playlist. The only problem here is that RTSP might benefit from a range 
format that takes it forms of chapter/tracks or some type of labels 
rather than exakt time from start.

> with other tracks in the session?

I would not considered it a implicit play request as the media are 
already playing. I think it is important to remember that with the 
aggregate simpification the whole session has the state, not the 
individual media. Therefore any media added to a playing session will 
automatically be playing. And as I pointed out before it will start on 
the exakt same offset as the other media within the session.

You can not use this to build a time line that looks like this

<---media A -->               <----- media C ---->
               <---media B ---->

IF one sets up three media it will result in a time line that looks like 
this

<---media A --->
<---media B ---->
<-media C ->

> the SETUP has an implicit PLAY.

No, it is not contradicting. When you have outstanding SETUPs you are 
not allowed to send PLAY requests. However when you are in PLAY state 
and sending a SETUP request you are not sending any PLAY. Don't mix up 
requests with states.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Geetha Srikantan <[email-masked]>
Date: Fri, 12 Sep 2003 09:43:01 -0700

hi Magnus,

Inline..

> people might have used "media track" as being the same as a "media stream".

Sorry..'track' was probably a bad choice, I mean the logical 'pipe' identified
by the
client IP + ports and server IP + ports, for a specific stream in a session.
That is the
pipe identified by < <client IP + RTP port + RTCP port>, <server IP + RTP port
+ RTCP port>>
on which the track or stream url's content is streamed.

> out above this is to add a media to a session.

To clarify - is it possible to add new content to an existing stream in the
session, i.e.
to an already existing pair of <client IP + ports>, <server IP + ports>, which
were negotiated *earlier*
to stream contents of a different url?
This would seem rather complicated - and I'm not sure what the motivation
would be.
If this is not allowed, it would be good to have the document say so...that
was my point.

> rather than exakt time from start.

Yes, I see these two ways of doing a playlist.
My question only applies if it is possible to add new content to an existing
stream, and the content
on the existing stream reaches the end of  range for that stream, for example.

> <---media A -->               <----- media C ---->

Ok..I think this is getting clearer.  It looks like this functionality is not
intended to add content to
an existing stream or 'pipe'.

> IF one sets up three media it will result in a time line that looks like

Ok..so the three media share the same time-line although one of them might
have been SETUP later than
the others, right?

Is the following a possible scenario, where * indicates when that stream was
SETUP?
Here each of media A, B, C are each on a unique < <client IP + RTP
port + RTCP port>, <server IP + RTP port + RTCP port>>.

<-*-media A -------->
<-*-- media B ----->
<----------media C ---*----->

It would be extremely helpful if these cases were explicitly mentioned in the
document - for a reader
of the spec who hasn't been involved in the discussions, these would provide
an excellent guideline.
Right now, the text is very sketchy and leaves room for the wrong
interpretation.
It would be great to add concrete examples for the use of SETUP during Play
state in the text with
a typical

> and sending a SETUP request you are not sending any PLAY. Don't mix up

Yes, this is a bit of a confusion - thanks for clarifying. It would help to
add text to the
document to highlight this point.

thanks
geetha

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Sep 2003 10:02:02 +0200

Hi,

Comments inline. Note that I have a question about removing SETUP in 
PLAY state later down in the mail.

> to stream contents of a different url?

No, as you correctly understood later in your reply. RTSP does work 
around the media resource that are identified by the SETUP URI. That 
media resource can be added or removed from a RTSP session, the 
transport method and parameters can be changed. So it does not work by 
specifying a transport channel and then specifying what resources that 
go into this.

> If this is not allowed, it would be good to have the document say so...that

I think the important thing is to ensure that one understands how it 
works and what shall happen. That way one can understand if it is usable 
for the purpose one has or if other ways need to be found.

> an existing stream or 'pipe'.

Yes, exactly. It is intended to add the media streams in parallel with a 
common time line.
> have been SETUP later than

Yes,
> It would be great to add concrete examples for the use of SETUP during Play

The only use cases that so far has been discussed to my knowledge was to 
add or drop different versions of the media. However as bit-rate 
switching mechanism this is rather heavy. I think that the bit-rate 
switching can be discussed separately and the best method for 
accomplishing it can be defined separately. In the interest of 
simplifying things that are in the core, could this be something we 
could remove?

Are there anybody that has or plans to implement this functionality? If 
not I would suggest that we drop it from the core spec. There is nothing 
preventing us from specifying this later on.

> document to highlight this point.

I will look into this.

Cheers

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Mon, 15 Sep 2003 10:05:27 -0700

> specifying a transport channel and then specifying what resources that 

The RealNetworks RDT transport has a "track id" field in its header and also
multiplexes control and data traffic.  It uses one UDP port per aggregate
url.  Is this a valid use of the protocol?

-- 
Politics is like coaching a football team. you have to be smart enough to
understand the game but not smart enough to lose interest.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Sep 2003 09:43:17 +0200

Hi Tom,

> url.  Is this a valid use of the protocol?

I don't see a problem to use RTSP to specify what transport protocol and 
what demultiplexing points that is used to identify the different media 
streams. In the case of RTP this is the RTP sessions. If you in RFC uses 
the same port and another demultiplexer in the form of "track ID" I 
don't see a problem. If I have this protocol I would simply have a 
proprietary Transport header parameter that needs to be present when RDT 
is signalled that indicates what "track id" that will be used for this 
media stream.

I think that it is important to remember that RTSP is not media 
transport dependent, which it might appear due to the fact that RTP is 
so written into the protocol. I hope that the new appendix B "Media 
Transport Alternatives" will help clarify this issue.

Cheers

Magnus Westerlund

---

From: Geetha Srikantan <[email-masked]>
Date: Fri, 19 Sep 2003 09:54:04 -0700

hi Magnus,

Thanks for clarifying this issue, it is very helpful.

Regarding your question on whether we can remove the functionality that allows
SETUP with a new url
during play state - I agree that not having this functionality would simplify the
spec. And if it is needed,
it can always be introduced in an extension to the main RTSP spec. So my vote would
be to remove it from the main spec.

geetha