Cisco Meraki Managed Communciations MC74 IP Phone Released

Cisco Meraki have released a new cloud-managed phone.


Gotta say I love the look of the elegant slim-line design.

The key to this deployment model’s appeal can be seen in the finer details of the datasheet.  Just a few highlights that piqued my interest below.


Hardware Specs:

  • High definition color 7” IPS backlit touchscreen display (1280×800)
  • Integrated GbE switch with passthrough port
  • Rear and side USB headset ports
  • Ambient light sensor


Phone Features:

  • Hold Transfer
  • Ad hoc conferencing
  • Mute
  • Visual voicemail
  • Directory
  • Interactive Voice Response
  • History
  • Extension to extension calling

Pretty standard stuff.


Zero Touch:

  • Meraki Communications phones benefit from zero-touch deployment. With only a serial number the network admin can remotely configure the phone for a user or meeting room. Once online it will connect to the cloud, pull down its configuration and within seconds be ready to make calls.

Very interesting!


Codec Support:

  • Wideband audio G.722 internal calling (G.711 for PSTN calling)

Was surprised that the datasheet appears quite limited in codec support.  Honestly, was hoping to see Opus on that list…



  • VoIP Fully encrypted voice and SIP signaling (TLS/SRTP)


Looking forward to following its mainstream adoption…  Interesting times ahead!





Tagged , , , , ,

CUBE URI-based Routing and Multiple Via Headers

Cisco introduced some pretty cool URI enhancements for CUBE from 15.4(1)T that have added some great extensions to the CUBE feature set, and specifically include some fine-grained SIP routing control.  These have been long overdue as IOS-based VoIP routing has been heavily dependent on numerical pattern matching due to Cisco’s ongoing support for H.323-style legacy configuration.

These enhancements are covered in a lovely Cisco doc here.  I’ve also blogged previously on a similar topic on how to utilize these and other new CUBE SIP features to provide Loop Prevention on CUBE.


To start, the basic configuration for URI dial-peer matching is somewhat trivial:

voice class uri voice-class-uri-tag sip|tel
    host hostname-pattern
    host ipv4:ipv4-address
    host ipv6:ipv6-address
    host dns:dns-address
    pattern uri-pattern
    user-id username-pattern
dial-peer voice tag voip
 session protocol sipv2
 incoming uri { from | request | to | via } voice-class-uri-tag

Here we see that incoming called-number is dropped and is instead routing using incoming uri.  Typically, we’d match the URI on a via header, with our voice class uri container applying a match on our preferred IP Address / DNS address.

I am referring to RFC compliant behaviour for the Via header from RFC 3261: Via

   The Via header field indicates the transport used for the transaction
   and identifies the location where the response is to be sent.  A Via
   header field value is added only after the transport that will be
   used to reach the next hop has been selected (which may involve the
   usage of the procedures in [4]).

   When the UAC creates a request, it MUST insert a Via into that
   request.  The protocol name and protocol version in the header field
   MUST be SIP and 2.0, respectively.  The Via header field value MUST
   contain a branch parameter.  This parameter is used to identify the
   transaction created by that request.  This parameter is used by both
   the client and the server.

Here we note that a SIP Request can contain multiple Via headers.  This is used as a loop prevention mechanism for SIP Routing.  This becomes incredibly import when multiple SIP Proxies forward requests.  This is well described here for the SIP initiate.


With this in mind, I came across an interesting scenario recently where a call route through an ITSP’s SIP Proxy network changed without my knowledge, meaning that the Via header ordered list in the inbound INVITE changed.  This resulted in not matching my voice class uri configuration.  This stymied me at first until I noted the following for this feature:

In a scenario where multiple SIP hops are involved in a call, there would 
be multiple via headers involved, and the topmost via header of an 
incoming SIP invite represents the last hop that forwarded the SIP 
request, and the bottom-most via header would represent the originator 
of the SIP request. This feature supports matching by the last hop that 
forwarded the request (neighboringSIPentity), which is the topmost via 


From the PDF link’s worked examples, we can see the matching will use the following behaviour:

