Subject: Re: [MMUSIC] Mixing aggregate and non-aggregate control (long)

From: Rob Lanphier <[email-masked]>
Date: Mon, 4 Feb 2002 18:21:59 -0800 (Pacific Standard Time)

Hi Jonathan,

I've floated your proposal around here at RN, and I think we agree with
most of what you lay out.  More inline.

On Fri, 25 Jan 2002, Jonathan Sergent wrote:
> (a) PLAY should only be allowed for playing everything that was SETUP.
>     It should be an error to PLAY a stream URL on a session where multiple
>     stream URLs have been SETUP.

Agreed.

> (b) PAUSE should then be modified so that only PAUSE of the URL that was
>     PLAYed is legal, to remove the other half of the "mute" functionality.

Also agreed.

> (b) New methods: MUTE and UNMUTE, to reintroduce mute functionality
>     -- Can be done as an extension rather than part of 2326
>     -- Either way, it should be optional

I think an extension is certainly the safer route to take.  If it's part
of a new RTSP draft, it might not be on the same interop timescale as the
rest of the draft.  Since it'd be an optional extension, it makes sense as
an extension.

>     -- Can be detected via OPTIONS (or by trying and letting it fail;
>        but the server shouldn't close the connection or session for an
>        unknown method) since they are new methods

Agreed.  That's part of what we like about this.

>     -- This could also be done with a pre-defined parameter instead of
>        a new method.

This seems new and different enough to justify a new method.  It's not
like method names are any more expensive than headers, and the semantics
are such that it is different.

>     -- Can only be used on a stream URL which has been SETUP for the
>        same session.  Error to use it on an aggregate URL.
>     -- "Mutedness" of a stream is not reset by doing PAUSE or PLAY
>     -- MUTE can be sent before PLAY and will persist

Agreed on all points.  One thing we might want to consider is whether or
not it is/can be an error to *not* SETUP one of the streams in an
aggregate session.  In my book, that's fine...the stream is just MUTEd by
default.  If we allow this, though, then we have to consider the
possibility of a SETUP after PLAY (and whether or not that's an implicit
UNMUTE).

>     -- Range header can be used to schedule MUTE and UNMUTE operations.
>        If queueing is to be performed, MUTE and UNMUTE requests are
>        queued the same way that PLAY requests are.

Hee hee....assuming we can agree on how PLAY requests get queued.  :)

In general, this is a good principle.

> (c) Deprecate the usage of PLAY with no range header on a playing stream
>     as a liveness ping.  Allow it to remain a no-op for a playing stream,
>     but suggest that clients use a SET_PARAMETER or an OPTIONS
>     which mentions the session identifier as a keep-alive.  Could introduce
>     a PING method, but I think this is unnecessary.

I agree with Magnus on this.  We could continue to "harmlessly"  overload
other methods, but that's the same trap that got us where we are.  It
seems that a PING would be so well understood as a method, and so easily
implemented, that we should just add it.

Where I disagree with Magnus is that I don't think we can require this
from clients and servers, but we can require the following:

1.  Implementations MUST not disconnect when rejecting this method (or any
well-formed new method)
2.  PING senders MUST be prepared to accept "405 Method not allowed", and
treat that as an acceptable liveness check.

> (d) Queued play should either be removed or be made optional.
>     If the server does not do queued play, then PLAY requests with
>     range headers are invalid while the server is playing and should
>     generate "method not valid in this state".

Agreed.

Rob

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Feb 2002 16:43:39 +0100

Hi,

See comments below.

