Solved V18 - Non used DID is automatically forwarded toward main trunk instead of END CALL

[saint__]

Greetings all,

I have a customer with 100's of DID.
I noticed that if a DID is free to use and not assigned to an extension or queue or call flow app, if someone calls it, it goes to wherever the main trunk number is assigned to go to.
Customer does not want that and want all unused DID to ring busy. Therefore, we had to create incoming rules for all unused DID and set them up to END CALL.

By doing this, when we create a new user and want to assign a DID, we don't see the list of free DID obviously (because they are now assigned to incoming calls / END CALL).
Is there an option in 3CX which would allow us NOT to create the DIDs in the Incoming rule and point them to END CALL but rather let them free and automatically END CALL when not used?

Thank you

 

[leejor]

The trunk will have a default route, where all calls go, that don't match a DID number rule. You could set that route to end the call if this will not cause other issues. Otherwise, you'd have to create a DID rule for all unused DID numbers.

You might also see if your provider can deal with unused DID numbers, and not send them to your PBX until needed, by still reserving them for you, but routing to a not in service recording.

 

[saint__]

Our default route goes to a Call Flow App.
Are you saying that the work around is to setup default route to END CALLS then create an incoming rule for the trunk main number? We already created rules for un-used numbers, but as I wrote in my first post: By doing so, it removes the numbers from available DID, therefore they can't be used during user creation. We need to create the user first, then go in incoming rules and apply one of the DID to the user, which adds extra steps.

Asking the carrier to deal with unused DID is not happening with this customer. They have a high turn around, and DID are changed on a weekly basis. Things need to be done fast, and from the PBX side.

 

[leejor]

Are you saying that the work around is to setup default route to END CALLS then create an incoming rule for the trunk main number?

Unless the "main" number is sending a DID number to route on, then no, this won't work for you. You have the default route, and the DID routes. It is probably assumed that any DID numbers being sent to to PBX are going to be wanted calls. Someone else may offer another option, but I suspect you will have to deal with all DID numbers being sent by creating a rule for each..

 

[saint__]

Unless the "main" number is sending a DID number to route on, then no, this won't work for you. You have the default route, and the DID routes. It is probably assumed that any DID numbers being sent to to PBX are going to be wanted calls. Someone else may offer another option, but I suspect you will have to deal with all DID numbers being sent by creating a rule for each..

Gotcha. It shouldn't work like that. If a DID is not used, it should ring busy. All other systems do that, and every customer expect this. If we want a unused DID to be routed to the main number, then it's something which needs to be done manually. But anything else not used should be a END CALL by default. Just my 2 cents from working on Alcatel-Lucent, Cisco, Asterisk, and other systems.

 

[cobaltit]

I'm not sure I agree with the 'it shouldn't work like that'. Innovation would never happen if we kept doing the same thing in the same way over and over.

If everything not used should be routed to END CALL by default, then set the trunk to route to END CALL by default on the trunk and you have it the way apparently everything else works. If the default setting on the trunk when creating it was set to that, then you'd have thousands of complaints by new users who've never configured a PBX before. For many, this is their first foray into using a PBX the default settings are more 'friendly'.

 

[leejor]

I guess 3CX looks at as...if a call is incoming, and I have no rule that matches, then it goes to the default route. Other systems may not make use of a default, so if it does not know where to send the call, it ends it, or returns busy tone. Not all systems work the same way. An alternative could be posted in the Ideas section.

I also have to assume that if someone has reserved, and is paying for hundreds of active DID numbers, then they have plans to make use of the majority, in quick order, leaving only a few, spares, that would need to terminate at a recording, or alternative. I can't recall the issue, you are having, being brought up, before.

 

[saint__]

@cobaltit
I tried that, and it does not work.
Went to the SIP Trunk, and changed the ROUTE CALLS TO End Call / End Call
Then Incoming rule for the main number to my CallFlowApp and Afterhours. <- This changed the default behavior in the trunk, which then changes the default behavior for non used numbers.

Where it does not make sense for a end user is that if I don't have a setup for a particular DID it should ring busy. The fact that it does not forces me to create an incoming rule for all unused DID, which then prevent me to use them directly in the "INCOMING DID" under USER, when I create a new user. Just my two cents.

 

[cobaltit]

