We are having intermittent problems dialing out from asterisk 11.6.1 to a Grandstream GXW4104.
Background:
We have a very old Asterisk 11.6 system running on Centos 6.6 on some even older HP DL380 hardware. We repurposed a newer Lenovo TS430 server platform, installed Centos 6.10 and Asterisk 11.6.1 on it. The thought was that once we get to a newer hardware platform, we could work on upgradimn the OS and Asterisk versions. We have three analog lines connected to two different Grandstream GXW4104’s.
Prior to the move, we would on occasion receive a channel unavailable from a GXW4104. Once this situation occurred, no calls would go out. Though we could still receive calls. We determined that this would occur after a long power outage when the GXW4104’s would restart faster than the Asterisk. A power off/on of the GXW4104’s always resolved the situation. However, after the move, the GXW4104’s return a channel unavailable about once every day or so. We can still receive calls, but no longer make calls out. A power off/on of the GXW4104’s will fix the problem.
We started a syslog server and pointed both GXW4104’s to it. We have wireshark running on the Centos system. Though I haven’t been able to catch the flows prior to and during the event. The GXW4104’s are running with mostly the default configuration. We did configure the “Account 1 / General Settings” to point to our Asterisk server. Along with “User Accounts” to match the sip.conf settings.
I’m looking for a suggestion how better to capture the events leading up to the “channel unavailable”. Any suggestion about a sip.conf or GXW4104 setting to examine closer would also be appreciated.
From sip.conf
; ******************************
; * Grandstream ATA Gateway *
; ******************************
Thank you for your suggestion. I set qualify=no on one of our ATA’s. How would this effect a chanunavail reply from a GXW4104? Qualify looks to monitor a connection. We do not see any network connection problems between our Asterisk and the GXW4104’s. We do not see lagged / reachable messages on the console for the GXW4104’s.
I am aware that our running version of Asterisk is not supported. We needed to move everything off 18 year old hardware before it died. Now that it’s moved, we need to fix this one problem. Then we can look at migrating to a supported version.
You didn’t provide this information in your original post.
You need to examine the SIP exchanges and determine whether a registration is not being refreshed in time, or the device is retuning a SIP status which is treated as unavailable. In the latter case, the problem isn’t with Asterisk, but the exact error response may give a clue.
My apologies for missing pertinent information. This is the first asterisk related problem that got tossed my way. I wasn’t sure what information to include.
In the Asterisk console, I don’t see any sort of timeout messages. It looks like the GXW4104 is returning a ChanUnavail. I need to capture an exchange to verify this. I think I have a handle on some small parts. I’m still trying to wrap my head around SIP and all the bits and pieces. Our dialplan tries all 6 connections at once. Then connects with whichever endpoint is successful. I added the office-iguanas reply to the caller so folks would let me know something unusual occurred. Here is the asterisk log during a occurrence.
[2022-03-03 08:12:18.979] VERBOSE[2674][C-00000004] netsock2.c: == Using SIP RTP CoS mark 5
[2022-03-03 08:12:18.979] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:1] Verbose(“SIP/265-00000013”, “2,2022-03-03-08:12:18 Calling outside 11 digit number - 17653428456”) in new stack
[2022-03-03 08:12:18.979] VERBOSE[5705][C-00000004] app_verbose.c: == 2022-03-03-08:12:18 Calling outside 11 digit number - 17653428456
[2022-03-03 08:12:18.979] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:2] Dial(“SIP/265-00000013”, “SIP/5838/17653428456,30”) in new stack
[2022-03-03 08:12:18.979] WARNING[5705][C-00000004] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
[2022-03-03 08:12:18.979] VERBOSE[5705][C-00000004] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[2022-03-03 08:12:18.979] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:3] Dial(“SIP/265-00000013”, “SIP/4266/17653428456,30”) in new stack
[2022-03-03 08:12:18.980] WARNING[5705][C-00000004] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:4] Dial(“SIP/265-00000013”, “SIP/4830/17653428456,30”) in new stack
[2022-03-03 08:12:18.980] WARNING[5705][C-00000004] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:5] Dial(“SIP/265-00000013”, “SIP/5838-94/17653428456,30”) in new stack
[2022-03-03 08:12:18.980] WARNING[5705][C-00000004] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:6] Dial(“SIP/265-00000013”, “SIP/4266-94/17653428456,30”) in new stack
[2022-03-03 08:12:18.980] WARNING[5705][C-00000004] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:7] Dial(“SIP/265-00000013”, “SIP/4830-94/17653428456,30”) in new stack
[2022-03-03 08:12:18.980] WARNING[5705][C-00000004] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:8] Verbose(“SIP/265-00000013”, “2,2022-03-03-08:12:18 Calling outside 11 digit number - 17653428456 - DIALSTATUS CHANUNAVAIL”) in new stack
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] app_verbose.c: == 2022-03-03-08:12:18 Calling outside 11 digit number - 17653428456 - DIALSTATUS CHANUNAVAIL
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [17653428456@internal:9] Goto(“SIP/265-00000013”, “internal-CHANUNAVAIL,1”) in new stack
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Goto (internal,internal-CHANUNAVAIL,1)
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [internal-CHANUNAVAIL@internal:1] Verbose(“SIP/265-00000013”, “2,2022-03-03-08:12:18 INTERNAL-CHANUNAVAIL - internal-CHANUNAVAIL - CHANUNAVAIL”) in new stack
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] app_verbose.c: == 2022-03-03-08:12:18 INTERNAL-CHANUNAVAIL - internal-CHANUNAVAIL - CHANUNAVAIL
[2022-03-03 08:12:18.980] VERBOSE[5705][C-00000004] pbx.c: – Executing [internal-CHANUNAVAIL@internal:2] Wait(“SIP/265-00000013”, “2”) in new stack
[2022-03-03 08:12:20.982] VERBOSE[5705][C-00000004] pbx.c: – Executing [internal-CHANUNAVAIL@internal:3] Playback(“SIP/265-00000013”, “office-iguanas”) in new stack
[2022-03-03 08:12:21.097] VERBOSE[5705][C-00000004] file.c: – <SIP/265-00000013> Playing ‘office-iguanas.ulaw’ (language ‘en’)
[2022-03-03 08:12:24.297] VERBOSE[5705][C-00000004] pbx.c: – Executing [internal-CHANUNAVAIL@internal:4] Hangup(“SIP/265-00000013”, “”) in new stack
[2022-03-03 08:12:24.297] VERBOSE[5705][C-00000004] pbx.c: == Spawn extension (internal, internal-CHANUNAVAIL, 4) exited non-zero on ‘SIP/265-00000013’
It seems that we managed to find a bug. Our present work around is to restart the ATA gateways daily. We are working on bringing the OS and Asterisk current. This link describes what we were seeing.