[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.