[SOLVED] Inbound calls being rejected

I have an IP registration SIP trunk with a provider in Brasil. I can make outbound calls with no problem.

Inbound calls come from a second IP address (Outbound uses x.x.x.2, inbound uses x.x.x.3).

So, if from CLI i run asterisk -rvvvvvvvvv and then sip set debug on and place a call to any of my inbound DID’s, I never see anything hit my system.

Provider has shown that my fPBX is replying to the inbound that he is passing as SIP/2.0 401 Unauthorized.

I have:
disabled IPtables (temporarily, as a test)
enabled anonymous calls
enabled guest calls
restarted asterisk service
rebooted entire PBX

Nothing seems to be working.

Server: FPBX-13.0.195(13.21.0)

U 2018/05/14 22:09:08.622053 X.X.X.3:5070 -> Y.Y.Y.192:5060
    INVITE sip:Inbound [email protected] SIP/2.0.
    Via: SIP/2.0/UDP X.X.X.3:5070;branch=z9hG4bK6d9fd0fa.
    Max-Forwards: 70.
    From: "CallerID" <sip:[email protected]:5070>;tag=as6ba970a0.
    To: <sip:Inbound [email protected]>.
    Contact: <sip:[email protected]:5070>.
    Call-ID: [email protected]:5070.
    CSeq: 102 INVITE.
    User-Agent: VoipControl PBX.
    Date: Tue, 15 May 2018 01:09:08 GMT.
    Supported: replaces, timer.
    Diversion: <sip:+Inbound [email protected]>;reason=unconditional.
    Content-Type: application/sdp.
    Content-Length: 261.
    o=root 1928389977 1928389977 IN IP4 X.X.X.3.
    s=Asterisk PBX
    c=IN IP4 X.X.X.3.
    t=0 0.
    m=audio 29838 RTP/AVP 0 8 101.
    a=rtpmap:0 PCMU/8000.
    a=rtpmap:8 PCMA/8000.
    a=rtpmap:101 telephone-event/8000.
    a=fmtp:101 0-16.

    U 2018/05/14 22:09:08.627763 Y.Y.Y.192:5060 -> X.X.X.3:5070
    SIP/2.0 401 Unauthorized.
    Via: SIP/2.0/UDP X.X.X.3:5070;branch=z9hG4bK6d9fd0fa;received=X.X.X.3.
    From: "CallerID" <sip:[email protected]:5070>;tag=as6ba970a0.
    To: <sip:Inbound [email protected]>;tag=as0f5f8369.
    Call-ID: [email protected]:5070.
    CSeq: 102 INVITE.
    Server: FPBX-13.0.195(13.21.0).
    Supported: replaces, timer.
    WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="77e740d9".
    Content-Length: 0.

    U 2018/05/14 22:09:08.627948 X.X.X.3:5070 -> Y.Y.Y.192:5060
    ACK sip:Inbound [email protected] SIP/2.0.
    Via: SIP/2.0/UDP X.X.X.3:5070;branch=z9hG4bK6d9fd0fa.
    Max-Forwards: 70.
    From: "CallerID" <sip:[email protected]:5070>;tag=as6ba970a0.
    To: <sip:Inbound [email protected]>;tag=as0f5f8369.
    Contact: <sip:[email protected]:5070>.
    Call-ID: [email protected]:5070.
    CSeq: 102 ACK.
    User-Agent: VoipControl PBX.
    Content-Length: 0.

    U 2018/05/14 22:09:16.499463 Y.Y.Y.192:5060 -> X.X.X.2:5060
    OPTIONS sip:Provider FQDN SIP/2.0.
    Via: SIP/2.0/UDP Y.Y.Y.192:5060;branch=z9hG4bK2faf7142.
    Max-Forwards: 70.
    From: "Unknown" <sip:[email protected]>;tag=as39b641c6.
    To: <sip:Provider FQDN>.
    Contact: <sip:[email protected]:5060>.
    Call-ID: [email protected]:5060.
    CSeq: 102 OPTIONS.
    User-Agent: FPBX-13.0.195(13.21.0).
    Date: Tue, 15 May 2018 01:09:08 GMT.
    Supported: replaces.
    Content-Length: 0.

    U 2018/05/14 22:09:16.505340 X.X.X.2:5060 -> Y.Y.Y.192:5060
    SIP/2.0 501 Not Implemented.
    Via: SIP/2.0/UDP Y.Y.Y.192:5060;branch=z9hG4bK2faf7142.
    From: "Unknown" <sip:[email protected]>;tag=as39b641c6.
    To: <sip:Provider FQDN>.
    Call-ID: [email protected]:5060.
    CSeq: 102 OPTIONS.
    Server: MERA MSIP v.1.0.2.
    Content-Length: 0.

