Subject: RE: [MMUSIC] Aggregate Control URI

From: Thomas Zeng <[email-masked]>
Date: Fri, 11 Jul 2003 13:27:46 -0700

Bill:

Based on my understanding of the discussions during the past RTSP tele
conferences, I'd like to make a couple of  comments. 

See below.

- thomas

>  -----Original Message-----
> From: 	Bill May [mailto:[email-masked]] 
> Sent:	Friday, July 11, 2003 10:17 AM
> To:	Aravind Narasimhan
> Cc:	Magnus Westerlund; [email-masked]
> Subject:	Re: [MMUSIC] Aggregate Control URI
> 
> 
> 
> Aravind Narasimhan wrote:
> >  Secondly, as Tom and Magnus have mentioned, a 
> > user may try to aggregate multiple streams in one RTSP session, where 
> > there isnt a unified presentaiton description, or where someone has 
> > ignored to put a session level aggregate control URL in the SDP.  Now 
> > the server has the right to say that it cannot aggregate the given media
> 
> > URLs in a session, 
> 
> I will agree with this; however, it does not make sense for the client
> to create it's own aggregate URLS where the server does not specify one
> (given the SDP case).
	[Thomas Zeng]  The bottom line is that PLAY is always an "aggregate"
operation. Regardless of the control URI in the PLAY request, the sessionID
will uniquely identify the media streams affected by the PLAY request.  That
is the spirit of draft-ietf-mmusic-rfc2326bis-04 (see section 11.4).  In
your case, if the SDP does not intend to support aggregate control (assume
that the SDP does have more than one media tracks), it should NOT have used
RTSP in the media level control URL.

>  > but it does not make sense for the server to allow
> > two or more streams to be part of a session where each stream within the
> 
> > session is going ot be controlled separately in a non-aggregate fashion.
> 
> I'm sorry, but I do not understand.
> 
> 
> I can see a scenario where you might want to stop the video, but still
> maintain
> the audio.  In this case, you have 2 or more streams running, and the
> client
> wishes to stop 1 of them.  This is a perfectly legal scenario.
	[Thomas Zeng]  There are two ways to do what you want here: 1) issue
teardown on the audio track. 2) perform a MUTE on the audio track.

> Another would be a fast forward application, where you pause 1 or more
> streams
> while changing speeds on another.
	[Thomas Zeng]  Again, you would use MUTE to pause 1 or more streams,
then use PLAY with range to seek.

> Can you please expand on why it doesn't make sense to allow streams to
> be controlled seperately ?  I've done most of my work on the player side
> with
> the idea that the streams could be seperate, so most likely I'm missing
> something.
	[Thomas Zeng]  If two streams belong to same RTSP session, and you
issue PLAY on one stream, what would be the state of the overall session ?
what would be the NPT  (Normal Play Time) of the session? If I recall
correctly, if PLAY/PAUSE were allowed on each track in a mutli-tracked RTSP
session, the RTSP state machine would break.

> > In the RTSP concalls of late, there was a general trend towards a 
> > consensus that within a RTSP session, all streams should be "aggregately
> 
> > controlled."  In other words, once part of a session, an individual 
> > media stream will be tied to the timeline of the session and will be 
> > controlled in conjunction with the rest of the streams in the session.  
> > So control methods such as PAUSE, PLAY would apply collectively to all 
> > streams within the session.  The upshot of this is that you cannot just 
> > PLAY or PAUSE a single media stream within a session.
> 
> Why ?  To me, aggregate (or control of the entire session) control and
> non-aggregate control (or control based on each stream) can be used
> at the same time, and should be allowed.
	[Thomas Zeng]  Yes, you are right here. The decision by the RTSP
task force was to let PLAY/PAUSE be aggregate, while SETUP/TEARDOWN and
MUTE/UNMUTE be non-aggregate (note MUTE/UNMUTE is defined as an extension to
RTSP core spec).

