Cisco SIP Proxy Server Version 1.2 Administrator Guide - Product Overview [Cisco SIP Proxy Server]

Table Of Contents

Product Overview

What is SIP?

Components of SIP

SIP Clients

SIP Servers

What is the Cisco SIP Proxy Server?

Features

Server Modes

Protocol Support

Spiralled and Looped Request Detection

Address Translation, Routing, and IP Resolution

Authentication, Authorization

Accounting

Server Farm Support

IP Security

Access and Error Logging

Requirements

Solaris Platform Requirements

Linux Platform Requirements

Related Documentation

Reference Links

Product Overview

This chapter provides an overview of the Cisco SIP Proxy Server, its features, and prerequisites. This chapter contains the following sections:

•What is SIP?

•What is the Cisco SIP Proxy Server?

•Requirements

•Related Documentation

What is SIP?

Session Initiation Protocol (SIP) is the Internet Engineering Task Force's (IETF's) standard for multimedia conferencing over IP. SIP is an ASCII-based, application-layer control protocol (defined in RFC 2543) that can be used to establish, maintain, and terminate calls between two or more end points.

Like other VoIP protocols, SIP is designed to address the functions of signaling and session management within a packet telephony network. Signaling allows call information to be carried across network boundaries. Session management provides the ability to control the attributes of an end-to-end call.

SIP provides the capabilities to:

•Determine the location of the target end point—SIP supports address resolution, name mapping, and call redirection.

•Determine the media capabilities of the target end point—Via Session Description Protocol (SDP), SIP determines the "lowest level" of common services between the end points. Conferences are established using only the media capabilities that can be supported by all end points.

•Determine the availability of the target end point—If a call cannot be completed because the target end point is unavailable, SIP determines whether the called party is already on the phone or did not answer in the allotted number of rings. It then returns a message indicating why the target end point was unavailable.

•Establish a session between the originating and target end point—If the call can be completed, SIP establishes a session between the end points. SIP also supports mid-call changes, such as the addition of another end point to the conference or the changing of a media characteristic or codec.

•Handle the transfer and termination of calls—SIP supports the transfer of calls from one end point to another. During a call transfer, SIP simply establishes a session between the transferee and a new end point (specified by the transferring party) and terminates the session between the transferee and the transferring party. At the end of a call, SIP terminates the sessions between all parties.

Conferences can consist of two or more users and can be established using multicast or multiple unicast sessions.

Note The term conference means an established session (or call) between two or more end points. In this document, the terms conference and call are used interchangeably.

Components of SIP

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 that returns a response on behalf of the user.

Typically, a SIP end point is capable of functioning as both a UAC and a UAS, but 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 architecture standpoint, the physical components of a SIP network can be grouped into two categories: clients and servers. Figure 1-1 illustrates the architecture of a SIP network.

Note In addition, the SIP servers can interact with other application services, such as Lightweght Directory Access Protocol (LDAP) servers, location servers, a database application, or an extensible markup language (XML) application. These application services provide back-end services such as directory, authentication, and billing services.

Figure 1-1 SIP Architecture

SIP Clients

SIP clients include:

•Phones—Can act as either a UAS or UAC. Softphones (PCs that have phone capabilities installed) and Cisco SIP IP phones can initiate SIP requests and respond to requests.

•Gateways—Provide call control. Gateways provide many services, the most common being a translation function between SIP conferencing endpoints and other terminal types. This function includes translation between transmission formats and between communications procedures. In addition, the gateway also translates between audio and video codecs and performs call setup and clearing on both the LAN side and the switched-circuit network side.

SIP Servers

SIP servers include:

•Proxy server—The proxy server is 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.

•Redirect server—Provides the client with information about the next hop or hops that a message should take and then 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.

What is the Cisco SIP Proxy Server?

The Cisco SIP Proxy Server Version 1.1 provides the primary capabilities required for call session management in a VoIP network and processes SIP requests and responses as described in RFC 2543. Powered by Apache, the Cisco SIP Proxy Server can be configured to operate as a transaction stateful or stateless server. The Cisco SIP Proxy Server can also be configured to provide additional server modes and features. For example, the Cisco server can be configured to:

•Function as a redirect or registrar server

•Translate E.164 numbers to URL via location server protocols such as Telephone Number Mapping (ENUM)

•Perform gateway and Domain Name System (DNS) routing