INVITE sip:123@ SIP/2.0

Via: SIP/2.0/TCP;branch=z9hG4bK-17716-1-0

Via: SIP/2.0/TCP;branch=z9hG4bK-28280-1-0


In my situation, I’d been using a voice class uri that looked something like this:

voice class uri ITSP sip
    host ipv4:
dial-peer voice tag voip
 session protocol sipv2
 incoming uri via ITSP
I would have expected the feature to consider the ordered list in decreasing priority, but the dial-peer never matched…  As per the feature description, only the “neighboringSIPentity” is considered.
Just something to note when deploying this feature in future.
Tagged , , , , , ,

CUCM Video Codec Preferences Support – CSCuw53802

Colleague called me for assistance with a video call that wouldn’t set up when dialling in to a VC bridge.

The call flow was from a Polycom endpoint to the new Conductor-managed vTS bridge that I’d installed a week before.  The endpoint could dial into the Rendezvous VC bridge, but calls only had audio.  Some additional testing showed that this wasn’t working for point-to-point calls to Jabber as well, which helped us rule out the bridge completely.

My colleague pulled a Wireshark from Jabber, and the signalling confirmed a codec support issue on the Polycom:

Jabber INVITE with H.264:


However, the response clearly showed that our Polycom unit didn’t like this, and marked the video streams as inactive:


My colleague did some reading up on our somewhat outdated Polycom unit, and we ultimately found that some release keys and a firmware upgrade would be needed.  Customer not too happy, but nothing to do here other than upgrade…

However, my colleague did post a question to me:

Can we not just set some video codec preferences for this call, or at least for the call into the VC bridge?

Well, the answer is… no!


As of 11.0 this is not supported.  However, thankfully this does appear to have been considered in the roadmap for CUCM 11.5:



This is good news, as the CUCM-based video architecture is now quite mature, having gone through several iterations since it’s inception from CUCM 9.x.

As the market for Skype for Business grows, H.265 begins to create more and more headaches due to patent licensing problems, and Cisco subsequently begins to punt Thor as a potential future video standard, this new feature should hopefully solve some problems down the line.



Tagged , , , , , , , , , , , , , , ,

Accessing the jabber-config.xml Jabber Configuration File

Often when working on Cisco Jabber installations, you will be required to edit an existing jabber-config.xml file to change client parameters or support new functionality, or simply as part of an audit or system assessment want to have a look at what customization is being used for Jabber already.

There are several ways to access the jabber-config.xml file from your CUCM/TFTP server or Jabber client PC.

When troubleshooting, it is often helpful to know the methods to view from both the TFTP server and the Jabber client PC.  Discrepancies can be a good starting point for troubleshooting.

Method 1 – CUOS

From CUOS, run the following command:

admin:file view tftp jabber-config.xml


Method 2 – Browser

From your browser, enter the following:


where X.X.X.X is the CUCM (i.e. TFTP Server) IP Address


Method 3 – TFTP Client

Use a TFTP Client such as Windows TFTP client or TFTPD32 and GET the jabber-config.xml file.


Method 4 – Windows Client PC

Fetch this from the following path:

%USERPROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config

You may need to enable showing of hidden files on the Windows desktop to reach this.


If you know of more, please let me know!


Tagged , , , , , ,

VoIP Bandwidth Calculations

If you’re preparing for a your CCIE Written or Lab exams, or (far more importantly) if you need to perform bandwidth sizing for a VoIP design or implementation, it’s critical to be able to accurately calculate the amount of bandwidth that your precious voice streams are going to need as they traverses your network.

Vik Mahli makes an excellent overview of what this means in terms of a QoS configuration here, but skips the calculation part altogether in order to focus on the LAN QoS config that he wished to cover in his post.  Naturally, this created some confusion which was carried over into the comments section!

I encourage you to read the comments, specifically Mark Holloway’s length post on this topic.  Mark makes an excellent reference here to the QoS SRND, and is well worth a read!  Please see this link and refer to where Mark and Vik use a 93bkps base for G.711 calls from.

