Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

Signaling and Transport Protocols

Now that you have a good understanding of the evolution of integrated voice and data networks, this section briefly discusses the concepts of different signaling and transport protocols used in IPT solutions.

Today, organizations use a PBX system or a key system as customer premises equipment (CPE) to provide voice services. Key systems are less expensive than PBX systems, but they typically support fewer users and do not have the rich functionality and feature sets available in PBX systems. If there are large numbers of users on the PBX system, it is not possible to forklift the PBX systems and replace them with IP-based call-processing servers. In these scenarios, the IPT solution should provide the integration with the existing PBX or key systems. Knowing the type of interfaces and signaling protocols supported on the PBX or key systems allows you to choose the right hardware and software components on the IPT solution so that the PBX or key systems can coexist with the IPT solution until migration to IPT is completed.

Telco Signaling Protocols

Conceptually, the signaling protocols that are used in the telco networks can be divided into three categories:

Subscriber-to-network signaling Used by end users to request the network to set up a call. The telephone companies (telcos) treat these interfaces as subscriber interfaces.

Intranetwork signaling Used between switches in the telco network to set up and tear down calls between telco switches.

Network-to-network signaling Used between two networks to set up and disconnect calls and to exchange billing and other related information. The types of network-to-network signaling are not new signaling types but rather are variants of the intranetwork signaling types.

Signaling is further divided into two types: analog and digital.

Analog Signaling

By definition, analog signals are sent over wires or through air and carry information through some combination of frequency, phase, and amplitude. You can find trunks that use analog signaling in small offices or in offices where the telco switch does not support digital signaling. Analog signaling types usually fall under the subscriber-to-network signaling category. The three common analog trunk types are loop start, ground start, and ear and mouth (E&M).

Loop-start and ground-start trunks use the same wire pair for both audio and signaling. Most of the telephone connections to households around the world use loop-start signaling. E&M uses separate wire pairs for audio and signaling. You can find E&M signaling trunks in older PBX/central office switches.

The telephone system usually uses dual-tone multifrequency (DTMF) or dial pulse/digit transmission methods to transmit the digits that the subscriber dials. DTMF, which is the most popular method, uses two simultaneous voice-band tones for dialing, such as touch-tones. Dial pulse, which is an older method, uses a series of make and brake pulses to represent digits. In pulse dialing, an off-hook state is represented by a make state of the pulse, and an on-hook state is represented by a break state of the pulse.

Digital Signaling

Analog trunks require a physical set of wires per trunk and thus might not be the best method when provisioning a large number of trunks. Hence, higher-density digital trunks are used in larger organizations that have higher call volumes. There are two varieties of digital signaling trunk types: T1 and E1 circuits. When a network supports voice on T1 and E1 circuits (also used for data transmission), two types of signaling mechanisms are used:

Channel-associated signaling (CAS)

Common channel signaling (CCS)

CAS falls into the subscriber-to-network and CCS into intranetwork signaling.

CAS

In CAS, signaling information is carried in-band. This means that actual voice conversation travels along with the signaling information on the same circuit. One example of a CAS signaling system is Robbed Bit Signaling (RBS). RBS gets its name from the nature of its operation, in which some of the bits from the payload in each time-division multiplexing (TDM) slot are robbed and reused for signaling.

In the E1 facility, the signaling bits are arranged in time slot 16. CAS on the E1 facility also uses R1 (MF) and R2 (MF Compelled) types of signaling methods.

CCS

CCS separates signaling information from user data. Two examples of protocols in which you can find CCS signaling are ISDN and Q.SIG.

ISDN permits telephone networks to carry data, voice, and other types of traffic. ISDN has two types of variants:

Basic Rate Interface (BRI) Composed of two B (bearer) channels (used to carry data and voice traffic) and one D (data) channel (used for signaling), referred to as 2B+D. Each B channel provides 64 kbps, and the D channel provides 16 kbps for signaling. Two B channels combined can provide 128 kbps of bandwidth. Although the signaling is in a separate channel, it travels along with data.

Primary Rate Interface (PRI) Composed of 23 B channels and one D channel (23B+D) when using a T1 facility, and 30 B channels and a single 64-kbps D channel (30B+D) when using an E1 facility. Each B channel is 64 kbps.

The other example signaling standard that uses CCS, Q.SIG, has many variations in its feature implementations. Q.SIG is used in many PBX systems and in PBX internetworking.

VoIP Protocols

This section provides a brief overview of the operation of VoIP protocols and explains how these protocols play a role in IPT networks.

Two types of VoIP protocols exist:

Protocols that provide the call control and signaling

Protocols that carry voice payload (RTP, RTCP, UDP, and IP)

The job of the call-control and signaling protocols is to set up and tear down the connection between two or more endpoints in a VoIP network. The following is a list of the call-control and signaling protocols commonly found in IPT networks:

H.323(peer-to-peer model)

Session Initiation Protocol (SIP)(peer-to-peer model)

Media Gateway Control Protocol (MGCP)(client/server model)

Skinny Client Control Protocol (SCCP)(a lighter-weight Cisco proprietary protocol that uses the client/server model)

