Category Archives: Tech
CSCvf07153 is a pretty simple mistake exacerbated by inconsistent implementation from Cisco.
What is it? Cisco CUBE sends the local timezone of the router in SIP headers when the RFC specifies that GMT should always be used. This causes some SBCs to respond with 400 SIP Parser Error : Missing TIME ZONE and causes calls both inbound and outbound to fail.
The bug lists a workaround, yet the workaround is not complete for two reasons.
- It only lists the Daylight Saving timezone and not the Standard timezone
- It lists the timezones only in upper-case, but CUBE (3.16.7S) uses upper-case for Standard time and lower-case for Daylight Saving time.
TAC is updating the bug notes with this info, but it may not show up for a few days. Here’s a proper workaround. Replace CST/CDT/cst/cdt with your timezone:
voice class sip-profiles 27 response ANY sip-header Date modify "CST" "GMT" response ANY sip-header Date modify "CDT" "GMT" request ANY sip-header Date modify "CST" "GMT" request ANY sip-header Date modify "CDT" "GMT" response ANY sip-header Date modify "cdt" "GMT" request ANY sip-header Date modify "cdt" "GMT" response ANY sip-header Date modify "cst" "GMT" request ANY sip-header Date modify "cst" "GMT"
A few months back I was working on a Cisco Conductor implementation and ran into a bit of a hiccup. Here is what we set out to do:
- Conductor integrated to CUCM to provide ad-hoc conference resources for Jabber and TelePresence endpoints with the following versions & requirements:
- CUCM 10.5
- Conductor 3.0
- vTelePresence Server 4.0
- All media and signaling must be encrypted
- Symantec managed PKI for internal server certs
Everything worked fine using unencrypted traffic. In fact, it even worked fine when the media was encrypted and the signaling was left unencrypted. To be even more specific, we could even encrypt half of the signaling successfully, but getting all of the signaling encrypted posed a problem. What’s even worse, a cosmetic bug led to some tail-chasing. Let’s take a look at the integration between CUCM and Conductor and break things down.
The config guides state that two items must be configured on CUCM.
- A SIP Trunk must be created. This is how CUCM sends calls to the Conductor and ultimately to the TelePresence Servers (TS) it represents. This is done via SIP signaling and RTP media.
- A Conference Bridge Media Resource. This is what CUCM uses to make API calls via HTTP(S) to Conductor to create those ad-hoc video conferences on demand. The API call happens before CUCM sends the SIP signaling for the actual video call so that Conductor creates the conference and knows where to send that incoming SIP INVITE and video call.
Getting this all to work unecrypted was no problem, so let’s look at how we control encryption for these three items:
- API signaling (TCP port 443, HTTPS)
- SIP signaling (TCP port 5061, SIPS)
- RTP media (UDP ports 16384-32767, sRTP)
The SIP Trunk controls the SIP Signaling and the Media. On the SIP Trunk configuration page the first setting is to check the SRTP allowed box.
The next item is to specify the SIP signaling port as 5061 as that is the port where Conductor expects to receive secure SIP signaling. We should also set a custom SIP Trunk Security Profile. More on that next.
The SIP Trunk Security Profile allows us to define a few things that force the encryption.
- Set the device security mode to Encrypted to force encryption.
- Set the expected transport both inbound and outbound to force TLS.
- Set the expected inbound port (listening port) to 5061 (TCP).
- The item I skipped over is the X.509 Subject Name. This is what CUCM uses to validate the certificate it receives from Conductor. It will look at the received certificates Subject Name as well as any SANs for a match against this value. If there is a match (and the certificate has a valid, trusted chain) the certificate validation will succeed. Note that this field is case sensitive.
At this point it is important to note that this is as specified in the deployment guide for Conductor/CUCM 3.0 even though these settings are what I would call “bad practice”. You know, the opposite of best practice. The config guide has one easy no-no to pick out (my screenshot is “corrected”). They use a hostname that is not fully qualified in the X.509 Subject Name field of the Security Profile, which we know makes our security friends cry themselves to sleep at night. The second seems a little more innocuous at first. They state you should enter an IP address rather than FQDN on the SIP Trunk config page’s Destination Address setting. This is particularly interesting because it shows that CUCM can have a secure SIP Trunk pointed at an IP address, but succeed the certificate validation because it will use the value in the SIP Trunk Sec Profile’s X.509 Subject Name to match an FQDN from the Conductor’s certificate.
Why are these “bad practice”? Because the CAB Forum says that only public FQDNs should be used in certificates. See this note from the CAB Forum: Guidance on Internal Names (and IP addresses).
… on November 11, 2015, the issuance of certificates with a reserved IP address or internal server name is prohibited. On October 1, 2016, all publicly trusted SSL/TLS certificates with an internal name or reserved IP address will be revoked and/or blocked by browser software. As of July 1, 2012, all CAs were required to notify customers applying for internal name certificates that the use of such certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016.
Let’s keep moving with our Conductor config, but… spoiler alert: this will end up being the crux of our issue.
I should point out that at this point if you have properly installed certificates on both CUCM and Conductor including all necessary root and intermediate CA certs to the appropriate trust stores that this SIP Trunk will be ‘operational’. If you enable SIP Options Pings in CUCM 10.5 the status of the SIP Trunk will show “up” in the CCMadmin interface. We’ve knocked out 2/3 of the config. The SIP signaling and RTP (sRTP in this case) are successfully configured.
The last piece is the API integration via the CUCM Conference Bridge media resource. Let’s do that. Under Media Resources > Conference Bridge we create a new CFB of type Cisco TelePresence Conductor similar to this ensuring the Use HTTPS box is checked.
And this is where it all falls apart. The CFB will never register. Well.. sort of never. Time for an aside on the cosmetic bug, CSCuo85081.
The bug notes, as with most Cisco bugs, are a bit confusing. The net of this is that if, when you create this CFB, you leave Use HTTPS unchecked and CUCM successfully creates an unencrypted (HTTP) connection to Conductor and you then check the box Use HTTPS it will not actually use HTTPS. Even after multiple Resets, Apply Configs, etc. the existing HTTP sessions are not torn down nor are new HTTPS sessions created. You must reboot UCM or delete the CFB and recreate it checking the Use HTTPS box upon creation in order for HTTPS to be used. Imagine the fun had tracking this down via packet captures and mysterious CFB “un”-registrations the morning after a cluster reboot. It really is true, packet captures don’t lie.
Perhaps the worst part is that the box Use HTTPS will stay checked, the endpoints will report they are connected securely to Conductor and everyone assumes life is good. Until you reboot and it all breaks. Or when the security team audits the traffic and sends you directly to jail, do not pass go, do not receive $200 when they find your Conductor admin credentials being sent in clear text via this HTTP call from CUCM. By the way, to mitigate you could(should) create a new user on Conductor with API permissions only (no admin/GUI rights) to use for your CUCM integration.
Okay, so we know to check our packet captures to ensure our traffic is truly encrypting before declaring victory. So why won’t HTTPS work? Remember back to our SIP Trunk and SIP Trunk Sec Profile when I noted the interesting behavior that the destination was an IP address, but the certificate validation was done on a different field? The CFB traffic does not benefit from this ability to specify two different addresses. The destination address of the SIP Trunk that is specified on the Conductor CFB config page is used both as the destination of the API call and as the subject name to validate against the received certificate.
Remember that we configured an IP address as the destination of the SIP Trunk. That IP address does not show up as the Subject Name on any of the SANs so the certificate validation fails and the HTTPS connection cannot be established.
Ah-ha! Success! It validates successfully against one of our certificate’s SANs and registers. Packet cap confirms the traffic is encrypted. Life is good. Let’s place a test call.
Hrm… call failed trying to conference in the third endpoint.
Pro tip: If you ever find yourself needing to look at Conductor diag logs… don’t. It’s not that you can’t find useful info in them, but they are obnoxiously verbose and difficult to read mostly due to the use of line endings every fifth character.
The Conductor logs tell us that the conference.create step failed because Conductor couldn’t find a valid Location for the IP address in the API call. The logs show the FQDN being used as we specified in our “Override SIP Trunk Destination as HTTP Address” setting to get the CFB to pass the cert validation and register. But it says it can’t find a Location for the IP Address. Ah, here is our next problem. Conductor logic for matching inbound calls to conference templates is driven by the IP address assigned on the Conductor Location page. This is why you must create all those ‘secondary’ IP addresses on Conductor. Each new conference template must be assigned its own IP address. At this time, Conductor will only match against IP and does not have any logic to match the corresponding FQDN.
Well… that puts us in a bit of a pickle. If we tell CUCM to use the IP address for this API call the cert validation fails. And if we tell it to use the FQDN the cert validation succeeds, but the API call fails because Conductor doesn’t understand FQDNs. This is why the deployment guide states that IP addresses MUST be used for the SIP Trunk to Conductor and that the “Override destination” setting should not be used on the CFB config page.
Apparently most of Cisco’s customers are okay with sending admin/API credentials in clear text across their internal networks as I was surprised to find TAC and, via escalations, the BU had not come across this before. Their recommendation is to include the IP addresses of the Conductor (yes, all of them) as SANs in the certificate so that the certificate validation succeeds when telling CUCM to connect to the Conductor IP addr rather than FQDN.
That’s all fine and good if you are signing certificates via an internal CA, but if using a public CA or a managed PKI service from someone like Symantec for your internal PKI you will be hard-pressed to find anyone willing to sign a CSR that includes an IP address. See the CAB Forum Guidance on Internal Names discussion earlier in this post. I ended up having to generate a self-signed certificate and install the self-signed cert directly to CUCM’s Tomcat trust store.
But here we get to the last fly in the ointment so to speak. You cannot use the GUI to generate this CSR. You must use OpenSSL to generate a CSR off-box with the correct parameters. Why? Because the GUI generates a CSR with all SANs set to a type of DNS. CUCM will not validate the certificate properly unless the IP addresses are set to a type of IP address. See the difference in the two below.
Using the Conductor GUI to generate a CSR yields the following:
DNS:conductor.widgets.co DNS:conductor-adhoc.widgets.co DNS:conductor-rendezvous.widgets.co <strong>DNS</strong>:10.10.10.10 <strong>DNS</strong>:10.10.10.11 <strong>DNS</strong>:10.10.10.12
With a certificate created using SANs as above the cert validation still fails. What we need is this:
DNS:conductor.widgets.co DNS:conductor-adhoc.widgets.co DNS:conductor-rendezvous.widgets.co <strong>IP Address</strong>:10.10.10.10 <strong>IP Address</strong>:10.10.10.11 <strong>IP Address</strong>:10.10.10.12
We cannot do this via the Conductor GUI because it does not allow us to specify the type of SAN. If you are familiar with Expressway you will note that its CSR generation tool does give you some flexibility here specifying SANs of type DNS or XMPP, etc. We would need something similar in Conductor, but it’s just not there. Instead we need to generate a certificate off-box using OpenSSL. You can take the existing private key from Conductor and re-use it to create the new certificate or you can generate a new private key. The command below was run from Terminal on a Mac and generates a new private key and cert.
openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout newprivkey.key -out conductor.pem -config openssl.cnf
What do we have here? We tell openssl to generate 2048-bit RSA encrypted private key named ‘newprivkey.key’. We also tell it to generate a certificate named ‘conductor.pem’ using a special config named openssl.cnf. The modified openssl.cnf file should be in the same directory where you are running this command and where the private key and CSR will be created. What needs to be in that openssl.cnf file? First, let’s find the default config file.
ben@vw$ locate openssl.cnf /System/Library/OpenSSL/openssl.cnf
Copy that to some new directory and we can make some edits.
$cp /System/Library/OpenSSL/openssl.cnf ~/scratch/conductorcert/
First, find the [req] section and change the default bits to 2048.
#################################################################### [ req ] default_bits = <strong>2048</strong>
Since this is a self-signed cert and we are not actually generating a CSR (where we would use the [v3_req] section) we use the [ v3_ca ] section to add keyUsage and SAN information. Normally we’d specify things such as dataEncipherment for keyUsage as well as serverAuth, clientAuth and IPsec End System to the extendedKeyUsage parameters. Here we are going to leave these commented out. If no parameters are set here then the certificate can be used for any of them. We just leave CA:FALSE set. The keyUsage and extendedKeyUsage parameters you see here are commented out, but include the values you would normally want in a CSR for Conductor. Add dataEncipherment and include serverAuth, clientAuth and IP Sec End System. When I tried setting these I had some issues getting CUCM to accept the certificate. Admittedly, I probably could have looked a little harder at this to find the right combo of extensions to make this work with a self-signed cert, but sometimes you just need to take off and nuke it from orbit. At this point we’re breaking so many security best practices with this self-signed cert I wasn’t too concerned. Plus, in theory this is temporary as Cisco is supposed to provide a permanent fix in an upcoming release (see notes at the end for the bug to track if you’re interested). Finally, we include a line telling it to add an array of alternate names to this certificate.
[ v3_ca ] basicConstraints = CA:FALSE #keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment #extendedKeyUsage=serverAuth,clientAuth,220.127.116.11.18.104.22.168.5 subjectAltName = @alternate_names
Next we will create our array of alternate names (this section does not exist in the default file, we are creating a new section named alternate_names). Remember that this must include every FQDN and every IP address used by this Conductor. The admin FQDN/IP and any others used for ad-hoc or rendezvous conferences. Add to this list as needed for your install.
[ alternate_names ] DNS.0 = conductor.widgets.co DNS.1 = conductor-adhoc.widgets.co DNS.3 = conductor-rendezvous.widgets.co IP.0 = 10.10.10.10 IP.1 = 10.10.10.11 IP.2 = 10.10.10.12
We are now ready to generate our private key and self-signed certificate. Referencing again the same command as above, this will create those two items with our modified openssl.cnf file.
ben@vw$openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout newprivkey.key -out conductor.pem -config openssl.cnf Generating a 2048 bit RSA private key .................................+++ ...................................+++ writing new private key to 'newprivkey.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Minnesota Locality Name (eg, city) :Minneapolis Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polzin Organizational Unit Name (eg, section) :Lab Common Name (e.g. server FQDN or YOUR name) :conductor.widgets.co Email Address :firstname.lastname@example.org
Let’s take a look.
ben@vw$ls -la total 40 drwxr-xr-x@ 5 ben staff 170 May 25 13:07 . drwxr-xr-x@ 22 ben staff 748 May 25 13:05 .. -rw-r--r--@ 1 ben staff 1976 May 25 13:07 conductor.csr -rw-r--r--@ 1 ben staff 1675 May 25 13:07 newprivkey.key -rw-r--r--@ 1 ben staff 10093 Feb 11 23:09 openssl.cnf
We now have a private key and certificate, let’s check that cert.
ben@vw$openssl x509 -in conductor.csr -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: b6:de:10:3a:38:17:d2:0c Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=Minnesota, L=Minneapolis, O=Polzin, OU=Lab, CNemail@example.com/emailAddressfirstname.lastname@example.org Validity Not Before: May 25 18:21:48 2015 GMT Not After : May 24 18:21:48 2018 GMT Subject: C=US, ST=Minnesota, L=Minneapolis, O=Polzin, OU=Lab, CNemail@example.com/emailAddressfirstname.lastname@example.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:a4:2f:66:aa:0c:fc:0d:2b:32:b6:5b:18:51:65: ab:29:66:80:cf:73:7d:3e:d1:a5:a2:9e:a2:f0:41: 51:0d:70:9e:7d:64:a9:97:e2:6a:7d:4e:ab:3f:79: 33:11:74:98:83:9d:e9:a9:ab:14:eb:26:db:ae:1e: 31:5a:d2:95:22:d2:88:b3:88:09:27:73:73:4a:ca: 5d:35:b9:69:0d:f6:bd:b6:d6:7e:a7:47:46:40:17: 70:6b:86:45:11:33:43:49:7c:7b:7b:ad:7c:80:3e: ee:5b:14:03:bc:8d:71:73:21:a1:0d:fd:48:0a:69: 60:c1:37:be:75:98:a9:36:9a:84:94:15:93:53:17: 11:cc:d0:dd:78:e2:f8:bb:40:ba:af:5c:43:ac:25: 18:57:1c:64:96:c8:1c:30:27:a0:18:36:18:e6:6c: 83:e3:44:58:29:fa:02:9f:d2:ea:2b:0e:45:6d:f1: 29:31:bc:9a:5d:34:b9:a0:dc:55:de:a3:65:b5:f9: ad:62:95:03:74:65:4e:6d:d2:a3:56:45:2c:fb:c1: e8:de:17:2d:c0:11:81:c1:13:20:b1:f1:84:47:26: 3b:7e:4e:53:c0:c8:e1:8a:e7:12:91:64:e2:06:41: ae:d5:02:de:e9:6a:57:d5:b0:63:c8:53:1a:64:47: 9d:dd Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Alternative Name: DNS:conductor01.widgets.co, DNS:conductor-adhoc.widgets.co, DNS:conductor-rendezvous.widgets.co, IP Address:10.10.10.10, IP Address:10.10.10.11, IP Address:10.10.10.12 X509v3 Subject Key Identifier: 3C:32:14:CC:D0:C4:79:5E:C1:28:25:16:43:89:3C:8C:CD:AB:2F:2C X509v3 Authority Key Identifier: keyid:3C:32:14:CC:D0:C4:79:5E:C1:28:25:16:43:89:3C:8C:CD:AB:2F:2C DirName:/C=US/ST=Minnesota/L=Minneapolis/O=Polzin/OU=Lab/CNemail@example.com/emailAddressfirstname.lastname@example.org serial:B6:DE:10:3A:38:17:D2:0C Signature Algorithm: sha1WithRSAEncryption 86:fe:7d:1e:d8:97:76:52:9a:49:fd:82:1b:bd:fa:05:80:87: 12:bb:4a:a6:97:44:9d:eb:52:e5:58:63:99:8d:66:bd:ab:82: b5:01:6e:ce:52:24:77:61:21:a2:d4:a0:dd:c9:f7:30:2d:7f: be:bb:73:22:6b:82:53:b8:14:90:5d:ba:ae:39:da:6e:1e:fe: 8a:a8:08:17:bb:56:29:2a:da:95:16:3e:f2:46:e6:84:62:88: 41:1c:8c:38:58:07:b6:b8:b9:72:10:ca:3f:7d:0e:d5:c1:ea: 40:b5:0f:9a:fa:c9:53:48:94:52:68:e8:9d:f7:6a:be:68:d5: 3f:a9:3f:bd:80:c9:ab:17:f4:9c:15:c1:e4:1e:85:68:3d:5c: ec:42:24:f4:bb:a4:fe:4a:b8:d1:2d:e2:a5:8c:f5:8d:5e:e5: af:25:26:e6:3d:40:f7:f4:61:61:b4:5f:89:da:1f:02:8a:a6: 53:61:23:52:30:ed:a4:ce:a8:6c:69:7b:ba:65:b2:de:28:18: 3d:fd:15:a3:e6:bf:7a:41:f2:62:a7:90:71:bf:f3:ac:c5:81: 22:ab:43:8a:8b:fa:cc:63:fd:fd:f7:fe:8e:bf:7c:02:1a:40: 97:86:fc:00:9b:13:90:f7:32:36:7c:b4:17:c0:51:63:1d:45: f1:f2:46:86
Now to get this installed on Conductor.
SSH to Conductor as root and navigate to /tandberg/persistent/certs.
ben@vw$ssh email@example.com Password: Last login: Tue May 3 18:59:01 CST 2015 from 10.10.10.1 on pts/1 ~ # cd /tandberg/persistent/certs
Copy the existing private key and certificate in case you need to fall back (note that the SSH session uses a different certificate so making modifications here will not kill you SSH session or ability to connect to the Conductor).
~/persistent/certs #cp privkey.pem privkey.pem.bak ~/persistent/certs #cp server.pem server.pem.bak
Use SCP to transfer the new private key and cert or use vi and copy paste. For variety, SCP for private key and vi for cert. Use either one.
~/persistent/certs # scp firstname.lastname@example.org://Users/ben/scratch/newprivkey.pem ./privkey.pem The authenticity of host '10.10.10.1 (10.10.10.1)' can't be established. RSA key fingerprint is 77:ff:dd:55:22:dd:44:aa:77:bb:66:11:22:33:44:55. Are you sure you want to continue connecting (yes/no)? yes Password: conductor.csr 100% 1830 1.8KB/s 00:00
And the cert (again, feel free to use SCP, but if not available you can always copy/paste into your SSH session using vi).
~/persistent/certs # touch selfsignedconductor.pem ~/persistent/certs # vi selfsignedconductor.pem ... Open the cert on your machine with a text editor, copy the entire contents. Back in vi on Conductor: type i for insert mode type Ctrl-V for paste type :wq to save and quit ... ~/persistent/certs #cp selfsignedconductor.pem server.pem
Reboot Conductor. Validate the certificate is as expected by viewing it via a browser. The list of SANs must look like this with special attention to the IP address: type.
DNS:conductor.widgets.co DNS:conductor-adhoc.widgets.co DNS:conductor-rendezvous.widgets.co IP Address:10.10.10.10 IP Address:10.10.10.11 IP Address:10.10.10.12
Now take that same certificate file and upload it to CUCM’s tomcat-trust certificate store on all nodes. Restart Tomcat on all nodes. CUCM will now properly validate the certificate even when using the IP address as the destination of the SIP Trunk and Conductor CFB object in CUCM. And because we used the IP address the API calls will succeed because Conductor is able to match those IP addresses to Locations and their assigned IP addresses.
I expect that Cisco will provide some workaround in a future release of Conductor.
There is a relatively easy workaround that they could implement by allowing you to specify the SAN type when creating the CSR in Conductor to specify a SAN being an IP address rather than DNS name (update 5/28/2015, this has been assigned CSCuu53177). This would be a poor workaround as using IP addresses in certificates is frowned upon and will be deprecated next year by all CAs (most will not issue certs with IP addresses today).
The real fix will be to modify the logic of Conductor to match Locations to IP addresses AND their associated FQDNs. In this way we could do all of our config in CUCM by FQDN and still have those API calls succeed during that conference.create step as Conductor matches against its Locations.
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.
If you read the dial plan section of Cisco’s UC SRND or happen to attend one of their dial plan design presentations at Cisco Live or a similar event you will invariably read or hear the words Globalization and Localization. What do they mean and how does it apply to dial plan design?
The UC SRND provides a guiding principal for global dial plan design:
Accept localized forms upon call ingress, and globalize them; route the call based on the globalized form; and localize the call to comply to the form required by the destination.
Cisco UC SRND 9.x – Dial Plan
If you’ve read my last two posts about E.164 numbers and choosing a DN Length (E.164 vs some arbitrary number of digits) you should be on board with the benefits of having a consistent format for the core of your dial plan. When you can build all of your call routing decisions with the assumption that all dial strings involved are unique with a consistent format it becomes very easy to make those decisions.
However, the source and destination devices often expect a format other than E.164. End users dialing from phones expect to be able to dial PSTN access codes, leave off the country code or area code for a local call or dial an abbreviated format using site codes. Similarly, a destination like the telephone carrier providing PSTN access may expect specific formats like 10 digits for local metro calls or an international access code like 00 or 011. In a world where we demand E.164 formatted numbers to make call routing decisions none of these things are allowed to enter the ‘dial plan core’.
This is why we must globalize (or expand to E.164) numbers that enter our dial plan and then localize (customize from E.164) numbers when they leave. Here’s a quick diagram that shows this concept with a slew of features that take place in the ‘core routing’ section of our dial plan that are made easier when we have the consistency of E.164 numbers.
How do we go about this? With Transformation Patterns.
First, what’s the difference between a Transformation Pattern and a Translation Pattern? A Translation directly affects the path or route that a call takes. A CSS is applied to a translation and this affects where the call goes next. A Transformation changes the format of a called or calling party number, but does not itself change the route or path that a call takes. When the call arrives at the next hop the path may change based on the new format of the number delivered, but that decision is made at the next step in the process.
Two quick notes on Transformation Patterns:
- The Transformation CSS ignores patterns in the <None> partition. It is the only type of CSS within CUCM that does this.
- The CSS assigned to a device as the Called Party Transformation CSS should include ONLY Called Party Transformation Patterns and no Calling Party Transformations. Same thing the other way when applying a Calling Party Transformation CSS. Bad things might happen if this is not followed that range from CCM core dumping to calls ending up in unexpected places.
Where should we apply these Transformation Patterns? At a minimum in two places.
First, we should apply them to our inbound SIP Trunks or Gateways to the Inbound Calling Party Transformation CSS to globalize the calling party numbers we receive from the carrier to E.164. This puts the E.164 formatted number in phone directories like Missed and Received Calls and allows for easy dial back. This is part of our Globalization.
You might also ask whether we should Globalize the Called Party on ingress to CUCM. The answer here is yes, but I prefer to do this on the voice gateway rather than CUCM so that the expansion to E.164 will persist through SRST when our phones with +E.164 formatted DNs are registered to the local gateway. This means the called party will show up on CUCM in a globalized format already.
Second, we should apply Called Party Transformation Patterns on our outbound SIP Trunks or Gateways to Localize the call as it leaves CUCM. For customers that use PSTN Access Codes (e.g. dial 9 to get an outside line), I prefer to do all of this within CUCM so that I am sending the localized, PSTN Access Code-prefixed pattern to the voice gateway. Once again, this has benefits for SRST as my users are used to dialing with a PSTN Access Code and my dial-peers on the voice gateway will match those dialing habits.
Remember that each of these Called Party Transformations will be a \+… pattern. Because we globalized the called number to +E.164 in order to have a consistent, unique number to make an intelligent call routing decision we lost the context of the user dialed string. Said another way, I no longer know whether the user dialed the number with or without a country code (if the user intended it to be a local or LD call). CUCM needs to have the logic that matches what the carrier expects to see. Local area codes for that site should not include the country code, in the US maybe they should even be dialed as a 7-digit pattern instead of a 10-digit pattern. CUCM must have this logic because the users are unable to influence this by dialing differently (we globalize it and that context doesn’t make it all the way through to the end device). A site like http://www.localcallingguide.com/lca_prefix.php is helpful in finding which area codes and exchanges should be local for a particular site in the US.
We’ve previously discussed interdigit timeout and E.164. With these foundational concepts out of the way we can dive more specifically into UCM.
Let’s start with this statement and look at how to get there: All DNs in UCM should be configured in E.164 format.
I think it’s fair to say that 5 years ago if building UCM (~4.x/5.x days) the DNs were the same length as internal extension dialing. When I say DN I mean the Directory Number field configured when clicking on “Line DN [x]” on a Device in UCM. Maybe the DNs were 4 digits, maybe 5. In larger organizations maybe they were 7 or 8 digits including a site code. In some organizations it was common practice to have a Partition for each site for these internal DNs as there might be overlap between sites. Translation patterns would add or strip digits as necessary to complete calls across the organization.
Then Cisco went and added things like Local Route Groups (LRGs). Mobile Connect became a core feature, not a secondary app. CUPC and later Jabber were introduced with click-to-call and Application Dial Rules (ADRs). InterCompany Media Engine (IME) was released and required E.164. Then SAF CCD and ILS came along to do much the same job as IME, but inside a single org that had multiple clusters. Transformation patterns and the ability to manipulate call ID presentation is ubiquitous. Even outside of Cisco’s product enhancements I think we’ve seen a trend in the last five to seven years of UC becoming the norm rather than the leading edge. More and more organizations started to consolidate the PBX at every site and centralize that management in a platform like Cisco’s Unified Communications Manager.
Each of the things mentioned in that last paragraph changed the way we think about the dial plan. Route patterns can be re-used across multiple sites via Local Route Groups. To prevent on-net calls from being sent to the PSTN when they show up in a corporate directory as the full DID a separate translation or ADR is required for every DID range to strip the call back down to the 5-digit DNs. Mobile Connect required ADRs or customized CSS’s to allow end users to put their cell phone numbers into the User Options page in their preferred format. Organizations consolidating PBXs in an attempt to lower the administrative burden find again and again that deciding on a common dial plan for all those sites is a difficult thing.
There has to be a better way, right? A method to the madness that scales. One that won’t require re-ordering ADRs every time a new DID range is purchased. That won’t require adding a pattern or partition to every site’s CSS to allow all the existing sites to dial the new location that was just brought online. And, of course, there is a better way.
Very simply, create every DN as an E.164 formatted string that matches the DID. Every, single one. Put them all in the same Partition. Now we have a single place in the dial plan for every internal destination formatted as a unique, non-overlapping string. How does this benefit us?
- Administration – A single Partition and format no matter what the site. There is no need to scroll through hundreds of partitions or remember site codes or extension lengths when creating a phone for the new guy that starts tomorrow.
- AAR – Remember when you had to create separate AAR Groups and prefixes for every location? Forget it. Create a single AAR Group and a single AAR CSS that points directly to a single E.164-formatted Route Pattern attached to a Route List with a Local Route Group. Done.
- Want to make sure the masses aren’t dialing their friends in the office a few states over via the PSTN and incurring toll charges? Put a simple Translation Pattern in place of each PSTN-facing Route Pattern to Globalize the dial string to E.164 so UCM can quickly analyze whether this pattern is On Net. More on this powerful technique in the next post.
- Application Dial Rules – There’s no longer a need for ADRs that map to individual sites or DID ranges. Create a single set of generic patterns that normalize all dialed strings to E.164 format. Analyze that E.164 string to see whether it is On Net or Off Net.
- Deploying IME, SAF CCD or ILS? Similar to AAR, check a few boxes and call it a day. No need for messy translations and workarounds.
- Ready to deploy Centralized SIP Trunking and need to put a single Inbound CSS on that SIP Trunk that can reach every site? A single CSS with a single Partition can do the job here. No per-site translations required.
What about non-DIDs? Yes, there are places in UCM where non-DIDs may be required. In my humble opinion these should be extremely rare. Buy more DIDs, they’re relatively cheap. Assign them to anything and everything. Assign them to Agent lines, assign them to common area phones, assign them to nearly everything. Even locations that previously had a single main number with an auto attendant/receptionist that transferred calls to everyone via their non-DID extension in the past… yup, every one of these people should get DIDs as well. Hide it on outbound calls if you must, but assign DIDs. It just makes life easier.
When non-DIDs are required I suggest following the same format as E.164 keeping the + and country code, but modifying the area code to some string that is clearly not valid. Then put all of these non-DIDs in the same “All Internal” Partition where the E.164-formatted DIDs exist. In the US it might look like this:
- The zeroes make it clear to admins and end users alike that this is not a valid NANPA/PSTN number.
- In the case of multiple clusters it may make sense to assign an NXX to each cluster. Take an organization with three UCM clusters in the US. East Coast, Midwest and West Coast. In the example above the NXX 001 would correspond to the East Coast cluster, 002 to the Midwest cluster and 003 to the West Coast cluster. This type of assignment can make sense, but don’t go overboard and overthink this.
- Most numbering plans reserve both area codes and numbering codes. I do not recommend using some of these reserved area codes like 777 or 950 as these are not easily distinguishable by end users as non-DIDs.
- I also do not recommend keeping the country code and valid area code followed by a reserved or dummy NXX for the same reason. The 958 or 555 NXX is reserved, but how many end users will readily recognize this?
Always be consistent with this and develop a plan to assign and track these non-DID assignments across sites and clusters.
E.164 seems to be a buzzword lately when it comes to dial plan design. Let’s first define E.164.
The ITU-T developed the E.164 recommendation that defines a standard number format. That format is a global standard of up to 15 digits usually prefixed by a +. (Thanks, Wikipedia.) What does that mean for us? It means that we can define every PSTN-dialable number in a consistent, standard format that guarantees each is unique. Here are some examples of E.164 numbers.
This standard format is good for the majority of folks in IT who have slight OCD tendencies when it comes to naming standards and documentation in general. The unique part of it helps us when designing a dial plan to avoid unwanted behaviors like interdigit timeout. Recall our discussion of interdigit timeout and leading digits or characters. The E.164 recommendation to use the + char as a prefix means these globally unique strings will not overlap with any other internal dialing patterns.
E.164 sounds great as a potential tool to avoid interdigit timeout, but unfortunately Cisco does not fully support the + char in all UC products. Here’s a quick snapshot (to the best of my knowledge as of 7/20/2013 and UC 9.1):
- UCM – Fully Supported.
- However, in some fields it requires the + to be escaped. E.g. a DN must be in the format \+16515551234. This is moderately acceptable for an administrator except for the fact that it’s very difficult to keep straight which fields require the escape character and which do not when creating bulk load import spreadsheets. This is entirely unacceptable when the UI designers do not catch this distinction and it slips through to an end user facing location in the /ucmuser User Option web page or in the Queue Status app or elsewhere.
- CUC – Fully Supported.
- In 9.x. Prior to 9.x the + was only supported in Alternate Extension fields and not the Primary Extension field. CUC 9.x supports the + in the Primary Extension field and evaluates a number with or without the + as the same extension. E.g. If I configure one user with the extension +16515551234 and another with the extension 16515551234 the second user creation will fail due to an overlap (assuming both are created in the same Partition).
- UCCX – Not supported for Agent DNs
- This is a major problem and needs to be fixed. The common workaround is to create a separate partition in UCM for Agent DNs and configure them without the +, then limit the use of that partition to only necessary CSS’s.
- CER – Partial Support
- CER can dynamically track phones configured with DNs that include a +. It can route calls from these phones no problem.
- CER cannot create manually configured phones with DNs that include a +.
- It also cannot search for a phone by Extension if it includes a +.
- Finally, it does not support ELINs that include a +.
- IM&P/Jabber – Fully supported
One of the most interesting parts of my job designing Cisco UC solutions is dial plan design. This will be the first in a series of posts discussing enterprise dial plan design as it relates to Cisco UC. The topic for this first post? A discussion of one of the more important design constraints when it comes to dial plans: avoiding interdigit timeout.
Interdigit timeout is a primary factor every time I walk into a new organization to help with a dial plan design. Interdigit timeout occurs when a user dials a string of numbers, but the system still matches multiple possible destinations (patterns) and must wait to see if more digits will be entered or if it should pick the best match with the current dial string.
Here’s a simple example. Let’s say I allow users to dial each other internally via 4-digit extensions. The CEO has also determined that to make life easy for end users they should be able to dial a 10-digit number to reach PSTN dialers so that their office phone works just like the iPhone in their pocket. So I decide to call Deb at extension 6515. The system matches this, but also recognizes that I have a pattern 651[2-9]XXXXXX to route calls local to St. Paul, MN out the St. Paul site’s gateway. Deb’s 6515 extension has the same digits as an Irish pub in St. Paul, MN with a phone number 6515551234. Because of this, it must wait a few seconds to see if I will enter more digits to dial that Irish pub where a tall, cold glass of Guinness awaits or if I really intended to dial Deb. This is very confusing to users who are not used to hearing silence or waiting for the phone to start playing ringback. Chaos ensues and the help desk manager just started researching office pranks to exact revenge on the voice team.
Let’s apply this to UCM on a larger scale. In any UCM we likely have thousands of potential patterns that exist as DNs, Translation Patterns, and Route Patterns. To incur interdigit timeout we need variable length patterns. If every pattern was 4 digits long the system would never need to wait to see if there is a 5th digit. Once we have variable length patterns we can quickly eliminate overlap (which causes interdigit timeout) with a different leading digit. This is why you often have PSTN access codes (e.g. dial 9 for an outside line). I like to create a Leading Digit chart to help understand potential areas for overlap. This requires knowing all extension ranges, DID ranges, PSTN patterns, etc. and might look like this.
- 0 – Reserved for Operator
- 1 – Extensions at Site1 – 4 digits, 1000-1499
- 2 – Extensions at Site2 – 4 digits, 2700-2799
- 3 – Extensions at Site3 – 5 digits, 30000-31999
- 4 – Extensions at Site4 – 4 digits, 4000-4999
- 5 – Open
- 6 – Open
- 7 – Open
- 8 – Extensions at Site5 – 4 digits, 8100-8199
- 9 – Reserved for PSTN Access Code
- * – Reserved for feature codes
- # – Reserved as end of dialing string termination character
- + – E.164 Prefix
This is a pretty concise way of showing where we have room for expansion when ordering new DID ranges to make them fit in the existing dial plan without overlap. The example above is an ideal situation with some leading digits completely open and some with plenty of room for expansion.
Many large enterprises don’t have this luxury. As often as I have a small company with an ideal outcome in their “Leading Digit” analysis I have another company that states, “We have 50 sites with a mix of 3, 4 and 5 digit extension dialing that start with every digit, 1-9”. Often that company is moving from many disparate phone systems at each site to a single, centralized phone system for all sites. It’s easy to explain that some changes need to occur to make this work when all sites must be taken into consideration. What isn’t so easy is getting end users (and execs) to accept these changes. We try to find the change that will have the smallest impact.
What techniques can we use to avoid interdigit timeout issues? Here are a few examples:
- Implement a site access code. Each site has a 2-digit site code followed by a 4-digit extension and some renumbering may be required.
- 22 1234
- Use a prefix character like *. This is very similar to the idea of a site access code, but a slightly different track. It essentially moves a client on an existing 4-digit dial plan to a 5-digit dial plan and takes advantage of the fact that * is typically not used in dial plans or extensions today.
- Require a suffix or terminating character to signal to UCM that the user is done entering digits. The standard terminating character is #.
- Renumber the extensions at some sites to open up a leading digit like 9 to use as a global PSTN Access Code. Alternate: Buy more DIDs and renumber.
- Limit the scope of these shorter dial strings. Rather than allowing all users to 4-digit dial every other user allow 4-digit dialing only within a single site and calls to other sites require the full DID.
Generally I end up with some variation or mix of these options. In subsequent posts on dial plan design this topic of avoiding interdigit timeout will be a common theme. Next we’ll look at the ITU-T’s E.164 recommendation including it’s ability to help avoid interdigit timeout.
As a unified communications engineer who splits time between my home office, company office and my customer sites (sometimes at multiple locations in the same day) I need to carry my office with me.
For the last seven years I’ve used a Tom Bihn Empire Builder with matching Brain Cell for my laptop. It saw me through most of college, five years as a UC engineer and has traveled all over Europe and the US. It’s been attached to my hip every day for those 7 years and the thing is in fantastic shape. TB & co. make an incredible, durable product.
But things change. I carry a lot of gear and that gear is heavy. Often enough I end up doing a fair amount of walking during the day: either traveling around town, through airports, at conferences or doing site surveys for large office spaces, manufacturing plants, distribution centers and the like. The briefcase/messenger style Empire Builder is extremely functional and looks very professional, but with all that gear it was time to play nice with my shoulder & back.
I ended up with the picture to the right, a Tom Bihn Smart Alec. It’s awesome. A little smaller than the Empire Builder and smaller than I expected, but I think that was a good thing as it forced me to organize a bit better and be smart about what I pack. They have a saying at TB, “Siquid mantica non capit, domi relinquendum est.” translated to “If it doesn’t fit in your knapsack, leave it behind.” Good advice.
It has the typical Tom Bihn quality materials and construction and is extremely comfortable. The design is pretty slick too; placement and number of pockets is perfect. Check out the link above for more info.
So what do I lug around in this thing every day? I’m glad you asked. You’ll see I’ve turned into a bit of a Tom Bihn junkie. Starting at 9 o’clock on the left with the water bottle and moving clockwise:
- Starting in the left side pocket:
- Liberty Bottleworks Tom Bihn Matterhorn water bottle – replaced a slightly smaller Sigg water bottle. Although a little larger it still fits great in the side pocket.
- And there’s still room in the same side pocket for a TB Ballistic Organizer Pouch connected to the o-ring there. Size small (4th of July special edition) holding whiteboard markers… a good consultant brings their own 🙂 Disclaimer: I may like whiteboarding more than I should.
- On to the first of two sections on the main compartment:
- First another small organizer pouch connected to one of the o-rings in the main compartment holding an often used MiFi charger.
- A TB Cache holds my 15″ MBP (has an SSD so I opted for the Cache rather than the more protective Vertical Brain Cell, the space saving of the Cache vs Brain Cell comes in handy and I’m glad I waited to order until after I had my Smart Alec).
- Resting on the Cache is a TB Breve (appears to be discontinued, unfortunately) holding my iPad, iPad AV adapter, Verizon 4G MiFi and short micro USB cable to charge the MiFi from my laptop. Also tucked a few business cards and a TB Ultrasuede Screen Cloth above the zippered pockets (great way to make use of that space with some thin items you don’t need often).
- On the bag itself are my MBP power adapter and a MS Mobile Mouse 4000 (considering a switch to an Apple Magic Mouse) that go into the two zippered pockets on the main opening.
- To the right are two more TB Ballistic organizer pouches, size small. One in the main compartment holding Koss KSC75 headphones.
- On to the side compartment:
- The second small organizer pouch mentioned above is in the side compartment holding a couple USB thumb drives and a CF card reader (great for upgrading IOS and transferring files on Cisco ISR’s and VG224’s)
- Also in the side compartment: eye drops to keep the contacts lubricated during late night cutovers, mints, pens and few other odds and ends.
- Below the bag are a few more items that go in the main compartment.
- Starting on the right is a TB Snake Charmer (awesome) that holds all kinds of cables. Cat6 network cable, HDMI cable, USB extension cable, Monoprice mini DisplayPort adapters (HDMI, DVI, VGA), mini USB cable, micro USB cable, KeySpan USB Serial Adapter and a Monster Outlets To Go power strip with a USB charging port.
- Bottom middle is a TB Vertical Freudian Slip. Holds a legal pad, smaller notepad, Moleskin notebook, some pens. Still deciding if I really need this or would be better served by freeing up space in the main compartment. So far I think it’s a keeper for holding the notepads and other papers & receipts I seem to accumulate.
- Last on the bottom left are a couple items from Plantronics:
- First up is a Plantronics P420 USB speakerphone. I don’t use this one all that often, but when I do use it it’s a lifesaver. Quality on this thing is phenomenal and works great for impromptu conference calls. It’s worlds better than your cell phone’s speakerphone.
- Next is a corded headset, a Plantronics SupraPlus wideband headset with Quick Disconnect adapter. I actually prefer this model to their newer EncorePro line as the SupraPlus stays attached to my head a bit better. Along with that I have a DA45 USB adapter so I can use it with various softphones on my laptop and an AC10 adapter so I can connect it directly to the headset port on a Cisco phone.
- One item that didn’t make it into the picture as I transitioned between bags and recovered from a trip with the family this weekend was my NIV Thinline Bible. I use the Glo Bible and Logos apps on my iPad, but the hardcopy is nice to have around and great for takeoffs and landings when flying.
That doesn’t account for my toolkit bag. I try not to do a lot of cabling and tracing wires, but it does come in handy to have a punchdown tool, test set, etc. in the trunk of my car. A topic for another post…
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.).