Solved Calls to non-existing numbers generate multiple calls in V18

[ToniGarcia]

Hello, we have detected a problem since we have v18, we have received emails indicating that we have exceeded the number of licenses, we have investigated in the Call Log and we have seen that if we call an internal extension that does not exist, the system suddenly generates 20 /30 calls to that number.




In the example, extension 1192 has called 3533 and it does not exist.

We have detected this with v18, in v16 we did not have this problem.

Gracias.

 

[VasilisV_3CX]

Hi @ToniGarcia,

Do you have any outbound rules that match 3533?

Who is your SIP Provider?

What version of PBX are you using?

Can you replicate this by dialing any other numbers? Does this only happen with numbers that don't exist?

 

[ToniGarcia]

Hi @ToniGarcia,

Do you have any outbound rules that match 3533?

Who is your SIP Provider?

What version of PBX are you using?

Can you replicate this by dialing any other numbers? Does this only happen with numbers that don't exist?

Thanks for your answer, I don't have any outbound rule for this extension, This problem happens with any internal extension that doesn't exist.

I can replicate the problem by dialing any internal number that doesn't exist.

Our provider is Vodafone, but this happens to us on internal calls.

Version 18.0.3.461

Thank you.

 

[VasilisV_3CX]

Hi @ToniGarcia,

I'll PM you shortly regarding this.

 

[ToniGarcia]

Hi @ToniGarcia,

I'll PM you shortly regarding this.

Thanks, I wanted to add that we have a bridge with a Beronet, I see that these calls are also shown in the Beronet in the active calls, I don't know if it must be a problem with the Beronet, but I don't remember having this problem before with v16

 

[leejor]

What does the Activity Log show, when you dial this number? (Verbose) Is it attempting to route it somewhere?

 

[ToniGarcia]

Hello, this is de call log

05/05/2022 3:43:34 PM - L:42216.1[Extn:3660] got Terminated Recv Req CANCEL from 172.23.16.11:5060 tid=643438923 Call-ID=[email protected]: CANCEL sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 172.23.16.11:5060;branch=z9hG4bK643438923;rport=5060 Max-Forwards: 70 To: <sip:[email protected]> From: "Toni Garcia" <sip:[email protected]>;tag=291470595 Call-ID: [email protected] CSeq: 141 CANCEL User-Agent: Grandstream GXP2170 1.0.11.16 c074ad05624a Content-Length: 0

We have an outgoing rule that makes 4-digit extensions direct them to the Beronet Bridge, which I don't know because it causes the loop.

 

[leejor]

I would make that rule a bit more strict (a required prefix, or leading digit?), or it will be used whenever a four digit number, that does not exist in the PBX, is dialed.

 

[ToniGarcia]

Hello, we can't add a prefix to the extension, but I still don't understand the 3cx loop behavior, I would say that before with v16 it didn't happen, or maybe we hadn't detected it.

 

[ToniGarcia]

It's hard to do this on a production system with the volume of calls we have, isn't there a way to see how the loop is caused?

 

[leejor]

So....your 4 digit outbound rule, is going to be used when any non-existent extension (or SIP ID) is dialed. Where that call then goes, or if it routes back to 3CX, then repeats the same loop, is what you will have to determine. Obviously you have a reason to send some 4 digit numbers to the BridgeBaronet trunk, but those numbers must exist somewhere. If there is a specific range of numbers that you need to send calls... 2xxx, 3xxx, or even 23xx, as examples, you could make the outbound rule, a bit more "selective". This would cause any invalid number call, to simply fail.

 

[ToniGarcia]

So....your 4 digit outbound rule, is going to be used when any non-existent extension (or SIP ID) is dialed. Where that call then goes, or if it routes back to 3CX, then repeats the same loop, is what you will have to determine. Obviously you have a reason to send some 4 digit numbers to the BridgeBaronet trunk, but those numbers must exist somewhere. If there is a specific range of numbers that you need to send calls... 2xxx, 3xxx, or even 23xx, as examples, you could make the outbound rule, a bit more "selective". This would cause any invalid number call, to simply fail.

