SIP Network Overview
Revised: October 30, 2012, OL-12397-18
This guide describes the Session Initiation Protocol (SIP) signaling features supported in Release 5.0 of the Cisco BTS 10200 Softswitch, and explains how to provision them.
Note In this document, the term "SIP devices" includes SIP phones and softclients that act as a SIP user agent (UA) to originate and terminate calls for an address of record (AOR) identity.
This chapter contains an overview of the SIP network and includes the following sections:
•General SIP Overview
•SIP Functions Performed by the BTS 10200
General SIP Overview
The SIP support features are built on the existing BTS 10200 software and hardware platform. The BTS 10200 includes a Call Agent (CA), Feature Server (FS), Element Management System (EMS), and Bulk Data Management System (BDMS). In this book, use of the term "BTS 10200" indicates the Call Agent unless otherwise specified.
SIP support for subscriber features is provided by the Call Agent and the POTS Feature Server.
The BTS 10200 uses SIP and SIP for telephones (SIP-T) signaling to communicate with other SIP-based network elements. The implementation is based upon the evolving industry standards for SIP, including IETF document RFC 3261, SIP: Session Initiation Protocol. The BTS 10200 supports both SIP trunks and SIP-based subscriber lines (SIP devices), and provides the following SIP-related functions:
•Protocol conversion between SIP and several other protocols, including SS7, PRI, ISDN, H.323, MGCP, and CAS.
•Tandem back-to-back user agent for direct SIP-to-SIP calls (trunk to trunk, phone to phone, and trunk to/from phone), and SIP-to-SIP-T calls.
•SS7 bridging between softswitches using SIP-T methods.
•Native support of SIP endpoints such as SIP phones, including authentication and registration management. (For example, the BTS 10200 maintains the current location of SIP subscribers.)
The BTS 10200 provides billing data for SIP calls. Specific fields are supported in the call detail records for calls that originate or terminate on a SIP trunk or subscriber. For detailed information on these fields, including billing management and data, refer to the Cisco BTS 10200 Softswitch Billing Interface Guide.
The BTS 10200 SIP implementation is based on the evolving standards in the Internet Engineering Task Force (IETF) Request for Comments (RFC) publications, including the documents in the following list, and may not be fully compliant in all cases. The BTS 10200 is largely compliant with RFC 3261. For the level of compliance with all other RFC publications and drafts referenced in this document, see the specific feature descriptions.
•RFC 2617, HTTP Authentication
•RFC 2976, SIP INFO method
•RFC 3261, SIP: Session Initiation Protocol
•RFC 3262, Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
•RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers
•RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification
•RFC 3311, The Session Initiation Protocol (SIP) UPDATE Method
•RFC 3372, Session Initiation Protocol for Telephones (SIP-T): Context and Architectures
•RFC 3398, Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
•RFC 3515, The Session Initiation Protocol (SIP) Refer Method
•RFC 3891, The Session Initiation Protocol (SIP) Replaces Header
•RFC 3892, The Session Initiation Protocol (SIP) Referred-By Mechanism
•RFC 4028, Session Timers in the Session Initiation Protocol (SIP)
SIP Functions Performed by the BTS 10200
The BTS 10200 supports call processing for SIP trunks and phone users. As a result of native SIP subscriber support, SIP subscribers can use features similar to those available to MGCP subscribers.
Note For a comparison of the MGCP and SIP feature support, see the "Comparison of SIP-Based Features and MGCP-Based Features" section.
Figure 1-1 shows a network architecture example in which the BTS 10200 provides native support for SIP subscribers and SIP trunks. As shown in this drawing, the BTS 10200 can establish calls between networks with various protocols, including calls between SIP trunks and SIP subscribers. In the SIP network, the BTS 10200 provides Registrar services with SIP user authentication.
Figure 1-1 Example of Network Architecture with the BTS 10200
SIP functions performed by the BTS 10200 include
•User agent server (UAS)
•User agent client (UAC)
•SIP subscriber authentication
Note The Cisco BTS 10200, as part of the back-to-back functionality, plays the role of the UAS and UAC.
Most features provided by the SIP phones comply with LATA Switching Systems Generic Requirements (LSSGR), depending on the phone implementation and capabilities. Due to the nature of the SIP protocol, however, your experience with a feature might differ from what is documented in the LSSGR for that feature.
The system supports interworking combinations between SIP subscribers and the following entities:
•PSTN (SS7, ISUP)
For information on SIP cause codes and their relation to standard (Q.850) cause codes, see Appendix H, "SIP Cause Code Mapping" in the Provisioning Guide.
SIP Registrar support enables SIP subscribers to be served by the BTS 10200 directly. The BTS 10200 acts as a Registrar and authenticates the SIP request. SIP subscribers register with the BTS 10200 and originate calls through the BTS 10200.
To initiate a session with a SIP subscriber, the BTS 10200 must know the current address of the subscriber. Registration creates bindings in a location service for a particular domain. The bindings associate an address-of-record Uniform Resource Identifier (URI) with one or more contact addresses. A SIP subscriber notifies the BTS 10200 of its availability at the address provided in the contact for the specified duration. The BTS 10200 uses the challenge-based Digest Access Authentication to authenticate the SIP subscriber. (Digest Access Authentication is described in RFC 2617.)
The SIP subscriber registers with the BTS 10200, setting up a binding between the Address of Record (AOR) and its contact address. The registration is valid for a period of time specified by the SIP phone in the REGISTER message, after which the registration expires. If the SIP phone does not specify a time period for expiration, the BTS 10200 applies a default timer, SIA_REGISTER_DEFAULT_EXPIRES, which is provisionable in the ca-config table. The BTS 10200 also requires that the duration specified by the phone be in a range between the values provisioned for SIA_REG_MIN_EXPIRES_SECS and SIA_REG_MAX_EXPIRES_SECS in the ca-config table. To provision these parameters, see the procedure in the "Provisioning a SIP Subscriber" section.
Figure 1-2 demonstrates the SIP phone Registrar function.
Figure 1-2 SIP Phone Register Function
User Agent Client and User Agent Server
The user agent is a software application running on a SIP system.
The user agent can work either as a client or server. When a call is placed, the user agent Client (UAC) places the request, and the user agent server (UAS) services the request and sends a suitable response. The roles change continually, however; for example, with call hold, either user can put the other user on hold.
Figure 1-3 shows the BTS 10200 working as a UAC, sending out a call request.
Figure 1-3 User Agent Client
Figure 1-4 shows the BTS 10200 working as a UAS, accepting a call request.
Figure 1-4 User Agent Server
Back-to-Back User Agent
The back-to-back user agent acts as a UAC and UAS for a single call. It keeps the two call segments separate on the BTS 10200. Typically, a proxy routes a call, but does not act as a user agent. The BTS 10200 acts as a user agent. In a call between two SIP endpoints (such as SIP phone or SIP trunk), The BTS 10200 terminates the originating half of the call, playing the UAS role, and then sets up the terminating half of the call as a UAC.
Note There is no provisioning associated with the back-to-back functionality. The BTS 10200 automatically acts as a back-to-back user agent for a SIP-to-SIP call.
Figure 1-5 shows the BTS 10200 working as a back-to-back user agent.
Figure 1-5 Back-to-Back User Agent Server
Figure 1-6 shows the call flow for registration.
Figure 1-6 Call Flow for Registration
Figure 1-7 shows the call flow for a back-to-back user agent.
Figure 1-7 Back-to-Back User Agent Call Flow with Authentication