Genesys CTI User Forum

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

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

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

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. 

[quote author=Genecist link=topic=1731.msg5922#msg5922 date=1158250191]
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:

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

[b]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:[/b]
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:

[b]21106 dials 21107 and they connect:[/b]
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

[b]21106 completes the transfer, and now 21112 is talking to 21107:[/b]
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:

[b]21107 and 21112 are notified by EventPartyChanged that 21106 has left the *new* conn id:[/b]
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.


[/quote]

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.

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.