CE 8.2 code on the DX70 and DX80

***UPDATED***  The Devpack, CE8.2.1 and conversion cop are now available on CCO.

CE 8.2.0 firmware for the DX70 and DX80 posted to CCO today.  (But of course we’re still waiting for the Devpack with the QED that will be released in the next week or so.)  The release notes are here.  The Official Conversion Guide is here.  Any instructions in this guide would override what I’ve said.

I’ve been running the beta for the last few weeks and can absolutely say CE code on the DX is MUCH more responsive, stable and usable than the Android-based code.  (That said the last few builds of 10.2(5) android code have been pretty decent.)

CE 8.2 code is absolutely the code to move to if your primary use for the DX is for video calls.

 

File_000(1)


Why move to CE on the DX?

  • Responsiveness.  No more lag!  It’s snappy.
  • Stability.  Seldom, I had the random crash and full-reboot during video calls with Android.  While it was pretty rare, it was super frustrating.
  • Video-centric user interface.  It run CE codec code now and feels like a Cisco codec (like SX10, 20, etc.) now.  It’s all about the video call.
  • Registration to VCS/Expressway
  • Far-end Camera Control
  • OBTP (one button to press) meeting launch and TMS management
  • Fully customizable wallpaper


Why stay on Android?

  • You need Android applications.  CE doesn’t run any apps, period.
  • You use the built-in Cisco Webex and Jabber Android apps on the DX.
  • You need a local web browser.  CE doesn’t have a web browser built in.
  • You are currently using Wi-Fi or Bluetooth.  The CE code doesn’t yet support Wi-Fi or BT.  (That’s coming in a follow-on release.)
  • You need telephony features on the phone like CFwdAll, Shared Lines, Voicemail button, Auto answer.

What happens to Android?

Android will be supported on the DX70 and Dx80 for the life of the product.  Keep running it if you need features that will always only be specific to Android (local web-browser, Android Apps).  The DX650 will remain Android-only.

Converting to CE Code using CUCM

Note: You have a couple options to convert to CE code.   CUCM of course or, as the conversion guide notes, there is a public TFTP server on the internet provided by Cisco to convert a DX using.  As far as CUCM, you can convert the DX either onnet or connected via MRA registration through Expressway.

  1. Upgrade to the latest build of Android code – 10.2(5)207 by installing the COP file on CUCM, restarting TFTP and rebooting your DXes.  (Either way you want to go to this code because of all of the bugfixes.)
  2. Install the latest (Early July 2016) Devpack:
    CUCM 11.0.1:  cmterm-devicepack-11.0.1.22048-1.cop.sgn
    CUCM 10.5.2: cmterm-devicepack10.5.2.14076-1.cop.sgn
    CUCM 9.1.2: cmterm-devicepack9.1.2.16137-1.cop.sgn
  3. Install the Devpack on CUCM as well as cmterm-synergy-ce8_2_1_no_defaults.cop.sgn (or latest version) so that it gets the Telepresence DX70 and Telepresence DX80 device type QED installed.  Reboot your cluster.  (Unless you’re on CUCM 11.5 which doesn’t need the immediate reboot!!)  Or bug someone you know for the standalone CE 8.2 QED in the meantime.
  4. This devpack should have the CE 8.2 firmware, but if not install the CE 8.2 COP file – mterm-s52040ce8_2_1.k3.cop.sgn (or current); restart TFTP.
  5. In CUCM, change the Phone Load of the existing DX80 to the CE 8.2 phone load name specified in the conversion guide.  For 8.2.0 it is sipdx80.ce821.rel.loads
  6. The DX80 will take a few minutes (10-15) to upgrade to CE 8.2.1.
  7. Take note of the MAC address of the DX80 in the CUCM device, because you are about to DELETE the DX80 device!
  8. Delete the DX80 device from CUCM.
  9. Create a new Telepresence DX80 device in CUCM and paste in the MAC address of the DX80 you just deleted.  Set the appropriate device settings and add an extension/SIP URI to the device.
  10. On the DX80 itself, run through the startup wizard and pick UCM registration or UCM through Expressway (if your endpoint is registering through Expressway).
  11. You’ve now got a DX80 on CE 8.2 code
  12. Enabled Web Access in CUCM device settings so that you can get to the DX80 GUI.
  13. Login to the GUI and set the admin password.  (This step may not be needed, setting the admin username/password was not available in earlier CE betas via the CUCM device setting page.)

 


Other Notes

  • The Touch 10 doesn’t work on the DX80 or Dx70, you must use the built-in touch screen on the DX.

8800 Series 11.5(1) Firmware – Enhanced Line Mode

11.5 firmware for the 8800 series phones is on CCO now.

It comes with a bunch of cool new features.

