8800 Handset Firmware 11.0(1)

One common criticism of the 8800 10.x firmware was it’s behavior in truncating Line Text Labels when there was ample space on the display to show more characters.  Version 11.0(1) fixes this:

 

IMG_5212

 

(Sorry for the mediocre photo.)

The Line Text Label supporting 30 characters (the maximum supported in the LTL field in CUCM) on a single line on the display.  There’s some cool stuff coming in the next release of code which will add even more functionality to the 8800 series.

Firmware 11.0(1) adds the following features:

 

The highlights being the ability to use the BIB for Barge, and official support for MRA.

 

Advertisement

DX 10.2(5) Firmware Released

Are you about ready to throw your DX out the window because dialing with the Phone app is an unresponsive nightmare as it tries to do a lookup on every call it’s ever made?  🙂

Well the fix is out.  The Phone app is revamped and actually doesn’t suck.

I’ve been running the 10.2(5) beta firmware for a few weeks and have been much happier with my DX80 and 650.  The final build is now out.

Would you like the DX to stay on your PC input when a call comes in?  It finally does!

Would you like HDMI audio from your PC to actually come out the DX speakers?  You got it!

Release notes are here.

One thing to note for MRA users.  The DX only trusts public CA certs like the 8800 series now.  So if you’ve deployed your Expressway-E with private certs, you’ll bust MRA on the DX if you dont move to public certs.

Catalyst 3850 IOS 16.1.1

Upgraded my 3850 to Denali 16.1.1 today. The new unified web GUI for the whole switch is pretty slick.  There are a ton of new features. See the Release notes here.  Now this is the first release of 16 so I don’t know I’d jump on it for a production network until there is a bug fix rebuild, or at least without checking the open caveats.

I ran into a problem that the APs would register, the radios just wouldn’t come up. Nothing I tried in the GUI (like bouncing the radios between disabled and enabled) would get them to go Operationally UP.

Turns out the secret was to go into the guy and do a “no ap dot11 5ghz shutdown” and a “no ap dot11 24ghz s.”  The radios came right up and everything is working again.

Registering an SX-10 (and TC-based endpoints) through Collab Edge MRA

Recently I worked on an MRA deployment using SX-10, MX-300 and DX-series (650/70/80) endpoints.

I had Expressway-C and E working successfully for 8800 series MRA, but needed to get the TC-based and DX-based endpoints to register.  This turned out to to involve some issues that I wasn’t expecting.

TC-based endpoint registration

There isn’t a lot of documentation  for TC endpoint registration through MRA (since traditionally it’s been registered to VCS through VCS-E).  The best documentation that I could find was here:  http://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/118696-config-cucm-00.html

I began the deployment by registering the MX-300 I use directly to CUCM to make sure I had it successfully working before attempting registration through MRA.  I’d previously had it registered to a VCS-C.

MRA requires TC 7.3 code, so I decided to deploy 7.3.4 since it is the latest bugfix version.  I downloaded and deployed the COP file to CUCM since CUCM will be in control of what version of software the TC endpoint will use once it’s registered to CUCM (like typical phones get firmware).

Note that TC 7.3.3 or greater firmware have different functionality for remote screen monitoring of systems!  TC 7.3.3 introduces the requirement to have an option key for remote system/screen monitoring of the TC endpoint.  You’ll need to work with TAC/Cisco to get option keys cut if you are doing remote screen monitoring before going to 7.3.3+.

Registration to CUCM was straightforward.  I defined the device on CUCM as you would normally define a phone, picking the appropriate SIP profiles.  I didn’t do secure registration as this is optional.   (The documentation above does mention that secure registration is optional, but the example works through a secure registration.)

I made sure to set the device association my end user in CUCM.  This is important for MRA later.

Once the MX-300 was registered and making calls successfully through CUCM, I moved it out to a general internet connection to work on MRA.

On the touchpanel I launched the Provisioning wizard and selected Cisco UCM via Expressway.  After putting in my credentials I was greeted with this error:

IMG_4257 copy

After doing quite a bit of research and looking at the detailed error logs from the MX-300, it turns out that your Expressway-E certificate must also include a SAN for the domain name itself (e.g.  yourdomain.com).  The error actually indicates that it wants a collab-edge.yourdomain.com SAN:

Edge TLS verification failed: Edge domain ‘yourdomain.com’ and corresponding SRVName ‘collab-edge._tls.yourdomain.com’ not found in certificate SAN list.

The challenge I had is that the certificate I’d bought from GoDaddy for Expressway-E (that was working with 8800 MRA) wasn’t a UCC or multi-SAN certificate and you need to have at least the Expressway-E as the CN and the domain as a SAN.

At this point I decided that it was time to move from GoDaddy to DigiCert since they have unlimited resigning of certificates without having to revoke any of them.  This essentially allows you to create as many certificates as you want without having to keep buying more like GoDaddy.  I bought the Wildcard Plus certificate and used it to create a multi-SAN certificate for my Expressway-E.  The CN is always *.yourdomain.com, but you can add a bunch of SANs (like 20 or so.)

