ULAW ALAW and RFC2833

I understand the need for using 2833 while using compression codecs. I
was wondering if anyone could tell me why 2833 is used with ULAW/ALAW.

Thanks in advance,
Scott

stawdema@yahoo.com wrote:

> I understand the need for using 2833 while using compression codecs. I
> was wondering if anyone could tell me why 2833 is used with ULAW/ALAW.

I hope this is not a homework question ;)

Think event speed and bandwidth reduction.

-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Thanks. No, not a homework question - just my wandering mind ;)  I just
re-read the
2833 spec and guess can make a case for robustness as well - like if
you drop a
packet in the midst of a long digit press.

Phil Frisbie, Jr. wrote:
> stawdema@yahoo.com wrote:
> 
>> I understand the need for using 2833 while using compression codecs. I
>> was wondering if anyone could tell me why 2833 is used with ULAW/ALAW.
> 
> 
> I hope this is not a homework question ;)
> 
> Think event speed and bandwidth reduction.

It doesn't help the former, and the latter would be pointless, as the 
tones are present for such a small part of the call.

There are several reasons for using RFC2833 with the high bit rate 
codecs. The most critical is it is much more tolerant of packet loss. A 
lost packet in the middle of a DTMF digit can break the digit into two. 
Used properly, RFC2833 can alleviate that kins of issue. The snag is, 
RFC2833 is often not used properly. A practical reason is a lot of boxes 
will only handle DTMF in one way. If that way happens to be RFC2833, 
then you just have to send that form, whatever codec you use.

Actually DTMF handling in VoIP is a horrible, horrible mess, and I'm 
sure whoever wrote RFC2833 had never used a telephone.

Steve