Re: Where to attach a DTMF API

On 11/29/2011 05:19 PM, Randell Jesup wrote:
> On 11/29/2011 5:23 AM, Timothy B. Terriberry wrote:
>>>> How should we handle these cases? Can we create a null audio track using
>>>> the current API?
>>> How would you do it for a legacy client? My understanding was that
>>> RFC4733 required and existing (audio) RTP stream (identified by SSRC) to
>>> insert its DTMF payloads into.
>>
>> I think the question is simply whether or not we can create such an RTP
>> stream without acquiring a MediaStream via getUserMedia(). roc's
>> MediaStream Processing API certainly provides a way to do this. Chris
>> Rogers' Web Audio API doesn't seem to provide MediaStream objects that I
>> can tell, but I assume that's something that could be fixed.
>
> This is a case where we want to create a one-way-connection, or maybe
> one where the user doesn't want to give mic access (but does want the
> call to go through).
>
> While microphone/file-source access needs to be use-approved, we could
> allow an application to create a 'null' audio (or video) mediatrack
> without permission (silence for audio, black (or black with "no video"
> or "camera off" or a camera with a red circle-slash)).  That could then
> be used in place of a GetUserMedia() stream.
>
> We may have uses for this elsewhere, perhaps for muting (you don't want
> to wait for signaling on mute, and just stopping sending is a problem in
> some cases, especially if the signaling channel is slow/broken) or to
> open channels immediately while waiting for the user to respond about
> media access.  However, these may be spurious uses if the media tracks
> support a Mute operation.
>
> Perhaps more to the point, being able to switch the source for a channel
> from the mic to self-generated data (silence, "the doctor will be with
> you shortly", black, a test pattern, camera-with-slash, etc) is more the
> point of what we need, and for this we'd just need to be able to build a
> stream using a source like that instead of switching the source of an
> existing stream/track.
We did some experimentation along those lines, with a solution where the 
user can switch between sources, but with the browser and not the app in 
control. Our idea actually had another purpose: getUserMedia could 
immediately answer with a default stream, but that stream would be 
benign data stream such as a test image or a pre-recorded video. The 
user can then switch to the live camera stream at any time, and back to 
the default stream during the session.

We wrote some stuff up at 
<https://labs.ericsson.com/developer-community/blog/dmp> if someone is 
interested.
>

Received on Tuesday, 29 November 2011 17:46:12 UTC