486 busy needed!

Hi there.

We are managing few FreePBXs and other brands sip PBXs, each located locally in different branches of our business. Each of these remote PBXs are connected through a centralized one, a FreePBX release 14. We called this one our “Main” PBX.

The “Main” FreePBX is used as a sort of gateway, a centralized point to reach public networks using different Sip providers.

If one remote user wants to pass an outside call, it’s local PBX will pass the call to the “Main” one, and then the “Main” one will pass that outbound call to one of our SipTrunk providers depending of the destination of that call.

Now, everything (well, almost everything) is working fine, except for a specific scenario.

Problem : Let’s take Brandon as an example. Brandon is working in one of our remote branches, and that branch have it own PBX. Brandon is being in remote working for quite a long time now, and it’s office extensions is being forwarded to it’s home land lines. Brandon have a basic land line, without a call waiting service (Brandon is an old school type of guy).

If Brandon is receiving a 2nd consecutive call on his business extension, the 2nd caller will hear “You’re call cannot be completed as dialled, please try your call later”.

Why ? Our “Main” FreePBX intercepts the 486 busy coming back from Brandon’s land line provider, and ultimately our Sip Trunk provider, and plays the congestion message, instead of relaying the 486 busy up to Brandon’s office PBX. If we change the action of the Optional Destination on Congestion setting (outbound route) to something else, the PBX will execute that action on a busy call just as expected.

Is there anyways for us to bypass that Optional Destination on Congestion setting and let the FreePBX relay the 486 busy back to the downstream PBXs ?

“Main” FreePBX - 14.0.13.28
PBX Firmware: 12.7.6-2002-2.sng7
PBX Service Pack:1.0.0.0
Asterisk: 13.32.0

Thanks

2 Likes

Thanks Lorne, I’ll give it a try as soon as possible ! :slight_smile:

1 Like

@lgaetz

Hi Lorne.

I tried your code, and yes it did send a 486 busy, but…

Our PBX still plays a Busy tone when the trunk provider returns a 486 busy, unless the trunk itself is congested.

I temporarily drop down the Maximum Channels on the trunk itself to 2 calls, and as expected, the 3rd outbound call went into the congestion destination set to the Custom Destination “Send_sip_486_Busy”, which is linked to send-sip-response-code,486,1 you sent me earlier. At this moment, yes asterisk is sending back a 486 busy to the downstream PBXs.

I guess I should include a GOTO [send-sip-response-code] or something else into the dialplan somewhere so Asterisk will react differently when receiving a 486 from our Trunk provider ?

Thanks.

That’s the limit of my expertise in this area.

Unless I misread it, you would have this issue even with a standalone FreePBX. The workaround would be to use FollowMe with call confirmation.

Regarding your “Main FreePBX” I think you are should consider a SIP Proxy like Kamailio (look into dSIP Router)

Found the issue ! :wink:

Our outbound trunks had the option “Continue on busy” turned on which makes FreePBX to continue to find a possible path for that call even it its receiving a 486 busy from the upstream providers. As the context has no other issue except to send calls on that trunk, FreePBX played it’s own wav file as instructed by one of its macro , can’t remember which one is (dial-trunkout ??) .

Now, as our “main” is sending back a 486 to the downstream PBXs, when a remote branches PBX is sending a call to a busy PSTN number, the branch PBX knows of the busy line and send the call to the appropriate treatment (voicemail) instead of the callers hearing "You’re call cannot be completed as dialled ".

Thanks.

1 Like

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