Are you using a supported SIP trunk provider? Because having the default route to end call, and your main number with an incoming rule, should cause 3CX to drop any calls that are listed as DIDs while leaving them available to assign as you want. No rules should need to be created for those DIDs to drop them.

 

[saint__]

Yes, using Flowroute.

 

[cobaltit]

Hmm.. just to clarify.

So with the trunk default route set to end call. If you have a DID configured in the trunk, but no inbound rule configured, then the call follows the main number still?

 

[saint__]

This customer has 100 DIDs. Let's call them xxx.yyy.0000-0099

Under the trunk configuration, it is a requirement to give a Main Trunk Number.
There, I use xxx.yyy.0000, and I set it up for test purpose to END CALL / END CALL

From there, I go to Incoming rule, I pick did xxx.yyy.0000 and I set daytime to a Call Flow App, and night time to a VM.

When I go back to the trunk, the Main Trunk No now changed to replicate whatever I did in the Incoming Rules.

Now, if I call xxx.yyy.0099 for example, it is going to follow the main trunk rule, even through there is no incoming rule setup for this number. So I need to go into the incoming rules, and create a END CALL for xxx.yyy.0099 so if someone calls it, it rings busy/unavailable.

By doing this though, if I create a new user and need to assign a free DID, the 0099 will not show up because it's used in incoming rules already. So I need to create the user first, then go to incoming rules and re-assign 0099 to the new user.

 

[cobaltit]

Ahh ok. Sorry not that familiar with Flowroute setup since do our own trunks but what you describe is the expected behavior in this case.

While 3CX requires something in the main number configuration, we don't use that for anything so it can be anything you want for our trunks.

- If Flowroute doesn't care you can change the main number something bogus and then add the main number as a DID (in 3CX). It doesn't even have to be a number, could say (DONOTUSE)
- If they do care have Flowroute change your main number to a DID you can sacrifice or get a DID from a different area code or state to use for this purpose and change it.

You might also be able to switch to IP authentication if that would eliminate any dependency on the main number field

 

[saint__]

We are using IP Authentication. But it looks like it still require 4 characters min for the main trunk.
I'll try some alpha numerical entry and will update this thread to see if it works. Thanks!

 

[saint__]

Doing so have the same behavior, where now I see "ABCD" as a free inbound rule, while it should not be.
Oh well... I feel it's a bug since it's used, it should not be free. If 3CX wants to fix it, fine. if not, we'll work around.

 

[cobaltit]

Ultimately the main number is just a DID so yes, it will show up as routable but I'm not sure why you care since your complaint was that DIDs on the trunk not assigned a rule END CALL were following the default trunk route. By setting the default trunk route to END CALL you now no longer have to do that leaving the available DIDs free to assign to extensions as needed. This behavior is no different than something like a firewall where you have a default rule like 'Deny all' and then you have to add specific rules to allow. In your original scenario the default rule was 'Allow all to my CFD' which required specifically adding Deny rules to your DIDs. You've change that now.

 

[saint__]

On an ISDN world, when you do an incoming translation from carrier DID into your numbering plan, if a number is not used, it is not routed to a generic place. The PBX sends back an ISDN UNAVAILABLE message, which basically rings busy on the caller's end.

If I take another SIP based server like Asterisk, a non setup number will return a 404 NOT FOUND usually.

All I'm saying is that if 99 of my DIDs are programmed under the trunk to be known, but not setup in the incoming call routing, they should not follow the main trunk DID rules. When I run a TCPDUMP, I see the incoming SIP SDP calling for a non setup number, and still 3cx takes it to the main trunk rule.

If not rule is setup, then nothing should be happening to this incoming call (beside a SIP 404)

To take your firewall example this would be the same thing as having multiple IP given to you by the carrier.
You setup 1 IP in your firewall with rules. If you receive a request on another IP which is not known, the firewall drops it.

On this note, happy new year to all!

 

[NickD_3CX]

Happy New Year!

I will flag this as "resolved" as I feel an explanation has been given.

The recap, the "Main Trunk Number" is a DID, so you can create an Inbound Rule for it, and any changes to this Inbound Rules are reflected in the Trunk Settings.
The "Main Trunk Number" though also doubles as a "catch all" rule for any DIDs being called but have not specific Inbound Rules.

It is not a bug, it is the intended behavior. I think though you have been provided with a way to work around it.