Skip to main content

Agent and call to mobile phone number

Posted by RJansen on Tue, 01/30/2018

For after hours support we would like:
1: dynamically login as an agent (already possible)
2: associate a mobile phone number to that agent

So when a support call comes in it checks to queue for a agent and then calls the mobile phone number associated with that specific agent.

Is this already possible somehow or is this something that could be implemented in a future release?


Submitted by volodya on Tue, 01/30/2018 Permalink

Hello,

Do you want to have more than one agent in the queue while at least one of them will have external phone number?

Submitted by RJansen on Wed, 01/31/2018 Permalink

Ideally we would like to have lets'say 10 agents with all ten of them a seperate external phone number.
So if 2 agents are logged into the after hours support queue because its there turn for after hours support 2 mobile phone numbers are being called when a support request (call) enters the queu.

In reply to by volodya

Submitted by netriplex on Wed, 01/31/2018 Permalink

Rjansen,

Consider having your agents using thirdlane connect and/or a separate softphone client to connect to the PBX from their cell phone.

Asterisk does not support cell phone numbers in queues, because queues operate based on "state" information of the extension/agent. Since a cell phone (as a cell phone number) is not connected to the PBX to monitor the state of the user, cell phones do not function within the queue model as agents.

Normally, when a call comes into a queue, there is a queue strategy, such as ring all. In the case of external devices (not registered to the PBX in some way), the Asterisk has no way of knowing when ringing all if the caller got that "agents" Voicemail or if the agent actually answered, etc. As a real world example, a call comes in and both of your agents cell phones ring, one of your agents hit ignore and the call goes to the agents cell phone voicemail, the asterisk system has no way to know that the call was "answered" by a voicemail, so now your caller ends up in your agents cell phone voicemail instead of still hearing ringing for your "backup" agent. Similarly, if both agents are already on the phone, the caller will end up in one of your agents voicemail, instead of hearing hold music waiting in the queue.

Things get even more tricky when/if you have other queue strategies to think about. This is why asterisk does not support this for queues and most likely never will.

Submitted by RJansen on Fri, 02/02/2018 Permalink

Thanks for the explanation.
The thirdlane connect app only receives external calls when the app is active. It doesn't work when the phone is locked or in the background. This only applies when the connect app extension is part of a huntlist or queue.
When i setup a inbound route direcly to the connect app extension it works also when the phone is locked or the app is in the background.
So thats why i would like to send the call to a mobile phone number directly.

Submitted by RJansen on Fri, 02/02/2018 Permalink

Thanks for the explanation.
The thirdlane connect app only receives external calls when the app is active. It doesn't work when the phone is locked or in the background. This only applies when the connect app extension is part of a huntlist or queue.
When i setup a inbound route direcly to the connect app extension it works also when the phone is locked or the app is in the background.
So thats why i would like to send the call to a mobile phone number directly.

Submitted by netriplex on Sun, 02/04/2018 Permalink

I agree the connect has its shortcomings and there are many more than just that.

Have you tried to just create a separate extension for the mobile agents to use from SIP softphone instead of TL Connect and see how they operate in the background?

Submitted by thirdlane on Sun, 02/04/2018 Permalink

It is quite possible that we could determine that an agent is being contacted by the queue and send notification to connect. Let me discuss this with the team.

Submitted by netriplex on Mon, 02/05/2018 Permalink

The same enhancement for hunt lists would be nice as well. Most of our users extensions are "dialed" via a hunt list.

Submitted by eeman on Wed, 02/07/2018 Permalink

if your agent is working remotely then he/she should not be using their mobile phone to work in a queue. this would solve your "he thirdlane connect app only receives external calls when the app is active. It doesn't work when the phone is locked or in the background" issue. Use the PC client, not the mobile app. What good is it to answer a queue call if you cant actually do any work to help the caller?

Submitted by netriplex on Mon, 03/26/2018 Permalink

Any update on push notifications for an extensions when they are contacted via hunt lists and queues?

Submitted by netriplex on Wed, 05/02/2018 Permalink

