Ring Group Prioritized Hunt Strategy GW Problem

[zafeirop]

Hi,

I realized that the Ring Group Prioritized Hunt Strategy is not working well with some of my clients Gateways.

The problem is that there are some customers who want to forward calls, through their Ring Groups to external numbers, in Hunt Strategy.

In Hunt Strategy, the numbers are called the one after the other. If the first number does not answer, the call will be routed to the next sequential number in queue.

On 3CX side, call switch between the hunt numbers (after the Ring Time has passed with no answer) takes place so fast that GW is not able to close the previous channel and proceed with the next call. So a busy error is transmitted or 503 Service Unavailable.
This is the case for many PSTN GWs that are able to route only 1 simultaneous outgoing channel.

There must be a delay, of about .5 or 1sec for some GWs in order to allow some time to settle down the previously active channels and return to idle mode for the next call.

Is there a delay setting hard coded or through a 3CX setting that I am not aware ?
Why 3CX does not fallbackup to backup routes for the particular external numbers that are dialed ?

Thanks
TZ

 

[lneblett]

Would not the issue be with the gateway not releasing the line soon enough to make it available, or is it not really havng enough GW (trunk) availability to satisfy the demand? Inserting a delay, no matter the length, still requires that an outgoing trunk be available when the time comes for a need. Maybe I am missing the point, but on the surface I am not able to glean how a .5 or 1 sec delay will ensure the availability of a line. To me, the delay would simply be a hit or miss prospect that is still dependent on the timing of when a call is physically disconnected, the diconnect is recognized by the GW and it goes back on-hook (idle), and when a need arises to place an outbound call be it through a ring group or other demand. The two actions (disconnect of a call in order to make a call) seem independent of one another and while perhaps some calls might get lucky enough to get through, others still won't. Can you advise which make and model of GW? Also, I am a little confused with the phrase of "1 simultaneous outgoing channel". If 1, then simulatenous to what?

Now then as to the questlon about if the GW is unable to process the call, why does it not use the other routes.....can you advise as to how the outbound rules are established?

 

[zafeirop]

lnblett you are right!
That was a wrong expression, using the term "1 simultaneous call" :roll:.
I meant a degenerated case of a Gateway with a single line.

But, I am sure that you aggree that in single line scenario GWs, 3CX needs a delay timer!

Real case scenario:
Let's say that a call reaches a Ring Group which forwards calls to external numbers with Prioritized Hunt Strategy.
3CX calls number1.
GW forwards call to PSTN.
Ring Time out has come.
3CX closes SIP channel to GW.
GW tries to close channel to PSTN.
3CX opens new SIP channel to call next hunt number2.
GW is not fast enough to release the previous channel, and responds with Busy or 503.
3CX exits with relevant error.

In this scenario, 3CX fails, overall!
No backup routes are used!

BTW: A GSM that behaves like this is GSM Portech MV372

 

[lneblett]

OK, now I understand the scenario. Thanks. Interesting to say the least.

In essence, the ring group is actually external to 3CX as the "real" extensions are on the other side of the GW. The GW is providing SIP signaling back to 3CX such that the intent is that if there is no answer, it goes to the next "real" extension.

In this particular scenario, I can see how a delay might be helpful. However, to be fair, it is somewhat of a chicken and egg kind of question- Is the GW too slow or is 3CX too fast? Is .5 or 1 second enough time to satisfy all timing issues that might be ecountered or might there be other time delays needed?

My take is that if the GW indicates that it is busy, then it is busy and I don't know that 3CX or any other system will know that the reason it is busy is because one call just completed and the line has yet to fully recover. I am guessing that your creative solution and how you have implemented the GW is not how most other Portechs are employed. As a gateway yes, but as an active part of a psuedo ring group....likely not. Again, I profess not to know if the other channel is what took the originating inbound call that triggered the ring group being activated and/or if there is other activity that may make use of the Portech but I assume it possible that any number of scenarios might make use of both channels simulataneously thereby making the delay inconsequential

Don't get me wrong, the delay sounds good in this case, and probably causes little harm as the time is rather short, but not knowing how else the device may be employed makes me wonder if the delay will be a 5%, 20%, or even a near 100% solution.

I don't really consider this a failure of 3CX or even of the Portech, but rather a unique need where a delay might be one solution but there is also the solution where Portech makes other GWs that have additional capacity. I know, I know, the added cost to that which you already have, but it is there and available. You can always submit a feature request to allow for the delay.

I think the real question is about the routing that does not occur when the Portech can't be used.

 

[craigreilly]

Also, is there ever an opportunity, during that delay, that someone or something else might also take that Dialtone?

 

[zafeirop]

Also, is there ever an opportunity, during that delay, that someone or something else might also take that Dialtone?

Hi Craig, all,
In Single line Gateways, the overall traffic is relatively low, so the chance for someone else to pick up the free channel, instead of the 3CX System, is really low.
I would like to have that "delay" feature, even if it is oriented for small capacity systems.

To lneblett:
I'm glad that you understood my scenario and that you have an expert's point of view in this discussion.
I know really well that when we oversize an installation plan and we add bigger systems with greater capacities, many problems are solved, but there will always be a point in time where the system will operate near its maximum line capacity (business growth, more extensions added etc.).

And in our case (Hunt Strategy), the last line will always being dropped due to inefficient or unsynchronized communication between the PBX and the GW.
So, the system will have a capacity o N-1 lines while the customer paid for N.

If you combine this problem with the routing issues that I faced and the routing logic for outgoing calls through Ring Groups, then 3CX has to be changed a lot to conform to most market standards.

 

[lneblett]

Well, I respectfully disagree about the customer paying for n and getting n-1. Only because the timing is at issue does it make it seem like n-1 is true, but if the call is indeed answered on the first extension, then he really did get n. if two independent calls are routed to the GW outside of the ring group, he still gets n. only in the event that the call goes unanswered and the line has yet to settle does the issue arise. And yes, as you grow, capacity will be an issue, but still the option always exists to add capacity to meet demand.

So, while I may not share your perspective on the n issue, I do share it as to why the other routings do not come into play.

Because your scenario is unique to most (some) of us, what happens in the event that the first number dialed out is busy rather than simply not answered? Just curious. This is really an unusual set-up to me (being in the USA) and hope to learn more about it.

Your perspective of how it should work, is there another system that you know of that does handle it in the manner you expect? I use PSTN gateways and they too have a delay between when the physical disconnect occurs and the line is available for re-use. I can tell you in this case that it takes more than a couple of seconds, but this may not be representative of how GSM is.

 

[leejor]

Is the gateway set-up as one trunk group, with N simultaneous calls available, or as individual trunks? If it is the previous, then I should think that the gateway, receiving the second call, should be able to (realizing that it is not quite finished with the first call line) send that call out on a second trunk. If there is only one trunk on the gateway, then it may be that, given that the majority of business users will probably have access to multiple trunks, this sort of issue was never considered by the designers.
It would be very interesting to know if other makes/brands of gateways are able to deal successfully with this scenario.
It may be a question to raise with the manufacturer. Perhaps you've discovered a bug that warrants an update in the next firmware release?