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!

MiCC - IVR Ports / IVR Hunt Group Setup

Status
Not open for further replies.

Lee_C

Technical User
Jul 19, 2018
3
GB
Ok here is the scenario
MiVB 9
MiCC 9

2 trunk gateways
1 enterprise server
1 remote server
16 ports
16 redundant ports

How would you configure this?

Currently have 16 ports on trunk gateway 1, which are secondary to trunk gateway 2. These use enterprise server.

Also have 16 ports on trunk gateway 2, which are secondary to trunk gateway 1. These use the remote server.

All 32 ports in a hunt group, interleaved.

Calls bounce around the group of ports and route perfectly fine...

However, the reporting is not working. Call 1 is reported, call 2 is not... and so on.
 
have you added all the MIvb's as media servers
do all of them have SMDR enabled
does xnet cos have SMDR internal enabled

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

 
"Currently have 16 ports on trunk gateway 1, which are secondary to trunk gateway 2. These use enterprise server.
Also have 16 ports on trunk gateway 2, which are secondary to trunk gateway 1. These use the remote server."


We only have one of these , pretty sure mitel recommended that all ports were programmed on the same pabx (gateway1) and then made resilient to Gateway2
then 1/2 were associated with the IVR on the enterprise server ( primary) and the others on the Remote IVR

what part of the reporting isnt working ?
what does the IVR routing do with the calls
can you see smdr for the calls on the data link ( or within raw SMDR)

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

 
To be more generic than Bill, what is not working.
In my support experience, the hardest part of troubleshooting always is to define the problem.
This case, for example, has the following complications:
Two IVR servers but one reporting: does any data from the remote get into any reporting or not
Two routing systems (the IVR connects via stations and not trunks):
- verify if calls actually go through all 32 ports
- information to IVR ports is NOT SMDR, but it is a good place to start checking
- MiCC include a MiTai browser that allows you to monitor the port activity from the MiCC server itself
- clustered MiVB systems add the CeID digits in front of DNs to identify exact routing information, might be confusing - make sure you considered resiliency and identified the active routing path
- calls to your backup 16 ports could be passing through the IP trunks to the secondary gateway during normal operation that would result in totally different SMDR and routing information (see point above)

Agree with Bill in suggesting to review your resiliency/redundancy configuration.
For your consideration:
If you have two trunk gateways but one is a resilient backup, then use it for resiliency only.
Same for the Remote IVR. If that is only a backup for the Primary, then avoid routing split traffic on it.
It might seem logical to use backup systems with other backup systems, but the data flow does not always follow that logic.
- SMDR , just as PMS for that matter, is not resilient and neither is MiTai signaling

Might sound archaic, but get a pen and a piece of paper to start.
Have fun!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top