PartyChange event being sent during transfers on T

we have setup a desktop application to handle call transfers. These work ok when the transfer destination is on a different T server. However when the transfer is on the same T server the genesys messages come in in a different order.

In the transfer to the same T server we get a PartyChange event during the transfer, which has a different ConnID.

In our normal model we have defined the PartyChange event as signifying an inbound transfer call.

Does anyone know why the T server would be sending the PartyChange event during a transfer or has anyone have a similar problem/setup?

I think this can be normal and your application should be aware of that to handle calls properly.

The possible scenarioes are:

Scenario A.

1. Agent1 (A1) has a call (C1)

2. A1 makes a consult call (C2) to a queue to transfer the call. C1 is on hold.

3. C2 from the queue goes to Agent2 (A2) A2 gets EventRinging (C2)

4. A2 answers EventEstablished (C2)

5. A1 completes the transfer A2 has EventPartyChanged which “turns C2 into C1” (this event has ConnId = C1 and PreviousConnId = C2)

6. A2 has C1 call, A1 has no call.

Scenario B.

1. Agent1 (A1) has a call (C1)

2. A1 makes a consult call (C2) to a queue to transfer the call. C1 is on hold.

3. C2 from the queue goes to Agent2 (A2) A2 gets EventRinging (C2)

4. A1 completes the transfer before A2 has aswered. A2 has EventPartyChanged which “turns C2 into C1”

5. A2 answers EventEstablished (C1)

6. A2 has C1 call, A1 has no call

Scenario C.

1. Agent1 (A1) has a call (C1)

2. A1 makes a consult call (C2) to a queue to transfer the call. C1 is on hold.

3. A1 completes the transfer before C2 has been routed anywhere. EventPartyChanged which “turns C2 into C1” is on the queue

4. C1 from the queue goes to Agent2 (A2) A2 gets EventRinging (C1)

5. A2 answers EventEstablished (C1)

6. A2 has C1 call, A1 has no call

Please, take a look at events that A2 gets.

I think the case of transferring to the remote TServer is scenario C, transferring to the local TServer is A or B (depends on the type of transfer i.e. if this is a mute transfer or a twostep transfer, the way the agents make transfers etc.).

if the transfer is not to the queue the scenarioes are very similar. In case of transferring to the remote TServer is identical, because the remote ransfer mechanism behaves like a queue.

Regards,

Leszek

Thnaks for that but what we actually are getting in scenario 3 is the PartyChange event being delivered to agent1 A1. Is this correct?

Can you, please, make a test call and describe the details (Dn, ConnectionId) of all the events you are getting?

BTW. Have you got a call recording solution? If yes, is recording performed by singlestep conference?

Leszek

Agent1 sends TransferStart

04/04/06 12:56:14.365 : Transfer1: Source Call ID 34759510,

   DN 1324445330, In Call, TConn 03260149CF9C5245,

Agent1 gets Event EventAttachedDataChanged

  DN 1324445330, In Call, TConn 03260149CF9C5245 

Agent1 gets Event EventHeld

Call Info : ID 34759510, DN 1324445330, Held, TConn 03260149CF9C5245,

Agent1 gets EventAttachedDataChanged

Call Info : ID 34759510, DN 1324445330, Held, TConn 03260149CF9C5245,

Agent1 gets Event EventDialing

Call Info : ID 34759510, DN 1324445330, New Call, TConn 02C801508821DB05

Event Evented

ENESYS_SO : Call Info : ID 34759510,

Agent 1 gets

DN 1324445330, In Call, TConn 02C4015084F7D9E9, User Data

04/04/06 12:56:17.879 TRACE: GT_GENESYS_SO :04/04/06 12:56:17.880 TRACE: GT_GENESYS_SO : TSERVER_EVENT [05473, 385876021, 1324455330, 1324445330] PartyChanged :

Agent 2 gets Event EventRinging

ID 34759510, DN 1324445336, New Call, TConn 02C4015084F7D9E9,

Agent 2 gets Event EventEstablished

DN 1324445330, In Call, TConn 02C4015084F7D9E9,

It’s weird.

Agent 2 gets events with ConnId attribute different from ConnIds in both held and consultation calls.

