Subject: Re: [codec] #5: Mention DTMF in requirements, Testing DTMF?

From: Steve Underwood <[email-masked]>
Date: Fri, 02 Apr 2010 14:24:02 +0800

Hi,

I'm the author of the SpanDSP library people have referenced.

People seem to have only mentioned DTMF talk-off in these discussions, 
but the issue of corrupting the DTMF so it is less detectable is 
probably more of an issue.

Over the years there have been two reference data sets for testing DTMF 
talk off - the one from Mitel, and the one from Bellcore. Both started 
out as audio cassette tape products. The files I use for DTMF testing 
with SpanDSP are:

- A wave file produced by resampling to 8k samples/second the MP3 
version of the Mitel tape, which Mitel's heirs provide freely. If this 
is fed to TDM equipment it seems to give pretty much the same hits and 
near misses as the original Mitel cassette tape version. It seems, 
therefore, that aging of the original tape and transcription to MP3 have 
no unduly affected he signal.

- A set of wave files which were produced years ago from a pristine set 
of the Bellcore test tapes, using a cassette player with speed 
adjustment, so the pitch could be tweaked to be bang on target. Later, 
Telcordia/Bellcore stopped selling the tapes, and they gave me 
permission to hand out these files to a couple of people. Since they are 
transcribed from copyright tapes, I only handed them out where 
permission was sought. Now they seem to have introduced an audio CD 
version of the tapes.

You could use almost any long passages of speech for this kind of 
testing, but the above two data sets are the industry accepted ones, as 
you can compare different DTMF detectors reasonably well by comparing 
their false hits on this data. The Bellcore tapes are about 3 hours of 
audio, taken from the PSTN, where the call changes several times per 
seond. This is quite a tough test. The Mitel tape is about 30 minutes of 
audio passages recorded from the PSTN. Here they change the call every 
sentance or two, so the character os the test is somewhat different. It 
is much easier to get a good result with the Mitel tape, for various 
reasons, although I have found the Mitel tape a pretty good one for 
exercising talk-off issues in things like 2280Hz and 2600Hz signalling 
tone detectors.

The detection performance of DTMF detectors is usually quoted by their 
performance against the other data Mitel provided - a set of DTMF digits 
with various distortions of level, frequency and noise component. I took 
the spec for that data, and built a test suite which synthesises the 
relevant signals more precisely than the recordings on the Mitel tape. I 
encourage anyone interested in DTMF to make use of that work.

Regards,
Steve

On 03/29/2010 06:17 AM, Wyss, Felix wrote:
>
> Christian,
>
> Telcordia sells the "Bellcore tape" DTMF talk-off immunity test 
> recordings as a set of 3 CDs:
>
> http://telecom-info.telcordia.com/site-cgi/ido/docs.cgi?ID=SEARCH&DOCUMENT=FR-763-01 
> <http://telecom-info.telcordia.com/site-cgi/ido/docs.cgi?ID=SEARCH&DOCUMENT=FR-763-01>
>
> --Felix
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Christian Hoene
> *Sent:* Sunday, March 28, 2010 10:22
> *To:* [email-masked]
> *Subject:* Re: [codec] #5: Mention DTMF in requirements, Testing DTMF?
>
> Hi,
>
> I found some open source DTMF code at
>
> http://www.soft-switch.org/spandsp-modules.html
>
> Does anybody has access to nice DTMF sample files such as those 
> describe in
>
> http://www.soft-switch.org/spandsp_faq/ar01s13.html ?
>
> Christian
>
> ---------------------------------------------------------------
>
> 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:* Michael Knappe [mailto:[email-masked]]
> *Sent:* Friday, March 26, 2010 11:38 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [codec] #5: Mention DTMF in requirements
>
> I would agree with 'should'. Lot's of dtmf out there still, but also 
> out of band options (rfc 2833 / 4733) that make in-band carriage less 
> a concern for SIP telephony applications.
>
> Mik
>
> ------------------------------------------------------------------------
>
> *From*: [email-masked] <[email-masked]>
> *To*: Christian Hoene <[email-masked]>
> *Cc*: [email-masked] <[email-masked]>
> *Sent*: Fri Mar 26 18:10:31 2010
> *Subject*: Re: [codec] #5: Mention DTMF in requirements
>
> Perhaps analog DTMF carriage is a SHOULD?
>
> I agree that out-of-band is preferable, however, there still are 
> scenarios where coded DTMF tones will be sent.  It would be nice 
> (though IMHO not essential) for this carriage to work.
>
> Stephen Botzko
>
> On Fri, Mar 26, 2010 at 3:04 PM, Christian Hoene 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Hi,
>
>
> > If the point of this issue to allow this codec to be used to 
> successfully
> > transit an IP network between two TDM networks,
>
> which is not the primary use-case.
>
>
> > I'd suggest that out-of-
> > band tone transport is far preferable to trying to ensure that the codec
> > will carry the tones adequately to allow them to be detected after
> > regeneration.
>
> I totally agree. Out-of-band is much better than inband.
>
> Sorry for my radical view but I believe that analog DTMF is an old and 
> obsolete technology not worth considering anymore.
>
> Christian
>
>

