Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: ademince on August 06, 2010, 01:18:55 AM
-
Dear All,
Our Tserver is closing the client URS connection, complaining about it being too slow? what is too slow? where do we tell the system to wait a bit longer.
I would greatly appreciate if anyone can help.
ps. I couldn't attach the log file some how however here is the part with error.
AttributeTimeinSecs 1281051273 (09:34:33)
AttributeExtensions [137] 00 04 02 00..
'GCTI_GLOB_CID' bin: A1 4A 5B 4C.. (len=8)
'GCTI_SUPERVISED_TRANSFER' 0
'GCTI_NAT_INDICATIONTYPE' 'Public:National'
'GCTI_NAT_INDICATION' '362712212'
AttributeNetworkCallID a14a5b4c0c510200
AttributeCustomerID 'Resources'
AttributeANI '362712212'
AttributeDNIS '4584'
AttributeCallUUID 'P1VNV5VMOT6EJ1F0H55DQ08TL8002161'
AttributeConnID
008201d51aa6fdf8
AttributeCallID 20748
AttributeCallType 2
AttributeCallState 23
AttributeThisQueue '4584'
AttributeThisTrunk 262404
AttributeThisDNRole 2
AttributeThisDN
'4584'
AttributeOtherTrunk 262404
AttributeOtherDNRole 1
AttributeOtherDN '362712212'
@09:34:33.3190 [ISCC] Translate: '362712212' -> ''; result 1 ()
@09:34:33.3190 [ISCC] Party object is removed:
p:0000000000000000,00000000 n::
09:34:33.319 Int 04544 Interaction message "EventRouteUsed" generated
09:34:33.319
Trc 04542 EventRouteUsed sent to [1280] (0000327c URS 172.21.135.40:2426)
09:34:33.319 Trc 04542 EventRouteUsed sent
to [736] (0000001b StatServer_URS 172.21.135.40:3968)
09:34:33.319 Trc 04542 EventRouteUsed sent to [628] (00000011
StatServer_Hist 172.21.135.41:4263)
09:34:33.319 Trc 04542 EventRouteUsed sent to [640] (00000012
StatServer_Realtime 172.21.135.40:3972)
09:34:33.319 Trc 04542 EventRouteUsed sent to [604] (0000000f WFM_StatServer
172.21.135.42:4304)
09:34:33.319 Trc 04542 EventRouteUsed sent to [544] (0000000a URS_HA 172.20.105.54:3425)
09:34:33.319 Trc 04542 EventRouteUsed sent to [568] (0000000c StatServer_Realtime_HA 172.20.105.54:3427)
09:34:33.319 Trc 04542 EventRouteUsed sent to [556] (0000000b StatServer_URS_HA 172.20.105.54:3426)
09:34:33.319 Trc
04542 EventRouteUsed sent to [496] (00000007 StatServer_Hist_HA 172.20.105.52:1424)
09:34:33.319 Trc 04542
EventRouteUsed sent to [532] (00000009 WFM_StatServer_Bak 172.20.105.53:2787)
09:34:33.319 Trc 04542 EventRouteUsed
sent to [520] (00000008 StatServer_CCP_Melbourne 172.20.105.55:1700)
09:34:33.334 Trc 04542 EventRouteUsed sent to
[1376] (00003182 HGFeeder++ 172.16.16.99:2413)
PartyRQueue::<510c:510c:4584@017E9788>: Additional message is
sent
@09:34:33.3340 [0] 7.6.003.05 distribute_event: message EventDiverted
AttributeEventSequenceNumber
000000000003f67b
AttributeTimeinuSecs 334000
AttributeTimeinSecs 1281051273 (09:34:33)
AttributeOtherDN '362712212'
AttributeOtherDNRole 1
AttributeOtherTrunk 262404
AttributeThisDN '4584'
AttributeThisDNRole 2
AttributeThisTrunk 262404
AttributeThisQueue
'4584'
AttributeCallState 23
AttributeCallType 2
AttributeCallID 20748
AttributeConnID
008201d51aa6fdf8
AttributeCallUUID 'P1VNV5VMOT6EJ1F0H55DQ08TL8002161'
AttributeDNIS '4584'
AttributeANI '362712212'
AttributeCustomerID 'Resources'
AttributeNetworkCallID a14a5b4c0c510200
AttributeExtensions [137] 00 04 02 00..
'GCTI_GLOB_CID' bin: A1 4A 5B 4C.. (len=8)
'GCTI_SUPERVISED_TRANSFER' 0
'GCTI_NAT_INDICATIONTYPE' 'Public:National'
'GCTI_NAT_INDICATION' '362712212'
@09:34:33.3340 [ISCC] Translate: '362712212' -> ''; result 1 ()
@09:34:33.3340
[ISCC] Party object is removed: p:0000000000000000,00000000 n::
09:34:33.334 Int 04544 Interaction message
"EventDiverted" generated
09:34:33.334 Trc 04542 EventDiverted sent to [1280] (0000327c URS 172.21.135.40:2426)
09:34:33.334 Trc 04542 EventDiverted sent to [736] (0000001b StatServer_URS 172.21.135.40:3968)
09:34:33.334 Trc
04542 EventDiverted sent to [628] (00000011 StatServer_Hist 172.21.135.41:4263)
09:34:33.334 Trc 04542 EventDiverted
sent to [640] (00000012 StatServer_Realtime 172.21.135.40:3972)
09:34:33.334 Trc 04542 EventDiverted sent to [604]
(0000000f WFM_StatServer 172.21.135.42:4304)
09:34:33.334 Trc 04542 EventDiverted sent to [544] (0000000a URS_HA
172.20.105.54:3425)
09:34:33.334 Trc 04542 EventDiverted sent to [568] (0000000c StatServer_Realtime_HA
172.20.105.54:3427)
09:34:33.334 Trc 04542 EventDiverted sent to [556] (0000000b StatServer_URS_HA
172.20.105.54:3426)
09:34:33.334 Trc 04542 EventDiverted sent to [496] (00000007 StatServer_Hist_HA
172.20.105.52:1424)
09:34:33.334 Trc 04542 EventDiverted sent to [532] (00000009 WFM_StatServer_Bak
172.20.105.53:2787)
09:34:33.334 Trc 04542 EventDiverted sent to [520] (00000008 StatServer_CCP_Melbourne
172.20.105.55:1700)
09:34:33.334 Trc 04542 EventDiverted sent to [1376] (00003182 HGFeeder++ 172.16.16.99:2413)
treatmentsClean: removing pending for (510c:510c:4584@017E9788)(0)
treatmentsClean: removing pending for
(510c:510c:4584@017E9788)(1)
PartyRQueue: <510c:510c:4584@017E9788> removed, state = (0-4)
@09:34:33.3340 [BSYNC]
Trace: Send to backup (TServer_Melbourne_HA) [1388]:
message EventUserEvent
AttributeServerRole 0
AttributeUserEvent EventRouteUsed
AttributeThisDN '4584'
AttributeCallID 20748
AttributeConnID
008201d51aa6fdf8
AttributeReserved_2 1793
AttributeCause 26
attr_#1005 a14a5b4c0c510200
@09:34:33.3340 [BSYNC] Trace: Sent
CallList::Delete: call (2:510c:1@01BAA008) to be deleted
@09:34:33.3340 [BSYNC]
Trace: Send to backup (TServer_Melbourne_HA) [1388]:
message EventUserEvent
AttributeServerRole 0
AttributeUserEvent [1011]
AttributeCallID 20748
attr_#1005 a14a5b4c0c510200
attr_#1007 0
@09:34:33.3340 [BSYNC] Trace: Sent
Party::Release: for <510c:510c:362712212@01CA2778/dialling/Forwarded> with
cause (Failed[57])
@09:34:33.3340 [ISCC] Party removed [ssp view]:
@ c:008201d51aa6fdf8,01baa008 @
m:0000000000000000,00000000,0000000000000000 p:1 i:0000510c nw:00000000:a14a5b4c0c510200 t:2
- p:01ca2778 @
c:008201d51aa6fdf8,01baa008 r:1 t:1 s:0 n:362712212
@09:34:33.3340 [ISCC] Party removed:
@
c:008201d51aa6fdf8,01baa008 @ m:0000000000000000,00000000 p:1 i:0000510c nw:a14a5b4c0c510200 t:2
-
p:0000000000000000,01ca2778 @ c:008201d51aa6fdf8,01baa008 r:1 ------ n:362712212:
@09:34:33.3340 [ISCC] Party object
is removed: p:0000000000000000,00000000 n:362712212:
Party::commit::deleted[1]: for
<510c:510c:362712212@01CA2778/released> with cause/rel (0:0)
Party: <510c:510c:362712212@01CA2778> removed, state
= (0-4)
08/06/10@09:34:33.334 --- Rq::RouteEndRequest ---
link (link-tcp) S->H: (0[4 / 1] requests pending)
09:34:33.334 Std 04523 Connection to client URS closed (reason: too slow) on [1280], id=0000327c
@09:34:33.3500
[ISCC] QUERY_MONITOR <URS:0000327c@> destroyed
@09:34:33.3500 [ISCC] Location URS:0000327c@/0 is removed
@09:34:33.3500 [ISCC] Location object URS:0000327c@/0/0 is removed
-AP[139]->-1244 @09:34:33.3500
-Ap[139]-<-1244
@09:34:33.3500
@09:34:33.522 DataFromSwitch 196 bytes
0000-000f: a1 81 c1 02 02 04 15 02-01 15 30 81 b7 55 04 02
|..........0..U..|
0010-001f: 1a f7 00 a0 48 a3 46 30-44 6b 0a 82 02 51 0c 83 |....H.F0Dk...Q..|
0020-002f: 04 0f 85
01 00 63 07 84-05 34 34 32 32 30 61 0b |.....c...44220a.|
0030-003f: 82 09 33 36 32 37 31 32-32 31 32 62 06 84 04 34
|..362712212b...4|
0040-004f: 35 38 34 64 06 84 04 34-35 38 34 6b 0a 82 02 51 |584d...4584k...Q|
0050-005f: 0c 83 04
01 04 01 04 4e-01 02 0a 01 16 7e 65 a0 |.......N.....~e.|
0060-006f: 0f 17 0d 31 30 30 38 30-36 30 39 33 35 32 37 5a
|...100806093527Z|
0070-007f: a1 52 30 0b 06 06 2b 0c-89 36 83 78 02 01 0f 30 |.R0...+..6.x...0|
0080-008f: 18 06 06
2b 0c 89 36 84-00 30 0e 80 0a 30 33 36 |...+..6..0...036|
0090-009f: 32 37 31 32 32 31 32 81-00 30 12 06 06 2b 0c 89
|2712212..0...+..|
00a0-00af: 36 84 09 04 08 a1 4a 5b-4c 0c 51 02 00 30 15 06 |6.....J[L.Q..0..|
00b0-00bf: 06 2b 0c
89 36 84 0b a3-0b 82 09 33 36 32 37 31 |.+..6......36271|
00c0-00c3: 32 32 31 32 -
|2212 |
08/06/10@09:34:33.522 RECEIVED: 196 bytes
aPDU-rose invoke { -- SEQUENCE --
invokeID 1045,
operationValue 21,
argument { -- SEQUENCE --
crossRefIdentifier '021af700'H -- "..÷." --,
eventSpecificInfo callEvent deliveredEvent { -- SEQUENCE --
connection { -- SEQUENCE --
call '510c'H
-- "Q " --,
device dynamicID '0f850100'H -- ".….." --
},
alertingDevice deviceIdentifier
implicitPrivate '3434323230'H -- "44220" --,
callingDevice deviceIdentifier implicitPublic
'333632373132323132'H -- "362712212" --,
calledDevice deviceIdentifier implicitPrivate '34353834'H -- "4584"
--,
lastRedirectionDevice deviceIdentifier implicitPrivate '34353834'H -- "4584" --,
originatingConnection { -- SEQUENCE --
call '510c'H -- "Q " --,
device dynamicID '01040104'H --
"...." --
},
localConnectionInfo 2,
cause 22
},
extensions { -- SEQUENCE --
security
{ -- SEQUENCE --
timeStamp '3130303830363039333532375a'H -- "100806093527Z" --
},
privateData {
-- SEQUENCE/SET OF --
privateData { -- SEQUENCE --
manufacturer {1 3 12 1206 504},
15
},
privateData { -- SEQUENCE --
manufacturer {1 3 12 1206 512},
{ -- SEQUENCE --
callingPartyName '30333632373132323132'H -- "0362712212" --,
alertingPartyName ''H -- "" --
}
},
privateData { -- SEQUENCE --
manufacturer {1 3 12 1206 521},
-
Client too slow generally means that the client is not responding to server requests on time, due usually to network latency. Check the network connection - delay, jitter, blips - and add ADDP if you haven't yet.
Fra
-
Hi Fra,
Our network is very stable as we have other more sensetive apps between the sites with faults and network guys are unable find any fault on their side. We added ADDP with timeouts from 20 seconds to even 300 seconds but still same issue. When TServer closes the URS connection it drops all the waiting calls to default.
Also what does below error mean? as each time it happens, below error comes on TServer Log:
[ISCC] QUERY_MONITOR <URS:0000327c@> destroyed
@09:34:33.3500 [ISCC] Location URS:0000327c@/0 is removed
@09:34:33.3500 [ISCC] Location object URS:0000327c@/0/0 is removed
-
300? That is useless...try 10 in local and 5 in remote
-
[quote author=ademince link=topic=5771.msg25151#msg25151 date=1281104106]
Hi Fra,
Our network is very stable as we have other more sensetive apps between the sites with faults and network guys are unable find any fault on their side. We added ADDP with timeouts from 20 seconds to even 300 seconds but still same issue. When TServer closes the URS connection it drops all the waiting calls to default.
Also what does below error mean? as each time it happens, below error comes on TServer Log:
[ISCC] QUERY_MONITOR <URS:0000327c@> destroyed
@09:34:33.3500 [ISCC] Location URS:0000327c@/0 is removed
@09:34:33.3500 [ISCC] Location object URS:0000327c@/0/0 is removed
[/quote]
Have you got any firewalls in between?
When TServer closes the connection it default routes all calls, obviously, as it's aware it can't get the destination from URS.
The snippet posted is just telling that Tserver is removing the URS from its connections. However, it is not clear to me why it links URS to ISCC...
Fra
-
Cavagnaro,
I have changed setting as per your suggestion however the drop outs are more frequent therefore I have changed back to not using the ADDP at all. The drop outs are less frequent this way.
Fra,
No, there is no firewall between the sites. The URS is located in site A, no issues reported at site A, however the dropouts happen on site B and C. If I promote site B URS to be primary then I have issues at site A and site C and no issues reported on site B. I know that this sounds like a network issue however the network techos as well as the carrier gone thru so much checks but could not find any fault. We even increased our bandwith to be the double the size yet the same drop outs happening. The CPU usage of the servers involved are around 1%, all ping tests are succesfull without any drop of packets etc. We even disabled the virus scan on all servers yet no help...very frustrating.....help...!!!!
-
[quote author=ademince link=topic=5771.msg25162#msg25162 date=1281398011]
Cavagnaro,
I have changed setting as per your suggestion however the drop outs are more frequent therefore I have changed back to not using the ADDP at all. The drop outs are less frequent this way.
[/quote]
Well if that is the case it is a clear indicator that something wrong is going on yourt network. You say that a ping was successful, but a ping of how many bytes? 32? That is nothing. Try to do a continous ping with 1024 bytes (-l 1024) and see how this behaves. You can have 3Gb of bandwidth but without QoS is almost the same as there must be a point on your network that will not handle such speed...
-
Ademince,
Well, the network guys always tend to blame others before they admit that the problem really could be in network. So you have to come with real proof in order to make them really do something with it. Therefore I would not put a big relevance what they are actually saying.
Check your SCS logs whether there are no intermittent and short lasting host disconnections reported.
Secondly what you can check is to try transfer big files (50MB) between affected hosts and check transfer speed.
And the last step is to install Wire-shark on both host and monitor the network traffic.
Additionally you can try to run URS on the same host as TServer in order to prove functionality without having network in the picture .
Good luck.
E.