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

[Marc Petit-Huguenin <[e-mail]>]

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 <http://www.telurix.com/>
> 
> 
> On Fri, Apr 2, 2010 at 3:49 PM, Marc Petit-Huguenin <[e-mail]
> <mailto:[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>
>     <http://www.telurix.com>
>     >
>     >
>     > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene
>     <[e-mail] <mailto:[e-mail]>
>     > <mailto:[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]>
>     >     <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]> <mailto:[e-mail]
>     <mailto:[e-mail]>>;
>     >     [e-mail] <mailto:[e-mail]> <mailto:[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