Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58623A6AD6 for ; Fri, 2 Apr 2010 13:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.111 X-Spam-Level: X-Spam-Status: No, score=-99.111 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 mwF3GmL42d03 for ; Fri, 2 Apr 2010 13:57:39 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 5A73C3A68C8 for ; Fri, 2 Apr 2010 13:42:56 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 969BCDC0401A; Fri, 2 Apr 2010 20:43:29 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 9B730DC04018; Fri, 2 Apr 2010 20:43:28 +0000 (UTC) Message-ID: <4BB656F0.5080305@acm.org> Date: Fri, 02 Apr 2010 13:43:28 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100307 Iceowl/1.0b1 Icedove/3.0.3 MIME-Version: 1.0 To: Roman Shpount References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> <4BB64A39.80509@acm.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:57:40 -0000 On 04/02/2010 01:25 PM, Roman Shpount wrote: > This was somewhat my point: instead of figuring out how to encode > telephone signals in the CODEC encode them using these standards. If we > need to make this robust in situations when these CODECs are not > available we can include a pass though mechanism for their content in > the CODEC itself (even though I really think this is a bad idea). > Whatever we are going to do to encode telephony signals would probably > be worse quality, less robust and consume more bandwidth then the > existing work. Not sure why we need to recreate it. Sorry, I misunderstood you then. I thought that you were proposing to use a different type of frame inside the codec to carry the DTMF. > > Comfort noise is a different animal altogether. First of all, I think CN > is covered by IPR licensing from G.729. I cannot find any IPR disclosure for RFC 3389 or draft-ietf-avt-rtp-cn. If you think that there should be one, then you should fill a third-party IPR disclosure. > Furthermore, unless I am > mistaken, it is narrow band. I heard suggestions about using AMR-WB > comfort noise for wide band, but this once again might be covered by > AMR-WB IPR. I do not see why RFC 3389 would not be used fine for the Internet wideband codec. There is an example for use with G.722.1: m=audio 49230 RTP/AVP 101 102 a=rtpmap:101 G7221/16000 a=fmtp:121 bitrate=24000 a=rtpmap:102 CN/16000 > _____________________________ > Roman Shpount - www.telurix.com > > > On Fri, Apr 2, 2010 at 3:49 PM, Marc Petit-Huguenin > wrote: > > On 04/02/2010 12:02 PM, Roman Shpount wrote: > > This is all wonderful, but what seems to be missing here is any > type of > > standard test for DTMF tone detection. We have a number of tests for > > things that should not be detected as DTMF (various talk-off > tapes), but > > there is no test with samples of valid DTMF signals. In real world you > > get quite a variety of tones that different handsets or telephone > > devices generate when a digit is pressed. Some of those tones are > almost > > at border line conditions for a valid DTMF tone. > > > > Second issue, which was already mentioned here, would be > performance of > > DTMF tone detector in the presence of packet loss or time stretching > > caused by jitter buffer. Those things, even if they do not prevent > DTMF > > detection, are almost guaranteed to split a single long tone in two. > > > > Finally, we seemed to concentrate on DTMF tones only, but in > reality all > > the signaling/special tones are quite important. Fax Send/Receive > tones > > come to mind almost immediately as tones that are typically detected > > inband (very few gateways encode those tones using RFC 4733/2833) > > > > I think we should formulate this requirement not in terms of DTMF tone > > but in terms of accuracy of reproduction of periodic signals in > > specified frequency ranges. To be honest, the most robust solution > would > > be to incorporate RFC4733/4744 as a part of the codec in a manner > > similar to comfort noise frames. > > Why would you want to do that, when there is perfectly good > *Internet* codecs > for telephony signals (RFC 4733, RFC 4734 and RFC 5244) and comfort > noise (RFC > 3389)? > > > _____________________________ > > Roman Shpount - www.telurix.com > > > > > > > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > > > >> > wrote: > > > > Hi Stephan, > > > > Comments inline: > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of Tübingen > > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > > http://www.net.uni-tuebingen.de/ > > > > From: stephen botzko [mailto:stephen.botzko@gmail.com > > > >] > > Sent: Friday, April 02, 2010 4:50 PM > > To: Christian Hoene > > Cc: Michael Knappe; stpeter@stpeter.im > >; > > codec@ietf.org > > > Subject: Re: [codec] #5: Mention DTMF in requirements > > > > (a) "MUST NOT" means that it must fail. Perhaps you meant "need > > not" or "might not"? > > > > CH: Yes, I meant need not (or the German „muss nicht“) > > > > (b) SHOULD is commonly used in establishing requirements, and it > > certainly was used in MARTINI and other working groups at > IETF77 in > > requirements presentations with no confusion. It has a clear > meaning > > in the requirements context (desirable but not essential) and I > > see no reason to avoid its use at this phase. There will > certainly > > be other things that are "nice to have", and it is appropriate > > to track them and consider them in the selection/standardization > > process. > > > > CH: Better? "The codec SHOULD support the transmission DTMF at > most > > transmission conditions." > > > > I agree that language about DTMF might not need to be in the final > > RFC. Though if DTMF quality is known to be inadequate, it > > probably makes sense to tell people that. > > > > CH: Agreed. The limits of the codec shall be clearly stated. > > > > I also agree to the obvious comment that DTMF detection > methods are > > out of scope. > > > > CH: Agreed. > > > > CH: Isn't time to include the MUST requirement for DTMF > testing and > > SHOULD requirement for transmission support into the > > requirements document. > > Then, we could close issue #5 and continue with other things. > > > > Christian -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org