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;
Outgoing fromdomain=trunk-uc-ie.blueface.com
Insecure=invite
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
Incoming
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; <UC_username>:<UC_password>@trunk-uc-ie.blueface.com:5062
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.
Based on @raoul 's comments, try adding to your pjsip settings: From Domain: trunk-uc-ie.blueface.com
and if needed From User: <UC_username>
both of these affect outgoing only.
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.
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;
username=<UC_username>
type=peer
secret= <UC_Password>
qualify=yes
port=5062
insecure=invite host=trunk-uc-ie.blueface.com
fromuser=<UC_username> fromdomain=trunk-uc-ie.blueface.com
defaultuser=<UC_username>
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.
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.
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).