Intersite screen pops

[MarcRobinson]

We have two call centers, one in MO and one in NE. Until recently we've had GVPs only at the MO site. We now have GVPs at both sites. Calls can come to either site. When a GVP releases a call to go to an agent, the PBX can transfer the call either to a local agent, or to the other site to take advantage of the lowest expected wait time. (NOTE: We are NOT using Genesys routing. The Avaya switches manage the routing decisions.)

We have no problem with screen pops for an agent at the same location (i.e., a MO GVP transferring to a MO agent works; an NE GVP transferring to an NE agent works). Also, when a call transfers from a MO GVP to an NE agent, the screen pop works. But when a call transfers from an NE GVP to a MO agent, we get no screen pop.

We've checked configurations until we're blue in the face, bounced all our services, and our vendor has double-checked everything, too. Is there anything else that might explain this? We're under a time deadline to get this working, and getting rather concerned.

By the way, the logs for the NE  T-Servers show messages like this, which contains the word "Skipped" and isn't like the MO T-Server logs:
@11:22:41.0480 [ISCC] Trace: Received from server [MO_TServer]@[MOSwitch]/0/2/2: message ISCCEventCallInfo
ISCCAttributeReferenceID 8716289 [00850001]
ISCCAttributeResponseCode Skipped
ISCCAttributeTrackingID 7208964 [006e0004]

[René]

Hi Marc,

You wrote that Avaya is responsible for routing of the interactions so I assume Genesys does monitor agent's extensions and your application does screen pop-up when a call arrives. Is that correct?

In that case I have few questions...

- What application does screen pop-up (in-house development, GDesktop, CRM with Gplus etc.)?
- How is screen pop-up fired (simply by EventRinging or there are multiple conditions like EventRinging + some key in UserData etc.)?
- Could you post here log of TServer showing "EventRinging" event on agent's extension for successful and unsuccessful screen pop-up?

René

[Marc]

Rene,
Thanks for the response.
I posted a reply, but it didn't show up. Here goes again.

In response to your questions:

- What application does screen pop-up (in-house development, GDesktop, CRM with Gplus etc.)?
We use an application we developed in-house. It's been working for a year. Its logs shows that it isn't getting the call information from the T-Server. This confirms what we see in the T-Server logs.

- How is screen pop-up fired (simply by EventRinging or there are multiple conditions like EventRinging + some key in UserData etc.)? Not sure -- I'd have to check with our developer. But I think it's fired off when the event is fully established. I'll check on this.

- Could you post here log of TServer showing "EventRinging" event on agent's extension for successful and unsuccessful screen pop-up?
Here's one I think succeeded -- it's been a few days, so I can't guarantee this:

@09:55:43.2860 [<<] 08 00 00 45 08 02 81 B1 62 96 1C 3D 91 A1 3A 02 01 02 02 01 95 40 32 0C 05 FF 31 32 32 38 10 02 0E 79 6C 0B 81 37 38 35 37 36 34 39 35 30 32 70 05 FF 33 37 33 38 96 0A 03 80 8F 8B 44 01 82 47 01 81 49 05 81 31 39 33 B5
TP_AsaiData
FACILITY  CRV:81b1
Facility: INVOKE
InvokeId: 2
Operation: EventReport
ConnectedNum[1]: (local),'1228'
CallID[1]: 3705
CallingNum: (ISDN_telephony),'7857649502'
CalledNum: (local),'3738'
TrunkGroupId[1]: (dir/gr/memb),0/15/11
PartyId[1]: 2
Event[1]: Alerting
Domain[1]: (ACD_Split),'1935'
@09:55:43.2860 [asai] (processEvReportAlerting)
@09:55:43.2860 [gctmi] TMsg [EventRinging(1228)] distributing to model
@09:55:43.2860 [gctmi] Call [007301818528fc90/e79,sOG,tOG,l1] distributing EventRinging
@09:55:43.2860 [gctmi] Call [007301818528fc90/e79,sOG,tOG,l1] processRinging
@09:55:43.2860 [asai] Call [007301818528fc90/e79,sOG,tOG,l1] (createParty)
@09:55:43.2860 [gctm] Party [007301818528fc90:1228,s0,tDN,rDST,lINT] created.
@09:55:43.2860 [asai] Party [007301818528fc90:1228,s0,tDN,rDST,lINT] (AsaiIntParty)
@09:55:43.2860 [asai] Party [007301818528fc90:1228,s0,tDN,rDST,lINT] setting id to 2
@09:55:43.2860 [gctm] Party [007301818528fc90:3738,s9,tQ,rDST,lINT] rls-party best match, weight 85% to EventRinging
@09:55:43.2860 [gctm] Party [007301818528fc90:1935,s9,tQ,rDST,lINT] rls-party certain match to EventRinging
@09:55:43.2860 [gctm] Call [007301818528fc90/e79,sOG,tOG,l1] ReleaseParty match found.
@09:55:43.2860 [gctmi] Party [007301818528fc90:1935,s9,tQ,rDST,lINT] processDiverted
@09:55:43.2860 [gctm] Party [007301818528fc90:1935,s9,tQ,rDST,lINT] Changing state to 0

