Asterisk 13.26 - Alarm Receiver incomplete string in some cases

Hello,

I am currently working on an Asterisk server that receives a Contact ID from a device and then, if the device sends the 606 event, a voip call starts.

The issue is that sometimes the server doesn’t recognises the Contact ID. I know that it can be a number of things including the line used (PSTN to VoIP) , but I am trying to see if there are solutions that I can try on the Asterisk before having to call the number service provider or saying to the customer that his line doesn’t work with our solution…

The dialplan is nothing out of the ordinary:

[alarm-receiver]
exten => s,1,Noop(Starting Alarm Receiver)
;same => n,Set(VOLUME(TX)=3)
same => n,Set(VOLUME(RX)=2)
same => n,Set(CALLERID(name)=${CALLERID(num)})
same => n,Wait(1)
same => n,Set(ALARMRECEIVER_CALL_LIMIT=40000)
same => n,AlarmReceiver
same => n,Set(ConfNum=${CALLERID(num)})
same => n,Set(RecordFile=/var/lib/recordings/${FILE})
same => n,Set(CONFBRIDGE(bridge,record_file)=${RecordFile})
same => n,Set(CONFBRIDGE(bridge,record_conference)=yes)
same => n,ConfBridge(${ConfNum},,sirep_user)
same => n,Wait(3)
same => n,SendDTMF(9,,500)
same => n,Hangup

The alarmreceiver.conf is configured like this:

[general]
timestampformat = %a %b %d, %Y @ %H:%M:%S %Z
;
; Specify a spool directory for the event files. This setting is required
; if you want the app to be useful. Event files written to the spool
; directory will be of the template event-XXXXXX, where XXXXXX is a random
; and unique alphanumeric string.
;
; Default is none, and the events will be dropped on the floor.
;

eventspooldir = /var/lib/alarm
logindividualevents = no

;
; The timeout for receiving the first DTMF digit is adjustable from 1000 msec.
; to 10000 msec. The default is 2000 msec. Note: if you wish to test the
; receiver by entering digits manually, set this to a reasonable time out
; like 10000 milliseconds.

fdtimeout = 2000

;
; The timeout for receiving subsequent DTMF digits is adjustable from
; 110 msec. to 4000 msec. The default is 200 msec. Note: if you wish to test
; the receiver by entering digits manually, set this to a reasonable time out
; like 4000 milliseconds.
;

sdtimeout = 1000

;
; Wait for the connection to settle post-answer. Adjustable from 500 msec. to 10000 msec.
; The default is 1250 msec.
;

answait = 1250

; When logging individual events it may be desirable to skip grouping of metadata

;no_group_meta = yes

;
; The loudness of the ACK and Kissoff tones is adjustable from 100 to 8192.
; The default is 8192. This shouldn't need to be messed with, but is included
; just in case there are problems with signal levels.
;

loudness = 8192

;
; The db-family setting allows the user to capture statistics on the number of
; calls, and the errors the alarm receiver sees. The default is for no
; db-family name to be defined and the database logging to be turned off.
;

;db-family = yourfamily:

;
; End of alarmreceiver.conf

The only change is the sdtimeout.

An example from the same PSTN line:

(In the same call)
[Dec 26 18:00:57] VERBOSE[7567][C-000e9412] app_alarmreceiver.c: AlarmReceiver: Incomplete string: 07251811010001, trying again…
[Dec 26 18:00:58] VERBOSE[7568][C-000e9413] app_alarmreceiver.c: AlarmReceiver: Incomplete string: , trying again…
[Dec 26 18:01:01] VERBOSE[7567][C-000e9412] app_alarmreceiver.c: AlarmReceiver: Received Event 0725181101000013
[Dec 26 18:01:06] VERBOSE[7568][C-000e9413] app_alarmreceiver.c: AlarmReceiver: Incomplete string: 071318134000013, trying again…

(Second call)
[Dec 26 18:02:34] VERBOSE[7830][C-000e9418] app_alarmreceiver.c: AlarmReceiver: Received Event 0725181101000013
[Dec 26 18:02:38] VERBOSE[7830][C-000e9418] app_alarmreceiver.c: AlarmReceiver: Received Event 072518160600000B

It seems too random to be an issue in the user’s PSTN line.

Any ideas?

But it works fine for other lines from other customers ?

I wouldn’t rule it out. Analog lines are antennaes. They pick up vibrations from all sorts of things.

It works fine for most customers.

This happens a lot with customers using VoIP landlines. But it can happen too with PSTN lines in a smaller quantity.

The worst part is, we don’t have a VoIP landline nor a PSTN with problems here to test it.

You might try toggling codecs on your VoiP test lines. Garbled DTMF could be the result of G729 instead of G711. Then if confirmed it is codec issue, ask customers to change to G711 on just these calls.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.