Connecting a VoIP System to a Service Provider Network

A VoIP system that can place calls only to other devices on the IP network is only marginally useful; we still need to place calls out to the PSTN, and to do so we need to connect to a phone service provider, whether via traditional TDM links or ITSP connections. The device that acts as the interface to the PSTN is the voice gateway; it provides the physical connection and logical translation between two or more different network technologies.

Understanding Gateways, Voice Ports, and Dial Peers

The following sections establish some terms of reference.

Gateways
In the Cisco Unified Communications architecture, a gateway is typically a voice-enabled router with an appropriate voice port installed and configured. Gateways can have both analog and digital voice port connections, including analog FXO, FXS, and E&M or digital T l / E l or PRI interfaces.

Call Legs
A call leg is the inbound or outbound call path as it passes through the gateway. As the call comes into the gateway, it is associated with an inbound port. (This is the inbound call leg.) As the call is sent out another gateway port, this creates the outbound call leg. There will be inbound and outbound call legs at each gateway router.

Dial Peers
A dial peer is a pointer to an endpoint, identified by an address (a pattern of digits). Cisco gateways support two types of dial peers: POTS and VoIP. POTS dial peers are addressed with PSTN phone numbers, and VoIP dial peers are addressed by IP addresses. Dial peers identify the source and destination endpoints of call legs; an inbound call leg is matched to a dial peer, and the outbound call leg is routed to a destination dial peer. Depending on the direction of the call, the dial peers may be POTS inbound and VoIP outbound, vice versa, or possibly both VoIP. It is unlikely but not impossible that the

inbound and outbound dial peers would both be POTS. Each dial peer also defines attributes such as the codec to use, QoS settings, and other feature settings. Dial peers are configured in the gateway IOS, using either the CLI or GUI interface.

The partial output that follows shows a simple POTS dial peer configuration:


The number assigned to dial peers is arbitrary, although dial peer 0 exists by default and cannot be deleted. The keyword pots creates a POTS dial peer; the keyword voip would create a VoIP dial peer. The destination-pattern command identifies that the attached device (phone or PBX) terminates calls to the specified number (or a range of numbers if connecting to a PBX). The port command identifies the physical hardware connection the dial peer will use to reach the destination pattern.

The destination-pattern command associates a phone number with a dial peer. The specified pattern can be a specific phone number (as above, 8675309) or an expression that defines a range of numbers. The router uses the patterns to decide which dial peer (and associated physical port) it should route a call to. The following table briefly explains destination-pattern syntax.


Configuring VoIP dial peers is equally simple. Examine the following configuration:


In this example, the destination pattern is any four-digit number starting with "4." A new command, session-target, is used to identify the IP (version 4 in this case) address of the gateway or call agent that will terminate the call. If the IP address is on a router, it should be a loopback IP so that the address is always available even if a physical interface fails. The preceding configuration creates an H.323 dial peer (in contrast to a SIP dial-peer).


Routers attempt to match dial peers for the inbound call leg according to the following rules:

1. Look for the incoming called-number command in a dial peer that matches the called number or DNIS string of the inbound leg.

2. Look for the answer-address command in a dial peer that matches the calling number or ANI string of the inbound call leg.

3. Look for the destination-pattern command in a dial peer that matches the calling number or ANI string of the inbound call leg.

4. Look for the POTS dial peer port command that matches the voice port of the incoming call (POTS dial peers only).

5. If all of the above fail to match, match against Default Dial Peer 0 as a last resort.

The default dial peer 0 config for inbound POTS calls includes the following:

• no ivr application

When a router is matching the dialed digits against the patterns in the configured dial peers, it attempts to find the longest match. This occurs on a digit-by-digit basis. Each successive digit may validate some patterns while eliminating others until a single pattern represents the longest match between the dialed digits and the destination pattern, at which point the call is routed to the outbound dial peer configured with that matching pattern.

Consider the following configuration:


Given this configuration, the following example dialed numbers illustrate how the patterns match dialed digits:

• The dialed number 867-5309 will match dial peer 40 (exact 7-digit match)

• The dialed number 867-4309 will match dial peer 30 (first four digits match)

• The dialed number 867-3309 will match dial peer 20 (first four digits match)

• The dialed number 876-5309 will match dial peer 10 (no other exact match, so the ".T" pattern matches)

Introducing VoIP Signaling Protocols

VoIP signaling protocols are responsible for call setup, maintenance, and teardown. A number of different protocols are in use—some standards-based, others proprietary, and each with advantages and disadvantages. The following sections introduce the signaling protocols you should know about, including SCCP, H.323, MGCP, and SIP.


VoIP Signaling Protocols

VoIP signaling protocols handle the call setup, maintenance, and teardown functions of VoIP calls. It is important to keep in mind that the signaling functions are an entirely separate packet stream from the actual voice bearer path (RTP). The signaling protocol in use must pass the supervisory, informational, and address information expected in any telephony system.

VoIP signaling protocols are either peer-to-peer or client-server; in the case of peer-to-peer protocols, the endpoints have the intelligence to perform the call-control signaling themselves, Client-server protocols send event notifications to the call agent (the Unified CM server) and receive instructions on what actions to perform in response. The following table summarizes the characteristics of the four signaling protocols dealt with here.


H.323
H.323 is not itself a protocol; it is an umbrella standard that defines several other related protocols for specific tasks. Originally conceived as a multimedia signaling protocol to emulate traditional telephony functionality in IP LAN environments, it is a long-established and stable protocol very suitable for intervendor compatibility. H.323 is supported by all Cisco voice gateways and CM platforms as well as some third-party video endpoints.


MGCP

Media Gateway Control Protocol is a lightweight client/server protocol for PSTN gateways and some clients. It is simple to configure and allows the call agent to control the MGCP gateway, eliminating the need for expensive gateways with intelligence and complex configurations. The gateway reports events such as a trunk going off-hook, and the call agent instructs the gateway on what to do; the gateway has no local dial plan because all call routing decisions are made at the call agent and relayed to the MGCP gateway. MGCP is not as widely implemented as SIP or H.323. MGCP is not supported by Unified CM Express or the Smart Business Communication System.


SIP

Session Initiation Protocol is an IETF standard that uses peer-to-peer signaling. It is very similar in structure and syntax to HTTP, and because it is text-based, it is relatively simple to debug and troubleshoot. SIP can use multiple transport layer protocols and can support security and proxy functions. SIP is an evolving standard that currently provides basic telephony functionality; further developments and extensions to the standard will soon make it feature-comparable with SCCP. One of its most important capabilities is creating SIP trunks to IP Telephony service providers, replacing or enhancing traditional TDM PSTN connections.


SCCP

Skinny Client Control Protocol is a Cisco-proprietary signaling protocol used in a client-server manner between Unified CM and Cisco IP Phones (and some Cisco gateways). SCCP uses TCP connections to the Unified CM to set up, maintain, and tear down voice and video calls. It is referred to as a stimulus protocol, meaning that it sends messages in response to events such as a phone going off-hook or a digit being dialed. SCCP is the default signaling protocol for all Cisco IP phones, although many also support SIP; SIP does not yet support the full feature set available to SCCP phones. All Cisco Unified Communications call agents (CM, CM Express, and the 500 Series) and some gateways support SCCP.