After the call setup process is complete, the source and destination endpoints can transmit and receive data by using the RTP/RTCP/IP/UDP protocol stack. A typical VoIP network uses any one or a combination of these protocols, depending on the endpoints involved. These protocols are needed at different points in an IPT network. As mentioned before, the gateway is an interface between the IP telephony network and the PSTN or a PBX. On one side, the gateway supports the signaling protocols needed to interface with the PSTN or a PBX. On the other side, the gateway supports the signaling and control protocols needed to interface with the IPT network via the CallManager. The CallManager also acts as a protocol translator. On one hand, the CallManager could be communicating with an IP phone using SCCP, and on the other hand, it could be communicating to the gateway using MGCP, H.323.

The following sections discuss briefly some basic functionality of the call control and signaling protocols that carry voice payload.

H.323

H.323 is an International Telecommunication Union (ITU) specification to carry real-time voice traffic such as telephone calls, video, and data over an IP network. The H.323 protocol specification describes how a session between two H.323 endpoints is created and maintained. The following are the main components of H.323:

H.225 Scaled-down version of Q.931 to set up an IP connection between two H.323 endpoints.

H.245 Allows H.323 endpoints to negotiate their capabilities (such as codecs available) with each other.

RAS H.323 endpoints use this protocol to communicate with H.323 gatekeepers to Manage Registration/Administration/Status.

The preceding three components use TCP for transport. The H.323 standard has gone through many revisions. The current standard is H.323 Version 4. Cisco CallManager 4.0 is compliant with H.323 Version 2 standards.

The "Call-Flow Scenarios" section later in this chapter discusses the call flow sequence between the IP phone and a voice gateway using the H.323 protocol.

SIP

SIP is an RFC standard (RFC 3261) from the Internet Engineering Task Force (IETF), the body responsible for administering and developing the mechanisms that comprise the Internet. SIP is one of the most talked about protocols these days because of its wide interoperability with other products.

SIP is a peer-to-peer protocol. The peers in a session are called user agents (UAs). A user agent can function in one of the following roles:

User agent client (UAC) A client application that initiates the SIP request

User agent server (UAS) A server application that contacts the user when a SIP request is received and returns a response on behalf of the user

Typically, a SIP endpoint is capable of functioning as both a UAC and a UAS, but it functions only as one or the other per transaction. Whether the endpoint functions as a UAC or a UAS depends on the UA that initiated the request. From an architectural standpoint, the physical components of a SIP network can be grouped into two categories: clients (endpoints) and servers. Figure 1-6 shows the SIP architecture.

In Figure 1-6, the SIP clients are phones such as Cisco SIP phones (7960, 7940, and ATA-18x can be configured as SIP phones by loading SIP firmware) and SoftPhones that are loaded on the user's PC/laptop. The routing entities within the SIP architecture are called SIP servers. The following are the three types of SIP servers:

SIP proxy server An intermediate device that receives SIP requests from a client and then forwards the requests on the client's behalf. Basically, proxy servers receive SIP messages and forward them to the next SIP server in the network. Proxy servers can provide functions such as authentication, authorization, network access control, routing, reliable request retransmission, and security. The role of a SIP proxy server is similar to that of a gatekeeper in an H.323 network.

Redirect server Provides the client with information about the next hop or hops that a message should take, after which the client contacts the next hop server or UAS directly.

Registrar server Processes requests from UACs for registration of their current location. Registrar servers are often co-located with a redirect or proxy server.

SIP uses six main messages for its basic functionality:

Register message Sent by the UAs to tell the network where they can be located. The location could be one or more addresses.

Invite message Sent by a UA to initiate a session.

ACK message Used to acknowledge that a successful session has been initiated.

Bye message Used to terminate a session that is already in progress and established.

Cancel message Used to terminate a session that is not yet established (for example, phone is still ringing).

Options message Used for an out-of-band mechanism to determine the capabilities of another UA.

Users in the SIP network are identified by a unique SIP address such as an e-mail ID. Figure 1-7 shows the basic call setup diagram of a successful call when a SIP proxy server is present in the network.

Figure 1-7 shows the following sequence of events:

The calling party sends an Invite message to the called party.

The SIP proxy server responds to the calling party with the informational response "100 Trying."

At the same time, the SIP proxy server sends an Invite message to the called party on behalf of the calling party.

The called party responds with two informational responses: "100 Trying" and then "180 Ringing."

The SIP proxy server passes the informational response "180 Ringing" to the calling party.

The called party responds with the response "200 OK" if the call is successful.

The SIP proxy server passes the success response "200 OK" to the calling party.

The calling party sends an ACK message.

The SIP proxy server passes the ACK message to the called party.

After SIP successfully completes the signaling, a media path between the two endpoints is established.

Starting with CallManager 4.0, CallManager can communicate with SIP endpoints (SIP IP phones, SIP gateways) via SIP Proxy server. This feature, referred to as "SIP Trunk" and shown in Figure 1-8, allows any CallManager-controlled device to communicate with a SIP network. Future releases of CallManager might include the direct support of SIP so that CallManager can talk to the SIP endpoints directly without the need for a SIP proxy server.

