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
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?
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?
[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?