---

From: Steve Underwood <[email-masked]>
Date: Fri, 02 Apr 2010 14:26:57 +0800

On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote:
> On 03/28/2010 11:00 AM, stephen botzko wrote:
>    
>> I would agree with this if I saw reasonable evidence that a
>> preponderance of gateways and sending systems provide the signaling in
>> these RFCs.
>>
>> Since I am not sure that this is the case, I am unconvinced that we can
>> totally remove the requirement.
>>
>> I'd also say that an encoder that detects the DTMF tones and outputs the
>> RFC 4733/34 events would fully meet the requirement.
>>      
> As former CTO of a VoIP provider, I never saw a PSTN provider not supporting at
> least RFC 2833 (even if one of them did not declare it in its SDP)
>
> Perhaps the question can be asked at the next SIPit event.
>    
Its true that RFC2833 is widely deployed. Its even true that many 
systems have updated to RFC4733. Sadly, its also true that there are 
still many quirky implementations widely deployed, and a lot of people 
still need to interwork with audio DTMF.

Steve

---

From: James Rafferty <[email-masked]>
Date: Fri, 2 Apr 2010 09:48:35 -0400

I'd agree with Steve that are still many deployments which do not use RFC 2833 or RFC 4733. In our gateways, we've had to support interworking variations of tone support such as INFO and in-band, in addition to the RFC 2833 / RFC 4733.  

James
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Underwood
Sent: Friday, April 02, 2010 2:27 AM
To: [email-masked]
Subject: Re: [codec] #5: Mention DTMF in requirements

Steve

_______________________________________________
codec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/codec

---

From: stephen botzko <[email-masked]>
Date: Fri, 2 Apr 2010 09:53:55 -0400

Are you two suggesting that in-band DTMF is a MUST?  Or alternatively a
SHOULD?

Stephen Botzko

On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty
<[email-masked]>wrote:

> I'd agree with Steve that are still many deployments which do not use RFC
> 2833 or RFC 4733. In our gateways, we've had to support interworking
> variations of tone support such as INFO and in-band, in addition to the RFC
> 2833 / RFC 4733.
>
> James

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Apr 2010 07:57:10 -0600

How is the never-ending debate among DTMF signalling *methods* in-scope
for the Codec WG? I think that Henning brought this up in Anaheim only
to make sure that we test some DTMF tones. The signalling method is out
of scope for the codec itself.

On 4/2/10 7:53 AM, stephen botzko wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I'd agree with Steve that are still many deployments which do not
>     use RFC 2833 or RFC 4733. In our gateways, we've had to support
>     interworking variations of tone support such as INFO and in-band, in
>     addition to the RFC 2833 / RFC 4733.
> 
>     James
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of Steve Underwood
>     To: [email-masked] <mailto:[email-masked]>

---

From: James Rafferty <[email-masked]>
Date: Fri, 2 Apr 2010 09:59:06 -0400

Stephen,

I'd suggest SHOULD.  Using RFC 2833 / RFC 4733 is preferred to ensure passage, but if the DTMF can be passed in native form and still be detectable, that would be a big plus.

James
From: stephen botzko [mailto:[email-masked]]
Sent: Friday, April 02, 2010 9:54 AM
To: James Rafferty
Cc: Steve Underwood; [email-masked]
Subject: Re: [codec] #5: Mention DTMF in requirements

Are you two suggesting that in-band DTMF is a MUST?  Or alternatively a SHOULD?

Stephen Botzko
On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty <[email-masked]<mailto:[email-masked]>> wrote:
I'd agree with Steve that are still many deployments which do not use RFC 2833 or RFC 4733. In our gateways, we've had to support interworking variations of tone support such as INFO and in-band, in addition to the RFC 2833 / RFC 4733.

James
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Steve Underwood
Sent: Friday, April 02, 2010 2:27 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [codec] #5: Mention DTMF in requirements

Steve

_______________________________________________
codec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/codec
_______________________________________________
codec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/codec

---

From: stephen botzko <[email-masked]>
Date: Fri, 2 Apr 2010 10:01:42 -0400

I heard no decision as to DTMF tone encoding.

As far as I am concerned, the question of whether the codec MUST encode DTMF
tones accurately enough to be detected at the decoder output (or SHOULD or
non-requirement) is still open.

That question clearly is in-scope, and has nothing to do with signaling.

Stephen Botzko

---

From: Brian West <[email-masked]>
Date: Fri, 2 Apr 2010 09:07:34 -0500

I think SHOULD and MAY must not be used in any DRAFT or RFC it leaves room for argument and ambiguous interpretations which lead to incompatibilities (case in point SIP).  As for DTMF, I would note that any method that works could be used and mandating anything is really outside the scope of the codec itself.  You have INFO, KPML, 2833 or In-Band.  Granted if the codec is too lossy in-band is pointless and unreliable.  And if you wish this to scale to any degree server side in-band should be DISALLOWED.  And you would think 2833 is the wise choice... but then again the MAY and SHOULD word screwed that up.

/b

---

From: Brian West <[email-masked]>
Date: Fri, 2 Apr 2010 09:08:14 -0500

I couldn't agree more.  That was my first thought when the thread initially started.

/b

---

From: Brian West <[email-masked]>
Date: Fri, 2 Apr 2010 09:08:36 -0500

There is that word again... SHOULD.  strike that from the draft along with MAY.

/b

On Apr 2, 2010, at 8:59 AM, James Rafferty wrote:

> Stephen,
>  
> I’d suggest SHOULD.  Using RFC 2833 / RFC 4733 is preferred to ensure passage, but if the DTMF can be passed in native form and still be detectable, that would be a big plus. 
>  
> James

---

From: Brian West <[email-masked]>
Date: Fri, 2 Apr 2010 09:10:11 -0500

But Codecs themselves do not detect DTMF.  Thats the job of the DTMF detector.  NOT the codec.  In all my work with codecs I have not once seen one that knows anything about DTMF.  And if the codec is too lossy inband is out of the question.

/b

On Apr 2, 2010, at 9:01 AM, stephen botzko wrote:

> As far as I am concerned, the question of whether the codec MUST encode DTMF tones accurately enough to be detected at the decoder output (or SHOULD or non-requirement) is still open.
>

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 2 Apr 2010 16:21:18 +0200

Hi guys,

just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#History) is definitely out of scope?

Christian

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian West
>Sent: Friday, April 02, 2010 4:10 PM
>To: stephen botzko
>Cc: [email-masked]
>But Codecs themselves do not detect DTMF.  Thats the job of the DTMF detector.  NOT the codec.  In all
>my work with codecs I have not once seen one that knows anything about DTMF.  And if the codec is too
>lossy inband is out of the question.
>
>/b
>
>> As far as I am concerned, the question of whether the codec MUST encode DTMF tones accurately enough
>to be detected at the decoder output (or SHOULD or non-requirement) is still open.
>>

