AgentLogin on PJSIP device behavior misunderstood


#1

Hello,

I have a testing environment of 3 pjsip registered devices registered by using realtime MySQL ps_* tables. (101,102,103)


xxxx*CLI> pjsip list endpoints

 Endpoint:  <Endpoint/CID.....................................>  <State.....>  <Channels.>
==========================================================================================

 Endpoint:  101                                                  Not in use    0 of inf
 Endpoint:  102                                                  Not in use    0 of inf
 Endpoint:  103                                                  Not in use    0 of inf

Objects found: 3

as well as 2 queues in queues table (arabic, english):

linuxbox*CLI> queue show
arabic has 0 calls (max unlimited) in 'ringall' strategy (14072s holdtime, 66s talktime), W:0, C:8, A:1, SL:0.0%, SL2:0.0% within 0s
   No Members
   No Callers


english has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0%, SL2:0.0% within 0s
   No Members
   No Callers

Also I have 2 agents registered in agents.conf as agent ids (1001, 1002):
here is the content of agents.conf:

[my_agents](!)
ackcall=yes
acceptdtmf=#
autologoff=20

[1001](my_agents)
fullname=John Smith

[1002](my_agents)
fullname=Jane Doe

I’m logging in agent (1002) on pjsip phone (102) using the dialplan Application “AgentLogin” by making AMI originate action:
with these parameters : {context:agent_login , priority: 1, channel: pjsip/102, exten: 102, caller_id: 1002}

The device 102 rings and when I answer it it plays “Agent logged in” prompt and keeps connected and call counter works on the softphone.

back to CLI, issuing agents list command gives this:

xxxx*CLI> agent show all
Agent-ID Name                 State       Channel                        Talking with
1001     John Smith           UNAVAILABLE
1002     Jane Doe             NOT_INUSE   PJSIP/102-000000a2

Defined agents: 2, Logged in: 1, Talking: 0

then after that, I dynamically add the agent (device) to ‘arabic’ queue using AMI : {action : QueueAdd, Interface: PJSIP/102, MemberName: Jane Doe} , it succeeds and QueueMemberAdded Event gives “status”: 2
Issuing Queue show CLI Command then gives:

xxxx*CLI> queue show
arabic has 0 calls (max unlimited) in 'ringall' strategy (14072s holdtime, 66s talktime), W:0, C:8, A:1, SL:0.0%, SL2:0.0% within 0s
   Members:
      Jane Doe (PJSIP/102) (ringinuse enabled) (dynamic) (In use) has taken no calls yet
   No Callers


english has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0%, SL2:0.0% within 0s
   No Members
   No Callers

When I use one of the other devices (101 or 103) to call extension 9000 (which does add the caller to “arabic” queue) , it rings and waits for an answer on 102 device while it was already inline through the privious call to AgentLogin.

What I’m expecting (say want) is, when a caller gets added to queue it should be directly connected to the assigned agent on device by queue strategy, so the agent hears a beep and gets connected to the caller and start the conversation directly without the need to click answer to get connected to the caller.

here is my dialplan’s extensions.conf contents by the way:


[general]
static=yes
writeprotect=no
priorityjumping=no
autofallthrough=yes
clearglobalvars=no

[globals]
; Dial timeout - 20sec.
DIAL_TOUT=20
; Digit timeout - 3sec.
DIGIT_TOUT=3
; Response timeout - 10sec.
RESP_TOUT=10


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; PBX :Calls between PJSIP Extensions that are**strong text** set in PS_* mysql tables
[from_customers]
exten => s,1,NoOp("A Call into from_customer has been made from Exten : ${EXTEN}")

exten => _1XX,1,NoOp(called extension : ${EXTEN})
same => n,Answer()
same => n,Dial(PJSIP/${EXTEN})


exten => 9000,1,NoOp("Extension 9000 has been called by ${EXTEN} ${CALLERID}")
same => n,Answer()
same => n,Queue(arabic)


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; https://blogs.asterisk.org/2016/02/10/converting-from-chan_agent-to-app_agent_pool/
; agents added in agets.conf as 1001,1002,

[agent_login]
exten => _XXX,1,NoOp(Agent login has been called from extension ${EXTEN} ....)
same => n,NoOp(Login agent with id :  ${CALLERID(num)})
same => n,set(agent_id, ${CALLERID(num)})
same => n,NoOp("Caller Agent ID Is : ${agent_id}")
same => n,Set(CHANNEL(dtmf-features)=H)
same => n,Set(CONNECTEDLINE(all)="Awaiting call" <${EXTEN}>)
same => n,Answer()
same => n,AgentLogin(${CALLERID(num))
same => n,NoOp("Agent Login status is : ${AGENT_STATUS}")
same => n,Hangup()

[agents]
exten => _XXXX,1,NoOp(inside agents context request agent in extension ${EXTEN})
same => n,AgentRequest(${EXTEN})
same = n,Congestion()


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

can someone please hint me on how to make this done ?


#2

You need to add the agent channel, not the underlying PJSIP one. At ;east that is how it used to work.


#3

But aren’t agent channels get obsolete or deprecated as per my understanding on this link:
https://blogs.asterisk.org/2016/02/10/converting-from-chan_agent-to-app_agent_pool/

or i’m missing something ?

if so, is there any suggesting on what do I need to change to make it work ?


#4

My knowledge of agents is dated, but I think I can pretty safely say that adding the PJSIP channel to the queue won’t magically trigger AgentRequest logic for it. It will literally put that device as the queue member and calls will be made direct to that device. If there is an AgentLogin in effect, I would assume that they will either appear on the second line on the device, or be rejected by the device.

Without bringing myself fully up to date, my guess would be that one has to put a local channel in the queue and that channel then has to call AgentRequest. Actually, looking at the document you reference, it does clearly state that local channels have to be added to the queue:

As you can see, the queue members have to be Local channel members that monitor the agent’s custom device state “ Agent:<agent-id> "


#5

Brilliant :+1: !
Yes, it worked perfectly After using Local/[agent_id]@agents as the interface instead of the underlying PJSIP Channel.

Thanks @david551