Enhanced Line Mode

The coolest and most useful that I’ve seen requests for is the new Enhanced Line Mode.  (I’ll abbreviate it ELM even if there’s overlap with the PLM/ELM acronym.)  ELM allows all 10 buttons on the phones to be used a programmable line keys (PLKs).

The mode we’re used to includes 5 PLKs on the left, and 5 context-sensitive function keys on the right.  I like this mode, having gotten used to it back in the day with the 9900 series phones, but hear customers who need more than 5 PLKs (in particular for admin/receptionists who want more than 5 BLFs or Shared lines).

 

File_000

As you can see in the picture, I can now use all 10 buttons.

While the firmware is out now, there is a Devpack required to enable the ELM feature on the device configuration page.

The release notes indicate that you should get the latest Devpack from CCO, install it and reboot the cluster to enable the ELM setting.  The challenge you’ll hit is that the latest Devpack on CCO as of today (mid-June) doesn’t actually include the QED file that enables the ELM setting.  The Devpack that inclues the QED will release in the next couple weeks.

Look for a Devpack with a late-June/early-July date stamp if you want to turn this feature on.

Enhanced Do Not Disturb

The DND function has been updated to be much more obvious which is nice.

File_000(1)

Other features to mention:

  • Wi-Fi Security Enhancements
  • Customized Dial Tone for SIP Phones

See the release notes for more information about the last two.

 

 

Adventures in Upgrading to CSR 11.0

Now that all of the core CSR 11 components have had a service release under their collective belts, it’s go-time.  I helped a customer upgrade CUCM, IM&P and CUC from 10.5 to release 11.0.

  • CUCM/CUC 11.0(1a)SU1
  • CUCM IM&P 11.0(1)SU1
  • Jabber for Mac and Windows 11.5
  • Latest DX-series/8800 firmware
  • Expressway C/E X8.7.1
  • CWMS 2.6 MR1 Patch 1
  • Security COP to address CSCuy07473 for CUCM 11.0(1)
  • Permanent Licensing Surprises
  • Holding UCCX at 10.6 for now…. (Agent/Supervisor issues)

 

CUCM 11.0(1a)SU1

This is a four node system (pub and 3 subs) running the latest 10.5 SU.  Upgraded the pub during evening hours and told it not to reboot the night before.  Once it had completed the upgrade, I ran the upgrade on the three subs and told them not to reboot.  The maintenance window was the next evening, so we didn’t make any changes during that window.

When trying to reboot the pub to the new version from the GUI it got into an ugly loop.  Switch version reported that an upgrade was still in progress.  Went to the upgrade menu option and it indicated that I had to assume control over the upgrade.  Did so and the log file showed that the upgrade had completed successfully and that the lock files were released.  Went back to switch version and it still indicated that it was in an upgrade…

Bailed on the GUI and issued the version switch from the CLI.  It didn’t complain at all and did the version switch from 10.5 to 11.  It was a faster process than I imagined, taking less than 10 minutes to reboot on 11.  I was a bit concerned if it was going to work given the GUI seeming to be in a loop, but it rebooted just fine.

I rebooted the subs all from the CLI since I didn’t (and now perhaps don’t trust) the GUI switch version.  They all rebooted quickly too and were up and running on v11.0

Important!  Please note that the OVA release notes indicate that the RAM should be upgraded to 6GB for the CUCM and CUC VMs – http://www.cisco.com/web/software/283088407/126036/cucm-11.0.ova.readme.txt.  This was pointed out by a kind reader, which I hadn’t noticed until my CUC was falling apart after the upgrade.  Moving this VM to 6GB was an immediate fix.

CUC 11.0(1a)SU1

This was a textbook upgrade that evening.  I’d prestaged 11.0 like CUCM and the reboot took about 15 minutes.  All was well until I applied the permanent licensing.  Which I’ll cover later

IM&P 11.0(1)SU1

I wasn’t able to pre-stage this upgrade so ran it the evening of the maintenance window.  It’s a fairly small system so it took about an hour to upgrade and reboot.  The reboot seemed excessively long and I was worried, but it came back and workstation Jabber  clients automatically connected.

In conjunction with this upgrade I updated my jabber-update.xml file and push out the latest 11.5(2) version of the Mac and Windows clients.  We also updated all of the user photos on the webserver that houses them to current pictures.  Jabber was hit and miss about actually pulling the new picture.  It seemed that you had to manually view the profile on some users to get it to pull the new picture.

Latest DX/8800 series Firmware

The DX-series firmware has been a bumpy bumpy bumpy road.  It’s finally pretty stable as of 10.2(5)154.  A newer 10.2(5)195 is out so I pushed that out as it has a number of bugfixes.  I also updated the photo location for the DX-series phones and they all now pull the photos correctly from the webserver that houses them.  The super secret URL to put in the Company Photo Directory is this:  http://<webserver ip address>/%%uid%%.jpg

