The Need for Signaling and Call Control

Signaling and call control are fundamental to the call establishment, management, and administration of voice communication in an IP network. This section discusses the benefits of using signaling and call control and offers an overview of what signaling and call control services provide.

VoIP Signaling

In the traditional telephony network, a voice call consists of two paths:

An audio path carrying the voice
A signaling path carrying administrative information such as call setup, teardown messages, call status, and call-progress signals.

ISDN D-channel signaling and Common Channel Signaling System 7 (CCSS7) or Signaling System 7 (SS7) are examples of signaling systems that are used in traditional telephony.

By introducing VoIP into the call path, the end-to-end path involves at least one call leg that uses an IP internetwork. As in a traditional voice call, support for this VoIP call leg requires two paths:

A protocol stack that includes RTP, which provides the audio call leg
One or more call control models that provide the signaling path

A VoIP signaling and call control environment model includes endpoints and optional common control components, as described in the following sections.

Endpoints

Endpoints are typically simple, single-user devices, such as terminals, that support either a voice process (for example, the Cisco IP phone application) or a gateway. In either case, the endpoint must be able to participate in signaling with other VoIP endpoints, directly or indirectly, through common control components. The endpoints must also be able to manipulate the audio that is in the audio path. This might involve performing analog-to-digital conversion or converting the format to digital voice so that it takes advantage of compression technology.

Gateways provide physical or logical interfaces to the traditional telephone network. A gateway that is connected digitally to a service provider central office (CO) switch is an example of a gateway providing a physical interface. A gateway providing access to an interactive response dialog application is an example of a gateway providing a logical interface.

Common Control

In some call control models, the common control component is not defined. In others, it is employed optionally. Common control components provide call administration and accounting. These components provide a variety of services to support call establishment, including the following:

Call status
Address registration and resolution
Admission control

Typically, the services of the common control components are implemented as applications. These services are collocated in a single physical device or distributed over several physical devices with stand-alone endpoints and gateways.

Call Control Models

Cisco and other vendors support a variety of call control protocols. While this chapter focuses on H.323, SIP, and MGCP, some of the industry's most popular call control protocols include the following:

H.323 ITU-TRecommendation H.323 describes the architecture to support multimedia communications over networks without quality of service (QoS) guarantees. Originally intended for LANs, H.323 has been adapted for any IP network.
Session initiation protocol (SIP) SIP is an Internet Engineering Task Force (IETF) RFC 3261 call control model for creating, modifying, and terminating multimedia sessions or calls.
Media Gateway Control Protocol (MGCP) MGCP (IETF RFC 2705) defines a call control model that controls VoIP gateways from an external call control element or call agent.
H.248/Megaco Protocol The Megaco protocol is used in environments in which a media gateway consists of distributed subcomponents, and communication is required between the gateway subcomponents. The Megaco protocol is a joint effort of IETF (RFC 3015) and the ITU-T (Recommendati on H.248).
Session Announcement Protocol (SAP) SAP (IETF RFC 2974) describes a multicast mechanism for advertising the session characteristics of a multimedia session, including audio and video.
Real-Time Streaming Protocol (RTSP) RTSP (IETF RFC 2326) describes a model for controlled, on-demand delivery of real-time audio and video.
Cisco Unified CallManager ("Skinny") Cisco Unified CallManager is a proprietary Cisco implementation of a call control environment that provides basic call processing, signaling, and connection services to configured devices, such as IP phones, VoIP gateways, and software applications.

In the traditional telephone network, the individual call legs contributing to an end-to-end call often involve different signaling systems and procedures. The following section describes call control translation.

Call Control Translation

In Figure 6-1, an IP phone is communicating with its SIP proxy server using SIP. However, the IP phone is also attempting to reach an H.323 endpoint. Because the two VoIP protocols are different, a translation is necessary at the SIP proxy server (namely, an H.323 gateway) to allow the two telephony endpoints to establish a connection.

Figure 6-1. Translation Between Signaling and Call Control Protocols

A call between a residential user and an office worker likely involves a signaling system that is unique to the various call legs that exist between the originator and the destination. In this scenario, the sequence of signaling systems includes the following:

Analog signaling (Foreign Exchange Station [FXS] or Foreign Exchange Office [FXO] loop start) to the CO
CCSS7 between the COs
ISDN PRI signaling to the PBX
Proprietary signaling to the desktop telephone

When part of the path is replaced with an IP internetwork, the audio path between the IP endpoints is provided by RTP, and the call control mechanism is based on a call control protocol, such as SIP, H.323, or MGCP.

But what if different call control models represent the endpoints? What if, for example, the originating endpoint uses H.323 and the destination is managed as an SIP endpoint? To complete calls across the IP internetwork, a call control gateway that recognizes the procedures of both call control models is required. Specifically, the translating gateway interprets the call setup procedure on the originating side and translates the request to the setup procedure on the destination side. Ideally, this translation is transparent to the endpoints that are involved and results in a single endpoint-to-endpoint audio relationship.

