Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

"Asveren, Tolga" <tasveren@sonusnet.com> Fri, 04 March 2016 10:34 UTC

Return-Path: <tasveren@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9581B362F for <rtcweb@ietfa.amsl.com>; Fri, 4 Mar 2016 02:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKOLUqD9NMQL for <rtcweb@ietfa.amsl.com>; Fri, 4 Mar 2016 02:34:39 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D726B1B3633 for <rtcweb@ietf.org>; Fri, 4 Mar 2016 02:34:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=faSsWEE7+iyfMEqevOe6c7GFteT45yY2lCegg+VHNy0=; b=tOUGQ4c4p57J6w4/KLOxzEjN5z+9/cQegKiq21ZUARKX3RQxQfgPA4VuQZeWXbxMv7Wgd2t2v6xi48ndGkmOkjb1nvtWOlEAet1M/BupvQVQaZ72+StShVqTUEOgw0ZLBEplXUnZQtmz1uNhy+jlKcfj6eB2XnG1ak51zMupAlc=
Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 4 Mar 2016 10:34:10 +0000
Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Fri, 4 Mar 2016 10:34:11 +0000
From: "Asveren, Tolga" <tasveren@sonusnet.com>
To: Harald Alvestrand <harald@alvestrand.no>, Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciCAAdggAIAAwScAgAATEICAAEfAgIAACySAgAEinnA=
Date: Fri, 04 Mar 2016 10:34:10 +0000
Message-ID: <SN1PR0301MB15514E3DE966D04694948F16B2BE0@SN1PR0301MB1551.namprd03.prod.outlook.com>
References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <SN1PR0301MB15518F98FD31A3BAE6505079B2BB0@SN1PR0301MB1551.namprd03.prod.outlook.com> <56D55FE9.60408@alvestrand.no> <SN1PR0301MB15512FBBCA5186B4829FEFA8B2BB0@SN1PR0301MB1551.namprd03.prod.outlook.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <SN1PR0301MB1551D1333297368D66B150ACB2BB0@SN1PR0301MB1551.namprd03.prod.outlook.com> <CAD5OKxvf+HBknqxXXY=_t9sCFGUFMUczu6k5DkMS-M8aV0Sjxw@mail.gmail.com> <SN1PR0301MB1551006A8D73179743E85322B2BB0@SN1PR0301MB1551.namprd03.prod.outlook.com> <CA+9kkMBGzjJFbLpo4te12tpaFFS_aoEXmoARudkq1EbZ5AnuYw@mail.gmail.com> <SN1PR0301MB1551CDEEA6EA1C7A696972B7B2BB0@SN1PR0301MB1551.namprd03.prod.outlook.com> <CA+9kkMA++uB6p0QYgWtgYtd9ysa9F5jb2wZnSm=Q-Fgig06_zg@mail.gmail.com> <SN1PR0301MB15514DE72ED6C92766D32E80B2BD0@SN1PR0301MB1551.namprd03.prod.outlook.com> <56D824BD.2080305@alvestrand.no> <CAD5OKxvVZuyHqWDZCcbOAYJTzKoFA4cm1DvvHoe8Zjm4LTRh3w@mail.gmail.com> <56D86A45.70406@alvestrand.no>
In-Reply-To: <56D86A45.70406@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com;
x-originating-ip: [73.29.18.75]
x-ms-office365-filtering-correlation-id: 6840161c-e4be-4a20-9e41-08d344188642
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:H1lWOX37ncRGORgxKkD/uDTzUp9tOH/d49XiG+pTYkRoFe7Of8EmY2t5eBmpBH03JNzq1n2cJ3HqB2ZZmjfAolrWJDncxwx2qNlgRGy8zdfxCNxa3Lxobzo2joEhjDG091+7+vDZZvXeNj/6aq/tMA==; 24:P7x1MuVzNqVfBcantXbDQY6HQ0MSM62DUC8pBt1oajWKmQ7jNZaE66Z/RMmfgVDH1lXzWqPUZF2WdxmG2Qov9sTLQPjmABd8TVAl7he7GDI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552;
x-microsoft-antispam-prvs: <SN1PR0301MB155271EFABD1688CF150B40FB2BE0@SN1PR0301MB1552.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552;
x-forefront-prvs: 0871917CDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(2473001)(24454002)(164054003)(377454003)(13464003)(86362001)(5001770100001)(1220700001)(230783001)(93886004)(40100003)(1096002)(5003600100002)(50986999)(586003)(189998001)(74316001)(76576001)(81166005)(4326007)(3660700001)(99286002)(19580395003)(102836003)(2906002)(5008740100001)(92566002)(3846002)(3280700002)(6116002)(33656002)(106116001)(10400500002)(19580405001)(2900100001)(5004730100002)(66066001)(122556002)(2950100001)(54356999)(77096005)(76176999)(87936001)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sonusnet.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 10:34:10.9444 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/m439iUgLXUl9a9SlL9L1urvZMlw>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Mar 2016 10:34:42 -0000

