Genesys CTI User Forum

Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: rkd on January 12, 2016, 10:33:17 PM

Title: Do we have OOS setting for Extensions?
Post by: rkd on January 12, 2016, 10:33:17 PM

We faced an issue today with one of the extensions having wrong Contact field.

This value has to be manually updated as the hard phone never registers in SBC. One of the agent tried to log in as a SIP end point with this Hard phone extension and when he logged out, the contact field was put back as '*'. After that all calls started failing to deliver and the extension was not going as unavailable also.

We were seeing the below error when SIP tried to deliver the call to this extension.
message EventUserEvent
attr_#1005 0
attr_#1004 515
attr_#1003 1452620136
attr_#1002 28816482
attr_#1001 5
attr_#1000 131072
AttributeAgentWorkMode 0 (Unknown)
AttributeAgentStateReasonUnused 1
AttributeThisDN '34354'
@11:35:36.5150 [BSYNC] Trace: Sent
11:35:36.515: GetRtPartyId: call 430389, party 1620971
11:35:36.515: GetRtPartyId: routingLinkId not set
11:35:36.515: ResolveCallInfo: set flag DIAL_PLAN_PROCESSING
11:35:36.515: SIPTR(11050820): Begin step 0 - SipTransactionResolveCallInfoByDialPlan(11050821)
11:35:36.515: DialPlan: No dialplan defined for +19728688236.
11:35:36.515: DialPlan: No rule applied, using original destination '88506'.
11:35:36.515: DialPlan: clear flag DIAL_PLAN_PROCESSING
11:35:36.515: Unable to resolve number for DN:88506
11:35:36.515: SIPDM: failed to get registration info for 88506
11:35:36.515: SIPDM: failed to get registration info for 88506
11:35:36.515: Call connect failed with error NOT_REGISTERED, no DialPlan script condition - rejecting call.
11:35:36.515: ERROR: 10000029, DialPlanHandleConnect(scenario, trData,result,*instruction), SipCallManagerDialPlan.cpp,2128
11:35:36.515: SIPTR(11050821): failed
11:35:36.515: SIPTR(11050820): Step 0 - SipTransactionResolveCallInfoByDialPlan(11050821) failed
11:35:36.515: SIPTR(11050820): failed
11:35:36.515: SIPCM: transaction SipScenario failed
11:35:36.515: PI: 00 S[IN]D[+19728688236]C[*D[+19728688236]]P[-]
11:35:36.515: PI: 00 S[QN]D[34354]E[-]
11:35:36.515: OnRequestFailed
  -- thisCall by party
11:35:36.515 Std 36002 Request rejected: error code 71(Invalid Called Dn)



  AttributeErrorMessage 'Invalid Called Dn'

URS is showing

11:35:46.925_A_E_01290275d8e50145 [14:32] <-----------ERROR
11:35:46.925 Std 21003 interaction 01290275d8e50145 routing error 0232 No answer at DN

I would like to know whether we can set any kind of OOS check for the extensions for these kind of scenarios? Please advise.

Title: Re: Do we have OOS setting for Extensions?
Post by: Kubig on January 12, 2016, 11:06:52 PM

This seems like incorrect behaviour on T-Lib level. You can adjust it through activating the "automatic inactive agent logout" feature on SIP server - for more info follow the documentation. Of course, you can configure the active OOS by oos-force/oos-check options - again, follow the documentation.

Title: Re: Do we have OOS setting for Extensions?
Post by: rkd on January 13, 2016, 01:50:01 AM

Thanks Kubig. When i checked the active OOS settings, as per documentation its meant only for other type of DNs and not for extension.

Let me check on the automatic inactive agent logout function.

RKD

Title: Re: Do we have OOS setting for Extensions?
Post by: Kubig on January 13, 2016, 07:36:24 AM

You are right. In any case, you can use the passive OOS check mechanism - related option "recovery-timeout" which is applicable for Extension DN type as well.

Title: Re: Do we have OOS setting for Extensions?
Post by: victor on January 15, 2016, 07:34:11 AM

Kubig -

recovery-timeout enables out-of-service-on-error, which is permanent. Anything less drastic?

Title: Re: Do we have OOS setting for Extensions?
Post by: genesysguru on January 17, 2016, 02:35:39 PM

use-register-for-service-state ?

Title: Re: Do we have OOS setting for Extensions?
Post by: cavagnaro on January 17, 2016, 05:22:48 PM

[quote author=victor link=topic=9305.msg41931#msg41931 date=1452843251]
Kubig -

recovery-timeout enables out-of-service-on-error, which is permanent. Anything less drastic?
[/quote]
Will be until new Register arrives...so why not? If end point can't send new Register then there is truly an issue