Blueface UC Settings

While I have used Blueface (Legacy) SIP for a number of years without issue, they are currently moving all legacy accounts over to their UC system,

While I can get the trunk to register with their servers I am unable to make any incoming or outgoing calls, something is ‘out of wack’ given that I get ‘All circuits are busy’ when attempting outgoing calls.

I am wondering if anyone has had success working with these new settings. Ideally running FreePBX with Cisco Endpoints.

Many thanks.

What, if anything, appears in the Asterisk log on an attempted incoming call? What does the caller hear?

If nothing in the Asterisk log, run sngrep and report what, if anything, shows on an attempted incoming call.

If nothing in sngrep, please post: Modem make/model? Configured as router? Separate router/firewall, if any? Any VoIP-specific settings in modem or firewall?

Incoming caller met with engaged dial tone.

IP range for service provider is the same as old Truck that still works fine, either way it’s whitelisted in routers firewall.
Only noticeable difference between Trunks (other than login details) is that it now runs on port 5062 instead of 5060 (which all my devices and service providers were previously using.

Excerpt from Log;
323378[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:25] ExecIf(“SIP/106-00000003”, “0?Set(DIAL_TRUNK_OPTIONS=)”) in new stack

323379[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:26] Set(“SIP/106-00000003”, “HASH(__SIPHEADERS,Alert-Info)=unset”) in new stack

323380[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:27] Dial(“SIP/106-00000003”, “SIP/Blueface_UC_out/0879008118,300,b(func-apply-sipheaders^s^1,(4))U(sub-send-obroute-email^0879008118^60879008118^4^1628796802^^35314430405)”) in new stack

323381[2021-08-12 20:33:22] WARNING[21618][C-00000003] app_dial.c: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)

323382[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)

323383[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:28] NoOp(“SIP/106-00000003”, “Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 20”) in new stack

323384[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:29] GotoIf(“SIP/106-00000003”, “0?continue,1:s-CHANUNAVAIL,1”) in new stack

323385[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx_builtins.c: Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)

323386[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:1] Set(“SIP/106-00000003”, “RC=20”) in new stack

323387[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:2] Goto(“SIP/106-00000003”, “20,1”) in new stack

323388[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx_builtins.c: Goto (macro-dialout-trunk,20,1)

323389[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:1] Goto(“SIP/106-00000003”, “continue,1”) in new stack

323390[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx_builtins.c: Goto (macro-dialout-trunk,continue,1)

323391[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:1] NoOp(“SIP/106-00000003”, “TRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE: 20 - failing through to other trunks”) in new stack

323392[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:2] ExecIf(“SIP/106-00000003”, “1?Set(CALLERID(number)=106)”) in new stack

323393[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:11] Macro(“SIP/106-00000003”, “outisbusy,”) in new stack

323394[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] pbx.c: Executing [[email protected]:1] Playback(“SIP/106-00000003”, “all-circuits-busy-now&please-try-call-later”) in new stack

323395[2021-08-12 20:33:22] VERBOSE[21618][C-00000003] file.c: <SIP/106-00000003> Playing ‘all-circuits-busy-now.alaw’ (language 'en’)

As mentioned Truck shows as registered both on PBX and with provider. I have a feeling it’s nothing more than a setting, but so far even with extensive searching I can’t put a finger on it.


And nothing appears in either the Asterisk log or in sngrep?

For the outbound call, at the Asterisk command prompt type
sip set debug on
make the failing call, paste the entire Asterisk log for the call at and post the link here.

Nothing in either log for attempted incoming call, it would appear that currently no data is coming from provider to my PBX and I am in conversation with them over this.

As regards attempted outbound call, the debug log for this is;


3485[2021-08-13 11:29:28] VERBOSE[25762][C-00000008] app_dial.c: Called SIP/Blueface_UC_out/0879008118
3486[2021-08-13 11:29:28] WARNING[23696][C-00000008] chan_sip.c: Received response: "Forbidden" from '&lt;sip:[email protected]&gt;;tag=as2bb3d726'

Call is sent to the provider, and they have rejected it. They should be able to tell you why.

Thank you for that. That issue actually might be at my end given that the IP listed is in fact mine and not the providers.
It would appear that the wrong IP is being used (theirs starts 194, mine starts 89) and thus I have a setting misaligned. Would it be possible to direct me to the area that deals with resolving these IP.

Many thanks.

So I’m making progress, I have found that by adding fromdomain and outbondproxy I am able to make outgoing calls.
Incoming calls though aren’t working. I am getting the 401 Unathorized message in Sngrep.

One thing I notice in the Asterisk log is;
netsock2.c: Port disallowed in

I wondered if anyone might offer any thoughts or am I way of the mark?

Many thanks.

Try adding
to your trunk outgoing settings. (Incoming settings should be left blank.)

If no luck, at the Asterisk command prompt, type
sip set debug on
make a failing incoming call, paste the Asterisk log for the call at and post the link.
The previous paste did not show the SIP trace, so please note: The sip debug command is canceled by any reload or restart, so issue it just before making the test call. When you type it, you should see a response
SIP Debugging Enabled

I believe the reason that insecure=very was deprecated is that people were overusing it, but the result has been that they overuse insecure=port,invite instead. This is two different setting.

However, if this was really intended to be insecure=port, because of:

netsock2.c: Port disallowed in

That is objecting to the presence of the port as a syntax error, not to the particular value of the port as semantic/security problem.

The underlying option for this, PARSE_PORT_FORBID, is used in several places (e.g. for maddr= parameters), so, unless there are secondary errors that indicate the exact field being accessed (or you want to set a breakpoint and see the backtrace), you are going to have to look at the whole incoming packet to see if there are obvious uses a of a port number where one is not allowed.

That works. Thank you very much.

But is it the insecure=port that worked or the insecure=invite that worked (or do you really need both in your case)?

Hard to say, while I thought that I had this sorted I have now found that there must be something up with the registration as sometimes the calls come through, more often than not they don’t.
Incoming calls are fine whenever I try.

I currently have insecure=invite. At least I get some calls through whereas before I got nothing.

I have a feeling this maybe down to registration times but I’m certainly open to ideas?
On speaking previously with the provider re registration times, they recommended 1800, which is what I have changed my maximum expiry (registration string) to.

If you have a static IP address and the provider supports it, have them send calls directly to your PBX, instead of registration.

If you must use registration, set a short expiry interval if the provider tolerates it, e.g. 120 seconds, to keep the NAT association open and quickly regain registration should it be lost.

If the provider insists on a long registration interval, (in your hardware firewall) forward the SIP port from their IP addresses to your PBX.

Thanks again for your help. Changing the time alone didn’t get the desired result however I have also found a similar thread;

Updated using their new IP / Domain, coupled with addition of insecure=invite to trunk and adjusting the default registration time to 120secs. It would appear that I have this trunk now setup reliably.

I’m having a similar issue.

How did you get the trunk to register in the first place? I seem to be stuck on that.

I’m happy to help if I can.

In what way are you stuck, in getting your trunk to register / stay registered with Blueface or to receive incoming calls?

I haven’t yet been able to register.

My old SIP connection is working fine, but their new UC connection configuration isn’t.

I added the config similar to before, but I am seeing -
Registration for ‘’ timed out
in my logs.

I have two registrations -

I have my firewall enabled to allow ALL outgoing (to get it working), and have enabled incoming from their IP block to ports 5060 and 5062 for these two registrations.

My Trunk configuration -
Outgoing -

Incoming -
USER Context <UC_username>
USER Details -

Registration String -

I am guessing that it is something in the Registration string?

but you should really be using a pjsip trunk.