> Perhaps I do not understand the argument why control over streams
> in a session is so difficult.  Can you point me to some information about
> this ?
> 
> The only thing I could see is that you might want to discourage changes
> to the overall timeline, ie:one stream going back 10 seconds from the
> rest of the presentation.
> 
> But it would seem to me that would be an easy thing to prevent.
> 
> > To achieve the notion of "non-aggregate control", or may be the more 
> > appropriate term is "independent control" the consensus was that the 
> > onus should be on the client to set up multiple RTSP sessions, each with
> 
> > one or more media streams and manage them in a non-aggregate fashion.  
> 
> That seems non-intuitive to me -keeping twice as much information as
> needed.
> 
> > To try to clearly specify the mechanisms of "non-aggregate" control of 
> > individual media streams within a single session would probably cloud 
> > and confuse the spec unnecessarily, since the functionality is easily 
> > achievable by having multiple RTSP sessions that are controlled 
> > independently.  If this becomes a very serious requirement, someone can 
> > write an extension to RTSP that describes how two independent RTSP 
> > sessions can be controlled in a coordinated, yet non-aggregate fashion.
> 
> I guess I'm not understanding why this would be difficult.  The only
> limitation would be that the timeline must be consistent across all
> streams.  Otherwise, control the streams to your heart's content.
	[Thomas Zeng]  Here the concern is on RTSP state machine.
> I apologize for being so dense.
> 
> > Now there is an effort underway to establish the MUTE/UNMUTE methods to 
> > temporarily "silence/unsilence" individual streams within a RTSP session
> 
> > as a extension to RTSP.  In this case, however, the streams would still 
> > be tied to the timeline of the RTSP Session, where PLAY and PAUSE on the
> 
> > session would supercede the MUTE/UNMUTE methods.
> 
> I'm not sure that this buys you anything, if all a MUTE is is a PAUSE to
> an individual streams.  It does sound like over-complicating (adding more
> states and breaking backward compatibility) to avoid a couple of
> sentences.
> 
> > But I can see where my definitions for aggregate control and 
> > non-aggregate control could be a bit ambiguous, since obviously, there 
> > are methods such as SETUP and TEARDOWN, and even MUTE and UNMUTE that 
> > can work on individual media streams within a session.  I'll see if I 
> > can clean it up to take these methods into account.  We may just have to
> 
> > come up with more appropriate terminology.
> 
> Most likely that is why I do not understand.
> 
> Bill
> 
> 
> _______________________________________________
> 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: Bill May <[email-masked]>
Date: Mon, 14 Jul 2003 10:41:25 -0700

Thomas,

I think that we can agree that this new specification would not be
backward compatible with existing RTSP session.

To me, it does not seem like for good reason.  Not enough bang for the
buck, but perhaps I am still missing something.

As long as you are aware of this and have done so intentionally, that's
cool.  But IMO, I would not not be making these changes (adding MUTE,
requiring PLAY/PAUSE to be aggregate as opposed to stream based) in
order to make wording or a state machine clearer.

In fact, the MUTE complicates the state machine in the exact same way
that a non-aggregate PAUSE does.

More below:

> teardown on the audio track. 2) perform a MUTE on the audio track.

Doesn't teardown now need to be aggregate ?  So that wouldn't work.

> session, the RTSP state machine would break.

I'm not sure that I understand why the state of the session is important.
The server would be issueing the required streams.

The NPT of the session would be whatever the player decided it would be -
it can derive this from the RTPInfo, and decide how it wants to deal with it.

Are you defining a specification on how to develop a server (which is what
a state machine would imply) ?  Or a method of interoperability ?

