I started writing this series three years ago, but got distracted by other tasks and neglected to complete this last post in the series. It’s one of the most important. Before I begin writing about other topics I wanted to come back to this draft and the notes I started three years ago and finally publish it.
First, let’s set our baseline. The common wisdom in Cisco UC for as long as I can remember has been to use the “Device/Line” approach. Older SRNDs spent plenty of time explaining this approach, which can be summed up as follows:
- Provide access to ALL destinations via the Device CSS (unrestricted access to internal & PSTN)
- Restrict access and create Classes of Service via the Line CSS and exact match blocking patterns.
- The resulting concatenation of the Device and Line CSS’s would provide the user’s Class of Service.
E.g. if I had a pattern, 9.1[2-9]XX[2-9]XXXXXX to provide long distance calling in the US applied to the Device CSS, but I wanted this phone to have Local-only dialing privileges I would need to create a duplicate pattern, 9.1[2-9]XX[2-9]XXXXXX, that would be set to block or reject the call. This blocking pattern would be applied to the Line.
The thought was that you only needed one set of blocking patterns to handle an entire country dialing plan. That same 9.1[2-9]XX[2-9]XXXXXX that blocked LD calls in Minnesota would work equally well for users in California, Kentucky, etc. It was intended to minimize the overall configuration needed.
But with +E.164 patterns this starts to break down. These blocking patterns that provide Class of Service can no longer be applied globally when it comes to E.164 because they are source specific (i.e. the context of the call matters). Take a look at this same E.164 pattern and see what I mean:
- +1651XXXXXXX in Minneapolis, MN blocks Local calls
- +1651XXXXXXX in Chicago, IL blocks Long Distance calls
- +1651XXXXXXX in Germany blocks International calls
Once deciding to allow users to dial E.164 patterns our entire Class of Service design breaks down. We’d need to individually create blocking patterns at every geographic location based on their local, LD and Intl patterns.
What’s the alternative? A single CSS. That single CSS should have:
- Route Patterns that are ONLY in +E.164 format
- All other patterns are Translation patterns that Globalize to +E.164 format
In this way we create translation patterns that allow all of the end user dialing habits, globalize those varied dialing habits to a standard E.164 number and then provide class of service based on the E.164 patterns.
Here are two examples:
In the first we have an end user that dialed 9 608 298 1100. Looking at the translation patterns in that LD partition you can see that they also could have dialed 9 1 608 298 1100 or +1 608 298 1100 and the end result would be the same. We expand to E.164, use the Originating CSS option on the translation and try again, but now we match the +E.164 Route Pattern.
In the second example we see a CSS that only provides Local calling from Minneapolis. We still match the same translation pattern for this call and expand to an E.164 number. But now when we loop back around there is no matching pattern for the +16082981100 number. There is access to the local area code +1763XXXXXXX, but no long distance area codes.
One benefit of this is that toll fraud patterns like 1-900 numbers only need to be defined once as +E.164 blocking patterns. No matter how a user tries to dial (with PSTN Access Code, with/without 1, etc.) the only Route Pattern that will match and potentially provide PSTN access is the single blocking pattern.
What are some other benefits of this Single CSS approach?
- There are places we can’t apply a Device/Line approach because CUCM only allows one CSS
- Call Forward CSS’s (except CFwdAll)
- Rerouting and Out-of-dialog CSS’s
- Integrations (SIP Trunks to 3rd party systems, Expressway, etc.)
- Device/Line is complicated and confusing. It’s second nature for most voice engineers now, but new engineers and customers who rarely touch the Call Routing config in CUCM have trouble following the “resultant CSS” to know what access a phone truly has. A single CSS is easier to troubleshoot.
- No need to create exact match blocking patterns for Line CSS’s for every pattern created and added to a Device CSS. Let’s face it, the system might be perfect on First Day of Service, but come back a year or two later and I guarantee there are toll fraud holes in that Device/Line design from admins inadvertently creating new patterns and not creating a partner exact match blocking pattern for all of the Line CSS’s.
Where should we apply this single CSS? The Device or the Line? Choose carefully for your design.
- If applied to the Device it is changed by Device Mobility and Extension Mobility
- If applied to the Line it follows that user when roaming.
This isn’t a one size fits all scenario, but I’ve found this approach to work well.
- Apply a single CSS to the Line only.
- Apply Emergency (911) patterns to the Device since emergency calls should be location-specific rather than user-specific. But do so via each Device Pool’s Device Mobility CSS. Even if you are not using Device Mobility this CSS will still apply to the phone and keeps extra config off of the phone. It also means it’s less likely admins will forget to set it and cause an issue with emergency calling.
Jessie decided it’s time to start the baby registries. Similar to Jessie deciding it’s time to start nesting (that was about 2.5 weeks in). So now the registries are up, the garage sale shopping has begun and new, baby-related items magically appear every other week.
During the baby registration process I was given sole responsibility for choosing a baby monitor. A task I took on with an appropriate level of gusto.
My first thought: throw a Cisco 8945 in the baby room with auto-answer on and get a Cius to carry around the house as the ‘monitor’. I pre-wired the bedrooms shortly after we moved in and have an NME etherswitch module in my 2821 providing 24 ports of PoE to the house so all the infrastructure is in place. But Jessie quickly shot that down. I think mostly due to the pricetag slightly north of $1k.
Back to the traditional methods…
- Video or no video. I decided no video. If my baby can’t get Cisco video it’s not getting any video.
- Next requirement was DECT.
- There’s no way I was going to let my baby’s babbling duke it out in the 2.4 or 5 GHz range along with the 20-some home wireless networks I can see from my living room.
- Plus, the extra range lets me hang out in my neighbor’s driveway with a cold beer in hand while still carefully monitoring the baby room.
- Third DECT benefit.. 120 encrypted channels. The neighbors down the street don’t need to listen to me read the little one Chicka Chicka Boom Boom at 3am.
Finally decided on the Philips Avent monitor. I think this is why Jessie only gave me a couple items to pick out. It’d be middle of next year before the baby gets a crib at this rate.
Everyone is talking about Cisco’s latest Cius announcement today, the AppHQ and July 31st availability.
- Cisco Newsroom – http://goo.gl/X2vmT
- No Jitter – http://goo.gl/qgYbM
- Engadget – http://goo.gl/5cIsF
- Gizmodo – http://goo.gl/wpVLC
I won’t disagree that Cisco has a a ways to go yet with the Cius (I’ve been using one the last few weeks), but the reviewers are missing the point here.
First, price. Reviewers, stop freaking out about it. If the Cius is $750 list and Cisco’s standard discounts apply most customers will pay a very “tablet-competitive” price even though it’s not “a tablet”. For reference, Cisco’s 9971 video phone has a list price just under $1000 and many customers are more than willing to buy them. Now you can have everything the 9971 offers and more.
Second, Android & the power of apps. Enterprise-grade video phone + Android apps = unlimited potential. Read Dave Michels great article on re-inventing the desk phone on nojitter.com, http://goo.gl/Hfr87. The Cius has 80-90% of his wishlist and it’s definitely on the right track here. Beyond these features think about current Cisco developers like Singlewire and the possibilities with their InformaCast notification products. Or the ability for a contact center supervisor to walk around the building with a Cius getting real-time stats and re-skilling agents to meet traffic spikes with a swipe of their finger. This is the future of the enterprise desk phone.
Finally, all the tablet comparisons are fine, but the real value for enterprises is this: VDI & the Cius media dock. Enterprises can buy a Cius and they no longer have to buy that employee a computer. A Cius with the dock connected to a monitor, keyboard & mouse with a Citrix or VMware View virtual desktop to connect to is the power play here. Now even at list price that $750 doesn’t sound so bad.
The strength of the Cius isn’t that it’s a tablet, because as far as that’s concerned it’s mediocre at best as the recent reviews have shown. They’re right. It’s not an iDevice. It’s not slim, aluminum, dual-core. It doesn’t even run recent code (Android 2.2). But Cisco’s positioning this in a perfect mix of their collaboration & data center strengths with a dash of the “consumerization of IT” thrown in. I think the idea & theory is perfect, now Cisco just needs to deliver.
A couple interesting items I learned about Cisco Unified Communications Manager’s (UCM) Automated Alternate Routing (AAR) feature today.
- In UCM 8.6, even with 1kb of bandwidth allocated for audio it still lets one call through. The second gets stopped or uses AAR. This one might be a bug… more research on that.
- If a DN has a Remote Destination or Dual Mode phone associated to it, AAR will not kick in. The call will be placed to the RD only and the AAR path will not be used. I’m still trying to decide if this is desirable and I’m leaning towards no and a TAC case.
- When exceeding Video Bandwidth for a location a call between two video phones will still traverse the WAN as usual if there is audio bandwidth available, but just set itself up as an audio-only call. Then if video bandwidth opens up and the call is held/resumed video will be added back into the call (unfortunately, looks like a hold/resume is required to get UCM to renegotiate the media. It’d be cool if UCM would keep track of the call and add video when the bandwidth opened up.).
I know you’re an enterprise-focused company and in light of recent events you’ve proven your loyalty there. But let’s take a look at that consumer market in a different light, because your competitors are doing just that. First up:
Skype… oh yeah, and Microsoft
No one seems to be quite sure if Microsoft understands what they did here and the incredible potential the purchase provides. I work with enterprises to design their UC systems every day and lately I’ve been hearing a lot of this, “What’s the deal with SIP trunking? Can I use that to connect to Skype? We have a bunch of vendor support teams in *insertforeigncountryhere* that only use Skype. Plus, all our execs use Skype when they travel.”
This next idea should scare the daylights out of anyone on Cisco’s sales team. Native Skype “node” built into MS Lync 2.0’s edge server. Take a look at these usage numbers from Wikipedia. Direct access to all those users from your Lync client using their impressive SILK super-wideband, adaptive bitrate, audio codec and also offering video (conferencing)? Everyone was scratching their heads, but it’s a wonder Skype wasn’t snapped up by Cisco or Microsoft sooner.
And then there’s Google – http://goo.gl/WjwNj
Google may not be an enterprise UC player yet, but that doesn’t mean they won’t soon be taking a share of the SMB market through their Google Apps program by adding GVoice in the near future. Could you imagine if Google offered a simple IVR to all of their GApps customers? For the <20 user businesses it’d be incredible. Now take a look at the link above if you haven’t already. Chrome OS + native & free video chat using their new WebRTC & iLBC? Instant access to all of their existing gMail, gTalk & GVoice users? With high-quality audio & video? The power of the masses strikes again.
So where does this leave Cisco? It means that while they cancelled Flip, may be selling Linksys, and Umi is a flop because they doesn’t get consumer pricing, they still have an opportunity with consumer UC. Cisco needs to attack the consumer market with their own free desktop IM/presence/voice/video client just like their competitors. I think that opportunity is Umi Connect.
(sidenote – WebEx Connect? Umi Connect? Is it possible they’re using the same Client Services Framework backend for this Umi Connect client? please say yes)
Back on point, supposedly a Umi Connect desktop client will be available for free to Umi subscribers this fall. I say make it available for free to anyone this fall. Charge for video voicemail storage, charge for the Umi hardware, but give the client away for free. Your competitors are doing it. Build native federation between Umi Connect and WebEx Connect. Make federation to a corporate Cisco Unified Presence Server a checkbox to select during install. Give away a free client, connect it to the meet.webex.com beta site and you’ll have users by the boatload. And then you’ll have a leg to stand on when Microsoft announces a builtin Skype node in Lync 2.0.
Update on July 9th, 2012: This post was originally published in June 2011. A year later a lot has changed.
First, Cisco quickly came out with a matching SIP load so they are not limited to just SCCP. From what I’ve seen there is feature parity between the two and if I had a choice I’d pick SIP. Hopefully Cisco continues to invest more heavily in the SIP loads as they’ve done with their other high-end models.
Second, a number of initial gripes are fixed in recent firmware.
- Custom backgrounds & ringers
- Max/call busy trigger is now configurable
- Mobility & DND are now available as softkeys
- Many other little fixes here and there
This thing has been my primary desk phone for quite a few months now and I’m growing to like it. There are still a few things I’d like to see fixed (e.g. Phone VPN), but if I were faced with a purchasing decision today I would favor this over a 7942/45 and in most cases the 7962/65. I’d accept the fact that I’ll be doing regular firmware upgrades over the next year or so and balance it with the fact that I “future-proofed” my environment by offering video & Bluetooth to a large population of workers.
*When wouldn’t I use these to replace a 796x phone? When I need sidecars. And in that case, I’d move up to an 8961/9951/9971 and use the KEMs. They have some really nice high call volume features. The phone + KEM costs a bit more, but for the few people who need them it’s worth it.
Cisco recently released their new 8941/45 phones with built-in video cameras. A few interesting observations, but first the differences between the two.
The 8941 lacks gigabit network connectivity and Bluetooth, but comes in as a Class 1 PoE device (3.84w or less). The 8945 adds gig & Bluetooth, but still comes in much lower on the power scale than any of Cisco’s other phones with a color screen or video running between 6-7w when the screen is active.
Perhaps the most interesting design decision is the fact that the default firmware (and only fw at the moment) is SCCP, an interesting departure from their other recent high-end phones that run SIP (the 8961/9951/9971). I really expected SIP to be the go-to fw for all new phones. Especially considering the camera, why not re-purpose existing 9900 code rather than write all new fw from scratch?
A couple comments on the physical design of the phone. First, new finish & new handset. Take the finish from the bodies of the 7900 & 9900 phones, mix and serve for the 894x. Handset looks to be the same as the one that will come with the Cius dock. I miss the meaty 7900 handsets, but this is much better than 9900 handsets. Screen looks great, in some ways more crisp & clean the 9971. Disappointing that it appears there is no way to add a sidecar/KEM and no USB ports.
I had very high hopes for this phone and thought it would be the replacement for the 794x/6x phones that brought video to the masses. Unfortunately, while the hardware is all there the firmware is beyond disappointing. The good news? Firmware can be fixed. A few things that Cisco should consider non-negotiable when they release an information worker phone:
- No Phone VPN support.
- No custom background or ringtone support.
- UI is slow, e.g. phone can’t keep up with me when I’m dialing, much less moving through the setting or service menus.
- Hardcoded max call/busy trigger (3/2) just like the 6900s. Poor shared line support due to this. Ridiculous that Cisco thinks this is acceptable for a phone of this caliber.
- Pre-config’d softkeys like the 9900s (not the 7900s). Another frustrating aspect. Mobility & DND can’t be put on softkeys, so those 4 line buttons get cut down to 2 very quickly and you’re back to a 794x.
- Other miscellaneous things like not supporting Visual Voicemail give you the feeling that Cisco pushed this one out the door a little early.
Ah… IOS. Refreshing after spending a week with ACME Packet’s ACLI. And at the same time it certainly has it’s own frustrations. It took me a while to get this working in my lab (partially because I was in Boston and my lab is most decidedly not), but I have a feeling DNS SRV records with SIP are going to prove very useful to me in the future.
The goal here: use DNS SRV records to minimize the number of dial-peers required in IOS. Typically CUCM is set up in some sort of redundant fashion so that there are multiple call processing servers. Going deeper, the configuration of CUCM is such that CM Groups are created with a max of three servers per group meaning everything needs to be pointed at two or three different servers in case one goes down. So we want to use one dial-peer to send a particular call to a CM Group made up of three servers rather than the usual three.
VoIP dial-peers use session targets to determine where to send a matching call. With no DNS SRV records each pattern would require three dial-peers using preference commands as shown below (Note: The use of an ipv4: target vs dns: target makes no difference here, I am using ipv4 in this example for contrast. DNS A records for each server would still require three dial-peers, it is only with DNS SRV records that we can collapse three dial-peers down into one).
dial-peer voice 1 voip destination-pattern 2000 preference 1 session protocol sipv2 session target ipv4:10.0.0.1 dial-peer voice 2 voip destination-pattern 2000 preference 2 session protocol sipv2 session target ipv4:10.0.0.2 dial-peer voice 3 voip destination-pattern 2000 preference 3 session protocol sipv2 session target ipv4:10.0.0.3
With DNS SRV records we can cut this down to one dial-peer:
dial-peer voice 1 voip destination-pattern 2000 session protocol sipv2 session target dns:cmgroup1.lab.local
along with a little extra config (to host the DNS SRV records in IOS to remove reliance on the corporate DNS server)
ip host cucm1.lab.local 10.0.0.1 ip host cucm2.lab.local 10.0.0.2 ip host cucm3.lab.local 10.0.0.3 ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm1.lab.local ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm2.lab.local ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm3.lab.local ip name-server 127.0.0.1 ip domain name lab.local
Finally, in order for a CUCM subscriber server to accept a SIP URI with a destination of @cmgroup1.lab.local rather than @<servername>.lab.local each parent DNS SRV records (cmgroup1.lab.local) must be added to the Cluster FQDN list in Enterprise Parameters. If this step is not completed, expect to see SIP 404 Not Found errors. From the CUCM Help:
This parameter defines one or more Fully Qualified Domain Names (FQDN) for this cluster. Multiple FQDNs must be separated by a space. Wildcards can be specified within an FQDN using an asterisk (*). Examples are cluster-1.rtp.cisco.com and *.cisco.com. Requests containing URLs (for example, SIP calls) whose host portion matches any of the FQDNs in this parameter will be recognized as a request destined for this cluster and/or devices attached to it.
Many thanks to these helpful resources, the first in the list is an especially good resource:
I spent the last week in Boston, MA at ACME Packet taking a configuration basics course for their Net-Net 4000 products. For those not familiar with ACME Packet, they make Session Border Controllers for VoIP applications. They claim to be the inventor of the SBC and historically have sold to carriers (and done very well). They recently bought Covergence, aiming to take a stab at the enterprise & commercial market with their rebranded Net-Net 2600.
A few thoughts from the last week:
- Anyone who is familiar with 1) configuring network devices via a CLI and can telnet/ssh/ftp via a command line and 2) VoIP & SIP should skip straight to their advanced configuration class. Out of the five days only two were all that useful (Wed/Thur when we talked about basic SIP config for the Net-Net in Access Backbone and Peering environments).
- These products are powerful in a big way. Very impressed by the product both in terms of features and scalability.
- I’m a little green (only been in the industry 3-4 years), but in my mind ACME has put together a horrendous CLI (they call it the ACLI, ACME CLI). I really like where they’re headed with the object-oriented nature, but the implementation is downright scary. Even the simplest configuration tasks quickly become painful. Be ready for huge, complex configs while you curse & swear at your keyboard finding yourself yet again lost in their poorly labeled contexts.
- Their Net-Net 2600 is an especially interesting product in that it fits very well in the enterprise & commercial space. On-box transcoding up to 400 sessions and (according to them) all the same features as their 3800-4500 products make for quite the SBC. If you figure 400 sessions is ~17 PRIs you can see this “low-end” model will scale very well for most organizations. And that’s only if you need transcoding. Take out the transcoding and the session limits go sky-high like their other products. I’m very interested in taking the config class for the 2600 product.
- Pricing. I’ve only heard rumors, but it sounds like their products are ridiculously expensive. I think the pricing might have worked well in the carrier space, but they may have a difficult time penetrating the enterprise market if the numbers I’ve heard are actually true. If I can buy 10 3900-series ISR G2’s from Cisco for the same price as one ACME Net-Net I’m going to have a tough time justifying the purchase to mgmt even if it is the better product.