Attendant consoles and call park

[TN94z]

So we have a call park range of 100 numbers. The operators use this feature more than any other phone at this location. Once before, the call park DNs became locked up somehow and the operators were unable to park anyone. From what I was told, an ini is all that would resolve the issue. Well, I got a call from one of the operators today stating that when they park calls, the numbers are jumping all around the range instead of just being the next available. She stated this is the same way it acted before they locked up the last time.

My question is, is there any way to stat the call park range to maybe see what is causing the issue? I was not here the last time it happened so I am unaware of the troubleshooting steps that were used to determine the PBX needed an ini. I am trying to maybe stop the issue before the feature becomes unavailable and we must ini again.

 

[TN94z]

And I do understand about the timers and the call returning, but the operators are starting to see DNs that they usually don't see and they are not seeing the park DNs they normally see. No one else in the organization uses call park.

 

[kstaff22]

I have had strange issues over the years with call park-----and at times have been forced to INI to clear. There is no way of tracing or stating the call park dn's to see if they are in use. You could try outing the call park data block in LD 50----or just plan an after hours INI.

 

[TN94z]

Okay. That's about what I figured, but I wanted to confirm before coming to that conclusion. Thanks for the help. If it gets worse, I may out the data block and build it back to see if it clears it.

 

[TN94z]

What's the best practice for removing the call park data block and rebuilding? When I tried, it would not let me because there were active DNs. Do you just have to get lucky enough to catch the system where no one has parked a call?

 

[Firebird Scrambler]

I thought Call Park DN's were all done in LD 50?.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website =

http://somertel.com

 

[TN94z]

They are and that's what I'm trying to remove. But it wouldn't let me because a DN was busy and I was wondering if there was a way around that...

 

[Firebird Scrambler]

Try and reduce the DN's in stages rather than all at once.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website =

http://somertel.com

 

[TN94z]

I have tried every change I can and the system will not allow any of them. I tried, outing the call park data block. I tried changing the range of DNs on the call park data block. I tried disabling call park in LD 15 first. The PBX would give me an error on each of those, so I guess an ini is the only option.


With an ini, does it unregister the wlan handsets? I know calls in progress stay up and calls in queue, park, etc...are dropped. I am just uncertain if the wlan handsets will actually have to re-register. Thanks

 

[Firebird Scrambler]

When making the changes, did you log in at Admin 1 or Admin2 level?.

What error did you get, when you tried to make changes in Call Park. Can you post them here please?.



Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website =

http://somertel.com

linkedin

 

[TN94z]

Admin2.

When I try to out the cpk data block:
REQ out
TYPE cpk
CUST 0
SCH961 Active park DN cannot be deleted.
Try again later.
Severity: Info



If I try to change the cpk DN assignment:
REQ chg
TYPE cpk
CUST 0
CPTM
RECA
SPDN 100 3400
SCH2387 System park DN cannot be deleted if Call Park option is CPA.
Change Call Park option to CPD in LD 15 and try again or new range must
completely cover system park DNs.
Severity: Info



If I try to change the number of DNs in the range:
REQ chg
TYPE cpk
CUST 0
CPTM
RECA
SPDN 75 3300
SCH2387 System park DN cannot be deleted if Call Park option is CPA.
Change Call Park option to CPD in LD 15 and try again or new range must
completely cover system park DNs.
Severity: Info



If I try to disable cpk in LD 15:
REQ: chg
TYPE: ftr

TYPE FTR_DATA
CUST 0
OPT cpd
SCH2386 SCH2386
There are system park DNs.

Severity: Info

 

[Firebird Scrambler]

Print off your DNB and perhaps your TNB to find out if you have any DN conflicts as the error message suggests that 33xx or 34xx exist in your system.

Also print off your CDB as you might have OPT = CPA

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website =

http://somertel.com

linkedin

 

[TN94z]

Opt is CPA, I have already verified that but you can't change it.

The 3300 range was set aside a long time ago for park.
The 3400 was confirmed free before I tried adding it.

I believe the errors are just pointing to the fact that there are call park DNs in the system within that range, which we already knew.

This has happened a couple of times in the past. I believe that some of the call park DNs get busied somehow (or the PBX thinks they're busy) and thus takes away from the count. Then when you try to delete, it won't allow you because the DNs show as busy. We have ini'd in the past, but I was trying to find a way around that this time.

Out of that range of 100 DNs, the operators are now down to getting the same 5 or 6 every time now. And they are in no certain order... This is how we know that they are about to run out. They use them so much, they know how the park numbers should be presented to them. Once they start getting the strange order of numbers, they realize what's about to happen and open a work order.

 

[Firebird Scrambler]

It now sounds as if the next step will be to do a sysload and then try to remove them. I recall that lowering the SCPW in LD 15 requires a sysload and perhaps it is the same although not documented for Call Park DN's.

I can't think of anything else to suggest at this moment in time.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website =

http://somertel.com

linkedin

 

[TN94z]

Thanks for you help. The customer decided she wanted us to ini at lunch yesterday. So we went that route. I am going to check with the operators today and see if that resolved the issue.

 

[TN94z]

Issue seems to be resolved.