B2BUA: Enabling Class 5 Capabilities in SIP Designs
Posted on 2005-01-06 16:19 freshventure 阅读(849) 评论(0) 收藏 举报] 09, 2003 (3:43 H)
URL: http://www.commsdesign.com/showArticle.jhtml?articleID=16502048
Session initiation protocol (SIP)-based voice-over-IP (VoIP) designs certainly provide some interesting benefits over today's Class 5 switching systems. SIP enables capabilities like presence, instant messaging, application, and application sharing—all of which could prove to be strong future applications.
But while SIP has excelled in providing new services, designers have struggled building SIP-based systems that can provide the Class 5 services that end users demand. Users first want the basics, such as call forwarding and transfer, before they will consider deploying SIP-based VoIP and all the exciting new features and functionality it delivers.
To solve this problem, VoIP designers can turn to the back-to-back user agent (B2BUA). B2BUA takes what is traditionally a SIP end-to-end call and mediates it through a central SIP server. Because it is mediated through a central device for the entire duration of the call, 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.
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. Let's take a closer look at B2BUA and examine its impact on a SIP-based VoIP design.
ABCs of B2BUA
B2BUA is a logical entity that receives requests as a user agent server (UAS) and, in order to respond to them, 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 (Figure 1).
The well-known SIP specification, RFC 3261, does not define special functionality for B2BUA, but rather defines it as a concatenation of a UAC and UAS. As such, B2BUA is not a standard, it is an entity that can be inserted into SIP designs.
From the application perspective, a 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.
There are five key features that the B2BUA delivers to a SIP-based VoIP architecture, which we will explore in detail below. They are:
- 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.
Let's look at each in more detail.
1. 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 and opens the door for a wide range of features a B2BUA can implement:
This type of 3PCCfunctionality has many implementations. One implementation can be in a call center where outbound calls are handled 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. Thus, the B2BUA must act as the controller, initiate messages, and manipulate SDP. In such an application, the scenario defined for the B2BUA in the 3PCC draft will connect the call between the agent and the customer.
This isn't to say that designers can't choose an option for connecting a call between an agent and a customer without using a B2BUA. They can always use the REFER message, sent by the controller to the agent's phone, and cause the agent's phone to call the customer. This type of implementation will remove the centralized control delivered by the B2BUA.
However, this application will not be sufficient in all cases. A B2BUA will be necessary for applications where there is a need for the server to be on the signaling path and be able to, for example, add another media path for a supervisor to join the call. In this application a B2BUA acting as 3PCC functionality is required.
The scenario presented in Figure 2 (numbered 4 in the 3PCC draft) avoids this timeout failure. The conclusion is that application developers should choose one of these 2 scenarios according to the nature of destination UAs and if this is not know the scenario illustrated in figure 2 is preferred. In both cases a B2BUA is the natural entity to implement the controller functionality.
2. Interworking with Alternative Networks
The B2BUA can be used to provide interworking between different signaling networks. 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.
3. Interworking Between LAN and WAN
While internetworking between signaling networks is easily solved, firewall and network address translation (NAT) traversal pose headaches for VoIP developers. Since IP traffic is filtered and modified as it passes into the local network, creating a challenge when establishing a real-time point-to-point multimedia connection.
Different solutions for this problem have been introduced in the market and standard bodies. For example, the interactive connectivity establishment (ICE) 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 firewall 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-level gateway (ALG). This entity typically resides in the dematerialized zone (DMZ) 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 an ALG in SIP, a B2BUA is required rather then a proxy server because it will need to be an active participation in the call and have the ability to modify SIP message headers and SDP body content in order to switch between public and private addresses.
4. Managing, Monitoring Call State
Certain applications such as billing systems require monitoring of call state and call history. Designers can implement this functionality using both a call stateful proxy and B2BUA since both hold call state.
A call stateful proxy may require that it be located on the routing path of all SIP messages related to a certain call and a B2BUA would take 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.
5. Cloaking the Endpoint Location
The B2BUA allows for cloaking of endpoint location, enabling both custom anonymizing services as well as replicating circuit-switched private number telephony services (even though there are drafts defining privacy in SIP by other means). 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.
Users Beware
B2BUA is a radical departure from how many see SIP-based communications. Much as an enterprise's PBX controls all calls in the network, or a carrier's Class 5 switch controls calls on the PSTN, the B2BUA also plays a central role in every SIP VoIP call, from beginning to end.
However, this article is not without a warning. Developers need to be aware that a B2BUA prevents a UA from directly contacting the destination UA. While this delivers Class-5/PBX functionality and management, it also prevents direct implementation of certain SIP-based end-to-end features such as REFER and exchange of secured bodies using S/MIME.
About the Author
Amir Zmora is responsible for product management of SIP products in Radvision's Technology Business Unit. Previously, Zmora was the product line manager for the company's H.323 Toolkit, 3G-324M Toolkit, and Gatekeeper Toolkit. He also managed both the R&D and QA for RADVISION's entire H.323 product line. Amir can be reached at amirz@radvision.com. is responsible for product management of SIP products in Radvision's Technology Business Unit. Previously, Zmora was the product line manager for the company's H.323 Toolkit, 3G-324M Toolkit, and Gatekeeper Toolkit. He also managed both the R&D and QA for RADVISION's entire H.323 product line. Amir can be reached at
浙公网安备 33010602011771号