[asterisk-dev] app_alarmreceiver troubleshooting

[Dimitar Penev]

Hi Kaloyan,

With an ATA I have managed to receive the contact ID properly. 

Thank you
Dimitar
 
> On Wed, 13 Feb 2013 13:09:50 +0200, "Dimitar Penev" <dpn at switchvoice.com>
> wrote:
>> Hi Kaloyan,
>> 
>> Thanks for the pointers!
>> 
>>> 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.
>> Yes meanwhile I have found that you guys did some job around
>> alarmreceiver()
>> and I have tested the asterisk trunk. Unfortunately I got the same 
>> behaviour.
>> I have enabled the DTMF debuging and what I see is that asterisk gets
>> Mnually confirmed that the message sent is:
>> 1111181628010004
>> 
>> Asterisk detects:
>> 11111816280004 [pause] 11
>> Asterisk waits to get 16 digits in total and the last 11 is actually the
> 
>> next retry alarm pannel is sending
>> So it seems Asterisk is missing few tones at the end.
>> I have experiment with dtmf_hits_to_begin and dtmf_misses_to_end from 
>> dsp.conf with no improvement
>> 
> 
> Another possible cause of problems is if dtmf mode is not set to inband,
> but info or rfc2833. I had such problem with an ATA detecting the DTMFs
> instead of Asterisk and no changes in asterisk could help
> 
> Alarmpanels are sending very short tones and minor noise on the line may
> cause problems. The new version should (if sdtimeout is properly
> configured) should truncate the first event during the pause and (maybe)
> properly detect the next event.
> 
>>>
>>> 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
>> 
>> I have confirmed that my SIP link is using ulaw codec.
>> Or did I misundestood your remark?
> 
> With the new version it doesn't matter if it is ULAW or ALAW as long as
> there is no transcoding along the call path.
> 
>> To clarify on the picture I have sent on my first email 'Asterisk device
> 1'
>> is an embedded PBX runing Asterisk 1.4  and having FXS interface.
>> I am getting to the point that this device is modifying my TDM stream
>> and my alarmreceiver on the PC box is not what making the issues.
>> I will try with an ATA instead hopfully this time get my Contact ID 
>> recognized.
>> 
>> Thank you for the help!
>> Dimitar Penev
>