---

From: James Rafferty <[email-masked]>
Date: Fri, 2 Apr 2010 10:26:59 -0400

Christian, 

I'd agree that testing fax should be out of scope.  

Lots of reasons why, but I won't get into that here.  

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Hoene
Sent: Friday, April 02, 2010 10:21 AM
To: [email-masked]
Subject: Re: [codec] #5: Mention in requirements, FAX?

Hi guys,

Christian

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 02 Apr 2010 07:33:16 -0700

> just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#History) is definitely out of scope?

And V8bis? V.21? V.25? V.32/V32bis?  V.18?  SS5?

All this stuff should be out of scope and the text should say that terminals
that needs this MUST do it out of band, so no tests are needed.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Michael Knappe <[email-masked]>
Date: Fri, 2 Apr 2010 07:48:25 -0700

Agreed. In-band fax carriage should not be in the scope of the codec, and
the automated switchover to mechanisms like T.38 should also be outside the
scope of our work.

Mike

---

From: stephen botzko <[email-masked]>
Date: Fri, 2 Apr 2010 10:59:01 -0400

Perhaps we are using "scope" for two different things?  For me, "out of
scope" means outside the working group charter.

"in-band fax carriage" is in scope from a charter perspective, though I
agree it is a non-requirement for the codec.

Automated switchover is clearly outside the charter, so it is out of scope
(in my definition).

The reason this might matter:  Things that are "out of scope" of the charter
shouldn't be discussed on the list at all.  Debates about non-requirements
and requirements of course should be on the list.

Stephen Botzko

On Fri, Apr 2, 2010 at 10:48 AM, Michael Knappe <[email-masked]> wrote:

