Configuring Cisco Jabber Problem Reporting

Cisco Jabber has an administrative feature allowing users to submit problem reports directly from the user interface. When troubleshooting issues with Jabber this is usually one of the first steps. I consider this a better method instead of having the user save the PRT zip file, subsequently lose it on their computer, and then clogging your inbox.

The nuts and bolts of how this works is briefly described in the Cisco Jabber installation and configuration guide. You need a method to submit the problem report and a method to retrieve the problem report. This post is purely focusing on how to submit the problem report to a server and it’s up to you on how to retrieve it. If you’re anticipating using this frequently or in an enterprise you’re going to need to do some light file handling on the server side. The Cisco problem reporting upload mechanism doesn’t randomize file names during the upload.

I’m working with my FreeBSD server specialized for Jabber functions so underneath I have Apache and PHP. The disclaimer I’m going to insert is that is up to YOU to secure your installation. Creating a free-for-all upload location on your network poses a big security risk. My goal here is to give you the basics with Jabber and what it is doing.

Cisco Jabber does an HTTP POST directly to the URL you specified in your jabber-config.xml. This HTTP POST contains the following information so this is merely informational if you would like use a different upload method. The “ciscoID” portion of the POST is generated by the Cisco JID.

POST /uploadprt.php HTTP/1.1
Request Method: POST
Full request URI:
Type: multipart/form-data
Content-Disposition: form-data; name="zipFileName"; filename=""

Now that you know how Cisco Jabber uploads to your server you need a corresponding catch-all script to accept the upload. Cisco gives you an example HTML form that you can put on your server. This form is optional and not necessary to have Cisco Jabber automatically upload PRTs. The goal was to provide you an example of how you need to accept the ‘zipFileName’ form data.


<form name="uploadPrt" action="" method="post" enctype="multipart/form-data">
<input type="file" name="zipFileName" id="zipFileName" />

<input type="submit" name="submitBtn" id="submitBtn" value="Upload File" />

The next piece of the puzzle is the uploadprt.php file and how it interacts with the incoming HTTP POST from Jabber. Jabber uploads a file name that is exactly “” and if you do nothing else to the file name the user will continually overwrite the same file. So I decided to go ahead and add a time-stamp which you can see below in the $uploadfile variable.

I do not recommend you use this code without adding in proper file handling controls. I’m working in a sealed environment so this is the bare essential method to accept the upload. Obviously the $uploaddir needs to be set to your server location you want to store the files.


$uploaddir = '/usr/local/www/apache22/data/uploads/';
$uploadfile = $uploaddir . date('Y_m_d_H_i_s') . basename($_FILES['zipFileName']['name']);
move_uploaded_file($_FILES['zipFileName']['tmp_name'], $uploadfile);

So you’ve put all this together and as always I’m ready to tell Jabber via the jabber-config.xml file where to upload problem reports. It’s important to note that the PrtLogServerUrl parameter points to your upload PHP script and not the HTML form provided in the documentation.


<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">

The end result is I have a directory on the server that houses the Jabber problem reports as “”. From here you can work this into any further automation methods such as e-mailing or FTP. The first goal has been met to get the file from the client to the server and from there further automate.

If everything is working you’ll end up with a little window that looks like this. Happy Jabber-ing!


Configuring Cisco Jabber Automatic Updates

With Jabber releases coming from Cisco on a near monthly basis there is a way to keep everyone updated. You can find a section in the installation guide about automatic updates, but it isn’t super clear. I’ll show you from a live installation how it is put together. You’ll want to only do this starting with version 10.5.

First of all you’re going to need a place to host an XML file and the installation files that will be downloaded by the clients. Some may choose Windows/IIS because of familiarity, but I’m a #FreeBSD fan. It’s also something to notice that some of the other application servers from Cisco like Jabber Guest are built on CentOS Linux so you may want to go that route.

Once you’ve found a suitable location you need to create the update.xml file which Jabber checks for changes. If you have thousands of clients in your environment be prepared for that.

<?xml version="1.0" encoding="utf-8"?>
<App name="JabberMac">
<App name="JabberWin">