Building on some of the discussions there, I’d like to provide some additional detail on how these calculations can be performed in this post.

Finally, please take note that this does not account for signalling bandwidth requirements.  This is a different discussion – ping me and I’ll blog about this too! 🙂


Performing VoIP Bandwidth Calculations


Calculation Assumptions

Firstly, we will have to make some protocol-related assumptions for sizing purposes:

  • IP – 20 bytes
  • User Datagram Protocol (UDP) – 8 bytes
  • Real-Time Transport Protocol (RTP) – 12 bytes
  • Compressed Real-Time Protocol (cRTP) reduces the IP/UDP/RTP headers to 2 or 4 bytes
  • Multilink Point-to-Point Protocol (MP) – 6 bytes
  • Frame Relay Forum (FRF).12 Layer 2 (L2)– 6 bytes
  • End-of-frame flag on MP and Frame Relay frames – 1 byte
  • Ethernet L2 headers– 18 bytes


Codec-Specific Information

Secondly, we need to know some values that are codec-specific:

  • Voice Payload Size
  • Codec Bitrate

Some values worth keeping in mind here are:

  • G711
    • Bit Rate – 64 kbps
    • Default Payload size – 160 bytes
  • G729
    • Bit Rate – 8 kbps
    • Default Payload size – 20 bytes
  • iLBC 20ms
    • Bit Rate – 15.2 kbps
    • Default Payload size – 38 bytes
  • iLBC 30ms
    • Bit Rate – 13.33 kbps
    • Default Payload size – 50 bytes


There is a detailed discussion of these values and their explanations here.  I won’t go into more detail in this post.  Please refer to the above document for clarity.


For differing Millesecond Packet Sizes (e.g. G.729 20ms/30ms), the codec bitrate is always constant.  Therefore the payload size can always be scaled as a ratio using the formula of:

codec bit rate = codec sample size / codec sample interval

More on this later in a worked example…


Bandwidth Calculation Formulas

From the TAC Online Help, we’re presented with a fairly simple calculation:

Total Packet Size = (Media Access Header - Layer 2) + (IP/UDP/RTP Header) + (voice payload)
Voice Packets Per Second (PPS) = codec bit rate / voice payload size
Bandwidth = [ (voice packet size) + 1 byte (frame flag) ] * PPS

Finally, it is best practice to allow for a 5.0% overhead in all calculations.


Some Worked Examples

This seems simple enough, so let’s put it into practice in some worked examples!


Example 1 : 3 Concurrent G.711 Calls over Ethernet

Total Packet Size = [ (18) + (40) + (160) ] = 218 bytes 

Packets per Second = [ 64 kbps * 1000 bits per kilobit ] / [ 160 bytes (default voice payload) * 8 bits per byte ]  = 50 pps

Bandwidth = [ ( 218 bytes ) + (0 bytes ) ] * 50 pps * 8 bites/byte = 87200 bits/sec = 87.2 kbps

5.0% Overhead87.2 kbps * 1.05 = 91.560 kbps

Concurrent Calls = 3 * 91.560 kbps = 274.68 kbps


Example 2 : 5 Concurrent G.729 Calls over PPP with Compressed RTP

Total Packet Size = [ (6) + (2) + (20) ] = 28 bytes 

Packets per Second = [ 8 kbps * 1000 bits per kilobit ] / [ 20 bytes (default voice payload) * 8 bits per byte ]  = 50 pps

Bandwidth = [ ( 28 bytes ) + (1 byte) ] * 50 pps * 8 bites/byte = 87200 bits/sec = 11.6 kbps

5.0% Overhead = 11.6 kbps * 1.05 = 12.18 kbps

Concurrent Calls = 5 * 12.18 kbps = 60.9 kbps


Example 3 : 10 Concurrent iLBC Calls over Ethernet using a 20ms bitrate

Total Packet Size = [ (18) + (40) + (38) ] = 96 bytes

Packets per Second =[ 15.2 kbps * 1000 bits per kilobit ]  / [ 38 bytes (default voice payload) * 8 bits per byte ]  = 50 pps