I migrated the DX-es from Anyconnect VPN over to MRA through Expressway that night since this latest ASA Sev 10 Bugfix upgrade has caused an odd cert issue for the DX (not not normal Anyconnect software clients on other platforms).  Remote phone control does work properly from Jabber (that is VPNed in) to the phone that is connected via MRA.

CUCM 11.0 default firmware also had older firmware for the 8800 series phones so I pushed the latest 11.0 version and am anxiously awaiting 11.5 for some really cool upcoming features for the 8800 series.

Expressway C/E X8.7.1

Textbook upgrade.  I love the software that came from Tandberg.

CWMS 2.6MR1 Patch 1

This is still my favorite app to upgrade by miles.  Attach the ISO to the Admin VM in vCenter and press go from the GUI.  An hour or so later after a couple reboots of all the various VMs (Admin, Media, IRP) you kick it back out of maintenance mode and you’re done.

Security COP to address CSCuy07473 for CUCM 11.0(1)

This patch JUST released with the latest security fixes for CiscoSSL (a ciscoized variant of OpenSSL).  Install on each CUCM node and you’re done.  No reboot required.

Permanent Licensing

After upgrading everything to 11.0 everything kicked into 60-day temp license mode as expected.  (Upgrading to CSR 10.5 was bad news when it didn’t do what it was supposed to and CCX ate all of it’s licenses resulting in a P1 case.)

The TAC case for licensing was pretty straightforward.  Had permanent licenses in about a day after providing the contract number that showed SWSS.

I held of installing the permanent licenses until after hours in the event that something would go wrong and take the system down (still nervous after the CCX incident).  Installation went fine with one side issue.

I had complaints about SpeechConnect / voice enabled directory handlers on Unity Connection not working right.  Turns out CUC didn’t like the permanent licenses as far as SpeechConnect.  It had pulled the licenses from ELM/PLM properly and was in compliance, but it took a restart of the Conversation service for it to start doing the voice recognition stuff again.  Rather odd.

Holding at CCX 10.6

Since 10.6 is the last version of CCX to support CAD/CSD and Finesse, I’m working to migrate the contact center over to Finesse.  There are some usability complaints we’re working through.  The users love the idea of a dedicated app that pops when a call comes in as well as the agent-to-agent chat inside CAD.  Getting them to use a web-browser for Finesse has been a challenge.   Once I have those details ironed out we’ll force them into Finesse when we upgrade to CSR 11.5 in the summer.

 

 

 

Deploying Multistream Conferencing with vTS and CUCM

With the release of CE8 code for Cisco video endpoints (like the SX10 (8.1), SX20 (also MX200-G2 and MX300-G2) and SX80-based endpoints like the SX80, MX700 and MX800), and the appropriate infrastructure components, multistream video is a possibility.  Multistream video allows an endpoint to send multiple resolution video streams and have the bridge pass the most appropriate streams to the far-end video units.  The far end video unit would receive a full resolution stream of the active speakers, and then low quality streams of the other participants.  The most useful feature of multistream video is the ability to use both screens of a dual-screen video unit to see remote participants (when doing single-stream transcoded mode, you can only do single screen video, and secondary screen content.)  Multistream also allows for ActiveControl layout, which allows the endpoint to choose the video layout vs. the video bridge determining the layout of the participants (which has rudimentary DTMF layout control).

Components used in my lab configuration:

  • SX10 (CE8.1)
  • MX800 (CE8.0.1)
  • (2) 8845 video phones (used to inject more video streams — these endpoints do not support multistream, they do single stream and receive their layout from the bridge)
  • Conductor XC4.1
  • vTS 4.2(4.23)
  • CUCM 11.0(1)21900-11 (Latest and greatest version is a requirement) -or- VCS X8.7.1

This guide assumes you’ve already setup a Rendezvous (aka MeetMe) number/URI that is routed to Conductor/vTS and you’re able to to normal conference calls.  We’ll modify settings to enable multistream.

Guide to configure endpoints and CUCM SIP Profile – http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/solutions/cmrpremises/cmr-premises-deployment-guide-r6-0.pdf

The relevant portion of this configuration is to make sure your SIP trunk to conductor is in a Location that supports full quality video.  I sent the inter-region bandwidth to UNLIMITED in my test system.  Cisco recommends a minimum of 1mpbs per screen, otherwise the vTS bridge may kick that video unit down to single-stream transcoded mode.

Configure the endpoint to support multistream

In CUCM the setting is in the device specific settings, Multistream Mode needs to be set to Auto.  Despite some of the documentation reading otherwise, Auto will attempt to do multistream, there is not actually an On setting.

