Hunt group is not working

So I am using I am using a GrandStream gateway( GXW410X) for 2 traditional lines I use with FreePBX. These two lines are set to roll over if one line is busy (I believe this is called hunt group) but it doesn’t work that way when using FreePBX if someone else were to call while the line is busy it wouldn’t roll over it would say that the line is out of services so how do I go about having the “hunt group” functionality to be in sync with FreePBX.

I’m using FreePBX 14.0.5.25

Two POTS lines, right?

If that’s true, they need to be in a hunt group at your telephone company.

Now, the “out of service” message is troubling, because that actually means something specific.

You’ll need to look, first, at your /var/log/asterisk/full log and see if the message is coming from Asterisk or if it’s coming from the telco.

Yes POTS lines. It is already in a hunt group at the services providers end. My services provider suggested that it might be a missing configuration to allow to roll over in my trunk or incoming call settings

That’s not how the system works. The lines terminate in your Grandstream which passes the calls in through the trunk(s) you’ve set up for the Grandstream. Once you hit the trunks, everything is processed through the “standard” inbound pipeline (based on the context= setting in your trunk definitions).

Everything that comes in on a trunk gets routed to the Inbound Routes. The call is then processed based on the DID and/or CID identified with the line it came in on (passed from the Grandstream) through the Grandstream trunk.

So, we need to find out which piece of the inbound is causing the problem. This will require logs. Without consulting the logs, there’s no point speculating. Your second line should have it’s own number. Try calling it first and see if you can get into the PBX. If that’s working, look at the logs and see how it’s getting processed.

calls come through and go through just fine from both lines.

Logs

VERBOSE[27828][C-000006d7] pbx.c: Executing [[email protected]:7] Answer(“SIP/10.0.0.30-00000ef7”, “”) in new stack

VERBOSE[27828][C-000006d7] pbx.c: Executing [[email protected]:8] Wait(“SIP/10.0.0.30-00000ef7”, “2”) in new stack

VERBOSE[27828][C-000006d7] pbx.c: Executing [[email protected]:9] Playback(“SIP/10.0.0.30-00000ef7”, “ss-noservice”) in new stack

VERBOSE[27828][C-000006d7] file.c: <SIP/10.0.0.30-00000ef7> Playing ‘ss-noservice.ulaw’ (language ‘en’)

VERBOSE[27823][C-000006d6] app_dial.c: Connected line update to SIP/225-00000ef5 prevented.
[2019-05-09 14:06:36] VERBOSE[27823][C-000006d6] app_dial.c: SIP/227-00000ef6 answered SIP/225-00000ef5

VERBOSE[27831][C-000006d6] bridge_channel.c: Channel SIP/227-00000ef6 joined ‘simple_bridge’ basic-bridge <1033b3cb-ff69-4cac-ae8f-71fdf6b95735>

VERBOSE[27823][C-000006d6] bridge_channel.c: Channel SIP/225-00000ef5 joined ‘simple_bridge’ basic-bridge <1033b3cb-ff69-4cac-ae8f-71fdf6b95735>

VERBOSE[2434] chan_sip.c: Extension Changed 227[ext-local] new state InUse for Notify User 221
[2019-05-09 14:06:36] VERBOSE[2434] chan_sip.c: Extension Changed 227[ext-local] new state InUse for Notify User 222

VERBOSE[27828][C-000006d7] pbx.c: Executing [[email protected]:10] PlayTones(“SIP/10.0.0.30-00000ef7”, “congestion”) in new stack

VERBOSE[27828][C-000006d7] pbx.c: Executing [[email protected]:11] Congestion(“SIP/10.0.0.30-00000ef7”, “5”) in new stack

VERBOSE[27831][C-000006d6] bridge_channel.c: Channel SIP/227-00000ef6 left ‘simple_bridge’ basic-bridge <1033b3cb-ff69-4cac-ae8f-71fdf6b95735>

VERBOSE[27823][C-000006d6] bridge_channel.c: Channel SIP/225-00000ef5 left ‘simple_bridge’ basic-bridge <1033b3cb-ff69-4cac-ae8f-71fdf6b95735>

VERBOSE[27823][C-000006d6] app_macro.c: Spawn extension (macro-dial-one, s, 55) exited non-zero on ‘SIP/225-00000ef5’ in macro ‘dial-one’

VERBOSE[27823][C-000006d6] app_macro.c: Spawn extension (macro-exten-vm, s, 26) exited non-zero on ‘SIP/225-00000ef5’ in macro ‘exten-vm’

VERBOSE[27823][C-000006d6] pbx.c: Spawn extension (ext-local, 227, 2) exited non-zero on ‘SIP/225-00000ef5’

VERBOSE[27823][C-000006d6] pbx.c: Executing [[email protected]:1] Macro(“SIP/225-00000ef5”, “hangupcall,”) in new stack

VERBOSE[27823][C-000006d6] pbx.c: Executing [[email protected]:1] GotoIf(“SIP/225-00000ef5”, “1?theend”) in new stack

VERBOSE[27823][C-000006d6] pbx_builtins.c: Goto (macro-hangupcall,s,3)

(I hope this is useful)

The most useful data would be the first few lines related to the call (just before the beginning of what you posted). However, set an Inbound Route with DID Number and CallerID Number both blank (a catch-all route) with a working extension as the Destination. Repeat the failing call. If the extension rings, look at the CDR report to see what DID was called and set up an Inbound Route to match.

If it still fails, post a log starting with the very first line related to the incoming call.

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