[MEDIACTRL] MRB: DTMF Support
Eric Burger <eburger@standardstrack.com> Tue, 23 February 2010 12:25 UTC
Return-Path: <eburger@standardstrack.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BAF28C1BF for <mediactrl@core3.amsl.com>; Tue, 23 Feb 2010 04:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level:
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvx3VCTD+gPY for <mediactrl@core3.amsl.com>; Tue, 23 Feb 2010 04:25:46 -0800 (PST)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 0EA9A28C114 for <mediactrl@ietf.org>; Tue, 23 Feb 2010 04:25:46 -0800 (PST)
Received: from rrcs-24-199-33-18.west.biz.rr.com ([24.199.33.18] helo=[10.0.0.115]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1Njtrf-0007Y1-U1 for mediactrl@ietf.org; Tue, 23 Feb 2010 04:27:48 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Feb 2010 04:27:47 -0800
Message-Id: <6669E357-2C50-4F87-90F8-C5AAB1AF851F@standardstrack.com>
To: mediactrl@ietf.org
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [MEDIACTRL] MRB: DTMF Support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2010 12:25:46 -0000
A question came up during the review of MRB. Currently, one of the values for DTMF support in the consumer and media server interface API is "INFO". There are at least three incompatible INFO usages for transporting DTMF and we are about to get a fourth. More importantly, I am not aware of any media server that can consume or generate INFO's for DTMF transport. Anyone mind if we drop the "INFO" value for DTMF support? The editors put it in just because they were thinking, "how does DTMF go through networks?" not "how do media servers see and handle DTMF?" Note that by "INFO for DTMF," we mean the use of an INFO method to transport the digit information. We do NOT mean the use of a media control protocol over INFO. Thus, while both MSCML and MSML use INFO to *report* digits, they do NOT use INFO to *transport* digits. So, a quick poll (responses requested!): 1. Does your media server accept or generate INFO for DTMF transport? 1a. If Yes to #1, what INFO payload format and how do you determine what payload to receive / send? 2. Would you miss removing INFO as a value for DTMF transport?
- [MEDIACTRL] MRB: DTMF Support Eric Burger