Cisco Jabber for Windows Client SDK

[sa.kh.cisco]

Is there an SDK for Cisco Jabber for Windows client? I could only find the Web SDK. Are there no other SDKs that would let me control features of the Jabber Windows Client?

[Jonathan Schulenberg]

Only the URI protocol handlers it registers with Windows (eg tel: ) and the Microsoft Persona API it registers to for Office/SharePoint DLL integration.

Other than that the APIs are server-side. What are you attempting to do?

[sa.kh.cisco]

Thanks for your response, Jonathan.

I'm trying to create a WPF application that would have a dial pad and call button, which I'm hoping to use to make calls on Jabber's desk-phone functionality. Also, the WPF application should be able to listen to incoming calls in Jabber, and perform certain activities after listening to the event.

Which server-side API should I use to perform the above requirements?

[Jonathan Schulenberg]

For the make-a-call requirement you could simply collect the dial pad input and have the "call" button be a hyperlink of tel:<user input>. Jabber should pick that up and dial it.

The second part is trickier. There are a few options:

1. You could use old-school Windows TAPI by installing the Cisco TSP from CUCM (Applications > Plugins). This has the ability to achieve both of your requirements; however,  the downside is it requires a client-side update every time you patch the CUCM servers.
2. There is a long-standing web service on CUCM called WebDialer which can initiate calls from any phone, Jabber or otherwise.
3. Less so an API but if your application, preferably server-side, has a SIP stack you could issue an Unsolicited SIP REFER (this requires a security setting on the SIP Trunk Security Profile) to CUCM via a SIP Trunk. If you wanted to see how this works you can use the Cisco Viewmail app which adds a "Play via phone" function to Unity Connection's Single Inbox or Integrated Messaging functions. CUC sends a SIP REFER to CUCM which causes the user's phone to make the call.

[sa.kh.cisco]

I have a few more questions about your solutions:

1) Seems like using Windows TAPI cannot be a solution for us, because TAPI has some kind of limitation on the number of users. This was the initial reason why were trying to move away from TAPI and use Jabber instead. However, after doing some more research, seems like Jabber still uses TAPI for its CTI controls. Is this correct?

2) WebDialer can make calls. But seems like it cannot listen to incoming calls.

3) Again, the last solution seems to be able to make calls. But will this be able to listen to incoming calls and trigger certain events based on the incoming caller's number?

[Jonathan Schulenberg]

Oh right. I got distracted while writing my response and switched back to make-a-call options.

Yes, Jabber still uses CTI when controlling desk phones as do other Cisco applications (e.g. CCX). It's not going away in the near future even though it's an old protocol. The CTI scalability is documented in the UC SRND. Unless you have more than three concurrent CTI subscriptions per user or a very high user count this shouldn't be a big problem. My advise would be to install the TSP on your application server only to contain the installs of it when you update CUCM. I recommend reading about the concept of a Super Provider CTI application as it would make maintaining your application easier. Without this you have to manually associate every phone that you want to get events from to the Application User your application server signs into CUCM with (assuming you don't have the TSP be client-side and the user logs into the TSP as themselves).

The other way to listen for calls, at least in concept, is a SIP SUBSCRIBE/NOTIFY message from RFC5359. The problem is that Cisco doesn't have a documented example of this on developer.cisco.com to my knowledge. Even if they did, I believe it would only be able to tell your app about the call; it wouldn't be able to accept 3rd-party call control messages (e.g. answer, hold, end call) as CTI allows.

[sa.kh.cisco]

Seems like for Jabber Desktop Client to avoid the limitation, we are manually adding phones to Application User that our Jabber server signs into CUCM.
 

Is there a way I could build my WPF phone application such that I can use similar settings as Jabber in terms of Application User (in order to avoid the TAPI limitation similarly)? I'm guessing that we would have to create our own application server to connect to CUCM, and that it should be able to sign in to CUCM using a certain Application User.

Is there an API/guidelines to create this custom application server for my phone application? Are there any other requirements in order to be able to sign in to CUCM using a certain Application User? I'd really appreciate any kind of help. Thanks!

[Jonathan Schulenberg]

I'm not certain I follow you.

A phone must be associated to a user - either End User (i.e. real human) or an Application User (i.e. service account) - in order to observe events on it and control it (aka 3rd-party call control).

Jabber signs in as the End User, to which the physical phone should be associated by best practice. It's using the same CTI protocol for controlling a physical desk phone that the Windows TSP provides; the TSP just provides a standard Windows TAPI interface as an abstraction layer.

If you have an application server and it logs into TSP as an Application User then it would need all phones associated to that user account. The exception is if you leverage the Super Provider construct, at which point the Application User is given a different group membership and can monitor any/every device in the system.

