Solved Incoming DIDs - Inbound Rules Not Working

[Alan Figgins]

Hi All,

I have a situation with a 3CX install (Debian ISO / Bare Metal) where I cannot get incoming DIDs to route to the extension required, but rather are always picked up by the main trunk number IVR.

I have tried getting this to work with both DID and CID rules. DID rules seem to do nothing under any circumstances, which is odd, since I figured that would be how it should work, but apparently not (at least for this situation).

I am fairly convinced that it is something to do with the way that the provider (2Talk in NZ) is sending the calls / numbers through, since I can get it to work fine under one scenario, but not the one we need.


This works: If a DID number from a different account than the main trunk number (at the provider) is diverted to the main number, I can capture that (with an incoming CID rule, but not with a DID rule), and redirect the number to an extension.

This fails: If a DID number from within the same account as the main trunk number (at the provider) is diverted to the main number, I cannot capture that (with either an incoming CID rule, nor with a DID rule), and redirect the number to an extension.


So, it seems to me that the way that the provider diverts the number depends on whether it is from the same account or another account. I realise that I will probably need to talk to the provider, but I am hoping to get some assistance to know what to say to them - get my wording / terminology right if you like


I have done a capture of each and the one that works shows the following initial lines in the activity log:

08/14/2019 9:56:11 PM - [CM503001]: Call(C:779): Incoming call from Line:10001<<09XXX3565 to <sip:[email protected]:5060>
08/14/2019 9:56:11 PM - Line limit check: Current # of calls for line Lc:10001(@2Talk - 09 XXX 1290[<sip:[email protected]:5060>]) is 1; limit is 10
08/14/2019 9:56:11 PM - [CM503012]: Inbound office hours rule (ZZ - Test - Alan - 20190814 - 2130) for 10001 forwards to DN:001
08/14/2019 9:56:11 PM - [Flow] No office hours set, office hours assumed
08/14/2019 9:56:11 PM - [Flow] Looking for inbound target: called=09XXX1290; caller="649XXX3565" <sip:09XXX3565@:5060>

That seems to me to show that the call comes in, aimed at 09XXX3565, 3CX then identifies the Inbound CID Rule (ZZ - Test - Alan - 20190814 - 2130), and forwards the call to DN:001 (my test extension). That seems to make perfect sense, and it works as expected with the call going to Ext 001. The odd thing is that it identifies the 'caller' as 649XXX3565 which is actually the DID number, not the actual, originating caller number.


However, the one that fails has these initial lines:

08/14/2019 10:02:20 PM - [CM503001]: Call(C:781): Incoming call from Line:10001<<021XXXXXX to <sip:[email protected]:5060>
08/14/2019 10:02:20 PM - Line limit check: Current # of calls for line Lc:10001(@2Talk - 09 XXX 1290[<sip:[email protected]:5060>]) is 1; limit is 10
08/14/2019 10:02:20 PM - [CM503012]: Inbound office hours rule (00 - Default Incoming DID) for 10001 forwards to DN:200
08/14/2019 10:02:20 PM - [Flow] No office hours set, office hours assumed
08/14/2019 10:02:20 PM - [Flow] Looking for inbound target: called=09XXX1290; caller="6421XXXXXX" <sip:021XXXXXX@:5060>

Here, the 'caller' is shown as 6421XXXXXX - this is actually correct in that it is the actual, originating caller number.

However, nowhere does it identify the called (DID) number, rather it says the 'called' number is 09XXX1290 (which is the main trunk number, not the DID), and thus sends the call to the main IVR (Ext 200).

A further review of the activity log, shows that the only time that the DID number is mentioned is in the headers (if that is the correct terminology) where there is a single line showing:

Diversion: <sip:[email protected]>;reason=unconditional

649XXX1079 is the actual DID number called.


Questions:

Q1) Is there any way to 'write' an inbound rule (DID or CID) to capture that?

Q2) Could I do something under the SIP Trunk > Inbound Parameters to make it work?

Q3) If not, do I need to talk to the provider (2Talk)? If so, what should I say to them to help them to help me?


Thanks,

Alan.

 

[YiannisH_3CX]

Hello @Alan

First of all make sure that you used the default template included in the PBX to setup 2Talk.

Then make sure that your DIDs are added like local numbers i.e. 0123456789

I believe that you are having source identification issues and the PBX cannot match the inbound call to a DID because the format is wrong. Apply the changes and let us know if that resolves the issue.

 

[Alan Figgins]

Hi Yiannis,

I did use the template (enter country, provider, main trunk number) when I setup the connection.

