Recently I was called to look at a MiVoice Business installation that experienced an unexpected issue after a network upgrade: calls were suddenly being dropped, and the system showed as unavailable. The culprit? A small but significant change made by the carrier—they mistakenly switched the PRI protocol from DMS100 to NI2 during the upgrade. This mix-up led to a frustrating situation where the carrier initially blamed the Mitel equipment, but a deeper investigation revealed the true cause.
What Happened?
First, let’s break down the issue. The MiVoice Business system was working fine until the carrier performed a network upgrade (Saturday at 3am of course). During this process, the carrier accidentally changed the PRI (Primary Rate Interface) protocol from DMS100 to NI2. These protocols, DMS100 and NI2, are essentially languages that the system and the carrier’s network use to communicate with each other. When both sides aren’t speaking the same language, things can go wrong—and that’s exactly what happened here.
As a result of this protocol mismatch, calls that came into the MiVoice system started being dropped. The Mitel equipment couldn’t understand the incoming messages correctly, so it responded by indicating that the requested channel was unavailable. The carrier, seeing the equipment marked as unavailable, initially pointed the finger at the Mitel system, assuming it was at fault.
The Clues: What the Logs Revealed
To get to the bottom of this issue, a Layer 2/Layer 3 (L2L3) trace was taken—a technical tool that captures the communication happening between the system and the network. Here’s what the trace showed when a call came in:
2024-08-19 11:43:58 Link 1 - To Mitel - HLen 4, ILen 66, IType 6
SAPI 0 TEI 0 C/R 1 P/F 0 NR 77 NS 11 INFO Orig PD=0x8 CR=0x0c7 SETUP(0x5)This is the “setup” message, which essentially means the network was trying to establish a call. However, a bit later, the Mitel system responded with:
2024-08-19 11:43:58 Link 1 - From Mitel - HLen 4, ILen 9, IType 5
SAPI 0 TEI 0 C/R 0 P/F 0 NR 12 NS 77 INFO Dest PD=0x8 CR=0x0c7 RELEASE COM(0x5a)
This response is the “release” message, indicating that the system was dropping the call. The critical part of this message is the “Cause code: requested circuit/channel unavailable.” This means that the system couldn’t find the appropriate channel to complete the call—because the system and network weren’t on the same page, protocol-wise.
Understanding the Problem: Protocol Mismatch
So why did this happen? The MiVoice system was set up to use the DMS100 protocol, but after the carrier switched to NI2, the messages it sent didn’t match what the Mitel system was expecting. Think of it like trying to read a book written in a different language—you might get some parts, but not enough to make sense of the whole thing. The result was that the system couldn’t properly process incoming calls, leading to dropped calls and unavailable channels.
The Fix: Getting Back on Track
Once the issue was identified, the fix was straightforward: the carrier reverted the protocol back to DMS100, the protocol that the MiVoice system was set up to use. With both the system and the network speaking the same language again, calls started going through as they should, and the issue was resolved.
Lessons Learned: Why Protocol Matters
This case highlights a crucial lesson for anyone managing telecommunications systems: consistency in protocol settings is key. Even small changes can have big impacts, especially when it comes to how different systems communicate.
After any network upgrade, it’s important to verify that all settings—like the PRI protocol—are still correct. If something goes wrong, having detailed logs or traces, like the L2L3 trace used here, can help pinpoint the issue quickly.
By ensuring that both the PBX (Private Branch Exchange) and the carrier’s network are aligned, businesses can avoid the frustration of dropped calls and ensure smooth, reliable communication.