Solved Calls routing to IVR instead of DID

[DCB]

We're recently updated to version 18.0 update 3 Build 461. We have a DID pointed at a remote office that uses an SBC, which has also been updated.
Random calls that should be routing to the DID are hitting our main IVR and confusing callers.

 

[Evolute IT]

A DID is an ingress point, not a destination. Can you show the call log that it generates?

 

[DCB]

The call log suggests that people are dialing the main number. When we answer and talk to them, they're surprised, "Oh, I was trying to reach so-and-so."
The more I look at it, the more I wonder if this be a SIP provider (bandwidth.com) issue?

07/07/2022 1:20:24 PM - [Flow] Looking for inbound target: called=+1402819xxxx; caller="J WILSON " <sip:+1402598xxxx@:0>

07/07/2022 1:20:24 PM - CallerNameAddr: "J WILSON "<sip:+1402598xxxx;nf=e>

07/07/2022 1:20:24 PM - Call from "J WILSON " <sip:[email protected]>;tag=gK002c1e2f to <sip:[email protected]>;tag=159b2b7d

 

[leejor]

If the main IVR is the default route on the trunk, and a DID number is being set by your provider, then I would have to assume that the number sent does not exactly match the number(s) you have in the DID rules. Make use of the * wildcard, to replace the first 3 or 4 digits in the rule number, so that a match is made on the remaining digits

 

[DCB]

The DID is set in the system, but not by the provider. I do have a wildcard before the area code. Should I wildcard everything except the last 4? (eg *1234)
Here's my SIP trunk for the DID

 

[leejor]

I suppose you could, but may not be necessary to go to that far..
You say...

The DID is set in the system, but not by the provider.

Does that mean that your provider is not yet sending the DID information?

 

[DCB]

The provider is sending the correct information as far as the call is concerned. My understanding was that the 3cx would route the call based on the incoming number that was dialed. Here is a successful test placed from my mobile:

07/11/2022 7:44:47 AM - Source is identified as trunk Lc:10001(@(402) 553-xxxx (Joe's Cafe')[<sip:[email protected]:0/UDP>]) (single match by DID)
07/11/2022 7:44:47 AM - Trunk Lc:10001(@(402) 553-xxxx (Joe's Cafe')[<sip:[email protected]:0/UDP>]) has matched as source by DID only
07/11/2022 7:44:47 AM - Default best-route IP is determined as 172.31.xxx.xxx

Here's a failed call that was performed 10 seconds after terminating the successful test. In both cases, 402-553-xxxx was dialed.

07/11/2022 7:45:26 AM - No inbound caller ID reformat rule for DN:10000 is defined, or it is disabled (<Rules />)
07/11/2022 7:45:26 AM - Source is identified as trunk Lc:10000(@402-819-xxxx[<sip:[email protected]:0/UDP>])
07/11/2022 7:45:26 AM - IncomingCall: C:2902 from <sip:[email protected]:0/UDP> to <sip:[email protected]:5060/UDP>

 

[Saqqara]

I would change the DDI to *553xxxx (where x are the actual numbers)

Looking at the log, the incoming number is (402) 553-xxxx , where you have setup the DDI as *402553xxxx - it will not match

 

[DCB]

This weekend, I was trying some things and I tried that too. Apologies for not posting this earlier:

 

[Voipiod]

I'm having same issue

 

[YiannisH_3CX]

Hi @DCB

Have you followed the Bandwidth guide to set them up? All numbers should be added in the E164 number format. Also make sure that you have set them up using the default template.

 

[DCB]

Hi Yannish. I went back through this doc and verified that everything is setup as it should be. Still no luck.

 

[YiannisH_3CX]

Can you send a screenshot of your SIP Trunks Inbound parameters page so we can verify how the trunk is set up?

 

[DCB]

Here you go. Again, this was working fine until the system was updated.

 

[YiannisH_3CX]

Ok great, edit your DIDs back to the E164 format (+1XXXXXXXXXXXXX) and try again.
Dial the main number and confirm its working. Then dial the second number and see if its routing to the correct destination or not.
Make sure your Inbound rules are correct for each number and pointing to the correct destination.
Also how many numbers do you have in your trunk?

If the test fails navigate to your Activity log and search for the Invite coming from the provider (you should be in Verbose logging). Is the called number sent correctly?

Here you go. Again, this was working fine until the system was updated.

I can assure you its not the update. The functionality has not changed, especially since you are running update 3.

 

[DCB]

Yiannis, I did as you suggested.
Both SIP trunks DIDs only have the E164 format.


The main number (819) is working fine. No issues. Placed a call to 553 from my desk, and it worked fine. Called again from my mobile and it failed (routed to main number).
These are the only 2 numbers in the trunk. 553 is set to only have a maximum of 1 call.
Inbound rules are correct. 553 is set to deliver to an extension (9000). 819 is set to ring to an IVR (8001).

Here is the redacted log from the failed call. It's probably more than needed. You can see the misroute in the first 12 lines. To me, it looks like the call is be presented correctly, in accordance with the DID (line 2 from the bottom)
Sorry for the word-wrap. I didn't see an option to disable it.