Configure CUCM

Configure the SIP Profile used by the SIP trunk to Conductor to include the following settings:

  • Allow iX Application Media and Allow multiple codecs in answer SDP are checked on.
  • SDP Transparency Profile is set to Pass all unknown SDP attributes

In System > Service Parameters > Call Manager Service > click advanced > set SIP Maximum Incoming Message Size to 18000.

Configure Conductor

On the Conductor server, under the Conference Template you’re using for your conference, select advanced template parameters and add:

  • Enable iX protocol – True and the box checked
  • Multiscreen layout – ActivePresence and the box checked

No settings on vTS need to be changed, it will automatically do multistream if the endpoints meet the requirements, and CUCM (or VCS) and Conductor are properly configured.

When you join with a multi-stream endpoint you will see the following on vTS Conferences page:

 

vts1

You’ll notice the endpoints that support multistream show Multistream, and the 8845 phone named “Mike White” is Standard because it only supports a single stream.

If we look at the statistics for 5580 (the SX80) you’ll see multiple video streams being sent and received:

vts2

 

Lastly if we look at the call statistics from the video endpoint itself, we see the same information:

endpoint1

 

The touchpanel now shows more details in the layout.  You can see each participant in the conference and the active speaker.

IMG_5313

 

While you can select from several canned layout modes (same typical layouts are you’re used to), this version doesn’t yet support complete drag and drop layout of individual participants where you want them.  If you select a particular participant, you can see information about any of the participants and boot them if you are meeting organizer:

IMG_5314

 

Overall its very cool, and sets the groundwork for much more flexibility in the future with layout control.

 

IMG_5315

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.

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.

 

 

 

 

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.

WebEx Event Center Mobile Support

Yes, it must be a sure sign of the apocalypse. Event Center is finally supported on iOS and Droid. Imagine being able to join an event center hosted Webex meeting from the road… I’ve only been asking for this for the last five years. 🙂

Upgrade to Webex 7.0 client and WBS 29.8 and life will be as sweet as candy.

The more important feature in 7.0 is management of your Personal Meeting Room (WBS 29.11).

I’ll detail PMR soon, but it is a huge step forward in making it easy for people to join Webex. Your PMR meeting ID/URL is always stays the same. No pesky meeting IDs to remember. You can join from video phone, TP unit (think DX, EX, SX, etc.), or any Webex client.

Intelligent Proximity for Telepresence endpoints

TC 7.1.2 code was recently posted to CCO.  This version of code supports the experimental (or feature preview) “Intelligent Proximity” feature.  This feature allows your Apple iPad or iPhone (iOS 7+) to pair with the endpoint (C, EX, SX, MX-series) using “ultrasound” (~21kHz), perform simple call control (dial/answer), and view content being shared by the device on your iPad/iPhone.

Administrator Configuration

  • Login as administrator to the telepresence codec that you want to enable the feature on.
  • Make sure it is on 7.1.2 code.
  • Under System Configuration search for byod
  • Turn the Mode to On

Note: the ultrasound volume is independent of the normal audio volume.  There are CLI configuration commands to change the volume of the ultrasound pairing signal.  The default is optimized for stand-alone (e.g. MX-series) room units.  I’ve had no problems making it work on a C40, SX20, Profile 55, MX 300 G2, and MX200.  If your codec is connected to an amplified room audio system, you may need to change the volume if you are having inconsistent results.

Ultrasound is used just for the pairing of the iOS device, not for content sharing or codec control.  Those functions are done over IP via the WiFi network.  Therefore, your iOS device will need to be on a WiFi network that has connectivity to the codec.

The ultrasound signal runs at about 21kHz which typically is a high enough frequency to stay in a single room.  It actually contains an encoded security token that validates that you are in the room currently.  If the ultrasound signal is no longer sensed, the IP connectivity will be dropped.  This is to prevent a user from seeing content on their iOS device without being present in the room.

 

End-user configuration/usage

Search for Proximity on the App Store and install it (free application).

Join a WiFi network that has connectivity to the Telepresence Codec.

Enter the room that the codec is in they want to pair with.  The Proximity app asks for permission to use their microphone.  This is a requirement so that the iOS device can detect the ultrasound signal from the codec.  If they deny permission to use the microphone the app will not work.

When the app hears the ultrasound it will connect via IP to the codec.  IF the codec is not in a call they will be allowed to dial or answer.  If the codec is in a call and content is being shared, they will see the content on their device.  Depending on the number of snapshots configured in the BYOD section, the user will be allowed to scroll back to see content they may have missed (if they came into the meeting late), or want to refer back to.

It’s very cool!