Note This Cisco SIP Proxy Server includes software developed by the Apache Software Foundation (http://www.apache.org/).

Features

The Cisco SIP Proxy Server offers the following features:

•Ability to function as a transaction stateful or stateless proxy server, stateful or stateless redirect server, and registrar server

•Call forwarding

•CLI Tools for:

–routing and registry databases

–MySQL subscriber databases

•Ability to distinguish spiralled requests from looped requests

•Address translation

–Registry database (static registry entries for contact points)

–Gatekeeper Transaction Message Protocol (GKTMP) interface with Cisco NAM for 1-800, 1-900, and LNP lookups as well as least-cost routing

–E.164 to URL address translation (via location server protocols such as ENUM and GKTMP)

•Next-hop routing

–Static E.164 routes (dial plans)

•SRV lookup for static route

–RAS module that allows communications between a Cisco SIP proxy server and a H.323 directory gatekeeper

–Static domain routes

–DNS SRV routes

•Authentication and authorization via HTTP (Hypertext Transfer Protocol) Digest or HTTP Basic and MySQL, or via HTTP Basic or CHAP-password and Radius.

•Accouting via Radius

•Server farm support for sharing database information (registry, routing, and special number services databases)

•SIP over User Datagram Protocol (UDP) transport protocol support

•Interoperability with Cisco SIP gateways, SIP IP phones, and unified messaging

•IP security (IPSec) for SIP signaling messages

•Access and error logging

Server Modes

The Cisco SIP Proxy Server can be configured to function as one of the following types of servers:

•Transaction stateful or stateless proxy server

The Cisco SIP Proxy Server can operate as a transaction stateful or stateless proxy server.

When configured to be a stateful proxy server, the proxy server creates a transaction control block (TCB) and remembers incoming and outgoing requests, providing reliable retransmission of proxied requests and returning the best final response or responses back upstream. One transaction encompasses the received request, the request or requests (if forked) forwarded downstream, responses received from downstream hosts, and the best response returned upstream.

When configured to be a stateless proxy server, the Cisco SIP Proxy Server forgets all information once a request or response has been processed. As a stateless proxy server, the Cisco SIP Proxy Server will just forward requests and responses.

The Cisco SIP Proxy Server also performs functions such as authentication, authorization, and security.

•Transaction stateful or stateless redirect server

As a redirect server, the Cisco SIP Proxy Server accepts SIP requests, maps the address in the Request-URI to zero or more new addresses, and returns these addresses as Contacts in a SIP 3xx response to the UAC.

When configured as a stateless redirect server, the Cisco SIP Proxy Server does not create a TCB on receiving an INVITE request.

The Cisco SIP Proxy Server is configured to function as a redirect or proxy server for all calls (globally), however, this default functionality can be changed via the optional Action parameter included in the Contact header of a Register request. If an action parameter is given in a Register request, the Cisco SIP Proxy Server will function as specified by that parameter. If no action parameters is given in the Registration request, the Cisco SIP Proxy Server will function as configured. The Action parameter specification is honored when the UseCallerPreferences directive is set to On in the sipd.conf file.

•Registrar server

As a registrar server, the Cisco SIP Proxy Server processes requests from UACs for registration of their current location. The Cisco SIP Proxy Server also maintains registration information and can share this information with other registrar servers in its farm. As a registrar server, the Cisco SIP Proxy Server provides location services to the proxy server.

Note In Version 1.1 of the Cisco SIP Proxy Server, registrar servers also must be configured to function as either a proxy or redirect server. Standalone registrar servers are not supported.

For more information on configuring server modes, see the Configuring the Cisco SIP Proxy Server Core Configuration Section.

Protocol Support

The Cisco SIP Proxy Server supports the following network and transport protocols:

•Internet Protocol (IP)

IP is a network layer protocol that sends datagram packets between nodes on the Internet. IP also provides features for addressing, type-of-service (ToS) specification, fragmentation and reassembly, and security.

The Cisco SIP Proxy Server supports IP as it is defined in RFC 791.

•User Datagram Protocol (UDP)

UDP is a simple protocol that exchanges data packets without acknowledgments or guaranteed delivery. SIP can use UDP as the underlying transport protocol. With UDP, retransmissions are used to ensure reliability.

The Cisco SIP Proxy Server supports UDP as it is defined in RFC 768 for SIP signaling.

•Domain Name System (DNS)

DNS is used in the Internet for translating names of network nodes into addresses. SIP uses DNS to resolve the host names of end points to IP addresses.

•Session Description Protocol (SDP)

SDP is an ASCII-based protocol that describes multimedia sessions and their related scheduling information.

The Cisco SIP IP phone uses SDP for session description.

Spiralled and Looped Request Detection

A spiralled request is a request that re-visits the Cisco SIP Proxy Server with a new request-uri and is considered a new transaction by the proxy. A looped request is a request that contains the proxy's via header and the request-uri is the same as it was when it first visited the proxy.

At the proxy, this capability has the following effects.

•Allows the same call to be logged more than once

•May cause invocation of different features

•If Record-Route field in the INVITE message is enabled at the proxy, Record-Route procedure will be performed more than once.

Note The Call-ID, From, To and CSeq.seqnum fields of a spiralled request are the same as that of the request which visited the proxy the first time.

Address Translation, Routing, and IP Resolution

The following steps are performed by the Cisco SIP Proxy Server to deliver messages from endpoint to endpoint:

1. Translation—Process of translating an incoming Request-URI into an outgoing Request-URI.

2. Next hop routing—Process of obtaining a set of Fully Qualified Domain Names (FQDNs) or IP addresses with port numbers for each of the SIP entities found in the translation step. Among others, this step involves the following features.

a. SRV lookup for static route—Process of a SRV lookup on the Static_Route_NextHop field if the Static_Route_NextHopPort field in a static route is not specified or is zero.

b. RAS LRQ message transmission to gatekeeper—Process of sending the LRQ message to the H.323 gatekeeper to obtain the next hop gateway transport address.

3. IP resolution—Process of converting each next hop found in the next hop route lookup step into an IP address.

Note If a Route header is present in the SIP request message, the Cisco SIP Proxy Server translation and next hop routing functions are bypassed. Record-Route must be enabled on the server for subsequent requests to contain a route header.

Translation

During the translation step, the Request-URI of an incoming request is processed and a list of Contacts returned, each providing a URL to use in the outgoing request.

The Cisco SIP Proxy Server translation modules, in the order that they are called, are as follows:

•Call Forward Unconditional (mod_sip_call_forward)

•Registry (mod_sip_registry)

•ENUM (mod_sip_enum)

•GKTMP (mod_sip_gktmp)

The first module to return a Contact or Contacts completes the translation step and the remaining modules are not called. For example, if the Registry module returns a Contact, then neither the ENUM or GKTMP module are called. If none of the translation modules returns a Contact, the core proxy module (mod_sip) returns a Contact based on the incoming Request-URI and that Request-URI is used in the next hop routing step.

Next Hop Routing

This step in SIP request processing is to determine the next hop (next hop routing). Next hop routing takes each translated Request-URI and locates a set of next hop SIP entities capable of routing to the new Request-URI. This step involves two features outlined as follows.

•SRV Lookup for Static Route

Previously, only Simple DNS `A' lookup on the Static_Route_NextHopPort field of a static route was available. If the Static_Route_NextHopPort field of a static route is not specified or is zero, this enhancement allows the Cisco SIP Proxy Server to perform SRV lookup on the Static_Route_NextHop field.

•H.323 RAS module

The RAS module allows communications between a SIP proxy server and a H.323 gatekeeper. Cisco SIP Proxy Server can send ASN.1 encoded RAS LRQ message to a H.323 gatekeeper which responds with a RAS LCF message. The following diagram illustrates how the proxy server sends a LRQ H.225 RAS message to a gatekeeper which responds with a LCF message that can contain a gateway transport address.

Figure 1-2 Cisco SIP Proxy Server and H.323 gatekeeper Message Processing

This modules supports the following:

–H.323 RIP (Request in Progress) message—This message contains a time-delay value. Upon receipt of this message, the Cisco SIP Proxy Server resets its timer and wait for the final response from the gatekeeper.

–Directory gatekeeper—This gatekeeper forwards requests to the other gatekeepers and return the highest priority and lowest cost gateway information to the requesting endpoint. Value of the TTL (time-to-live) field in the LRQ message must be greater than zero. The default is 6 hops.

–Sequential LRQ—The Cisco SIP Proxy Server can send LRQ request sequentially based on the priority specified for the gatekeeper clusters in sipd.conf file. Configurable parameters include the following.

•Timeout value for each individual request

•Total LRQ request window

•Whether to wait for the best LCF within the LRQ time window or to return the first valid LCF response to the proxy server.

–Blast LRQ—The Cisco SIP Proxy Server can send LRQ requests to all gatekeeper clusters before listening to the responses from the gatekeepers. It can also be configured to either take the first valid LCF response or wait for the best response within the LRQ time window.

–Multi-alternate endpoint—If the selected LCF from a gatekeeper contains alternate endpoints, the Cisco SIP Proxy Server can parse these endpoints and store them in the route table. The routes in the alternate endpoints have lower priority than the route for the primary endpoint.

–Redundant gatekeeper—This can be configured by maintaining a list of prioritized gatekeeper clusters in the Cisco SIP Proxy Server configuration. Once this is configured, the following trial process takes place.

•The proxy server tries one of the gatekeepers randomly in the cluster which has the highest priority or lowest cost.

•If this trial expires the timeout value specified in the RASTimeoutInterval directive, the proxy server tries the next gatekeeper in the same cluster in a round-robin manner.

•If LRJ message is received by the proxy server, it tries a gatekeeper in the next highest priority cluster and so forth.

The following diagram illustrates the configuration.

See also directive RASGateKeeperCluster in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9.

–Tech prefix—The Cisco SIP Proxy Server prepends the technology prefix (one, two or three digits + `#') to the expanded dialed number to the LRQ request. It can also be included in the Request-URI of the INVITE message forwarded to the SIP/H.323 gateway. Multiple technology prefixes can be configured in the sipd.conf file based on the expanded dialed number.

See directive RASTechPrefix in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9.

–Pavo extension—Cisco SIP Proxy Server can include Pavo extensions (CallIdentifier, RedirectIEInfo, CallingOctet3a) in the LRQ from the CC-Diversion header of the incoming INVITE message.

To locate the next hop SIP entities, the following actions take place:

•If the host portion of the new Request-URI is the address (FQDN or IP address) of the server itself, the next hop routing is performed using the user portion of the Request-URI.

E164 routing is an implementation of this method.

•If the Static_Route_NextHopPort field of a static route is not specified or has the value of 0, the Cisco SIP Proxy Server tries to do SRV lookup on the Static_Route_NextHop field.

If this lookup is successful, the algorithm outlined in RFC 2782 will be used to select one destination. If this lookup fails, alternate destinations will be tried and the proxy will do simple DNS `A' lookup on the Static_Route_NextHop field of the static route. This field should contain a name for the `A' lookup.

•If no route is found in the E164 routing, RAS LRQ message is sent by the Cisco SIP Proxy Server to the H.323 gatekeeper cluster which is identified to have the highest priority and lowest cost gateway.

According to configurations and availability of the gatekeepers being contacted, one of the following messages is returned before the time limit in the configured timeout window expires. For reference, see directives RASTimeoutInterval and RASLRQWindow in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9.

–LCF (Location Confirm)

–LRJ (Location Reject)

–RIP (Response in Progress)

The RIP message is activated when the gatekeeper cluster is connected to a remote gatekeeper (by UDP). This is related to the number of hops to be attempted. For reference, see directive RASTimeToLive in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9.

•If the host portion of the new Request-URI is NOT the address (FQDN or IP address) of the server itself, the routing is performed using the host portion of the Request-URI.

Domain routing and next hop routing via DNS SRV are implementations of this method.

IP Resolution

This step in processing SIP requests is to convert each next hop found via next hop routing into an IP address. Standard IP resolution (via gethostbyname) is performed via DNS, NIS, NIS+, or host file; depending on the IP resolution subsystem configured on your proxy.

For more information on configuring directives pertaining to address translation and routing, see the "Configuring Cisco SIP Module Standard Directives" section on page 3-9.

Authentication, Authorization

The Cisco SIP Server can be configured to provide authentication and authorization. The authentication can take place either at a Radius Server or at the Proxy. Three types of authentication are supported by the Proxy in conjunction with the appropriate Radius Server:

•CHAP-Password Authentication

•HTTP DigestAuthentication

•HTTP Basic Authentication

HTTP Digest Authentication and HTTP Basic Authentication are supported by the Proxy.

Radius is an IETF protocol based on UDP. It functions by exchanging a set of attribute/value pairs between the client and server. For example, a Cisco SIP Proxy Server acting as a Radius client exchanges attribute/value pairs with a Radius Server to provide authentication.

For Radius supported authentication, the UAC password is stored at the Radius Server. For Proxy supported authentication, the UAC password is stored in a subscriber table in a MySQL database.

Authentication

The default authentication scheme is the HTTP Digest Authentication performed at the Cisco SIP Proxy Server. HTTP Digest Authentication and HTTP Basic Authentication are performed as described in RFC 2617.

When Digest Authentication and Basic Authentication are used at the Proxy, these schemes use the Username as found in the Authorization Header or the Proxy-Authorization Header as the key to query the MySQL database.

If the authentication takes place at the Radius Server, the Username is passed as one of the attribute/value pairs from the Cisco SIP Proxy Server to the Radius Server where it can be used to key the User Search, before performing authentication.

The CHAP-Password Authentication scheme is supported only on the Radius Server. The Username is passed as one of the attribute/value pairs from the Cisco SIP Proxy Server to the Radius Server where the Radius Server performs authentication.

The UserName may be expanded by the Cisco SIP Proxy Server before performing the MYSQL lookup, or before it is passed to the Radius Server. This enables phone numbers to be expanded to fully expanded E164 numbers before processing.

Authorization

An authenticated user is authorized. Currently, there is no authorization of specific user capabilities for the service provider voice applications.

Accounting

The Cisco SIP Server can be configured to provide accounting services via a Radius server. When accounting is configured, it ensures that Call Detail Records (CDR) generated during calls are logged on a Radius accounting server as described in RFC 2159.

Accounting uses a basic start-stop method and standard RADIUS attributes where possible. When the accounting services are enabled and the interface to the Radius server is configured, the Cisco SIP Proxy Server will create and send the Accounting records to the Radius server described as follows.

•The start record is written when a 200 OK is received by the Cisco SIP Proxy Server for an INVITE.

•The stop record is written only when BYE is received by the Cisco SIP Proxy Server.

Server Farm Support

A server farm is a group of Cisco SIP Proxy Servers that share database information; providing redundancy and high availability. When the members of a farm are defined, all updates to a member's database is replicated across every member of the farm. During replication, any member of the farm that is out of synch with the other members, will resychronize.

A farm is a group of Cisco SIP Proxy Servers that share database information. This database information can be routing, registry, or number services database information. Database information is shared by mirroring all updates to databases for all members of the farm and by keeping the databases synchronized.

By default, a farm is created for the routing, registry, and number services databases. To configure a farm, the names of the members of the farm and the ports at which to lock and update the farm members is required.

IP Security

IP Security (IPSec) provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets between participating IPSec devices (peers), such as the Cisco SIP Proxy Server and a UAC, SIP gateway, or another Cisco SIP Proxy Server. With IPSec, data can be transmitted across a public network without fear of observation, modification, or spoofing.

All IPSec combinations have been successfully tested and proven to secure traffic to and from the Cisco SIP Proxy Server on the following platforms:

•Solaris 2.8 Operating Environment (via manually-keyed key management method)

•Redhat Linux 6.2 (Kernel 2.2.14-5.0) with Linux FreeS/WAN Release 1.5 (via manually-keyed and Internet Key Exchange (IKE) key management methods)

Access and Error Logging

The Cisco SIP Server uses the standard Apache logging functionality in addition to a SIP-specific logging functionality. The standard Apache logging functionality is defined for the Cisco SIP Proxy Server as a whole, while the SIP logging functionality can be configured on a per-module basis.

By default, internal Cisco SIP Proxy Server errors are logged to /usr/local/sip/logs/error_log (on Linux) and /opt/sip/logs/error_log (on Solaris). Access records are logged to /usr/local/sip/logs/access_log (on Linux) and /opt/sip/logs/access_log (on Solaris). Cisco SIP Proxy Server logging and additional functions specific to logging (for example, rotating logs), are configured via configuration file directives. For information on configuring configuration file directives, see Chapter 3, "Configuring the Cisco SIP Proxy Server."

Log rotation and size are per standard apache. For information on Apache and Apache logs, see www.apache.org.

Requirements

The Cisco SIP Proxy Server can be run on either a Solaris or Linux platform. The following sections list the minimum hardware and software requirements for each platform. Before installing and configuring the Cisco SIP Proxy Server, one of these requirements must be met.

For a list of Cisco supported platforms, see the Cisco SIP Proxy Server Release Note.

Solaris Platform Requirements

If you are implementing the Cisco SIP Proxy Server on Solaris, the following is required:

•Workstation—Sparc or UltraSparc server class machine with a minimum of 256 MB of RAM and 1 GB of disk space.

•Solaris™ 2.6 Operating Environment or later

•For IPSec:

–Solaris 2.8 Operating Environment or later

–Authentication and Data Encryption—By default, Authentication can be used when Solaris Solaris 2.8 Operating Environment is installed. Data Encryption is available on a Solaris supplemental CD.

Linux Platform Requirements

If you are implementing the Cisco SIP Proxy Server on Linux, the following is required:

•PC—Intel Pentium III processor operating with a minimum of 128 MB of RAM and 1 GB of disk space.

•Linux Kernel 2.2.13 or later

•For IPSec, Linux FreeS/WAN with Redhat Linux (refer to www.freeswan.org for the latest implementation of Linux FreeS/WAN IPSec and its targeted Redhat Linux version).

Related Documentation

The following is a list of related Cisco SIP VoIP publications. For more information about implementing a SIP VoIP network, refer to the following publications:

•Cisco SIP IP Phone 7960 Administrator Guide

•Getting Started Cisco 7960 IP Phone

•Enhancements for the Session Initiation Protocol for VoIP on Cisco Access Platforms

•Session Initiation Protocol Gateway Call Flows

•Cisco IOS Multiservice Applications Command Reference

•Cisco IOS Multiservice Applications Configuration Guide

Reference Links

The following is a list of links to the websites of companies or to additional information on technologies referenced within the Cisco SIP Proxy Server software and documentation:

•www.apache.org

•www.mysql.com

•www.sun.com

•www.linux.org

•www.cs.wustl.edu/~schmidt/ACE.html

•www.redhat.com

•www.freeswan.org

	Cisco SIP Proxy Server Version 1.2 Administrator Guide
	Product Overview
Cisco SIP Proxy Server Version 1.2 Administrator Guide CD Installation Guide for the Cisco SIP Proxy Server Version 1.2 on Linux CD Installation Guide for the Cisco SIP Proxy Server Version 1.2 on Solaris About This Guide Product Overview Installing MySQL Subscriber Database Configuring the Cisco SIP Proxy Server Maintaining the Cisco SIP Proxy Server System Administration Tools Cisco SIP Proxy Server Compliance Information Cisco SIP Proxy Server Call Flows Accounting Services Record Attributes Glossary	Download this chapter Product Overview Table Of Contents Product Overview What is SIP? Components of SIP SIP Clients SIP Servers What is the Cisco SIP Proxy Server? Features Server Modes Protocol Support Spiralled and Looped Request Detection Address Translation, Routing, and IP Resolution Authentication, Authorization Accounting Server Farm Support IP Security Access and Error Logging Requirements Solaris Platform Requirements Linux Platform Requirements Related Documentation Reference Links Product Overview This chapter provides an overview of the Cisco SIP Proxy Server, its features, and prerequisites. This chapter contains the following sections: •What is SIP? •What is the Cisco SIP Proxy Server? •Requirements •Related Documentation What is SIP? Session Initiation Protocol (SIP) is the Internet Engineering Task Force's (IETF's) standard for multimedia conferencing over IP. SIP is an ASCII-based, application-layer control protocol (defined in RFC 2543) that can be used to establish, maintain, and terminate calls between two or more end points. Like other VoIP protocols, SIP is designed to address the functions of signaling and session management within a packet telephony network. Signaling allows call information to be carried across network boundaries. Session management provides the ability to control the attributes of an end-to-end call. SIP provides the capabilities to: •Determine the location of the target end point—SIP supports address resolution, name mapping, and call redirection. •Determine the media capabilities of the target end point—Via Session Description Protocol (SDP), SIP determines the "lowest level" of common services between the end points. Conferences are established using only the media capabilities that can be supported by all end points. •Determine the availability of the target end point—If a call cannot be completed because the target end point is unavailable, SIP determines whether the called party is already on the phone or did not answer in the allotted number of rings. It then returns a message indicating why the target end point was unavailable. •Establish a session between the originating and target end point—If the call can be completed, SIP establishes a session between the end points. SIP also supports mid-call changes, such as the addition of another end point to the conference or the changing of a media characteristic or codec. •Handle the transfer and termination of calls—SIP supports the transfer of calls from one end point to another. During a call transfer, SIP simply establishes a session between the transferee and a new end point (specified by the transferring party) and terminates the session between the transferee and the transferring party. At the end of a call, SIP terminates the sessions between all parties. Conferences can consist of two or more users and can be established using multicast or multiple unicast sessions. Note The term conference means an established session (or call) between two or more end points. In this document, the terms conference and call are used interchangeably. Components of SIP 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 that returns a response on behalf of the user. Typically, a SIP end point is capable of functioning as both a UAC and a UAS, but 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 architecture standpoint, the physical components of a SIP network can be grouped into two categories: clients and servers. Figure 1-1 illustrates the architecture of a SIP network. Note In addition, the SIP servers can interact with other application services, such as Lightweght Directory Access Protocol (LDAP) servers, location servers, a database application, or an extensible markup language (XML) application. These application services provide back-end services such as directory, authentication, and billing services. Figure 1-1 SIP Architecture SIP Clients SIP clients include: •Phones—Can act as either a UAS or UAC. Softphones (PCs that have phone capabilities installed) and Cisco SIP IP phones can initiate SIP requests and respond to requests. •Gateways—Provide call control. Gateways provide many services, the most common being a translation function between SIP conferencing endpoints and other terminal types. This function includes translation between transmission formats and between communications procedures. In addition, the gateway also translates between audio and video codecs and performs call setup and clearing on both the LAN side and the switched-circuit network side. SIP Servers SIP servers include: •Proxy server—The proxy server is 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. •Redirect server—Provides the client with information about the next hop or hops that a message should take and then 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. What is the Cisco SIP Proxy Server? The Cisco SIP Proxy Server Version 1.1 provides the primary capabilities required for call session management in a VoIP network and processes SIP requests and responses as described in RFC 2543. Powered by Apache, the Cisco SIP Proxy Server can be configured to operate as a transaction stateful or stateless server. The Cisco SIP Proxy Server can also be configured to provide additional server modes and features. For example, the Cisco server can be configured to: •Function as a redirect or registrar server •Translate E.164 numbers to URL via location server protocols such as Telephone Number Mapping (ENUM) •Perform gateway and Domain Name System (DNS) routing Note This Cisco SIP Proxy Server includes software developed by the Apache Software Foundation (http://www.apache.org/). Features The Cisco SIP Proxy Server offers the following features: •Ability to function as a transaction stateful or stateless proxy server, stateful or stateless redirect server, and registrar server •Call forwarding •CLI Tools for: –routing and registry databases –MySQL subscriber databases •Ability to distinguish spiralled requests from looped requests •Address translation –Registry database (static registry entries for contact points) –Gatekeeper Transaction Message Protocol (GKTMP) interface with Cisco NAM for 1-800, 1-900, and LNP lookups as well as least-cost routing –E.164 to URL address translation (via location server protocols such as ENUM and GKTMP) •Next-hop routing –Static E.164 routes (dial plans) •SRV lookup for static route –RAS module that allows communications between a Cisco SIP proxy server and a H.323 directory gatekeeper –Static domain routes –DNS SRV routes •Authentication and authorization via HTTP (Hypertext Transfer Protocol) Digest or HTTP Basic and MySQL, or via HTTP Basic or CHAP-password and Radius. •Accouting via Radius •Server farm support for sharing database information (registry, routing, and special number services databases) •SIP over User Datagram Protocol (UDP) transport protocol support •Interoperability with Cisco SIP gateways, SIP IP phones, and unified messaging •IP security (IPSec) for SIP signaling messages •Access and error logging Server Modes The Cisco SIP Proxy Server can be configured to function as one of the following types of servers: •Transaction stateful or stateless proxy server The Cisco SIP Proxy Server can operate as a transaction stateful or stateless proxy server. When configured to be a stateful proxy server, the proxy server creates a transaction control block (TCB) and remembers incoming and outgoing requests, providing reliable retransmission of proxied requests and returning the best final response or responses back upstream. One transaction encompasses the received request, the request or requests (if forked) forwarded downstream, responses received from downstream hosts, and the best response returned upstream. When configured to be a stateless proxy server, the Cisco SIP Proxy Server forgets all information once a request or response has been processed. As a stateless proxy server, the Cisco SIP Proxy Server will just forward requests and responses. The Cisco SIP Proxy Server also performs functions such as authentication, authorization, and security. •Transaction stateful or stateless redirect server As a redirect server, the Cisco SIP Proxy Server accepts SIP requests, maps the address in the Request-URI to zero or more new addresses, and returns these addresses as Contacts in a SIP 3xx response to the UAC. When configured as a stateless redirect server, the Cisco SIP Proxy Server does not create a TCB on receiving an INVITE request. The Cisco SIP Proxy Server is configured to function as a redirect or proxy server for all calls (globally), however, this default functionality can be changed via the optional Action parameter included in the Contact header of a Register request. If an action parameter is given in a Register request, the Cisco SIP Proxy Server will function as specified by that parameter. If no action parameters is given in the Registration request, the Cisco SIP Proxy Server will function as configured. The Action parameter specification is honored when the UseCallerPreferences directive is set to On in the sipd.conf file. •Registrar server As a registrar server, the Cisco SIP Proxy Server processes requests from UACs for registration of their current location. The Cisco SIP Proxy Server also maintains registration information and can share this information with other registrar servers in its farm. As a registrar server, the Cisco SIP Proxy Server provides location services to the proxy server. Note In Version 1.1 of the Cisco SIP Proxy Server, registrar servers also must be configured to function as either a proxy or redirect server. Standalone registrar servers are not supported. For more information on configuring server modes, see the Configuring the Cisco SIP Proxy Server Core Configuration Section. Protocol Support The Cisco SIP Proxy Server supports the following network and transport protocols: •Internet Protocol (IP) IP is a network layer protocol that sends datagram packets between nodes on the Internet. IP also provides features for addressing, type-of-service (ToS) specification, fragmentation and reassembly, and security. The Cisco SIP Proxy Server supports IP as it is defined in RFC 791. •User Datagram Protocol (UDP) UDP is a simple protocol that exchanges data packets without acknowledgments or guaranteed delivery. SIP can use UDP as the underlying transport protocol. With UDP, retransmissions are used to ensure reliability. The Cisco SIP Proxy Server supports UDP as it is defined in RFC 768 for SIP signaling. •Domain Name System (DNS) DNS is used in the Internet for translating names of network nodes into addresses. SIP uses DNS to resolve the host names of end points to IP addresses. •Session Description Protocol (SDP) SDP is an ASCII-based protocol that describes multimedia sessions and their related scheduling information. The Cisco SIP IP phone uses SDP for session description. Spiralled and Looped Request Detection A spiralled request is a request that re-visits the Cisco SIP Proxy Server with a new request-uri and is considered a new transaction by the proxy. A looped request is a request that contains the proxy's via header and the request-uri is the same as it was when it first visited the proxy. At the proxy, this capability has the following effects. •Allows the same call to be logged more than once •May cause invocation of different features •If Record-Route field in the INVITE message is enabled at the proxy, Record-Route procedure will be performed more than once. Note The Call-ID, From, To and CSeq.seqnum fields of a spiralled request are the same as that of the request which visited the proxy the first time. Address Translation, Routing, and IP Resolution The following steps are performed by the Cisco SIP Proxy Server to deliver messages from endpoint to endpoint: 1. Translation—Process of translating an incoming Request-URI into an outgoing Request-URI. 2. Next hop routing—Process of obtaining a set of Fully Qualified Domain Names (FQDNs) or IP addresses with port numbers for each of the SIP entities found in the translation step. Among others, this step involves the following features. a. SRV lookup for static route—Process of a SRV lookup on the Static_Route_NextHop field if the Static_Route_NextHopPort field in a static route is not specified or is zero. b. RAS LRQ message transmission to gatekeeper—Process of sending the LRQ message to the H.323 gatekeeper to obtain the next hop gateway transport address. 3. IP resolution—Process of converting each next hop found in the next hop route lookup step into an IP address. Note If a Route header is present in the SIP request message, the Cisco SIP Proxy Server translation and next hop routing functions are bypassed. Record-Route must be enabled on the server for subsequent requests to contain a route header. Translation During the translation step, the Request-URI of an incoming request is processed and a list of Contacts returned, each providing a URL to use in the outgoing request. The Cisco SIP Proxy Server translation modules, in the order that they are called, are as follows: •Call Forward Unconditional (mod_sip_call_forward) •Registry (mod_sip_registry) •ENUM (mod_sip_enum) •GKTMP (mod_sip_gktmp) The first module to return a Contact or Contacts completes the translation step and the remaining modules are not called. For example, if the Registry module returns a Contact, then neither the ENUM or GKTMP module are called. If none of the translation modules returns a Contact, the core proxy module (mod_sip) returns a Contact based on the incoming Request-URI and that Request-URI is used in the next hop routing step. Next Hop Routing This step in SIP request processing is to determine the next hop (next hop routing). Next hop routing takes each translated Request-URI and locates a set of next hop SIP entities capable of routing to the new Request-URI. This step involves two features outlined as follows. •SRV Lookup for Static Route Previously, only Simple DNS `A' lookup on the Static_Route_NextHopPort field of a static route was available. If the Static_Route_NextHopPort field of a static route is not specified or is zero, this enhancement allows the Cisco SIP Proxy Server to perform SRV lookup on the Static_Route_NextHop field. •H.323 RAS module The RAS module allows communications between a SIP proxy server and a H.323 gatekeeper. Cisco SIP Proxy Server can send ASN.1 encoded RAS LRQ message to a H.323 gatekeeper which responds with a RAS LCF message. The following diagram illustrates how the proxy server sends a LRQ H.225 RAS message to a gatekeeper which responds with a LCF message that can contain a gateway transport address. Figure 1-2 Cisco SIP Proxy Server and H.323 gatekeeper Message Processing This modules supports the following: –H.323 RIP (Request in Progress) message—This message contains a time-delay value. Upon receipt of this message, the Cisco SIP Proxy Server resets its timer and wait for the final response from the gatekeeper. –Directory gatekeeper—This gatekeeper forwards requests to the other gatekeepers and return the highest priority and lowest cost gateway information to the requesting endpoint. Value of the TTL (time-to-live) field in the LRQ message must be greater than zero. The default is 6 hops. –Sequential LRQ—The Cisco SIP Proxy Server can send LRQ request sequentially based on the priority specified for the gatekeeper clusters in sipd.conf file. Configurable parameters include the following. •Timeout value for each individual request •Total LRQ request window •Whether to wait for the best LCF within the LRQ time window or to return the first valid LCF response to the proxy server. –Blast LRQ—The Cisco SIP Proxy Server can send LRQ requests to all gatekeeper clusters before listening to the responses from the gatekeepers. It can also be configured to either take the first valid LCF response or wait for the best response within the LRQ time window. –Multi-alternate endpoint—If the selected LCF from a gatekeeper contains alternate endpoints, the Cisco SIP Proxy Server can parse these endpoints and store them in the route table. The routes in the alternate endpoints have lower priority than the route for the primary endpoint. –Redundant gatekeeper—This can be configured by maintaining a list of prioritized gatekeeper clusters in the Cisco SIP Proxy Server configuration. Once this is configured, the following trial process takes place. •The proxy server tries one of the gatekeepers randomly in the cluster which has the highest priority or lowest cost. •If this trial expires the timeout value specified in the RASTimeoutInterval directive, the proxy server tries the next gatekeeper in the same cluster in a round-robin manner. •If LRJ message is received by the proxy server, it tries a gatekeeper in the next highest priority cluster and so forth. The following diagram illustrates the configuration. See also directive RASGateKeeperCluster in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9. –Tech prefix—The Cisco SIP Proxy Server prepends the technology prefix (one, two or three digits + `#') to the expanded dialed number to the LRQ request. It can also be included in the Request-URI of the INVITE message forwarded to the SIP/H.323 gateway. Multiple technology prefixes can be configured in the sipd.conf file based on the expanded dialed number. See directive RASTechPrefix in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9. –Pavo extension—Cisco SIP Proxy Server can include Pavo extensions (CallIdentifier, RedirectIEInfo, CallingOctet3a) in the LRQ from the CC-Diversion header of the incoming INVITE message. To locate the next hop SIP entities, the following actions take place: •If the host portion of the new Request-URI is the address (FQDN or IP address) of the server itself, the next hop routing is performed using the user portion of the Request-URI. E164 routing is an implementation of this method. •If the Static_Route_NextHopPort field of a static route is not specified or has the value of 0, the Cisco SIP Proxy Server tries to do SRV lookup on the Static_Route_NextHop field. If this lookup is successful, the algorithm outlined in RFC 2782 will be used to select one destination. If this lookup fails, alternate destinations will be tried and the proxy will do simple DNS `A' lookup on the Static_Route_NextHop field of the static route. This field should contain a name for the `A' lookup. •If no route is found in the E164 routing, RAS LRQ message is sent by the Cisco SIP Proxy Server to the H.323 gatekeeper cluster which is identified to have the highest priority and lowest cost gateway. According to configurations and availability of the gatekeepers being contacted, one of the following messages is returned before the time limit in the configured timeout window expires. For reference, see directives RASTimeoutInterval and RASLRQWindow in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9. –LCF (Location Confirm) –LRJ (Location Reject) –RIP (Response in Progress) The RIP message is activated when the gatekeeper cluster is connected to a remote gatekeeper (by UDP). This is related to the number of hops to be attempted. For reference, see directive RASTimeToLive in Configuring E.164 to Request-URI Address Translation in Configuring Cisco SIP Module Standard Directives, page 3-9. •If the host portion of the new Request-URI is NOT the address (FQDN or IP address) of the server itself, the routing is performed using the host portion of the Request-URI. Domain routing and next hop routing via DNS SRV are implementations of this method. IP Resolution This step in processing SIP requests is to convert each next hop found via next hop routing into an IP address. Standard IP resolution (via gethostbyname) is performed via DNS, NIS, NIS+, or host file; depending on the IP resolution subsystem configured on your proxy. For more information on configuring directives pertaining to address translation and routing, see the "Configuring Cisco SIP Module Standard Directives" section on page 3-9. Authentication, Authorization The Cisco SIP Server can be configured to provide authentication and authorization. The authentication can take place either at a Radius Server or at the Proxy. Three types of authentication are supported by the Proxy in conjunction with the appropriate Radius Server: •CHAP-Password Authentication •HTTP DigestAuthentication •HTTP Basic Authentication HTTP Digest Authentication and HTTP Basic Authentication are supported by the Proxy. Radius is an IETF protocol based on UDP. It functions by exchanging a set of attribute/value pairs between the client and server. For example, a Cisco SIP Proxy Server acting as a Radius client exchanges attribute/value pairs with a Radius Server to provide authentication. For Radius supported authentication, the UAC password is stored at the Radius Server. For Proxy supported authentication, the UAC password is stored in a subscriber table in a MySQL database. Authentication The default authentication scheme is the HTTP Digest Authentication performed at the Cisco SIP Proxy Server. HTTP Digest Authentication and HTTP Basic Authentication are performed as described in RFC 2617. When Digest Authentication and Basic Authentication are used at the Proxy, these schemes use the Username as found in the Authorization Header or the Proxy-Authorization Header as the key to query the MySQL database. If the authentication takes place at the Radius Server, the Username is passed as one of the attribute/value pairs from the Cisco SIP Proxy Server to the Radius Server where it can be used to key the User Search, before performing authentication. The CHAP-Password Authentication scheme is supported only on the Radius Server. The Username is passed as one of the attribute/value pairs from the Cisco SIP Proxy Server to the Radius Server where the Radius Server performs authentication. The UserName may be expanded by the Cisco SIP Proxy Server before performing the MYSQL lookup, or before it is passed to the Radius Server. This enables phone numbers to be expanded to fully expanded E164 numbers before processing. Authorization An authenticated user is authorized. Currently, there is no authorization of specific user capabilities for the service provider voice applications. Accounting The Cisco SIP Server can be configured to provide accounting services via a Radius server. When accounting is configured, it ensures that Call Detail Records (CDR) generated during calls are logged on a Radius accounting server as described in RFC 2159. Accounting uses a basic start-stop method and standard RADIUS attributes where possible. When the accounting services are enabled and the interface to the Radius server is configured, the Cisco SIP Proxy Server will create and send the Accounting records to the Radius server described as follows. •The start record is written when a 200 OK is received by the Cisco SIP Proxy Server for an INVITE. •The stop record is written only when BYE is received by the Cisco SIP Proxy Server. Server Farm Support A server farm is a group of Cisco SIP Proxy Servers that share database information; providing redundancy and high availability. When the members of a farm are defined, all updates to a member's database is replicated across every member of the farm. During replication, any member of the farm that is out of synch with the other members, will resychronize. A farm is a group of Cisco SIP Proxy Servers that share database information. This database information can be routing, registry, or number services database information. Database information is shared by mirroring all updates to databases for all members of the farm and by keeping the databases synchronized. By default, a farm is created for the routing, registry, and number services databases. To configure a farm, the names of the members of the farm and the ports at which to lock and update the farm members is required. IP Security IP Security (IPSec) provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets between participating IPSec devices (peers), such as the Cisco SIP Proxy Server and a UAC, SIP gateway, or another Cisco SIP Proxy Server. With IPSec, data can be transmitted across a public network without fear of observation, modification, or spoofing. All IPSec combinations have been successfully tested and proven to secure traffic to and from the Cisco SIP Proxy Server on the following platforms: •Solaris 2.8 Operating Environment (via manually-keyed key management method) •Redhat Linux 6.2 (Kernel 2.2.14-5.0) with Linux FreeS/WAN Release 1.5 (via manually-keyed and Internet Key Exchange (IKE) key management methods) Access and Error Logging The Cisco SIP Server uses the standard Apache logging functionality in addition to a SIP-specific logging functionality. The standard Apache logging functionality is defined for the Cisco SIP Proxy Server as a whole, while the SIP logging functionality can be configured on a per-module basis. By default, internal Cisco SIP Proxy Server errors are logged to /usr/local/sip/logs/error_log (on Linux) and /opt/sip/logs/error_log (on Solaris). Access records are logged to /usr/local/sip/logs/access_log (on Linux) and /opt/sip/logs/access_log (on Solaris). Cisco SIP Proxy Server logging and additional functions specific to logging (for example, rotating logs), are configured via configuration file directives. For information on configuring configuration file directives, see Chapter 3, "Configuring the Cisco SIP Proxy Server." Log rotation and size are per standard apache. For information on Apache and Apache logs, see www.apache.org. Requirements The Cisco SIP Proxy Server can be run on either a Solaris or Linux platform. The following sections list the minimum hardware and software requirements for each platform. Before installing and configuring the Cisco SIP Proxy Server, one of these requirements must be met. For a list of Cisco supported platforms, see the Cisco SIP Proxy Server Release Note. Solaris Platform Requirements If you are implementing the Cisco SIP Proxy Server on Solaris, the following is required: •Workstation—Sparc or UltraSparc server class machine with a minimum of 256 MB of RAM and 1 GB of disk space. •Solaris™ 2.6 Operating Environment or later •For IPSec: –Solaris 2.8 Operating Environment or later –Authentication and Data Encryption—By default, Authentication can be used when Solaris Solaris 2.8 Operating Environment is installed. Data Encryption is available on a Solaris supplemental CD. Linux Platform Requirements If you are implementing the Cisco SIP Proxy Server on Linux, the following is required: •PC—Intel Pentium III processor operating with a minimum of 128 MB of RAM and 1 GB of disk space. •Linux Kernel 2.2.13 or later •For IPSec, Linux FreeS/WAN with Redhat Linux (refer to www.freeswan.org for the latest implementation of Linux FreeS/WAN IPSec and its targeted Redhat Linux version). Related Documentation The following is a list of related Cisco SIP VoIP publications. For more information about implementing a SIP VoIP network, refer to the following publications: •Cisco SIP IP Phone 7960 Administrator Guide •Getting Started Cisco 7960 IP Phone •Enhancements for the Session Initiation Protocol for VoIP on Cisco Access Platforms •Session Initiation Protocol Gateway Call Flows •Cisco IOS Multiservice Applications Command Reference •Cisco IOS Multiservice Applications Configuration Guide Reference Links The following is a list of links to the websites of companies or to additional information on technologies referenced within the Cisco SIP Proxy Server software and documentation: •www.apache.org •www.mysql.com •www.sun.com •www.linux.org •www.cs.wustl.edu/~schmidt/ACE.html •www.redhat.com •www.freeswan.org
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks