Re: [Bug 20816] "Hold" unspecified

Inline...

On 4/20/13 3:17 AM, Randell Jesup wrote:
> 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).

This is a very murky area.

In the sip world it is pretty common for "music on hold" to result in 
audio from a different SSRC than was previously being sent and rendered. 
It is necessary for the recipient to realize that it should render this 
new RTP stream to the same device the prior stream was being rendered.

This works, more or less, in the case where a single m-line is assumed 
to contain only a single logical stream (what term are we used for that 
now? In clue I we would call it a Capture.)

In a bundled case it can still work as long as there is a separate 
m-line for each "Capture" even when it might be represented by a series 
of different SSRCs.

Otherwise we need a way to identify that multiple RTP Streams belong to 
the same Capture. The proposal has been to use a new RTP header to 
convey this, or else explicitly signal a set of SSRCs that map to the 
same Capture.

AFAIK the informal notions of "Hold" haven't been explored in this 
context. New work is needed.

 Thanks,
 Paul

>>> 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)
>>>
>>
>>
>

Received on Friday, 26 April 2013 23:24:52 UTC