Losing control of a CDN

[David]

Hi all,

I use TServer 6.1 for Symposium.
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

Could you help me

Thanks David

[Ralph]

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?

[Vic]

David,

can you please:

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?

What environment are you running in?

[VIP]

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).

[KL]

I did not know that.
What other defaults like that are there? Is there a simple bried descriptions for them?

[David]

Hi Vic,

Thanks for your help

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

My environment is TServer 6.1 for Symposium

[bogdan]

Hello,

Just today I had the same problem with Tserver7.6, the solution was to recreated pe CDN from PBX:
[code]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[/code]

Best Regards,
Bogdan

[nishantank]

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.

Hope that helps.

Nishant