3300 ACD Resiliency Rel 4.1

[kwbMitel]

Trying out ACD resiliency for the first time.

I'm stuck on the path. It appears that I need to use a different DN than the one on the primary. Have I missed something or is this the way to go?

Sets Are Resilient
Agent ID's Are resilient
Agent Groups are resilient

Paths on the other hand seem to require manual duplication with alternate DN's.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[Supernova99]

Hi KWB

Yes you have to have different DN's on the resilient controller you need to keep the reporting numbers the same if you are using 6100 and keep the networked agent groups in the path's

It is a long and arduous path to get this right with a lot of testing required.

I would recommend that if you can just change the first digit so that you can keep track

so if primary controller are using 1xxx paths then secondary use 2xxx path's or whatever range you have free

The reason I say this is beacuse it will make it easier to track in 6100
once programmed put the queues in queue groups.
The 6100 reporting method needs to change to reflect reporting against queue groups instead of queues, so that in the event of a failover they are still reporting the activities of the day.

Back to the programming you will need to remove remote directory entries on the secondary controller of the primaries paths and ARS this to the primary
If 4.1+ then they will need to be local DN's
I have just realised whilst wring this that programming local DN's is going to be an issue if the agents are expecting a path name to be displayed with 4.1

You will need to setup a IP trunking loopback and absorb the 1 and insert the 2 via digit mod

Put these routes in a list and then apply this to a 1xxx ARS

Then if the primary fails and the call tries to route to 1xxx the 1st choice is OOS and the 2nd choice will be the loopback absorb the 1 and insert the 2 which will result in a calling the 2xxx locally.
(Note when testing a failover it will take a couple of calls to realise that the primary link is down as the system will try to connect to the failed primary and show OOS
Once it has raised an ICP alarm all calls go straight to loopback)

