Genesys CTI User Forum

Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Toz on August 23, 2016, 06:28:50 AM

Title: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 06:28:50 AM
Have a question regarding strange behavior of ExtensionUpdate[‘after-call-divert-destination’,DN] function in genesys. It supposed to divert a call after interaction with agent ends to a different routing point (eg for surcvey, etc), so it does. But strangely after second strategy (survey) ends it does not hang the call, stays with silence. Can you help with that issue? Is it our local problem, or genesys bug? 
The problem is not in survey itself, because I created simple strategy that sets aftercall divert and dials test agent, and after call release by agent it diverts to other strategy that simply plays message and goes to exit block. But call stays online with silence instead of being released.
T-server version is 8.1.102.35
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 07:45:38 AM
You have to release/disconnect it within your routing strategy, the exit block does not do it.
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 09:01:00 AM
Added ReleaseCall[] function before exit block - did not help.
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 09:42:59 AM
Try to use Disconnect function
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 09:52:43 AM
Cant find Disconnect function. Can you help me with that?
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 10:26:33 AM
In log there is a error message
AttributeErrorMessage 'Object not known'
AttributeRouteType 7 (RouteTypeReject)
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 11:12:19 AM
And if I set up a strategy to ReleaseCall[] without setting an aftercalldivert option - Route is OK. Call terminates.
I think aftercalldivert breaks Reject route somehow. Why?
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 11:18:07 AM
I am always using the TRoute function with RouteType equal to "RouteTypeCallDisconnect" and it works as expected.
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 11:30:37 AM
You mean TRoute['','',RouteTypeReject,'']?
Already did that, got error message in log, posted before.

Can anyone assemble lab with 2 strategies on 2 RPs, where one sets ExtensionUpdate['after-call-divert-destination', XXXX], where XXXX is second RP, and second strat just plays some message and either uses TRoute or ReleaseCall[] to release call.
I can't understand why system unable to find route to reject?
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 11:38:44 AM
No, I meant  TRoute['','',RouteTypeCallDisconnect,'']
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 11:41:05 AM
Ok, tried TRoute['','',RouteTypeCallDisconnect,'']

Got:
AttributeErrorCode 1143
AttributeErrorMessage 'Object not known'
AttributeReferenceID 4823057
AttributeReason [14] 00 01 01 00..
'RTR' 886
AttributeRouteType 14 (RouteTypeCallDisconnect)
AttributeOtherDN ''
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 11:54:46 AM
Weird, have to check entire logs, because it working in general cases.
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 12:09:50 PM
Well - found a 'solution'
Created RP with no strategy and TRouted to it. Succesfully drops the call. But that is not right at all.

Can anybody please just repeat my case to check is that a bug or a feature? Is it necessary to open genesys care case for that, or its just our enviromnment broken somehow?

Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 12:11:16 PM
What version of SIP server are you using? I will check the function within my LAB
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 12:15:00 PM
posted before
8.1.102.35
Thanks!
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 12:17:35 PM
Just have tested it and it works as expected, my call flow is:

Initial RP -> Agent -> Agent disconnect the call -> SIP forward the call at the "divert" RP -> Strategy is executed and the call is disconnected/released
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 12:22:37 PM
Well that's quite embarrasing. Thanks for testing!

Don't know where to look for the reason why it is broken, any suggestions?
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 12:30:14 PM
Try to post the SIP logs covering the RequestRouteCall and upcoming events
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 12:55:12 PM
Whited out with ***** some server names


message RequestRouteCall
AttributeThisDN '4901'
AttributeConnID 037a028a72261ff0
AttributeOtherDN ''
AttributeExtensions [53] 00 02 00 00..
'CUSTOMER_ID' 'Environment'
'SWITCH' 'SIPSwitch_*****'
AttributeRouteType 14 (RouteTypeCallDisconnect)
AttributeReason [14] 00 01 01 00..
'RTR' 886
AttributeReferenceID 4829626
15:44:24.597 Int 04543 Interaction message "RequestRouteCall" received from 820 ("URServer_P_*****")
@15:44:24.5970 [ISCC] destination_location substituted by local
@15:44:24.5970 [ISCC] destination_location substituted by local
15:44:24.597  -- created: CRequest@98f69f0 RequestRouteCall-URServer_P_*****[820]/4829626
15:44:24.597: $+TLIB:CTI:Unknown:0:145
15:44:24.597 +++ CIFace::Request +++
  -- new invoke
