IETF Logo Mail Archive

Re: [rtcweb] Support DTMF "codec" or expose DTMF in signaling? (Re: DTMF usecase before DTMF API)

Roman Shpount <roman@telurix.com> Fri, 18 November 2011 20:56 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753A611E80E4 for <rtcweb@ietfa.amsl.com>; Fri, 18 Nov 2011 12:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.905
X-Spam-Level:
X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZW1qqtLXokL for <rtcweb@ietfa.amsl.com>; Fri, 18 Nov 2011 12:56:11 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 867FC11E80DE for <rtcweb@ietf.org>; Fri, 18 Nov 2011 12:56:11 -0800 (PST)
Received: by ggeq3 with SMTP id q3so1663742gge.31 for <rtcweb@ietf.org>; Fri, 18 Nov 2011 12:56:11 -0800 (PST)
Received: by 10.50.160.161 with SMTP id xl1mr4764797igb.5.1321649770677; Fri, 18 Nov 2011 12:56:10 -0800 (PST)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id dd36sm7147550ibb.7.2011.11.18.12.56.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Nov 2011 12:56:07 -0800 (PST)
Received: by pzk5 with SMTP id 5so6536302pzk.9 for <rtcweb@ietf.org>; Fri, 18 Nov 2011 12:56:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.65.166 with SMTP id y6mr5348087pbs.120.1321649765059; Fri, 18 Nov 2011 12:56:05 -0800 (PST)
Received: by 10.68.7.33 with HTTP; Fri, 18 Nov 2011 12:56:04 -0800 (PST)
In-Reply-To: <CAOJ7v-3gYPjAKST_K9tvU4DAGHyyapujf8t9KeDMKE3geutQ=Q@mail.gmail.com>
References: <CAOJ7v-18cNX8xussOPXSEoFxAARu8WriL8XgxPVUXBrWhz=FFg@mail.gmail.com> <4EC28CF5.6000109@jesup.org> <D666B5A5-BF2E-46B7-B97F-06C3736E8357@acmepacket.com> <CAOJ7v-3v5Zu9ZOuL3Qqu+aEDJ4a3cqH+oJ2yj_ewOpxKe=jA_g@mail.gmail.com> <733D6CE2-2360-4688-8268-3503F7E2460C@acmepacket.com> <9A05449A-C0FB-4548-AA80-728EC82218BB@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6C01CE9B22@inba-mail01.sonusnet.com> <4EC5C6FB.4040804@alvestrand.no> <6725A83E-0BB0-4F86-AB27-75027E317710@acmepacket.com> <4EC60963.8060508@alvestrand.no> <CALiegfmFizZ7zC55MCHVs_w6EO-FHfn2fSH4+yqCD5O82T3MTw@mail.gmail.com> <4EC63561.10909@skype.net> <CALiegfnraby3e_TKMj95VUvaEyg3deomL=yciw0EW13O5q9w5w@mail.gmail.com> <4EC6480D.7080505@skype.net> <CALiegfnCZMJ0GYpehD3XGsN=cGHHXMA1FFD5PfKSVRc7SYE+4w@mail.gmail.com> <4134053A-A1D9-4E52-9A53-3F5790A2F405@acmepacket.com> <CALiegfmm8HFO+ODU3RxCznam1512UdQnzW6iQrXKFCNWV73RPQ@mail.gmail.com> <CAD5OKxtQTgT5W4mECdc-O_ST7XFgjUmy_K-GxEJ27Jw-_2z9vw@mail.gmail.com> <CAOJ7v-3gYPjAKST_K9tvU4DAGHyyapujf8t9KeDMKE3geutQ=Q@mail.gmail.com>
Date: Fri, 18 Nov 2011 15:56:04 -0500
Message-ID: <CAD5OKxvDCtjtD4S9LjLb6SZ9QErsNCXCAKAXhr1cNJ=oBSY7jA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="bcaec54309b8c38cd104b20890ce"
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Support DTMF "codec" or expose DTMF in signaling? (Re: DTMF usecase before DTMF API)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2011 20:56:12 -0000

On Fri, Nov 18, 2011 at 3:02 PM, Justin Uberti <juberti@google.com> wrote:

> Can you make a proposal for what you'd like to see here? My view is that
> DTMF is a special case already, so the most pragmatic approach is a special
> case DTMF API.
>

DTMF is somewhat a special case due to fast payload switching. So, it might
need its own specific API.

What I was thinking is something a long the line of
sendCodecCommand(payloadType, JSONObject). In case of DTMF the JSON object
should have digitString and digitDuration parameters (maybe more, but this
is up for the group to decide if we want to specify pause duration and
volume). Having a CODEC specific command is helpful, since this will allow
control of codec specific options that can be changed without offer/answer,
such as encoder complexity or enabling decoder post processing filters,
without polluting the API.
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email