All circuits are busy with outbound call on voip.ms trunk


#1

I am having trouble making outbound calls through a voip.ms trunk on a new FreePBX 15.0.16.81 install. I think I might have a dial pattern problem, but I can’t figure it out.

When I dial a 7-digit number (5551212), I get: https://pastebin.com/bEua1D1F

A 10-digit number (6185551212) gets me: https://pastebin.com/8s4iPerd

Dialing 11 digits (16185551212) gets me:

== Setting global variable ‘SIPDOMAIN’ to ‘10.10.2.1’
== Using SIP RTP Audio TOS bits 184
== Using SIP RTP Audio TOS bits 184 in TCLASS field.
== Using SIP RTP Audio CoS mark 5
– Executing [16185551212@from-internal:1] ResetCDR(“PJSIP/202-0000003b”, “”) in new stack
– Executing [16185551212@from-internal:2] NoCDR(“PJSIP/202-0000003b”, “”) in new stack
– Executing [16185551212@from-internal:3] Progress(“PJSIP/202-0000003b”, “”) in new stack
– Executing [16185551212@from-internal:4] Wait(“PJSIP/202-0000003b”, “1”) in new stack
> 0x7f8354543650 – Strict RTP learning after remote address set to: 10.10.10.192:20142
> 0x7f8354543650 – Strict RTP switching to RTP target address 10.10.10.192:20142 as source
– Executing [16185551212@from-internal:5] Playback(“PJSIP/202-0000003b”, “silence/1&cannot-complete-as-dialed&check-number-dial-again,noanswer”) in new stack
– <PJSIP/202-0000003b> Playing ‘silence/1.ulaw’ (language ‘en’)
– <PJSIP/202-0000003b> Playing ‘cannot-complete-as-dialed.ulaw’ (language ‘en’)
– <PJSIP/202-0000003b> Playing ‘check-number-dial-again.ulaw’ (language ‘en’)
– Executing [h@from-internal:1] Macro(“PJSIP/202-0000003b”, “hangupcall”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“PJSIP/202-0000003b”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“PJSIP/202-0000003b”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] NoOp(“PJSIP/202-0000003b”, " montior file= ") in new stack
– Executing [s@macro-hangupcall:5] GotoIf(“PJSIP/202-0000003b”, “1?skipagi”) in new stack
– Goto (macro-hangupcall,s,7)
– Executing [s@macro-hangupcall:7] Hangup(“PJSIP/202-0000003b”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 7) exited non-zero on ‘PJSIP/202-0000003b’ in macro ‘hangupcall’
== Spawn extension (from-internal, h, 1) exited non-zero on ‘PJSIP/202-0000003b’

My voip.ms trunk has dial patterns of:

Prepend 1618 (noprefix) NXXXXXX
Prepend 1 (noprefix) NXXNXXXXXX

In summary, dialing 7 and 10 digits give me the “All circuits are busy” message. Dialing 11 gives me the “Your call cannot be completed as dialed.” Interestingly, dialing the voip.ms echo test number, 4443, gets me the same “Your call cannot be completed as dialed” message.

Can somebody point me in the right direction?


#2

You need to add patterns to your Outbound Route to allow dialing 1NXXNXXXXXX and 4443.

The 7- and 10-digit calls were rejected by VoIP.ms. I’m guessing that the caller ID you sent was not acceptable. I believe that they require 10 digits on calls to North America, but starting with the country code for overseas calls.

If that’s not it, at the Asterisk command prompt type
pjsip set logger on
make another failing call, paste the Asterisk log for the call (which will now include a SIP trace) at pastebin.freepbx.org and post the link here.

With luck, the trace will tell us why the call was rejected.


#3

Thanks for the reply.

I typed pjsip set logger on and tried again. Here’s the output from that attempt: https://pastebin.freepbx.org/view/3f912692


#4

Looks like I have the issue solved! I think there was a problem with the trunk no registering.

Thanks for the help, Stewart!


#5

I don’t believe that VoIP.ms requires registration to make a call (they authenticate each outgoing INVITE), but it’s certainly possible that whatever you did to fix registration also affected outbound.

Line 345: From: <sip:202@10.10.2.1>;tag=2d95f6da-0157-4655-888a-280a8e569bb5
seems wrong. VoIP.ms rejected the INVITE before authentication. I’m not a VoIP.ms customer and don’t know whether they require a username in the From header. If they do, you would need a From User setting in the trunk. If they don’t (they use the auth ID supplied when they authenticate), then 202 is not a valid caller ID.