If you have 6160 IQ this process also gets a whole lot worse (I won't post this unless you need assistance with this as well.)



Share what you know - Learn what you don't

 

[kwbMitel]

hmmm Some good info there. Especially on the path routing as that had not occured to me that it might be an issue.

I'm not sure your method is required however. A simpler solution occurs to me.

I believe you can leave the path in the remote directory form. Instead of your solution, I would create a specific ARS route list for the path DN. The second choice would be an IP loopback with modified digits to change the DN.
example:

ACD Path = 1000 (on system 1)
ACD Path = 2000 (on system 2)
CEID Sys 1 = 101
CEID Sys 2 = 102
ARS for cluster on sys 1 = 102 + 4 digits = Route to sys 2
ARS for cluster on sys 2 = 101 + 4 digits = route to sys 1
Also on system 2 I enter 1011000 + zero digits = Route list 1st choice sys 1, 2nd loopback with mod digits (1011000 changed to 1022000)

Under normal conditions the call to 1000 will route to system 1 and enter the queue.
If the IP trunking is down. The call will follow the 2nd choice and loopback and enter queue 2000.

This seems simpler to me. What do you think?

BTW - Prairiefyre is not a factor for me.



**********************************************
What's most important is that you realise ... There is no spoon.

 

[Supernova99]

Yes I think that would be better now we have 4.1

I think the ARS digits you mention need to be a bit tighter perhaps?
e.g. 1011 + 3
1012 + 3
but that is just a small point

As I noted in my previous post whilst writing, now we have common data sharing we have got to think more about the local DN in keeping resilient clusters resilient!




Share what you know - Learn what you don't

 

[kwbMitel]

I don't like to limit my systems by being too specific with the ARS digits when it comes to CEID's. I might want to put a 2XXX extension or a 3XXX extension on system 1. If I define 1011 + 3 I'm limited to only digits that start with 1.

My digits to follow always matches my DN length allowing me the greatest flexibility. I sometimes use this to test my IP trunking between systems by initiating a call to a sys1 extension but dial the sys2 CEID first. This causes the call to go out and back from system 2. Very useful for troubleshooting.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[Supernova99]

The reason I added this comment was as an extra, just for the Path routing

So if normally you have 101 +4 for extns it still works with no modifications no alternate loopback

But 1011 + 3 with a route list including the loopback will provide the resiliency for the path's

both can exist in the ARS table however it will only be the path's that have a 2nd choice



Share what you know - Learn what you don't

 

[kwbMitel]

OK, I think you might have missed my ARS entry 1011000 that was specific for the path and routed to a list. Your solution would also route any non-resilient dn on system 1 with a leading digit of 1. At least you agree on the principle.

Ideas are forming in my mind regarding using this type of solution to facilitate fax machines that are homed on system 1 that could be converted to alternate machines on system 2. Interesting.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[Bigsin]

Why not using a resilient huntgroup in front of the ACD path's?

For example DDI = 3333

Create a huntgroup 3333. Make it resilient.
At the Primary controller
Set a Rerouting Always(day/night1/night2) to Path 1000 for huntgroup 3333

At the secondary controller:
Set a Rerouting Always (day/night1/night2) to Path 2000 for huntgroup 3333

 

[kwbMitel]

Bigsin - My controllers have redundant links to the PSTN. Under normal conditions with both controllers active, the call can be presented on either system and needs to route appropriately. Your solution would fail if the call was presented to the secondary controller.

My solution will work under normal conditions and in the event of a primary failure.

P.S. I already have the Paths fronted by a phantom DN for the purpose of voicemail integration and lamping. The phantom is already resilient. I had considered your method but the requirement of having the routing programmed differently was enough for me to reject it even without the trunking considerations.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[Bigsin]

You said "Bigsin - My controllers have redundant links to the PSTN. Under normal conditions with both controllers active, the call can be presented on either system and needs to route appropriately. Your solution would fail if the call was presented to the secondary controller."

Why wold it fail?

If the call is presented to 3333 on the secondary controller, the call wil be forwarded to ACD Path 1000 in my example.

I've tested it a few minutes ago with a phone connected to the secondary controller. When calling 3333 the call is presented to the primary controller. I don't see a reason why it would fail with a trunk call on the secondary controller.

 

[kwbMitel]

So I reached the point where I had to duplicate my RAD Greetings. I'm using embedded VM for my RADs. I did not want to rerecord my greetings.

I found the following thread thread1329-1573663 but it was not overly helpful as it only entails how to capture the RAD recording and not how to place it on a different system.

So, using filezilla
Directory = /vmail/d/vm
Files listed include RADXXX.vox where XXX = Rad Greeting number.

Enjoy.



**********************************************
What's most important is that you realise ... There is no spoon.

 

[kwbMitel]

BigSin - RE Why would it fail

At the secondary controller:
Set a Rerouting Always (day/night1/night2) to Path 2000 for huntgroup 3333

If the call is presented to system 2 under normal circumstances it will route to path 2000 on system 2 instead of path 1000 on system 1. If you are finding otherwise, please explain how.


**********************************************
What's most important is that you realise ... There is no spoon.

 

[kwbMitel]

Actually, I just answered my own question. The huntgroup's primary routing is to system 1 and so system 2 does not handle the call unless failover is active.

So it comes down to whether you want to control things with routing or with ARS. Routing is easier but ARS is less likely to be accidently changed. I will always vouch for the method that is less likely to fail even if it requires more work.

I haven't completely thought things thru yet and I may yet have issues with my routing and integration with VM. We'll have to see when I get a chance for a failover test.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[boycey9]

Surely this is far easier than all this loop back.
Path 1 =2000
Path 2 =3000
Speed Call 1000 points to path on relevant controller.ie controller 1 sp call 1000=2000 and on controller 2 sp call 1000=3000.
what ever controller the call comes in on, hits the relevant path.
Both Paths have the same resiliant ACD group attached.
Wont affect reports because as above you are already having to run a group report anyway.
And this also works with 6160

The only draw backs will be that if a controller fails you will lose the calls in the queue hosted on that controller.

 

[Supernova99]

The problem is KWB has trunks live on both controllers so the call will fail routing to 3000 as the agents are not available in the path until they are resilient
Hence need to be smarter at routing the call

Share what you know - Learn what you don't

 

[kwbMitel]

Boycey9 - In your analysis you need to follow the routing thru in both a live environment AND failover. Consider that the call can enter the system thru either system.

Using speedcalls will definitely fail for the reason that a call coming into sys2 in a non-failover state will not route to system 1.

Additionally, my speedcall table is shared and I want to keep it that way.

I do not always look for the easiest way to do things. Many factors determine what solution is prefered.

In this case:
- Will it work on a live system
- Will it work in failover
- Can it be understood by a 3rd party (Supported)
- How subject is it to accidental change (Bad support)



**********************************************
What's most important is that you realise ... There is no spoon.

 

[LoopyLou]

Just my two cents.

What we did was create path 3000 on the one controller and 3001 on the other. Both had the same agent groups and agent ID's. We then used a resilient hunt group that was rerouted to 3000 on PBX A and 3001 on PBX 2. The incoming DID's pointed to the hunt group. We split the PRI's between the two controllers and that way we had survivability. A call could come in on either 3300 and would be sent to the same agents. ACD hotdesk ID's were resilient as well as the phones used and the agent groups.

The single biggest problem with communications is the illusion that it has taken place.

 

[bobcheese]

KbwMitel, what boycey9 is suggesting is how I have set it up in the past the speedcall points to the path on each local controller (1 speedcall for the DID on each controller). As the agent group is resilient and set as the primary AG in the path on the resilient controller as well when a call comes into the secondary controller the call will be offered to the agent group that is currently registered to the primary controller (in normal state)I believe this forms part of the network ACD feature.

 

[kwbMitel]

Bobcheese - understood. I was not certain it would function that way and I have no way to test. (this is being programmed on a system 1400 Km away. That being said, I've already mentioned that my speedcall tables are shared and I want to keep them that way.

Loopylou - Yes, I've already worked out that the resilient hunt group method would work. My misgivings are that it requires my Call routing assignment to be programmed differently and that this is a simple thing to accidently change. This customer maintains their own system and I can easily see them modifying call routing on their own. This is related to a recent posting of mine where it was discovered that the Call routing on the 2 systems were not sync'ing via SDS. It is the customer's and my expectation that the call routing tables match on both systems. By using ARS, eventhough it is more complicated to follow the call flow, it is much more resistant to change.

I'm in the final testing phase (live system) and I will report my results once we do a full failover test.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[bobcheese]

KWBMitel, could you not just edit the SDS settings for System speedcalls so that the majority of the data was shared (a range of numbers) and the speedcalls used for DID translation were kept as 'local only'?

Just a thought.