Sometimes, it appears that after several hours, I loose the control of a CDN. In that case, this only issue that I have is to restart TServer to take back the control of this CDN
David, could you specify which exact version of SLink and TServer you use? And: Did you turn SLink trace on to compare SLink events with TServer events?
paste the log where CDN is being unregistered? (Is it being unregistered at all?)
How do you know that you lost control of CDN? Is it because your calls start defaulting? How certain are you that the problem is CDN and not something else, like URS’ strategy?
By design, Meridian 1 will revoke control of CDN from application acquired the CDN (TServer) when 10 calls in a row were default routed by Meridian 1. Usually it happens when URS is busy and unable to respond to EventRouteRequest in 4 sec (the default for Meridian1).
You are right, I suppose that I lose control of the CDN, because after a while (certainly after 10 calls using the default route), any calls entering the CDN are using the ACD default route
Just today I had the same problem with Tserver7.6, the solution was to recreated pe CDN from PBX:
received from 70669(buc_tserver_b_760)agnes.crm.orange.intra:3200(fd=) message EventError
(Application has not acquired the CDN)
AttributeErrorMessage 'Application has not acquired the CDN'
AttributeReferenceID 9826
AttributeThisDN '4078'
AttributeConnID 015201d5ef72e6e6
AttributeCallID 18096554
AttributeErrorCode 411
AttributeTimeinSecs 1282127068 (13:24:28)
AttributeTimeinuSecs 444785
AttributeEventSequenceNumber 00000000007ddfb5
David
I have faced this same issue in the past.
In my case, it was the Symposium that was taking back control of the CDN whenever it was restarted. Resolution was to delete the CDN from Symposium and let only Genesys take control.