Re: [rtcweb] DTMF usecase before DTMF API [was RE: The DTMF API]

On 11/18/2011 09:53 AM, Ravindran, Parthasarathi wrote:
> It will be great in case usecase are added before going into DTMF API.
4.3.2.  Fedex Call

4.3.2.1.  Description

    Alice uses her web browser with a service something like Skype to be
    able to phone PSTN numbers.  Alice calls 1-800-gofedex.  Alice should
    be able to hear the initial prompts from the fedex IVR and when the
    IVR says press 1, there should be a way for Alice to navigate the
    IVR.

4.3.2.2.  Derived Requirements

    F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22

    A1, A2, A3, A4, A7, A8, A9, A10, A11, A12

>   AFAIK, DTMF is not directly going to useful in browser-browser scenario and it is possible to pass DTMF in the signaling layer for H.323, SIP in the standard manner.
What do you mean by "the standard manner"?

> IMO, There are way to solve DTMF in WebRTC without including media level API.
How do you propose to allow Alice in the use case to navigate the IVR 
without having some API that allows injecting DTMF?

Whether the API is media level or not, it seems clear to me that there 
needs to be an API. (The alternative would be to claim that the dialpad, 
too, is part of the browser chrome - that seems to me like the wrong 
solution in this case.)

(and - sounding like a broken record - the API aspects REALLY need to be 
in the W3C list.)
> Thanks
> Partha
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>> Of Hadriel Kaplan
>> Sent: Thursday, November 17, 2011 6:18 PM
>> To: Justin Uberti
>> Cc: Randell Jesup;<rtcweb@ietf.org>
>> Subject: Re: [rtcweb] The DTMF API [Was: Traffic should be encrypted.
>> (Re: Let's define the purpose of WebRTC)]
>>
>>
>> FYI - I asked an expert and he said that for the default DTMF duration
>> that although 50ms is the official minimum, in practice it's safer to
>> use 100ms and people often do that (or even longer but we don't need
>> to).  We also need to have a 50ms gap minimum.
>> So basically confirming what was already stated in other emails in this
>> thread.
>>
>> -hadriel
>>
>>
>> On Nov 16, 2011, at 1:38 AM, Hadriel Kaplan wrote:
>>
>>> On Nov 16, 2011, at 1:13 AM, Justin Uberti wrote:
>>>
>>>> [Local]MediaStreamTrack.sendDTMF(in DOMString tones, in optional long
>>>> duration)
>>>>
>>>> ex:
>>>> sendDTMF("1")  // plays tone 1 for 50 ms sendDTMF("2", 200)  // plays
>>>> tone 2 for 200 ms
>>>> sendDTMF("123")  // plays tones 1, 2, 3 in succession, each for 50 ms
>>>> sendDTMF("456", 200)  // plays tones 4, 5, 6 in succession, each for
>>>> 200 ms
>>> Sounds good to me, but supporting a multi-digit-string as you did
>>> above reminds me that I'll have to check with some experts if this is
>> ok - it reminded me there have been issues with DTMFs being too close to
>> each other in time, but I am not an expert in that and it may not be an
>> issue at all.  (there were issues in PSTN when multiple DTMFs were
>> generated back-to-back from a saved address-book contact-entry type
>> thing, but it may have only been a problem for using in-band DTMF which
>> won't be an issue here) I'll ask.
>>> -hadriel
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>