Now that you’ve prepared your server and update.xml just upload those files to your server. The Jabber for Mac version requires the DSA signature in the file name and you can find that in the release notes from the download. I haven’t tried this on IIS but I do hear it requires a few modifications to host this file on IIS considering the name.

root@yuengling:/usr/local/www/apache22/data/jabber # ll
total 56100
-rw-r--r-- 1 upload www 56574006 Sep 22 10:50 Cisco-Jabber-Mac-!!.zip
-rw-r--r-- 1 upload www 786432 Nov 1 17:47 CiscoJabberSetup.msi
-rw-r--r-- 1 upload www 557 Sep 25 19:33 update.xml

From here you need to test downloading each of these files and once that works you can proceed updating your jabber-config.xml. Recall that your jabber-config.xml file is hosted on CUCM so be prepared to update that file, upload to CUCM, and restart TFTP services. Please remember to upload to all your TFTP nodes in the cluster.

<config version="1.0">

You can add a piece of code into your jabber-config.xml that will give users a display of information. I haven’t found that really useful at this stage, but I may do it for the Jabber 10.6 update that is coming ‘soon’.

If it displays properly your next task is to load up Jabber, click Help and “Check for Updates”. If everything pieced together properly you should get the following.


Skype’s first day on the job?

Is this really the message the Microsoft Skype team is trying to send?  We’re getting marketing showing that Skype is having it’s first run as a business communications platform. Great for the new guy getting a new job, but are you ready to align your business with Skype? I disagree with this approach from Microsoft and say that this may not be the best marketing approach for the future of Skype for Business.

I now have to reach out to some Lync fan-boys and get their reaction.


Is Skype for Business WebRTC?

It has been an exciting few days in the WebRTC world. We’re seeing movement from Microsoft, Cisco, WebRTC, and the IETF. If you haven’t heard the IETF released that the “mandatory to implement” codecs include VP8 and H264. While this seemingly kicks the can down the road at least we have a direction. The enterprises I talk to are 99% on the H264 bandwagon. It’s very difficult to displace a codec once it is in the market and we have H264 devices that will be around for at least 6 additional years. So anything we pick moving forward needs the backwards compatibility.

Is Skype for Business WebRTC?

This question is starting to come up because we’ve seen Microsoft announce additional ORTC support and Skype for Business within two weeks of each other. ORTC is seemingly positioning itself as WebRTC 1.1 which may sounds like a fork but I’ve been told it is not. I took a brief look look at the “shim” that the community is pitching showing how ORTC will have WebRTC 1.0 compatibility. I’m not convinced we will see much support for this “shim”.

Yes, Skype for Business is WebRTC albeit the ORTC side of the specification. I will speculate that we’re simply seeing Microsoft flex their muscle. They have Skype in the consumer market and Lync in the enterprise market to push forward ORTC and H264. This feels similar to how Microsoft has handled codec implementation in the Lync product. While everyone was on the H264 AVC bandwagon we saw Lync 2013 show up with H264 SVC.

While Skype has been traditionally a consumer market product we have to acknowledge what enterprises are evaulating. We saw Microsoft announce that Lync as a product name is on the way out so we needed to quickly understand how WebRTC fits into the picture. Let’s not forget that many enterprises use Lync and they all need to know the direction we’re going. Very soon we’ll most likely see a Skype for Business built around Office Web Apps server and the back end will be Lync Server 2015.

Microsoft gives you a new glass of water to drink every 3 years. You’ll get thirsty near the end of that 3 years wondering what is next. Before you know it you have another full glass and Microsoft expecting you to gulp it down as quickly as possible. Personally I’m getting a bit tired of this approach. Come back around every quarter and top off what we have in front of us.

Moving to FQDN for CUCM

The latest hurdle I’ve seen involves moving existing clusters to FQDN instead of IP. This usually involves making sure all endpoints registering to CUCM have DNS servers and a search suffix provided by DHCP.

Every installation I’ve done has been based on server name and DNS. One client had to change an installation back to IP in the server field because of their DNS domain hierarchy. Heading into DNS usually involves triple checking the DNS/DHCP side of the world before changing a cluster. For a long time Cisco TAC even advocated that cluster server names are set to the IP address. I’ve always had interesting conversations when I would open a TAC case on of my installations.