CUBE SIP Lineside Phone Proxy Configuration

Today I finally worked through getting a Cisco 9971 SIP phone to register to CUCM via CUBE lineside SIP proxy for a tech session I am presenting in a few weeks.   A few notes follow…

Go grab IOS 15.3(3)M2 code and put it on the router you’re using.

The CUBE Cisco Unified Communications Manager Line-Side Support configuration guide is a train wreck and has multiple errors and omissions.  Work through it but make the following changes…

From the Guide…

In the Configure a PKI Trustpoint section make on step enter the line as “crypto pki trustpoint self-trustpoint” (or another unique name that will be used below in a later step).

There is a critical step missing in this section.   Step 8 which actually enrolls the trustpoint.  Type “crypto pki enroll self-trustpoint” (or the unique name yo used when defining the trustpoint.

In the Importing the CUCM and CAPF Key section don’t forget to repeat the process twice, once for the CallManager.pem certificate, and once for the CAPF.pem certificate.  Call the CAPF trustpoint “capf-trustpoint.”

In the Creating a CTL File section Step 2 – the name of the trustpoint is “self-trustpoint” (ignore the 6s), or the unique name you assigned above.

In Step 3 the capf-trustpoint name is “capf-trustpoint” (ignore the 6s)

 

Quit following the configuration guide at this point.

Now bail on the configuration guide and add this to your configuation.  Please note, if you are alreadying doing CUBE or SIP turnks to you gateway YOU MAY NOT WANT TO PASTE THIS IN TO A PRODUCTION VOICE GATEWAY!!

Enable CUBE (recall this is a licensed feature from Cisco)

voice service voip
no ip address trusted authenticate  !- DANGER DANGER DANGER — This is disabled by default and enabling this could open your gateway to TOLL FRAUD.  My system is isolated, and I used this command to allow CUBE to pass RTP from the outside to the inside in my lab environment.  Consult Cisco documentation before enabling this on a CUBE that is exposed to the internet!
allow-connections sip to sip
sip
header-passing
registrar server
nat auto
pass-thru headers unsupp
pass-thru subscribe-notify-events all
pass-thru content unsupp
registration passthrough
extension cucm
!
!

Define your URIs that will be modified

This is the outside interface of CUBE
voice class uri 1 sip
host ipv4:10.21.1.1

This is the inside interface of CUBE

!
voice class uri 2 sip
host ipv4:10.25.1.20

This is the CUCM Publisher

!
voice class uri 3 sip
host ipv4:10.25.1.60

Build the requisite SIP profiles – These can be cut and pasted EXCEPT for the part in Bold that needs to be changed to your CUCM PUB IP address before pasting

voice class sip-profiles 10
request INVITE peer-header sip contact copy “>(;.*)” u01
request REGISTER peer-header sip contact copy “>(;.*)” u02
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request REGISTER sip-header Contact modify “(.*)” “\1\u02”
!
voice class sip-profiles 11
request INVITE peer-header sip contact copy “>(;.*)” u01
request INVITE peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u02
response 200 peer-header sip contact copy “>(;.*)” u03
request CANCEL peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u04
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request INVITE sip-header SIP-Req-URI modify “.*” “INVITE sip:\u0210.25.1.60 SIP/2.0″
response 200 sip-header Contact modify “(.*)” “\1\u03”
request CANCEL sip-header SIP-Req-URI modify “.*” “CANCEL sip:\u0410.25.1.60 SIP/2.0″
!
voice class sip-hdr-passthrulist 10
passthru-hdr Remote-Pary-ID
passthru-hdr Call-Info
passthru-hdr Content-ID
passthru-hdr supported
passthru-hdr require
passthru-hdr Referred-By
!
voice class sip-copylist 10
sip-header SIP-Req-URI
sip-header contact
!
voice class sip-copylist 11
sip-header contact

 

Build the Phone Proxy – Modify anything below in Bold to your IP addresses

voice-phone-proxy cubepp
tftp-server address ipv4 10.25.1.60 local-addr ipv4 10.25.1.20 acc-addr ipv4 10.21.1.1
ctl-file ct1
access-secure
service-map server-addr ipv4 10.25.1.60 port 8443 acc-addr ipv4 10.21.1.1 port 8443
service-map server-addr ipv4 10.25.1.60 port 8080 acc-addr ipv4 10.21.1.1 port 8080
service-map server-addr ipv4 10.25.1.60 port 3804 acc-addr ipv4 10.21.1.1 port 3804
complete

 

voice-phone-proxy tftp-address ipv4 10.21.1.1
port-range 40000 50000
voice-phone-proxy tftp-address ipv4 10.25.1.20
port-range 40000 50000
voice-phone-proxy file-buffer size 30

Build your Dial Peers to proxy registrations

dial-peer voice 2 voip
description DP_facing_CCM
session protocol sipv2
session target ipv4:10.25.1.60
session transport tcp
destination uri 1
incoming uri via 3
voice-class sip extension cucm
voice-class sip call-route url
voice-class sip profiles 11
voice-class sip pass-thru headers 10
voice-class sip copy-list 11
dtmf-relay rtp-nte
codec transparent
!
dial-peer voice 1 voip
phone-proxy cubepp signal-addr ipv4 10.21.1.1 cucm ipv4 10.25.1.60
description DP_Access_Side
session protocol sipv2
session target registrar
session transport tcp tls
destination uri 2
incoming uri request 1
voice-class sip call-route url
voice-class sip profiles 10
voice-class sip registration passthrough registrar-index 1
voice-class sip pass-thru headers 10
voice-class sip copy-list 10
dtmf-relay rtp-nte
codec transparent

Enable the SIP User Agent

sip-ua
timers connection aging 60
registrar 1 ipv4:10.25.1.60 expires 3600 refresh-ratio 100 tcp

 

Test it out

Connect a phone to the inside of the network and register it successfully to your CUCM.  Perform a test call to make sure audio is working.

Move it to the outside (in my case I created VLAN21 and only had it routed on the outside interface of the CUBE router) and delete the CTL/ITL.  Change the TFTP to the outside IP address of CUBE (in my case 10.21.1.1).

If phone proxy is working it will register.  It can take a couple minutes.

 

Some debugging commands

  • show sip registration passthrough status
  • Debug voice dial-peer inout
  • Debug voice phone-proxy all

 

The Relevant Bits of my Lab Router Config

IP Address Scheme:

CUCM – 10.25.1.60

CUBE Inside – 10.25.1.20 (ip routable inside to CUCM)

CUBE Outside – 10.21.1.1 (typically this would be a public IP or natted to the outside)

 

Cisco 2951 Config

version 15.3

!
hostname C2951-LAB
!
crypto pki trustpoint cucm_trustpoint
enrollment terminal
revocation-check none
!
crypto pki trustpoint cucm_capf
enrollment terminal
revocation-check none
!
crypto pki trustpoint self-trustpoint
enrollment selfsigned
serial-number
subject-name CN=C2951-LAB
subject-alt-name 8945_SEC.lab.domain.com
revocation-check crl
rsakeypair pp_uno
!
!
crypto pki certificate chain cucm_trustpoint
certificate ca 6749FF335ACDECF99948DB3A35527681
308202A4 3082020D A0030201 02021067 49FF335A CDECF999 48DB3A35 52768130
0D06092A 864886F7 0D010105 05003064 310B3009 06035504 06130255 53311630
14060355 040A130D 43697363 6F6F6F6F 6F6F6F6F 6F310C30 0A060355 040B1303
534C4331 14301206 03550403 130B534C 434C4142 32352D36 30310B30 09060355
04081302 5554310C 300A0603 55040713 0353434C 301E170D 31333130 32353035
33343236 5A170D31 38313032 34303533 3432355A 3064310B 30090603 55040613
02555331 16301406 0355040A 130D4369 73636F6F 6F6F6F6F 6F6F6F31 0C300A06
0355040B 1303534C 43311430 12060355 0403130B 534C434C 41423235 2D363031
0B300906 03550408 13025554 310C300A 06035504 07130353 434C3081 9F300D06
092A8648 86F70D01 01010500 03818D00 30818902 818100A3 54BD2EFD D87226F1
CDAAC4BA 8567040A 9814A2A3 8057E803 57AD56E4 6933D2E0 05B392F4 0091ECA6
B9609FE8 DC386317 75844DCD 5F78E8BB 055E77D4 AC03B99A EBE4184C A432D784
AB2CAEEB 539DEC55 409D1CC6 EE1E45C4 A8E1F89B 128ABAD9 C80D8DF0 5DD761FB
16B27305 49545567 F53B65E1 4461CF25 1CF5BE53 B8059F02 03010001 A3573055
300B0603 551D0F04 04030202 BC302706 03551D25 0420301E 06082B06 01050507
03010608 2B060105 05070302 06082B06 01050507 0305301D 0603551D 0E041604
14F5EC15 F22A21B2 02EB351E 2F7E9DB7 21226E3D 8F300D06 092A8648 86F70D01
01050500 03818100 321D20AB C0980512 2A9843BC 33D78624 A62E82AC C0CE9387
23EA2E5D 9BE12EFE 1A63114E 316A42B5 F36D73E5 68C93053 902D1FCB 86F0FA59
A14E7845 610F8590 4132D0A9 1A10D393 61D7A14C 6E8DAEEB BF33950F 676F7EE2
A0699D96 7E7121DE 820FE5BB F0332E61 1BDE9F43 D2FEB42C 2623A1B5 E768501D
B624BEBC 49C9500B
quit
crypto pki certificate chain cucm_capf
certificate ca 6109543C30968DE66EB25CE2C58CD0A7
3082029E 30820207 A0030201 02021061 09543C30 968DE66E B25CE2C5 8CD0A730
0D06092A 864886F7 0D010105 05003066 310B3009 06035504 06130255 53311630
14060355 040A130D 43697363 6F6F6F6F 6F6F6F6F 6F310C30 0A060355 040B1303
534C4331 16301406 03550403 130D4341 50462D30 61666333 39323031 0B300906
03550408 13025554 310C300A 06035504 07130353 434C301E 170D3133 31303235
30353334 32395A17 0D313831 30323430 35333432 385A3066 310B3009 06035504
06130255 53311630 14060355 040A130D 43697363 6F6F6F6F 6F6F6F6F 6F310C30
0A060355 040B1303 534C4331 16301406 03550403 130D4341 50462D30 61666333
39323031 0B300906 03550408 13025554 310C300A 06035504 07130353 434C3081
9F300D06 092A8648 86F70D01 01010500 03818D00 30818902 818100A9 F234D83D
13CA75FE 2F9C6041 921DB77A 869CA6E3 29AC94E3 8EBB099F 2C33AE51 A5EFEC3D
B151D31A C2A1A02D 79727287 6F2910E3 DC308D1D E4841409 F6B7131C 5D0A40CA
DA4DDF8A 49682465 2BCA05F5 D3B8CF86 DC2D5136 2CB0F6F6 35747B7D 696AEE6C
F0947654 8A49D275 1D8501CA 1808F948 BAB32B37 8B5AD708 E122E902 03010001
A34D304B 300B0603 551D0F04 04030202 A4301D06 03551D25 04163014 06082B06
01050507 03010608 2B060105 05070305 301D0603 551D0E04 160414DF D666E78A
FCE19727 F039EF69 B44BA2DF B59D3730 0D06092A 864886F7 0D010105 05000381
81003667 BD568296 1280E5EF 26F22309 0901B655 1A694158 4731AAE7 E6EFD071
0FF1D024 F180A918 BC98DAF8 61DBB2BE FFD1A75B 56D49325 F49F75EB E22CB3C0
94447F2D 5E89B4D7 E511E554 374F4E52 7983A054 4F9B9EA3 4305042B EDB15EBD
3B5EDB8D FF4C8C83 5B0FF139 D5D7DD0D 001445F2 93E3DE30 5612DFF0 112B4214 783C
quit
crypto pki certificate chain self-trustpoint
certificate self-signed 01
308202A1 3082020A A0030201 02020101 300D0609 2A864886 F70D0101 05050030
59311530 13060355 0403130C 43323935 312D534C 434C4142 31403012 06035504
05130B46 54583137 3431414B 534B302A 06092A86 4886F70D 01090216 1D433239
35312D53 4C434C41 422E736C 636C6162 2E636973 636F2E63 6F6D301E 170D3134
30343038 31383032 31395A17 0D323030 31303130 30303030 305A3059 31153013
06035504 03130C43 32393531 2D534C43 4C414231 40301206 03550405 130B4654
58313734 31414B53 4B302A06 092A8648 86F70D01 0902161D 43323935 312D534C
434C4142 2E736C63 6C61622E 63697363 6F2E636F 6D30819F 300D0609 2A864886
F70D0101 01050003 818D0030 81890281 8100A67C DB60E221 6621A5B2 2F691BFC
5956086E 6B9AE741 885CAB9D B6898DFC C328A19C E4A4A981 DF0A76EB 1CA33CDA
016E1DE5 FD68FF6F 85F1CEBE 1F5A7D2B CD00F5BB DE3080D7 035A69DD 0C260447
0957E19D 2F27A9ED 0B1F6DE4 45AAACCB 16EE480C 1B7D1F51 7E652D36 DB208A00
F05956C4 07A7483D 1EC310AC F1D05346 CEB90203 010001A3 79307730 0F060355
1D130101 FF040530 030101FF 30240603 551D1104 1D301B82 19383934 355F5345
432E736C 636C6162 2E636973 636F2E63 6F6D301F 0603551D 23041830 16801464
E3A180EB 3CA73479 7E3AF3B7 E1181782 CB0B9630 1D060355 1D0E0416 041464E3
A180EB3C A734797E 3AF3B7E1 181782CB 0B96300D 06092A86 4886F70D 01010505
00038181 00A11F68 786EA2B2 EA741486 EF863E81 BF646077 DBE5CBDC 41159E24
15535334 9CF2427C A8A5271B 4D0D406B 4AB8E2D0 07F0ABCC E369616F 859CC789
EC25802C A34F89DC 2233A7D9 DD7EAE9D 0E2D831D 781D0B0B 54F43C8F 7F8FF899
6184A6D2 E882EF4B 3D2D5EC3 6475ACD5 72E4428D 71A9F0AF 43CB5F74 0CDD97D3
3CD36B8A 6B
quit
!
!
!
!
!
ip dhcp excluded-address 10.21.1.1 10.21.1.99
!
ip dhcp pool VLAN21
network 10.21.1.0 255.255.255.0
option 150 ip 10.21.1.1
default-router 10.21.1.1
!
!
!
ip domain name lab.domain.com
!
!
voice service voip
no ip address trusted authenticate
allow-connections sip to sip
sip
header-passing
registrar server
nat auto
pass-thru headers unsupp
pass-thru subscribe-notify-events all
pass-thru content unsupp
registration passthrough
extension cucm
!
!
voice class uri 1 sip
host ipv4:10.21.1.1
!
voice class uri 2 sip
host ipv4:10.25.1.20
!
voice class uri 3 sip
host ipv4:10.25.1.60
voice class sip-profiles 10
request INVITE peer-header sip contact copy “>(;.*)” u01
request REGISTER peer-header sip contact copy “>(;.*)” u02
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request REGISTER sip-header Contact modify “(.*)” “\1\u02”
!
voice class sip-profiles 11
request INVITE peer-header sip contact copy “>(;.*)” u01
request INVITE peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u02
response 200 peer-header sip contact copy “>(;.*)” u03
request CANCEL peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u04
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request INVITE sip-header SIP-Req-URI modify “.*” “INVITE sip:\u0210.25.1.60 SIP/2.0”
response 200 sip-header Contact modify “(.*)” “\1\u03”
request CANCEL sip-header SIP-Req-URI modify “.*” “CANCEL sip:\u0410.25.1.60 SIP/2.0”
!
voice class sip-hdr-passthrulist 10
passthru-hdr Remote-Pary-ID
passthru-hdr Call-Info
passthru-hdr Content-ID
passthru-hdr supported
passthru-hdr require
passthru-hdr Referred-By
!
voice class sip-copylist 10
sip-header SIP-Req-URI
sip-header contact
!
voice class sip-copylist 11
sip-header contact
!
interface GigabitEthernet0/1
ip address 10.25.1.20 255.255.255.0
duplex auto
speed auto
!
interface GigabitEthernet0/2
ip address 10.21.1.1 255.255.255.0
duplex auto
speed auto
!
voice-ctl-file ct1
record-entry selfsigned trustpoint self-trustpoint
record-entry capf trustpoint cucm_capf
record-entry cucm-tftp trustpoint cucm_trustpoint
complete
voice-phone-proxy cubepp
tftp-server address ipv4 10.25.1.60 local-addr ipv4 10.25.1.20 acc-addr ipv4 10.21.1.1
ctl-file ct1
access-secure
service-map server-addr ipv4 10.25.1.60 port 8443 acc-addr ipv4 10.21.1.1 port 8443
service-map server-addr ipv4 10.25.1.60 port 8080 acc-addr ipv4 10.21.1.1 port 8080
service-map server-addr ipv4 10.25.1.60 port 3804 acc-addr ipv4 10.21.1.1 port 3804
complete
voice-phone-proxy tftp-address ipv4 10.21.1.1
port-range 40000 50000
voice-phone-proxy tftp-address ipv4 10.25.1.20
port-range 40000 50000
voice-phone-proxy file-buffer size 30
!
dial-peer voice 2 voip
description DP_facing_CCM
session protocol sipv2
session target ipv4:10.25.1.60
session transport tcp
destination uri 1
incoming uri via 3
voice-class sip extension cucm
voice-class sip call-route url
voice-class sip profiles 11
voice-class sip pass-thru headers 10
voice-class sip copy-list 11
dtmf-relay rtp-nte
codec transparent
!
dial-peer voice 1 voip
phone-proxy cubepp signal-addr ipv4 10.21.1.1 cucm ipv4 10.25.1.60
description DP_Access_Side
session protocol sipv2
session target registrar
session transport tcp
destination uri 2
incoming uri request 1
voice-class sip call-route url
voice-class sip profiles 10
voice-class sip registration passthrough registrar-index 1
voice-class sip pass-thru headers 10
voice-class sip copy-list 10
dtmf-relay rtp-nte
codec transparent
!
!
sip-ua
timers connection aging 60
registrar 1 ipv4:10.25.1.60 expires 3600 refresh-ratio 100 tcp
!