CM is the cadillac of enterprise phone systems (PBX) with almost every feature imaginable. Like many enterprise vendors, they provide GUI applications written for Windows and they work fine--if they have the features that you want to use. Once you want to start integrating with other enterprise systems and automating tasks, you run into situations where the provided tools hinder work more than they help.
The primary interface to these PBX systems is with a terminal. Originally it was a serial terminal but now telnet and ssh are available. When you log in you select a "terminal type." Most people use the screen-based VT220 interface where you type commands and use tab and return to move around the screen to make changes. It's not fun to use those screens for scripting, but there's another undocumented terminal type called "OSSI" that's designed for scripting and is used by Avaya's own GUI tools.
In this post I'll describe the web service system I've built around the OSSI terminal connection. The end result is contained within a Perl module that comprises the heart of this system.
The system breaks down into three parts:
PBXD is a server based on the Net::Server::PreFork CPAN module that manages a pool of connections to a single PBX and provides an XML interface to DEFINITY_ossi.pm. There is 1 instance of PBXD running for each of our 3 PBX systems. Each PBXD instance has its own config file.
Finally the web interface is a Perl CGI script that knows about each PBXD instance and proxies the XML requests from clients to specific the PBXD instance for each PBX.
Here's a visual description of the system
Once it's setup and deployed you have a scalable platform for rapid development of web applications to manage all of your PBX systems. We've moved both batch and interactive application to the new system and it's been working well. I hope you've found this post interesting and that it will give you some ideas and code that can help manage you own PBX systems.
The primary interface to these PBX systems is with a terminal. Originally it was a serial terminal but now telnet and ssh are available. When you log in you select a "terminal type." Most people use the screen-based VT220 interface where you type commands and use tab and return to move around the screen to make changes. It's not fun to use those screens for scripting, but there's another undocumented terminal type called "OSSI" that's designed for scripting and is used by Avaya's own GUI tools.
In this post I'll describe the web service system I've built around the OSSI terminal connection. The end result is contained within a Perl module that comprises the heart of this system.
The system breaks down into three parts:
1. DEFINITY_ossi.pmDEFINITY_ossi.pm is the Perl module that knows how to connect to all of our PBX systems, process commands, and return data either formatted like the output of the VT220 screen or as a set of OSSI fields.
2. A separate PBXD server instance for each PBX.
3. A single web CGI interface that passes XML requests between the client applications and the correct PBXD instance.
PBXD is a server based on the Net::Server::PreFork CPAN module that manages a pool of connections to a single PBX and provides an XML interface to DEFINITY_ossi.pm. There is 1 instance of PBXD running for each of our 3 PBX systems. Each PBXD instance has its own config file.
Finally the web interface is a Perl CGI script that knows about each PBXD instance and proxies the XML requests from clients to specific the PBXD instance for each PBX.
Here's a visual description of the system
Once it's setup and deployed you have a scalable platform for rapid development of web applications to manage all of your PBX systems. We've moved both batch and interactive application to the new system and it's been working well. I hope you've found this post interesting and that it will give you some ideas and code that can help manage you own PBX systems.
Wow wow wow wow wow wow wow wow wow wow! Ben, that's fantastic! I've been hunting for any OSSI documentation for years and there it is, ready Perl module implementation, just like Christmas present! Thanks a bunch!
ReplyDeleteP.S. By the way, do you have any docs on OSSI protocol or that was all reverse engineering?
Thanks for the flattering comments. It was all reverse engineering mostly based on packet captures and a bit of guessing. I've heard rumors of there being real documentation.
ReplyDeleteThis system is quite impressive. Have a bit of a problem attempting to get it running.
ReplyDeletegetting connection parameters for n1
ERROR: unknown PBX [n1]. Config must be added to config file pbx_connection_auth.xml before it can be used in production.
Can't call method "get_node_name" without a package or object reference at ./pbxd line 41.
-- child init hook --
suggestions?
Is this being maintained? Will it work with Communications Manager 6.1?
ReplyDeleteI did much of the same reverse engineering work [with Wireshark] to create a CLI utility to perform various batch functions. Great job taking that to the next level with a web interface!
ReplyDeleteKev: It looks like the error means you need to put the login credentials and pbx name in the pbx_connection_auth.xml file.
ReplyDeleteThanks Sam! It's great to hear that someone else has dug into the OSSI protocol too. And for anyone else wondering it's still working in latest CM versions and in Avaya Aura.
ReplyDeleteBen: Thanks for the solution, But I didn't understood the way you connecting between web interface and PBXD.
ReplyDeleteWhen i run, I got the following error please suggest:
Could not connect to pbxd server on 10.129.95.12: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.