I have setup FreePBX with PJSIP. I have setup a trunk to my ISP who requires outbound authentication. On the trunk setup I have selected outbound authentication, have setup username and secret, applied changes, and restarted freepbx.
However, my calls using the trunk are rejected with a 403. Using pjsip logging I notice that the outgoing invite does not have an authentication line. Why is FreePBX not sending credentials to the ISP? SIP transactions are:
> INVITE
< 100 TRYING
< 403 FORBIDDEN
Credentials do not go in the initial INVITE, and can’t, because it’s challenge/response based authentication. The remote side should challenge at which point the INVITE is then sent with credentials. It’s likely some other configuration, such as from_user not being set to your username.
Where would I set the “from_user” field for the trunk? I’m not even sure what this field is/means; I set the username+secret for the trunk.
The SIP INVITE does contain a valid From: line. But perhaps that’s why the ITSP is not challenging with a 407. Googling from_user isn’t giving me much
I don’t speak FreePBX. In Asterisk it is the from_user setting on the endpoint. Whether that is needed or not - no idea.
For the installs that we have PJSIP setup with authentication on trunks we typically only need to configure the Username and Secret fields (which should be pretty self explanatory).
In the pjsip trunk, Advanced tab, set the value of From User to the same as you have in Username.
If you still have trouble, at the Asterisk command prompt type
pjsip set logger on
make a failing call attempt and the SIP trace will appear in the Asterisk log, along with the regular entries.
This is also on the Asterisk mailing list[1].
[1] [asterisk-users] PJSIP not performing outbound authentication
OK - I think I’m getting closer to the cause. My ITSP (Twilio) is not challenging with a 407 because the SIP INVITE 's FROM line contains the Asterisk server’s private IP (I think). I suspect that Twilio will not challenge if it’s a private IP (I’m guessing). Even though the Sip settings “LOCAL NETWORKS” and “EXTERNAL ADDRESS” are set correctly (I have a FQDN for external that resolves fine, and 172.31.0.0/16 for local network), the private IP is going out on the FROM line. I also have this same local net defined on the trunk transport.
As Joshua pointed out I’m experimenting with a pure asterisk system, and FPBX 16 as well. I’m tackling this on two fronts. It seems I’m getting very close to the root cause…just can’t figure out why Asterisk isn’t substituting the right IP. I’m not sure if this is a FPBX config issue, or an Asterisk issue.
It doesn’t touch the From header because it doesn’t matter for normal use. There is a “from_domain” option which can be used to explicitly set the domain portion of the From header. It’s unlikely to be your problem, unless Twilio requires a specific From domain.
We use Twilio as well and we don’t have to make any special configurations other then filling out the corresponding information for the username and secret fields in the pjsip settings → general tab.
You also need to make sure that the credentials that you created for the trunk are actually applied at Twilio under the Trunk → Termination → Authentication → Credential List.
PS. Twilio also controls access to the trunk using an IP control list. You’ll need to create one appropriate for your connection and apply it to the same section as the credentials above.
Joshua: According to Twilio the 403’s VIA line shows the IP of the PBX used for ACL matching. It is taken from the FROM line of the invite. So according to Twilio the FROM line needs the public IP of the PBX. And in my case the 403 via line shows received= with the private IP. I would post a link to Twilio’s doc here but I can’t post a link.
Now, I don’t have an ACL set on Twilio, only credential list, and those credential are set correctly for the trunk. But since I’m not even getting a 407 from Twilio, Asterisk doesn’t even have a chance to offer credentials. Which makes me think perhaps Asterisk needs to change the FROM IP too to work correctly with Twilio.
dobrosavljevic: are you using chan_pjsip with Twilio with a credential list only, or ACL, or both? I can’t understand why yours would be working and mine not.
I’m just left scratching my head. I may have to open a ticket with Twilio to ask why they are not sending a 407 back.
That would be a very broken SIP implementation!
It should be taken from the Via line of the INVITE, or if rport is set, which it normally is, from source address of the IP packet.
david55: I agree. Being new to SIP there are some strange rules/interpretations…
Anways…solved this one with the help of Twilio. Although their document does say that the Invite’s FROM: ip must match the public IP of the PBX making the call, since I don’t use an ACL this will be ignored. (But for Digium, maybe this is worth investigating).
The problem was that my INVITE was using an IP address (of twilio) instead of a URI. Even though it maps to the same IP, Twilio will reject it with a 403. And this isn’t documented anywhere. SO
INVITE sip:[email protected]:5060 SIP/2.0
should have been:
INVITE sip:[email protected]:5060
Many thanks to everyone who helped. Hopefully the above answer will save some newbie many hours of time 
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.