Blueface UC Settings


Try a new pjsip trunk. Leave all settings at defaults except:

Trunk Name: (as desired)
Username: <UC_username>
Secret: <UC_password>
SIP Server:

This is probably not enough to make calls, but it should register and incoming should work. If so, we can work on outgoing next.


I must admit, I found that it was certainly not as easy as coping the same format from their legacy accounts over to the UC.
The settings I have found that are needed are;
I don’t believe nat=yes is required as you may well have that set in your SIP settings, also I’m not sure it matters but I have qualify=yes

My settings are the same

Registration string
I found that there is no need for the Username at the end, however as Stewart1 recommends, you do need the port number after the domain.
Format that works;

With luck that should get you registered. If it does and you can make calls but can’t receive them you may need to update the /etc/hosts with Blueface’s IP addresses.

Lastly I did find one other small issue, whereby on the Blueface Web GUI, under ‘Device connections’ there is an option for DNIS presentation, this needs to be On.

Best of luck.


Based on @raoul 's comments, try adding to your pjsip settings:
From Domain:
and if needed
From User: <UC_username>
both of these affect outgoing only.

(David55) #24

nat=yes should never be needed for a sensibly configured ITSP, as ITSPs really should include their public address in Via, and Contact, and in SDP c= lines, and, in many cases, will be directly on the internet. nat= does not relate to Asterisk being behind NAT; it relates to the peer being behind NAT, failing to compensate for it, and Asterisk failing to recognize that this is the case.

(Paul W) #25

I’m using FreePBX

I don’t seem to have the option for pjsip trunk. Only a chan_sip trunk.

It seems to register now, however, I can’t make any outgoing calls.

So, my Outgoing, PEER Details -


I’m guessing you have the other settings you listed (above) in there as well? You could also try defaultuser=UC-username> I have it in mine but to be honest I wasn’t sure if it was needed.
My peer settings are;
secret= <UC_Password>

It may be worth checking your settings within the Blueface Web GUI as well, specifically the DNIS presentation.
Also I noticed that where you may have used your internal Blueface direct dial within the Outbound route, I now use the full number ‘3531xxxxxxx’ (if it’s a Dublin number). This same number is used in the Trunk outbound Caller ID.


Note that if you have fromuser set (overrides the From header) and also don’t have a sendrpid parameter (will not send Remote-Party-ID or P-Asserted-Identity headers), then the trunk Caller ID is not sent at all and your outbound caller ID will always be whatever is configured at the provider.


@Stewart1 thank you, a useful to know.

(Paul W) #29

Thanks so much for all the assistance. Looks like I am finally making progress.

So, the connection seems to establish. I can’t make a call, but, the Blueface UC Portal is actually showing my attempts correctly.

I’ll go back to them now, and see if they can offer any further assistance in actually making/receiving a call through to our FreePBX system.

(Paul W) #30

Only getting back to this now.

So, it seems I am registering correctly now.

When I attempt to make an outgoing call, in the BlueFace UC Portal, I can see the attempt.

However, the call does not connect. My logs show a 401- unauthorized.

Any specific info I can share to help diagnose this?


Paste the Asterisk log of a failing call (including sip debug) at and post the link here.

(David55) #32

401 means “please authenticate yourself”. It should be followed by a repeat of the request with authentication data. If there is no repeat, it means the end sending the INVITE has no authentication data to send (typical case for an ITSP).

Asterisk can also send 401 when an endpoint isn’t recognized, in order to waste an attacker’s time.

I’m not clear whether outgoing is relative to Asterisk or to the endpoint, and so I’m not clear which is sending 401.

(Paul W) #33

The log output - view/e8363dd1 (I can’t post links)

I replaced the number being called with <Call_Number> and our IP with <OFFICE_IP>

Maybe I’ve just had a long day and am missing the simple errors.

(David55) #34

<Call_Number> is neither a valid extension in your from-internal context, nor does it start with a valid trunk route prefix.

The 401 is completely normal and this is not an authentication issue.

(Paul W) #35

So, in the Outbound Routes, I set the prefix of 0 for this connection. So, to get out via the trunk, it should require a 0.

Our working connection uses a prefix of 9.

If I switch these around, and use 9 for the new route and 0 for the old route, I can still get out via the old route, but not get out via the new outbound route.

So, I am failing to see why it would consider the number invalid.


As @david55 says. Check your Outbound Routes; it appears that the number dialed does not match any of the patterns. If you have the CallerID field filled in, confirm that it matches the extension number you are calling from.

If you still have trouble, try calling a number that you can post publicly, for example a local McDonald’s, so you don’t have to redact anything related to that number (and we can see any number rewriting done by Asterisk).

(Paul W) #37

Ok, I found the issue.

Damn callflows.

It was an issue with the outgoing dial pattern, and the CID.

All working now.

You guys know what you’re at, and I’m a beginner with this stuff. Thanks for the help.

(system) closed #38

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