SIP Network Overview
This guide describes the Session Initiation Protocol (SIP) signaling features supported in Release 6.0.3 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:
•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.
The BTS 10200 uses SIP and SIP for telephones (SIP-T) signaling to communicate with other SIP-based network elements. The implementation is based on 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 Signaling System 7 (SS7), primary rate interface (PRI) Integrated Services Digital Network (ISDN), H.323, Media Gateway Control Protocol (MGCP), and Channel Associated Signaling (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.
Compliance
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)
•Registrar
•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 Local Access and Transport Area (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.
Interworking
The system supports interworking combinations between SIP subscribers and the following entities:
•H.323 trunks
•SIP trunks
•Public switched telephone network (PSTN)—SS7 and ISDN user part (ISUP)
•ISDN
•MGCP subscribers
SIP Cause Codes
For information on SIP cause codes and their relation to ITU-T standard Q.850 cause codes, see the "SIP Cause Code Mapping" section in the Provisioning Guide.
SIP Registrar
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 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 Call Agent Configuration (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 UAC places the request, and the 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
SIP xGCP SDP Interworking Feature
SIP and the protocols represented by the term xGCP use the Session Description Protocol (SDP).
Note In this document, the term xGCP refers to the following protocols:
Media Gateway Control Protocol (MGCP)
Network-based Call Signaling (NCS
Trunking Gateway Control Protocol (TGCP)—TGCP meets requirements for the Media Gateway
Controller-to-Media Gateway interface
SIP and xGCP use SDP differently. SIP and xGCP exchange SDP transparently using the Call Agent (Cable Management System, Media Gateway Controller). However, the exchange of SDP data creates interworking problems because xGCP might ignore or reject SIP SDP syntax. Using this feature, the Cisco BTS 10200 translates SIP SDP syntax into equivalent xGCP connection-handling syntax.
To enable the Cisco BTS 10200 to operate SIP xGCP SDP Interworking, configure the following tokens in the MGW_PROFILE table to suit the specific protocol interworking required between the Cisco BTS 10200 and media gateways in your network:
SDP_XGCP_SIP_IWF_SUPP
SDP_BANDWIDTH_AS_ONLY
SDP_MULTIPLE_MEDIA_DESC_SUPP
SDP_PTIME_ADD_FROM_MPTIME
SDP_PTIME_ADD_FROM_LCO
SDP_CALL_SETUP_IWF_SUPP
SDP_PORT_ZERO_SUPP
SDP_IP_ZERO_SUPP
Note For complete CLI information, see the Cisco BTS 10200 Softswitch CLI Database.
Limitations
When the Cisco BTS 10200 operates the SIP xGCP SDP Interworking feature it requires additional processing time. To minimize the additional time required to process this feature, consider the following two criteria when you configure the MGW_PROFILE table:
•Capacity— Set only the relevant MGW_ PROFILE table tokens to Y when interworking is required.
•Calls Per Second (CPS)—This feature scans SDP for each call. Set only the MGW_PROFILE token, SDP_XGCP_SIP_IWF_SUPP to Y when interworking is required.
Industry Standards
This feature implements SIP-xGCP SDP interworking requirements defined in PacketCable EC (Engineering Change) CMSS1.5-N-07.0407-5.
Feedback