Bandwidth = [ ( 96 bytes ) + (0 bytes ) ] * 50 pps * 8 bites/byte = 38400 bits/sec = 38.4 kbps

5.0% Overhead = 38.4 kbps * 1.05 = 40.32 kbps

Concurrent Calls = 10 * 40.32 kbps = 403.20 kbps

The TAC Tool does not cover iLBC calculations, but we can see that there’s nothing special going on here.  We just needed to know the bitrate values for the codec and the calculations are effectively the same.


Example 4 : 5 Concurrent iLBC Calls over Ethernet using a 30ms bitrate

Total Packet Size = [ (18) + (40) + (50) ] = 108 bytes

Packets per Second =[ 13.3 kbps * 1000 bits per kilobit ]  / [ 50 bytes (default voice payload) * 8 bits per byte ]  = 33.3 pps

Bandwidth = [ ( 108 bytes ) + (0 bytes ) ] * 33.3 pps * 8 bites/byte = 28800 bits/sec = 28.8 kbps

5.0% Overhead = 28.8 kbps * 1.05 = 30.24 kbps

Concurrent Calls = 5 * 30.24 kbps = 151.20 kbps


Example 5 : 2 Concurrent G.729 Calls over Ethernet using a 40ms bitrate

OK, let’s end it off with a challenge 🙂

As I said above, the bitrate is always a constant for any codec:

codec bit rate = codec sample size / codec sample interval

Therefore, we will need to calculate our new Payload Sample Size for 40ms instead of 20ms:

Codec Sample Size = 8 kbps * 40ms  / (8bits/byte) = 40 bytes

See?  Not so hard!  If you’re following, you can actually see that you could have just used a ratio of:

New Payload Size = Old Payload Size * (New Sampling Interval / Old Sampling Interval)


OK, I digress.  Now, carrying on as before:

Total Packet Size = [ (18) + (40) + (40) ] = 98 bytes

Packets per Second =[ 8 kbps * 1000 bits per kilobit ]  / [ 40 bytes (default voice payload) * 8 bits per byte ]  = 25 pps

Bandwidth = [ ( 98 bytes ) + (0 bytes ) ] * 25 pps * 8 bites/byte = 19600 bits/sec = 19.60 kbps

5.0% Overhead =19.60 kbps * 1.05 = 20.58 kbps

Concurrent Calls = 2 * 40.32 kbps = 41.16 kbps

As you can see, the payload size may have doubled, but the packet throughput has halved!


Example 6 : 8 Concurrent G.722 Calls over Ethernet using a 10ms bitrate

Building on the ideas presented in the previous example:

New Payload Size = 160 kbps * (10/20) = 80 kbps

Total Packet Size = [ (18) + (40) + (80) ] = 138 bytes

Packets per Second =[ 64 kbps * 1000 bits per kilobit ]  / [ 80 bytes (default voice payload) * 8 bits per byte ]  = 100 pps

Bandwidth = [ ( 138 bytes ) + (0 bytes ) ] * 100 pps * 8 bites/byte = 110400 bits/sec = 110,4 kbps

5.0% Overhead =110.40 kbp * 1.05 = 115.92  kbps

Concurrent Calls = 8 *115.92 kbps = 927,36 kbps

OK, at this point not much more to cover! 🙂


A Final Note on Sampling Rates…

I highlighted the PPS value in Example 5 in red to make a final point on this topic.

As you can see, the payload size may have doubled, but the packet throughput has halved.


Where does all of this come  into play?  Well, there are two competing considerations here:

  1. Longer Durations (i.e. a lower PPS value) reduces Network Overheads
  2. Increased Packet Sizes decreases the resiliency to Network Errors (such as packet loss)


Considerations such as physical hardware capabilities, link stability, available bandwidth, PBX feature sets (and don’t forget that of your Peering Partners!)  etc. can all be considered when deciding on a preferred sampling rate for your VoIP network – a lot for the VoIP designer to think about when making decisions on what codecs (and respective capabilities) to support!


Online References

