On March 4th we gave a presentation at the XMPP / IETF Meetup at Mozilla HQ in London.
We covered the problem we set out to solve (disparate and fragmented telephone systems in the enterprise) and how we went about solving it so as to unify events and call control using XMPP.
6. GLOBILITY UNIFIED SERVER
The Solution for Unified Communications
• A scalable and distributed messaging platform
• Open + Extensible
• Secure
• Compliant
• Federated
Hello everyone, I’m Leon Roy, CTO at Globility. We’re a small software company in the heart of London and would like to thank Steven, Laura and their team for organizing this fantastic event and giving us the opportunity to share what we’ve been doing in the XMPP space.
To begin with I’d like to start by taking you back - the year is 2006…the world’s major financial firms and large enterprises were spending billions of dollars
On telephony devices made by companies like Cisco, British Telecom, Avaya, Nortel. The list goes on…most of these institutions would have devices made by more than one company.
These phones ranged from simple £500 desk phones to £10000 Dealerboards capable of handling several hundred simultaneous calls and dozens of mixed audio streams. These tel systems existed as islands within the ent. Isolated from CRM or Addr Book apps end users were having to dial 100s of contacts a day, manually - real chore. As time went on integration opened up w/ vendors providing APIs which allowed integration with apps like Outlook’s addr book and CRM solutions like Salesforce. Click2Dial or CTI as it’s known became more and more common.
The only problem was - each vendor - had their own API. Cisco JTAPI/TAPI, Avaya JTAPI, Microsoft TAPI/CSTA, Etrali Proprietary API, Nortel Proprietary API, IPC Proprietary API, Speakerbus Proprietary API, BT Proprietary API, even Asterisk had their own custom interface.
We saw an opportunity - to unify these disparate APIs behind a single common API and provide a rich set of value added libraries and software on top. Our requirements were scalability and fault tolerance, an open and extensible protocol and architecture, security and encryption as standard, compliance and ideally federation. To be honest, only one technology really stood out for us.
Enter XMPP, extensible, secure and federated it satisfied all our requirements - the next question for us was which XMPP server to use - there were a number of proprietary and open source ones, but the server which really caught our eye was Openfire. It was Java, for which there are a tonne of libraries to make our life easier when it came to unifying these disparate telephony APIs. It also had a great plugin architecture which meant we could create plugins for each vendor and simply drop them onto the system. Java and Openfire were important technologies to bring our customers on board since it allowed us to close source some plugins and open source others. The third part was our XMPP extension. GTX.
We built plugins for nearly all the major vendors and added a rules engine and compliance layer on top to log all messaging in and out of the system, log all telephony actions as in who answered or made what call, to whom, when and for how long.
We built custom classes for client libraries in .NET, Java, Javascript, C++ and Flash and build our own client from the ground up.
Now onto the actual XMPP messaging. The first step for any connecting client is service discovery and we communicate our protocol, its capabilities and version.
A simple make call looks like this. We simply specify the system, which is typically the component node and we specify the destination number.
Our system returns either an error or the state of the newly created call in the IQ result, with callid and state as well as the actions available on the call, in this case dropCall.
The user receives subsequent events as XMPP messages with the callid and a notification of what change triggered the event, in this case it’s the state which has gone CONNECTED. In addition the user can see that they can perform two operations on the call, dropCall and holdCall. The user decides to drop the call…
The user sends dropCall along with the corresponding callId.
The IQ result contains the response to the dropCall which contains the new callState IDLE.
The client receives a final XMPP message stating that the call event has change to IDLE.
Hello everyone, I’m Leon Roy, CTO at Globility. We’re a small software company in the heart of London and would like to thank Sean, Laura and their team for organizing this fantastic event and giving us the opportunity to share what we’ve been doing in the XMPP space.