> possibility of a SETUP after PLAY (and whether or not that's an implicit

My opinion is that we must allow to setup a single media from a presentation
containing multiple medias, as this is non-aggregate control. Some clients may
desire to do this in certain presentations. I believe disallowing doing single
stream control with play and pause in an aggregated session, i.e. a session with
two or more different medias setuped, still cleans up this a lot. Then
introducing an extension for MUTE and UNMUTE giving a that functionality. This
seems to provide all functionality that I can think of.

I do have a question regarding aggregated control. Is it allowed to setup two
medias coming from different presentations? I think this is a special case of
creating aggregates from medias in individual files and not in any container
files.

> treat that as an acceptable liveness check.

I believe that point 2 is in error. I agree that it must be ready to accept 405
or 501 Not Implemented. But it can't treat it as a an acceptable keep alive
mechanism. The session id probably never was interpreted and the timer not reset.
I can't see any reasons not to mandate PING for all implementations. When most
implementations support the new spec keep alive and livness checks can be done in
both directions (client<-->server). I do understand that a fallback mechanism
should be specified. In my opinion the livness check should be done in the
following way:

1. Try required method PING. If a old non upgraded implementation is used, on
error message try both 2.
2a. Try Options with session ID. I am uncertain if most implementations support
this? The problem is that you don't know if the session timer was reset.
2b. If SET_PARAMETER with session ID is implemented it should also work. But as
this is outside the minimal implementation it is uncertain if it will work.

Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/T/VA
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Aravind Narasimhan <[email-masked]>
Date: Wed, 06 Feb 2002 11:50:39 -0500

Please see my comments inline:

[snip]

>>Scenario #6:
>>Initial connection setup, followed by:
>>--------------------------------------------------------------------
>>C->S
>>PLAY rtsp://host/a/ RTSP/1.0
>>Cseq: 4
>>Session: ZZEfpZ0zxK5
>>Range: npt=0-30
>>
>>--------------------------------------------------------------------
>>S->C (time = t)
>>RTSP/1.0 200 OK
>>Cseq: 4
>>Session: ZZEfpZ0zxK5
>>RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
>>          url=rtsp://host/a/c;seq=16778;rtptime=1946900992
>>
>>--------------------------------------------------------------------
>>C->S (time = t + 1)
>>PLAY rtsp://host/a/ RTSP/1.0
>>Cseq: 5
>>Session: ZZEfpZ0zxK5
>>Range: npt=45-60
>>
>>--------------------------------------------------------------------
>>S->C
>>RTSP/1.0 200 OK
>>Cseq: 5
>>Session: ZZEfpZ0zxK5
>>RTP-Info: url=rtsp://host/a/b;seq=16664;rtptime=660914,
>>          url=rtsp://host/a/c;seq=18578;rtptime=1949600992
>>
>>--------------------------------------------------------------------
>>
>>This is normal queued play.  The server plays the presentation for the
>>first thirty seconds, then immediately jumps 15 seconds ahead and plays
>>the last fifteen seconds, then pauses.
>>
>
>I would like us to consider the language we are using. I would not call it
>pauses after it has played the last 15 seconds. Rather I would call it halt or
>stops. The reason is the use of the word pause implies that the client sent a
>pause, which obviously not is the case. 
>
I dont think you can use the word "halt".  Section 10.6 of the RFC uses 
halt in its explantion of the PAUSE functionality:
Section 10.6

   The PAUSE request causes the stream delivery to be interrupted
   (halted) temporarily. If the request URL names a stream, only
   playback and recording of that stream is halted. 

 The word is too overloaded.  The defintion of  a PLAY with range 
headers uses PAUSE in it explanation too.  
Section 10.5

    After playing the desired range, the presentation is automatically
    paused, as if a PAUSE request had been issued.

obviously "halt" and "pause" were meant to be used interchangeably in 
the RFC.
 I do think that clearer terminology is warrented in a newer rev. of the 
standard.

>And the difference is rather obvious if
>you would send another play without range after the stream has halted. If it has
>halted the play starts from the beginning of stream (npt=0-). If it was paused
>it would continue where it has paused.
>
I dont think that RFC draws this disctinction at present.

>>I think these changes are warranted to clean this up:
>>
>This behavior with the mute functionality looks fine. To my understanding the
>functionality which is removed is the possibility to change the synchronization
>between media, as this is possible with multiple single media sessions, i.e.
>non-aggregated control, I don't see a problem.
>
one thing that needs to be addressed is the question of muting all the 
streams in a session.  Likewise the question of muting a stream before 
playback has begun is important to consider.

>
>
>I would argue for a mandatory to implement method PING in both servers and
>clients. This prevents overloading of functionality which created this mess in
>the first place.
>
Agreed.

Aravind

---

From: Jonathan Sergent <[email-masked]>
Date: Wed, 6 Feb 2002 13:25:11 -0800

Sorry it took so long for me to respond.  I have been out of reach
of email...

> rest of the draft.  Since it'd be an optional extension, it makes sense as

This sounds right.  I think will want to implement it, but we don't
have a client.  Is there someone else interested in making this work?

> possibility of a SETUP after PLAY (and whether or not that's an implicit

I think that not doing a SETUP is different than doing a MUTE, because
the RTP session is never established, and RTCP reports cannot be
exchanged, and so on.

The RFC is unclear on what a SETUP means after PLAY if the SETUP is for
a URL that is not already part of the session.  (If it's for the same
URL, then it's just a request to change the transport parameters, of
course.)  I think we should forbid this, because it just adds more
complexity.  It would make it so that you could use SETUP and TEARDOWN
of individual streams to do approximately the same thing as MUTE and
UNMUTE.  (I would like to leave "There's More Than One Way To Do It" to
the Perl people and say that this is probably not desirable for network
protocols.)

Since the second and further SETUP requests can be pipelined (you can
send them all at once since you have the session ID after the first
one), I don't think there is a latency argument for this, either.

> Hee hee....assuming we can agree on how PLAY requests get queued.  :)

Yeah.

I unfortunately missed the call today so I don't know if we came to any
conclusions on what to do about queued play yet.  We will need to
figure out a resolution for that before we could move forward with an
I-D on a MUTE/UNMUTE extension, because it would come out
differently...

> treat that as an acceptable liveness check.

Can we add PING to the base specification and still go to draft standard?
I sympathize with the desire to avoid overloading, but I think it is a lot
easier to just keep the current use of OPTIONS.  I think we can agree that
using OPTIONS as a keep-alive is not going away, and I would prefer for us
to not introduce two ways of doing the same thing.

On (1) I agree 100%; on (2) I think it would be a 501 Not Implemented.
405 would imply that the server understood the PING but didn't allow it.
It seems like this would imply PING having failed rather than succeeded.
If we have PING, I think the client should be prepared to receive one of
200, 454, or 501.

I think 405 means that the method is not valid for the given URL, i.e.
if you try to send a web server a POST for an ordinary HTML file.  So
one final question about PING is what should be done with the URL
field.  (I wonder the same thing about OPTIONS, though; what should the
server do if you do an OPTIONS with a Session header on a URL that is
not part of that session?)

--jss.