Redirection between two Extensions ends the incoming Calls to nowhere

[Cryjack]

Hi there,

the following occurs between two Users:

- User A sets an internal redirection to User B
- User B sets an internal redirection to User A
- Neither User A nor User B knows about the redirection to each other

Now all external calls to User A and User B are ending in a "Number not known"-Message directly from the Provider. Nobody can see that there is a problem except the caller itself. How can we prevent the users from doing something like this? Can the call be forwarded to a system extension in case something like this happens?

Thanks in advance.

 

[JohnS_3CX]

Hi Cryjack

Firstly read this and provide details
https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

Additional:
How was the redirection set (exact details) and what was the state and status of both extensions when this happened?

 

[Cryjack]

Hi John,

thank you for your quick reply. Here are the needed details about our install:

• 3CX Version, Professional Annual 24SC, 16.0.622
• Server OS, 3CX Linux based
• Is the 3CX Server Hosted and where?, On Premise
• IP Phone Make/Model/Firmware, Snom D385 Deskphones, Snom M70 DECT
• Provisioning Method: Local
• Trunk Provider or Gateway Make/Model, SIP Trunk via Ecotel
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

Additional:
- The redirection was set via 3CX Webclient for both Users.
- User A was set to "Out of Office 2" with internal and external calls redirected to User B because of Vacation/Holiday
- User B was set to "Away" with internal and external calls redirected to User A because of daily workhours.

 

[JohnS_3CX]

Understood. This cannot be directly prevented and can technically be considered a valid scenario

1. Call arrives on trunk
2. Calls is routed to user A
3. User A says sorry not available, please go to user B
4. User B says sorry not available, please go to user A
5. At this point a loop is detected and both destinations are effectively not available
6. The PBX replies to the provider that the user was not found (SIP/2.0 404 Not Found)
7. The provider will play a custom message depending in how their system is set up (in this case "number not known"

I think this is one of those things that the users should be aware of: if you are both away the call will go nowhere.

One way around it, depending on your use-case of course, could be to have a ring group with these two people so that when they are both unavailable you will have a Destination If No Answer going to an IVR or a receptionist.

 

[Cryjack]

Yes, this seems to be the problem we discovered.
It is a bit hard to make the user understand to be aware of this. Can this technically be permitted in such a case?

We're going to use some new ring groups for this now. This seems to be the best parcatice till now.


Thank you for your quick help.

 

[JohnS_3CX]

Yep, technically it is valid because 2 users may take breaks for example where only 1 person is out and the other can take their calls. So you cannot prevent them from doing it, but you can inform them of the consequences and use a work around like the ring group to be sure

 

[leejor]

Remind employees that is a good habit to ring the destination that you plan on forwarding your calls, informing them you are doing so, before implementing. That step, would make the originator aware that the forwarded call will not go where they expect it to.

 

[Cryjack]

Remind employees that is a good habit to ring the destination that you plan on forwarding your calls, informing them you are doing so, before implementing. That step, would make the originator aware that the forwarded call will not go where they expect it to.

Thank you for your reply Leejor. This is indeed a nice approach, but not usable in this case. User B just sets it's status to 'away' where then the configured redirection takes place. So making a call to test the redirection for every change in status shouldn't really be the way to go with 3CX.

It may be interesting if 3CX could check the redirection before applying the change and give some feedback then. Maybe a simple future-feature?

 

[JohnS_3CX]

Not really possible, as the like you said it may work initially and then the other person will set their status to away, "breaking" the forwards which where valid a moment ago

 

[Cryjack]

Not really possible, as the like you said it may work initially and then the other person will set their status to away, "breaking" the forwards which where valid a moment ago

Wouldn't it be possible to check the redirections on every status and/or configuration change? Maybe with a message directly to the user or admin? For now nobody is informed about 'problems' with internal redirects and the calls are lost. That is the worst case that could happen in my opinion.
The main problem is the 'not knowing about this', because there is no way to check. So this could happen every user, every day without knowing something may be wrong.

 

[leejor]

User B just sets it's status to 'away' where then the configured redirection takes place.

If people are "re--using" the same destination, simply setting to Away, then they should be aware of the fact that the other (destination) extension sets their "away" back to them, possibly causing the loop, if both are activated.

As suggested earlier, making the extensions a member of a ring group, will cause any call to that ring group to ignore that extensions forwarding "rules".

 

[Cryjack]

@leejor
I totally agree with you and completely understand the problem and the suggested solution.

But I can't rely on the user's awareness (to be true, the most of them don't understand what happens there and why). The user sets it's status and should be fine with it until a warning appears, telling that there is a problem. Beeing able to set wrong/inconsistent parameters that leads into mayor problems with incoming calls can't rely on the users awareness in my opinion.

Again, I totally understand the problem and agree with you both. For now I'm going to use ring groups for this issue, but maybe there is a way in further versions to avoid something like this on user-side.