search

wdoekes / asterisk-chan-dongle

chan_dongle channel driver for Huawei UMTS cards, works with Asterisk 14+
Other
298 stars 104 forks source link

Ignoring unknown result: CRING, CLIP in at_response.c (incoming calls stopped working) #82

Open DmitrySandalov opened 4 years ago

DmitrySandalov commented 4 years ago

(First of all thank you for maintaining this fork! It is highly appreciated.)

The calls stopped going into the dongle-incoming without any obvious reason (incoming SMS and USSD were still working). I didn't change the configuration for a long time, so I thought that it was something external.

Switching the log level to debug in /etc/asterisk/logger.conf

console => notice,warning,error,debug

I saw the following errors after initiating an incoming call to Asterisk from +1234567890 (redacted):

DEBUG[132]: at_response.c:1918 at_response: [dongle0] Ignoring unknown result: '+CRING: VOICE'
DEBUG[132]: at_response.c:1918 at_response: [dongle0] Ignoring unknown result: '+CLIP: "+1234567890",145,,,,0'
DEBUG[132]: at_response.c:1918 at_response: [dongle0] Ignoring unknown result: '+CRING: VOICE'
DEBUG[132]: at_response.c:1918 at_response: [dongle0] Ignoring unknown result: '+CLIP: "+1234567890",145,,,,0'
DEBUG[132]: at_response.c:743 at_response_cend: [dongle0] CEND: call_index 1 duration 0 end_status 104 cc_cause 16 Line disconnected
DEBUG[132]: at_response.c:147 at_response_ok: [dongle0] AT+CLCC sent successfully

Since it was CRING, not RING, I was in the RES_UNKNOWN: case of at_response.c

After performing a search, I found out that this may be when AT+CRC is set to 1 (cellular result codes are switched to the extended format).

I checked the current value of CRC:

$ asterisk -rx 'dongle cmd dongle0 AT+CRC=?'
[dongle0] Got Response for user's command:'+CRC: (0,1)'

Set it to 0

$ asterisk -rx 'dongle cmd dongle0 AT+CRC=0'
[dongle0] Got Response for user's command:'OK'

Checked if it is indeed 0

$ asterisk -rx 'dongle cmd dongle0 AT+CRC=?'
[dongle0] Got Response for user's command:'+CRC: (0,1)'

The result was the same as before I set it to 0 (a bit strange to me), but the calls are now working fine (going into case RES_RING: of at_response.c).

Looks like at_response.c needs another case for handling CRING (and perhaps CLIP) when AT+CRC=1 (set by one's service provider externally?)