Subject: RE: Mute vs. PAUSE in RTSP

From: Eric Fleischman <[email-masked]>
Date: Wed, 26 Mar 1997 09:31:14 -0800

I recommend that we not add in "MUTE" as an RTSP method.

"MUTE" is problematic and adds little value and considerable unneeded
extra complexity. If this extra complexity is added, it must handle at
least the following scenarios:

1) streaming data is sent as a "group of media streams" from the same
source (e.g., ASF, QuickTime, AVI). The natural thing to expect is that
the user will turn down their sound volume to handle a mute - thus the
command is unnecessary. If the command exists, one would expect the
client to simply not render the sound. The third possibility, to have
the server "extract" the sound channel(s) and not send them, adds extra
state and overhead to the server - particularly with interleaved data
types - and this overhead will detrimentally harm the performance of the
server. (This is "A Bad Thing".)

2) streaming data is sent as segregated media streams. In this case the
more efficient approach for the network would be to unjoin the audio
stream and rejoin it once the user wishes to hear audio again. Thus,
mute is not needed. In the case in which multiple audio streams are
being received and are "locally mixed", a mute will have to "silence"
all of the streams to be effective. This offers less control than the
network controlled alternative already present with RTP/MBONE.

Thus, I recommend that we not add in "MUTE" as an RTSP method.

	-----Original Message-----
	From:	Mark Handley [SMTP:[email-masked]]
	Sent:	Tuesday, March 25, 1997 9:11 AM
	To:	Henning Schulzrinne
	Cc:	[email-masked]
	Subject:	Re: Mute vs. PAUSE in RTSP 

	>In discussions I've had since I wrote this note, I'm becoming
more
	>convinced that a single RTSP session should really only control
a single
	>media stream (which may consist of several substreams, as when
you are
	>delivering a Quicktime/AVI/ASF movie) to avoid problems with
	>presentation authors piecing together unrelated media objects.

	Given that the delay from a user pressing "go" to the server
getting
	the message is not predictable, how would you suggest
synchronised
	startup of playback of separate audio and video streams is
performed
	if you don't have a common RTSP session (and can therefore
guarantee
	atomicity)?  

	You can buffer the first stream which arrives, but this does
seem to
	complicate the issue somewhat wrt the client knowing for certain
that
	the later stream is definitely going to start arriving
eventually.

	Mark

---

From: Karl Auerbach <[email-masked]>
Date: Wed, 26 Mar 1997 12:15:01 -0800 (PST)

> .... The third possibility, to have

Ummmm... it seems to me that sending a stream when nobody is listening is
rather a much, much worse thing.  Indeed, even stronger condemnitory terms
would apply.

I'd rather lose performance on some server somewhere than place the burden
on the network and make everyone suffer, even those not concerned with
multimedia networking.

		--karl--

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 28 Mar 1997 14:53:55 +0200 (EET)

>I recommend that we not add in "MUTE" as an RTSP method.

Agreed. Given PAUSE, MUTE doesn't pay off.

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>