Subject: [MMUSIC] Comments on RTSP MUTE:draft-sergent-rtsp-mute-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Mar 2002 11:57:45 +0100

Hi Jonathan,

I finally had time to read your proposal. I have the following comments:

1. Section 2.1 first paragraph, should not the following sentence use 
capital MUST?
"The URL must be for a stream which has already been SETUP in the 
current session."

2. What is the behavior if you do UNMUTE on a stream that is not muted? 
Should it return "455 Method Not Valid in This State" or return "200 ok"?

3. How does MUTE interact with RECORD. Should it not be possible to use 
MUTE/UNMUTE also on recording streams?

4. In a response to a UNMUTE it says that RTP-info SHOULD be returned. 
Shouldn't also a range header specifying where it resumes also be 
included. This range header should be open ended and only specifying the 
point of unmuteing. Otherwise the synchronization information will be 
incomplete

5. A IANA section should be added which register the option "mute" in 
the so far non existing RTSP options registry. This will of course 
prevent this draft from being a proposed standard before the updated 
RTSP specification also is approved.

6. At least open issue 5 seems to go away as we remove the queued play 
functionality.

7. Perhaps the draft should be a little more elaborated on the fact that 
the presentation clock keeps running even if all media are muted.

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]

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

---

From: Aravind Narasimhan <[email-masked]>
Date: Tue, 19 Mar 2002 15:35:30 -0600

Hi Magnus,
I'll venture to answer some of your concerns since I co-authored the 
proposal.

> "The URL must be for a stream which has already been SETUP in the 

agreed.

>
> 2. What is the behavior if you do UNMUTE on a stream that is not 
> muted? Should it return "455 Method Not Valid in This State" or return 
> "200 ok"?

I think there are a couple of veiled questions in the issue that you 
bring up.

   1. Does MUTE/UNMUTE cause more states to be added to the server state
      machine?
      If we want to send a message saying "Method not Valid in this
      State" it kindof implies that we are adding more states to the
      state machine. If we end up going down the path of adding states,
      we may have to add the PLAYING-MUTED, PLAYING-UNMUTED,
      PAUSED-MUTED, and PAUSED-UNMUTED states and track that with
      respect to each of the streams. I think it gets pretty complicated
      I dont think we want to do this. As far as the server/client is
      concerned it is in the Playing states or Ready states.
   2. I think that it should return "200 ok" This allows the client to
      not have to maintain information as to "muted state" of the
      server. We may want to add the following wording to the UNMUTE
      section of the proposal to be clear on this:

   If UNMUTE is issued on a stream that has not been setup or has already
   been torndown the server should respond with "455 Method Not Valid in 
   This State" and should send an "Allow:" header with SETUP as the
   value.  If an UNMUTE request is received for a stream that is not
   currently "muted" or scheduled to be "muted", the server will return
   a "200 OK" as if the UNMUTE succeeded.  

However, we are saying in the proposal that an UNMUTE will send 
Rtp-Info. It is not clear if we should send Rtp info in the case where 
an UNMUTE is sent on an already "unmuted" stream. This needs to be 
resolved, because this issue is similar to the "PLAY w/o Range Header 
for liveness ping" issue that was discussed in the Feb 6 Telecon. We 
resolved to deprecate the use of PLAY as a liveness ping in response to 
similar issues. My suggestion would be to not send an RTP-Info in the 
response of an UNMUTE of an already "unmuted" stream.

>
> 3. How does MUTE interact with RECORD. Should it not be possible to 
> use MUTE/UNMUTE also on recording streams? 

We didnt consider this in our submission. It needs to be incorporated. I 
see the functionality being the same as what the PLAY case would have. 
Mainly, MUTE should cause the server to temporarily suspend the 
recording of a stream within a presentation. Additionally, the 
presentation clock will still keep running so that when an UNMUTE 
happens, the new data is recorded synchronized with the current 
presentation NPT.

My main question here is really what the use for such functionality 
would be other than maintaining consistency within the proposal and 
within RTSP. However consistency is a good goal and we should strive for 
it. So I dont have any objections to having defined behavior for 
MUTE/UNMUTE interaction with RECORD. The question is whether it should 
be what I describe above in the previous paragraph.

> included. This range header should be open ended and only specifying 
> the point of unmuteing. Otherwise the synchronization information will 
> be incomplete 

agreed. a range header is needed in the response and rtp-info's rtptime 
will correspond to the time in the range response header. the question 
going back to the previously raised issue here is whether we should be 
sending back RTP info and range headers for an UNMUTE on a already 
"unmuted" stream. My answer tends to be no, we shouldn't. Otherwise 
UNMUTE essentially becomes a way to query the server current NPT. I dont 
think UNMUTE is intended to be used for such functionality. However I 
think that UNMUTE should still return a 200 Ok..

> RTSP specification also is approved.

ok. I'm not clear on how to do this. . .

> 7. Perhaps the draft should be a little more elaborated on the fact 
> that the presentation clock keeps running even if all media are muted.

agreed.

---

From: Tom Marshall <[email-masked]>
Date: Tue, 19 Mar 2002 20:41:05 -0800

>      section of the proposal to be clear on this:

Why not define new status codes?

463 Already Muted
464 Not Muted

> response of an UNMUTE of an already "unmuted" stream.

[side note: I have always viewed the RTP-Info header as "nice but not
necessary for operation".  There is a race between the first data packet(s)
and the play response so you cannot really count on it being received before
starting to play.]

I agree that it is only logical to send an RTP-Info header if it results in
a successful unmute action.

> be what I describe above in the previous paragraph.

I agree.  Consistency is good and your solution maintains consistency.  The
only thing I could add is to recommend a course of action when the encoder
sends a MUTE but continues sending packets.  Should the packets be discarded
or should the MUTE be ignored?

---

From: Jonathan Sergent <[email-masked]>
Date: Wed, 20 Mar 2002 09:41:00 -0800

> Why not define new status codes?

I think that if we want to return an error, 455 is okay.  455 requires
you to list the valid methods in the Allow header, so properly
implemented clients will not end up in an undefined state when this
happens.  This might be a better idea than letting redundant MUTE and
UNMUTE requests silently succeed.

> or should the MUTE be ignored?

I think the packets should be discarded.  Consider the situation where
the RTP session is a multicast session, so the server is recording the
multicast session.  The RTSP client may send a MUTE to tell the server
to stop recording for a little while; the multicast session may
continue.