Great way to start the day. We have lost our connection with the trunk provider.
Trunk provider says the traffic they send goes unanswered.
Outgoing call log says “TRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE:21 - failing through to other trunks”
Inbound calls rollover to the assigned failover number.
Cause No. 21 - call rejected.
This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.
Only suggestion
A) pay your bill if you haven’t
B) check with your provider otherwise
From provider: “The traffic we send goes unanswered. Is the FPBX on PJSIP? Is have a firewall enabled? Is it behind a firewall?”
Firewall makes no difference on or off. We have money in the account. 
As for PJSIP tsee below, is that saying I have a SIP registration but no PJSIP?
Asterisk Info
Yet the sent you a Cause 21, I would turn on your SIP debugging for Your F1System trunk IP
Incoming calls are working after a restart. What is that screen saying.
Hit enter too fast there.
I am not sure how to read this, what matters.
The one thing that stands out is you show one chan_sip registry, from a shell
rasterisk -x “sip show registry”
Your outbound call is on a pjsip trunk. The provider is rejecting the call. For useful troubleshooting, at the Asterisk command prompt, type
pjsip set logger on
make a failing test call and post a new log.
However, I suspect the problem is a bad outbound caller ID.
[2020-07-23 10:23:32] DEBUG[12926][C-0000002a] pbx_variables.c: Result of 'TRUNKOUTCID' is '303-464-0011'
[2020-07-23 10:23:32] DEBUG[12926][C-0000002a] pbx_variables.c: Result of 'USEROUTCID' is '204'
I don’t know which of these is being sent, but both are wrong. Your provider most likely expects 13034640011, +13034640011 or possibly 3034640011.
The logs are not meaning much to me. What shows that the call was rejected?
Could this be related to IP authorization, I do not see in the logs that IP Auth is being used?
Maybe sngrep is more readable for you?
Sure, if your public IP address changed, your provider will reject calls until you update their portal with your new IP address.
In any case, with IP auth there is no registration. And, assuming that your incoming trunk is pjsip (that’s what your outgoing trunk is), then any registrations would be with pjsip.
The ip did not change.I have recreated the trunk and the outbound route then restarted asterisk, still have no outbound, ACB. How would I tell if IP Authorization fails?
As requested earlier, do the
pjsip set logger on
make a test call and paste the new log. With luck, the error response from the provider will have a clue as to what’s wrong.
More a matter of not knowing what it means. I can suss out how it builds the call and how it routed through all the PBX options but not how the connection itself. I am expecting to see something that shows I have a route that includes my techid and POP. Right church, wrong pew?
Sorry, thought I mentioned pjsip command not found. Suggestion?
You meant CLI. Got it.
The logger was not on for this call. Please try again.
When you type
pjsip set logger on
you should see a response
PJSIP Logging enabled
After doing that, make your test call, being sure not to do any restart, reload, apply config, etc., which will turn logging back off.
[2020-07-23 12:26:03] VERBOSE[2295][C-00000021] app_dial.c: Called PJSIP/[email protected]
[2020-07-23 12:26:03] VERBOSE[2295][C-00000021] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)
In between these lines is where the SIP trace should have appeared, but didn’t.
However, are you sure this is for the correct call? You didn’t post the log until 12:45 MDT. Was the call really 19 minutes earlier?