07/20/2022 8:59:22 AM - Added leg L:94.2[Ivr:8001] <-> L:94.1[Line:10000<<++1402630xxxx] 07/20/2022 8:59:22 AM - [Flow] Call(C:94): making call from L:94.1[Line:10000<<++1402630xxxx] to T:Ivr:8001@[Dev:sip:[email protected]:5483;rinstance=3d151ba25d9c3e7e] 07/20/2022 8:59:22 AM - [CM503027]: Call(C:94): From: Line:10000<<++1402630xxxx ("ME " <sip:[email protected]:5060>) to T:Ivr:8001@[Dev:sip:[email protected]:5483;rinstance=3d151ba25d9c3e7e] 07/20/2022 8:59:22 AM - [CM503004]: Call(C:94): Route 1: from L:94.1[Line:10000<<++1402630xxxx] to T:Ivr:8001@[Dev:sip:[email protected]:5483;rinstance=3d151ba25d9c3e7e] 07/20/2022 8:59:22 AM - [Flow] Endpoint Ivr:8001 has no forwarding rule on reason 'All calls' 07/20/2022 8:59:22 AM - [Flow] Call(C:94): has built target endpoint: Ivr:8001 for call from L:94.1[Line:10000<<++1402630xxxx] 07/20/2022 8:59:22 AM - [Flow] Target endpoint for 8001 is Ivr:8001 07/20/2022 8:59:22 AM - [Flow] Building target endpoint to 8001 from "ME " <sip:[email protected]:5060> 07/20/2022 8:59:22 AM - [CM503010]: Call(C:94): Making route(s) from Line:10000<<++1402630xxxx to <sip:[email protected]:5060/UDP> 07/20/2022 8:59:22 AM - Remote SDP is set for leg L:94.1[Line:10000<<++1402630xxxx] 07/20/2022 8:59:22 AM - [CM505003]: Provider:[402-819-2274] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060] 07/20/2022 8:59:22 AM - Inbound DID: ''; Phonebook Name: '' 07/20/2022 8:59:22 AM - [CM500002]: Call(C:94): Info on incoming INVITE from Line:10000<<++1402630xxxx: Invite-IN Recv Req INVITE from 67.231.IP.ADDRS:5060 tid=0cBeb89e3a6311f2454 [email protected]: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 67.231.IP.ADDRS:5060;branch=z9hG4bK0cBeb89e3a6311f2454 Max-Forwards: 70 Contact: "ME " <sip:[email protected]:5060> To: <sip:[email protected]> From: "ME " <sip:[email protected]>;tag=gK0c2483aa Call-ID: [email protected] CSeq: 975282 INVITE Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, OPTIONS Content-Disposition: session; handling=required Content-Type: application/sdp Supported: replaces P-Asserted-Identity: "ME " <sip:[email protected]:5060> Content-Length: 282 v=0 o=Sonus_UAC 595989 50037 IN IP4 67.231.IP.ADDRS s=SIP Media Capabilities c=IN IP4 216.82.225.XXX t=0 0 m=audio 55186 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 07/20/2022 8:59:22 AM - [CM503001]: Call(C:94): Incoming call from Line:10000<<++1402630xxxx to <sip:[email protected]:5060> 07/20/2022 8:59:22 AM - Line limit check: Current # of calls for line Lc:10000(@402-819-XXXX[<sip:[email protected]:0/UDP>]) is 1; limit is 5 07/20/2022 8:59:22 AM - Blacklist check: number '+1402630xxxx', list: ''; result = false 07/20/2022 8:59:22 AM - Dev(2137808107):[sip:[email protected] / 10000]: PBX contact is public IP: <sip:[email protected]:5060/UDP> 07/20/2022 8:59:22 AM - [CM503012]: Inbound office hours rule (unnamed) for 10000 forwards to DN:8001 07/20/2022 8:59:22 AM - [Flow] No office hours set, office hours assumed 07/20/2022 8:59:22 AM - [Flow] Looking for inbound target: called=+14025537008; caller="ME " <sip:+1402630xxxx@:0> 07/20/2022 8:59:22 AM - CallerNameAddr: "ME "<sip:+1402630xxxx;nf=e164> 07/20/2022 8:59:22 AM - Source is identified as trunk Lc:10000(@402-819-XXXX[<sip:[email protected]:0/UDP>]) 07/20/2022 8:59:22 AM - IncomingCall: C:94 from <sip:[email protected]:0/UDP> to <sip:[email protected]:5060/UDP> 07/20/2022 8:59:22 AM - Added leg L:C:94.1[No endpoint yet] 07/20/2022 8:59:22 AM - Call from "ME " <sip:[email protected]>;tag=gK0c2483aa to <sip:[email protected]>;tag=014a473e 07/20/2022 8:59:22 AM - Source is identified as trunk Lc:10000(@402-819-XXXX[<sip:[email protected]:0/UDP>])

 

[YiannisH_3CX]

The called number in the logs does not match any of the 2 DIDs you have as far as I can tell unless you changed the numbers in the log you posted.

If that is the case then the PBX does not have anything to match to and routes the call to the first trunk it sees. Compare the log from the successful call to the failed call and see if the successful call has the right called number.

Also do you have 2 separate trunks from Bandwidth and not 1 trunk with 2 DIDs?

 

[DCB]

This:
07/20/2022 8:59:22 AM - Call from "ME " <sip:[email protected]>;tag=gK0c2483aa to <sip:[email protected]>;tag=014a473e

Doesn't match this? (The last 4 are the same)

 

[leejor]

Is the number ("ME"), your caller ID, or the DID (the number you dialed)?

 

[DCB]

ME is my actual name, so my caller ID