Queues keep dialing busy numbers

[Uffe]

Funny thing...

I have set up a standard queue in 3CX 11 with ring-all. I have a few normal extensions as well as 1-2 external ones. The external ones are mobile phones. This gives me two troubles:

1) When the user of the mobile phone press "reject" then 3CX immidiatly call again. It is impossible for the mobile user to have some peace, short of turning the phone off or putting it in flightmode.

2) Very often, infact in most of the cases where the mobile user accept the call, then 3CX hangs up and redials back to the mobile phone. In the SIP trace it is clear that 3CX sends a BYE.

As you can see there is no escape for the mobile user, he cannot accept and he cannot reject...

Case 1) Might be working as intended, 3CX has no other whay to detect if an external extention is busy except for trying to dial it. Is there any workaround to get 3CX to only try external extensions once?

In case 2) there is probably som error, I get this mostly when I have 2 external extensions in the queue.

Any ideas?

/Uffe

 

[lneblett]

I am not certain why you would have mobile phones in a queue, but if in a queue and logged in as available and it does ring their mobile why is reject an allowed response? Why do they not answer? If they don't want it to ring, why do they not log out of the queue? You have essentially told 3CX that they are a part of the queue and to dial their number. As you indicated, 3 CX has no way to determine the phone's actual status without actually dialing the number and finding out. If they reject and then one of the local agents subsequently picks up the call, does 3CX then quit ringing and dialing the ring group?

You did not mention what the allowed ring time is or what happens to a call in the event the time elapses and there is no answer.

Mobile phones and their carriers typically have more latency than their landline based cousins and certainly more than what phones connected to the 3CX system have. In other words, say you have a timeout of 20 seconds. When the the call goes into the queue (ring all) the timer begins counting immediately which means that the local phones start ringing before the dial to the mobile has even begun. I am wondering if it is at all possible that by the time your mobile users can get to their phones and answer the call if the timeout has elapsed subsequently causing the 3CX system to move on to the if no answer routine (sends BYE, which might appear to be mid-stream to the mobile user, but not to 3CX). If the no answer routine involves your mobile, that could be a reason for the apparent call-back.

I am only guessing at the last part.

 

[Uffe]

Well, we can leave the discussion about why to have mobile phones in a queue. But lets just say that in Sweden we are moving towards a situation when the last landline to be disconnected is not far away. 3CX needs to work alot on mobile phone integration and mobile extensions to succeed here.

I have need for 3CX to try an external extension more than once, so if there is a workaround to achieve that, I would be grateful for any tips.

Regarding 2) I have tried both short and long dial time. The thing is that 3CX doesnt hang up until you answer. It does not matter if you let it ring once or 10 singals, it still hangs up immidiatly upon answer in about 2/3 of the time. So i don't think it is related to ring time.

Regards

Uffe

 

[Uffe]

Sorry, I missed the operative word in the middle paragraph...

I have _NO_ need for 3CX to try an external extension more than once, so if there is a workaround to achieve that, I would be grateful for any tips

/Uffe

 

[leejor]

You fail to mention the method that you are using to place the calls to the mobile(s). VoIP, ISDN Gateway, PSTN Gateway...or if it is clear that correct answer supervision is being passed back to 3CX.

In theory, a mobile, as a part of a queue should behave no differently than a local extension as long as 3CX has the correct status of the phone, and of course, it has no way of knowing if the phone is in use unless it attempts a call. Even then, if there is not correct answer supervision, things can go wrong.

I have set up a standard queue in 3CX 11 with ring-all.

You don't mean a ring group do you?

When the user of the mobile phone press "reject" then 3CX immediately call again.

Does this user have voicemail, on the mobile? Are they rejecting the call and the status does not change, in 3CX's view since there was no answer supervision sent?

It is impossible for the mobile user to have some peace, short of turning the phone off or putting it in flightmode.

That is going to be the case, isn't it? There is no provision for a "do not disturb" option on a mobile. You'd have to change the forwarding option at 3CX if the user no longer wished to receive a call. Or change the ringtone on the mobile to silence based on the incoming caller ID from the 3CX end.

The reason queues work well on local sets is because the PBX is aware of the agents status because of SIP messages passed from the set to the PBX.

 

[leejor]

But lets just say that in Sweden we are moving towards a situation when the last landline to be disconnected is not far away. 3CX needs to work alot on mobile phone integration and mobile extensions to succeed here.

That may well be for individual . residential users, but for the majority of businesses, especially those that have agents and queues they will still be making use of some sort of wired desk phone/headset/softphone, in the office. Most (no, not all) members of a queue are required to be in front of a computer.

 

[leejor]

Unfortunately we are still unable to EDIT a previous post...

The issue you are having, with the use of the "reject" button on the mobile might be because, as far as 3CX is concerned (and this all relies on supervision being passed correctly), the call was ringing, and then the trunk into 3CX was disconnected. Because the call was never answered, no supervision, as far as 3CX knows, it was still ringing when the trunk disconnected. The reject told the mobile provider to drop the call, which in turn was passed to your provider, of the trunks into 3CX, and that was then dropped.