External queue agents with call confirm

Status
Not open for further replies.

yois

New Member
Jul 14, 2020
12
1
3
41
Use Case:
Volunteer roadside service dispatchers that take calls on their cell phones from a Queue. There will never be a physical extension registered to the PBX. Call Confirm is necessary so that calls from the queue don't appear "answered" by the mobile phone's voicemail.

I can't figure out how to do this.

I've created a dummy extension with follow-me; that doesn't work as the call fails as NOT_REGISTERED. This is already mentioned in this thread:

I tried a loopback/<extension> as the agent contact, but the logs just show that the call "loopback/<extension>-b has reached the last dialplan instruction." But when routing an inbound DID to the <extension> directly, follow-me is working correctly. Something about the B leg of the call doesn't find a match in the dialplan.

I then tried loopback/<extension>/<context>, then I get:
Code:
[ERR] mod_lua.cpp:202 /usr/share/freeswitch/scripts/app/follow_me/index.lua:228: bad argument #1 to pairs (table expected, got nil)

While I'm at it... As I'm playing with this, every time I make a change to the Agent configuration, I need to restart the Call Center in order for the agent to appear as logged in. Am I missing something basic about logging in an agent into a queue?

I'm a FusionPBX noob with a strong FreePBX/Asterisk background. This is something that is SO easy with Asterisk and seems impossible with FreeSWITCH.
 
Last edited:

yois

New Member
Jul 14, 2020
12
1
3
41
I enabled SQL debug in follow_me LUA, and found that the domain UUID is being set to a random UUID that isn't even present on my system when looping back from the queue.

I worked around this by setting the correct domain_uuid in the domain_variables section of the dialplan for the correct context, but this seems like a bug of some sort.

Any explanations? Where is domain_uuid supposed to be set in the dialplan, and shouldn't it be an export instead of a set?
 
  • Like
Reactions: neil1788
Status
Not open for further replies.