With the introduction of Jabber, certificates (and multi-SAN in 10.5), and IPv6 we finally have come full circle to needing the server set to FQDN. Since you cannot apply an invalid TLD or IP address into the subject or SAN field names you’ll need to get certificates based on an actual public FQDN. If you want full BYOD interoperability the certificates you get should come from a 3rd party valid certificate authority. (I like Digicert)

Long story short – your “CUCM > System > Server” should be set to

Cisco CUBE line-side SIP Proxy – Transcoding

To properly handle SRTP to RTP internetworking on your CUBE SIP proxy you will need PVDM modules. To maximize your usage you should have G711 configured as a region and “codec transparent” on your dial peers. You can do G729 however that is higher complexity and you’ll get less sessions out of your PVDM modules.

Using DSP calculator I came up with this assuming G711 between IP Phone and everything else:

0-16 Sessions = PVDM3-16; 17-24 sessions = PVDM3-32; 25-48 sessions = PVDM3-64; 49-96 sessions = PVDM3-128; 97-144 sessions = PVDM3-192; 145-192 sessions = PVDM3-256. Some model routers obviously support more than one PVDM3. Use the Cisco DSP calculator for the best answer.

If you assume high complexity G729 a PVDM3-256 can only support 60 sessions!

Configuration in the previous post mentions using SCCP and to do so requires the telephony-service along with relevant SCCP configuration. Since our transcoding will happen local to the router we can use LTI API instead of the SCCP API. If both SCCP and LTI are configured the LTI takes precedence.

IOS 15.4(2)T

Enable CUBE:

voice service voip

allow-connections sip to sip

DSP farm profile:

dspfarm profile 1 transcode universal security

trustpoint SELFSIGN (this is your selfsigned trustpoint on the CUBE, use whatever name you’ve used)

no codec g729ar8

no codec g729abr8

maximum sessions ? = this will return the maximum value allowed for the configured codecs in this profile

no tls (turn off SIPS interworking since we are transcoding local to the router for performance)

