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

[stephen botzko <[e-mail]>]

I am fine with your suggestions.

Stephen Botzko

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <[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]]
> Sent: Friday, April 02, 2010 4:50 PM
> To: Christian Hoene
> Cc: Michael Knappe; [e-mail]; [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
>
>
>
>