We have the Beronet because we have a Trunk against a Cisco Call Manager, the extensions that 3CX does not have are referred to the Call Manager, but if the extension does not exist, 3cx should sound a message that it does not exist, the rule is not known. if it is possible, for example 3407 today is not a 3cx extension and tomorrow it can be, I think it is something basic that if the pbx does not get an answer, it has to reject the call.

 

[leejor]

Unfortunately (for you), the way it works, is that if you dial a number, and it does not match a valid extension number, or a SIP ID, on the PBX, then 3CX will attempt to match an outbound rule. In your case, it finds one, that is very vague, and happens to match the length of an extension number, and uses it. What happens to the call after that, and if it is sent back to 3CX (does the Cisco do that?), is what you will have to determine.

 

[ToniGarcia]

Hello, in the call to a non-existent number nothing is heard, while the phone is off the hook in the Call log continuous calls appear as in the first image and there comes a time when 3cx notifies me that I have run out of licenses due to excess use of channels.

 

[leejor]

And that is why I wonder if a call, routed out on the baronet trunk, to the Cisco is ending the call back to 3CX, only to be repeated.
If everything works properly, the call will route to Cisco, the be dealt with it at that destination, busy tone, or a non-existent number recording. Obviously, there are valid number that are being sent over this trunk group, or you would not have created it. Do those calls work properly? If so, then the "problem" is probably in the Cisco, not knowing what to do with invalid numbers.

Is this trunk two-way?

 

[ToniGarcia]

Hello, with the numbers that I am having the loops, they do not exist in cisco, it is a range of 3CX extensions, when the calls are from the range of Cisco extensions, Cisco tells me that the number does not exist, the trunk is bidirectional.
I don't know if it's possible the range of 3CX extensions that doesn't go towards the outgoing rule. thank you

 

[YiannisH_3CX]

When you dial a number the PBX will go through its list of extensions to find a match. If it does not, it will look for an outbound rule to send the call out. If it finds one the call will be directed out.
The way to limit that is by limiting your outbound rule either by a prefix or by adding the Cisco numbers are the valid numbers to be dialed.

What happens in your case is because you are using a Bridge with a Beronet (which I have no idea why that is necessary) the call goes out and it is sent back in from the other side because there is no match there either. You may want to look at why the call is routed back to 3CX.
As this is a bridge 3CX expects that you are contacting a 3CX extension when the call comes back to it looks for an extension and if it does not find one it routes the calls back out of the PBX.

You don't hear anything during this because each side is sending a trying message until the call is established but since the call is in a loop it never does.

In my opinion this is a case of bad configuration because neither side is doing something technically wrong.

 

[ToniGarcia]

Hello, Our 3CX Provider installed a Beronet for internal calls between Cisco and 3Cx, our parnet could not make a trunk / bridge between 3CX and Cisco for which the CCM version is old, but it is a separate issue.

What I don't understand is why with v16 we had not detected this problem.

The solution would be according to what you tell me would be to filter the Range of 3CX extensions so that they do not go to the output rule. I would like to do it the other way around, filter the range of 3CX extensions and not send it to Beronet, if I have to tell it the Cisco ranges it will be more complicated and I don't know if different filters can be added in the same rule.

Thank you.

 

[leejor]

The correct way to handle this is to configure the Cisco to terminate (recording?), and not route invalid numbers back to 3CX.

You might also consider requiring a prefix digit, when dialing Cisco numbers on on 3CX, to lessen the chance that the outbound rule routes a disused local extension. In other words, from 3Cx, Cisco numbers are now 5 digits long. Just strip the leading digit before sending. It won't eliminate the problem, but should cut down on the chance of it happening.

 

[YiannisH_3CX]

For me how you mitigate the issue depends on how you are using the bridge, how may extensions are on each side and the capabilities for the Cisco on the other side. I am sure there are a few solutions to your issue but you have to find the optimal for your use case.