associate application CUBE (this is where we define the CUBE LTI API vs the SCCP API.

no shutdown


CUBE1# Show dspfarm profile 1

Dspfarm Profile Configuration

Profile ID = 1, Service =Universal TRANSCODING, Resource ID = 1

Profile Description :

Profile Service Mode : secure

Trustpoint : SELFSIGN

Profile Admin State : UP

Profile Operation State : ACTIVE

Application : CUBE Status : ASSOCIATED

Resource Provider : FLEX_DSPRM Status : UP

Number of Resource Configured : 96

Number of Resources Out of Service : 0

Number of Resources Active : 0

Codec Configuration: num_of_codecs:2

Codec : g711ulaw, Maximum Packetization Period : 30

Codec : g711alaw, Maximum Packetization Period : 30



Cisco CUBE line-side SIP proxy – Security


Two basic concepts need to be considered with the CUBE line-side feature. Access side and core side. We will continue those two concepts when we move to the follow-up posts on dial peers and SIP/RTP modifications.

Access side (aka line-side) is your connection between CUBE and the IP Phone. If your phones are already secured by another method then you could support the access side via SIP and RTP. If you’re bringing phones in from the Internet obviously you’ll want SIPS and SRTP. If you’ve ever used Wireshark to capture an RTP session it is extremely easy to listen to that voice call if the media is sent in the clear. In short – you want secure access side.

The core side is your connection between CUBE and Communications Manager. If based on your network architecture you have CUBE behind an external Internet facing firewall you may want to have a non-secure core side. Meaning SIP/RTP is sent in the clear back to CUCM and other devices internal to the network. If you have a mixed-mode cluster obviously you already have secure core and will require the “access-secure” within the phone proxy configuration.

Do you have a mixed mode cluster or a non-secure cluster? You need all of the certificates on CUBE regardless and I’ll go ahead to give some more information for LSC certificates and non-secure clusters. If you have a mixed mode cluster you’ll need to import the MIC Cisco_Manufacturing_CA, CAP-RTP-001 and CAP-RTP-002. The reason is you want valid trust points across the CUBE. If you have used USB keys or a signed CA you’ll obviously need to add those certificates to CUBE. The MIC certificates do not need to be in the CTL file. I may point this out several times but if you are doing secure core side back to CUCM you need to import the CUBE selfsigned certificate into CUCM nodes to support the SIPS/SRTP negotiation!

Similar to the ASA phone proxy in order for Cisco IP phones to download the LSC certificates, the Cisco CUBE permits the CAPF TLS connection. It does not proxy the CAPF connection. The Cisco CUBE requires the CAPF CA certificate, contained in the CTL file, for the Cisco IP phone to establish a TLS connection with the CAPF process running on the CUCM node. Once completed, Cisco IP phones can download the LSC over the CAPF TLS connection. To clarify, the USB tokens or CA certs in the CTL are not necessary because the Cisco CUBE is serving the CTL file and inserts the CAPF CA certificate, which the Cisco IP phone trusts, to establish the CAPF TLS connection. This is part of the phone proxy configuration when you do a service map for port 3804 the CAPF service on CUCM.


The phone can then dynamically update the LSC certificate from CUCM CAPF service and CUBE access line-side feature must import the CUCM CAPF certificate into the CTL to support this function.

So there are 2 purposes here to import the CAPF certificate from CUCM

#1 The phone must have this certificate in the CTL file to pass the authenticate during an LSC update

#2 CUBE would use this certificate to authenticate phone during the TLS connection.


To state the obvious for clarity – Regardless if you have a mixed-mode or non-secure cluster you obviously need to import the CAPF.pem to CUBE line-side from every CUCM node! IF you have a mixed-mode (secure) cluster you also need to import the CUBE self-signed certificate into CUCM to support the core side SIPS/SRTP negotiation. The CUBE self-signed must be imported to CUCM first. Multiple SAN certificate for the phone must be configured based on the phones security profile in CUCM. You have probably already dealt with this if you are running a mixed-mode cluster and performing SRTP with another CUBE possibly for PSTN access.

((I really want to call this out – More and more you’re going to be working with certificates across all of the Cisco Collaboration products. Do yourself a favor and have your Microsoft team spin up a Windows Server 2012 running SCEP/NDES. This way you can automatically enroll devices with a trusted CA and stop having to import/export trusted CA certificates everywhere. I’ve covered this in some older posts but it’s time to have a trusted CA across your internal corporate network.))

There is another interesting detail for CUBE on your ISR 29xx or 39xx series router. To do RTP to SRTP interworking you need DSP resources. Shocked? Don’t be. I’m getting to that configuration right now because this is super important when you pick a router for CUBE line-side. The most basic way to check if you’re already configured is via “show call active voice brief” and look for “SRTP: on” or “SRTP: off”. If you can make calls and you have NOT set up a SCCP based DSP transcoder your calls are in the clear! SRTP is controlled by your dial-peer and the “srtp” command. Setting “srtp fallback” will allow RTP media if the TLS/SRTP connection cannot be established.

Using DSP calculator I came up with this assuming G711 between IP Phone and everything else:

0-16 Sessions = PVDM3-16; 17-24 sessions = PVDM3-32; 25-48 sessions = PVDM3-64; 49-96 sessions = PVDM3-128; 97-144 sessions = PVDM3-192; 145-192 sessions = PVDM3-256. Some model routers obviously support more than one PVDM3. Use the Cisco DSP calculator for the best answer.

If you assume high complexity G729 a PVDM3-256 can only support 60 sessions!

SRTP-RTP internetworking is available with normal and universal transcoders. The transcoder on the CUBE is invoked using SCCP messaging between the SCCP server and the SCCP client. The SCCP messages carry the SRTP keys to the digital signal processor (DSP) farm at the SCCP client. The transcoder can be within the same router or can be located in a separate router. TLS should be disabled only when the transcoder is located in the same router. To disable TLS, configure the no form of the tls command in dsp farm profile configuration mode. Disabling TLS improves CPU performance since you are not needing to exchange keys within the same router. If bouncing the call off an external DSP farm you’ll need to keep TLS in the mix to ensure end-to-end secure connections.

REALLY IMPORTANT – Most companies have multiple CUCM servers for redundancy. If you want CUBE to have a redundant core side configuration you must also import the Callmanager.pem and CAPF.pem certificates from all nodes the CUBE will connect to. This is really where CUCM 10.5 can help out with multi-node multi-SAN certificates but you DON’T WANT TO USE 10.5 MULTI-SAN certificates for Callmanager.pem. I believe I was the first to find and create the SEV2 bug CSCup28852 and your phones will continually reboot due to CUCM sending group restarts to ALL phones. First fixed in 10.5(1.98000.77) but that release isn’t available yet for download.


Cisco Communications Manager 10.5 Certificates BUG

Finally we get cluster-wide certificate management via multi-SAN certificate support. EDIT 6/10/2014 – and I immediately find a SEV2 bug working with TAC Bug ID:CSCup28852. Callmanager hates this certificate and sends group resets every ITL refresh meaning your phones reboot every 10 minutes or so. Fixed in a later CUCM version but not available for download at this time.

You need to properly set up your Microsoft CA to provide the proper certificate template.

  1. New Certificate template “Web Server X509v3”
    1. Certificate purposes – Server authentication, client authentication, IP security end system
    2. Key usage – Digital signature, Non repudiation (I add this so this can also be used for the VMware hosts, Key encipherment, data encryption. When you are in “Key Usage” you cannot assign Key Agreement and Key Encryption. You want to select “key encipherment”
    3. Key length: 2048
    4. Hash: SHA256
  2. Generate Multi-SAN certificate request from your CUCM publisher
    1. Certificate purpose: tomcat
    2. Distribution: Multi-server (SAN)
    3. Common name: Can be left as-is of put in a vanity name
      1. Auto-populated Domains
      2. This should list all of your CUCM and IM&P nodes in the cluster.
    4. Parent domain!
      1. Be sure this is the parent DNS domain your SERVERS are residing in. There are some caveats here if you have servers in different domains
      2. Example:
    5. Other domains!
      1. ADD your directory URI domains (AKA e-mail domain).
      2. Example:
    6. Key Length: 2048
    7. Hash: SHA265
  3. Submit the CSR to the Microsoft CA via http://ca-server/certsrv
  4. Upload the CA root and any intermediates
  5. Upload the new certificate to CUCM publisher

Enjoy that you didn’t have to do that on every cluster node!

Reminder: If Jabber is connecting to Voicemail you need to go to Unity Connection and create CSR and assign a certificate for each Unity Connection node. Jabber will still prompt for a certificate error if Unity Connection is un-signed.

Cisco Conductor 2.3 – BE6000 and BE7000

Just bringing you a few highlights about Conductor 2.3 which should align with Telepresence Server 4.0.

Conductor XC2.3 has a new API that will allow Cisco TMS to obtain conference information, capacity information, and provision conferences. The client can create a new ConfBundle with auto-dialed participants and conference aliases. It is important to note that these API provisioned conference details will only be available through the API and not the Conductor web interface. In short – you still need TMS for scheduling which isn’t a big deal.

Putting the pieces together the scheduling of TP conferences connecting TMS to Conductor is a welcome addition. I’m making an assumption that vTS 4.0 and TMS 14.4 will be available very soon. This should speed the adoption of the vTS and Conductor within the Be6000 and Be7000 platforms. I’m still not 100% positive how TMS and TMSPE with Exchange will play into this but I’m assuming those pieces will be available soon.

Most likely this will all align with announcements we’re going to hear from Cisco Live.

More Telepresence!

VCS and Expressway 8.1 to 8.1.1 Patch

If you patch 8.1 to 8.1.1 and your Mobile and Remote Access stops working you need to regenerate your certificates.

During the patch from 8.1 to 8.1.1 the XCP/XMPP router service is being introduced. When modifying anything related to XCP/XMPP on VCS or Expressway you need to regenerate the certificates. The same applies when you modify or add XMPP chat node alias.

The certificates need to be regenerated on Core and Edge. Once applied a restart will have it take effect.

The documentation does not currently reflect that this is a required step and should be updated soon.