Re: [codec] #5: Mention DTMF in requirements

[Roman Shpount <[e-mail]>]

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.

Comfort noise is a different animal altogether. First of all, I think CN is
covered by IPR licensing from G.729. 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.
_____________________________
Roman Shpount - www.telurix.com


On Fri, Apr 2, 2010 at 3:49 PM, Marc Petit-Huguenin <[e-mail]>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 <http://www.telurix.com>
> >
> >
> > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Stephan,
> >
> >     Comments inline:
> >
> >
> >     ---------------------------------------------------------------
> >     Dr.-Ing. Christian Hoene
> >     Interactive Communication Systems (ICS), University of Tübingen
> >     Sand 13, 72076 Tübingen, Germany, Phone [phone]
> >     http://www.net.uni-tuebingen.de/
> >
> >     From: stephen botzko [mailto:[e-mail]
> >     <mailto:[e-mail]>]
> >     Sent: Friday, April 02, 2010 4:50 PM
> >     To: Christian Hoene
> >     Cc: Michael Knappe; [e-mail] <mailto:[e-mail]>;
> >     [e-mail] <mailto:[e-mail]>
> >     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: [e-mail]
> Professional email: [e-mail]
> Blog: http://blog.marc.petit-huguenin.org
>