i- I don't think satisfactory technical explanation is provided why "enforcing a range" is superior to a "default range". I will leave this here and obviously this is just my personal -but honest- opinion.

ii- I got confused about what WEBRTC WG refers to, maybe to W3C? If so, is rtcweb-audio specification only about browsers? I wouldn’t think so. There are other types of entities playing in the RTCWeb domain, e.g. gateways. The limits we are talking about, are they applicable only for digits sent by browsers? What about digits emitted by a native application or a gateway? Will a browser be able to accept them if they are out of the range (assuming that the final outcome is to use enforced ranges)?

iii- Just as an example, I am aware of systems, which can detect digits <40ms.

iv- What about the gap between the final packet (with E-bit set) retransmissions? 

v- As use cases for the need for longer duration (all these are based on the same deployment model: A "legacy" application controlled by phone needs to be extended so that it can be accessed by Internet connected devices, e.g. a web-book. DataChannel is not used, e.g. not supported by gateway, by application etc..., hence digits are used for control.

- TV gaming show
User registers for the game and is selected for that day's show.
The user sees what is happening on the game on his TV and controls it by digits
The game (balloon escape) requires that at the beginning the user pumps air into the balloon. This is done by continuously pressing "5"

- Remote valve/door/lock control
Authorized person makes a call and then continuously presses "6" to keep the valve/door/lock open for that period.

- Panic button
An application for women who are mistreated by their husbands. Police/Social service workers rush to the registered address if she presses "7" continuously for longer than 10 seconds.

I am just trying to show that there are many different/imaginative ways using the "digit UI".


Thanks,
Tolga

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Thursday, March 03, 2016 11:46 AM
> To: Roman Shpount <roman@telurix.com>
> Cc: Asveren, Tolga <tasveren@sonusnet.com>; Ted Hardie
> <ted.ietf@gmail.com>; Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com>; rtcweb@ietf.org
> Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt>
> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
> 
> Den 03. mars 2016 17:06, skrev Roman Shpount:
> > On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand
> > <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
> >
> >     You've made this argument before. I cannot see that anything new has
> >     been brought to the table that is likely to alter the WEBRTC WG
> >     consensus to have these enforced limits.
> >
> >
> > Am I correct to understand that WEBRTC WG decided that there should be
> > limits on DTMF tone generation and it is up to this group (IETF
> > rtcweb) to decide the exact values of these limits?
> 
> Formally, the RTCWEB group can advise the WEBRTC group about appropriate
> values, but in practice, the result is indistinguishable from your formulation :-
> )
> 
> > In this case, as I have stated before, the maximum tone duration
> > should be 8000 ms to match possible tone duration for RFC 2833 DTMF
> > tone. RFC
> > 2833 was in use for the past 15 years and no one reported any issues
> > with this limit.
> >
> > Minimum tone duration of 40 ms and minimum gap duration of 30 ms are
> > minimum physically required to transmit DTMF tone as 8 KHz audio
> > signal and still satisfy the talk-off specifications. These
> > limitations have not caused any practical issues for the past 50
> > years. I would like to mention that shorter tones are used during call
> > setup since it can be guaranteed that no audio signal is present and
> > talk-off requirements are relaxed. Furthermore VoIP only networks,
> > which use RFC 2833/RFC 4733 tones, can support tones and gaps of
> > anything from 0 ms and up. This is why I initially advocated for 0 ms
> > min duration. On the other hand if the group decides that removing one
> > more potential foot gun is more important, I will not be too upset.
> >
> > If anybody can come up with the practical example where tones longer
> > then 8 sec or shorter then 40 ms with less then 30 ms gaps are used,
> > please report them to the list. Otherwise, let's document what is in
> > W3C TR and move on.
> 
> Sounds good.