Dear all,
ever since I have decided to use RTC for implementation of SIP for Genesys softphone, I have been plagued by one problem after another. After overcoming all of them, I am yet again dumbfounded by the latest revelation that Genesys needs “Replaces” keyword to successfully complete a supervised call transfer. And as luck would have it, RTC does not allow people to issue “Replaces”.
Here is a log of me dialing 6003 from 6005 and then having 6003 complete the transfer to 6006:
sipcs: 11:33:03.176 Sending [368,UDP] 661 bytes to 172.30.0.170:10384 >>>>>
REFER sip:172.30.0.170:10384 SIP/2.0
To: "Ali" <sip:6005@172.30.0.222:5060>;tag=8aab2a8ee961403a85a7029506502aaa;epid=6387ea970b
Call-ID: 40bdad23911543aa8c1f61f762d570d6@172.30.0.170
CSeq: 2 REFER
Content-Length: 0
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK23A65995-735A-4F29-AC36-BFC49E62D08C-2627 Contact: <sip:172.30.0.222:5060>
Refer-To: <sip:6006@172.30.0.222:5060?Replaces=DDD8BC6C-86E6-4B67-89B7-F5D0BD8A0C3E-896%40172.30.0.222%3Bto-tag%3Dd30e1a15%3Bfrom-tag%3D15cfabcc75d64697b2cde1704f544759> Referred-By: <sip:172.30.0.222:5060;genesysid=0090016fcd45b0cb>
6005 accepts REFER and issues INVITE to 6006
sipcs: 11:33:03.176 dispatchDE: dlg[1268]
sipcs: UK-PEM:HANDLE(CONNECTED):<<EVENT(28)<<DLG[1268]
sipcs: dialog [1268:07@018382f8]: << Event 28 << TRN[3743]
sipcs: CallMatcher: Added match on REF_ID DDD8BC6C-86E6-4B67-89B7-F5D0BD8A0C3E-896@172.30.0.222/d30e1a15/15cfabcc75d64697b2cde1704f544759
sipcs: SIPSStepXfer[0x01c2e900] started
Response (0): for CRequest@01C2E900 RequestCompleteTransfer-CTISIP_Client[324]/7
– RegisterQueue: CRequest@01C2E900 RequestCompleteTransfer-CTISIP_Client[324]/7 01C282D0 21073[0,1]
11:33:03.176 — CIFace::Request —
sipcs: 11:33:03.176 Received [368,UDP] 394 bytes from 172.30.0.170:1156 <<<<<
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK23A65995-735A-4F29-AC36-BFC49E62D08C-2627
From: <sip:6003@172.30.0.222>;tag=7C6E7540-110B-4A56-A6E7-32452E672A8E-684
To: "Ali" <sip:6005@172.30.0.222:5060>;tag=8aab2a8ee961403a85a7029506502aaa;epid=6387ea970b
Call-ID: 40bdad23911543aa8c1f61f762d570d6@172.30.0.170
CSeq: 2 REFER
User-Agent: RTC/1.2
Content-Length: 0
sipcs: 11:33:03.176 dispatchDE: dlg[1268]
sipcs: UK-PEM:HANDLE(CONNECTED):<<EVENT(32)<<DLG[1268]
sipcs: dialog [1268:07@018382f8]: << Event 32 << TRN[3743]
sipcs: 11:33:03.223 Received [368,UDP] 431 bytes from 172.30.0.170:1156 <<<<<
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 172.30.0.222:5060;branch=z9hG4bK23A65995-735A-4F29-AC36-BFC49E62D08C-2627
From: <sip:6003@172.30.0.222>;tag=7C6E7540-110B-4A56-A6E7-32452E672A8E-684
To: "Ali" <sip:6005@172.30.0.222:5060>;tag=8aab2a8ee961403a85a7029506502aaa;epid=6387ea970b
Call-ID: 40bdad23911543aa8c1f61f762d570d6@172.30.0.170
CSeq: 2 REFER
Contact: <sip:172.30.0.170:10384>
User-Agent: RTC/1.2
Content-Length: 0
sipcs: 11:33:03.223 dispatchDE: dlg[1268]
sipcs: UK-PEM:HANDLE(CONNECTED):<<EVENT(33)<<DLG[1268]
sipcs: dialog [1268:07@018382f8]: << Event 33 << TRN[3743]
sipcs: [+#]unregister_trx_reactor [3743]
sipcs: 11:33:03.410 Received [368,UDP] 370 bytes from 172.30.0.170:1156 <<<<<
BYE sip:172.30.0.222:5060 SIP/2.0
Via: SIP/2.0/UDP 172.30.0.170:10384
Max-Forwards: 70
From: "Ali" <sip:6005@172.30.0.222:5060>;tag=8aab2a8ee961403a85a7029506502aaa;epid=6387ea970b
To: <sip:6003@172.30.0.222>;tag=7C6E7540-110B-4A56-A6E7-32452E672A8E-684
Call-ID: 40bdad23911543aa8c1f61f762d570d6@172.30.0.170
CSeq: 2 BYE
User-Agent: RTC/1.2
Content-Length: 0
sipcs: 11:33:03.410 dispatchDE: dlg[1268]
sipcs: [+#] Referrer terminates main call leg; retaining referee
sipcs: party [6005@01bf7c80:1] -dlg [1268@18382f8]
sipcs: dialog [1268:08@018382f8] : -party [6005@01bf7c80] +party [@00000000]
sipcs: m_HADlgID << 0
sipcs: PARTY[6005]:>> SYNC-STATE >>
sipcs: 11:33:03.410 Sending [368,UDP] 368 bytes to 172.30.0.170:10384 >>>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.30.0.170:10384;received=172.30.0.170
From: "Ali" <sip:6005@172.30.0.222:5060>;tag=8aab2a8ee961403a85a7029506502aaa;epid=6387ea970b
To: <sip:6003@172.30.0.222>;tag=7C6E7540-110B-4A56-A6E7-32452E672A8E-684
Call-ID: 40bdad23911543aa8c1f61f762d570d6@172.30.0.170
CSeq: 2 BYE
Contact: <sip:172.30.0.222:5060>
Content-Length: 0
sipcs: 11:33:03.410 dispatchDE: dlg[1268]
sipcs: dialog [1268:09@018382f8]: << Event 57 << TRN[3744]
sipcs: dialog [1268:09@018382f8]: << Event 43 << TRN[3744]
sipcs: 11:33:03.410 dispatchDE: dlg[1268]
sipcs: dialog [1268:10@018382f8]: << Event 58 << TRN[0]
sipcs: 11:33:03.457 Received [368,UDP] 1054 bytes from 172.30.0.170:1156 <<<<<
INVITE sip:6006@172.30.0.222:5060 SIP/2.0
Via: SIP/2.0/UDP 172.30.0.170:10384
This is invite from 6005 to 6006 which should complete the transfer
From: "Ali" <sip:6005@172.30.0.222:5060>;tag=5260f10787104d5e83c4cae3768cd258;epid=6387ea970b
To: <sip:6006@172.30.0.222>
Call-ID: 404c4dcc18d84d64b5952cffec2f2680@172.30.0.170
CSeq: 1 INVITE
Contact: <sip:172.30.0.170:10384>
User-Agent: RTC/1.2
Referred-By: sip:172.30.0.222:5060;genesysid=0090016fcd45b0cb
Refer-Cookie: sip:172.30.0.222:5060;genesysid=0090016fcd45b0cb
Content-Type: application/sdp
Content-Length: 523
v=0
o=- 0 0 IN IP4 172.30.0.170
s=session
c=IN IP4 172.30.0.170
b=CT:1000
t=0 0
m=audio 14484 RTP/AVP 97 111 112 6 0 8 4 5 3 101
k=base64:GDrsutLw/tEm+Fh/idnsz953e7m5UdFKQN3IUl/Qb2I
a=rtpmap:97 red/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:6 DVI4/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=encryption:optional
sipcs: +dialog [0:00@018422c8]
sipcs: +dialog [0:00@01853af0]
sipcs: CInf[0x01854cf8]
sipcs: CallMatcher::MatchByDN: Not found:6005/6006 [b][size=10pt]<-- cannot find by ReferID![/b]
sipcs: dbg=>ProcessNewLinkedDialogs::1
sipcs: Reg. Info: dn[6005]<=cme[6005] Incoming Invite
sipcs: 11:33:03.457 dispatchDE: dlg[1274]
sipcs: UK-PEM:HANDLE(NON-CONNECTED):<<EVENT(12)<<DLG[1274]
11:33:03.457 +++ CIFace::Event +++
+++ Pre-event +++
Type EventOriginated
Devices: <6005/6005> <6006/6006> <-/->
ANI/DNIS: <6005> <6006>
Flags: divert=0 hook=1 postCall=0 active=1 moveAll=1 callType=1
--- Pre-event ---
+++ Dialing +++
-- internal call originator not found
+++ CIFace::Event +++
+++ Pre-event +++
Type EventInitiated
Devices: <6005/6005> <6006/6006> <-/->
ANI/DNIS: <6005> <6006>
Flags: divert=0 hook=1 postCall=0 active=1 moveAll=1 callType=1
--- Pre-event ---
+++ NewCall +++
-- call is consultation
SetHeld: party 6005.01BF7C80-0090016fcd45b0cb.01840BD0, cause Null [/size]
Now, if you read this far, you have noticed 
that there is a problem with the final invite - TServer mistakes it for a new call. The question is how do tell TServer that this is NOT a new call without the use of “Replaces” keyword.
Any ideas?