Our web based attendant console software can connect to a LOT of different phone systems. We can connect to Mitels and Nortels and Avayas and Ciscos and Broadsofts and… SNOMs?
One of the questions we get asked a lot is “can your software work with my phone system?” and the answer to that question is almost always yes, but how that happens varies from system to system.
As an example, when we connect to a Mitel phone system to provide our virtual call center software, we use a technology that Mitel created called Mitai to communicate with the Mitel. Mitai is a proprietary protocol that only works with Mitel phone systems and enables us to be notified when calls are ringing on an operator phone and it also allows us to answer/transfer/put on hold/etc. those calls.
On Avaya systems we use their DMCC protocol
On Broadsoft systems we use CAP-C or CTI or XSI (Broadsoft has really good support for third party applications, but that’s a completely different story)
But what about all of those Asterisk based systems e.g. Free PBX, TrixBox, etc. – how do we connect to all of the SIP PBXs out there?
Well the answer to that question requires that you know a little bit about how SIP works.
SIP is the industry’s answer to creating a standard protocol for call management. SIP basically allows any handset or PBX to communicate with one another even if they don’t know anything about the other device. For example, a SIP device made by Polycom can communicate with a PBX made by Asterisk without either system ever having heard about the other one. SIP is the standard that enables this. In order to make this possible SIP is extremely simple, it has only the most basic provisions for call management, you can make a new call (INVITE), send that call somewhere else (REFER), and hangup on a call (BYE).
I am simplifying things greatly and I do realize that there is more to SIP than those 3 things, but for the sake of this argument, the argument will hold.
SIP was designed to be an endpoint (phone) to server (PBX) type protocol, it can also operate endpoint to endpoint, but what it wasn’t ever designed for was third party control. Evo is the third party. There is no way with SIP for us to send a message to a phone that says “hey answer that call” – it just doesn’t work that way. In order for us to be able to do that, we would have to essentially act as a PBX and have the SIP phone register with us as its phone system – way too complicated for what we do.
So what does any of this have to do with SNOM?
Every SNOM phone has a built in (standard) API that allows us to control it. We can do every single thing you can do physically with the handset through code. We can answer a call, put a call on hold, transfer the call, etc. This works by us sending messages directly to the phone instead of the PBX which is how the above protocols work. Since SNOM phones are SIP devices, they can operate with Free PBX, TrixBox etc. and then we can control the SNOM directly to provide our services on those systems.
http://wiki.snom.com/FAQ/Can_I_control_my_snom_phone_remotely
One side note to this whole thing. Broadsoft is also a SIP based PBX and the company has built a third party call control API (CAP-C/CTI) that operates with almost all SIP devices and allows our application to connect directly to the PBX and control ANY SIP DEVICE. That means on a Broadsoft system, you can use Polycom phones, Cisco phones, Yealink phones, and yes even SNOM phones and our software can work with it. Most other SIP based PBXs have not done this work which is why we require SNOMs.
Leave a Comments