Solved What number from SIP to PBX?

[Rick Ford]

Hello all,

I've searched through the logs and I can't find what I'm looking for (I think). I'm trying to discover the actual number presented from the SIP to the PBX. For the most part all of our DID numbers are functioning correctly. When an outside caller dials the DID the correct extension rings. However, for a few (less than 10) people that call in regularly, their calls ALWAYS go to the receptionist and not the extension they dialed. Our setup is a SIP from Deutsche Telekom in Germany. We have a main number xxx 570 and the extensions are 10-99, so when most callers dial xxx 5736 it rings my phone on my desk. We have the main number xxx 570 routed to ext 11 as the main receptionist. When a few people call my number xxx 5736 or any extension (xxx 5737 or 5733) their calls ALWAYS go to the main receptionist on ext 11. But, the call log simply says the call came into ext11. I can't tell if the SIP presented xxx570 which is routed to ext 11, or if the SIP somehow presented xxx5711.

This is a relatively new 3CX implementation, starting in Nov 2020. Version 16.0.1078. We are self-hosted on a DELL server.

Any ideas? My 3CX expert left this week, so I'm scrambling to pick up the slack.

Thanks,
Rick

 

[YiannisH_3CX]

Hello @Rick Ford

For the call to be routed to the main trunk number it means that the PBX cannot match the called number to an Inbound rule. So those calls are all routed to the main trunk number.

So the first thing to check is to see if you have any CID rules configured that would force the PBX to match the caller with a rule. Those will be under your Inbound rules settings.

If no CID rules are configured then you will need to look at the logs of your PBX to determine how the calls are reaching your system. To be able to see the full SIP messages you need to enable verbose logging. To do so navigate to Dashboard / Activity Log / Settings and set the logging level to verbose. Restart the PBX services to fully enable the logging.

Replicate the issue and check the logs. You are looking for the called number that arrived in your PBX. For Deutsche Telekom it's either the "To" sip field or the "P-Called-Party-ID" depending on which product you have.

 

[Rick Ford]

Thanks YiannisH,

I looked at the CID rules (inbound). The only ones listed are the DID rules created by the 3CX software, one for each extension. I enabled verbose logging and restarted all the services. (Wow, what a lot of data!) I looked through two calls, one successful and one failed. I don't fully understand all the data, but I found a couple of things that are different. Here are two different log entries for the successful and failed calls. I have partially edited the numbers for privacy.

Successful call, from an external number +49----8099 to extension 36
15:52:15:425 Call from <sip:[email protected];user=phone>;tag=63e86612 to <sip:+49yyyyyyy5736@telekom.de;user=phone>;tag=0602115c
15:52:15:426 [Flow] Looking for inbound target: called=+49yyyyyy5736; caller="+49xxxxxx8099" <sip:+49xxxxxx8099@:0>

Failed call from an external number +49--8098 to extension 37
15:21:04:788 Call from <sip:[email protected];user=phone>;tag=1134f325 to <sip:0yyyyyy5737@tel.t-online.de>;tag=37c8730c
15:21:04:789 [Flow] Looking for inbound target: called=0yyyyyy45737; caller="+49zzzzzz8098" <sip:+49zzzzzz8098@:0>

The differences I see:
1. in the successful call the TO: sip is telekom.de but in the failed one it is tel.t-online.de
2. the called number is +49yyyy vs 0yyyy

Also, in the failed call it could not find any inbound rules to match:
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5736'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5701'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5703'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5737'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5712'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5718'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5716'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5715'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5710'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5702'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5711'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5721'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5733'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5722'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5724'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5723'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5717'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5729'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5730'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5725'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5728'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5750'
12/01/2021 15:21:04:792 | 6 | Checking inbound rule '': hour type = 2; cond = 6; mask = '+49yyyyyy5759'
12/01/2021 15:21:04:793 | 6 | Checking inbound rule '': hour type = 2; cond = 4; mask = ''
12/01/2021 15:21:04:793 | 6 | Rule match

Thanks for your assistance; this one has me stumped.

Rick

 

[leejor]

You might want to make use of wild cards, in your DID rules to accommodate numbers prefixed with 0 and +44. It would seem you are receiving calls with both number formats.

https://www.3cx.com/community/threads/inbound-did-routing-issue.60069/

 

[Rick Ford]

Hallo leejor,

THANK YOU. That worked. In the SIP Trunk list of DID numbers I edited the number to have a wild card: I changed the +4976xxxx to *76xxxx. It worked for the first call, so thank you very much.

Now I just have to change all of my extensions; is there an easier way than changing all of them by hand?

Rick

 

[YiannisH_3CX]

That shows that Deutsche Telekom is sending calls to you from different servers that use different number formats. The best solution is to use wildcards like @leejor suggested.
You can edit your DIDs manually or you can export your Inbound rules and editing the csv file. You then delete your inbound rules and DIDs (from your trunk settings) from the management console and import the new inbound rules back into the PBX. I recommend keeping the original file in case something goes wrong and performing a backup of the configuration just in case.
Note that the main trunk number cannot be deleted.

 

[Rick Ford]

Thanks YiannisH, that is good to know. I had already done them all by hand, but then I experimented with a few other changes using your suggestion to export the rules, change the file, and import them again. Thanks for the tip!