Cisco's developer site has a lot on the guidelines and in some cases examples/sandboxes: https://developer.cisco.com/collaboration

[sa.kh.cisco]

Thanks a bunch for your responses, Jonathan. Honestly, it's just your responses that are giving me some breakthroughs in my project at the moment.

I've tried to read more about Application User and Super Provider, and I've come across guidelines to configure them, however, I haven't been able to find an overview description about them. So, my knowledge about them is very limited.

We are creating this app for a third party that has Cisco Environment. So, we directly do not have access to make changes to their Cisco Environment. At the moment, seems like the third party does not want to leverage Super Provider construct. And in order to avoid TAPI limitation, they say they have started using Jabber which controls all phone functionalities through an Application User connected to the Call Manager.

We were wondering if we could mimic this with our own WPF phone application (which currently uses TAPI and does not overcome the user limitation). We were wondering if there is a way to create an Application Server for our app and use an Application User to connect to the CUCM. Are we headingin the right direction? Are we missing something?

[Jonathan Schulenberg]

And in order to avoid TAPI limitation, they say they have started using Jabber which controls all phone functionalities through an Application User connected to the Call Manager.

Assuming they are referring to the normal Jabber for Windows/Mac/iOS/Android applications then this is wrong. Jabber - the client, not the IM&P servers which are part of the CUCM cluster (if you're familiar with Lync consider CUCM+IM&P servers a Front End Pool) - do not use an Application User at all. When a user starts Jabber, assuming SAML SSO is off, they supply an email address. This is used to find the servers via DNS SRV records, or the Mobile and Remote Access Expressway (roughly analogous to a Lync Edge pool) to tunnel through the firewall. After the email address they are prompted for their End User username and password. This is then used to access several APIs on the server, namely the User Data Service to discover what the user has. This would include what the user has configured/available to them. After this is done the Jabber client does one of three things with respect to phone functionality:

1. If the user has no phone devices provisioned for them - physical or software - it becomes an IM&P client only.
2. If the user has a software phone phone provisioned, it registers as that using SIP. In this way Jabber is the actual phone. This is called a CSF device for Jabber Windows/OS X.
3. If the user has a desk phone assigned to their End User account AND administrative policy is to default to desk phone control, it registers to CTI Manager on the CUCM server to control the user's physical phone.

A user can toggle between option two and three, if appropriately provisioned, but cannot have both simultaneously. In other words, Jabber is either controlling a physical phone over CTI or is a phone itself using SIP. The difference is where the audio/video media is sent from/to.

All of this happens using that human's End User credentials.

Now, if you wanted to have a server control the user's phone - either a physical one or Jabber - you would use the TSP as an interface to CTI Manager on the CUCM server and receive real-time events (e.g. the user went off-hook, the phone is ringing with this caller ID, etc.) and issue commands to that phone (e.g. make a call to X). This is done using an Application User account because the server would need to do this for multiple users simultaneously. If you also use the Super Provider concept, the CUCM administrator doesn't have to take the extra step of associating every phone to your Application User manually. Instead, you can simply issue CTI subscriptions to see any/all device activity you want.

This is all assuming you wanted to do the integration server-side to avoid having to update the Cisco TSP application on every user PC (which also limits your WPF application to machines capable of running the TSP) every time the CUCM administrator patches the servers. If you don't care about that, then you can do this all client-side on the user's PC, and have them supply their End User credentials.

Of course, you could also reconsider the Jabber SDK and just embed the make/receive call functionality directly into your application instead.

[sa.kh.cisco]

Thanks for the detailed response, Jonathan!

Seems like we lack a lot of information on the back end of Cisco that is required for this project. I'm sure following your guidance would have lead to a proper implementation of the project as we had initially planned.

However, we recently came across the Accessory Manager API in Cisco Jabber for Windows, and realized that it provides call control as well as callbacks for call events. Seems like we will be able to use this for our requirement.

Thanks again for your response. It helped to clear a lot of things we hadn't understood, and I'm sure it will help future Jabber developers as well. 

[Jonathan Schulenberg]

That's actually a pretty good idea. It didn't occur to me in part because you're not building a physical accessory (eg. headset) but also because it's not an entirely public API; using it in a supported manner requires you be a Solution Partner Program. This is stated on the DevNet page for the Accessory Manager API.

I'm not entirely sure what the implications are if you leverage that API and something breaks. I'm pretty sure the customer can't call Cisco TAC for help; typically Cisco wants ISVs to have a developer support contract in place instead. I suggest reaching out to that channel team to ensure you know what the rules are.