This chapter introduces the concept of added-value services and their implementation in IP
Telephony products.Value-added services are services that integrate VoIP with other protocols and services. Seamless integration with Web, E-mail and potential other Internet services provides convenience which, is a key feature of Internet telephony.
|- 6.1 Web integration of H.323 services
A natural extension to any Internet service nowadays is its integration with the Web.
Unfortunately, H.323 is more difficult to integrate with Web interfaces than SIP, due to the complexity of the protocol and its roots in the telecom world.Web applications that would be much needed in the area are the following:
- Presence: Web-based applications that allow a group of users to indicate their availability for accepting calls and to check availability of others. Analogous to the classic ICQ-type application, H.323 presence applications could stir-up significantly more users if they were widely available;
- Click-to-dial: Web-based applications that allow users the ease to click in order to make a call to a target endpoint, service set up or user. Obviously, H.323 endpoint applications are harder to set up than e.g., MP3 client-applications that download media streams, and this has a limiting effect on their use. Achieving the ease of use of a click-to-dial interface would have a dramatic effect on the deployment of H.323;
- IPPBX management: Web-based applications that allow administrators of an IP-based PBX
system to monitor and control calls being made.The simplicity of use of such Web interfaces would allow the equivalent of a switchboard operator to: transfer calls, initiate multi-party calls, answer calls on busy, and terminate calls.
The applications above are mostly found in commercially-available integrated solutions and they employ proprietary methods that are extremely difficult to integrate with custom-made Web interfaces. If you are interested in setting up your own Web-based application and integrate it with your H.323 services, you must find the means of connecting it to the gatekeeper you have deployed.The methods are many and vary from gatekeeper to gatekeeper, depending on the available APIs and supported interfaces.
In this section, we will simply list some of the options available for interfacing with common gatekeepers. For more information please refer to Appendix B.
|- 6.1.1 RADIUS-based methods
If you are simply interested in making a presence application, then any gatekeeper with RADIUS
support can be interfaced with, through proper RADIUS server set-up. For example, the P.173
[IP Telephony Cookbook] / Setting up Value-added Services
FreeRADIUS server can be configured to execute an external script each time an authentication is made.This method can be used to keep a list of currently registered endpoints on the gatekeeper and make it available over the Web as a primitive means of advertising availability. A slightly better method would be to configure FreeRADIUS with MySQL back-end and maintain a database table with currently registered endpoints, by updating the table for each RADIUS
event (authentication and accounting).
|- 6.1.2. SNMP-based methods
An alternative to the above method is to use SNMP to interface with your gatekeeper, assuming it has SNMP support.The Cisco MCM has SNMP support but with limited functionality, while the RADVISION ECS supports the H.341 standard for SNMP access.You can explore the options available to an external application, interfacing with SNMP by carefully studying the supported MIBs for your gatekeeper.
|- 6.1.3 Cisco MCM GK API
The Cisco MCM Gatekeeper actually implements a very flexible API for receiving events that the administrator is interested in processing.The external application can choose to further process the event, or just log it for informational purposes.The API interface to the MCM is proprietary and based on the GKTMP ad-hoc protocol for informing the external application of RRQ, URQ, ARQ, LRQ, DRQ, BRQ and related (confirm/reject) events.The API allows the external application to issue respective confirm and reject (xCF,xRJ) commands for specific events, based on external application logic. Cisco provides a library in C and template code for an external application, but it is not fully working code and requires significant resources to be applied before a demo application can be built. Also commercial solutions from Cisco partners exist which are based on this same API (see GK API Guide Version 4.2).
|- 6.1.4 GNU GK Status Interface
The GNU Gatekeeper provides a very useful command-line interface for monitoring and control of gatekeeper operations. It is called the ‘Status Interface’ and allows telnet connections from remote administrative nodes to connect and monitor RCF/RJ, UCF/RJ, ACF/RJ, LCF/RJ, DCF/RJ, BCF/RJ events with detailed information.
Additionally, it allows monitoring of call detail records (CDR) for accounting applications and RouteRequest messages for interfacing with the ‘Virtual Queues’ feature, proprietary to the GNU Gatekeeper.The fact that many different nodes can connect at the same time over this administrative interface and process different events of the gatekeeper, allows for a distributed and flexible implementation of monitoring services. Indeed, a number of tools have been developed that build on this interface and provide interesting functionality:
- OpenH323 Gatekeeper Java GUI: this interface allows the monitoring of registrations and calls on the gatekeeper and provides endpoint information as well. Source code is available to modify for added functionality, if needed;
P.174
[IP Telephony Cookbook] / Setting up Value-added Services
- Sample ACD application: this interface allows the definition and management of groups of endpoints (agents) who will handle a large volume of calls for a single alias.The ACD will check which of the agents is qualified and available (not in another call and not logged off from ACD work) and informs the gatekeeper which agent will receive the call. If no agent is available, the ACD will tell the gatekeeper to reject the call. All call routing logic is kept out of the gatekeeper to ensure stable operation, while routing logic can be changed frequently;
- PHP GNUgk Status Monitor - v0.4: this application allows monitoring of registered endpoints and calls in progress through a PHP Web interface. Call disconnection is possible and further functionality is being developed. Source code is available.
|- 6.2 Web integration of SIP services
This chapter provides an overview of some added-value services implemented using a Web interface. Serweb, the Web interface for the SIP Express Router described in Chapter 4, will be used as an example implementation of Web-based added-value services for SIP
Integration of SIP services with Web interface is the most common scenario. A Web interface is often used for the provisioning of SIP products and for the implementation of advanced services.
Web browsers are available in the vast majority of existing operating systems.
|- 6.2.1 Click-to-dial
Click-to-dial is a method of establishing a call between participants using a Web interface. It greatly simplifies dialling, in that calling parties do not have to dial lengthy addresses and they keep their phonebooks separately from SIP phones. In its simplest form, a user has a Webpage where he can enter the SIP addresses of two users, and the SIP user agents of those two users get connected.We will focus on REFER-based click-to-dial.
A REFER-based click-to-dial scenario is based on the paradigm of intelligent end-devices and dumb network. One of the involved SIP user agents is asked to connect to the other and report to the server when it is done.
The drawback of this approach is that one of the involved SIP user agents must support the REFER SIP method which has been standardised recently (see RFC3515).The big advantage that balances the previous drawback is that it is extremely easy to implement REFER- based click-to-dial in the server. Call-flow for REFER-based click-to-dial is depicted in Figure 6.1.
First, the SIP server sends an INVITE to one of the phones because phones usually do not accept REFER without prior invitation.The INVITE contains 0.0.0.0 as the IP address in SDP, because there is no remote phone (the message is sent by user agent within the SIP server which does not deal with media).
After that, the server sends a REFER method which will ask the phone to send INVITE
somewhere else.The URI of the called party is passed to the phone in a Refer-To header field of the REFER method.
P.175
[IP Telephony Cookbook] / Setting up Value-added Services
The phone sends a NOTIFY method back to the server once the connection is established.
The click-to-dial feature allows the creation of many advanced features, like phone-book, in which you can click on an entry and your phone and phone of the person represented by the entry are connected.You can implement a list of missed call in exactly the same way and clicking on an entry in the list will connect your phone with that person. There are many others possible scenarios.
SIP Server
UA1
UA2
INVITE
200 OK
ACK