15:44:24.597 Trc 36210 Client 7(URServer_P_*****): no destination DN in request
  -- thisCall by party
  Parsed: RequestRouteCall
  From: URServer_P_*****[820]/4829626
  Numbers: +<4901> -<none>
  Calls: 5485030:1 none
  Parties: 4901.538e040-5485030:1
          none
  Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0
  -----
  -- validate
  -- state check: ok
  CIFace: Sent CRequest@98f69f0 RequestRouteCall-URServer_P_*****[820]/4829626
  -- created NAData c333620
  FinishRequest CRequest@98f69f0 RequestRouteCall-URServer_P_*****[820]/4829626
  IFace stats: q=0 s=0
  -- complete
  -- NAData ClRq removed
  TNAEmulator::NotifyBackup()
@15:44:24.5970 [BSYNC] Trace: Send to backup (SIPServer_B_*****) [852]:
message EventUserEvent
attr_#1005 0
attr_#1004 597
attr_#1003 1471956264
attr_#1002 2282910
attr_#1001 5
attr_#1000 131072
AttributeAgentWorkMode 0 (Unknown)
AttributeAgentStateReasonUnused 1
AttributeThisDN '4901'
@15:44:24.5970 [BSYNC] Trace: Sent
15:44:24.597: RID:CUUID>4829626:4I61R0DBQD48L514OGJQEPMOPK001G58:
15:44:24.597: IncrementRouteRequestCounter, option 100
15:44:24.597: $*:CTI:SIP:ROUTE_CALL:800282
15:44:24.597 --- CIFace::Request ---
15:44:24.597: $-TLIB:CTI:Unknown:0:769

15:44:24.597: $+SIP:CTI:SERVICE_COMPLETION_FAILURE:4095470:248
15:44:24.597 Trc 36210 Client 7(URServer_P_*****): no destination DN in request
15:44:24.597  -- thisCall by party
@15:44:24.5970 [0] 8.1.102.35 send_to_client: message EventError
(Object not known)
AttributeEventSequenceNumber 0000000000f3c3fd
AttributeTimeinuSecs 597000
AttributeTimeinSecs 1471956264 (15:44:24)
AttributeExtensions [53] 00 02 00 00..
'CUSTOMER_ID' 'Environment'
'SWITCH' 'SIPSwitch_*****'
AttributeErrorCode 1143
AttributeErrorMessage 'Object not known'
AttributeReferenceID 4829626
AttributeReason [14] 00 01 01 00..
'RTR' 886
AttributeRouteType 14 (RouteTypeCallDisconnect)
AttributeOtherDN ''
AttributeConnID 037a028a72261ff0
AttributeThisDN '4901'
AttributeClientID 7
15:44:24.597 Int 04545 Interaction message "EventError" sent to 820 ("URServer_P_*****")
15:44:24.597 Trc 04542 EventError sent to [820] (00000007 URServer_P_***** *****:55502)
15:44:24.597: internal error, RequestRouteCall failed without cleanup
15:44:24.597: $-SIP:CTI:SERVICE_COMPLETION_FAILURE:4095470:284
Title: Re: Strange behaviour of after-call-divert-destination
Post by: cavagnaro on August 23, 2016, 01:01:19 PM
I think your sip server is not aware of that RP. Try a reset

Enviado de meu E6633 usando Tapatalk

Title: Re: Strange behaviour of after-call-divert-destination
Post by: cavagnaro on August 23, 2016, 01:02:25 PM
On the TRoute you put the RP, right?