I have managed to find a number of excellent documents to help you.


For a detailed breakdown of how to perform these calculations:


A TAC tool, and simply the best out there with a nice GUI:


Configuring Bandwidth-based CAC for CUBE:


For quick and dirty calculations that don’t take into account network overheads:


Additional links to various sites that offer similar tools:


Hope this helps all you CCIE aspirants and VoIP network designers!



Tagged , , , , ,

RFC 5411 – And Other Guides to the SIP Galaxy

Given half a chance, I am always open to punt The SIP School as probably the best starting point for learning SIP out there.  I took this course some years ago, and was recently able to convince our management to get our whole voice team to complete the training.  It has really skilled up our team and made us a force to be reckoned within our local market.  If you want to learn SIP, look no further.  I’ve said it loads of times, this was without a doubt the key to my CCIE Collaboration success.  Before you ask, I have no affiliation to the SIP School whatsoever – am just a very, very satisfied customer!

That being said, my main motivation for suggesting this training material is that the course, although covering Core SIP and other topics incredibly well, is, by design, heavily influenced by the IETF standards documentation.  At the time of studying for the SSCA exam, I took the opportunity to do a detailed study of the RFCs that each section referenced.  To me, it is very important as a VoIP Engineer to have a strong understanding of RFC Compliance – particularly for SIP!


That being said, I only recently came across RFC 5411.  I can’t believe that in the last 5 years I’ve missed this!  This is absolutely the coolest IETF RFC for VoIP ever.  Unsurprisingly, this was written by Jonathan Rosenburg.

This is really a great starting point for working through the long list of RFCs that cover standard-based SIP (a term that can only ever be used loosely, haha).  Although there have been several key RFCs post-2009, this is an excellent starting point for even a seasoned SIP professional.  I particularly like how Jonathan has broken down this list functionally.  If you’re anything like me, you’ll soon find yourself deep down the rabbit hole!  And it definitely goes deep 🙂


I am particularly fond of these as well:

For something more Cisco-centric, this is a great read on how Cisco has recently endeavoured to remain RFC-compliant:


Happy reading.  Please ping me to add to this list!

Tagged , , ,

Cisco Support Community Collaboration Videos

Thanks to Java for sharing this – can’t believe I’ve never come across this!

A really, really awesome resource for a number of Collab-related support topics.  Some excellent videos on topics such as:

  • CUOS certificates
  • Self-Provisioning
  • Conference Now
  • PCD
  • TelePresence
  • VCS
  • Service Discovry and UDS
  • Various phone model factory reset procedures



Enjoy! 🙂

Tagged , , , , , , , , , ,

CUOS Certificate Expiration Issues and Regeneration

I arrived on site at a remote client picking up a deployment that was done some 18 months ago for additional scope of work.  However, when I arrived to begin, I encountered some strange behaviour that I struggled to attribute to anything obvious.

What I saw was:


  • High number of AXL connections on CUCM:

admin:utils diagnose test

Log file: platform/log/diag3.log