Trunk Settings:


host=Provider FQDN&X.X.X.3

Any help would be greatly appreciated!

I don’t believe that the syntax host=Provider FQDN&X.X.X.3 is accepted.

Use your present trunk for outgoing only. Include the register string as is and set

Define a separate trunk for incoming with

For testing, use a default Incoming Route (any DID, any CID) that routes to a working extension.

However, I suspect that you have a separate problem, which may or may not be related.: You say that you “never see anything hit my system”, but it seems virtually certain that the 401 response came from FreePBX. If you still have trouble, capture traffic with tcpdump on the PBX and move the capture file to your workstation to analyze with Wireshark.


I appreciate the reply. I have already tried the host=providerFQDN for outgoing and incoming settings with host-x.x.x.3, still nothing hitting the PBX.

Going to run a tcpdump and then analyze with wireshark… I have 4 hours to get this working until start of business here :frowning:

I’ll let you know what, if anything, I can find in the tcpdump


Please confirm that they were in separate trunks with different names.

hadn’t tried two separate trunks, just tried that… same thing, still not seeing anything in ‘sip set debug on’

just ran the tcpdump and tried a call, so going to take a look at that in Wireshark


Is sip set debug on working in general? For example, if you make a call from one extension to another, or an outgoing call, do you see the expected SIP trace?

Is pjsip used on any extensions or trunks in your system?

Conceivably, a SIP ALG in your router or firewall is intercepting and answering the incoming INVITE. Is your PBX on site or in the cloud? On a virtual machine? If so, details, please. Behind a NAT? (What router and/or firewall is between your system and the Internet?) If on site, do you have a ‘gateway’ (modem/router combination) from your ISP?

sip set debug on working as expected when extensions make outbound or ext <> ext calls.
no NAT
Server is Cloud (VMware vCenter 6.5), no NAT, no Firewall (I disabled it all on the PBX system until I get this working)
I have other PBXs in same Cloud provider, no issues. This is a new SIP provider (since I need Brasil local DID’s and termination rates)

Extensions connect to PBX via VPN, again no issues with outbound or extension to extension.

PJSIP is not used anywhere on the system, it is, in fact, disabled.

so tcpdump doesn’t show any traffic to/from either of the providers IP addresses.

It’s “gotta” be hitting something, I just can’t figure out what/where…

I’m very puzzled. This is a ‘register’ trunk, correct? Look at a REGISTER request to confirm that the Contact header has your correct public IP address and port. Your chan_sip bindport is 5060, correct? Check on your provider portal that the DID is routed to the account you are registering.

Was the SIP trace you posted sent to you by the provider, retrieved from their portal or obtained some other way?

Is the Y.Y.Y.192 address your correct public IP?

Is there anything ‘funny’ about the VMware networking setup? In particular, does your VM have its own dedicated static public IP?

Are there other incoming trunks on this system? Do they work ok?

Have you tried configuring a non-VPN extension for testing (it normally wouldn’t work, but with all your security disabled for testing, I’d expect it to be ok)?

ok, got it ringing over the VPN to the remote extension.

What I did:

Ensured that Anonymous and Guest SIP set to ‘Yes’
rebooted entire server
once server was up:
systemctl stop iptables
systemctl stop fail2ban

then asterisk -r
core set verbose 99
core set debug 99
sip set debug on

made a call from my cell phone to one of my DIDs, this worked.
Removed the any/any Inbound Route, applied changes, made call again, worked.
Set anon and guest SIP to no, applied changes, call failed

Re-enabled IPtables and Fail2Ban, repeated call, worked fine.

Now I’m going to go dig through the sip debug output to figure out why anon and guest needs to be enabled. Not too worried seeing as how all inbound is denied via iptables, except 1194 OpenVPN traffic from anywhere and my static IP, my secondary VPN static IP and my providers 2 IP addresses (for 5060:5070 and 10000:20000 only).

Remote site firewalls are locked down similarly.

Thanks for your help Stewart!

This is not a very techy suggestion but worked for me. I got 2 extensions from my sip provider. Set up one with a sip trunk and that one is the outbound route. Set up the 2nd extension on a pjsip trunk. Directed inbound calls to that number within the sip providers settings. That has worked a charm. Before that i had similar problems to what you described.

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