| H.323 and its associated ITU-T recommendations represent a distributed environment for establishing voice, video, and data communication in a network without a quality of service (QoS) guarantee, which is typical of an IP internetwork. In addition to describing how to configure H.323, this section discusses the features and functions of the H.323 environment, including its components and how they interact. Scalability and survivability issues are also discussed. H.323 and IP Recommendation H.323 describes an infrastructure of terminals, common control components, services, and protocols that are used for multimedia (voice, video, and data) communications. Figure 6-8 illustrates the elements of an H.323 terminal and highlights the protocol infrastructure of an H.323 endpoint. Figure 6-8. H.323 and Associated Recommendations 
H.323 was originally created to provide a mechanism for transporting multimedia applications over LANs. Although numerous vendors still use H.323 for videoconferencing applications, H.323 rapidly evolved to address the growing needs of VoIP networks. H.323 is currently the most widely used VoIP signaling and call control protocol, with international and domestic carriers relying on it to handle billions of minutes of use each year. Considered an umbrella protocol because it defines all aspects of call transmission, from call establishment to capabilities exchange to network resource availability, H.323 defines the following protocols: H.245 for capabilities exchange H.225.0 for call setup H.225.0 for Registration, Admission, and Status (RAS) control for call routing
H.323 is based on the ISDN Q.931 protocol, which allows H.323 to interoperate easily with legacy voice networks, such as the public switched telephone network (PSTN) or SS7. In addition to providing support for call setup, H.225.0 provides a message transport mechanism for the H.245 control function and the RAS signaling function. These functions are described as follows: Call-signaling function The call-signaling function uses a call-signaling channel that allows an endpoint to create connections with other endpoints. The call-signaling function defines call setup procedures based on the call setup procedures for ISDN (Recommendation Q.931). The call-signaling function uses messages formatted according to H.225.0. H.245 control function The H.245 control function uses a control channel to transport control messages between endpoints or between an endpoint and a common control component, such as a gatekeeper or a multipoint controller (MC). The control channel used by the H.245 control function is separate from the call-signaling channel. The H.245 control function is responsible for the following: - - Logical channel signaling Opens and closes the channel that carries the media stream
- - Capabilities exchange Negotiates audio, video, and coder-decoder (CODEC) capability between the endpoints
- - Master or responder determination Determines which endpoint is master and which is responder; used to resolve conflicts during the call
- - Mode request Requests a change in mode, or capability, of the media stream
- - Timer and counter values Establishes values for timers and counters and agreement of those values by the endpoints
RAS signaling function The RAS signaling function uses a separate signaling channel (that is, the RAS channel) to perform registration, admissions, bandwidth changes, status, and disengage procedures between endpoints and a gatekeeper (GK). It uses messages formatted according to H.225.0.
In Figure 6-9, notice that the real-time aspects of H.323 rely on the User Datagram Protocol (UDP). However, both the session-oriented control procedures and the data media type of H.323 use TCP. Figure 6-9. H.323 Adapted to IP 
Functional Components of H.323 In addition to a suite of protocols, the H.323 standard also specifies numerous functional components, as illustrated in Figure 6-10. An H.323 terminal is an endpoint that provides real-time voice (and optionally, video and data) communications with another endpoint, such as an H.323 terminal, gateway (GW), or multipoint control unit (MCU). Figure 6-10. H.323 Functional Components 
An H.323 terminal must be capable of transmitting and receiving G.711 (α-Law and μ-Law), which uses 64 kbps pulse code modulation (PCM)encoded voice, and might support other encoded voice formats, such as G.729 and G.723.1. H.323 Gateways An H.323 gateway is an optional type of endpoint that provides interoperability between H.323 endpoints and endpoints located on a switched-circuit network (SCN), such as the PSTN or an enterprise voice network, as depicted in Figure 6-11. Ideally, the gateway is transparent to both the H.323 endpoint and the SCN-based endpoint. Figure 6-11. H.323 Gateway 
An H.323 gateway performs the following services: Translation between audio, video, and data formats Conversion between call setup signals and procedures Conversion between communication control signals and procedures
IP-to-IP Gateways An IP-to-IP gateway facilitates easy and cost-effective connectivity between independent VoIP service provider networks. Some in the industry call IP-to-IP gateways border elements or session border controllers. The IP-to-IP gateway provides a network-to-network interface point for billing, security, Cisco Unified CallManager interconnectivity, call admission control, and signaling interworking. It performs most of the same functions of a PSTN-to-IP gateway, but joins two VoIP call legs. Media packets can either flow through the gateway and hide the networks from each other or flow around the IP-to-IP gateway if network security is not of primary importance. Figure 6-12 illustrates a basic IP-to-IP gateway network. From the perspective of the private, or customer, networks, the IP-to-IP gateway appears as a single public address that must be routable on their private networks (in this case, a 12.x.x.x address routable on the 10.10.x.x and 192.168.x.x networks). Care must be taken at the IP-to-IP gateway to ensure that proper routing restrictions are in place to prevent communication directly between the private networks attached to it. Also note that this model works only if no overlapping address schemes are used on the customers' networks. Finally, to the hop-off gateways on the public network, all calls appear to originate from the 12.x.x.x address of the IP-to-IP gateway and not the private addresses on the customer networks. Also note that the gatekeepers shown in the diagram control each zone independently, with the 12.10.10.11 gatekeeper acting as the control point for the public network, and therefore the IP-to-IP gateway. Figure 6-12. IP-to-IP Gateway 
H.323 Gatekeepers An H.323 gatekeeper is an optional component that provides call control support and services to H.323 endpoints, as shown in Figure 6-13. Although a gatekeeper is considered a distinct and optional component, it can be collocated with any other H.323 component. Figure 6-13. H.323 Gatekeeper 
The scope of endpoints over which a gatekeeper exercises its authority is called a zone. H.323 defines a one-to-one relationship between a zone and a gatekeeper. When a gatekeeper is included, the gatekeeper must perform the following functions: Address translation Converts an alias address to an IP address Admission control Limits access to network resources based on call bandwidth restrictions Bandwidth control Responds to bandwidth requests and modifications Zone management Provides services to registered endpoints
A gatekeeper might also perform: Call control signaling Performs call signaling on behalf of the endpoint (that is, gatekeeper-routed call signaling) Call authorization Rejects calls based on authorization failure Bandwidth management Limits the number of concurrent accesses to IP internetwork resources (that is, CAC) Call management Maintains a record of ongoing calls
Multipoint Conferences Support for multipoint conferences is provided by the following three functional components, as diagramed in Figure 6-14: Multipoint controller (MC) An MC provides the functions that are necessary to support conferences involving three or more endpoints. The MC establishes an H.245 control channel with each of the conference participants. Through the control channel, the MC completes a capability exchange during which the MC indicates the mode of the conference (decentralized or centralized). An MC is not modeled as a stand-alone component. However, it might be located with an endpoint (for example, a terminal or a gateway), a gatekeeper, or a multipoint control unit. Multipoint processor (MP) An MP adds functionality to multipoint conferences. An MP can receive multiple streams of multimedia input, process the streams by switching and mixing the streams, and then retransmit the result to all or some of the conference members. Similar to an MC, an MP is not modeled as a stand-alone component. Rather, an MP resides in an MCU. Multipoint control unit (MCU) An MCU is modeled as an endpoint that provides support for multipoint conferences by incorporating one MC and zero or more MPs. An MCU is modeled as a stand-alone component.
Figure 6-14. Multipoint Conference Components 
H.323 Call Establishment and Maintenance Although H.323 is based on the concepts of a distributed call control model, it often embodies centralized call control model concepts. Calls can be established between any of the following components: Endpoint to endpoint The intelligence of H.323 endpoints allows them to operate autonomously. In this mode of operation, endpoints locate other endpoints through nonstandard mechanisms and initiate direct communication between the endpoints. Endpoint to gatekeeper When a gatekeeper is added to the network, endpoints interoperate with the gatekeeper using the RAS channel. Gatekeeper to gatekeeper In the presence of multiple gatekeepers, gatekeepers communicate with each other on the RAS channel.
RAS Messages H.323 gatekeepers communicate with other H.323 devices (including other H.323 gatekeepers) through a series of RAS messages, as shown in Figure 6-15. Figure 6-15. RAS Messages 
Each of these RAS messages fall under one of the following categories: Gatekeeper discovery An endpoint multicasts a gatekeeper discovery request (GRQ). A gatekeeper might confirm (gatekeeper confirmation [GCF]) or reject (gatekeeper rejection [GRJ]) an endpoint. Terminal/gateway registration An endpoint sends a registration request (RRQ) to its gatekeeper to register and provide reachable prefixes. A gatekeeper confirms (registration confirmation [RCF]) or rejects (registration rejection [RRJ]) the registration. Terminal/gateway unregistration An endpoint or gatekeeper sends an unregistration request (URQ) to cancel a registration. The responding device confirms (unregistration confirmation [UCF]) or rejects (unregistration rejection [URJ]) the request. Bandwidth change An endpoint sends a bandwidth change request (BRQ) to its gatekeeper to request an adjustment in call bandwidth. A gatekeeper confirms (bandwidth confirmation [BCF]) or rejects (bandwidth rejection [BRJ]) the request. Location request An endpoint or gatekeeper sends a location request (LRQ) to a gatekeeper. An LRQ is sent directly to a gatekeeper if one is known, or it is multicast to the gatekeeper discovery multicast address. An LRQ requests address translation of an E.164 address and solicits information about the responsible endpoint. The responding gatekeeper confirms (location confirmation [LCF]) with the IP address of the endpoint or rejects the request (location rejection [LRJ]) if the address is unknown. Call admission An endpoint sends an admission request (ARQ) to its gatekeeper. The request identifies the terminating endpoint and the bandwidth required. The gatekeeper confirms (admission confirmation [ACF]) with the IP address of the terminating endpoint or rejects (admission rejection [ARJ]) if the endpoint is unknown or inadequate bandwidth is available. Disengage When a call is disconnected, the endpoint sends a disengage request (DRQ) to the gatekeeper. The gatekeeper confirms (disengage confirmation [DCF]) or rejects (disengage rejection [DRJ]) the request. Status queries A gatekeeper uses an information request (IRQ) to determine the status of an endpoint. In its response (IRR), the endpoint indicates whether it is online or offline. The endpoint might also reply that it understands the information request (information request acknowledged [IACK]) or that it does not understand the request (information request not acknowledged [INAK]).
Call Flows While H.323-based networks scale better when a gatekeeper is used, a gatekeeper is not a required component in an H.323 network. H.323 networks containing a gatekeeper can scale even larger with multiple gatekeepers. This section discusses how H.323 calls are set up without a gatekeeper, with a single gatekeeper, and with more than one gatekeeper. Figure 6-16 shows an H.323 basic call setup exchange between two gateways. The optional gatekeeper is not present in this example. Although gateways are shown, the same procedure is used when one or both endpoints are H.323 terminals. Figure 6-16. H.323 Basic Call Setup 
The call flow without a gatekeeper includes these steps: 1. | The originating gateway initiates an H.225.0 session with the destination gateway on TCP port 1720. The gateway determines the IP address of the destination gateway internally. The gateway has the IP address of the destination endpoint in its configuration, or it knows a Domain Name System (DNS) resolvable domain name for the destination.
| 2. | Call setup procedures based on Q.931 create a call-signaling channel between the endpoints.
| 3. | The endpoints open another channel for the H.245 control function. The H.245 control function negotiates capabilities and exchanges logical channel descriptions.
| 4. | The logical channel descriptions open RTP sessions.
| 5. | The endpoints exchange multimedia over the RTP sessions, including exchanging call quality statistics using RTP Control Protocol (RTCP).
|
The basic setup procedure for an H.323 call requires multiple exchanges between the source and destination gateways. However, the Fast Connect procedure reduces the number of round-trip exchanges and achieves the capability exchange and logical channel assignments in one round trip, as illustrated in Figure 6-17. Figure 6-17. H.323 Fast Connect 
The Fast Connect procedure includes these steps: 1. | The originating gateway initiates an H.225.0 session with the destination gateway on TCP port 1720.
| 2. | Call setup procedures based on Q.931 create a combined call-signaling channel and control channel for H.245. Capabilities and logical channel descriptions are exchanged within the Q.931 call setup procedure.
| 3. | Logical channel descriptions open RTP sessions.
| 4. | The endpoints exchange multimedia over the RTP sessions.
|
Note Cisco H.323 voice equipment supports up to version 4 of H.323 and is backward compatible to earlier versions.
Call Flows with a Gatekeeper Figure 6-18 shows how an endpoint locates and registers with a gatekeeper. A gatekeeper adds scalability to H.323. Without a gatekeeper, an endpoint must recognize or have the ability to resolve the IP address of the destination endpoint. Figure 6-18. Finding and Registering with a Gatekeeper 
Before an endpoint can use a gatekeeper, it must register with the gatekeeper. To register, an endpoint must recognize the IP address of the gatekeeper. One of these two methods are used to determine the address of the gatekeeper: An endpoint can be preconfigured to recognize the domain name or IP address of its gatekeeper. If configured to recognize the name, an endpoint must have a means to resolve the name to an IP address. A common address resolution technique is the DNS. An endpoint can issue a multicast GRQ to the gatekeeper discovery address (224.0.1.41) to discover the IP address of its gatekeeper. If the endpoint receives a GCF to the request, it uses the IP address to proceed with registration.
To initiate registration, an endpoint sends an RRQ to the gatekeeper. In the register request, the endpoint identifies itself with its ID and provides its IP address. Optionally, the endpoint lists the prefixes (for example, telephone numbers) that it supports. These prefixes are gleaned from the plain old telephone service (POTS) dial peer destination patterns associated with any FXS port. To illustrate the steps involved in a call setup using an H.323 gatekeeper, consider the example depicted in Figure 6-19. In this example, both endpoints have registered with the same gatekeeper. Figure 6-19. Call Flow with an H.323 Gatekeeper 
Call flow with a gatekeeper proceeds as follows: 1. | The gateway sends an ARQ to the gatekeeper to initiate the procedure. The gateway is configured with the domain name or address of the gatekeeper.
| 2. | The gatekeeper responds to the admission request with an ACF. In the confirmation, the gatekeeper provides the IP address of the remote endpoint.
| 3. | When the originating endpoint identifies the terminating endpoint, it initiates a basic call setup.
| 4. | Before the terminating endpoint accepts the incoming call, it sends an ARQ to the gatekeeper to gain permission.
| 5. | The gatekeeper responds affirmatively, and the terminating endpoint proceeds with the call setup procedure.
|
During this procedure, if the gatekeeper responds to either endpoint with an ARJ to the admission request, the endpoint that receives the rejection terminates the procedure. In the previous examples, the call-signaling channel is created from endpoint to endpoint. However, in some cases, it is desirable to have the gatekeeper represent the other endpoint for signaling purposes. This method is called gatekeeper-routed call signaling, which is shown in Figure 6-20. Figure 6-20. Gatekeeper-Routed Call Signaling 
The process for gatekeeper-routed call signaling is as follows: 1. | The gatekeeper responds to an admission request and advises the endpoint to perform the call setup procedure with the gatekeeper, not with the terminating endpoint.
| 2. | The endpoint initiates the setup request with the gatekeeper.
| 3. | The gatekeeper sends its own request to the terminating endpoint and incorporates some of the details acquired from the originating request.
| 4. | When a connect message is received from the terminating endpoint, the gatekeeper sends a connect message to the originating endpoint.
| 5. | The two endpoints establish an H.245 control channel between them. The call procedure continues normally from this point.
|
Call Flows with Multiple Gatekeepers By simplifying configuration of the endpoints, gatekeepers aid in building large-scale VoIP networks. As the VoIP network grows, incorporating additional gatekeepers enhances the network scalability, as shown in Figure 6-21. Figure 6-21. Scalability with Multiple H.323 Gatekeepers 
Without a gatekeeper, endpoints must find each other by any means available. This limits the growth potential of the VoIP network. Through the registration and address resolution services of a gatekeeper, growth potential improves significantly. A single gatekeeper design might not be appropriate for several reasons. A single gatekeeper can become overloaded, or it can have an inconvenient network location, necessitating a long and expensive round trip to and from the gatekeeper. Deploying multiple gatekeepers offers a more scalable and robust environment. In Figure 6-22, each endpoint is registered with a different gatekeeper. Figure 6-22. Call Flows with Multiple H.323 Gatekeepers 
Notice the changes in the following call setup procedure: 1. | The originating endpoint sends an admission request to its gatekeeper requesting permission to proceed and asks for the session parameters for the terminating endpoint.
| 2. | The gatekeeper for the originating endpoint (Gatekeeper 1) determines from its configuration or from a directory resource that the terminating endpoint is potentially associated with Gatekeeper 2. Gatekeeper 1 sends an LRQ to Gatekeeper 2.
| 3. | Gatekeeper 2 recognizes the address and sends back an LCF. In the confirmation, Gatekeeper 2 provides the IP address of the terminating endpoint.
| 4. | If Gatekeeper 1 considers the call acceptable in terms of security and bandwidth, it maps the LCF to an ARQ and sends the confirmation back to the originating endpoint.
| 5. | The endpoint initiates a call setup to the remote endpoint.
| 6. | Before accepting the incoming call, the remote endpoint sends an ARQ to Gatekeeper 2 requesting permission to accept the incoming call.
| 7. | Gatekeeper 2 performs admission control on the request and responds with a confirmation.
| | | 8. | The endpoint responds to the call setup request.
| 9. | The call setup progresses through the H.225.0 call function and H.245 control function procedures until the RTP sessions are initiated.
| 10. | At the conclusion of the call, each endpoint sends a disconnect request to its gatekeeper to advise its gatekeeper that the call is complete.
| 11. | Each gatekeeper responds with a confirmation.
|
Types of Multipoint Conferences All types of multipoint conferences rely on a single MC to coordinate the membership of a conference. Each endpoint has an H.245 control channel connection to the MC. Either the MC or the endpoint initiates the control channel setup. H.323 defines the following three types of conferences, as shown in Figure 6-23: Centralized multipoint conference The endpoints must have their audio, video, or data channels connected to an MP. The MP performs mixing and switching of the audio, video, and data, and if the MP supports the capability, each endpoint can operate in a different mode. Decentralized multipoint conference The endpoints do not have a connection to an MP. Instead, endpoints multicast their audio, video, and data streams to all participants in the conference. Because an MP is not available for switching and mixing, any mixing of the conference streams is a function of the endpoint, and all endpoints must use the same communication parameters. To accommodate situations in which two streams (audio and video) would be handled by the different multipoint conference models, H.323 defines a hybrid. A hybrid describes a situation in which the audio and video streams are managed by a single H.245 control channel with the MC, but where one stream relies on multicast (according to the distributed model) and the other uses the MP (as in the centralized model). Ad-hoc multipoint conference Any two endpoints in a call can convert their relationship into a point-to-point conference. If neither of the endpoints has a collocated MC, then the services of a gatekeeper are used. When the point-to-point conference is created, other endpoints become part of the conference by accepting an invitation from a current participant, or the endpoint can request to join the conference.
Figure 6-23. Multipoint Conferences 
Deploying and Configuring H.323 Gateways and gatekeepers each provide specific features and functionality to the VoIP network. This section discusses the configuration of each device type to enable the use of these features and to enable the appropriate communication between device types. Reliability is critical for success in a voice network. This section also discusses strategies that are used to provide fault tolerance in the voice network. Finally, this section discusses the steps necessary to monitor and troubleshoot the VoIP network as required. Survivability Strategies In any environment that depends on common control components, the vulnerability of the environment is directly proportional to the probability of common control component failure. In a classical telephony application, fault tolerance is accommodated by incorporating extra common control technology. One strategy replicates all critical components. This expensive approach is often replaced with the more cost-effective solution of "n out of n + 1" redundancy. Specifically, a single spare component is available to step in when any one of the active n components fails. The essential part of either strategy is the replication of key components. The key components of an H.323 network include the gateways and the gatekeeper. H.323 can employ any of the following survivability strategies: Hot Standby Router Protocol (HSRP) HSRP allows two gatekeepers to share both an IP address and access to a common LAN. However, at any time, only one gatekeeper is active. Endpoints are configured with the name of the gatekeeper, which they can resolve using DNS or the IP address of the gatekeeper. Virtual Router Redundancy Protocol (VRRP) VRRP allows a group of gatekeepers on a multiaccess link to use the same virtual IP address, with one device acting as the master virtual router and one or more devices configured to be available as backup virtual routers. Endpoints are configured with the name or virtual IP address of the gatekeeper. VRRP is defined by the IETF as RFC 3768. Multiple gatekeepers with gatekeeper discovery Deployment of multiple gatekeepers reduces the probability of total loss of gatekeeper access. However, adding new gatekeepers presents a new challenge. Each gatekeeper creates a unique H.323 zone. Because an H.323 endpoint is associated with only one gatekeeper at a time (in only one zone at a time), endpoints are configured to find only one of several working gatekeepers. Fortunately, a gateway can be configured with an ordered list of gatekeepers, or the gateway can be configured to use IP multicast to locate a gatekeeper. Multiple gatekeepers configured for the same prefix Gatekeepers send location request messages to other gatekeepers when locating an endpoint. By supporting the same prefix on multiple gatekeepers, the location request can be resolved by multiple gatekeepers. This strategy makes the loss of one gatekeeper less significant. Multiple gateways configured for the same prefix Survivability is enhanced at the gateway with multiple gateways that are configured to reach the same SCN destination. By configuring the same prefix of destinations in multiple gateways, the gatekeeper sees the same prefix more than once as each gateway registers with its gatekeeper.
H.323 Proxy Server An H.323 proxy server can circumvent the shortcomings of a direct path in cases where the direct path between two H.323 endpoints is not the most appropriate (for example, when the direct path has poor throughput and delay characteristics, when it is not easily available because of a firewall, or when zones are configured as inaccessible on the gatekeepers in order to isolate addressing information in different zones). When a proxy server is involved, two sessions are typically established as follows: However, when a proxy server also represents the terminating endpoint, a third session is required, as follows: Originating endpoint to proxy server 1 Proxy server 1 to proxy server 2 Proxy server 2 to terminating endpoint
Figure 6-24 illustrates an example with three sessions. Figure 6-24. H.323 Proxy Server 
The objective in this scenario is for Terminal 1 and Terminal 3 to establish an end-to-end relationship for multimedia communications. The following sequence of events occurs: 1. | Terminal 1 asks Gatekeeper 1 for permission to call Terminal 3.
| 2. | Gatekeeper 1 locates Gatekeeper 3 as the Terminal 3 gatekeeper. Gatekeeper 1 asks Gatekeeper 3 for the address of Terminal 3.
| 3. | Gatekeeper 3 responds with the address of Proxy 3 (instead of the address of Terminal 3) to hide the identity of Terminal 3.
| 4. | Gatekeeper 1 is configured to get to Proxy 3 by way of Proxy 1. So, Gatekeeper 1 returns the address of Proxy 1 to Terminal 1.
| 5. | Terminal 1 calls Proxy 1.
| 6. | Proxy 1 consults Gatekeeper 1 to discover the true destination of the call, which is Terminal 3 in this example.
| 7. | Gatekeeper 1 instructs Proxy 1 to call Proxy 3.
| | | 8. | Proxy 1 calls Proxy 3.
| 9. | Proxy 3 consults Gatekeeper 3 for the true destination, which is Terminal 3.
| 10. | Gatekeeper 3 gives the address of Terminal 3 to Proxy 3.
| 11. | Proxy 3 completes the call to Terminal 3.
|
Notice that the resulting path between Terminal 1 and Terminal 3 involves three separate legs: one between Terminal 1 and Proxy 1, one between Proxy 1 and Proxy 3, and one between Proxy 3 and Terminal 3. Both the media and any signaling are carried over these three legs. Cisco's Implementation of H.323 Cisco provides support for a variety of H.323 components, as depicted in Figure 6-25. Figure 6-25. Cisco's Implementation of H.323 
Cisco-supported H.323 components include the following: H.323 terminals Cisco provides support for H.323 terminals in Cisco IP phones. Gateways Cisco implements H.323 gateway support in: - Cisco voice-enabled routers (first available in Cisco IOS Release 11.3) - Cisco SC2200 Signaling Controllers - Cisco PGW 2200 Public Switched Telephone Network (PSTN) Gateways - Voice-enabled Cisco AS5xx0 access servers - Cisco BTS 10200 Softswitch
Gatekeepers Cisco implements gatekeeper support in: - Cisco Multimedia Conference Manager - Cisco Unified CallManager - Routers (first available in Cisco IOS Release 11.3)
Multipoint Control Unit (MCU) The multipoint controller (MC) and multipoint processor (MP) of the Cisco IP/VC 3500 Series MCU support all H.323 conference types. The IP/VC 3500 also incorporates a gatekeeper. Other support Cisco PIX 500 Series firewalls and Context-Based Access Control (CBAC) support in the Cisco Secure Integrated Software monitor the logical channel handshaking of the H.245 control function and dynamically open conduits for the Real-Time Transport Protocol (RTP) sessions.
Configuring H.323 Gateways and Gatekeepers Figure 6-26 offers a sample topology, which contains two H.323 gateways and two H.323 gatekeepers. This figure will be used to illustrate the configuration of both an H.323 gateway and an H.323 gatekeeper. Figure 6-26. H.323 Gateway and Gatekeeper Sample Topology 
First, consider the configuration of the GW_1 gateway, as presented in Example 6-1. Example 6-1. Gateway GW_1's Configuration To use a gatekeeper, an administrator must complete the following three tasks on the gateway: Step 1. | Enable the gateway with the gateway command.
| Step 2. | Configure the relationship with the gatekeeper. This requires the following three interface subcommands:
- - h323-gateway voip interface Tells the router that this interface should be enabled for H.323 packet processing.
- - h323-gateway voip id Identifies the ID of the gatekeeper.
- - h323-gateway voip h323-id Configures the ID of this router. When the router registers with the gatekeeper, the gatekeeper recognizes the gateway by this ID.
| Step 3. | Configure a dial peer to use the gatekeeper with the ras parameter on the dial peer subcommand session target.
|
Example 6-2 shows the configuration of gateway GW_2. As you examine the configuration, notice that it is a mirror of GW_1's configuration. Example 6-2. Gateway GW_2's Configuration GW_2(config)#hostname ECV-2610-16 GW_2(config)#interface Ethernet 0/0 GW_2(config-if)#ip address 10.52.218.48 255.255.255.0 GW_2(config-if)#h323-gateway voip interface GW_2(config-if)#h323-gateway voip id gk-zone2.test.com ipaddr 10.52.218.46 1718 GW_2(config-if)#h323-gateway voip h323-id gw_2 GW_2(config-if)#h323-gateway voip bind srcaddr 10.52.218.48 GW_2(config-if)#h323-gateway voip tech-prefix 1# GW_2(config-if)#exit GW_2(config)#dial-peer voice 1 voip GW_2(config-dial-peer)#destination-pattern 17.. GW_2(config-dial-peer)#session target ras GW_2(config-dial-peer)#exit GW_2(config)#dial-peer voice 2 pots GW_2(config-dial-peer)#destination-pattern 911 GW_2(config-dial-peer)#port 1/1/1 GW_2(config-dial-peer)#no register e164 ! gateway
|
Also, notice a couple of optional gateway commands presented in these examples: A technology prefix advises the gatekeeper that this gateway can handle type 1# destinations. For routing purposes, a technology prefix might be assigned to a multimedia type, such as video. By registering type 1# support, the gateway supports the video applications. In the dial peer, the no register e164 subcommand causes the gateway not to register the destination pattern when communicating with the gatekeeper. When the dial peer does not register its prefix, it requires an alternative mechanism for the gatekeeper to acquire this information. Now that you have examined the configuration for the H.323 gateways, turn your attention to the configuration of the H.323 gatekeepers. Example 6-3 presents a sample configuration for the GK_1 gatekeeper. Example 6-3. Gatekeeper GK_1's Configuration| [View full width] GK_1(config)#hostname ECV-2610-15 GK_1(config)#interface Ethernet 0/0 GK_1(config-if)#ip address 10.52.218.47 255.255.255.0 GK_1(config-if#exit GK_1(config)#gatekeeper  GK_1(config-gk)#zone local gk-zone1.test.com test.com 10.52.218.47 GK_1(config-gk)#zone remote gk-zone2.test.com test.com 10.52.218.46 1719 GK_1(config-gk)#zone prefix gk-zone2.test.com 16.. GK_1(config-gk)#zone prefix gk-zone1.test.com 17.. GK_1(config-gk)#gw-type-prefix 1#* default-technology GK_1(config-gk)#no shutdown
|
The gatekeeper application is enabled with the gatekeeper command. For Example 6-3, the gateways are configured to withhold their E.164 addresses, so the gatekeepers must define the addresses locally. This is done with zone prefix commands. In the example, each gatekeeper has two zone prefix commands: the first pointing to the other gatekeeper and the second pointing to the local zone (meaning the prefix is in the local zone). The zone prefix command that points to itself is configured with the name of the gateway used to direct traffic to the destination. The address of the gateway is not required because it is determined automatically when the gateway registers. The commands in the example perform the following functions: zone local gk-zone1.test.com test.com 10.52.218.47 Defines the ID of the local gatekeeper zone remote gk-zone2.test.com test.com 10.52.218.46 1719 Defines the identity and IP address of a neighboring gatekeeper
For completion, Example 6-4 illustrates the configuration of the GK_2 gatekeeper. Again, notice that the GK_2 configuration is a mirror of GK_1's configuration. Example 6-4. Gatekeeper GK_2's Configuration GK_2(config)#hostname ECV-2610-14 GK_2(config)#interface Ethernet 0/0 GK_2(config-if)#ip address 10.52.218.46 GK_2(config-if)#exit GK_2(config-if)#gatekeeper GK_2(config-gk)#zone local gk-zone2.test.com test.com 10.52.218.46 GK_2(config-gk)#zone remote gk-zone1.test.com test.com 10.52.218.47 1719 GK_2(config-gk)#zone prefix gk-zone2.test.com 16.. GK_2(config-gk)#zone prefix gk-zone1.test.com 17.. GK_2(config-gk)#gw-type-prefix 1#* default-technology GK_2(config-gk)#no shutdown
|
Because the gateways register their technology prefixes, the gatekeeper does not need to be configured. If a technology prefix is required, the gw-type-prefix defines a technology prefix and can manually update technology prefix knowledge in the gatekeeper. In Example 6-4, the gatekeeper attempts to define a technology prefix as the default with the command gw-type-prefix 1#* default-technology. Any unknown destination is assumed to be of the default technology type, and calls are forwarded to any gateway that registered the default technology type. Monitoring and Troubleshooting H.323 Cisco offers a variety of show and debug commands for examining the status of the H.323 components and for troubleshooting H.323-related issues. Following are show commands used for H.323: show call active voice [brief] Displays the status, statistics, and parameters for all active voice calls show call history voice [last n|record|brief] Displays call records from the history buffer show gateway Displays the current status of the H.323 gateway configured in the router show gatekeeper calls Displays the active calls for which the gatekeeper is responsible show gatekeeper endpoints Lists the registered endpoints with H.323 IDs and supported prefixes show gatekeeper gw-type-prefix Displays the current technology prefix table show gatekeeper status Displays the current status of the gatekeeper show gatekeeper zone prefix Displays the gateways and their associated E.164 prefixes show gatekeeper zone status Displays the status of the connections to gateways in the local zone and the status of connections to gatekeepers in other zones
Example 6-5 shows output from the show gatekeeper calls command. Example 6-5. The show gatekeeper calls Output Router#show gatekeeper calls Total number of active calls = 1. GATEKEEPER CALL INFO ==================== LocalCallID Age(secs) BW 1-19342 101 16(Kbps) Endpt(s): Alias E.164Addr src EP: R3 2222 CallSignalAddr Port RASSignalAddr Port 10.7.7.2 1720 10.7.7.2 56763 Endpt(s): Alias E.164Addr dst EP: R1 1111 CallSignalAddr Port RASSignalAddr Port 10.1.1.2 1720 10.1.1.2 52888
|
While troubleshooting, show commands do not always provide the level of detail needed to diagnose an issue. The following debug commands can aid in troubleshooting by providing a more granular and real-time view of H.323 activity: debug voip ccapi inout Shows every interaction with the call control application programming interface (CCAPI) on the telephone interface and the VoIP side. Monitoring the debug voip ccapi inout command output allows administrators to follow the progress of a call from the inbound interface or VoIP peer to the outbound side of the call. Because this debug is processor-intensive, use it sparingly in a live network. debug cch323 h225 Traces the transitions in the H.225.0 state machine during the establishment of the call control channel. The first step in establishing a relationship between any two components is to bring up the call control channel. Monitoring the output of the debug cch323 h225 command allows administrators to follow the call setup progress and determine if the channel is established correctly. debug cch323 h245 Traces the state transitions in the H.245 state machine during the establishment of the H.245 control channel. Monitoring the output of the debug cch323 h245 command allows administrators to see if the channel is established correctly. debug cch323 ras Traces the state transition in the establishment of the Registration, Admission, and Status (RAS) control channel. Monitoring the output of the debug cch323 ras command allows administrators to determine if the channel is established correctly. debug h225 asn1 Displays an expansion of the ASN.1-encoded H.225.0 messages. When investigating VoIP peer association problems, this debug command helps administrators monitor the activity of the call-signaling channel. Because H.225.0 encapsulates H.245, this is a useful approach for monitoring both H.225.0 and H.245. debug h225 events Similar to the Abstract Syntax Notation One (ASN.1) version of the command, but does not expand the ASN.1. This debug command only debugs events, which usually imposes a lighter load on the router. debug h245 [asn1 | events] Similar to the H.225.0 variant except that it displays only the H.245 messages.
To turn off a debug command, issue the no debug or undebug all command. Leaving a debug command running can cause excessive processor overhead on the router. SIP Concepts and Configuration An understanding of the features and functions of SIP components, and the relationships the components establish with each other, is important in implementing a scalable, resilient, and secure SIP environment. This section describes how to configure the session initiation protocol (SIP) and explores the features and functions of a SIP environment, including SIP components, how these components interact, and how to accommodate scalability and survivability in a SIP network. SIP and Associated Standards SIP is a signaling and control protocol for the establishment, maintenance, and termination of multimedia sessions with one or more participants. Examples of SIP multimedia sessions include Internet telephone calls, multimedia conferences, and multimedia distribution. Session communications might be based on multicast, unicast, or both. SIP operates on the principle of session invitations. Through invitations, SIP initiates sessions or invites participants into established sessions. Descriptions of these sessions are advertised by any one of several means, including the Session Announcement Protocol (SAP), defined in RFC 2974, which incorporates a session description according to the Session Description Protocol (SDP), defined in RFC 2327. SIP uses other IETF protocols to define other aspects of VoIP and multimedia sessions. For example, SIP can use URLs for addressing, DNS for service location, and Telephony Routing over IP (TRIP) for call routing. SIP supports personal mobility and other intelligent ietwork (IN) telephony subscriber services through name mapping and redirection services. Personal mobility allows a potential participant in a session to be identified by a unique personal number or name. IN provides carriers with the ability to rapidly deploy new user services on platforms that are external to the switching fabric. Access to the external platforms is by way of an independent vendor and standard user interface. Calling-card services, 1-800 services, and local number portability are just three of these services. Multimedia sessions are established and terminated by the following services: User location services Locate an end system User capabilities services Select the media type and parameters User availability services Determine the availability and desire for a party to participate Call setup services Establish a session relationship between parties and manage call progress Call handling services Transfer and terminate calls
Although the IETF has made great progress in defining extensions that allow SIP to work with legacy voice networks, the primary motivation behind SIP is to create an environment that supports next-generation communication models that use the Internet and Internet applications. SIP is described in IETF RFC 3261 (June 2002), which renders obsolete RFC 2543 (March 1999). Cisco SIP Support The Cisco SIP-enabled product portfolio encompasses multiple components of a SIP network infrastructure, from IP phones and access devices to call control and PSTN interworking. Examples of Cisco SIP products include the following: Cisco IP phones The Cisco IP phone series, including the 7970, 7960, and 7940 Cisco IP phones, support SIP user-agent functionality. These IP phones deliver functionality such as inline-power support and dual-Ethernet ports, and deliver traditional desktop functionality such as call hold, transfer, conferencing, caller ID, call waiting, and a lighted message-waiting indicator. Cisco ATA 186 Analog Telephone Adaptor The Cisco ATA 186 supports SIP user-agent functionality. With two FXS ports and a single Ethernet port, the ATA 186 provides a low-cost means to connect analog phones to a SIP network. The ATA 186 also delivers traditional desktop functionality such as call hold, transfer, conferencing, caller ID, and lighted call-waiting and message-waiting indicators. Cisco packet voice gateways The Cisco 1700 modular access routers that are voice capableCisco 2600 Series multiservice platforms, Cisco 3800 Series multiservice platforms, 3700 Series multiservice platforms, Cisco AS5000 universal gateways, and Cisco 7200 Series voice gatewaysall support SIP user-agent functionality. These devices provide a means of connecting SIP networks to traditional time-division multiplexing (TDM) networks via T1, E1, Digital Service 3 (DS3), channel associated signaling (CAS), PRI/BRI, R2 signaling, FXS, Foreign Exchange Office (FXO), or ear-and-mouth (E&M) interfaces. Cisco packet voice gateways are used to build the largest IP telephony networks in the world. Cisco SIP Proxy Server The Cisco SIP Proxy Server provides the functionality of a SIP proxy, SIP redirect, SIP registrar, and SIP location services server. The Cisco SIP Proxy Server provides the foundation for call routing within SIP networks and can work with traditional SIP location services such as DNS or telephone number mapping (ENUM), with feature servers via a SIP redirect message and with H.323 location services using standard location request (LRQ) messages. The Cisco SIP Proxy Server runs on either Solaris or Linux operating systems. Cisco BTS 10200 Softswitch The Cisco BTS 10200 provides softswitch functionality to Class 4 and Class 5 networks and provides SIP-to-Signaling System 7 (SIP-to-SS7) gateway functionality for American National Standards Institute (ANSI) standardized networks. The BTS 10200 supports SIP user-agent functionality in conjunction with a Cisco voice media gateway such as a Cisco AS5000 Universal Gateway or a Cisco MGX 8000 Series Voice Gateway. Cisco PGW 2200 PSTN Gateway The Cisco PGW 2200 provides softswitch functionality for Class 4 networks, as well as Internet offload and SIP-to-SS7 gateway functionality for international networks. The PGW 2200 supports ISDN User Part (ISUP) certification in over 130 countries. The PGW 2200 supports SIP user-agent functionality in conjunction with a Cisco packet voice media gateway such as an AS5000 Universal Gateway or an MGX 8000 Series Voice Gateway. Cisco PIX and ASA Security Appliances The Cisco PIX and the ASA Security Appliances are SIP-aware networking devices that provide firewall and Network Address Translation (NAT) functionality. Because they are SIP-aware, these appliances are able to dynamically allow SIP signaling to traverse network and addressing boundaries without compromising overall network security. The Cisco PIX and the ASA Security Appliances functioning in this capacity are called application layer gateways (ALGs).
SIP Components SIP is a peer-to-peer protocol. The peers in a session are called user agents (UAs), as illustrated in Figure 6-27. Figure 6-27. SIP Functional Components 
A UA consists of two functional components: User agent client (UAC) A client application that initiates a SIP request User agent server (UAS) A server application that contacts the user when a SIP invitation is received and then returns a response on behalf of the user to the invitation originator
Typically, a SIP UA can function as a UAC or a UAS during a session, but not both in the same session. Whether the endpoint functions as a UAC or a UAS depends on the UA that initiated the request. Specifically, the initiating UA uses a UAC and the terminating UA uses a UAS. From an architectural standpoint, the physical components of a SIP network are grouped into the following two categories: SIP Applications Leaders in the communications industry are developing new products and services that rely on SIP, and they are offering attractive new communications services to their customers. Microsoft added support for SIP clients in core product offerings (for example, Windows XP), a step that will proliferate SIP clients on personal computers worldwide. SIP is gaining momentum in every market, and many interexchange carriers have deployed SIP in their networks. Cisco is enabling the advance of new communications services with a complete SIP-enabled portfolio, including proxy servers, packet voice gateways, call control and signaling, IP phones, and firewalls. These products are available today. Also, Cisco introduced support for SIP trunks in Cisco Unified CallManager 4.0. A SIP trunk can connect a Unified CallManager environment to a SIP proxy server, allowing these diverse network types to communicate. SIP Messages Communication between SIP components uses a request and response message model. Example 6-6 provides a sample of a SIP request message. Example 6-6. SIP Request Message INVITE: sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142
|
SIP communication involves the following two message types: Request from a client to a server Consists of a request line, header lines, and a message body Response from a server to a client Consists of a status line, header lines, and a message body
All SIP messages are text based and modeled on RFC 822, "Standard for ARPA Internet Text Messages," and RFC 2068, "Hypertext Transfer Protocol HTTP/1.1." SIP defines four types of headers: General header Entity header Request header Response header
The first two appear on both message types. The latter two are specific to request and response messages, respectively. In the request line, SIP uses a method to indicate the action to be taken by the responding component (usually a server). The following request methods indicate the action that the responding component should take: INVITE A client originates the INVITE method to indicate that the server is invited to participate in a session. An invitation includes a description of the session parameters. ACK A client originates the ACK method to indicate that the client has received a response to its earlier invitation. BYE A client or server originates the BYE method to initiate call termination. CANCEL A client or server originates the CANCEL method to interrupt any request currently in progress. CANCEL is not used to terminate active sessions. OPTIONS A client uses the OPTIONS method to solicit capabilities information from a server. This method is used to confirm cached information about a UA or to check the ability of a UA to accept an incoming call. REGISTER A UA uses the REGISTER method to provide information to a network server. Registrations have a finite life and must be renewed periodically. This prevents the use of stale information when a UA moves.
SIP response messages are sent in response to a request and indicate the outcome of request interpretation and execution. Responses take one of three basic positions: success, failure, or provisional. A status code reflects the outcome of the request. Status Codes The following response messages indicate the status of a request: 1xxInformational Provisional response. Indicates that the request is still being processed. 2xxSuccessful Indicates that the requested action is complete and successful. 3xxRedirection Indicates that the requestor requires further action. For example, a redirect server responds with a "moved" message to advise the client to redirect its invitation. 4xxClient error Fatal response. Indicates that the client request is flawed or impossible to complete. 5xxServer error Fatal response. Indicates that the request is valid but the server failed to complete it. 6xxGlobal failure Fatal response. Indicates that the request cannot be fulfilled by any server.
SIP Addressing An address in SIP is defined in the syntax for a URL with sip: or sips: (for secure SIP connections) as the URL type. SIP URLs are used in SIP messages to identify the originator, the current destination, the final recipient, and any contact party. When two UAs communicate directly with each other, the current destination and final recipient URLs are the same. However, the current destination and the final recipient are different if a proxy or redirect server is used. An address consists of an optional user ID, a host description, and optional parameters to qualify the address more precisely. The host description might be a domain name or an IP address. A password can be associated with the user ID, and a port number can be associated with the host description. Consider the SIP address examples presented in Example 6-7. Example 6-7. SIP Address Examples Fully Qualified Domain Names: sip:joe@cisco.com E.164 Addresses: sip:14085551234@gateway.com;user=phone Mixed Addresses: sip:14085551234;password=changeme@10.1.1.1 sip:joe@10.1.1.1
|
In Example 6-7, the user=phone parameter of sip:14085551234@gateway.com; user=phone is required to indicate that the user part of the address is a telephone number. Without the user=phone parameter, the user ID is taken literally as a numeric string. The 14085551234 in the URL sip:14085551234@10.1.1.1 is an example of a numeric user ID. In the same example, the password changeme is defined for the user. A SIP address can be acquired in several ways, including interacting with a user, caching information from an earlier session, or interacting with a network server. For a network server to assist, it must recognize the endpoints in the network. This knowledge is dynamically acquired by a location server, which queries its registrar server. To contribute to this dynamic knowledge, an endpoint registers its user addresses with a registrar server. Figure 6-28 illustrates a REGISTER mode request to a registrar server. Figure 6-28. SIP Address Registration 
To resolve an address, a UA uses a variety of internal mechanisms such as a local host table, DNS lookup, finger, rwhois, or LDAP, or it leaves that responsibility to a network server. A network server uses any of the tools available to a UA or interacts through a nonstandard interface with a location server. Figure 6-29 illustrates a SIP proxy server resolving the address by using the services of a location server. Figure 6-29. SIP Address Resolution 
SIP Call Setup Models If a UAC recognizes the destination UAS, the client communicates directly with the server. In situations in which the client is unable to establish a direct relationship, the client solicits the assistance of either a proxy server or a redirect server. Direct Call Setup When a UA recognizes the address of a terminating endpoint from cached information, or has the capacity to resolve it by some internal mechanism, the UAC might initiate direct (UAC-to-UAS) call setup procedures. As illustrated in Figure 6-30, direct setup is the fastest and most efficient of the call setup procedures. However, direct setup has some disadvantages. It relies on cached information or internal mechanisms to resolve addresses, which can become outdated if the destination is mobile. In addition, if the UA must keep information on a large number of destinations, management of the data can become prohibitive. This makes the direct method nonscalable. Figure 6-30. Direct Call Setup 
Direct call setup proceeds as follows: 1. | The originating UAC sends an invitation (INVITE) to the UAS of the recipient. The message includes an endpoint description of the UAC and SDP.
| 2. | If the UAS of the recipient determines that the call parameters are acceptable, it responds positively to the originator UAC.
| 3. | The originating UAC issues an ACK.
|
At this point, the UAC and UAS have all the information required to establish RTP sessions between them. Call Setup Using a Proxy Server The proxy server procedure is transparent to a UA. The proxy server intercepts and forwards an invitation to the destination UA on behalf of the originator, as depicted in Figure 6-31. Figure 6-31. Call Setup Using a Proxy Server 
A proxy server responds to the issues of the direct method by centralizing control and management of call setup and providing a more dynamic and up-to-date address resolution capability. The benefit to the UA is that it does not need to learn the coordinates of the destination UA, yet can still communicate with the destination UA. The disadvantages of this method are that using a proxy server requires more messaging and creates a dependency on the proxy server. If the proxy server fails, the UA is incapable of establishing its own sessions. Note Although the proxy server acts on behalf of a UA for call setup, the UAs establish RTP sessions directly with each other.
When a proxy server is used, the call setup procedure is as follows: 1. | The originating UAC sends an invitation (INVITE) to the proxy server.
| 2. | The proxy server, if required, consults the location server to determine the path to the recipient and its IP address.
| 3. | The proxy server sends the invitation to the UAS of the recipient.
| 4. | If the UAS of the recipient determines that the call parameters are acceptable, it responds positively to the proxy server.
| 5. | The proxy server responds to the originating UAC.
| 6. | The originating UAC issues an ACK.
| 7. | The proxy server forwards the ACK to the recipient UAS.
|
The UAC and UAS now have all the information required to establish RTP sessions. Call Setup Using a Redirect Server A redirect server is programmed to discover a path to the destination. Instead of forwarding the invitation to the destination, the redirect server reports back to a UA with the destination coordinates that the UA should try next, as shown in Figure 6-32. Figure 6-32. Call Setup Using a Redirect Server 
A redirect server offers many of the advantages of the proxy server. However, the number of messages involved in redirection is fewer than with the proxy server procedure. The UA has a heavier workload because it must initiate the subsequent invitation. When a redirect server is used, the call setup procedure is as follows: 1. | The originating UAC sends an invitation (INVITE) to the redirect server.
| 2. | The redirect server, if required, consults a location server to determine the path to the recipient and its IP address.
| 3. | The redirect server returns a "moved" response to the originating UAC, which contains the IP address obtained from the location server.
| 4. | The originating UAC acknowledges the redirection.
| 5. | The originating UAC sends an invitation to the remote UAS.
| 6. | If the UAS of the recipient determines that the call parameters are acceptable, it responds positively to the UAC.
| 7. | The originating UAC issues an acknowledgment.
|
The UAC and UAS now have all the information required to establish RTP sessions between them. Robust SIP Design In a SIP environment, the failure of a network server cripples UAs that are dependent on that server. The network servers in a SIP network are the proxy server, the redirect server, the registrar server, and the location server. The most obvious way to preserve access to the critical components is to implement multiple instances of access. For replication of a proxy or redirect server to be effective, a UA must have the ability to locate an active server dynamically. You can achieve this in any of the following ways: Preconfigure a UA with the address of at least two of the servers. If access to its first choice fails, the UA shifts to he second. If all servers are configured with the same name, you can configure a UA to look up the name using DNS. The DNS query returns the addresses of all the servers matching the name, and the UA proceeds down the list until it finds one that works.
Figure 6-33 illustrates replication of SIP servers for survivability. Figure 6-33. Survivability Strategies 
Cisco's Implementation of SIP Cisco provides support for the following SIP components: SIP user agents Cisco provides support for SIP UAs in Cisco IP phones. Cisco also implements SIP UA (gateway) support in the following devices: - Cisco voice-enabled routers (first available in Cisco IOS Release 12.1) - Cisco PGW 2200 PSTN gateways - Voice-enabled AS5xx0 access servers - Cisco BTS 10200 Softswitch
Network servers Cisco implements SIP proxy and redirect server support in the Cisco SIP Proxy Server. The server is an application designed for a Linux (Redhat 7.3) or Solaris 8 operating environment. Other support Cisco PIX and ASA Security Appliances monitor the SIP handshaking to dynamically open conduits for the RTP sessions.
Configuring SIP on a Cisco Router A SIP configuration consists of two parts: the SIP UA and the VoIP dial peers that select SIP as the session protocol. User Agent A Cisco voice-enabled router can be configured as a SIP UA. Example 6-8 shows a sample SIP UA configuration. Example 6-8. SIP User Agent Router(config)#sip-ua Router(config-sip-ua)#retry invite 2 Router(config-sip-ua)#retry response 2 Router(config-sip-ua)#retry bye 2 Router(config-sip-ua)#retry cancel 2 Router(config-sip-ua)#sip-server dns:ACME_SERVER
|
The UA is enabled with the sip-ua command. Subcommands are optional. Example 6-8 also shows how you can change the value of four retry counters, which optionally adjust SIP signaling timers. The configuration also specifies the name of a SIP proxy or redirect server with the sip-server command. Dial Peer SIP is selected as the call control protocol from inside a dial peer. Specifically, SIP is requested by the session protocol sipv2 dial peer subcommand. Example 6-9 illustrates two dial peer variations. Example 6-9. SIP Dial Peers Router(config)#dial-peer voice 444 voip Router(config-dial-peer)#destination-pattern 2339000 Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target ipv4:172.18.192.205 Router(config-dial-peer)#exit Router(config)#dial-peer voice 111 voip Router(config-dial-peer)#destination-pattern 111 Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target sip-server
|
Notice that in Example 6-9, both dial peers include session protocol sipv2, and SIP is used when the destination pattern matches either dial peer. However, in dial-peer 444, the IP address of the server is provided as the session target. The address can be the address of a UA, proxy server, or redirect server. In dial peer 111, the session target is sip-server. When sip-server is the target, the IP address of the actual server is taken from the sip-server subcommand in the SIP UA configuration. This means that from global configuration mode, the network administrator has entered the sip-ua command and the sip-server dns:server_name subcommand. The address represents the location of a proxy server or redirect server. In Example 6-8, the name of the SIP server is ACME_SERVER. Monitoring and Troubleshooting SIP The Cisco IOS provides a series of show and debug commands to provide support for monitoring and troubleshooting SIP. Example 6-10 demonstrates sample output from the show sip-us status command, and Example 6-11 shows sample output from the show sip-us timers command. Example 6-10. The show sip-us status Command Router# show sip-ua status SIP User Agent Status SIP User Agent for UDP :ENABLED SIP User Agent for TCP :ENABLED SIP max-forwards :6
|
Example 6-11. The show sip-us timers Command Router# show sip-ua timers SIP UA Timer Values (millisecs) Trying 500, expires 180000, connect 500, disconnect 500
|
The following show commands are valuable when examining the status of SIP components and troubleshooting: show call active voice [brief] Displays the status, statistics, and parameters for all active voice calls show call history voice [last n| record | brief] Displays call records from the history buffer show sip-ua retry Displays the SIP protocol retry counts show sip-ua statistics Displays the SIP UA response, traffic, and retry statistics show sip-ua status Displays the SIP UA listener status, which should be enabled show sip-ua timers Displays the current value of the SIP UA timers
The following debug commands are valuable when examining the status of SIP components and troubleshooting: debug voip ccapi inout Shows every interaction with the CCAPI on both the telephone interface and on the VoIP side. By monitoring the output, you can follow the progress of a call from the inbound interface or VoIP peer to the outbound side of the call. Because this debug is very active, you should use it sparingly in a live network. debug ccsip all Enables general SIP debugging. This debug is very active; you must use it sparingly in a live network. debug ccsip calls Displays all SIP call details as they are updated in the SIP call control block. You must use this debug to monitor call records for suspicious clearing causes. debug ccsip errors Traces all errors encountered by the SIP subsystem. debug ccsip events Traces events, such as call setups, connections, and disconnections. An events version of a debug is often the best place to start because detailed debugs provide a great deal of useful information. debug ccsip messages Shows the headers of SIP messages that are exchanged between a SIP client and a server. debug ccsip states Displays the SIP states and state changes for sessions within the SIP subsystem.
|