I generated the certificate with the following SANs – edge.yourdomain.com, yourdomain.com, collab-edge._tls.yourdomain.com and _collab-edge._tls.yourdomain.com.   One of the partner engineers that I talked to said that he got it working without having to add either collab-edge SAN.  (I’ve not looked into why/when we’ll need the collab-edge SAN and if it is actually be collab-edge as the error indicates, or if it needs the preceding underscore on collab-edge like the SRV records have.)

After applying the certificate to Expressway-E and rebooting it I tried the provisioning wizard on the touchpanel again and was greeted with the SAME ERROR.

It turns out that I hadn’t included the DigiCert root and the DigiCert Intermediate cert in the list of Trusted CAs on the endpoint itself.  The documentation indicates how to install it here – http://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/118696-config-cucm-00.html#anc10  Make sure you have both root and intermediate (if the CA you used signs with an intermediate) on the TC endpoint.

After this the MX-300 registered like a champ and is able to do calls.  I followed this same process to get an SX-10 registered as well.

The partner engineer I talked to said he had to work through a couple issues on his test:  1) Endpoint rejecting the user credentials when running through the provisioning wizard.  Make sure the endpoint is associated with the End User and that the end user has CTI Enabled and CCM End user.   2) Getting an http download error after getting through the initial expressway authentication and that it was caused by the endpoint needing to do a _cisco-uds.yourdomain.com lookup internally to find out where CUCM is to download it’s configuration.   He was in a split domain situation and didn’t have a _cisco-uds record for the external domain on the inside.

I’ll detail the adventure for the DX-series on another post.

 

 

 

 

Expressway 8.5.2+ MRA Issues

I’ve run into a couple challenges after an upgrade to Expressway/VCS 8.5.2 where MRA for phones quit working.

I found a bug that broke MRA in 8.5.2 (the recommendation has been to downgrade back to 8.5.1).  That bug is shows that it is now fixed in 8.6, so I upgraded to 8.6.1 recently.  MRA started working again, but only on one out of every three login attempts.  It was really weird.  In looking at the logs it showed a bunch of errors:

Home CUCM not available – Unknown CUCM cluster for node sub02

Home CUCM not available – Unknown CUCM cluster for node sub03

The deployment I was working on is a three node (pub and two subs), running split DNS (different internal domain than the external domain name).

After a lot of digging it turns out that there is a change in the way MRA handles CUCM lookup.  When I installed the system added my pub and subs to Expressway-C by IP address.  But it looks like Expressway now attempts to communicate with them via hostname, and not IP as they were defined by me.

Since Expressway is using the domain suffix assigned to MRA (extdomain.com), it is attempting to lookup sub02.extdomain.com and sub03.extdomain.com.  I didn’t have A records for these on my internal DNS server extdomain zone since I’ve never needed to resolve them by the external domain name.

Adding these two records fixed the login issue and it now logins on first attempt like it used to.

CCX and Logjam

The latest versions of Firefox and Chrome seem to have fixed the Logjam vulnerability which is causing issues logging into the CCX admin page.

Here’s the workaround:
>> Now for logjam exploit related to the Diffie-Hellman algorithm the workaround in place is as below :
1)    In FireFox, enter “about:config” in the URL field and press enter.
2)     Accept the “This might void your warranty!” warning
3)     In the search field at the top, enter “security.ssl3.dhe_rsa_aes”
4)    Double click each result (128 and 256) to toggle the Value to “false”

After accessing the page and doing what you need, you’ll want to set them back to true or you’ll be vulnerable.

Another option is to keep a copy of the worlds greatest browser ever, Firefox 24, installed for accessing CCX.  😉

CUCM 11 has posted to CCO

Good news.  CUCM 11.0(1) is availabe on CCO:

https://software.cisco.com/download/release.html?mdfid=286284802&flowid=74823&softwareid=282074295&release=11.0%281%29&relind=AVAILABLE&rellifecycle=&reltype=latest

CUCM IM&P (CUP):

https://software.cisco.com/download/release.html?mdfid=286287586&softwareid=283757588&release=11.0%281%29&relind=null&rellifecycle=null&reltype=null&i=rn

Unity Connection:

https://software.cisco.com/download/release.html?mdfid=286286362&flowid=74822&softwareid=282074295&release=11.0%281%29&relind=AVAILABLE&rellifecycle=&reltype=latest

 

Links are live again as of 6/30.

23:59:60 – The leap second you don’t really want.

It’s that special time when the ER&RSS decides we need an extra leap second.  I’ve not looked into the details, but instead of the clocks going from 23:59:59 to 00:00:00 the night of June 30, 2015, there will be an extra second added: 23:59:60.  Of course computer clocks aren’t going to appreciate a second called “60” that is outside the normal range of 0 to 59.

