De-acuired in CCM, but still acquired in PBX

[paterson]

Hey everyone,

I have an issue where I can de-acquire a TN/agent on the CCM (Rel 6.0 sus0603), but it stays acquired in the PBX. I have to use LD 48 to de-acquire.

I then re-acquire the same TN with the CCM, which will show properly in the PBX. A second de-acquire at this point will show the TN de-acquired in the PBX.

So, it doesn't work the first attempt, but will the second attempt. Any ideas of why the first de-acquire attempt failed?

_______________________________________________________________

If you did not take enough time to get it right the first time...

What makes you think that you have time to fix it?

 

[Supernn]

Try to upgrade to SU06

 

[Johnthephoneguy]

You can go to ld 48 and de-acquire in the pbx

ld 48

reg= dacr agt (then phone tn)

example:

dacr agt 120 0 4 5

JohnThePhoneGuy

"If I can't fix it, it's not broke!

 

[paterson]

Thanks guys.

But I'm already at SU06(SUS0603) and I already mentioned that I have to use LD 48 to de-acquire.

What I really am trying to determine is why I have to use LD 48 in the PBX to de-acquire when it should be an automatic process.

_______________________________________________________________

If you did not take enough time to get it right the first time...

What makes you think that you have time to fix it?

 

[JJhere]

This happens, we have the same problem and as of right now there is no fix....

 

[dj4020]

If your using Tapi it aquires the set as well and therefore the need to de-aquire in ld 48. TAPI uses the MLink to acquire resources I believe is why you'll still see ASID 16

Look for ACQ AS: TN,AST-DN,AST-POSID

Possible reason for you.

 

[matthew517]

When you make changes to you sets are you doing a change? Or outing the sets and rebuilding them? As well as deleteing the set in CC and then rebuilding them?

I have seen this before and it was due to people not properly changing sets and it causes corruption like this and it will contiune to grow.

If you use the change command to change a key you must deacquire the set then nul the ACD key the MSB key and the nrd key. Then you go back and do a change (not easy change) and put back in those keys and the key you want changed. Then you build the phoneset back in CC and re-acquire it.

 

[mte0910]

1st) If you have CTI, you will see that the set gets acquired by DN and POSID, that has nothing to do with TN. Only the Symposium (yeah I know they changed the name, but I didn't) will acquire by TN. I have never had a problem with the issue talked about here being connected to my CTI acquired DN/POSID.

2nd) I know everyone says you are supposed to out the phone and blah, blah, blah...that said, we deacquire the set (even if it means using LD 48) make our change (ECHG YES) and then re-acquire it. We have about 300-400 sets oer site with seven sites and have not seen the snowballing effect metthew talked about.

I have noticed that most of the time when the deacquire from CCM does not work, it is generally a sign that the Symposium and PBX are out-of-synch with one another. Watch your PBX for CSA errors, watch the Symposium for TFE, TFA, OAM errors. The greater the time since the last reboot, the more I see this.

FIX: When Avaya gets time, maybe they will dig into it

 

[matthew517]

I have no issues deacquiring sets do it the way I discribed which is the nortel ETas method. I have seen it when another tech made a change not a easy chAnge and did not nul the keys. The reason you nul the keys is the PBS makes a marker of each key in a high level that will remain and that is why the sets fail to deacquire and other corruption related issues occurs . In a call pilot class one of the level 3 nortel support guys showed me. And you never do an easy change on ACD sets. If
you do your corrupting your PBX big time.

 

[bajangsa]

OOPS - right you are. Much easier not to change any ACD sets which are acquired one way or another.