Here's one that failed:

@14:15:51.8760 [0] 7.5.011.03 distribute_event: message EventRinging
AttributeEventSequenceNumber 0000000000000056
AttributeTimeinuSecs 876000
AttributeTimeinSecs 1193426151 (14:15:51)
AttributeCallState 0
AttributeNetworkCallID 4294967295
AttributeCallType 2
AttributeCallID 14336
AttributeConnID 00850181bb351007
AttributeCallUUID 'C7S9J8AJVT4872A5CL4PPKQ63C00000M'
AttributeUserData [18] 00 01 00 00..
'II-Digits' '00'
AttributeDNIS '3405'
AttributeANI '8164601200'
AttributeThisTrunk 131076
AttributeThisDN '29599'
AttributeThisDNRole 2
AttributeOtherDN '8164601200'
AttributeOtherDNRole 1
AttributeExtensions [19] 00 01 02 00..
'UCID' bin: FF FF FF FF.. (len=8)
@14:15:51.8760 [ISCC] Debug: Translate: '8164601200' -> ''; result 1 ()
14:15:51.876 Int 04544 Interaction message "EventRinging" generated
14:15:51.876 Trc 04542 EventRinging sent to [448] (00000005 LincolnDevI-Server72 10.19.10.49:1731)
14:15:51.876 Trc 04542 EventRinging sent to [436] (00000004 DevRaytownStatServer72_B 170.231.31.232:1512)
@14:15:51.8760 [ISCC] Debug: Redistribute seized events finished
@14:15:51.8760 [ISCC] Debug: Transaction [COF8716293] is removed
@14:15:52.5630 [<<] 08 00 00 46 08 02 80 28 62 96 1C 3E 91 A1 3B 02 01 02 02 01 95 40 33 08 02 81 90 0C 06 FF 32 39 35 39 39 10 02 38 00 6C 0B A1 38 31 36 34 36 30 31 32 30 30 70 05 A1 33 34 30 35 96 01 01 00 0A 03 80 82 84 44 01 82 47 01 8B
TP_AsaiData
FACILITY  CRV:8028
Facility: INVOKE
InvokeId: 2
Operation: EventReport
Cause: C_NORMAL
ConnectedNum[1]: (local),'29599'
CallID[1]: 14336
CallingNum: (natl_ISDN_tel),'8164601200'
CalledNum: (natl_ISDN_tel),'3405'
OrigLine_II_digits: 0
TrunkGroupId[1]: (dir/gr/memb),0/2/4
PartyId[1]: 2
Event[1]: Connected
@14:15:52.5630 [asai] (processEvReportConnected)
@14:15:52.5630 [gctmi] TMsg [EventEstablished(29599)] distributing to model
@14:15:52.5630 [gctmi] Call [00850181bb351007/3800,sOG,tOG,l1] distributing EventEstablished
@14:15:52.5630 [gctmi] Call [00850181bb351007/3800,sOG,tOG,l1] processEstablished
@14:15:52.5630 [gctm] Call [00850181bb351007/3800,sOG,tOG,l1] Transition to ESTABLISHED state.
@14:15:52.5630 [asai] Call [00850181bb351007/3800,sOG,tOG,l1] (createParty)
@14:15:52.5630 [gctm] Party [00850181bb351007:8164601200,s0,tUNK,rORG,lEXT] created.
@14:15:52.5630 [asai] Party [00850181bb351007:8164601200,s0,tUNK,rORG,lEXT] (AsaiExtParty)
@14:15:52.5630 [asai] Party [00850181bb351007:8164601200,s0,tUNK,rORG,lEXT] setting id to 1
@14:15:52.5630 [gctmi] Party [00850181bb351007:8164601200,s0,tUNK,rORG,lEXT] processDialing
@14:15:52.5630 [gctm] Party [00850181bb351007:8164601200,s0,tUNK,rORG,lEXT] Changing state to 1000c
@14:15:52.5630 [ISCC] Debug: Party added [ssp view]:
@ c:00850181bb351007,010ef250 @ m:0000000000000000,00000000,0000000000000000 p:2 i:00003800 nw:00000000:ffffffffffffffff t:2
 p:011a4a50 @ c:00850181bb351007,010ef250 r:2 t:0 s:0 n:29599
