Issue (Feature:) with 'Expanding' call groups

[telis]

Hi 3CXers,

I have an issue with call groups. I am running 3CX 3.0.2328.0 on a test server. I have 2 extensions, 201 and 202 and two hunt groups 800 and 801. 800 has only 201 as a member and is set as ring all, ring time 8 seconds, destination if no answer is set to 801. 801 has 201 and 202 as members and is also set on ring all, ring time 30 seconds, destination on no answer continue ringing. I also have one SIP line set to call 800.

The trouble is that when the call leaves the first hunt group 800 and enters the second 801 the call alerting to 201 is momentarily stopped. This behaviour results in a missed call appearing on the handsets call history, when, as far as the user is concerned, no call was missed. It also leaves open the possibility that someone could pick up the handset in the brief interval between the call stopping ringing and starting ringing again, and therefore not be connected to the incoming call. Although after some attempts I have been unable to get this to happen.

It also does exactly the same with Queues instead of Hunt groups.

Actually we used to have this issue with the Avaya IP Office until the behaviour was changed in a firmware update years ago. It's quite a common scenario in a small office; you want the calls to go the junior people first, but if they are not able to take them you want them to go to the less junior people, whilst continuing to alert on the junior people’s handsets in case they get back to their desks.

Can anyone reproduce this? It would be better if the hunt group or queue looked ahead to the hunt group or queue it was going to overflow to and did not stop alerting any stations that were in the second group or queue.

Chris.

 

[telis]

We used to be a 3CX partner and think I may have been the first person from the UK to be certified as a 3CX professional after visiting a course in Malta. Before that we sold IP Office telephone systems.

Well we have been using SNOMone with Snom handsets since snom bought it, due to the fact that they, like the IP Office, support expanding hunt groups as described above, but since the news that they have been sold and Snom are getting back into bed with 3CX I have installed a demo of 3CX.

However disappointingly it still does support expanding hunt groups unlike the SNOMone. IP handsets support SIP re-invites, including of course the Snoms - http://wiki.snom.com/Settings/sip_cancel_reasons_to_ignore_missed_call - text='Call was replaced' - which means no missed call messages and interruptions in alerting if more extensions are in the second stage of a hunt group by a SIP re-invite.

 

[leejor]

It would be better if the hunt group or queue looked ahead to the hunt group or queue it was going to overflow to and did not stop alerting any stations that were in the second group or queue.

Agree....but, it may not be as easy to implement as that, and, it may not be required by enough users to warrant the change. You might want to submit a feature request though.

The only drawback with having one ring group pass on to a second (beside including the same extensions in both) is the amount of time the caller is possibly going to have to listen to ring-back tone before someone finally answers. Many people will give up after six or seven rings thinking the call did not go through properly.

 

[markshehan]

Hi 3CXers,

I have an issue with call groups. I am running 3CX 3.0.2328.0 on a test server. I have 2 extensions, 201 and 202 and two hunt groups 800 and 801. 800 has only 201 as a member and is set as ring all, ring time 8 seconds, destination if no answer is set to 801. 801 has 201 and 202 as members and is also set on ring all, ring time 30 seconds, destination on no answer continue ringing. I also have one SIP line set to call 800.

The trouble is that when the call leaves the first hunt group 800 and enters the second 801 the call alerting to 201 is momentarily stopped. This behaviour results in a missed call appearing on the handsets call history, when, as far as the user is concerned, no call was missed. It also leaves open the possibility that someone could pick up the handset in the brief interval between the call stopping ringing and starting ringing again, and therefore not be connected to the incoming call. Although after some attempts I have been unable to get this to happen.

It also does exactly the same with Queues instead of Hunt groups.

Actually we used to have this issue with the Avaya IP Office until the behaviour was changed in a firmware update years ago. It's quite a common scenario in a small office; you want the calls to go the junior people first, but if they are not able to take them you want them to go to the less junior people, whilst continuing to alert on the junior people’s handsets in case they get back to their desks.

Can anyone reproduce this? It would be better if the hunt group or queue looked ahead to the hunt group or queue it was going to overflow to and did not stop alerting any stations that were in the second group or queue.