Any update on this? Essentially all of our customers have abandoned Thirdlane Connect and are using the Bria mobile SIP phone app because they find the Thirdlane Connect app useless since it won't ring calls that are sent to their extension in any manner other than when their extension is directly dialed. Since Bria runs in the background and receives ALL calls to an extension, it has been the workaround.

However, this is much more difficult to manage and is more expensive as we essentially have to "eat" an extension license to setup a second extension for the Bria client and then configure multi extension contexts on all of their extensions along with setting up extra extensions in their huntlists and queues.

Submitted by netriplex on Sat, 08/25/2018 Permalink

Rjansen,

I have gone over this request with Alex numerous times for a year now to the point with arguing with him over how useless Connect is when users cannot be reached when their extension is rung as a part of a hunt group (nevermind a queue). He doesn't care really, never has. I have wasted a ton of effort over the years in trying to help him deliver features in Thirdlane people would really care about and they all go ignored. I have starting migrating customers to 3CX where this is supported in their mobile app.

Submitted by eugene.voityuk on Sun, 08/26/2018 Permalink

I just wanted to bring some clarity and put this issue to rest. We do care, in fact, this and related issues have been raised on our internal engineering meetings long before this topic was started. More than that, the root cause of this issue has triggered a major redesign of Thirdlane platform, now over a year in development, targeted to be released this year. The true issue behind this is more global than it may appear. Hunt list currently has only device based endpoints, but previously also had Extensions Based endpoints. For the Connect to be woken up and dialed, it has to be dialed via user extension script, which includes all the logic required to dial extensions, check call forwarding, set recordings and paths, etc. Short of patching Asterisk, this is the only way to check whether it is possible to wake up device associated with the dialed extension. Queues and Hunt lists are device based, and they don't execute extension script, they can simply send INVITE to a device specified in hunt list config, or device that is added as a member into the queue. The only possible way to change this in current condition is to use Local Channels (https://wiki.asterisk.org/wiki/display/AST/Local+Channel) as members in the queue, or as destinations in hunt lists, but our experience with Local channels showed, that they are unusably buggy, and commonly cause "Dead Locks" in Asterisk. So we removed Extension Based hunt lists, as they were backed by Local channels, we don't recommend to try to use queue members as Local channels, and I will warn you not to listen to anyone who will tell you the opposite. This issue will be resolved as a side effect in the next-generation Thirdlane platform which i mentioned previously, but it is not going to be in 9.x.

Submitted by netriplex on Sun, 08/26/2018 Permalink

Eugene,

While you have provided an explanation of sorts, it doesn't address the major issue that Thirdlane will essentially be 2 YEARS behind their competitor is a fairly business critical feature of the mobile application.

I am assuming this based on your indication that this will not be fixed in the 9.X release train and since 9.X was released approximately 1 year following 8.X, I am extrapolating that we are at least a year out from seeing this feature being functional.

How does Thirdlane propose that we as service providers using Thirdlane are supposed to retain customers for a full year without this feature? Receiving an incoming phone call as a part of a hunt list is possibly one of the most elemental features of phone system. 3CX does it, Vonage, RingCentral, etc all are capable of this basic functionality. How do we compete when something this basic isn't possible? The market for Thirdlane as an acceptable solution is basically limited to customers who do not want mobile application based functionality because any person that wants to receive calls via a mobile app is going to want/need to be able to receive incoming calls via hunt list at the least.

Submitted by netriplex on Mon, 08/27/2018 Permalink

RJansen,

If it was a couple months that would be fantastic. However, Eugene has implied that it is at least a year away as he indicated that support for it will not be coming to the 9.X release train. Meaning, we wont see this until 10.X is released which is probably a year away.

Submitted by eugene.voityuk on Mon, 08/27/2018 Permalink

Netriplex, please do not make any statements regarding Thirdlane product releases – it is misleading and inappropriate. Also, you should understand that your experience may not apply to the majority of Thirdlane users who use Connect and don’t find it to be “useless”. I already explained the reasons why this can't be achieved right now, and that we are working on the new Thirdlane platform that is planned to be released this year. Let's consider this topic closed.