CSCvf07153 Cisco CUBE uses incorrect timezone in SIP messages
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"
Dial Plan Design: A “Delightful” End User Experience
- Interdigit Timeout
- E.164
- 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
- etc.
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”.
Secure Conductor with CUCM Deployment Guide Fixups
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.
Okay, so let’s just use that next checkbox, the one that says Override SIP Trunk Destination as HTTP Address.
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,1.3.6.1.5.5.7.3.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 []:collab@widgets.co
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, CN=collab@widgets.co/emailAddress=collab@widgets.co
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, CN=collab@widgets.co/emailAddress=collab@widgets.co
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/CN=collab@widgets.co/emailAddress=collab@widgets.co
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 root@conductor.widgets.co 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 ben@10.10.10.1://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.
Related Cisco Bug IDs: CSCut22572, CSCuq90392
ISR 4000
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.
ISR 4000 Family – Cisco.com
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).
NIM T1 Modules – Cisco.com
- PVDM4. Cisco launches their 4th generation DSP. As mentioned it comes in a new form factor th
PVDM4 Module – Cisco.com
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 |
| 4451 | 1050/2000 | 6000 | 30-35 | 2000 |
| 4431 | 500/1000 | 3000 | 25 | 1200 |
| 3945E | 350 | 2500 | 35 | 1500 |
| 3925E | 250 | 2100 | 30 | 1350 |
| 3925 | 100 | 800 | 10 | 730 |
| 4351 | 200/400 | 1000 | 7-9 | 750 |
| 4331 | 100/300 | 400 | 6-8 | 100 |
| 4321 | 50/100 | 100 | 3 | 50 |
| 2951 | 75 | 600 | 3 | 250 |
| 2921 | 50 | 400 | 2 | 150 |
| 2911 | 35 | 200 | 1.5 | 100 |
| 2901 | 25 | 100 | 1 | 35 |
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.
Dial Plan Design: No Device/Line?!
- Interdigit Timeout
- E.164
- DN Length
- Localization and Globalization
- No Device/Line?!
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.
Dial Plan Design: Localization and Globalization
- Interdigit Timeout
- E.164
- DN Length
- Localization and Globalization
- No Device/Line?!
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.
Dial Plan Design: DN Length
- Interdigit Timeout
- E.164
- DN Length
- Localization and Globalization
- No Device/Line?!
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:
- +1000001XXXX
- 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.
Dial Plan Design: E.164
- Interdigit Timeout
- E.164
- DN Length
- Localization and Globalization
- No Device/Line?!
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.
- +16515551234
- +441122334455
- +4904511234567
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
Dial Plan Design: Interdigit Timeout
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.
- *1234
- Require a suffix or terminating character to signal to UCM that the user is done entering digits. The standard terminating character is #.
- 1234#
- 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.
The Mobile Office
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…
benpolzin 