Unable to get inbound DID calls and outbound calls

Hi All,
I need help with Inbound (DID) setup I have setup the Termination rates and origination rates still I am getting errors (TERMINATION_RATE_NOT_FOUND [31]) and outbound error messages ( ORIGNATION_RATE_NOT_FOUND [31]).
I will appreciate if someone can point me in the right direction.

I think I understand the issue.

If you have Skype or Telegram then you can give me.
I can help you over the anydesk.

It’s nothing wrong with the switch. It’s your configuration issue


Without asking for details(and as per my experience), I’ll advise you to delete all the rates that you have created, then download standard rates for outbound/inbound calls as CSV and import them accordingly. This will avoid a case where you’re creating wrong rates.

If you’re still facing the same issue, lete know.


Hello @voicecloud
It seems your provider sending the DID number format differently then your system has configured it. So that when system tries to find the number got as DID in database its not able to match. So either you need to ask the provider to send the call in the format as you configured in ASTPP or you need to configured the DID in the format as platform is receiving from DID provider, so that it can match and system can consider the call as Inbound and route it further as per the DID forwarding configured.

Thanks i had this issue with one of the DID provider i use the prefix to amend + as the number was coming with +44 i did it on provider IPaddress in acl

Thanks a lot I managed to resolve the issue it was related to the orientation and termination rates. Currently i see an issue where in CDR i cant see the trunk and Rate group of the inbound or outbound call. Note i have two trunks one for inbound and one for outbound

I will appreciate if you can assist my telegram
@ibrahimquraishi can do an anydesk session too.

I am having exactly this same problem for the past 3 days, how were you able to fix this problem.

I have the same issue, anyone knows how to solved?

Helps to post some logs and any other information. SO no, nobody knows how to solve because we know nothing about what is going on.

Hi thanks for the reply, this si the link for the output in my console, please help em if you know a possible solution thanks…


From looking at the logs, it seems your side cancelled the call.

  • 2023-08-17 19:02:39.909166 96.77% [DEBUG] sofia.c:7487 Channel sofia/default/14133899381@ entering state [terminated][487]

  • 2023-08-17 19:02:39.909166 96.77% [NOTICE] sofia.c:8729 Hangup sofia/default/14133899381@ [CS_EXECUTE] [ORIGINATOR_CANCEL]

  • 2023-08-17 19:02:39.929162 96.77% [NOTICE] switch_ivr_originate.c:3809 Hangup sofia/default/17324547221 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL]

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:581 (sofia/default/17324547221) Running State Change CS_HANGUP (Cur 6 Tot 361)

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_ivr_originate.c:4034 Originate Cancelled by originator termination Cause: 487 [ORIGINATOR_CANCEL]

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:844 (sofia/default/17324547221) Callstate Change DOWN → HANGUP

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:846 (sofia/default/17324547221) State HANGUP

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] mod_sofia.c:462 sofia/default/17324547221 Overriding SIP cause 487 with 487 from the other leg

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] mod_sofia.c:468 Channel sofia/default/17324547221 hanging up, cause: ORIGINATOR_CANCEL

  • 2023-08-17 19:02:39.929162 96.77% [INFO] mod_dptools.c:3637 Originate Failed. Cause: ORIGINATOR_CANCEL

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] mod_sofia.c:536 Sending CANCEL to sofia/default/17324547221

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:59 sofia/default/17324547221 Standard HANGUP, cause: ORIGINATOR_CANCEL

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:846 (sofia/default/17324547221) State HANGUP going to sleep

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:616 (sofia/default/17324547221) State Change CS_HANGUP → CS_REPORTING

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:581 (sofia/default/17324547221) Running State Change CS_REPORTING (Cur 6 Tot 361)

  • 2023-08-17 19:02:39.929162 96.77% [DEBUG] switch_core_state_machine.c:932 (sofia/default/17324547221) State REPORTING

  • 2023-08-17 19:02:39.929162 96.77% [INFO] mod_json_cdr.c:272 Process [6b27bd1b-64ca-46af-b65b-696188633033.cdr.json]

However, not enough reason for the call cancel is given. You will have to get the SIP messages. You can use sngrep for that.

I see you are using Anveo.com. Perhaps they made some changes. I t is my understanding they made call breaking changes often. You may also want to connect something like a PBX or SIP phone directly to them to make some test calls.

So this appears it could be a provider issue as I not seeing anything in the log for ASTPP to be cancelling the call.

The outbount calls work great with them, teh only thing, I have issues is with the incoming calls, or by anychanges is there any other DID provider you can recomet, for me to use with ASTPP… or should I just connect the DID to my PBX and from there send it to ASTPP. and thanks for the quick reply.

If it is incoming , you still need to check the SIP messages to see what is going on.

You can try VoIP.ms

Their support does not cost anything unlike Anveo, and they have a great Wiki on how to connect various PBX systems.

Use that link above, and they will give you a $10 credit once you top up with at least $15 and make one completing call.

Thanks for the link I tryt Voip.ms about a week ago and send the KYC and I havent recieve no response from there, thanks. and I was able to resolve teh issue was a misconfiguration in the URI that I made by mestake thnaks a lot.

Is ‘17324547221’ this the very exact number have created as DID in your system?

thanks for the reply, and that was actually the problem the DID was a different one I just had it setup wrong in the provider panel.