I have also exclusively entered all phone numbers in the same full national format (012345678). Here, in NZ, that format is: 0N LLL XXXX where 0N is a two digit code for the region (the first of the two digits is always a zero, to let the system know you want to get out of your local area I guess), LLL is a three digit code for the local area (within the region), and XXXX is the four digit number on the local exchange (or at least, that is what the format meant when it was first setup fifty years or ago or whatever).

I have not entered any numbers in full international format (+II N LLL XXXX), although I would expect that to work too, since I have never found a situation where it would not work on standard PSTN / mobile phones, even if I was calling to my (literal) neighbour.


I am reluctant to remove and re-add the SIP Trunk connection to 2Talk on a production system, at least during the week. If I was going to do that, I'd prefer to do it Saturday morning, since it is all working, with the exception of the DIDs (and they are currently 'working' as we have temporarily diverted them to the users' mobile numbers, and they are actually happy with that). For the avoidance of doubt, that is not the problem - we only diverted them to the mobiles, and bypassed 3CX when we found we could not get it working through 3CX.

I could wait until the weekend and play with it though.


In terms of the SIP Trunk settings, I do note that, to get Outbound Caller ID working, I had to make this change:

Outbound Parameters

From : User Part

Was Originally = "OutboundCallerId" Outbound caller Id taken from Extension settings in Management Console

Changed To = "AuthID" authentication

However, I am thinking that this would not impact on recognising incoming calls / DIDs?


Thanks,

Alan.

 

[AWS2P]

Hi,
as Yiannish said, perhaps format number doesn't match so your CID or DID inbound rule is not applying.

Try to modify your rules with wildcard like this : * LLXXXX

 

[Alan Figgins]

Hi aws2p

The difficulty is that I cannot see how to write a rule to capture the DID number, when the DID number does not appear at all, prior to the call being routed to the main IVR?

From my post above, this is what 3CX is getting:

08/14/2019 10:02:20 PM - [CM503001]: Call(C:781): Incoming call from Line:10001<<021XXXXXX to <sip:[email protected]:5060>
08/14/2019 10:02:20 PM - Line limit check: Current # of calls for line Lc:10001(@2Talk - 09 XXX 1290[<sip:[email protected]:5060>]) is 1; limit is 10
08/14/2019 10:02:20 PM - [CM503012]: Inbound office hours rule (00 - Default Incoming DID) for 10001 forwards to DN:200
08/14/2019 10:02:20 PM - [Flow] No office hours set, office hours assumed
08/14/2019 10:02:20 PM - [Flow] Looking for inbound target: called=09XXX1290; caller="6421XXXXXX" <sip:021XXXXXX@:5060>

The DID number does not appear there at all - only the main trunk number (09XXX1290).

Presumably it won't make any difference how I use a wildcard?

Am I missing something obvious?

Thanks,

Alan.

 

[Saqqara]

If 3cx is not seeing the DDI number, then you probably need to speak to your SIP provider and confirm they are passing the DDI number and if so which field.

 

[Alan Figgins]

Hi Saqqara,

Yes - I totally agree, hence my original question (3) in my first post:

What should I say to the provider to help them to help me?

Thanks,

Alan.

 

[AWS2P]

I assume you know which DID you subscribe to your SIP provider, so question seems easy
Ask if this DID number is sent on your trunk , if so in which sip field they are sending DID number

Is there something else sended than 09XXX1290 on your sip trunk ?

 

[Alan Figgins]

Hi aws2p,

Yes - you've nailed it - that is the key question!

I will go back to them and ask which field it is being passed within.

Thank you!

Alan.

 

[YiannisH_3CX]

I believe you are not seeing the DID because you are looking at the wrong part of the call. Start a Wireshark capture and "catch" an incoming call. Then open it and see what the provider is sending and to which SIP field. I just tried a test call and the template is setup correctly.

One thing you mentioned however is puzzling:

Outbound Parameters From : User Part Was Originally = "OutboundCallerId" Outbound caller Id taken from Extension settings in Management Console Changed To = "AuthID" authentication

I do not seeing this working as the trunk is IP based and AuthID is not required. Are you using an IP based trunk or an Authentication based trunk?

 

[Alan Figgins]

Hi Guys,

It was a setting issue at the provider.

Once the configuration at the provider was changed, the DID is shown up front, so the inbound call rule(s) can be used to divert the call to the right extension.

Thanks for your help - I really appreciate it.

Alan.

 

[YiannisH_3CX]

Glad you were able to resolve the issue and thank you for updating the thread with your solution.