Las Vegas actively cultivates its reputation as the edgiest of American cities…so it’s rather fitting that Cisco would go there to announce its Cisco® UC Gateway Services API, a Web-based application programming interface hell-bent on opening up the edge of the enterprise voice network to enable more voice services on the most widely used edge router in the industry, the Cisco Integrated Services Router Generation 2 (ISR G2) router. And that is not just any voice network edge – it is the entire network voice edge, since the Cisco UC Services Gateway API is supported with Cisco TDM Gateways and Cisco Unified Border Element (CUBE) for TDM and SIP trunking respectively. Therefore, no matter where you or your customers are in your migration to SIP, you can leverage the API and related applications.
The net-net: scammers looking to launch the next TDOS attack should be very, very scared. And developers looking to make apps to thwart these criminals should be very, very happy.
You can learn more about the API by reading our press release and watching this hot-off-the-show-floor video
Still want more? You should go hit the tables tonight because clearly this is your lucky day, and by that I mean yes indeed I have more for you. I just so happened to sit down with the one and only John Vickroy, the product manager responsible for the Cisco® UC Gateway Services API, for the behind-the scenes story. Here’s what he had to say:
Why did Cisco decide to develop this API?
We had two motivations: first, we wanted to get real-time information into the hands of developers. Second, we wanted to get them that information in a way that is readily available and actionable.
We realized there was a lot of information in our gateways—both our TDM and our session border controller SIP trunking gateways—that would be useful to third-party developers if we could make it readily available. But at the time, that information was available only through multiple different protocols—RADIUS, syslog, and SNMP. We didn’t want to get rid of those protocols but we knew that pulling them all together in a web format would allow us to reach a large number of developers who in turn could develop a large number of value-added solutions that could be integrated with our gateways.
We also realized there would be significant value in allowing our gateways to be controlled in a real-time mode while each call is active to obtain session information and media information about that call as it is happening. The media information is contained in RTP packets—those are the packets that carry the audio or video content; they tell you whether it’s voice, video, or modem traffic as well as things like busy tones and dial tones that are sort of part of signaling but also part of media. And finally it includes items like DTMF tones which occur while you are actually placing the call—think of “press number one for the Operator”. Being able to detect those in real-time would be valuable to certain development partners who want to create applications that can observe the real-time progress of the call and then take action on those calls. Action on those calls may be call termination, redirection or media forking. The real-time aspect added value above and beyond what was available via RADIUS, syslog, and SNMP.
The API gives developers complete visibility of what’s happening with calls historically and in real-time in an easy to access web-based developer format.
How do you envision developers will use this information?
This is what’s so exciting—the API can be used by a wide range of developers for a variety of applications. Too many other management tools for voice networks are focused on “serviceability” (think: “is the call working? Is there poor audio quality? Is there One-way audio?”) In other words, they are focused purely on the technical aspects of monitoring the voice network.
This UC Gateway Services API enables “call-detail records”—a very traditional third-party application to allow organizations to keep track of the calls they make. It also allows developers to take monitoring and control of the voice network to the next level, allowing companies to evaluate calls by asking “is the voice network being used in a way that aligns with the goals and objectives of the organization?” Policies can be defined for outbound calls—an organization can, for instance, restrict long-distance calls or even prevent employees from dialing certain numbers. For inbound calls, policies can provide security to protect against abusive calls, TDOS, harassing calls, and identity theft.
Our first development partner, SecureLogix, is providing enterprise-wide monitoring and control by providing a centralized policy management tool that uses the UC Gateway Services API to interact with all of the Cisco voice gateways in the network—whether they are supporting TDM or SIP gateway deployments. Since the UC Gateway Services API is supported on both our TDM Gateways and Cisco CUBE (Cisco’s session border controller used in SIP trunk edge environments) , SecureLogix can provide a centralized policy mechanism for the entire network. That policy mechanism is able to allow for flexible, nuanced control for the best protection from voice security threats. By defining policy to identify call sessions based on area code or by dialed number, organizations can more quickly correlate and identify threatening external calls. For example, they can identify unusual patterns that may not be reasonable calls the organization should be accepting. The UC Gateway Services API provides that information for each Cisco UC gateway and enables applications to deliver very sophisticated ways to protect the voice network.
Another category is capacity management; this API gives rich options for analyzing the capacity of your voice network. For example, most voice capacity management applications can only provide information about the utilization of the voice circuits. But, using the UC Gateway Services API, capacity management applications can also determine how many unanswered or busy calls occur in the Cisco Voice Gateway, thereby enabling an additional dimension of capacity to be analyzed that speaks to the human resource needed to support the business calls to the enterprise.
And yet another broad category has to do with voice recording—the ability to perform media forking on a call on a case-by-case basis. With this API you can identify a particular line coming in from the outside and say, “we want all calls from that line recorded”. Or perhaps you want to do it on a statistical basis—record every, say, 10th or 20th call for quality assurance purposes. It also gives you the ability to turn recording on and off during a call so you don’t have to record a call in its entirety—important for bandwidth management.
Is there a specific reason Cisco delivered this API right now?
It was largely based on the market trends. Voice over IP in general and the SIP protocol in particular are making voice network calls overall more efficient. But there’s a dark lining: it makes it easier for external bad guys to do things with the voice network that previously, in an all-TDM environment, were difficult and costly to do. Harassing calls, TDOS…voice over IP enables misuse of the voice network in a relatively inexpensive manner. With a little bit of brains and a PC, the bad guys can do quite a bit of damage.
We saw an opportunity to enhance our product to counter this voice attack scenario, so instead we opted to create an API. A web-based API made perfect sense and we committed to the project for that purposes. The other use cases—media forking, capacity management, call detail records, serviceability—sprang up logically and organically from there.
Will this functionality take the place of SNMP?
SNMP is here to stay. It is fully embedded. But certainly the web-based technologies are also here to stay and in the long-term this will be a great mechanism for significant additional value add integrated into our gateways—both from Cisco as well as from our partners.
How hard is it to create an API like this?
This API fits into Cisco’s overall concept of Software Defined Networks and cloud-based computing. This was not a small development project, I won’t go into budget or number of people required to bring it to the market, but now we can deliver significant functionality relatively easily—so you can certainly expect to see new features made possible by this API coming out beyond what was announced today.
How difficult is it for a third-party to use the API?
Very easy – especially for third-party developers who are interested in real-time call control for enterprise and commercial customers and are familiar with web-based programming.
Do you have any advice for developers looking to leverage this API?
Make sure you understand why you want to interact with real-time voice communication. Not every application that uses this API needs to interact with real-time data—call detail records , for instance, are dependent on call completions. But most of the value of this API is going to be in observing and controlling the real-time communication traffic—both the signaling and the media. Be sure to check out the Cisco Developer Network, which has overviews of the API and more information about the real-time call control that’s made possible by this API.