Call Setup Using a Redirect Server
A redirect server is programmed to discover a path to the destination. Instead of forwarding the INVITE to the destination, the redirect server reports back to a UA with the destination coordinates the UA should try next, as indicated in Figure 5-26.
Figure 5-26 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, as illustrated in Figure 5-26, uses the following steps:
1. The originating UAC sends an invitation (INVITE) to the redirect server.
2. The redirect server, if required, consults the 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 with the IP address obtained from the location server.
4. The originating UAC acknowledges the redirection.
5. The originating UAC sends an INVITE 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 ACK.
The UAC and UAS now have all the information that is required to establish RTP sessions between themselves.
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.
To obtain the IP address of a SIP UAS or a network server, a UAC performs address resolution of a user identifier. 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 is associated with the user ID, and a port number is associated with the host description.
A SIP address is acquired in several ways: by interacting with a user, by caching information from an earlier session, or by interacting with a network server. For a network server to assist, it must recognize the endpoints in the network. This knowledge is abstracted to reside in a location server and is dynamically acquired by its registrar server.
To contribute to this dynamic knowledge, an endpoint registers its user addresses with a registrar server. Figure 5-27 illustrates a voice REGISTER mode request to a registrar server.
Figure 5-27 Address Registration
To resolve an address, a UA uses a variety of internal mechanisms such as a local host table, DNS lookup, Finger protocol, RWhois, or LDAP, or it leaves that responsibility to a network server, as shown in Figure 5-28. A network server uses any of the tools available to a UA or interacts with a location server.
Figure 5-28 Address Resolution
SIP DTMF Considerations
The SIP DTMF relay method is needed in the following situations:
■ When SIP is used to connect a Cisco SRST system to a remote SIP-based IVR or voice-mail application
■ When SIP is used to connect a Cisco SRST system to a remote SIP PSTN voice gateway that goes through the PSTN to a voice-mail or IVR application
Note The need to use out-of-band DTMF relay conversion is limited to SCCP phones. SIP phones natively support in-band DTMF relay as specified in RFC 2833.
SIP usually sends DTMF in-band digits, whereas SCCP supports only out-of-band digits. The software-based Media Termination Point (MTP) device receives the DTMF out-of-band tones and generates DTMF in-band tones for the SIP client.
Figure 5-29 illustrates a call that begins with media streaming, and the Cisco Unified Communications Manager software-based MTP device has been informed of the dynamic DTMF payload type.
Figure 5-29 SIP DTMF Configuration Considerations
The procedure that makes it possible to send SCCP out-of-band DTMF tones to SIP networks is as follows:
1. The SCCP IP phone user presses buttons on the keypad. Cisco Unified Communications Manager collects the out-of-band digits from the SCCP IP phone.
2. Cisco Unified Communications Manager passes the out-of-band digits to the MTP device.
3. The MTP device converts the digits to RFC 2833-compliant in-band digits and forwards them to the SIP client.
Note Because the Cisco Unified Communications Manager software-based MTP can handle no more than 48 media streams in parallel, only 48 SCCP-to-SIP calls are available in older versions of Cisco Unified CallManager without a hardware MTP. In that case, it is necessary to configure the gateway to send DTMF out-of-band. (Cisco Unified Communications Manager Release 5.0 and later can handle SCCP-to-SIP calls without an MTP.)
As previously mentioned, SCCP IP phones are capable of sending only out-of-band DTMF digits. To support SCCP devices, originating and terminating SIP gateways can use Cisco proprietary NOTIFY-based out-of-band DTMF relay. In addition, NOTIFY-based out-of-band DTMF relay can also be used by analog phones attached to analog voice ports (known FXS) on the router.
NOTIFY-based out-of-band DTMF relay sends messages bidirectionally between the originating and terminating gateways for a DTMF event during a call. If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes precedence.
The originating gateway sends an INVITE message with SIP Call-Info header information to indicate the use of the NOTIFY-based out-of-band DTMF relay. The terminating gateway acknowledges the message with an 18x or 200 Response message, also using the Call-Info header. Whenever a DTMF event occurs, the gateway sends a SIP NOTIFY message for that event after the SIP Invite and 18x or 200 Response messages negotiate the NOTIFY-based out-of-band DTMF relay mechanism. In response, the gateway expects to receive a 200 OK message.
The NOTIFY-based out-of-band DTMF relay mechanism is similar to the DTMF message format described in RFC 2833.
Configuring SIP
A SIP configuration consists of two parts: the SIP UA and the VoIP dial peers that select SIP as the session protocol.
To integrate Cisco IOS gateways into a SIP service provider VoIP network, you can perform, at least, the following steps:
Step 1. Enable the SIP voice service within Cisco IOS. Step 2. Specify the parameters for the SIP service. Step 3. Configure the SIP UA.
Step 4. Configure the SIP-based VoIP dial peers to connect and route calls to the service provider’s SIP network.
Configuring a SIP Gateway Example
Figure 5-30 shows a scenario where you connect Cisco Unified Communications Manager Express to a SIP service provider. The SIP voice service configuration is one part of the SIP configuration.
Figure 5-30 Integrating IOS Gateways with a SIP ITSP SIP Gateway Configuration Scenario
As a network administrator, one of your duties is to configure a voice gateway to meet network requirements. Specifically, you have been asked to integrate SIP connectivity with your company’s VoIP service provider.
The requirements are as follows:
■ Use SIP as a signaling protocol.
■ Set the transport protocol to UDP.
■ Use interface Loopback 0 as the source interface for SIP.
■ Modify the UA as follows:
■ Enable local authentication.
■ Enable E.164 address registration for directly attached analog phones.
■ Configure a SIP server to be used with dial peers.
■ Change the number of SIP INVITE, RESPONSE, BYE, and Cancel retries to 2.
