Genesys CTI User Forum
		Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: victor on April 02, 2007, 09:18:02 AM
		
			
			- 
				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:
[size=8pt]	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>		[/size]					
								
  6005 accepts REFER and issues INVITE to 6006								
[size=8pt]	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		[/size]					
This is invite from 6005 to 6006 which should complete the transfer	
[size=8pt]	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][color=red]<-- cannot find by ReferID![/color][/size][/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  :P 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?