Is it possible that the calls don’t go directly from agent to agent in the same site, but they go to another site and then come back to the first site?

I think it’s time to take a look at the TServer logs.

If you want me to do it, please send them.

Regards,

Leszek

I think that the call is possibly sent to a queuing system within the same T server. This might change teh connID.

Unfortunately I am unable to send logs outwith the company but thanks for all your help. I think one of the guys in our team is in contact with Genesys.

I’ll post up the resolution if we get one.

cheers

Unfortunately we had to alter our application code to deal with the scenario of a SCR routed call being delivered to the same T server.

For this scenario we will get a partyChang event, after the transferStart, which will change the conn id of the 3rd party. :-[

I don’t understand why you don’t think there should be a new conn id after the transfer is complete.

Here’s a log generated by a tlib utility I wrote showing a transfer from DN 21106 to DN 21107 of a call placed by DN 21112 to DN 21106:

21106 presses transfer, 2112 is put on hold:
9/12/2006 3:15:52 PM: EventHeld, Conn ID:0078015eb530e83d, This DN:21106, Other DN:21112

Pressing transfer involves selecting a new line, this is where the new conn id comes in. 21106 now has 2 conn id’s associated with it:
9/12/2006 3:15:52 PM: EventOffHook, Conn ID:0078015eb530e83e, This DN:21106, Other DN:
9/12/2006 3:15:52 PM: EventOffHook, Conn ID:0078015eb530e83e, This DN:21106, Other DN:

21106 dials 21107 and they connect:
9/12/2006 3:15:55 PM: EventDialing, Conn ID:0078015eb530e83e, This DN:21106, Other DN:21107
9/12/2006 3:15:55 PM: EventRinging, Conn ID:0078015eb530e83e, This DN:21107, Other DN:21106
9/12/2006 3:15:55 PM: EventRinging,0078015eb530e83e,21107,21106,21106,21107,
9/12/2006 3:15:56 PM: EventEstablished, Conn ID:0078015eb530e83e, This DN:21107, Other DN:21106
9/12/2006 3:15:56 PM: EventEstablished, Conn ID:0078015eb530e83e, This DN:21106, Other DN:21107

21106 completes the transfer, and now 21112 is talking to 21107:
9/12/2006 3:15:57 PM: EventReleased, Conn ID:0078015eb530e83d, This DN:21106, Other DN:21112
9/12/2006 3:15:57 PM: EventReleased, Conn ID:0078015eb530e83e, This DN:21106, Other DN:21107
9/12/2006 3:15:57 PM: EventOnHook, Conn ID:0000000000000000, This DN:21106, Other DN:
9/12/2006 3:15:57 PM: EventOnHook, Conn ID:0000000000000000, This DN:21106, Other DN:

21107 and 21112 are notified by EventPartyChanged that 21106 has left the new conn id:
9/12/2006 3:15:57 PM: EventPartyChanged, Conn ID:0078015eb530e83d, This DN:21112, Other DN:21107
9/12/2006 3:15:57 PM: EventPartyChanged, Conn ID:0078015eb530e83d, This DN:21107, Other DN:21112

Hope that answers your questions.

Genecist,

if you carefully look at your code, you will see that you do not get a new ConnID after PartyChanged. You get xxxe83d which is ConnID of your original call being transferred. This was deduced by checking your EventHeld, which shows ConnID held before the trnasfer originated.

John log shows that there are three distinct ConnID: the original one, the consult call one, and the final one. This is caused by his PBX setting, which issues a new CallID after transfer-complete sequence. There is an option in tserver which let’s user control this.

John: AttributeTransferConnID - what does it say? Does it have your original ConnID in it?

You do not have this problem in multi-site transfer, because remote T-Server adjusts connid with the original connid using ISCC. When you do local transfer, Tserver has to rely on PBX callid to assign connId to it. Because your PBX issues new callid on complete Tserver dutifully assigns new connid to it. Check the logs and see if your callid returns to the original callid before the call was transferred.

You’re right! :o ;D

Hi Kim, Thanks for looking at this.
I haven’t checked this forum for a while and since then we have changed our CTI application to deal with this scenario. Pity I didn’t check earlier.

second-call-as-consult = true should take care of it.
And to be on a safe side, match-calls-by = “uui”
follow-calls = true