Jabber bot for Cisco IM&Presence

Creating a bot for Cisco Jabber isn’t very difficult: you’d need a python3 interpreter (ships with all latests Ubuntu installations) and a slixmpp library. I’m using pip to install slixmpp like that:

apt-get install python-pip3
pip3 install slixmpp

The example from slixmpp github repo (under “The Slixmpp Boilerplate” subtitle) is working right from the box: just specify bot’s username and password and IM&P server name or IP. If you need your bot to read or calculate some data and send it to you on a regular basis here is a modified example:

import logging
import asyncio
import datetime
import time
from slixmpp import ClientXMPP
from slixmpp.exceptions import IqError, IqTimeout

@asyncio.coroutine
def asleep(t):
    yield from asyncio.sleep(t)

def calc_smth():
    return time.mktime(datetime.datetime.now().timetuple())

class EchoBot(ClientXMPP):

    def __init__(self, jid, password):
        ClientXMPP.__init__(self, jid, password)
        self.add_event_handler("session_start", self.session_start)
        self.register_plugin('xep_0199')
    def session_start(self, event):
        try:
            self.send_presence()
        except IqError as err:
            self.disconnect()
        except IqTimeout:
            self.disconnect()


    def disconnected(self, event):
        print("%s disconnect" % self.jid)

if __name__ == '__main__':
    logging.basicConfig(level=logging.ERROR,format='%(levelname)-8s %(message)s')
    try:
        xmpp =  EchoBot('bot@example.com', 'password')
        xmpp.connect(address=("IM&P IP", 5222))
        xmpp.process(timeout=0.1)
        while True:
            asyncio.get_event_loop().run_until_complete(asleep(5))
            xmpp.send_message(mto='johndoe@example.com', mbody="Timestamp={}".format(calc_smth()), mtype='chat')
    except (KeyboardInterrupt, SystemExit):
        xmpp.disconnect()
        print("Done")

Just change bot’s JID  and password (bot@example.com and ‘password’ in this example), destination JID (johndoe@example.com), modify calc_smth function for it to do something usefull instead of calculation current timestamp and launch it with

python3 bot.py

Cisco Jabber update 11.5

There is a known vulnerability in Cisco Jabber versions lower than 11.5 http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20151224-jab. So I decided to perform a cetralized update on my user’s PCs and MACs.
First thing to to is to implement automatic upgrades
1) Go to Cisco Unified Operating System Administration -> Software upgrades -> TFTP File Management and look for jabber-config.xml. It can be also accessed from http://<cucm IP>:6970/jabber-config.xml.
2) Download it to your PC and edit it to add Client section like this

<config version="1.0">
<Client>
<UpdateURL>http://<your 3rd party web server>/jabber-update.xml</UpdateURL>
</Client>

3) Upload it to CUCM TFTP: Cisco Unified Operating System Administration -> Software upgrades -> TFTP File Management -> Upload file to / directory. Then restart TFTP service on every CUCM node (I’m not completely sure if it’s needed at all as updated file appears even without restart)

4) Now host a file named jabber-update.xml  on a 3rd party web server. It should look like that:

<JabberUpdate>
  <App name="JabberMac">
     <LatestBuildNum>226858</LatestBuildNum>
     <LatestVersion>11.5.0</LatestVersion>
     <Message>This new version of Cisco Jabber</Message>
     <DownloadURL>http://<your 3rd party web server>/Cisco-Jabber-Mac-11.5.0.226858-<long string with random characters - see below for info>.zip</DownloadURL>
  </App>
  <App name="JabberWin">
     <LatestBuildNum>26858</LatestBuildNum>
     <LatestVersion>11.5.0</LatestVersion>
     <Message>This new version of Cisco Jabber</Message>
     <DownloadURL>http://<your 3rd party web server>/CiscoJabberSetup-11.5.0.26858.msi</DownloadURL>
  </App>
</JabberUpdate>

