troubleshooting basic POTS calls on a router

We get calls fairly regularly from users at sites with router-based VoIP systems (whether UCM Express or distributed UCM, it doesn't matter) saying that callers to their outside lines are getting ring-no-answer behavior.

The first thing I want to do is see if the calls are actually getting to the router. So I access the CLI and do the following:

Router#terminal monitor
Router#debug vpm signal

Then I place a test call to one of their outside lines. If the router just sits there and produces no output, then the problem is almost certainly either in the PSTN, or somebody has unplugged the cable from the FXO port.

If the router produces a bunch of barely comprehensible output, then the line is ringing and you've got further troubleshooting to do. Don't forget to turn off debugging when you're done!

DSCP Confusion

A friend of mine asked me a question the other day that pointed out a common area of confusion with the DiffServ model for IP QoS. He was reading some documentation that recommended setting the DSCP value for voice-signaling packets to 26 instead of 24. He was trying to convert those numbers to Assured Forwarding (AF) values, and came up with 31 and 30, respectively. His question was "Why does the documentation appear to be making the QoS treatment of these packets WORSE?"

The answer is, it's not. 30 is not a valid AF value. With the Assured Forwarding classes, there are three drop precedence values: 1, 2, and 3. Since zero is not a valid drop precedence, 30 is not a valid AF.

The DSCP value of 26 is 001000 in binary. The per-hop-behavior (PHB) value for this is actually not an Assured Forwarding PHB at all, it's a Class Selector value, CS3. The class selector values equate directly to the old IP precedence values, from the days before DiffServ. So DSCP 26 = CS3 = IP precedence 3 = 001000.

Clear as mud? Try the Wikipedia article.

IPv6 at IETF

A few weeks ago at NANOG they turned off IPv4 on the wireless network for a while. Here's a story about the same thing at the much larger IETF meeting.

MBXSuite tool for troubleshooting Unity mailbox issues

I recently learned about a useful tool for troubleshooting Unity/Exchange mailbox issues. It's located in the \CommServer\TechTools folder, and it's called MBXSuite.exe.

To use it:

1) Select the user whose mailbox you want to test with.
2) Select the Unity service account you want to run as--usually UnityMsgStoreSvc.
3) Check "Verbose Diags"
4) Click "Logon Mailbox" and check the Diagnostics pane for errors.