Ring group hangs up 2nd incoming call

kpi6388 · August 28, 2021, 3:32pm

I have a ring group with one external destination. The first incoming call works fine. When the next call comes in, an internal phone rings once, the new call is then dropped with the message “all lines are busy”.

This is the ring group definition:
4416
5412
6440
055605555#

Ring strategy: ringall
Ring Time: 28 (changed that from 10 to 30 seconds - no difference)
Destination if no answer: Voicemail

The installation is for a small office with only 4 internal extensions: 2 phones and 2 headsets connected to a Gigaset 510N.

The only trunk is a Patton Smartnode 4120 device connecting to a legacy BRI line (ISDN connection with the capacity of two calls in parallel).

We have used the same setup for years with a Raspberry PI (RasPBX) without any problems. Same ring group. We only experienced SD Card failures and setup a new virtual server on Debian for better reliability. The phones and the Patton device should hence be ok. I compared all settings to the RasPBX installation and could not find any difference.

Without the external destination, everything works fine.

I found this in the log:

app_dial.c: Called SIP/SN4120/055605555
app_dial.c: SIP/6440-00000057 is ringing
app_dial.c: SIP/4416-00000055 is ringing
chan_sip.c: **Got SIP response 503 "Service Unavailable" back from x.x.x.x:5060**
app_dial.c: **SIP/SN4120-00000058 is circuit-busy**
app_dial.c: **Everyone is busy/congested at this time** (1:0/1/0)
....
file.c: <Local/055605555@from-internal-0000000d;2> Playing 'all-circuits-busy-now.ulaw' (language 'de_DE')
....
pbx.c: Auto fallthrough, channel 'Local/055605555@from-internal-0000000d;2' status is 'CONGESTION'
pbx.c: Executing [h@from-internal:1] Macro("Local/055605555@from-internal-0000000d;2", "hangupcall") in new stack
....
pbx.c: Executing [s@macro-hangupcall:7] Hangup("SIP/SN4120-00000054", "") in new stack
app_macro.c: Spawn extension (macro-hangupcall, s, 7) exited non-zero on 'SIP/SN4120-00000054' in macro 'hangupcall'
pbx.c: Spawn extension (ext-group, h, 1) exited non-zero on 'SIP/SN4120-00000054'

Some more background information:

When the first call comes in, the BRI has etwo lines available. One is used for the incoming call, the second is used for the external destination. Picking up the call from an internal phone will release the 2nd line.
During one incoming call, we can make an additional outgoing call without a problem.
When the 2nd call comes in, the BRI has only one line left and can’t reach the external destination. This would be ok for us, but the internal extensions should still be served.
The voicemail is not launched in the 2nd call - the system simply hangs up
When the 1st call is picked up by the external destination, all lines are really busy - that’s ok and not subject of my issue

Stewart1 · August 28, 2021, 4:15pm

I did a simple test to try to replicate your situation, by creating a Ring Group with one internal extension and one “external” number for which the Outbound Route has no trunks. It did not fail.

Please paste the complete Asterisk log (not the console log) for a failing call at pastebin.freepbx.org and post the last eight hex characters of the link here (as you are too new to post links). You should be able to produce the failure by making an outbound call from one extension, and while that is still in progress, calling in from your mobile to the ring group.

kpi6388 · August 28, 2021, 5:22pm

This is the pastebin URL id: 6e4eef90

Stewart1 · August 28, 2021, 5:58pm

[2021-08-28 19:12:48] VERBOSE[26981][C-00000022] pbx.c: Executing [s@macro-outisbusy:1] Playback("Local/055605555@from-internal-00000018;2", "all-circuits-busy-now&please-try-call-later") in new stack
[2021-08-28 19:12:48] VERBOSE[26979][C-00000022] app_dial.c: Local/055605555@from-internal-00000018;1 answered SIP/SN4120-0000008d