This long string with random characters in the file for update of MAC version can be found in release notes. But I consulted Cisco TAC because there were no release notes in download portal at Cisco.com when I was there that moment. And of course these zip and msi install files should be also accessible and biuld and version number should be consistent.

5) Now every user who will restart Cisco Jabber would get a message which encourages them to upgrade. But they can skip it unless you specify <Mandatory>true</Mandatory> in jabber-update.xml.
6) In order to check upgrade status I use RTMT. Go to Voice/Video -> Device -> Device Search -> Phone. Choose Any status, Any protocol, Any model, and Device name like CSF* and it will show a table with all CSF devices and their active load
7) If you want to export it you should use CLI:
– login to CLI with platform admin
– issue show risdb query phones file alldevices to create file alldevices.txt inside  platform/cli/ folder which lists all devices and their active loads.
– issue file get activelog platform/cli/alldevices.txt to upload it to SFTP server. CLI would ask a couple of questions about IP of SFTP, username/password, direcotry and correctness of server fingerprint. I’m using freeFTPd (http://www.freesshd.com/?ctt=download) as SFTP which very easy to install.
– repeat it for every CUCM node (every one with CallManager service running) as show risdb query phones will list devices registered only for the node it’s run on.

Now you have a file with list of every device in CUCM. I use Excel to sort it and extract only CFS devices. In most cases you can find user login right after CFS in device name so it should be easy to spot lazy users.
This approach has some restrictions as it will list only Cisco Jabber users that are using phone services and leave those who use only IM. Moreover RTMT and show risdb will list devices with statuses of Registered/Unregistered and not the ones with None status which
indocates that these users launched their Cisco Jabber quite some time ago.

Cisco Jabber (CAXL) powered web chat

Cisco IM&Presence server provides the ability to connect to it via BOSH interface. In order to turn this feature on navigate to Cisco Unified IM and Presence Serviceability -> Tools -> Control Center – Feature Services -> choose a node -> Cisco XCP Web Connection Manager and check if it’s started and activated.

Next, check what security setting are applied to it: Cisco Unified CM IM and Presence Administration -> System -> Security -> Settings. If Enable Web Client to IM/P Service Secure Mode is checked you’ll use https to reach BOSH interface, http otherwise.

Now let’s check if BOSH interface is up: navigate to https://cup_server_name:7335/httpbinding (use http if you are not using secure connection). You browser should show something like this:

123123

This URL can be overriden by modifying Cisco Unified CM IM and Presence Administration -> System -> Service Parameters -> choose a node -> Cisco XCP Web Connection Manager -> HTTP Binding Paths Handled – Path field.

I know only 2 clients that support BOSH connections: Pidgin and CAXL, which is a Cisco javascript library. The description of the latter can be found here and library docs here.

I decided to implement web chat, based on this library. The source can be found here. You’ll need Python2 with Flask and  requests modules for it to work.

After launching the app you’ll se a login screen:

login123123123

  • username: full username with domain part, e.g. user@example.com
  • password: end user password
  • IM&P node: FQDN or IP address or IM&P Node with Cisco XCP Web Connection Manager running
  • chat alias: full group chat name in a form like chat_name@chat_alias. Navigate to Cisco Unified CM IM and Presence Administration -> Messagin -> Group Chat Server Aliases  Mapping to check what chat_aliases are available

Once logged in the main window should look like that:

main123123123

The styling is pretty simple and can be modified.

 

 

Problems with user login into Cisco IM&Presence

Cisco IM&Presence supports both native Cisco Jabber clients and 3rd party XMPP clients like PSI.

Cisco jabber clients use special type of DNS SRV records (_cisco-uds._tcp.example.com) which stores an address of CUCM server. When they get it they make a request to a special service called Cisco UDS for a user login and his respective parameters – Service Profile to be exact. Cisco UDS can be found in UC Serviceability in Control Center -> Network Services -> CM Services, so if you experience problems with Cisco Jabber authorization and RTMT sends you AuthenticationFailed with Interface : cucm-uds  string you can restart it.

Service Profile (CM Administration -> User Management -> User settings -> Service profile) – defines which UC services are available to a user. Navigate to End User configuration to check which service profile is tied to a certain user. Service profile have links to IM and Presence Profile, which are defined by CM Administration -> User Management -> User settings -> UC services.

It is UC services which stores addresses of IM&P nodes. That’s how Cisco Jabber clients reach IM&P and get IM capabilities. Also without _cisco-uds SRV a client queries for _cuplogin._tcp SRV which points to IM&P nodes and uses the same process as 3rd party XMPP client described below.

3rd party XMPP clients don’t use _cisco-uds SRV. They use _xmpp-client._tcp SRV which points to IM&P node. Inside IM&P there is a service of Cisco XCP Connection Manager which listens on 5222 port and provides logins. So when there is a problem with login of 3rd party XMPP client it is likely that Cisco XCP Connection Manager is faulty and should be restarted.

Cisco UDS is pretty new service and a lot of stuff relies on it now in UC infrastructure (like MRA for example – I should definetely write a post on how CIisco Jabber clients login with MRA – it’s a peice of art) and it deals with a huge load ok. But Cisco XCP Connection Manager in certain situations becomes unavailable under heavy load. From the perspective of the client it looks like it’s responding and even provides a list of possible auth mechanisms of PLAIN and CISCO_VTG_TOKEN, but returns nothing when a client send it’s encoded password with XMPP (you can observe this with PSI XML console for example).

URI dialling in UC infrastructure. Part 1.

URI dialling in UC infrastructure is a good thing to have for a number of reasons. For example, if your dial plan is not flexible enough and the number of digits used for DNs is insufficient to cover all endpoints. In that case moving toward URI will give you more flexibility (in case you don’t want to enable access codes).
Another reason that sounds tempting is the expansion of Cisco Jabber usage: some of my users don’t want a hardware phone any more and ask to give them the opportunity to make and receive call with Jabber only. In that case I can leave them with Directory URI only which is equal to their email, which is nice.
Moreover, URI dialling is essential when making B2B calls.
So here I’m going to cover some potential cases of URI dialling with CUCM and VCS/Expressway

1) Cisco video codecs