Starting diagnostic test(s)
test – disk_space : Passed (available: 1796 MB, used: 12360 MB)
skip – disk_files : This module must be run directly and off hours
test – service_manager : Passed
test – tomcat : Passed
test – tomcat_deadlocks : Passed
test – tomcat_keystore : Passed
test – tomcat_connectors : Passed
test – tomcat_threads : Passed
test – tomcat_memory : Passed
test – tomcat_sessions : FailedThe following web applications have an unusually large number of active sessions: axl. Please collect all of the Tomcat logs for root cause analysis: file get activelog tomcat/logs/*
skip – tomcat_heapdump : This module must be run directly and off hours
test – validate_network : Passed
test – raid : Passed
test – system_info : Passed (Collected system information in diagnostic log)
test – ntp_reachability : Passed
test – ntp_clock_drift : Passed
test – ntp_stratum : Passed
skip – sdl_fragmentation : This module must be run directly and off hours
skip – sdi_fragmentation : This module must be run directly and off hours


  • Backups Failing


  • Jabber services listed as” UNKNOWN” from the GUI, even though listed as “STARTED” from Serviceability and from CLI:




  • Immediate Switch-Version failed after an upgrade due to SELinux failing to upgrade correctly, causing differing behaviour on different servers:
    – Java errors on login to server and CLI scripts unable to run due to permissions issues
    – A Cisco DB service refusing to start!
    – Kicked out of ssh session directly after authentication – SELinux issue



The SELinux issue actually prevented a switch-back as this could not be initiated from CLI.  To resolve this I had to complete a manual partition switch using the CUCM/CUC Recovery CD as well as a File System Check and Repair!


This was all very, very strange!


Once back to a “stable” platform after the partition swap and file-system check, I again attempted an upgrade, which this time failed:

04/20/2016 19:46:49|Started auditd…|<LVL::Info>
04/20/2016 19:46:49|Started setroubleshoot…|<LVL::Info>
04/20/2016 19:46:49|Changed selinux mode to enforcing|<LVL::Info>
04/20/2016 19:46:49|Cleaning up rpm_archive…|<LVL::Info>
04/20/2016 19:46:49|Removing /common/rpm-archive/|<LVL::Info>
04/20/2016 19:46:50|File:/usr/local/bin/base_scripts/, Function: main(), Upgrade Failed — (1)|<LVL::Error>
04/20/2016 19:46:50|Parse argument status=upgrade.stage.error|<LVL::Debug>
04/20/2016 19:46:50|_set_upgrade_status_attribute: status set to upgrade.stage.error|<LVL::Debug>
04/20/2016 19:46:50|is_upgrade_lock_available: Upgrade lock is not available.|<LVL::Debug>
04/20/2016 19:46:50|is_upgrade_in_progress: Already locked by this process (pid: 32606).|<LVL::Debug>
04/20/2016 19:46:50|release_upgrade_lock: Releasing lock (pid: 32606)|<LVL::Debug>


This time, I had selected an immediate switch-version instead of using a 2-stage process after a successful upgrade.  Again, I could confirm a successful upgrade:


04/20/2016 19:39:01 post_upgrade|Post Upgrade RTMTFinish|<LVL::Notice>
04/20/2016 19:39:01 post_upgrade|========================= Upgrade complete. Awaiting switch to version. =========================|<LVL::Info>
04/20/2016 19:39:01|Post-upgrade processing complete|<LVL::Info>
04/20/2016 19:39:01|Application install on inactive partition complete|<LVL::Info>
04/20/2016 19:39:01|L2 upgrade… Run selinux_on_inactive_partition|<LVL::Info>


So now, I concentrated on the post-upgrade switch-version logging, and picked up on this:


04/20/2016 19:46:38|(CAPTURE) /sbin/restorecon.orig set context /etc/opt/cisco/elm/client/.security/trust_certs/Cisco_Root_CA_M1.pem->system_u:object_r:cisco_etc_t:s0 failed:’Operation not permitted’|<LVL::Debug>
04/20/2016 19:46:38|(CAPTURE) /sbin/restorecon.orig set context /etc/opt/cisco/elm/client/.security/trust_certs/Cisco_Root_CA_M1.der->system_u:object_r:cisco_etc_t:s0 failed:’Operation not permitted’|<LVL::Debug>
04/20/2016 19:46:38|(CAPTURE) /sbin/restorecon.orig set context /home/sftpuser/>specialuser_u:object_r:user_home_t:s0 failed:’Operation not permitted’|<LVL::Debug>


It was then that I became very confused.  These strange issues together all pointed to **certificate expiration**.  However, the system had been installed less than 18 months ago, so this didn’t make sense!  I checked the certificates and confirmed – all expired.  Then it dawned on me.  When we had installed the system, we had staged the network and voice at the same time.  We’d pointed NTP to the firewall – which must have, prior to go-live, been set as a master by our firewall team … with the wrong date-time! 😦

So, root cause found, but now to resolve?!


Certificates are a tricky business in CUCM since the implementation of Security by Default.  I don’t intend to cover this topic here (it’s absolutely huge), but I will say this – changing certificates on CUCM can run the risk of getting you fired.

If you don’t know 100% what you are doing, you could cause an outage that will require serious skill to repair, an emergency TAC engagement,  manual phone intervention or a combination of the 3.


So, I now needed to complete Certificate Regeneration on CUCM, CUC and IM&P.

Some notes here:

  • My cluster was not in Mixed Mode – my life just got a whole lot easier!
  • The client didn’t have a Private CA, so we were forced to use Self-Signed.  A major consideration if you have signed certs.
  • I was working on a BE6K – with no redundancy – so for me…  ITL files are going to be an issue.  I must to do a “Pre- 8.0 Rollback” and blank all the ITL files before I start.
  • Multi-App integrations are probably going to require manual certificate download/import between clusters for IM&P


Following the above process, I carefully:

  1. Blanked all ITL files, with necessary TVS and TFTP service restarts as required
  2. Stopped TFTP Services
  3. Regenerated all applicable certificates as per the above guide
  4. Manually deleted “-trust” certificates as per the guide – I preferred the GUI to the CLI for this – watch out for related bugs in the above guide.
  5. Restarted all applicable services
  6. Removed Pre-8.0 Rollback Enterprise Parameter ITL blanking
  7. Again, restarted TVS and TFTP services
  8. Imported regenerated certs for intra- and inter-cluster communications


An Important Note:

When restart TFTP, always wait 5-10mins for the TFTP files to rebuild on the server.  More haste, Less-Job-Come-Monday.


Rebooted IM&P, and immediately saw that all the affected IM&P services were listed correctly:



Helpful links on SBD (Security by Default) and CUOS Certificates in General:



Check out the ITLRecovery enhancements in 10.x and above!



Tagged , , , , , ,

Gathering CUOS Installation Information Prior to Upgrade

It may sound obvious, but prior to any upgrade – prepare for the eventuality of a system rebuild.  I hit an upgrade today that required both a Recovery CD partition swap and file system check on the original Active Partition to recover the system, after SELinux failures occurred after a switch-version.

For a rebuild, collect the following from CLI prior to upgrade:

  1. show network eth0 

  2. show status

  3. show version active

  4. utils ntp config

  5. show web-security


This will collect IP/Hostname, DNS, NTP/Timezone, firmware and certificate details(last one is critical!).

This is all negated if you have Answer Files set up to begin with and/or are using PCD.



Tagged , , ,

Active Unassigned DN’s – Updating with SQL

Update to a previous post

Disclaimer :

Provided as is – you break your box all on your own buddy!  Lab this first.

 The offending DNs can be queried using:

select n.dnorpattern from numplan n
left outer join devicenumplanmap m on m.fkdevice = n.pkid
where m.fkdevice is null
and n.tkpatternusage = ‘2’
and n.iscallable = ‘t’

  • m.fkdevice is null assures the Route Plan element is unassigned
  • tkpatternusage = ‘2’ matches DNs only
  • iscallable=’t’ defines the “Active” checkbox on the DN page – and our offending behaviour.

Some help came from here.

Construct your own UPDATE SQL statement to fix it!  As assistance – start here, it’s not too difficult.


Tagged , , , , , ,
Collaboration Engineer

All things Technology - Posts to save for when you need them

Gerry Keleghan's Blog

A Blog about Cisco Unified Communications


my personal journey to ccie collaboration

Striving for greatness

Thoughts on DevOps, emerging tech, and open source

Network Experts Blog

“Knowledge comes by eyes always open and working hands.”

SIP Adventures

A unified communications blog by Andrew Prokop

The Cloverhound Blog

Cloverhound Employees Talk Unified Communications and Contact Center


Fog navigator. Get out of the clouds. Down to earth solutions. @Warcop

Cisco Collab Engineering Tips

Michael White - CCIE #26626


Photography by Manos,


Thoughts and experiences of a Cisco Collaboration engineer after clearing the CCIE lab...

The Daily Post

The Art and Craft of Blogging

The Blog

The latest news on and the WordPress community.

%d bloggers like this: