Category Archives: Uncategorized
- Interdigit Timeout
- DN Length
- Localization and Globalization
- No Device/Line?!
- Addendum: A Delightful End User Experience
Consider this an addendum to the dial plan series. I realized that I didn’t specifically discuss the end goal of the dial plan. The end goal is to make the dial plan, this end user interface to the phone system, easy to use and intuitive. In previous posts I discussed dial pattern context and that context matters when evaluating dialing patterns. E.g. +16515551234 is a local call from Minneapolis, long distance from Texas and international from Germany. This context is somewhat thrown out the window for many end users whose primary phone is their mobile phone. They dial 10-digits (or 11 or E.164) for every call. They aren’t charged separate rates for local or long distance.
Mobile devices and the habits they instill in end users should have an impact on our enterprise dial plan designs. What voice engineer hasn’t heard this in a dial plan design meeting, “I just want users to dial like they do on their cell phone.” Why do managers & executives say this? Because dialing on a cell phone is easy because it’s consistent and is a habit that is ingrained into every end user.
Technical sophistication, complexity, elegance, etc. means nothing if the perfect system you as the voice engineer design is not adopted by end users. The dial plan isn’t the desk phone UI, it’s not the softphone GUI, but is is a huge part of the user experience (UE). My nearly 10 years as a consultant have shown me over and over again that dial plan design influences end user adoption & acceptance.
What should our goal be then when it comes to dial plan design and end user acceptance? Allow users to dial in the way that is natural for them. More specifically, don’t require them to understand the context of the pattern they are dialing. Don’t require them to know whether the number in the next county over requires a 1 or if it should be dialed with 7-digits instead of 10-digits.
Here’s why. A UC system like Cisco’s that provides “browser to boardroom” experiences means that a user might be dialing from their:
- Cisco deskphone manually
- Cisco deskphone via the enterprise directory with numbers formatted per the HR department’s specs
- Cisco deskphone like the 8865 running Proximity to pair an end user’s mobile phone and suck in their mobile phone contacts
- Video endpoint in a conference room, again using Proximity to dial from their mobile phone contacts
- Jabber soft client using click-to-call to dial a number they looked up in their web browser
- Jabber soft client using their Outlook contacts
There is no standard or consistency in the format of these numbers. Asking users to “edit dial” before dialing and not providing the ability to tap or click a name and immediately send the call is not a “delightful” user experience. We want all of these potential scenarios to “just work”.
Cisco’s video endpoint updates over the summer including the DX80, MX700 and Speakertrack60 among others have received plenty of attention. These updates were important enough for John Chambers and Rowan Trollope to put together a great video showcasing how they enhance collaboration. After playing with a DX80 and installing a Speakertrack60 system I have to agree that these are some significant updates to their product line.
Today, though, let’s talk about some big changes coming to the Cisco Collab engineer’s world that aren’t quite as much fun to show off. I’m talking about the new ISR 4000 series, Cisco’s latest update to their branch router lineup. The line of products that are a part of every voice install and upgrade we do.
At first glance I might think this is just another incremental update to the same set of devices we’ve had for the last 10 years. Going back to the ISR G1’s we see that at face value we have largely the same set of models. The 4321 is a 2811 or 2911. The 4351 a 2951 replacement. And the 4431 bumps up to two power supplies just like the 3825 and 3925 before it. But there are some significant differences with these new ISR 4000s.
- NIM or Network Interface Module. This is the HWIC replacement. It is not backwards compatible and is a completely new form factor. I know there are some folks out there groaning about having to buy all new modules, but for us in the voice world this new NIM solves a major problem for us. The voice module NIMs have a PVDM slot on the NIM itself, enabled by a PVDM4 that also comes in a new form factor. This allowed Cisco’s engineers to create a separate clocking domain per NIM. With the EOS dates for NM-HDV modules earlier this year if a customer needed multiple clocking domains (e.g. They needed to support a local PRI from carrier A and an LD PRI from carrier B) they would have to buy a second router! Quite expensive for one PRI port. Now we can have up to 3 clocking domains in a single chassis on even the 4321. One other welcome update here is support for online insertion & removal (aka hot swap).
- PVDM4. Cisco launches their 4th generation DSP. As mentioned it comes in a new form factor th
at is not backwards compatible with the PVDM2 or PVDM3 that preceded it. Cisco has not turned on video conferencing as the PVDM3 did although the hardware can support it, but let’s be honest with ourselves; the PVDM3 was a really terrible video bridge that was quite expensive for the poor performance and user experience provided. It’s clear that products like Cisco’s TelePresence Server and Conductor are the future here.
- The other big change for us voice folks is the move away from “IOS Classic” to IOS XE. Outside of some corner case very large projects involving CUBE on an ASR a typical voice engineer has probably never run across IOS XE. Here’s a great article that sums up IOS XE, but if I can paraphrase the key update here is that IOS XE uses separate processes for the various tasks and systems running on a router. This means that if you run into a bug that causes the SNMP service to blow up the entire router doesn’t become unresponsive. Your voice processes like CUBE could continue to function unimpaired.
This might also help to explain why our friends in the CUBE product management team have so consistently pointed out to us over the last year that all the features they were developing in IOS Classic for the ISR G2 were launching at the same time in IOS XE for the ASR. Of course, now all that hard work pays off double when the newest additions to the ISR line running on Cisco’s latest IOS architecture come to market on a level playing field against their predecessors.
Let’s take a look at some performance comparisons. In the chart below we see throughput with services listed. Cisco claims that throughput with multiple services will not suffer nearly as much as they did on previous generation routers due to the multicore processor and IOS XE’s multi-threaded approach.
That is especially intriguing to me as a voice engineer because it means I have hardware where I can turn on all of the fun MediaNet features like Performance Monitor and AVC. Which in turn means that I can get some really incredible data out of tools like LiveAction. If you haven’t looked at LiveAction take 10 min to browse through their website and watch a few demo videos. It is hands down the most powerful QoS management and monitoring tool I’ve seen and well worth the time.
These new models also have a “Performance License” that enables additional processing power to support a higher throughput. The idea from Cisco being that you buy the router today and in three years when your WAN circuit gets an upgrade you simply buy a license rather than replace the router in order to support the higher throughput requirements. Personally, I’m not so hot on that idea and would have preferred each platform release without any sort of rate limiting or policing due to a license. You’ll see two numbers then in the chart below for performance of the ISR 4000s, the first is the default and the second is the throughput after applying the Performance License.
|Model||Throughput with Services||SIP Sessions||Calls Per Second||SRST|
The new ISR 4000 line might be enough change for voice engineers to handle at the moment, but there’s more. Our venerable VG224 analog gateway has long been in need of an update. Handicapped by non-field replaceable memory limitations it cannot make the jump past IOS 15.1 and thus lacks the enhancements of 15.2 and 15.4. Enter the VG310 (24-port) and VG320 (48-port). Yes, finally the 48-port 1RU analog gateway has returned (RIP VG248).
There is one surprising disappointment for the new VG310 and VG320 and that is the lack of IOS XE. These appear to be based on ISR G2 architecture and IOS Classic. While there are no plans to EOL the ISR G2 at the moment, history tells us it’s not that far down the road. When that happens these will be one of a very few gateway/router products still using IOS Classic.
These new platforms seem to have slipped by many of us, but a few months down the road all voice engineers will feel the impact as they trade in their 2900s and VG224s for 4300s and VG310s. While I don’t love everything about the new platforms (e.g. the additional performance license and the lack of IOS XE on the VG310/320), there’s enough good here to outweigh the shortcomings. Multiple clocking domains and the performance benefits with IOS XE’s architecture have me itching to deploy a few and put them to the test.