It appears that you have an old version of Core, in which the definition of macro-outisbusy lacks the logic to play the ‘all circuits busy’ message in early media. On the test system (not completely up to date but likely newer than yours) my version is 15.0.12.71. What version do you have on the failing system? On the Pi?

If feasible, try updating the module. Otherwise, you could override the definition of the macro.

On my system, the macro definition has logic to not use early media if it’s an emergency route. I don’t understand why that is required. Relevant code pasted below:

[macro-outisbusy]
include => macro-outisbusy-custom
exten => s,1,Progress
exten => s,n,GotoIf($["${EMERGENCYROUTE}" = "YES"]?emergency,1)
exten => s,n,GotoIf($["${INTRACOMPANYROUTE}" = "YES"]?intracompany,1)
exten => s,n,Playback(all-circuits-busy-now&please-try-call-later, noanswer)
exten => s,n,Congestion(20)
exten => s,n,Hangup

exten => intracompany,1,Playback(all-circuits-busy-now&please-try-call-later, noanswer)
exten => intracompany,n,Congestion(20)
exten => intracompany,n,Hangup

exten => emergency,1,Playback(all-circuits-busy-now&please-try-call-later)
exten => emergency,n,Congestion(20)
exten => emergency,n,Hangup

;--== end of [macro-outisbusy] ==--;

kpi6388 · August 28, 2021, 7:08pm

On the failing system: FreePBX 15.0.17.48

On the Pi: 12.0.76.6

I assume you mean the macro definition in /etc/asterisk/extensions_additional.conf
I copied your code and it does actually allow two parallel incoming calls. However, any outbound call is no longer possible with this modification.

My original macro is as follows:

[macro-outisbusy]
include => macro-outisbusy-custom
exten => s,1,Playback(all-circuits-busy-now&please-try-call-later)
;--== end of [macro-outisbusy] ==--;

Not sure if that file is a Debian standard (I’m using FreePBX on Debian, not the FreePBX distro) or a file that came with FreePBX. Couldn’t find in the tarball. I’ll look again into it tomorrow and compare it to the Pi, thanks for your hint.

Stewart1 · August 28, 2021, 7:20pm

This sounds bizarre, because the macro should not be called on an outbound call that doesn’t get a failure response from the trunk, so it shouldn’t matter what it contains. If you want to chase this further, paste a log of a failing outgoing call.

However, can you just update all modules to current? If not, please explain.

dicko · August 28, 2021, 7:44pm

If you are ‘off the reservation’ when compiling or installing asterisk in Debian based OS’s, you need to make sure the deprecated by Asterisk app_macro.so is compiled and loaded when using FreePBX (which still depends on it (go figure that one! are they not all under one roof now ? have ‘the asterisk guys’ and the ‘FreePBX guys’ at Sangoma not yet had a coffee together ? )

but as a diagnostic , what does (from a shell)

rasterisk -x 'module show  like app_macro'

return?

kpi6388 · August 29, 2021, 9:15am

This is the macro defined on the Pi:

[macro-outisbusy]
exten => s,1,Progress
exten => s,n,Playback(all-circuits-busy-now,noanswer)
exten => s,n,Playback(pls-try-call-later,noanswer)
exten => s,n,Macro(hangupcall)

I copied this on the new server into extensions_override_freepbx.conf and rebooted the server. This seems now to work fine.

Is extensions_override_freepbx.conf the right place to put the override macros?

kpi6388 · August 29, 2021, 9:20am

rasterisk -x 'module show  like app_macro'

returns:

Module                         Description                              Use Count  Status      Support Level
app_macro.so                   Extension Macros                         0          Running        deprecated
1 modules loaded

I may be wrong, but that looks ok to me.

I followed largely “How to Install FreePBX 15 on Debian 10 with Asterisk 16, PHP 7.3” as written in the freepbx.org wiki. I assume that takes care of the modules.

system · September 28, 2021, 9:20am

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