Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: vrbros on April 15, 2009, 07:08:32 PM
-
Hi,
We are working with a big Telecom service provider for their CTI inbound setup with AVAYA WVR and Genesys.
The customer has two types of agents, one that login using the Genesys custom CTI toolbar and get screen popup’s and the agents that login in directly to ACD using the AVAYA phones. Both types of agents might use the same Place for their operations at different times.
Now, using CCPulse, when we check the count of the total agents logged in on the places monitored by TServer, we get the count including both Genesys agents and non Genesys agents. Is there any way that we can have the count only representing the Genesys agents?
CHEERS!!
Ritesh
-
I think I read this question...here? Or was in the other forum. Any way, the fact that you can monitor the other agents means that they are Genesys agents too. Maybe not in operational mode of work but yes in the way that Genesys can monitor their DNs. Maybe you can try to Cound the logged in agents on each Queue and have a Queue for Genesys workers and another for non-Genesys workers.
-
There are quite a few threads in this Forum around this subject. Try searching for LOGIN Table... ;)
Tony
-
Hi,
The same agents may log in using the Genesys Agent desktop at one time and directly into the ACD using hard phone at another. So technically they log in to the same queue at both times.
Any way of differentiating the agent’s login method from any TServer event?
CHEERS!!
-
Hi,
Well, you could implement in to your softphone reason KVP for request loggin, so all agents who would use softphone will always have the reason code along with the loggin request and this you could then simply use to buildup filter to discriminate between softphone and non-softphone users in CCPulse for stat loggedin.
Cheers,
e.
-
ecki, as far as I remember this only works if you capture the event login, however not when asking how many agents are logged in with a stat...will try tomorrow again
-
Well id does work, however the stat will rise when agent will complete the login action with action logout.
-
Dear Ecki,
I understand what you say. The reason i didn't implemented this is because of the following scenario in our production floor:
- Agents log in using the Genesys Agent Desktop (lets assume here that it is sending the custom KVP here)
- Stat server acknowledges the same and increases the count of total number of agents logged in
- When the agent wants to log out, he has two options, press Logout button on Genesys Agent Desktop or press the "Hook" button/ Headset button on the AVAYA phone because it too triggers logout event via ACD
- If the agent presses the Logout button ---- NO ISSUES, as we can again send a KVP for stat server to decrement the count
- If the agent presses the "hook" button or the headset button, the agent still logs out (called Hard logout) but our stat server does not receives any custom KVP to understand that a Genesys agent has logged out. :(
Another scenario is where, lets say, there was a PC problem and the softphone was terminated forcefully.
So here in this scenario, the count on stat server increases but on logout, we might not be able to decrease the count.
Please note, i have about 1600 seats with a total of about 3500 agents working in shifts. And about 99% of agents use Hard logout instead of using the logout button on softphone.
CHEERS!!
-
Ritesh - can we return to the problem statement? What are you trying to achieve - the number of Agents Logged in to the Genesys environment? Would you consider counting the absolute number of checked out SDN Licenses... on FlexLM?
Tony
-
Tony, I need total number of agents logged in using the Genesys Agent Desktop. For the current environment, the same agent can log in using the GAD or directly using the AVAYA phone.
The solution is for supervisors and other manegerial people, FLexLm's console might not be a good option here.
CHEERS!!
Ritesh
-
Vrbros
It is enough when the reason is with request agent loggin. It does not have to be with request agent loggout as well. So you are safe in any case. Important is that agents are using softphone when they are logging in. Then the softphone can die and still Stat server will capture the right statistics because the loggin event is counted. I just tested it.
Cheers.
E.
-
Well easy too, if this works try ~(PairExists("KEYLOGIN","*") to count agents who can't send a KVP (hardphone) and (PairExists("KEYLOGIN","*") to count agents who can login using GAD or a softphone made by you.
Another thing you may use is in GAD go to http://genesys/gdesktop/admin and see al the agents logged in using GAD...
-
Hi Vic,
Sorry for this question, but I do not have deep knowledge about GAD yet ;). So here is the question. What exactly you can get with this link you provided?
Cheers,
e.
-
Vic <> Cavagnaro <> Vic <> caVagnaro....only see the V in common... 8)
In that section the admin can see who is using GAD and even logout the agents or get some data from them.
-
;D Sorry Cav my mistake. Thanks for answer. As I expected. It is the current status.
Cheers,
e.
-
Dear Ecki,
[i]"It is enough when the reason is with request agent loggin. It does not have to be with request agent loggout as well. So you are safe in any case. Important is that agents are using softphone when they are logging in. Then the softphone can die and still Stat server will capture the right statistics because the loggin event is counted."[/i]
The idea of sending a KVP for stat server to get the count that agent is logging in is OK. But how would stat server understand the logout without the KVP? I am sorry I was not able to test this as I was stuck with some documentation for site and lost track of this thread.
CHEERS!!
-
Hi,
Have look in to the Stat Server user guide Filter section. Just for info, Logged in is durable action.
>>>>>
For durable actions and statuses, Stat Server uses the number of times that
a filter condition was true on an action (or status) and the duration of time
for which the filter was true.
>>>>>>
-
I'd like to take a step back here... There are some statements I think it might be worthwhile exploring...
It's been stated that the Agent has 2 options to log out - via GAD and via the physical turret. The problem statement is that the StatServer is informed of the GAD Logout but not a physical turret logout...?
In my experience;
Using GAD to log out the Agent send a TEvent [b]Request [/b] = [i][b]TAgentLogout[/b][/i]. Once the T-Event is confirmed, the Switch/ACD will send an [b]Event [/b] to confirm the [i][b]TAgentLogout[/b][/i].
A physical Turret Logout [i]should [/i] invoke an instruction to the Switch/ACD [i]directly[/i], which is subsequently sent via the CTI Link to the T-Server, in the form of an [b]Event[/b] = [i][b]TAgentLogout[/b][/i].
So, in my opinion the TServer should be up-to-date(?) It is only the StatServer which is not obtaining the correct status updates - for Agents Logging out using their physical turret instead of GAD(?)
I suggested using the LOGIN Table, earlier in this thread. I have not had an opportunity to explore whether both scenarios for Logout (GAD vs. Turret) increment/decrease entries in the LOGIN Table. It is populated as a result of input from the TServer via the StatServer but I think it may work, in this scenario.
We have use of an Avaya and I have the LOGIN Table set up in our DEV environment - I'll take a look at what entries are updated (and how) when using;
A. A physical turret LOGIN (i.e. no Genesys)
B. A physical turret LOGOUT (i.e. no Genesys)
C. A GAD LOGIN
D. A GAD LOGOUT
E. A GAD LOGIN with a physical turret LOGOUT
F. A physical turret LOGIN with a GAD LOGOUT
I'll get back to you all with results...
Tony
-
Hi Tony,
I think the matter is rather in that they have two types of agent. One type are using GAD during entire CC work from login to logout and the other are using purely the hard phones (no CTI at all) although the place is monitored by Genesys. Probably those agents does not need CTI or does not have skill to do so. And as I understood it right, they want to know, how many agents were working on the particular day with Softphone and how many without.
-
Understood - so, as long as the TServer and IServer ([i]not [/i] IXNServer :) ) are effectively monitoring the whole ACD/GAD range (CTI and non-CTI) then we [i]should [/i] get LOGIN/LOGOUT result through TEvents, which [i]should [/i] be monitored by a StatServer, as long as it has all of the relevant TServer(s) and IServer(s) as connections and is correctly connected/configured via a DAP/DBServer to write the results into the LOGIN Table... ?
I'm taking a look at it, today... :)
Tony
-
OK - From what I can gather, you will be able to obtain a LOGINID and an indication of a LOGIN or LOGOUT, as well as a Timestamp from the LOGIN table and various other Configuration References.
I have tested a few scenarios and the TServer accepts all relevant EVENTS from the attached Switch/PBX (Avaya) then as long as the CME environment lists/registers [b]all [/b] LOGINID's (DN's) for both CTI and non-CTI Hard Phone/turret Extensions. For some clarity - if you add an IServer to the Connections of the StatServer, it can extract all of the associated LOGIN/LOGOUT EVENTS from the GAD, too.
For this to work, I need to make an assumption that the Extensions/DN's themselves are identifiable as "CTI" and "non-CTI". The results Table (LOGIN) can be extracted and queried on the basis of the Extension/LOGINID, Timestamp (Time Range) and Status (1 = LOGIN, 0 = LOGOUT)
Further to this, the following information is available on the LOGIN Table;
SWITCHDBID, DBDBID, QUEUEDBID, AGENTDBID, PLACEDBID, STATUS, TIME and LOGINID.
- It follows that it would be possible to create a LOOKUP Query from this information, to determine which LOGINID's (or PLACEDBID's) are logged in - and when they logged out. Of course, if the Agent simply closes GAD without logging out, you'd need to find a clever way of determining a "time-out" period of inactivity, to emulate a LOG OUT for those types of instances.
I'm sayng it [i]can [/i] work when using the LOGIN Table - with a bit of development!
- Anyone else want to venture their opinion?
Tony
-
[quote]For some clarity - if you add an IServer to the Connections of the StatServer, it can extract all of the associated LOGIN/LOGOUT EVENTS from the GAD, too.[/quote]
Tony, could you explain me why you need IServer for GAD? GAD is application based on Genesys AIL (Agent Interaction Layer) and communicates directly with TServer (on server side of course). IServer is virtual application used by IVR TServer. I don't see any connection between these two apps...
If StatServer monitors particular DN then login/logout events occurring on that DN (place) will be saved to LOGIN table. StatServer only need one connection for that - connection to TServer.
R.
-
Tony,
The issue is from what I understood, that the same extension is used by both types of agents. Agents who uses GAD for whole time of their session (except when agent is lazy to use softphone for log out or some component just crash down) and Agents who does not use GAD at all. As the extension is monitored by TServer, Stat Server is getting all events no matter if Agents are using GAD or not. How are you going to separate those two agents using data from LOGIN table? Or did I understand the core problem whatsoever?
e.
-
Rene,
The suggestion is that, [i]if [/i] you have a blended environment, you may want to connect to the TServer for Voice and also an IServer (based on the TServer template) for Interactions information. I tried to explain that it was [b]not [/b] an IVR TServer, but an MCR IServer - which is, in essence, a TServer too...! :)
Tony
[quote author=René link=topic=4096.msg18215#msg18215 date=1240320833]
[quote]For some clarity - if you add an IServer to the Connections of the StatServer, it can extract all of the associated LOGIN/LOGOUT EVENTS from the GAD, too.[/quote]
Tony, could you explain me why you need IServer for GAD? GAD is application based on Genesys AIL (Agent Interaction Layer) and communicates directly with TServer (on server side of course). IServer is virtual application used by IVR TServer. I don't see any connection between these two apps...
If StatServer monitors particular DN then login/logout events occurring on that DN (place) will be saved to LOGIN table. StatServer only need one connection for that - connection to TServer.
R.
[/quote]
-
Understood - I mentioned that the LOGIN Table also contains a Field called "PLACEDBID". Any entries on the LOGIN Table [i]with [/i] a PLACEDBID = CTI/Genesys, [i]without [/i] a PLACEDBID = non-CTI/Genesys...
At least, I [i]think [/i] that's right...?
Tony
[quote author=ecki link=topic=4096.msg18216#msg18216 date=1240321960]
Tony,
The issue is from what I understood, that the same extension is used by both types of agents. Agents who uses GAD for whole time of their session (except when agent is lazy to use softphone for log out or some component just crash down) and Agents who does not use GAD at all. As the extension is monitored by TServer, Stat Server is getting all events no matter if Agents are using GAD or not. How are you going to separate those two agents using data from LOGIN table? Or did I understand the core problem whatsoever?
e.
[/quote]
-
[quote]I tried to explain that it was not an IVR TServer, but an MCR IServer - which is, in essence, a TServer too...![/quote]
OK. Now it's clear to me. Thank for the explanation Tony
Personally, I'm using the abbreviation IxnServer for Interaction Server to avoid confusiong with IVR IServer :)
[quote]Understood - I mentioned that the LOGIN Table also contains a Field called "PLACEDBID". Any entries on the LOGIN Table with a PLACEDBID = CTI/Genesys, without a PLACEDBID = non-CTI/Genesys...[/quote]
Have you tested that? I would say that PLACEDBID will be filled even for non-CTI logins as StatServer uses place as the primary object internally.
R.
-
Going to try it out, tomorrow...
[quote author=René link=topic=4096.msg18221#msg18221 date=1240326103]
[quote]I tried to explain that it was not an IVR TServer, but an MCR IServer - which is, in essence, a TServer too...![/quote]
OK. Now it's clear to me. Thank for the explanation Tony
Personally, I'm using the abbreviation IxnServer for Interaction Server to avoid confusiong with IVR IServer :)
[quote]Understood - I mentioned that the LOGIN Table also contains a Field called "PLACEDBID". Any entries on the LOGIN Table with a PLACEDBID = CTI/Genesys, without a PLACEDBID = non-CTI/Genesys...[/quote]
Have you tested that? I would say that PLACEDBID will be filled even for non-CTI logins as StatServer uses place as the primary object internally.
R.
[/quote]
-
OK - I have found that an AGENTDBID is not appended to the entry in the LOGIN Table, when a hard phone/turret is used to LOGIN or LOGOUT - but the entry is valid in all other respects (SWITCHDBID, DBDBID, QUEUEDBID, PLACEDBID, STATUS, TIME and LOGINID are all populated.)
This would mean that you [i]can [/i] differentiate between CTI and non-CTI LOGIN's and LOGOUT's using the LOGIN Table Option of the StatServer. [i]How [/i] you do that is (and report from it) is the next problem... ;)
Tony