Enviado de meu E6633 usando Tapatalk

Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 01:10:30 PM
It seems that you have SIP server configured in other way than my LAB, you can post your app options to check them.
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 01:18:24 PM
[quote author=cavagnaro link=topic=9817.msg44491#msg44491 date=1471957345]
On the TRoute you put the RP, right?


Enviado de meu E6633 usando Tapatalk
[/quote]

In this case i just do TRoute['','',RouteTypeCallDisconnect,'']

What RP should I put there? Current strategy RP?
Title: Re: Strange behaviour of after-call-divert-destination
Post by: cavagnaro on August 23, 2016, 01:19:49 PM
I guess something and not blank. Kubig may know better. You are telling URS to route to nothing. Try that other RP

Enviado de meu E6633 usando Tapatalk

Title: Re: Strange behaviour of after-call-divert-destination
Post by: Kubig on August 23, 2016, 01:21:39 PM
In this case, the OtherDN is empty and it is right, because you just want to hangup the call. As I said, in my LAB it works as expected, so I guess some miconfiguration on SIP server application object level
Title: Re: Strange behaviour of after-call-divert-destination
Post by: cavagnaro on August 23, 2016, 01:31:55 PM
:-X Ok, didn't say anything then.
Try a reset of the SIPServer just in case.
Title: Re: Strange behaviour of after-call-divert-destination
Post by: Toz on August 23, 2016, 01:35:43 PM
Ok. I created RP 4902 with simple message. Trouted to it. No message played, but call cleared.
Strange things are happening in logs. It uses our international trunk to route to that destination, and I think gets nothing, thus clearing the call...

message RequestRouteCall
AttributeThisDN '4901'
AttributeConnID 037a028a722620fa
AttributeOtherDN '4902'
AttributeExtensions [53] 00 02 00 00..
'CUSTOMER_ID' 'Environment'
'SWITCH' 'SIPSwitch_*****'
AttributeRouteType 14 (RouteTypeCallDisconnect)
AttributeReason [14] 00 01 01 00..
'RTR' 886
AttributeReferenceID 4833323
16:27:35.994 Int 04543 Interaction message "RequestRouteCall" received from 820 ("URServer_P_*****")
@16:27:35.9940 [ISCC] destination_location substituted by local
@16:27:35.9940 [ISCC] destination_location substituted by local
16:27:35.994  -- created: CRequest@3dd3570 RequestRouteCall-URServer_P_*****[820]/4833323
16:27:35.994: $+TLIB:CTI:Unknown:0:75
16:27:35.994 +++ CIFace::Request +++
  -- new invoke
  -- thisCall by party
  Parsed: RequestRouteCall
  From: URServer_P_*****[820]/4833323
  Numbers: +<4901> +<4902>
  Calls: 4cdc710:1 none
  Parties: 4901.b4ae580-4cdc710:1
          none
  Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0
  -----
  -- validate
  -- state check: ok
  CIFace: Sent CRequest@3dd3570 RequestRouteCall-URServer_P_*****[820]/4833323
  -- created NAData fbb2310
  FinishRequest CRequest@3dd3570 RequestRouteCall-URServer_P_*****[820]/4833323
  IFace stats: q=0 s=0
  -- complete
  -- NAData ClRq removed
  TNAEmulator::NotifyBackup()
@16:27:35.9940 [BSYNC] Trace: Send to backup (SIPServer_B_*****) [852]:
message EventUserEvent
attr_#1005 0
attr_#1004 994
attr_#1003 1471958855
attr_#1002 2294735
attr_#1001 5
attr_#1000 131072
AttributeAgentWorkMode 0 (Unknown)
AttributeAgentStateReasonUnused 1
AttributeThisDN '4901'
@16:27:35.9940 [BSYNC] Trace: Sent
16:27:35.994: RID:CUUID>4833323:4I61R0DBQD48L514OGJQEPMOPK001GDI:
16:27:35.994: IncrementRouteRequestCounter, option 100
16:27:35.994: $*:CTI:SIP:ROUTE_CALL:804305
16:27:35.994 --- CIFace::Request ---
16:27:35.994: $-TLIB:CTI:Unknown:0:198

16:27:35.994: $+SIP:CTI:PARTY_STATE_CHANGED:4117171:121
16:27:35.994: routing dialog '19215842' terminated
16:27:35.994: Adding OtherTrunkName(RU_*****UCPGW01_INTERNATIONAL_Trunk): done
16:27:35.994  -- thisCall by party
16:27:35.994 SetContext: for party 4901.b4ae580-4cdc710:1
16:27:35.994 +++ CIFace::Event +++
  +++ Pre-event +++
    Type EventReleased
    Devices: <4901/4901> <-/74995860011> <-/->
    Calls: 17748505/037a028a722620fa/17748505.4cdc710/c:2/r:6 0/none
    Parties: D4901/4901.b4ae580-4cdc710:1/l:3/r:2/Queued,RtRequest,Destination
    X74995860011/74995860011.b4b1280-4cdc710:1/l:1/r:0/Established,Origination
    none
    Cause: SwitchTerminated/54, Info: 0
    Flags: divert=0 hook=1 postCall=0 active=1 moveAll=1 callType=1 hideOtherPi=0 InternalOther=0
  --- Pre-event ---
  +++ Released +++
    -- route: call disconnect
    SetRouteEnd: party 4901.b4ae580-4cdc710:1, cause SwitchTerminated
@16:27:35.9940 [BSYNC] Trace: Send to backup (SIPServer_B_*****) [852]:
message RequestSetDNInfo
AttributeReason [14] 00 01 01 00..
'RTR' 886
AttributeThisDN '4901'
@16:27:35.9940 [BSYNC] Trace: Sent
@16:27:35.9940 [0] 8.1.102.35 distribute_response: message EventRouteUsed
AttributeEventSequenceNumber 0000000000f40676
AttributeTimeinuSecs 994000
AttributeTimeinSecs 1471958855 (16:27:35)
AttributeExtensions [75] 00 02 00 00..
'OtherTrunkName' '********UCPGW01_INTERNATIONAL_Trunk'
'BusinessCall' 1
AttributeReason [14] 00 01 01 00..
'RTR' 886