At the direction of the International Earth Rotation & Reference Systems Service (see their bulletin here), the leap second will be introduced after 23:59:59, 30 June 2015. In effect, the clock will read 23:59:60 before it rolls over to 00:00:00, 1 July 2015. This is a one-time event that occurs simultaneously across the globe.

What products will be affected?  Unfortunately a lot from all kinds of manufacturers.

Cisco has a list of products here — http://www.cisco.com/web/about/doing_business/leap-second.html#~ProductInformation,

I would pay very close attention as the result of this 61st second in many of the bugs listed is the system crashing or hanging. Check your product versions against the bug lists.

A quick glance of products I work with regularly the following products affected:

  • CUCM < 8.0
  • CUC < 10
  • CER < 11
  • VCS/Expressway < 8.5.2
  • UCCX < 10.5
  • UCS-Manager < 2.2(3e)
  • Nexus 9000 = 7.0(3)I1(1.179)

Take a look at the list and implement the various patches or workarounds to avoid undesired outages.  Fun fun!

http://www.cisco.com/web/about/doing_business/leap-second.html#~ProductInformation,

8845 and 8865 720p Video Phones Announced

Great News!  The 8845 and 8865 phones have been announced.

Picture1

Ignore those labels above!  Both the 8845 and 8865 are available in white or black.

These phones follow the 8800 series features and functionality but add 720p video.  I’ve got a customer on the EFT for these phoens and they are fantastic.  The quality is outstanding when calling from the new models into a large telepresence unit in comparison to the VGA output of the 8945.

See the press-release here:

https://blogs.cisco.com/collaboration/say-hello-to-our-new-advanced-video-ip-phones

The basic difference between the models is the 8865 having WiFi and the ability to add KEM modules.  The 8845 is indented to be a successor to the 8945 and the 8865 a successor to the 9951/9971.

Datasheets are here –

http://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phone-8845/index.html

http://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phone-8865/index.html

Collab Edge MRA for 7800/8800/DX Series Endpoints

Cisco recently posted Expressway (and VCS) X8.5.2 and 10.3.1 firmware for the 8800 and 7800 series phones.  The combination of these products allows these phones to register remotely to CUCM utilizing Collaboration Edge MRA.  (The DX-series (650/70/80) is expected to support MRA in the next release of code due out shortly.)

This functionality isn’t TAC supported yet, and has been released in a “feature preview” form.  I’ve set it up and tested it and it works well for the most part.  However, there is not full feature parity for a phone registered via MRA vs directly registered to CUCM, but for testing and basic calls, it works well.

In order to set it up, make sure your Expressway MRA deployment for Jabber is working properly.  MRA for the 7800/800 series phones uses the same service discovery process that Jabber uses, so if you have Jabber working, you’ll have 95% of the work done.

One important piece of information to know is that the phone firmware trusts 100+ public root CA certificates.  If your Expressway-E server does not have a certificate signed by one of these CA’s it’s not going to work for the phones.

Here’s the basic procedure I followed to make it work:

  1. Installed the 8800 10.3.1 COP file via OSadmin and restarted the TFTP service.
  2. Logged in to Jabber via MRA to ensure the correct functionality of my MRA system and my login credentials.
  3. Defined the phone in CUCM and then connected the phone directly to CUCM so that it would pull the version of firmware that supports MRA.  (My 8851 phone shipped with an older version of code that did not have MRA support.)
  4. Took the phone off of the corporate network to an internet-access only network.
  5. I had initial problems with the phone not attempting MRA lookup after being connected to the internet-only network, so I followed the troubleshooting process of resetting the Network settings on the phone.  It then started to try the MRA process.

Steps the phone follows in MRA registration:

1) Phone attempts normal TFTP registration/_cisco-uds._tcp.domain.com lookup process:

IMG_1456

This fails because the phone has no direct access to CUCM.

2) Firmware now prompts for MRA credentials (These would be the same credentials you use for Jabber MRA login — in my case it is set to use LDAP/AD for authentication):

IMG_1458

Phone now attemps  _collab-edge._tls.domain.com service record lookup (like Jabber does) to discover the Expressway-E/VCS-E host.

3) Phone completes MRA login process

IMG_1459

The phone is now registered and usable.

I’ve read conflicting information about the number of calls supported, and number of lines supported via MRA.  In my experience I have two lines on the phone registered and am able to make two calls per line.  (I’ve not tested more than two calls per line.)  The list of features that may work or not is extensive, so be careful as things like Barge or Intercom may not work yet.

The phone also upgraded code via MRA successfully which is good to know.

IMG_1454

I’ve noticed some oddities with on-hook vs. off-hook dialing.  I know there are some limitations around KPML currently.  In my experience it seems to off-hook dial fine on the primary line, but on a secondary line or when attempting a second call on the primary line you MUST on-hook dial.

Phone registration isn’t supported via TAC yet so feel free to post here and we can collectively attempt to assist.  Remember the most basic step to troubleshoot is to see if your Jabber can successfully login.