Unifi UVP one Ext busy when dialing out

General Help
1

FreePBX 13 Distro, I have 2 extensions both setup exactly the same. Both extensions can receive calls and can call in between extensions just fine but one of the phones cannot dial out but can receive calls just fine. However, if I dial my (866) number the questionable extension/phone will dial out successfully but any other number I try to dial it immediately fails with 486 busy here message? I have checked the outbound route, I have checked the dial plan, I have created a new extension and same issue. It seems as though only the first extension I created “97” will dial out properly, the other extensions “99” and “100” will not dial out properly. I am using 2 Ubiquiti Unifi UVP VOIP Phones but I also had this same issue with a cisco phone as well.

Any suggestions where to look would be greatly appreciated as I am fairly new at Freepbx

2

https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs

3

0,") in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] netsock2.c: Using SIP RTP TOS bits 184
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] netsock2.c: Using SIP RTP CoS mark 5
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] app_dial.c: Called SIP/voipo/12177101046
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] app_dial.c: SIP/voipo-000003c8 is ringing
[2017-12-08 16:52:31] VERBOSE[8578][C-000003c2] chan_sip.c: Got SIP response 486 “Busy Here” back from 67.228.182.2:5060
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] app_dial.c: SIP/voipo-000003c8 is busy
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] app_dial.c: Everyone is busy/congested at this time (1:1/0/0)
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s@macro-dialout-trunk:24] NoOp(“SIP/99-000003c7”, “Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 17”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s@macro-dialout-trunk:25] GotoIf(“SIP/99-000003c7”, “0?continue,1:s-BUSY,1”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx_builtins.c: Goto (macro-dialout-trunk,s-BUSY,1)
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s-BUSY@macro-dialout-trunk:1] NoOp(“SIP/99-000003c7”, “Dial failed due to trunk reporting BUSY - giving up”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s-BUSY@macro-dialout-trunk:2] PlayTones(“SIP/99-000003c7”, “busy”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s-BUSY@macro-dialout-trunk:3] Busy(“SIP/99-000003c7”, “20”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] app_macro.c: Spawn extension (macro-dialout-trunk, s-BUSY, 3) exited non-zero on ‘SIP/99-000003c7’ in macro ‘dialout-trunk’
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Spawn extension (from-internal, 2177101046, 7) exited non-zero on ‘SIP/99-000003c7’
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [h@from-internal:1] Macro(“SIP/99-000003c7”, “hangupcall”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“SIP/99-000003c7”, “1?theend”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“SIP/99-000003c7”, “0?Set(CDR(recordingfile)=)”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Executing [s@macro-hangupcall:4] Hangup(“SIP/99-000003c7”, “”) in new stack
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘SIP/99-000003c7’ in macro ‘hangupcall’
[2017-12-08 16:52:31] VERBOSE[23566][C-000003c2] pbx.c: Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/99-000003c7’

4

I was able to figure out the issue, the outbound caller id for that extension was set to our 866 number and the SIP provider did not like that. We had to use the local number provided by our SIP provider for each extension.

5

With providers that do not allow foreign caller IDs, setting your CID at the trunk and not allowing it to be overridden would be a good plan.That way, if someone else changes their extension CID, you can nip the problem in the bud.

6

This. Even more importantly, external calls that are forwarded to the PSTN won’t be blocked by the provider. Better yet, find out what mechanism the provider uses to allow custom outgoing CID and implement it.