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?
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 highest 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 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 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 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/).
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
•CLI Tools for:
–routing and registry databases
–MySQL subscriber databases
•Ability to distinguish spiralled requests from looped requests
–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)
–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 and routing 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
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 access control.
•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.
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 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 Configuring the Cisco SIP Module Core Directives, page 3-5.
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. The resolution may include DNS SRV and DNS A records.
•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.
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)
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 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
If the Static_Route_NextHopPort field of a static route is not specified or is zero, the Cisco SIP Proxy Server performs an 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 waits for the final response from the gatekeeper.
–Directory gatekeeper—This gatekeeper forwards requests to the other gatekeepers and returns 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 requests sequentially based on the priority specified for the gatekeeper clusters in sipd.conf file. Configurable parameters include timeout value for each individual request, total LRQ request window, and 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. 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" section on page 3-17.
–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" section on page 3-17.
–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.
E.164 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 E.164 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 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" section on page 3-17.
–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" section on page 3-17.
•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.
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 "Configuring E.164 to Request-URI Address Translation" section on page 3-17.
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:
•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.
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 E.164 numbers before processing.
The Cisco SIP Proxy Server provides access control lists and user authentication which can be combined to provide more complex access control. Based on Apache access control mechanism, some SIP devices such as SIP gateways, do not authenticate themselves. They may be specified in the access control list, and instruct the Cisco SIP Proxy Server to accept INVITEs from them.
REGISTERs and INVITEs from other devices may be challenged by the Cisco SIP Proxy Server for user authentication. This is configurable.
An authenticated user is authorized. Currently, there is no authorization of specific user capabilities for the service provider voice applications.
The Cisco SIP Server uses basic start-stop records with a combination of standard attributes and Cisco VSAs. The 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 when BYE is received by the Cisco SIP Proxy Server.
Note The Cisco SIP Server receives the BYE only if Record-Route is enabled. Configuring the Cisco SIP Module Core Directives, page 3-5.
Server Farm Support
A server farm is a group of Cisco SIP Proxy Servers that share database information, provide redundancy and high availability. When the members of a farm are defined, all updates to a member database are 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.
The shared 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 and registry 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 (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 7.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.
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 the following sets of 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.8 Operating Environment
–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.
•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).
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
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: