[asterisk-dev] app_alarmreceiver troubleshooting

[Kaloyan Kovachev]

On Wed, 13 Feb 2013 10:51:26 +0100, "Olle E. Johansson" <oej at edvina.net>
wrote:
> 13 feb 2013 kl. 10:42 skrev Kaloyan Kovachev <kkovachev at varna.net>:
> 
>> Hi,
>> 
>> On Tue, 12 Feb 2013 23:57:53 +0200, "Dimitar Penev"
<dpn at switchvoice.com>
>> wrote:
>>> Hi All,
>>> 
>>> I have issue with an app_alarmreceiver() on my PC with
asterisk-1.8.7.2
>>> 
>> 
>> There are mane bugfixes and new features for app_alarmreceiver() in
>> Asterisk 11. Please test with the latest version as you issues may have
>> been fixed already.
>> 

I stand corrected even Asterisk 11 has the old code - trunk has the
cleanup and fixes

>> P.S.
>> as a side note you are most likely using ALAW, while
app_alarmreceiver()
>> from asterisk-1.8.7.2 has only ULAW - this is the most likely reason
for
>> your DTMF problems
> 
> That's new to me. I've been using alarmreceiver with ALAW, but maybe I
was
> lucky.
> What part of the code is ulaw-specific, Kaloyan?
> 

The old version used its own frequency generation routines in
make_tone_burst() and send_tone_burst() which builds ULAW data. Also in
alarmreceiver_exec() read and write formats are forced to ULAW.

If the other end is an FXO terminal adapter (for example) capable of ALAW
and ULAW the call is just silently switched to ULAW and no transcoding
takes place, but in case of digital dahdi channel (SS7 in my case) DTMF
detection does not work well - that's why in trunk alarmreceiver_exec()
switches to the old default ULAW only if the call is not already in ALAW or
ULAW, which was possible after switching to the built in ast_playtones_XXX
calls

> Curious.
> 
> /O
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev