Re: [Bug 20816] "Hold" unspecified

On 4/20/2013 12:00 AM, Harald Alvestrand wrote:
> On 04/19/2013 05:32 PM, Randell Jesup wrote:
>> I would suggest that we avoid the term "hold" - it's too loose, too 
>> many definitions (contradictory ones).
>>
>> We need:
>>
>> 1) Mute (on a track level)
>> (optionally) Mute on a stream level (Mute all tracks)
>> (where "Mute" means replace with silence/black)
>>
>> 2) Replace track with other media (muzak, slate, etc)
>
> Nit: The concept of "replace" is not well defined. In particular - 
> when one removes one audio track from a MediaStream, and adds another 
> audio track, has one replaced that audio track?
>
> I'd like to not use the "replace" word, and just talk about adding and 
> removing tracks in a MediaStream.

I explicitly don't want to say add/remove tracks (as in force 
negotiationneeded, or mess up downstream consumers who are cognizant of 
the tracks - for example, a video element that's displaying a particular 
track of a stream).

I want/need to in some seamless manner replace the content of a track.  
That *could* be mediaStream.replaceTrack(old,new), or it could be some 
way to change the source of a track, or have a composable 
track-selection object, much as WebAudio has the ability to mix or 
select from inputs to a node (in Mozilla parlance, a TrackUnion track 
that can select from it's input tracks).

This ability greatly improves the power of the application to compose 
the media they're producing.  If you want to go further, something along 
the lines of MediaStream Processing and WebAudio will be needed 
(especially for video, as WebAudio makes a lot of audio things possible 
(if perhaps overkill in simple switching cases) by having it sit between 
sources and MediaStreams used for PeerConnections, etc).

>
>>
>> 3) change directionality of a stream
>>      sendonly, sendrecv, recvonly
>
> This requires the manipulation of an object that does not have 
> explicit representation at the current API surface.
> Please, please, please don't use the word "stream" for it. Even "RTP 
> media stream" or (shudder) "M-line" is better than an unadorned "stream".

Change the directionality of an m-line (associated with MediaStreams 
added to a PeerConnection or produced by a PeerConnection).

>
>>
>> 4) notification of directionality changes
>>
>> From those, an application can compose whatever they want.
>>
>> Inaki's example is a combination of 1) and 3)
>>
>> My example (classic "business/pbx hold") is 2) (and unconnecting the 
>> incoming stream from the media elements, or muting the media elements)
>>
>
>

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Saturday, 20 April 2013 07:19:58 UTC