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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Add Mivb resilience controller to MiCollab+Mivb cluster
- Thread starter voipneerd
- Start date
Short answer yes
make sure its dimensioned the same with same resources
just add it to the cluster , share data from existing to it
add data to forms that dont share ( system options smdr ars etc)
you will have to manually add teh resiliency to existing config
- can probably do imports though id be careful
If I never did anything I'd never done before , I'd never do anything.....
make sure its dimensioned the same with same resources
just add it to the cluster , share data from existing to it
add data to forms that dont share ( system options smdr ars etc)
you will have to manually add teh resiliency to existing config
- can probably do imports though id be careful
If I never did anything I'd never done before , I'd never do anything.....
Its always been that way with trunk licenses
I agree that its costly
On most of our deployments we are using 50/50 sip trunks with enterprise carrier connections
CARRIER--1/2trunks-- MBG Proxy1 ---1/2trunks-----MIVB1
CARRIER--1/2trunks-- MBG Proxy2 ---1/2trunks-----MIVB2
so if 1 system is down they have 1/2 trunks
when both are operating the trunks are splayed across both controllers
If I never did anything I'd never done before , I'd never do anything.....
I agree that its costly
On most of our deployments we are using 50/50 sip trunks with enterprise carrier connections
CARRIER--1/2trunks-- MBG Proxy1 ---1/2trunks-----MIVB1
CARRIER--1/2trunks-- MBG Proxy2 ---1/2trunks-----MIVB2
so if 1 system is down they have 1/2 trunks
when both are operating the trunks are splayed across both controllers
If I never did anything I'd never done before , I'd never do anything.....
That's interesting!
We do that on the 2 incoming carriers and 2 MBG's, but didn't know it could be used with the second MCD.
Do you program 50% of the phones on each system, or is it only used for routing calls?
We also have MiCC.
And strange behavior:
MiCC is programed to us MCD1 first, and #2 second.
If #1 is down, calls come in via #2.
So, all okay.
In a normal situation, #2 is our resilient unit
And although all ARS configs etc are programed for MCD2 too, we see that calls sometimes -I suppose by mistake within MiCC- are send to MCD2, but do not go to an available agent.
(Ps. This behavior was seen when we upgraded MiCC and MiVB to 9, but due to issues, we had to revert the 2 MCD VM's to the old v8 ones.)
So that said, should MiCC in normal circumstances be able to deliver calls to both systems simultaneously or should all agents/ hotdesk phones connect to MCD1.
sorry for the lengthy text.
We do that on the 2 incoming carriers and 2 MBG's, but didn't know it could be used with the second MCD.
Do you program 50% of the phones on each system, or is it only used for routing calls?
We also have MiCC.
And strange behavior:
MiCC is programed to us MCD1 first, and #2 second.
If #1 is down, calls come in via #2.
So, all okay.
In a normal situation, #2 is our resilient unit
And although all ARS configs etc are programed for MCD2 too, we see that calls sometimes -I suppose by mistake within MiCC- are send to MCD2, but do not go to an available agent.
(Ps. This behavior was seen when we upgraded MiCC and MiVB to 9, but due to issues, we had to revert the 2 MCD VM's to the old v8 ones.)
So that said, should MiCC in normal circumstances be able to deliver calls to both systems simultaneously or should all agents/ hotdesk phones connect to MCD1.
sorry for the lengthy text.
- Status
Similar threads
