Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Alert DN is invalid for resilient ACD failover

Status
Not open for further replies.

AndrewTech

Technical User
Oct 6, 2017
26
0
0
US
Working on setting up resilient failover from my main MCD to a virtual controller. My ACD skill group has alert DN numbers that are currently programmed as analog extensions. I know i have to convert them somehow to get the second element to sync without SDS errors but i'm not quite sure how to best accomplish this. I don't want to reprogram the alert DN's as IP phones if i don't have to. Trying to save licensing.
 
Normally an alert DN is a key on the phone.

What is the reason/purpose of using an analog station?

**********************************************
What's most important is that you realise ... There is no spoon.
 
That is how it was programmed years ago and nobody changed it. We are going from half digital, half IP system to a full IP setup.
 
an alert DN has a lot of functionality when programmed as a key on a phone over and above the alert
[ul]
[li]Queue Atatus - key will be lit, flash or flash quickly depending on threshold programming[/li]
[li]Queued Calls - quantity of queued calls[/li]
[li]Agents avail - will display how many agents and how many idle agents[/li]
[li]Longest waiting call - duration of longest waiting call[/li]
[/ul]

If programmed on a key, you will not have issues with resiliency either.

**********************************************
What's most important is that you realise ... There is no spoon.
 
So the best way to handle this issue is to delete the analog extension and reprogram the DN number as a key on their phone? without convert the analog extension to an IP extension?
 
what would you hope to achieve by converting the DN to IP?

Really, I'm honestly asking, what purpose does having the alert associated directly with any phone serve?

Give me one thing it does programmed that way.


**********************************************
What's most important is that you realise ... There is no spoon.
 
we program ours on a trusted device (no license)and then repeat the key on real phones as per KWb's suggestion

seems stupid to have it on any real device make the trusted device resilient and bobs your uncle

If I never did anything I'd never done before , I'd never do anything.....

 
Ok, Billz66

So programming it against a station, you then make key appearances of that station to achieve the same purpose as programming the key directly.

If true, why bother with the station at all?

**********************************************
What's most important is that you realise ... There is no spoon.
 
We ended up redoing the alerts simply as buttons on the phones.

The dn's function as Alert numbers for our ACD groups. I guess in earlier software versions, they had to be programmed as an actual extension number in order to be recognized. BUt since our software upgrade on the MCD< we were able to reprogram as alert group buttons and delete the extensions. The reasoning for converting to IP extensions was to satisfy the need for resiliency. Can't set a skill group to resilient failover if any of the DN's are analog phones. Same goes for the alert DN. That problam is now resolved and we have all our agent skill groups set to secondary element failover.
 
KWB
We find that some customers want the alerts and some dont so to simplify the importing of multiple skill groups we assign a dummy number to each .
you cant put it on the skill group if it doenst exist so we add a trusted with multiple alerts on it as a repository
- also allows the extension that has the alrt to have its keys cleared and be deleted if required without having to remove the alert from teh skill group

I did a site recently with 100 Q and 100 skill groups , and was able to have them all imported at once and fully configured.

then when some users wanted to see the alerts we just add them as required.



If I never did anything I'd never done before , I'd never do anything.....

 
OK, Thanks Billz66

I follow a different drummer. As only the last agent with the last appearance of the Alert will cause any problems with deletion, I'd rather the system give me a heads up that I'm trying to delete the last instance of something.

I also need to be sure someone doesn't come behind me a f*** it up.

Your method is well organised and standardised and as long as everyone supporting the system knows how it's supposed to work, I can see how that would be a good alternative.

**********************************************
What's most important is that you realise ... There is no spoon.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top