> MUTE/UNMUTE be non-aggregate (note MUTE/UNMUTE is defined as an extension to

I'm not sure I understand still why MUTE is needed.  All it does is PAUSE
a single stream.  The MUTE complicates the RTSP server state machine in exactly
the same way that a non-aggregate PAUSE down.

It's the same thing called something different.

> 	[Thomas Zeng]  Here the concern is on RTSP state machine.

Which still has the same complications with the MUTE.

Bill May

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Jul 2003 09:52:01 +0200

Hi Bill,

> backward compatible with existing RTSP session. 

To my knowledge the changes result in a subset of the functionality that 
RFC 2326 specifies. This subset is working in this regard the same way 
the original specification. In our discussion there where no 
implementations that actually use the functionality of having individual 
PLAY/PAUSE in a aggregated session. The reason of the change was 
basically get the protocol to be interoperable. There where so many 
strange things when you allow individual media control within an 
aggregated session. By requiring all media control methods (PLAY and 
PAUSE) to work on the aggregated the whole issue was resolved and 
everything becomes consistent. So the interoperability issues of this 
change seem minor and the client will get clear indications through 
error codes that it attempts something not allowed by the server.

> that a non-aggregate PAUSE does. 

No it doesn't. As MUTE/UNMUTE only switch on and off the media delivery 
and do not effect the timing of the state and in what state machine 
state it is, it does not complicate things.

> Doesn't teardown now need to be aggregate ?  So that wouldn't work. 

Teardown can be used both aggregated and non aggregated.

>>> be controlled separately ?  I've done most of my work on the player 
>>> side
>>> with

Have you tried to implement a correct minimal implementation of the RFC 
2326 defined RTSP server? If you had I don't think you would ask this 
question. When I performed the implementation this resulted in a 50+ 
questions regarding how things should work that directly related to 
expected behaviour and interoperability.

> it can derive this from the RTPInfo, and decide how it wants to deal 

I don't think it is this simple. In a session with two aggregated 
session you will have actually three different playout clocks if you 
allow individual PLAY/PAUSE.
- The aggregated session playout time
- Media 1 playout time
- media 2 playout time.

When you perform an individual PLAY on a pause media using the media URL 
what should happened, what timers should be started? If you after that 
performs an aggregated PLAY, does that replace the previous media 
playout, or does it only start all not already running media? This is a 
rat hole.

> a state machine would imply) ?  Or a method of interoperability ?

This is a interoperability problem and a fix to a under specified part 
of RTSP.

> It's the same thing called something different.

Not exactly the same thing. You are correct that MUTE can be realized 
using one RTSP session per media and do all media synchronization at the 
client side. The MUTE/UNMUTE proposal is a separate extension draft and 
will  need further review. You might be correct that MUTE/UNMUTE are not 
in fact needed.

Best Regards

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Tue, 15 Jul 2003 01:08:22 -0700

> Teardown can be used both aggregated and non aggregated.

I was under the impression that RTSP/1.0 only allowed aggregate TEARDOWN,
while RTSP/1.1 will allow both aggregate and non-aggregate TEARDOWN.

> will  need further review. You might be correct that MUTE/UNMUTE are not 

I believe we have recently agreed that the RTP time continues while in the
PAUSE state.  Wouldn't this make MUTE and PAUSE pretty much identical?  What
would be the remaining difference(s)?

-- 
One good reason why computers can do more work than people is that they
never have to stop and answer the phone.

---

From: Dave Singer <[email-masked]>
Date: Tue, 15 Jul 2003 10:34:18 +0200

>would be the remaining difference(s)?

RTP time continues indeed, but not NPT, whereas I understand MUTE to 
say that NPT is advancing, whereas when paused it is not.  So, after 
play/pause a subsequent play will start where you paused (with RTP 
timestamps advanced by the duration of the pause, but the media 
continuous);  play/mute and then subsequent unmute would unmute 
material that is later in the source content by the the muted 
duration.

right?
-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Jul 2003 10:35:35 +0200

> material that is later in the source content by the the muted duration.
>
> right? 

Yes, MUTE only specifies that delivery is not performed. If you are in 
PLAY state the NPT time continues to run.

Cheers

Magnus Westerlund