Chris.

I believe the missed call problem you describe may be fixed in the next Service Pack - I know they discussed it.

However that might not be fixed on the phones themselves.

The way it works is that when you call the group it sends an invite to each phone. When the time is up it sends a cancel. Then the next group gets their invites. So the person genuinely did miss a call on their phone.

I can see how your solution may work but it sort of goes against the principles of SIP and the RFC. The PBX does not know about look ahead. The invites are sent, a timer starts, if the call connects then great if not then the timer fires, cancels are set and THEN it looks up the "what next" and sends more invites. It would slow everything down if it had to load everything (for example your 801 went to 802, what if that went to 803 that went to 804, that went to 805 etc getting bigger each time). Where do you stop the advance lookup on say a 256 call system? Just to stop a missed call on a phone, when they missed the call.

 

[telis]

Many people will give up after six or seven rings thinking the call did not go through properly.

The idea of more calls being included in the hunt group is precisely so the caller does not have to wait too long to get an answer whilst still giving the people most qualified to answer the call the first opportunity to answer it.

I believe the missed call problem you describe may be fixed in the next Service Pack - I know they discussed it.

However that might not be fixed on the phones themselves.

The way it works is that when you call the group it sends an invite to each phone. When the time is up it sends a cancel. Then the next group gets their invites. So the person genuinely did miss a call on their phone.

I think it's basically a quality issue. This is the way a lay person would expect it to work. And it's the way it worked in pre-IP telephone systems.

It would be extremely gratifying if this were in the Service Pack

It's a very, very typical Small Business set up, in fact possibly the most typical small business phone set up there is. A sales call (say from the auto attendant) should first go to the two sales people, but if they don't quickly pick up it should go all at once to the members of other departments to make sure it gets answered in good time whilst continuing to ring on the sales peoples handsets.

Also it's not just a missed call on the handset. In my experience these calls make up many of the missed calls on the handset, thus effectively breaking the missed called feature. Also the re-alerting itself is just poor fit and finish and poor user experience. It elicts the response, "why is it doing that?"

The way it works is that when you call the group it sends an invite to each phone. When the time is up it sends a cancel. Then the next group gets their invites. So the person genuinely did miss a call on their phone.

I can see how your solution may work but it sort of goes against the principles of SIP and the RFC. The PBX does not know about look ahead. The invites are sent, a timer starts, if the call connects then great if not then the timer fires, cancels are set and THEN it looks up the "what next" and sends more invites. It would slow everything down if it had to load everything (for example your 801 went to 802, what if that went to 803 that went to 804, that went to 805 etc getting bigger each time). Where do you stop the advance lookup on say a 256 call system? Just to stop a missed call on a phone, when they missed the call.

As far as a call being genuinely missed I don't think this is the case as far as the layman would see it, and they are the people using the phones. How have they missed the call if the person dialling is still hearing the ringing tone? There is only one call right? How can they have missed the call if the call is still alerting on other handsets including their own handset? If they pick up the call in the second alerting they have still missed the call? I know this is just semantics, but I think it's the more natural way of thinking about it.

I'm no expert but I don't see this in anyway as going against the RFCs. The RFCs don't define this behaviour one way or the other, or do they?

I can see two ways of doing this, explicitly or implicitly.

First option, explicitly.

The SNOMone has a second and indeed third "layer" in the huntgroup itself, this provides the limits you say are missing. It also simplifies the presentation and the implementation of the feature. It does change the interface however, which is a shame since it move things around for users who are used to where the are and may not see any benefit. One way of doing this would be to have a "Ring All with Overflow" which then displays the extra options. I have done a mockup of this attached.



Second option, implicitly.

No managment UI changes it just works as it is. In your example when the timer fires the system looks at the table of extensions that are alerting for that call then looks at the forwaded group's extension list and for any in both lists it does not send a cancel, and for those in the second group only it sends an invite as normal. It could alternatiovely send a re-invite to the already alerting extensions to change the huntgroup name as it appears on the handsets.

 

[markshehan]

I havent tried using Ring Groups with v11 sp2 as we use Queues rather than ring groups.

I know with a ring group that the phone does not show a missed call.