Jtapi error 122 - DN invalid on switch

[n3vek7]

Hey guys,

After a failure of the sub/primary jtapi link, calls currently handled by agents are working fine and new calls are routed correctly from IVR to agents. However, calls in queue at the moment of the failure, failed to get routed to an agent with a [b]"JTAPI ERROR 122 in call 0, dn 1234: DN invalid on switch"[/b] .

birds eye view of the architecture ; URS Centric - SIPServer -> URS -> PlayApp -> GVP -> SIPServer VQ for queuing -> ISCC from SIPS to TServer CUCM -> Agent Endpoint

[code]
@18:12:08.7820 [**1] 1 38 S 9 'Created thread pool for DN:1234'
@18:12:08.7820 [**1] 1 40 S 9 '(registerAddress) running on 1234'
@18:12:08.7820 [**1] 1 98 S 9 'Found 2 terminals, canǴ decide, returning null. [T0=SEPxyz T1=SEPabc]...'
@18:12:08.7820 [**1] 1 60 S 9 'getRegistrar for 1234: term_name=null addr!=null true'
@18:12:08.7820 [((1] 1 44 ISIS 11 0 '1234' 122 'DN invalid on switch'
@18:12:08.7820 [cm] (process_CCM_TEVENT_ERROR)
@18:12:08.7820 [cm] JTAPI ERROR 122 in call 0, dn 1234:DN invalid on switch
@18:12:08.7820 [gctmi] TMsg [EventError(1234)] distributing to model
@18:12:08.7820 [gctmi] Address [1234,tDN,sOOS,oIDLE,dUND] distributing EventError
@18:12:08.7820 [gctmi] Address [1234,tDN,sOOS,oIDLE,dUND] processError
@18:12:08.7820 [gctmi] Address [1234,tDN,sOOS,oIDLE,dUND] processHardwareError
@18:12:08.7820 [0] 8.1.202.29 distribute_event: message EventHardwareError
AttributeEventSequenceNumber 0000000000004a9e
AttributeTimeinuSecs 782000
AttributeTimeinSecs 1559772728 (18:12:08)
AttributeErrorMessage 'DN invalid on switch'
AttributeErrorCode 122
AttributeThisDN '1234'
@18:12:08.7820 [cm] CcmAddress::processHardwareError for DN: 1234 Message: 'DN invalid on switch'.
[/code]

Does this error talk to you? Knowledge base of Genesys wouldn't show anything.

Thanks.

[Kubig]

Is your T-Server CUCM running in HA mode? If yes, then check whether the registration for DN object 1234 was not keeped on current backup T-Server. I have encountered few times similiar issue on Cisco deployment, where after JTAPI link failure, some DNs stayed registered under backup T-Server on Cisco level

[n3vek7]

Thanks Kubig, I'm looking into this with GCC also, I'll let you guys know what is the root cause once it's found. So far, GCC refers to Cisco.