Re: DTMF again

> codec that can handle them is selected.) So I'd suggest having the API
> there always. It sends 2833/etc if possible, and if not it *MAY* send
> the tones as in-band audio (I wouldn't require it).

Then there's no way for an application to know if DTMF will actually 
work, and, correspondingly, whether or not it should display a dial-pad 
(the feature Justin was asking for on the call last night/this morning).

It's also not easy to do in all cases. Consider a remoteStream from one 
PeerConnection fed in as a localStream to another (something that is 
perfectly legal with the current API, AFAICT). If both sides support the 
same codecs, then as a useful optimization the browser could (possibly 
with some minor header rewriting) forward RTP packets between them 
directly. Until you first try to send DTMF. Then, for what you suggest 
to work, it has to create an encoder and start transcoding in order to 
inject the new audio. I expect no one will actually implement things 
like this. Instead it will either transcode always (precluding a useful 
optimization), or DTMF will silently fail (providing a bad user experience).

Received on Thursday, 15 December 2011 14:49:26 UTC