> >> just for the notes. Testing Fax (
> http://en.wikipedia.org/wiki/Fax#History) is
> >> definitely out of scope?
> >
> >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >>> Brian West
> >>> my work with codecs I have not once seen one that knows anything about
> DTMF.
> >>> And if the codec is too
> >>>> As far as I am concerned, the question of whether the codec MUST
> encode
> >>>> DTMF tones accurately enough
> >>> to be detected at the decoder output (or SHOULD or non-requirement) is
> still
> >>> open.
> >>>>

---

From: Michael Knappe <[email-masked]>
Date: Fri, 2 Apr 2010 08:01:29 -0700

Yes, excellent clarification, agreed.

Mike

On 4/2/10 7:59 AM, "stephen botzko" <[email-masked]> wrote:

Perhaps we are using "scope" for two different things?  For me, "out of scope" means outside the working group charter.

"in-band fax carriage" is in scope from a charter perspective, though I agree it is a non-requirement for the codec.

Automated switchover is clearly outside the charter, so it is out of scope (in my definition).

The reason this might matter:  Things that are "out of scope" of the charter shouldn't be discussed on the list at all.  Debates about non-requirements and requirements of course should be on the list.

Stephen Botzko

Mike

---

From: "Raymond (Juin-Hwey) Chen" <[email-masked]>
Date: Fri, 2 Apr 2010 11:54:00 -0700

(Responding to an earlier email on this topic...)

I think the issue here is not for a codec to detect DTMF, but for a codec to encode and decode the DTMF waveform with sufficient fidelity so it will not cause DTMF detection problems later in a DTMF detector.  

Although most codecs do not explicitly make use of DTMF properties to improve their coding fidelity with DTMF waveforms, a codec developer can indeed test a codec by passing DTMF tones through the codec followed by a DTMF detector and try to tune or otherwise improve the codec so that it minimizes the DTMF detection error rate as seen by the DTMF detector.  In fact, this is exactly what we have done when we developed the BV16 codec, and as a result of such testing and tuning, we were indeed able to modify the BV16 codec algorithm to improve the DTMF detection error rate after DTMF tones were passed through BV16 and then detected by a commercial DTMF detector.  Such DTMF pass-through test results of BV16, G.711, G.728, G.729E, and G.729 are described in our BroadVoice16 paper in the Proceedings of the 40th Asilomar Conference on Signals, Systems and Computers, 2006, available at our BroadVoice website www.broadcom.com/broadvoice.  That's why I could answer with confidence the DTMF pass-through question raised right after my BroadVoice codec presentation at our IETF 77 codec WG meeting on March 22.

I think in those conditions where out-of-band DTMF signaling is not available or is not implemented properly, it is crucial for the codec to pass DTMF tones through without causing significant increase of the DMTF detection error rate in a DTMF detector downstream, otherwise you may not even be able to get the correct telephone number through, or a credit card number or key press responses to a voice response system (press 1 for this, press 2 for that,...) may not go through correctly. That's why we went through the trouble of testing BV16 with DTMF tones and modifying BV16 to minimize the DTMF detection error rate, and that's why I agree with Stephen's comments below.

Raymond

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian West
Sent: Friday, April 02, 2010 7:10 AM
To: stephen botzko
Cc: [email-masked]
Subject: Re: [codec] #5: Mention DTMF in requirements

/b

---

From: "Wyss, Felix" <[email-masked]>
Date: Fri, 2 Apr 2010 16:00:41 -0400

I agree with those who question the value of catering to in-band DTMF for this codec.  Doing so will invariably require compromises somewhere else (quality/birate, CPU cost, coding delay, development/testing effort, code complexity, etc.)  Do we really expect that by the time this codec will be standardized and in wide use there will still be VoIP providers or devices that do not support RFC#2833 -- yet who do support this new codec? 

--Felix

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Raymond (Juin-Hwey) Chen
> Sent: Friday, April 02, 2010 14:54
> To: Brian West; stephen botzko
> Cc: [email-masked]
> I think the issue here is not for a codec to detect DTMF, but for a codec
> to encode and decode the DTMF waveform with sufficient fidelity so it will
> not cause DTMF detection problems later in a DTMF detector.
> 
> Although most codecs do not explicitly make use of DTMF properties to
> improve their coding fidelity with DTMF waveforms, a codec developer can
> indeed test a codec by passing DTMF tones through the codec followed by a
> DTMF detector and try to tune or otherwise improve the codec so that it
> minimizes the DTMF detection error rate as seen by the DTMF detector.  In
> fact, this is exactly what we have done when we developed the BV16 codec,
> and as a result of such testing and tuning, we were indeed able to modify
> the BV16 codec algorithm to improve the DTMF detection error rate after
> DTMF tones were passed through BV16 and then detected by a commercial DTMF
> detector.  Such DTMF pass-through test results of BV16, G.711, G.728,
> G.729E, and G.729 are described in our BroadVoice16 paper in the
> Proceedings of the 40th Asilomar Conference on Signals, Systems and
> Computers, 2006, available at our BroadVoice website
> www.broadcom.com/broadvoice.  That's why I could answer with confidence
> the
>  DTMF pass-through question raised right after my BroadVoice codec
> presentation at our IETF 77 codec WG meeting on March 22.
> 
> I think in those conditions where out-of-band DTMF signaling is not
> available or is not implemented properly, it is crucial for the codec to
> pass DTMF tones through without causing significant increase of the DMTF
> detection error rate in a DTMF detector downstream, otherwise you may not
> even be able to get the correct telephone number through, or a credit card
> number or key press responses to a voice response system (press 1 for
> this, press 2 for that,...) may not go through correctly. That's why we
> went through the trouble of testing BV16 with DTMF tones and modifying
> BV16 to minimize the DTMF detection error rate, and that's why I agree
> with Stephen's comments below.
> 
> Raymond
> 
> But Codecs themselves do not detect DTMF.  Thats the job of the DTMF
> detector.  NOT the codec.  In all my work with codecs I have not once seen
> one that knows anything about DTMF.  And if the codec is too lossy inband
> is out of the question.
> 
> /b
> 
> > As far as I am concerned, the question of whether the codec MUST encode
> DTMF tones accurately enough to be detected at the decoder output (or
> SHOULD or non-requirement) is still open.
> >

---

From: "Raymond (Juin-Hwey) Chen" <[email-masked]>
Date: Fri, 2 Apr 2010 14:15:17 -0700

If I remember it correctly, at least for our BV16 codec, modifying it to improve DTMF pass-through performance did not really hurt the codec's performance in coding speech.  Obviously I can't guarantee that the same will be true for all other codecs.

I can imagine that if a codec has a frame size of 20 or 30 ms, it will probably be more difficult than lower-delay codecs to pass DTMF signals without affecting DTMF detection performance. This is especially true for the G.720-specified 50 ms on, 40 ms off DTMF tone duration, because generally the codec frame boundaries do not coincide with the DTMF on/off time instants, so for the beginning frame and the ending frame of the codec where the DTMF signal only occupies part of the frame, the codec usually cannot reproduce the DTMF signal well.  That makes the remaining middle portion of the DTMF pulse (which can be coded better) too short for the DTMF detector downstream to decode the DTMF digits reliably.  This is especially true for the corner case of 50 ms on duration specified in G.720.  In our BroadVoice16 paper, we observed that most real-world DTMF signals we captured have an on duration between 90 and 160 ms, so longer codec frame size will be less of a problem there.  

In any case, low-delay codecs with a small frame size definitely have an advantage over longer-delay codecs for passing DTMF signals.  If you start with a low-delay codec anyway (like what we did with BV16), then tuning the codec to reduce DTMF detection error rate does not necessarily mean you have to take a hit in speech quality, bit-rate, etc.

Raymond

-----Original Message-----
From: Wyss, Felix [mailto:[email-masked]] 
Sent: Friday, April 02, 2010 1:01 PM
To: Raymond (Juin-Hwey) Chen; Brian West; stephen botzko
Cc: [email-masked]
Subject: RE: [codec] #5: Mention DTMF in requirements

--Felix

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Fri, 02 Apr 2010 21:57:22 -0400

Michael Knappe wrote:
> I would agree with 'should'. 

I think DTMF should be ignored entirely as far as requirements.  If
someone wishes to perform tests, they are welcome to do so and present
results, but there is no need to require anything.

> Lot's of dtmf out there still, but also out of band options (rfc 2833 / 4733) that make in-band carriage less a concern for SIP telephony applications.

There are many different machine-to-machine communications systems that
have been designed to operate over channels that also carry audio.  We
should not attempt to support any of them.  The only purpose of this codec
should be to carry sounds to a human ear.

Any machine-to-machine communications SHOULD be decoded from the stream
prior to compression and transmitted independently.  Any system that
encodes using the IWAC has access to the input stream, and so can perform
any required decoding (of rotary clicks, DTMF, fax, DRM watermark, V.42,
ZX Spectrum cassette, etc.) at that time.

Decoders MAY do whatever they want with the output stream, but any use
other than listening by a human should be unsupported.

--Ben

---

From: Roman Shpount <[email-masked]>
Date: Fri, 2 Apr 2010 22:10:10 -0400

+1
_____________
Roman Shpount

On Fri, Apr 2, 2010 at 9:57 PM, Benjamin M. Schwartz <
[email-masked]> wrote:

> > Lot's of dtmf out there still, but also out of band options (rfc 2833 /
> 4733) that make in-band carriage less a concern for SIP telephony
> applications.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Apr 2010 20:17:50 -0600

Agreed, this seems unnecessary. We have more important things to focus
on for now. :)

On 4/2/10 8:10 PM, Roman Shpount wrote:
> +1
> _____________
> Roman Shpount
> 
> 
> On Fri, Apr 2, 2010 at 9:57 PM, Benjamin M. Schwartz
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Michael Knappe wrote:
>     > Lot's of dtmf out there still, but also out of band options (rfc
>     2833 / 4733) that make in-band carriage less a concern for SIP
>     telephony applications.
>