Unable to receive incoming calls

Asterisk Asterisk Endpoints
1

A client has recently installed an Asterisk paging device and we cannot get an incoming call to complete to the line. The line registers successfully, but can’t figure out why the incoming calls are reaching ‘number not in service’.

<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Call is from [“WIRELESS CALLER” sip:8035795344@10.45.0.10;user=phone] : Dest address 208.104.4.80
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 CallMgr - Call [0x00d59774:sip]: Created
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP - Sending 180 response to INVITE. Dialog ID: 1:187
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13182616 CallMgr - Call [0x00d59774:sip]: Event received INCOMING
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-NET - Sending 520 bytes on transport 6 to Remote: 208.104.4.80:5060
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13879452 CallMgr - Conversation [0x00d57cd8]: Created
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13879452 CallMgr - Call [0x00d63a88:sip]: Created
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13879452 FBX - Redirecting call to: 8038214245
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13182616 CallMgr - Call [0x00d63a88:sip]: Event received OUTGOING
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Processing FCM event: CALL_PREPARE for Account Trunk_1
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13182616 CallMgr - Call [0x00d63a88:sip]: Event received VOIP_PREPARED
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13182616 CallMgr - Call [0x00d63a88:sip]: Event received DIAL
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Processing FCM event: CALL_PLACE for Account Trunk_1
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 CallMgr - Call [0x00d63a88:sip]: rtpAudio Channel added
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-NET - Sending 894 bytes on transport 5 to Remote: 10.41.204.22:5060
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Call to sip:8038214245@10.41.204.22 has been placed
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13646632 SIP-NET - Received 894 bytes on transport 1 from Remote: 10.41.204.22:50600
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-NET - Sending 507 bytes on transport 1 to Remote: 10.41.204.22:50600
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13646632 SIP-NET - Received 507 bytes on transport 5 from Remote: 10.41.204.22:5060
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP - Preparing to handle response to our request: 401 Authentication Required
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP - Informing Application Event: Invite Authentication Challenge, Dialog: 0:188
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-NET - Sending 455 bytes on transport 5 to Remote: 10.41.204.22:5060
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Processing SIP Protocol event: Invite Authentication Challenge for Account: Trunk_1
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-NET - Sending 1153 bytes on transport 5 to Remote: 10.41.204.22:5060
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Authenticating call to sip:8038214245@10.41.204.22 has been placed
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13646632 SIP-NET - Received 455 bytes on transport 1 from Remote: 10.41.204.22:50600
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13646632 SIP-NET - Received 1153 bytes on transport 1 from Remote: 10.41.204.22:50600
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-SRVR - Proxy: Request for non-existant extension: 8038214245
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-NET - Sending 354 bytes on transport 1 to Remote: 10.41.204.22:50600
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13646632 SIP-NET - Received 354 bytes on transport 5 from Remote: 10.41.204.22:5060
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP - Preparing to handle response to our request: 404 Not Found
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP - Informing Application Event: Reply, Dialog: 0:188
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13667700 SIP-NET - Sending 715 bytes on transport 5 to Remote: 10.41.204.22:5060
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13646632 SIP-NET - Received 715 bytes on transport 1 from Remote: 10.41.204.22:50600
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Processing SIP Protocol event: Reply for Account: Trunk_1
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Call event for call id 0:188
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Call event for call attempt with sip:8038214245@10.41.204.22
<188>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - This call attempt has ended with Response Code 404
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13182616 CallMgr - Call [0x00d63a88:sip]: Event received VOIP_ERROR
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13182616 CallMgr - Call [0x00d59774:sip]: Event received DISCONNECT
<190>1 2026-04-28T07:58:46 10.41.204.22 - 13638224 FCM-SIP - Processing FCM event: CALL_REJECT for Account Trunk_1_Account_1

2

What is this output from?

3

404, as a SIP response, means the called number is unknown.

Your logs don’t show what that number was.

4

According to the end client, this log was from an Asterisk PBX.

5

I can say it’s certainly not from Asterisk itself.

6

We were calling to 803-821-4245. For some additional context on this issue - we provide a Broadsoft SIP trunk for this client’s Asterisk PBX. The SIP trunk is registered, but when we call 803-821-4245 (or call 4245 internally) - the caller receives a recording that the number is not in-service. The end client reported back that the call is supposed to hit the Asterisk PBX and then it is used for paging.

I see a 404 Not Found coming back from the Asterisk PBX side, which I am under the assumption that there is no from-to route or the like setup on his PBX since the call will not complete.

7

As Joshua says, your log did not come from Asterisk.

Asterisk defines endpoints, which are matched against, typically, either user part of the From header, or the IP address. These select a context in which to interpret the number. For each context it contains patterns to be matched against the destination number. 404 implies either the first part worked, or Asterisk has been configured to accept unmatched callers, but there was mo match, associated with the context from the first stage, against the user part of the destination address.

Typically the rules for identify the endpoint are in /etc/asterisk/pjsip.conf, and those for taking recognizing a number, in a given context, are in /etc/asterisk/extensions.conf. However there are other ways of providing the information.

There is not enough information to prove that you are even talking to Asterisk, but if you are, the most practical way of proceeding are to get the logs from Asterisk, and interpret them in the light of the way Asterisk has been configured.