SX10 and SX20 codecs are very powerful devices. If they are not provisioned by CUCM or VCS they can dial via URI out-of-the-box provided SIP and H.323 protocols are on and there is no SIP proxy of H.323 gatekeeper configured.

For example, if you dial reception@example.com from a SX20 it will do the necessary DNS lookups for example.com domain and send SIP INVITE to the corresponding IP.

But in most cases codecs are managed by CUCM and all SIP INVITES are send to it. In that case you need to set up intracluster/intercluster URI dialling on CUCM and B2B dialling through collaboration edge VCS/Expressway.
I still keep H.323 protocol enabled (Configuration->System configuration->Networkservices->H323 ON) for SX20 to be capable of calling H323 destinations on its own.

2) Cisco Jabber

Jabber calling capabilities are managed and provisioned by CUCM by using special type of devices (i.e, CSF for Cisco Jabber for windows).  If you want to make calls to URI from Jabber you should enable this function in jabber-config.xml

  • download jabber-config.xml from CUCM TFTP by navigating to http://%5BIP address of CUCM node with TFTP running]:6970/jabber-config.xml
  • in the policies section change EnableSIPURIDialling parameter to true
  • upload updated jabber-config.xml to TFTP via Cisco Unified Operating System Administration -> Software updates -> TFTP File Management  -> Upload file (use / directory)
  • restart TFTP service

After restarting Cisco Jabber your devices will be able to use URIs.