+ p:011a4600 @ c:00850181bb351007,010ef250 r:1 t:1 s:0 n:8164601200
@14:15:52.5630 [ISCC] Debug: Party added:
@ c:00850181bb351007,010ef250 @ m:0000000000000000,00000000 p:2 i:00003800 nw:0000000000000000 t:2
 p:0000000000000000,011a4a50 @ c:00850181bb351007,010ef250 r:2 ------ n:29599:
+ p:0000000000000000,011a4600 @ c:00850181bb351007,010ef250 r:1 ------ n:8164601200:
@14:15:52.5630 [gctmi] Party [00850181bb351007:29599,sa,tDN,rDST,lINT] processEstablished
@14:15:52.5630 [gctmi] Address [29599,tDN,sIDLE] processOffHook
@14:15:52.5630 [gctm] Address [29599,tDN,sIDLE] Changing state to 1
@14:15:52.5630 [0] 7.5.011.03 distribute_event: message EventOffHook
AttributeEventSequenceNumber 0000000000000057
AttributeTimeinuSecs 563000
AttributeTimeinSecs 1193426152 (14:15:52)
AttributeThisDN '29599'

[René]

Hi Marc,

I don't see the event "EventRinging" for successful attempt so I can't compare it with the unsuccessful one. But event without that comparison the unsuccessful EventRinging seems to be OK. The only thing I would like to point out is that there are no UserData present.

Right now we need to know what conditions have to be fulfilled to fire off a screen pop on agent's desktop. Without that information it will be quite hard to find out why it doesn't work.

René

[victor]

Ok,

I think we got the problem... (I am hoping)

@11:22:41.0480 [ISCC] Trace: Received from server [MO_TServer]@[MOSwitch]/0/2/2: message ISCCEventCallInfo
  ISCCAttributeReferenceID  8716289 [00850001]
  ISCCAttributeResponseCode  Skipped
  ISCCAttributeTrackingID  7208964 [006e0004]

I bet that when GVP transfers a call, you do not have the right multi-site routing in place.

I am asking you to post a log of call transferred froom GVP to an agent on another site when you do not get the screen popup (I want both T-Servers), but since you are under a bit of time deadline, here are some of the major things I would check first:

1. do you allow attach data to be added to consult-call (is it set as join in CME) If no, chances are your GVP is placing a consult call to another site and then completes it, meaning that destination server does not know that and thus it never updates the user-data
2. using external routing point : if you are not using it, try using external-routing point instead of direct uui-based one. If you do not know how to do it, tell me and I will guide you through that (it is just defining ERP on both sites, and playing with GVP/URS (if you have it)
3. I will need to think...

But my gut feeling tells me that you are probably not setting consult-user-data to joint and your GVP is doing two-step transfer...
Check that and please post the log

Best regards,
Vic

[René]

Vic,

Marc has written that routing is done by Avaya not by Genesys URS. So I'm not sure if "pure" ISCC works in that situation. Maybe ISCC/COF could be a way...

René

[victor]

Good point, René (ﾞﾞﾟàáâãääåæçèêë! )

but I am guessing that since  calls and attach-data are working between the sites, it means that they got attach data at least going one way. Thus, whatever they have set for Genesys routing, at least, works. I'm guessing GVP on one site is probably transferring through a queue or manages to complete a transfer faster than the other one At least, this would be my initial guess and I would check logs for ISCC whether it has attach data and ConnID passed between sites or not.

[MarcRobinson]

Sorry I never got back to you guys.

It turns out that the problem was in the Avaya PBX! The AES link between the PBX and the T-Server was set up and working. However, there were TWO configurations in the PBX that are necessary for the T-Server to get the UCID from the PBX, (and the PBX-assigned UCID is necessary in order for the near and far T-Servers to send call-associated information.)
These settings were:
      Create Universal Call ID (UCID)? y
      Send UCID to ASAI? n
The PBX was creating the UCID, but not sending it to the T-Server. So when the call was handed from the near site to the far site, there was no way for the far T-Server to connect an incoming call with the call information the near T-Server had sent it. We changed the second setting to 'y' and this solved the problem.

Truly an esoteric situation.