Calls returning after GVP treatment are treated as new calls.

[Yogevo]

Hello i am a new participator but an old visitor of these forums and would love some help.

I am currently developing an CB,Position and EWT play application in Composer.
i have encountered a problem where after the treatment(application) ends, i route the call back to the originating RP, and then back to the VQ it was queuing in, but the entered call is treated as a new interaction(and is also gets a new ConnID) and therefor spams the VQ with additional call for each re-entry.

I must be doing something wrong but haven't managed to figure out what exactly.

btw i also tried routing the call to GVP using a few function in IRD as well as a treatment withing the target block.
and i tried to transfer the call from GVP by using the transfer call and Route request blocks.

please help.

[cavagnaro]

Your agents are on same sip server as GVP?
If not, be sure to be using ISCC correctly.
If yes, check your sip server logs to see why a new connid is created

Enviado de meu E6633 usando o Tapatalk

[Yogevo]

First of all thanks for replying.

And secondly regarding your question. yes i believe my Agents are on the same server as GVP, my developing environment has only one active sip server atm.

will check sip server logs to see what might be creating a new ConnID and will update asap.

[cavagnaro]

Also URS logs will help

Enviado de meu E6633 usando o Tapatalk

[Yogevo]

Hi, Under URS logs i can see a RequestSingleStepTransfer coming from GVP. Iv'e attached a part of the URS log here,
I hope it helps(Obviously iv'e change the sensitive info:

request to 65203(TServerSIP_T1/TServerSIP_T1_2) message RequestSingleStepTransfer
   AttributeReferenceID   1646
   AttributeReason   [14] 00 01 01 00..
      'RTR'   110
   AttributeExtensions   [29] 00 01 00 00..
      'CUSTOMER_ID'   'Environment'
   AttributeOtherDN   '705201'
   AttributeConnID   018a02bf338230c5
   AttributeThisDN   '100002'
..sent to BSXXXTEST:3000(fd=620)
    _A_I_018a02bf338230c5 [0E:04] ----------->ARRIVAL
10:33:02.261_I_I_018a02bf338230c5 [09:04] <<<<<<<<<<<<suspend interp(ROUTING), func:Default timers:00000
10:33:02.261 Std 04502 Cannot connect to TServer 'InteractionServer' at host 'BSMM-TEST', port 4420, reason 'unknown'
10:33:02.261_G_I_ [0F:08] SERVER InteractionServer(0000000002829b60 0 1 1) tried: 0 0000000002829b60 0000000002829b60
received from 65203(TServerSIP_T1)BSXXXTEST:3000(fd=) message EventAttachedDataChanged(refid=1645)
10:33:02.354_T_I_018a02bf338230c5 [14:32] EventAttachedDataChanged is received for ts TServerSIP_T1[SIP_T1] (this dn=100002, refid=1645)
received from 65203(TServerSIP_T1)BSXXXTEST:3000(fd=) message EventReleased
   AttributeCallState   0
   AttributeCallType   2
   AttributePropagatedCallType   2
   AttributeCallID   198
   AttributeConnID   018a02bf338230c6
   AttributeCallUUID   '6UCQ2HJOQD117635K5S9AMRSDO000066'
   AttributeUserData   [573] 00 16 00 00..
      'RP_NAME'   'סיוע משפטי'
      'gggAgent_SUM'   'MOJXXX@StatServer_UR.GA--1'
      'var_callinglistname'   'MJXXX'
      'var_cbpriority'   '120'
      'var_chosenservice'   'piq'
      'var_dnis'   '705201'
      'var_lang'   'he-IL'
      'var_origip'   '705201'
      'var_target1'   'MXXX@StatServer_UR.GA'
      'var_ewtthreshold'   '1'
      'var_returntarget'   'sip:705201@'
      'GVP_APP'   '165100'
      'ConnectionID'   '018a02bf338230c6'
      'CALL_SOURCE'   'CB'
      'var_ani'   '0546XXXXXX'
      'var_playewt'   'false'
      'var_playpiq'   'true'
      'var_playcb'   'true'
      'var_piq'   '0'
      'var_ewt'   '10'
      'RTargetAgentGroup'   'MOJXXX'
      'RPVQID'   'LPG4VLN4NP673F6RONECNAHP9O00003E'
   AttributeDNIS   '705201'
   AttributeANI   '0546XXXXXX'
   AttributeThisDN   '100001'
   AttributeThisDNRole   2
   AttributeThisQueue   '705201'
   AttributeOtherDN   '0546XXXXXX'
   AttributeOtherDNRole   1
   AttributeExtensions   [23] 00 01 01 00..
      'BusinessCall'   1
   AttributeTimeinSecs   1526542382 (10:33:02)
   AttributeTimeinuSecs   791000
   AttributeEventSequenceNumber   000000000001b536
10:33:02.791_T_I_018a02bf338230c6 [14:0c] EventReleased is received for ts TServerSIP_T1[SIP_T1] (this dn=100001)
    _T_I_018a02bf338230c6 [14:0a] del DN (TServerSIP_T1[SIP_T1] 100001 00000000028cfd90) controlled=0 calluuid=1 cleanup=0(ref.id=0)
10:33:02.791_M_I_018a02bf338230c6 [17:11] VQ 00000000029750b0 first available call: none, reason=(0)hold
    _T_W_018a02bf338230c6 [14:0a] there is no DNs for call, selfdestruction(15)



You can see the ConnID is changing mid log


I am also getting this error in logs:

received from 65203(TServerSIP_T1)BSXXXTEST:3000(fd=) message EventError
   (Call has disconnected)
   AttributeClientID   28599
   AttributeThisDN   '100001'
   AttributeConnID   018a02bf338230ce
   AttributeOtherDN   '705201'
   AttributeExtensions   [29] 00 01 00 00..
      'CUSTOMER_ID'   'Environment'
   AttributeReason   [14] 00 01 01 00..
      'RTR'   110
   AttributeReferenceID   1746
   AttributeErrorMessage   'device disconnected'
   AttributeErrorCode   237
   AttributeTimeinSecs   1526547398 (11:56:38)
   AttributeTimeinuSecs   964000
   AttributeEventSequenceNumber   000000000001bf10
11:56:38.964_T_E_ [14:0c] EventError is received for ts TServerSIP_T1[SIP_T1] - device disconnected
11:56:38.964_A_E_018a02bf338230ce [14:32] <-----------ERROR
11:56:38.964 Std 21003 interaction 018a02bf338230ce routing error 0237 device disconnected
    _T_W_018a02bf338230ce [0E:0f] emergency: delete call due to this error
11:56:38.964_T_I_018a02bf338230ce [14:02] sending event 58 for vq VQ_MOJXXX (39 0 1 1526387137 157 5)

[Yogevo]

Can anyone please help, this issue is a major road block for a much greater project. i will supply any info i can.

Thanks 

[cavagnaro]

Ok so check TServer logs to seee why it sent such error.


Enviado de meu E6633 usando o Tapatalk

[Yogevo]

This is all i could find in TServer_Sip logs:

@10:33:22.4470

• 8.1.101.53 send_to_client: message EventError

   (Call has disconnected)
   AttributeEventSequenceNumber   000000000001b546
   AttributeTimeinuSecs   447000
   AttributeTimeinSecs   1526542402 (10:33:22)
   AttributeErrorCode   237
   AttributeErrorMessage   'device disconnected'
   AttributeReferenceID   1646
   AttributeReason   [14] 00 01 01 00..
      'RTR'   110
   AttributeExtensions   [29] 00 01 00 00..
      'CUSTOMER_ID'   'Environment'
   AttributeOtherDN   '705201'
   AttributeConnID   018a02bf338230c5
   AttributeThisDN   '100002'
   AttributeClientID   28599
10:33:22.447 Int 04545 Interaction message "EventError" sent to 708 ("URS")
10:33:22.447 Trc 04542 EventError sent to [708] (00006fb7 URS 10.19.110.100:53220)
   -- deleted: CRequest@36a50e0 RequestSingleStepTransfer-URS[708]/1646
10:33:22.447: ModifyForRelease: TReleaseCall in conference, X-Genesys-Orig set to 705201
10:33:22.447: SIPTR(2957): canceled
10:33:22.447: SIPTR(2955): Step 1 - SipTransactionSingleStepTransfer(2957) canceled because of 'release'
10:33:22.447 SIPCONN(0546XXXXXX): operation 1, not deleted timer removed
10:33:22.447: SIPTR(2955): canceled
10:33:22.447: SIPCM: transaction SipScenario canceled because of release
10:33:22.447: SD: none
10:33:22.447 SIPCONN(100002): ClrMediaPeer
10:33:22.447 SIPCONN(0546XXXXXX): ClrMediaPeer
10:33:22.447 SIPCONN(0546XXXXXX): CheckUpdateTransferStatus: no original dialog
10:33:22.447 SIPCONN(100002): set monitor 0000000003a21db0, 0000000000000000
10:33:22.447 SIPCONN(100002): state e:1,p:3,s:0,c:0,rc:0,m:0
10:33:22.447: SipDialog: ClearCall(phone=0,state=7)
10:33:22.447: SipDialog::Terminate(state=7,reason=0)
10:33:22.447: SIPDLG[574]: register TRN[598764]
10:33:22.447: Sending  [0,UDP] 513 bytes to 10.19.110.101:5060 >>>>>
BYE sip:CTIConnector@10.19.110.101:5080 SIP/2.0
From: sip:0546XXXXXX@10.19.50.101:5060;tag=327A3F93-E929-44BB-9359-71599D2AEB2A-94589
To: <sip:705201@10.19.110.100:5060>;tag=B03239F4-7FB9-4C40-15A0-8E0727BC27EB
Call-ID: 4EA2E04E-98E2-4CA4-B878-187D79E21D88-94380@10.19.110.100
CSeq: 2 BYE
Content-Length: 0
Via: SIP/2.0/UDP 10.19.110.100:5060;branch=z9hG4bK5D1A101B-CCCE-4743-B40C-7043B5C25EA2-4146
Max-Forwards: 69
Route: <sip:000000000B639020@10.19.110.101:5060;lr;gvp.rm.datanodes=1;idtag=000001F2>



I cant attach all log file if need be :/

[cavagnaro]

There is a release
Which kind of Transfer is your app doing?


Enviado de meu E6633 usando o Tapatalk

[Yogevo]

I'm using the transfer block in composer with these settings:

Connect Timeout: 16
Connect When: Immediate
Destination: sip:705201@        -------> this is also the originating RP where the target VQ is.
Max Call Duration:0
Transfer Type:blind

Variables and Aai are empty.

[hsujdik]

As far as I know, URS doesn't allow the same call to be routing 2 times at once on the same routing point. I read it somewhere here in the forum

[cavagnaro]

There is a setting for TServer to allow that. It is a security feature. Yeah that could be too.


Enviado de meu E6633 usando o Tapatalk

[Yogevo]

@cavagnaro what is the name of the setting?


@hsujdik The problem i am having is a call is routed from a strategy to an IVR application to offer callback collect digits etc..
and once the application is done it routs the call back to the originating RP where the strategy above is loaded.
and URS or some other component treats the routed call from GVP as a new one.

Thus creating a new AttributeConnID and obviously multiple calls on the one VQ, when there is only one live call.

[Kubig]

I do not understand why you use transfer within IVR if this can be achieved easily via URS centric mode. However, try to post entire T-Server log to find out the root-cause of the release.

[terry]

- Is it URS who send call back to original RP? If yes, how it knows when to do it?
- Referred in URS log SingleTransfer is part of default routing (executed by URS function Default).
  Probably check strategy/solution in this regards - after default routing strategy cannot be continued anyway.