3) Intracluster URI dialling
There is a document on cisco.com describing the process of enabling intracluster URIs. I want to expand it a little bit.
If you have you user account synchronized with LDAP, their URI could be imported to CUCM as a part of this synchronization. Navigate to Cisco Unified CM Administration ->End User -> select a user.
In End User Configuration window there should be a populated Directory URI filed. Then scroll down and find Directory Number Associations.

1
The drop-down Primary Extension will be populated if an end user has a control of a device with DN configured (see Device Information -> Controlled Devices in this window). So when you choose a DN user’s Direcotry URI get’s assosiated with this DN and is automatically assigned to a partition defined by  System -> Enterprise Parameters -> End User Parameters -> Directory URI Alias Partition. Be sure to add this partition to a correspondent CSS.

Another option is to define custom (up to 5 different) URIs under DN configuration.  Navigate to a device -> Association (DN association section on the left), scroll down to Directory URIs section and add one (and choose a partition). If you have already completed first option via  End User Configuration window, in that case Directory URI will show up here with a green OK sign.

2
And don’t forget to check Use Fully Qualified Domain Name in SIP Requests checkbox in all SIP profiles used by Cisco Jabber devices and codecs.

Now you can use URI for calling between Jabber and video codecs inside you CUCM cluster

4) Intercluster URI dialling
This task is accomplished with ILS,which I think deserves a separate post.

In part 2 I’m going to cover B2B URI dialling both inbound and outbound.

Cisco Jabber “Share presentation” button is greyed out.

With the newest versions on CUCM and IM&Presence (10.5 and higher) greyed out “Share presentation” button in Cisco Jabber can be caused by a couple of things:
a) “Allow BFCP” checkbox isn’t checked in SIP profile of the CFS (TAB,BOT,TCT) device in CUCM
b) firewall is blocking a connection.
When investigating the latter I decided to discover what is this BFCP and how the presentation is shared.

1) When I make a call from Cisco Jabber to another video-capable endpoint (i.e SX20), a SIP invite is sent with following SDP attributes

Media Description, name and address (m): video 25990 RTP/AVP 126 97
Media Attribute (a): content:main

Media Description, name and address (m): video 26744 RTP/AVP 126 97
Media Attribute (a): content:slides

Media Description, name and address (m): application 5316 UDP/BFCP *
Media Attribute (a): floorctrl:c-s

Attribute with content:main describes our main video stream. The RTP stream will start right after called endpoint answers.
Attribute with content:slides is a presentation stream. This stream will be a usual RTP carrying payload with type of 126 (H264 coded video). It won’t start until we hit “Share presentation” button.
Attribute with application 5316 UDP/BFCP is a description of BFCP protocol. According to https://tools.ietf.org/html/rfc4582 it controls who is holding a shared resource (presentation in our case) and who’s transmitting (to avoid bidirectional presentation sharing).
Import thing here is who is going to be the server in this connection. In my case floorctrl:c-s shows that Jabber is willing to be a server as well as a client.

2) Let’s look at the SIP 200OK with SDP

Media Description, name and address (m): video 16880 RTP/AVP 126
Media Attribute (a): content:main

Media Description, name and address (m): video 16882 RTP/AVP 126
Media Attribute (a): content:slides

Media Description, name and address (m): application 28339 UDP/BFCP *
Media Attribute (a): floorctrl:c-only

First 2 media descriptions are obvious: they are usual answers to offers of the calling party. But in application 28339 UDP/BFCP there is an attribute of floorctrl:c-only.
This shows that called party is going to be a client in BFCP terms. Moreover it will initiate a BFCP connection. If there is a firewall which block UDP port 5316 in direction from endpoint to Jabber, BFCP server in Jabber won’t see an incoming connection and would grey-out the button. This BFCP connection will occur right after SIP 200 Ok and long before you can hit a “Share presentation” button in Cisco Jabber.

3) This only describes a case when you share the presentation during a call.
In addition you can share presentation without making a call from a chat window in Jabber. This is done without BFCP with a different protocol.