Call Setup

An audio path of a VoIP call leg is dependent on the creation of RTP sessions. These RTP sessions transport voice unidirectionally, so that bidirectional voice uses two RTP sessions. (In principle, if voice is needed in one direction only, as in the case of a recorded announcement or voice mail, only one RTP session is required.) Figure 6-2 shows RTP sessions being created during call setup.

Figure 6-2. RTP Sessions

To create RTP sessions, each endpoint must recognize the IP address and User Datagram Protocol (UDP) port number of its peer. In a limited implementation of VoIP, these values are preprogrammed. However, to be truly scalable, the addresses and port numbers must be recognized dynamically and on demand.

Note

During call setup, call control procedures exchange the IP address and UDP port numbers for the RTP sessions.

Creating the RTP sessions is not the only task of call control during call setup. The endpoints need to establish a bilateral agreement in which the communicating parties discover acceptable call parameters and then agree on the operating parameters of the call, as depicted in Figure 6-3.

Figure 6-3. Call Feature Negotiation

When agreement is not possible, the call is not completed and is dropped. Following are some examples of call parameters:

Coder-decoder (CODEC) Each endpoint must share a common format for the voice, or at least must recognize the opposite endpoint's choice for voice encoding. This is an example of a mandatory agreement. Not finding a common format is analogous to calling a foreign land and discovering that you are unable to carry on a conversation because the other party speaks a different language.
Receive/transmit Based on the application, the voice is one-way or two-way. Some endpoints do not meet the requirement for the session because they are designed to handle receive-only or transmit-only traffic when the call requests two-way communication.
Multipoint conferences Various types of multipoint conferences (for example, ad-hoc or meet-me) exist. The type of the multipoint conference, along with parameters (for example, the CODEC being used) required to participate in the conference, must be agreed upon.
Media type Potential media types include audio, video, or data.
Bit rate A session's bit rate defines its throughput requirements.

Call Administration and Accounting

Call administration and accounting functions provide optional services for the improved operation, administration, and maintenance of a VoIP environment.

Accounting makes use of the historical information that is usually formatted as call detail records (CDRs). CDRs are useful for cost allocation and for determining call distribution and service grade for capacity planning purposes.

Call administration includes the following capabilities:

Call status Monitoring calls in real time
Address management Supporting users with services such as address resolution
Admission control Ensuring that resources are being used effectively

The following sections describe each of these capabilities in more detail.

Call Status and CDRs

Several of the responsibilities assigned to call administration and accounting are dependent on access to current call status information or records of changes in the call status. Call status has both historical and instantaneous (real-time) benefits. Therefore, CDR functions include billing and capacity planning.

Call status provides an instantaneous view of the calls that are in progress. This view assists other processes (for example, bandwidth management) and can assist an administrator with troubleshooting or help provide user support.

CDRs, whose database is represented in Figure 6-4, include information about a call start time, duration, origin, destination, and other statistics that might be useful for a variety of purposes. This data is collected as a function of call status.

Figure 6-4. Call Status

Address Management

When an endpoint registers with a call control component, it supplies its telephone address or addresses and, if it is a gateway, the addresses of the destinations it can reach. The endpoint provides other information relating to its capabilities. Multiple destinations that are reachable through a gateway are usually represented by a prefix. The use of a prefix allows call control to create a database that associates a telephony address, for example, with its corresponding IP address, as illustrated in Figure 6-5.

Figure 6-5. Address Registration

Note

In the traditional telephony network, the address of a station is limited to the keys available on a dual-tone multifrequency (DTMF) keypad. In VoIP, an address takes on one of several other formats as well. For example, the address can be a host name or a URL.

Figure 6-5 illustrates the Toronto gateway registering its accessibility information. In this example, the gateway informs the common control component that it can reach all telephone numbers in the 416 area. This information is deposited into a database for future reference.

After an address is registered, it can be discovered through address resolution, as depicted in Figure 6-6.

Figure 6-6. Address Resolution

Address resolution translates a multimedia user address to an IP address so that the endpoints can communicate with each other to establish a control relationship and create an audio path.

Admission Control

Admission control has at least two aspects: authorization and bandwidth management. Access to a network should not imply permission to use the resources of the network. Common control limits access to the resources by checking the intentions and credentials of users before authorizing them to proceed.

Also, because bandwidth is a finite resource, appropriate bandwidth management is essential to maintaining voice quality. Allowing too many simultaneous voice calls over an IP internetwork results in a loss of quality for both new and existing voice calls.

To avoid degrading voice quality, a call control model establishes a bandwidth budget. By using data available from call status, the bandwidth management and Call Admission Control (CAC) functions monitor current bandwidth consumption. Calls might proceed up to the budgeted level, but are refused when the budget has reached its limit. This process is illustrated in Figure 6-7.