MGCP

As previously discussed, H.323 and SIP are based on the peer-to-peer model, whereas MGCP is based on a client/server model. As defined in RFC 2705, "MGCP is designed as an internal protocol within a distributed system that appears to the outside as a single VoIP gateway."

MGCP uses the Session Description Protocol (SDP, RFC 2327) to describe and negotiate media capabilities, which is also used in SIP. SDP functionality is similar to H.245 capability in H.323.

There are two main components of MGCP:

Media gateway (MG) Bridges networks that use different media types, such as circuit-switched, analog, and IP networks. An MG is also referred to as an endpoint (EP). An MG is an interface between a telephony network or a PBX and a VoIP network. Examples of Cisco media gateway products include 26xx/36xx/37xx series routers, Catalyst gateways such as WS-X-6608-T1/E1, and WS-6624-FXS gateways.

Media gateway controller (MGC) Controls the parts of the call state that relate to connection control for media channels in one or more media gateways. An MGC is also referred to as a call agent (CA) or as the industry term Softswitch. In the IPT networks, CallManager acts as a CA that provides call-processing functions and feature logic and controls the MG.

MGCP messages are sent over UDP/IP between the CA and MG. The client/server relationship is maintained between the CA and MG. Voice traffic (bearer channels) is carried over RTP/UDP/IP or other transmission media (e.g., ATM). MGCP is independent of transport media and can be used to control ATM or circuit-switched gateways.

Similar to H.323, MGCP has undergone several revisions. As of CallManager 4.0, support for MGCP 0.1 is included. The current revision of MGCP is 1.0.

MGCP uses very simple commands in the negotiation process between the MG and CA and uses UDP as a transport layer protocol. The default port is UDP 2427, although it is configurable in the CallManager. Examples of the commands are CRCX (CreateConnection), MDCX (ModifyConnection), etc., and every command requires an acknowledgement. The following list describes commonly used MGCP commands, and Figure 1-8 shows the usage of these commands:

CRCX The CA can use the CreateConnection command to create a connection that terminates in an endpoint inside the MG.

MDCX The CA can use the ModifyConnection command to change the parameters associated with a previously established connection.

DLCX The MG can also use the DeleteConnection command to delete an existing connection. The MG can also use the DeleteConnection command. This command indicates that a connection can no longer be sustained.

RQNT The CA can issue a NotificationRequest command to a gateway to instruct the gateway to watch for specific events such as hook actions or DTMF tones on a specified endpoint.

NTFY The MG can use the Notify command to inform the CA when the requested events occur.

AUEP and AUCX The CA can use the AuditEndpoint and AuditConnection commands to audit the status of an endpoint and any connections associated with it.

RSIP The MG can use the RestartInProgress command to notify the CA that the MG, or a group of endpoints managed by the MG, is being taken out of service or is being placed back in service.

Call-Flow Scenarios" section later in this chapter discusses the call-flow sequence between the IP phone and a voice gateway using the MGCP protocol.

SCCP

SCCP is a "lightweight" Cisco proprietary protocol that is based on a client/server model. In this model, all the intelligence is built into the server, which is a CallManager in the Cisco IPT solution. The client, which is a Cisco IP Phone, has minimal intelligence. In other words, the Cisco IP Phones have to do less work, thus requiring less memory and processing power. The CallManager, being the intelligent server, learns client capabilities, controls call establishment, clears calls, sends notify signals (i.e. message waiting indication (MWI), reacts to signals from the client (after the user presses the directory button on the phone), and so forth. CallManager communicates with the IP phones using SCCP and, if the call has to go through a gateway, communicates with the gateway using H.323 or MGCP.

RTP/RTCP

By now you should have a good operational understanding of signaling protocols such as H.323, SIP, MGCP, and SCCP. These protocols provide call-signaling and control functionality and are responsible for setting up and tearing down the connection between the endpoints. After the connection is set up between the two endpoints, the source and destination endpoints can transmit and receive data by using RTP/RTCP. As discussed in the "Next-Generation Multiservice Networks" section earlier in this chapter, RTP/RTCP uses UDP for transport.

Figure 1-9 shows the IP packet header information that transports the RTP/RTCP packets. As you can see, the IPv4 header is 20 bytes, the UDP header is 8 bytes, and the RTP header is 12 bytes, which means that a total of 40 bytes of header information is required to transport the single RTP packet. After this 40 bytes of IP header information, two 10-byte frames (10 bytes per frame for G.729 codec voice samples) of real voice payload are carried, for a total of 20 bytes of voice payload. (The Cisco implementation puts two frames into one packet.) A simple math calculation shows that the header has twice the number of bytes that are in the real payload. To address this particular issue, you can use RTP header compression technique on point-to-point links. You must apply the RTP header compression on a link-by-link basis. When enabled on a gateway, you can use the RTP header compression technique compresses the 40-byte header into 2 or 4 bytes. However, enabling compression increases the load of the CPU on the router. You need to make a decision based on the number of calls that you need to send out through that gateway.