Bringing Telephony Features into SIP Networks with Back To Back User Agent
Amir Zmora
Product Marketing, SIP Products
Technology Business Unit
RADVISION
Amir Zmora is responsible for product marketing, SIP products, for the Technology Business Unit of RADVISION. RADVISION is a leading provider of products and technology for real-time voice, video and data communications over packet networks. The company offers enabling technology and videoconferencing networking systems to enable enterprises and service providers to migrate their voice and video communications from traditional telephone networks to new converged networks.
Defining the need
When looking at VoIP architectures, everyone naturally focus in on the advanced functionality and features enabled by packet telephony-based communications such as presence and instant messaging, application sharing, mobility and more. This is a natural event as increased revenue or reduce cost are crucial criteria to justify moving from PSTN to IP. Naturally SIP (Session Initiation Protocol) enables many of these added value features. However, there is a missing element in the current dialog of migrating from PSTN to SIP-based communications - Class-5 telephony features?
In the PSTN network of today we consider features such as call transfer and call waiting as trivial. However providing these features in a VoIP architecture is no easy feat. The same challenge holds true when looking at enterprise PBXs, which have hundreds of features that are required both for everyday employee communications as well as call center applications.
In order for the VoIP-based telephony architecture and network to replace the existing TDM-based telephony system there is a bare minimum requirement that the telephony features exist and function in an interoperable manner.
Implementing Class-5 Telephony features in SIP
SIP User Agents (UA) are "smart" entities that hold call state and can implement a wide range of telephony features end-to-end without the need for a centralized control entity such as PBX. Nevertheless some features do require a centralized entity such as a PBX or Class-5 switch and these types of entities may increase interoperability.
Can a SIP Proxy do the job?
A SIP Proxy is an intermediary entity that mainly plays the role of routing. It decides about call routing and forking and also may apply policy and authorize certain calls to certain users. A SIP Proxy may not alter SIP messages and change message headers or body (except routing related headers such as Via). Additionally a SIP Proxy may not initiate disconnection of a call or creation of a call between 2 UAs.
SIP Back-To-Back User Agent Figure 1: Basic B2BUA functionality
A SIP Back-To-Back User Agent (B2BUA) takes what is traditionally a SIP end-to-end call and mediates it through a central SIP server. The B2BUA enables service providers to manage and track a call from beginning to end, integrate and offer new value added features, and bring Class-5 type functionality to IP networks.
The SIP standard briefly defines a B2BUA as a logical entity that receives requests as a User Agent Server (UAS) and in order to respond to them, it acts as a User Agent Client (UAC) and generates requests. Additionally it maintains dialog state and must participate in all of the requests sent on the dialogs it has established. The standard defines it as a concatenation of a UAC and UAS and therefore doesn't provide additional definition for this entity.
Issues in B2BUA functionality
The B2BUA functionality breaks one of SIP's advantages of end-to-end service because it prevents a UA to directly contact the destination UA by mediating the call between them. This prevents direct implementation of features such as REFER and exchange of secured bodies using S/MIME. Therefore a B2BUA should be used only in cases where such mediation is required/desired, usually when central call control is required.
Development with B2BUA
From the application perspective, the B2BUA enables deployment of voice and multimedia telecommunications equipment that seamlessly interwork with other communications networks and deliver centralized call and feature management. Products that benefit from SIP B2BUA include softswitches, application servers, SIP-based IP-PBXs, conference bridges, firewall/NAT traversal applications, 3G servers, call center applications, media servers and voice mail applications.
With the B2BUA module, the SIP server becomes an active participant in the call from beginning to end as all signaling messages pass through and are processed by the B2BUA at all times. A B2BUA maintains call state and actively participates in sending requests and responses for dialogs in which it is involved.
This B2BUA functionality provides major new applications including:
- centralized call management
- interworking with alternative networks
- SIP--based VoIP interworking between LAN and WAN
- management and monitoring of the entire call state
- cloaking of endpoint location
- Centralized call management
One of the most common uses of a SIP B2BUA is for development of Class-5 Switches, PBXs and Call Center applications. The B2BUA provides centralized call management with its active participation in a call. This feature gives the application tight system/call management. This opens the door for a wide range of features a B2BUA can implement:
Automatic Disconnection of call - A Pre Paid application requires the ability of warning the caller prior to exhaustion of credit and disconnection of call when credit is exhausted. A B2BUA can manipulate call signaling and SDP in order to play a warning from a media server, this can be done for example by opening an additional leg of the call to the media server and sending re-INVITE message to the caller UA with proper SDP making sure only the caller will hear the warning message.
Automatic connection of two party call - A B2BUA may act as what the standard defines as Third Party Call Control (3PCC) and connect a call between 2 UAs. The draft draft-ietf-sipping-3pcc-xx.txt (xx stands for version number that may change, current version at time of this publication is 04, please see IETF WEB site for latest version - www.ietf.org) defines different possible scenarios, 2 of them (1 & 4) are the most recommended ones where 1 should be used when the destination is an automatic machine such as voice mail or media server and scenario 4 is recommended for other cases such as calling someone's SIP phone. This type of functionality has many implementations one example can be in a call center where calls can be done according to a certain data base or queue of customers who requested a call at a certain time. This will require the application to detect a free agent and connect a call between the agent and the customer. This will require the B2BUA to act as the controller, initiate messages and manipulate SDP. In some cases it will be required that a supervisor will join the call in listen only or whisper mode (to instruct the agent) and therefore B2BUA will need tight control over call signaling and participate in entire call duration.
Figure 2: Third Party Call Control
Figure 2 may seem complicated but this message flow is required to avoid a timeout problem. Theoretically it is possible to follow scenario 1 defined in the 3PCC draft (scenario not illustrated in this article) and send to UA1 INVITE with no SDP that will require it to answer with an SDP offer that will be placed in the INVITE sent to UA2. In this case the SDP of UA2 will be sent to UA1 only in the ACK and therefore the ACK of the first INVITE to UA1 would need to be delayed until UA2 answers the INVITE with 200 OK and SDP answer. Since UA2 can be any type of UA the answer may be delayed and as a result of that UA1 will retransmit the 200 OK. UA1 will continue to retransmit the 200 OK for T1*64 seconds and if by then the ACK will not arrive the call will fail. The scenario presented here (numbered 4 in the 3PCC draft) avoids this possibility. The conclusion is that these 2 scenarios should be used with caution and in any case a B2BUA is the natural entity to implement the controller functionality.
Call Transfer - SIP defines the method REFER and other headers for the implementation of Call Transfer. Call Transfer functionality can be implemented end-to-end without any centralized intervention. There are reasons (some technical and some financial) to implement this functionality in a centralized entity such as Class-5 switch/PBX. For example SIP UAs may support different versions of the REFER draft or one may not support REFER at all, this will cause interoperability problems. A centralized entity that implements this will enhance interoperability in such a case.
Interworking with alternative networks
The B2BUA can be used for implementation of interworking applications for example between H.323 and SIP. Since the B2BUA is acting as a UA in the call and is actively processing signaling and message bodies throughout the duration of the call it may have one leg in the SIP network and another leg in a different VoIP network such as H.323. This feature is important for service providers with next generation networks who currently have to support both SIP and H.323 entities.
SIP--based VoIP interworking between LAN and WAN
FW and NAT traversal is yet another cavity of VoIP deployment. Different solutions are introduces in the market and standard bodies. For example Interactive Connectivity Establishment (ICE) that defines a methodology that uses existing protocols such as Simple Traversal of UDP through NAT (STUN), Traversal Using Relay NAT (TURN) and Real Specific IP (RSIP) for NAT traversal. Another common solution is a Protocol aware FW that does stateful inspection of packets and maintains call state for allowing VoIP traffic traversal. A third option that some criticize but yet is deployed and provides a quite simple solution is an Application Server. This entity typically resides in the DMZ (Dematerialized Zone) and bridges between public to private network addresses by changing VoIP message contents and by routing RTP traffic via an RTP Proxy.
In order to implement such functionality in SIP A B2BUA is required because it needs to be an active participant in the call and have the ability to modify SIP message headers and SDP (Session Description Protocol) body content in order to switch between public and private addresses.
Management and monitoring of the entire call state
Certain applications such as billing systems require monitoring of call state and call history. This type of functionality can be implemented by both a Call Stateful Proxy and B2BUA since both hold call state. A Call Stateful Proxy may require to be on the routing path of all SIP messages related to a certain call and a B2BUA is taking an active part of the call. On the other hand a B2BUA may also manage the call and decide for example to disconnect a call that is running out of pre paid credit.
Cloaking of endpoint location.
The B2BUA by its nature allows for cloaking of endpoint location, enabling both custom anonymizing services as well as replicating circuit-switched private number telephony services. Since all signaling passes through and is processed by the B2BUA, developers can now offer applications and platforms that dynamically cloak the identification of endpoints. SIP also defines several privacy documents that allow keeping the privacy of the caller without usage of B2BUA.
Summary
As we have seen in other VoIP protocols, one of the barriers for deployment was providing basic telephony functionality such as supplementary services. Users first want the basics such as Transfer before they consider deployment of VoIP and its new exciting features. Additionally, even though a SIP UA (as in H.323) is a "smart" entity that can implement all required functionality such as Transfer and other supplementary services, service providers as well as many PBX manufacturers prefer having a centralized control server for financial and technical reasons. A centralized control entity will help bridge between different standard implementations (e.g. will enable execution of Transfer even if the transferor doesn't support REFER or different versions of REFER are supported by different UAs). Since a B2BUA provides a solution to all these challenges, I personally believe it will be an accelerator for SIP deployment.
As the experts in voice and video over IP, RADVISION is the global technology leader in real-time IP communications for next generation networks. RADVISION products and enabling technology provide the "building blocks" needed to enable the Internet infrastructure to support real-time voice and video communications. As the technology partner of choice for both industry giants and innovative startups, RADVISION's products and technology are used by hundreds of companies vying for market position in the rapidly growing, multi-billion dollar IP telephony arena.
www.radvision.com