diff options
Diffstat (limited to 'doc/rfc/rfc3976.txt')
| -rw-r--r-- | doc/rfc/rfc3976.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc3976.txt b/doc/rfc/rfc3976.txt new file mode 100644 index 0000000..94e12fb --- /dev/null +++ b/doc/rfc/rfc3976.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group V. K. Gurbani +Request for Comments: 3976 Lucent Technologies, Inc. +Category: Informational F. Haerens + Alcatel Bell + V. Rastogi + Wipro Technologies + January 2005 + + + Interworking SIP and Intelligent Network (IN) Applications + + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +IESG Note + + This RFC is not a candidate for any level of Internet Standard. The + IETF disclaims any knowledge of the fitness of this RFC for any + purpose, and in particular notes that the decision to publish is not + based on IETF review for such things as security, congestion control, + or inappropriate interaction with deployed protocols. The RFC Editor + has chosen to publish this document at its discretion. Readers of + this document should exercise caution in evaluating its value for + implementation and deployment. See RFC 3932 for more information. + +Abstract + + Public Switched Telephone Network (PSTN) services such as 800-number + routing (freephone), time-and-day routing, credit-card calling, and + virtual private network (mapping a private network number into a + public number) are realized by the Intelligent Network (IN). This + document addresses means to support existing IN services from Session + Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. + The call request is originated on a SIP endpoint, but the services to + the call are provided by the data and procedures resident in the + PSTN/IN. To provide IN services in a transparent manner to SIP + endpoints, this document describes the mechanism for interworking SIP + and Intelligent Network Application Part (INAP). + + + + + +Gurbani, et al. Informational [Page 1] + +RFC 3976 Interworking SIP & IN January 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Access to IN-Services from a SIP Entity. . . . . . . . . . . . 4 + 3. Additional SIN Considerations . . . . . . . . . . . . . . . . 7 + 3.1. The Concept of State in SIP. . . . . . . . . . . . . . . 7 + 3.2. Relationship between SCP and a SIN-Enabled SIP entity. . 7 + 3.3. SIP REGISTER and IN services . . . . . . . . . . . . . . 8 + 3.4. Support of Announcements and Mid-Call Signaling. . . . . 8 + 4. The SIN Architecture . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. IN Service Control Based on the SIN Approach . . . . . . 9 + 5. Mapping of the SIP State Machine to the IN State Model . . . . 10 + 5.1. Mapping SIP Protocol State Machine to O_BCSM . . . . . . 11 + 5.2. Mapping SIP Protocol State Machine to T_BCSM . . . . . . 16 + 6. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 20 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 8.2. Informative References . . . . . . . . . . . . . . . . . 22 + Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24 + Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 24 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25 + +1. Introduction + + PSTN services such as 800-number routing (freephone), time-and-day + routing, credit-card calling, and virtual private network (mapping a + private network number into a public number) are realized by the + Intelligent Network. IN is an architectural concept for the real- + time execution of network services and customer applications [1]. IN + is, by design, de-coupled from the call processing component of the + PSTN. In this document, we describe the means to leverage this + decoupling to provide IN services from SIP-based entities. + + First, we will explain the basics of IN. Figure 1 shows a simplified + IN architecture, in which telephone switches called Service Switching + Points (SSPs) are connected via a packet network called Signaling + System No. 7 (SS7) to Service Control Points (SCPs), which are + general purpose computers. At certain points in a call, a switch can + interrupt a call and request instructions from an SCP on how to + proceed with the call. The points at which a call can be interrupted + are standardized within the Basic Call State Model (BCSM) [1, 2]. + The BCSM models contain two processes, one each for the originating + and terminating part of a call. + + + + + +Gurbani, et al. Informational [Page 2] + +RFC 3976 Interworking SIP & IN January 2005 + + + When the SCP receives a request for instructions, it can reply with a + single response, such as a simple number translation augmented by + criteria like time of day or day of week, or, in turn, initiate a + complex dialog with the switch. The situation is further complicated + by the necessity to engage other specialized devices that collect + digits, play recorded announcements, perform text-to-speech or + speech-to-text conversions, etc. (These devices are not discussed + here.) The related protocol, as well as the BCSM, is standardized by + the ITU-T and known as the Intelligent Network Application Part + protocol (INAP) [4]. Only the protocol, not an SCP API, has been + standardized. + + +-----------+ + | | + | SCP | + | | + +-----------+ + || + || + / \ + / \ + / INAP \ + / \ + / \ + +--------+ ISUP +--------+ + | SSP |*********| SSP | + +--------+ +--------+ + + Figure 1. Simplified IN Architecture + + The overall objective is to ensure that IN control of Voice over IP + (VoIP) services in networks can be readily specified and implemented + by adapting standards and software used in the present networks. + This approach leads to services that function the same when a user + connects to present or future networks, simplifies service evolution + from present to future, and leads to more rapid implementation. + + The rest of this document is organized as follows: Section 2 contains + the architectural model of an IN aware SIP entity. Section 3 + provides some issues to be taken into account when performing SIP/IN + interworking (SIN). Section 4 discusses the IN service control based + on the SIN approach. The technique outlined in this document focuses + on the call models of IN and the SIP protocol state machine; Section + 5 thus establishes a complete mapping between the two state machines + that allows access to IN services from SIP endpoints. Section 6 + includes call flows of IN services executing on SIP endpoints. These + services are readily enabled by the technique described in this + document. Finally, Section 7 covers security aspects of SIN. + + + +Gurbani, et al. Informational [Page 3] + +RFC 3976 Interworking SIP & IN January 2005 + + +List of Acronyms + + B2BUA Back-to-Back User Agent + BCSM Basic Call State Model + CCF Call Control Function + DP Detection Point + DTMF Dual Tone Multi-Frequency + IN Intelligent Network + INAP Intelligent Network Application Part + IP Internet Protocol + ITU-T International Telecommunications Union - + Telecommunications Standardization Sector + O_BCSM Originating Basic Call State Model + PIC Point in Call + PSTN Public Switched Telephone Network + RTP Real Time Protocol + R-URI Request URI + SCF Service Control Function + SCP Service Control Point + SIGTRAN Signal Transport Working Group in IETF + SIN SIP/IN Interworking + SIP Session Initiation Protocol + SS7 Signaling System No. 7 + SSF Service Switching Function + SSP Service Switching Point + T_BCSM Terminating Basic Call State Model + UA User Agent + UAC User Agent Client + UAS User Agent Server + VoIP Voice over IP + VPN Virtual Private Network + +2. Access to IN-Services from a SIP Entity + + The intent of this document is to provide the means to support + existing IN-based applications in a SIP [3] environment. One way to + gain access to IN services transparently from SIP (e.g., through the + same detection points (DPs) and point-in-call (PIC) used by + traditional switches) is to map the SIP protocol state machine to the + IN call models [1]. + + From the viewpoint of IN elements such as the SCP, the request's + origin from a SIP entity rather than a call processing function on a + traditional switch is immaterial. Thus, it is important that the SIP + entity be able to provide the same features as the traditional + switch, including operating as an SSP for IN features. The SIP + entity should also maintain call state and trigger queries to IN- + based services, as do traditional switches. + + + +Gurbani, et al. Informational [Page 4] + +RFC 3976 Interworking SIP & IN January 2005 + + + This document does not intend to specify which SIP entity shall + operate as an SSP; however, for the sake of completeness, it should + be mentioned that this task should be performed by SIP entities at + (or near) the core of the network rather than at the SIP end points + themselves. To that extent, SIP entities such as proxy servers and + Back-to-Back user agents (B2BUAs) may be employed. Generally + speaking, proxy servers can be used for IN services that occur during + a call setup and teardown. For IN services requiring specialized + media handling (such as DTMF detection) or specialized call control + (such as placing parties on hold) B2BUAs will be required. + + The most expeditious manner for providing existing IN services in the + IP domain is to use the deployed IN infrastructure as often as + possible. In SIP, the logical point to tap into for accessing + existing IN services is either the user agents or one of the proxies + physically closest to the user agent (and presumably in the same + administrative domain). However, SIP entities do not run an IN call + model; to access IN services transparently, the trick then is to + overlay the state machine of the SIP entity with an IN layer so that + call acceptance and routing is performed by the native state machine + and so that services are accessed through the IN layer by using an IN + call model. Such an IN-enabled SIP entity, operating in synchrony + with the events occurring at the SIP transaction level and + interacting with the IN elements (SCP), is depicted in Figure 2: + + +-------+ + | SCP | + +---+---+ + | + | INAP + | + +--------+ + | SIN | + +........+ + | SIP | + ---------->| Entity |---------> + Requests | | Requests out + in +--------+ (after applying IN + services) + + SIN: SIP/IN Interworking layer + + Figure 2. SIP Entity Accessing IN Services + + Section 5 proposes this mapping between the IN layer and the SIP + protocol state machine. Essentially, a SIP entity exhibiting this + mapping becomes a SIN-enabled SIP entity. + + + + +Gurbani, et al. Informational [Page 5] + +RFC 3976 Interworking SIP & IN January 2005 + + + This document does not propose any extensions to SIP. + + Figure 3 expands the SIP entity depicted in Figure 2 and further + details the architecture model involving IN and SIP interworking. + Events occurring at the SIP layer will be passed to the IN layer for + service application. More specifically, since IN services deal with + E.164 numbers, it is reasonable to assume that a SIN-enabled SIP + entity that seeks to provide services on such a number will consult + the IN layer for further processing, thus acting as a SIP-based SSP. + The IN layer will proceed through its BCSM states and, at appropriate + points in the call, will send queries to the SCP for call + disposition. Once the disposition of the call has been determined, + the SIP layer is informed and processes the transaction accordingly. + + Note that the single SIP entity as modeled in this figure can in fact + represent several different physical instances in the network as, for + example, when one SIP entity is in charge of the terminal or access + network/domain, and another is in charge of the interface to the + Switched Circuit Network (SCN). + + +-------+ + | SCP | + +---o---+ + | + +-----+ + | + **********|*********************************** + * +-------|-------------------+ * + * |+------o------+ | * + * || SSF(IP) | | * + * |+-------------+ | * + * || CCF(IP) | | * + * |+------o------+ | * + * +-------|-------------------+ * + * | SIN-enabled * + * +-------o-------------------+ SIP * + * | SIP Layer | Entity * + * +---------------------------+ * + ********************************************** + + Figure 3. Functional Architecture of a SIN-Enabled SIP Entity + + The following architecture entities, used in Figure 3, are defined in + the Intelligent Network standards: + + Service Switching Function (SSF): IN functional entity that + interacts with call control functions. + + + + +Gurbani, et al. Informational [Page 6] + +RFC 3976 Interworking SIP & IN January 2005 + + + Call Control Function (CCF): IN functional entity that refers + to call and connection handling in the classical sense (i.e., + that of an exchange). + +3. Additional SIN Considerations + + In working between Internet Telephony and IN-PSTN networks, the main + issue is to translate between the states produced by the Internet + Telephony signaling and those used in traditional IN environments. + Such a translation entails attention to the considerations listed + below. + +3.1. The Concept of State in SIP + + IN services occur within the context of a call, i.e., during call + setup, call teardown, or in the middle of a call. SIP entities such + as proxies, with which some of these services may be realized, + typically run in transaction-stateful (or stateless) mode. In this + mode, a SIP proxy that proxied the initial INVITE is not guaranteed + to receive a subsequent request, such as a BYE. Fortunately, SIP has + primitives to force proxies to run in a call-stateful mode; namely, + the Record-Route header. This header forces the user agent client + (UAC) and user agent server (UAS) to create a "route set" that + consists of all intervening proxies through which subsequent requests + must traverse. Thus SIP proxies must run in call-stateful mode in + order to provide IN services on behalf of the UAs. + + A B2BUA is another SIP element in which IN services can be realized. + As a B2BUA is a true SIP UA, it maintains complete call state and is + thus capable of providing IN services. + +3.2. Relationship between SCP and a SIN-Enabled SIP Entity + + In the architecture model proposed in this document, each SIN-enabled + SIP entity is pre-configured to communicate with one logical SCP + server, using whatever communication mechanism is appropriate. + Different SIP servers (e.g., those in different administrative + domains) may communicate with different SCP servers, so that there is + no single SCP server responsible for all SIP servers. + + As Figures 1 and 2 depict, the IN-portion of the SIN-enabled SIP + entity will communicate with the SCP. This interface between the IN + call handling layer and the SCP is not specified by this document + and, indeed, can be any one of the following, depending on the + interfaces supported by the SCP: INAP over IP, INAP over SIGTRAN, or + INAP over SS7. + + + + + +Gurbani, et al. Informational [Page 7] + +RFC 3976 Interworking SIP & IN January 2005 + + + This document is only applicable when SIP-controlled Internet + telephony devices seek to operate with PSTN devices. The SIP UAs + using this interface would typically appear together with a media + gateway. This document is *not* applicable in an all-IP network and + is not needed in cases where PSTN media gateways (not speaking SIP) + need to communicate with SCPs. + +3.3. SIP REGISTER and IN Services + + SIP REGISTER provisions a SIP Proxy or SIP Registration server. The + process is similar to the provisioning of an SCP/HLR in the switched + circuit network. SCPs that provide VoIP based services can leverage + this information directly. However, this document neither endorses + nor prohibits such an architecture and, in fact, considers it an + implementation decision. + +3.4. Support of Announcements and Mid-Call Signaling + + Services in the IN such as credit-card calling typically play + announcements and collect digits from the caller before a call is set + up. Playing announcements and collecting digits require the + manipulation of media streams. In SIP, proxies do not have access to + the media data path. Thus, such services should be executed in a + B2BUA. + + Although the SIP specification [3] allows for end points to be put on + hold during a call or for a change of media streams to take place, it + does not have any primitives to transport other than mid-call control + information. This may include transporting DTMF digits, for example. + Extensions to SIP, such as the INFO method [5] or the SIP event + notification extension [6], can be considered for services requiring + mid-call signaling. Alternatively, DTMF can be transported in RTP + itself [7]. + +4. The SIN Architecture + +4.1. Definitions + + The SIP architecture has the following functional elements defined in + [3]: + + - User agent client (UAC): The SIP functional entity that + initiates a request. + + - User agent server (UAS): The SIP functional entity that + terminates a request by sending 0 or more provisional SIP + responses and one final SIP response. + + + + +Gurbani, et al. Informational [Page 8] + +RFC 3976 Interworking SIP & IN January 2005 + + + - Proxy server: An intermediary SIP entity that can act as both a + UAS and a UAC. Acting as a UAS, it accepts requests from UACs, + rewrites the Request-URI (R-URI), and, acting as a UAC, proxies + the request to a downstream UAS. Proxies may retain + significant call control state by inserting themselves in + future SIP transactions beyond the initial INVITE. + + - Redirect server: An intermediary SIP entity that redirects + callers to alternate locations, after possibly consulting a + location server to determine the exact location of the callee + (as specified in the R-URI). + + - Registrar: A SIP entity that accepts SIP REGISTER requests and + maintains a binding from a high-level URL to the exact location + for a user. This information is saved in some data-store that + is also accessible to a SIP Proxy and a SIP Redirect server. A + Registrar is usually co-located with a SIP Proxy or a SIP + Redirect server. + + - Outbound proxy: A SIP proxy located near the originator of + requests. It receives all outgoing requests from a particular + UAC, including those requests whose R-URIs identify a host + other than the outbound proxy. The outbound proxy sends these + requests, after any local processing, to the address indicated + in the R-URI. + + - Back-to-Back UA (B2BUA): A SIP entity that receives a request + and processes it as a UAS. It also acts as a UAC and generates + requests to determine how the incoming request is to be + answered. A B2BUA maintains complete dialog state and must + participate in all requests sent within the dialog. + +4.2. IN Service Control Based on the SIN Approach + + Figure 4 depicts the possibility of IN service control based on the + SIN approach. On both the originating and terminating ends, a SIN- + capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O + SIP" entity is required for outgoing calls that require support for + existing IN services. Likewise, on the callee's side (or terminating + side), an equally configured entity ("T SIP") will be required to + provide terminating side services. Note that the "O SIP" and "T SIP" + entities correspond, respectively, to the IN O_BCSM and T_BCSM halves + of the IN call model. + + + + + + + + +Gurbani, et al. Informational [Page 9] + +RFC 3976 Interworking SIP & IN January 2005 + + + +---+ +---+ + | S | (~~~~~~~~~~~~~) | S | + | C |<--+ ( ) +-->| C | + | P | | ( ) | | P | + +---+ | ( Switched ) | +---+ + | ( Circuit ) | + V ( Network ) V + +-------+ ( ) +-------+ + | SIN | +---------+ +---------+ | SIN | + +-------+----| Gateway | ... | Gateway |------+-------+ + | O SIP | +---------+ +---------+ | T SIP | + +-------+ ( ) +-------+ + ( ) + (.............) + + O SIP: Originating SIP entity + T SIP: Terminating SIP entity + + Figure 4. Overall SIN Architecture + +5. Mapping of the SIP State Machine to the IN State Model + + This section establishes the mapping of the SIP protocol state + machine to the IN generic basic call state model (BCSM) [2], + independent of any capability sets [8, 9]. The BCSM is divided into + two halves: an originating call model (O_BCSM) and a terminating call + model (T_BCSM). There are a total of 19 PICs and 35 DPs between both + the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for + T_BCSM) [1]. The SSPs, SCPs, and other IN elements track a call's + progress in terms of the basic call model. The basic call model + provides a common context for communication about a call. + + O_BCSM has 11 PICs: + + O_NULL: Starting state; call does not exist yet. + AUTH_ORIG_ATTEMPT: Switch detects a call setup request. + COLLECT_INFO: Switch collects the dial string from the calling party. + ANALYZE_INFO: Complete dial string is translated into a routing + address. + SELECT_ROUTE: Physical route is selected, based on the routing + address. + AUTH_CALL_SETUP: Switch ensures the calling party is authorized to + place the call. + CALL_SENT: Control of call sent to terminating side. + O_ALERTING: Switch waits for the called party to answer. + O_ACTIVE: Connection established; communications ensue. + O_DISCONNECT: Connection torn down. + O_EXCEPTION: Switch detects an exceptional condition. + + + +Gurbani, et al. Informational [Page 10] + +RFC 3976 Interworking SIP & IN January 2005 + + + T_BCSM has 8 PICS: + + T_NULL: Starting state; call does not exist yet. + AUTH_TERM_ATT: Switch verifies whether the call can be sent to + terminating party. + SELECT_FACILITY: Switch picks a terminating resource to send the call + on. + PRESENT_CALL: Call is being presented to the called party. + T_ALERTING: Switch alerts the called party, e.g., by ringing the + line. + T_ACTIVE: Connection established; communications ensue. + T_DISCONNECT: Connection torn down. + T_EXCEPTION: Switch detects an exceptional condition. + + The state machine for O_BCSM and T_BCSM is provided in [1] on pages + 98 and 103, respectively. This state machine will be used for + subsequent discussion when the IN call states are mapped into SIP. + + The next two sections contain the mapping of the SIP protocol state + machine to the IN BCSMs. Explaining all PICs and DPs in an IN call + model is beyond the scope of this document. It is assumed that the + reader has some familiarity with the PICs and DPs of the IN call + model. More information can be found in [1]. For a quick reference, + Appendix A contains a mapping of the DPs to the SIP response codes as + discussed in the next two sections. + +5.1. Mapping SIP Protocol State Machine to O_BCSM + + The 11 PICs of O_BCSM come into play when a call request (SIP INVITE + message) arrives from an upstream SIP client to an originating SIN- + enabled SIP entity running the IN call model. This entity will + create an O_BCSM object and initialize it in the O_NULL PIC. The + next seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO, + ANALYZE_INFO, SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all + be mapped to the SIP "Calling" state. + + Figure 5 provides a visual map from the SIP protocol state machine to + the originating half of the IN call model. Note that control of the + call shuttles between the SIP protocol machine and the IN O_BCSM call + model while it is being serviced. + + + + + + + + + + + +Gurbani, et al. Informational [Page 11] + +RFC 3976 Interworking SIP & IN January 2005 + + + SIP O_BCSM + + | INVITE + V + +---------+ +---------------+ + | Calling +=======================>+ O_NULL +<----+ + +--+---/\-+ +-/\---+--------+ | + | | || +-------------+ | | | + | | ||<===+O_Exception +---------+ +--V-+ +--+-+ + | | || +--/\---------+ |DP 1| |DP21| + | | || | +----+ +-----+----+------+ +--+-+ + | | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+ + | | || | +----+ +--------+--------+ | + | | || | | | + | | || | +--V-+ | + | | || | |DP 3| | + | | || | +----+ +-----+----+------+ | + | | || +<---+DP 4|<-----+ Collect_Info +---->+ + | | || | +----+ +--------+--------+ | + | | || | | | + | | || | +--V-+ | + | | || | |DP 5| | + | | || | +----+ +-----+----+------+ | + | | || +<---+DP 6|<-----+ Analyze_Info +---->+ + | | || | +----+ +--------+--------+ | + | | || | | | + | | || | +--V-+ | + | | || | |DP 7| | + | | || | +----+ +-----+----+------+ | + | | || +<---+DP 8|<-----+ Select_Route +---->+ + | | || | +----+ +--------+--------+ | + | | || | | | + | | || | +--V-+ | + | | || | |DP 9| | + | | || | +----+ +-----+----+------+ | + | | || +<---+DP10|<-----+ Auth._Call_Setup+---->+ + | | || +----+ +--------+--------+ + +----+ | || | + | | || +--V-+ + | | || |DP11| + | 1xx | || +-----+----+------+ + | | ++========================+ Call_Sent | + | | +----/\----+------+ + | | On 100,180,2xx process DP14 || | + | | On 3xx, process DP12 || | + | V On 486, process DP13 || | + | +--+-------+ On 5xx, 6xx and 4xx || | + | |Proceeding| (except 486) process DP21|| | + + + +Gurbani, et al. Informational [Page 12] + +RFC 3976 Interworking SIP & IN January 2005 + + + | +-+-+------+<=========================++ | + | | | | + | | | | + | | | | + | | +--200------------------+ | + | +----4xx to 6xx--------+ | | + | | | +--V-+ + | On DPs 21, 2, 4, 6, 8, 10 | | |DP14| + | send 4xx-6xx final response | | +--------+----+--+ + +-------+ | | | O_Alerting | + | | | +---------+------+ + +--V-------+ | | | + |Completed |<------------+ | +--V-+ + +--+-------+ | |DP16| + | | +------+----+----+ + +--V-------+ | +-+ O_Active | + |Terminated|<---------------+ | +-------------+--+ + +----------+ | | + +-----+ +--V-+ + | |DP19| + +--V-+ +--------+----+ + |DP17| | O_Disconnect| + +--+-+ +-------------+ + | + V + To O_EXCEPTION + Legend: + + | Communication between + | states in the same + V protocol + + ======> Communication between IN Layer and SIP Protocol + State machine to transfer call state + + Figure 5. Mapping from SIP to O_BCSM + + The SIP "Calling" protocol state has enough functionality to absorb + the seven PICs as described below: + + O_NULL: This PIC is basically a fall through state to the next + PIC, AUTHORIZE_ORIGINATION_ATTEMPT. + + AUTHORIZE_ORIGINATION_ATTEMPT: In this PIC, the IN layer has + detected that someone wishes to make a call. Under some + circumstances (e.g., if the user is not allowed to make calls + during certain hours), such a call cannot be placed. SIP can + authorize the calling party by using a set of policy directives + + + +Gurbani, et al. Informational [Page 13] + +RFC 3976 Interworking SIP & IN January 2005 + + + configured by the SIP administrator. If the called party is + authorized to place the call, the IN layer is instructed to enter + the next PIC, COLLECT_INFO through DP 3 + (Origination_Attempt_Authorized). If for some reason the call + cannot be authorized, DP 2 (Origination_Denied) is processed, and + control transfers to the SIP state machine. The SIP state machine + must format and send a non-2xx final response (possibly 403) to + the upstream entity. + + COLLECT_INFO: This PIC is responsible for collecting a dial string + from the calling party and verifying the format of the string. If + overlap dialing is being used, this PIC can invoke DP 4 + (Collect_Timeout) and transfer control to the SIP state machine, + which will format and send a non-2xx final response (possibly a + 484). If the dial string is valid, DP 5 (Collected_Info) is + processed, and the IN layer is instructed to enter the next PIC, + ANALYZE_INFO. + + ANALYZE_INFO: This PIC is responsible for translating the dial + string to a routing number. Many IN services, such as freephone, + LNP (Local Number Portability), and OCS (Originating Call + Screening) occur during this PIC. The IN layer can use the R-URI + of the SIP INVITE request for analysis. If the analysis succeeds, + the IN layer is instructed to enter the next PIC, SELECT_ROUTE. + If the analysis fails, DP 6 (Invalid_Info) is processed, and the + control transfers to the SIP state machine, which will generate a + non-2xx final response (possibly 400, 401, 403, 404, 405, 406, + 410, 414, 415, 416, 485, or 488) and send it to the upstream + entity. + + SELECT_ROUTE: In the circuit-switched network, the actual physical + route has to be selected at this point. The SIP analogue would be + to determine the next hop SIP server. This could be chosen by a + variety of means. For instance, if the Request URI in the + incoming INVITE request is an E.164 number, the SIP entity can use + a protocol like TRIP [10] to find the best gateway to egress the + request onto the PSTN. If a successful route is selected, the IN + call model moves to PIC AUTH_CALL_SETUP via DP 9 (Route_Selected). + Otherwise, the control transfers to the SIP state machine via DP 8 + (Route_Select_Failure), which will generate a non-2xx final + response (possibly 488) and send it to the upstream entity. + + AUTH_CALL_SETUP: Certain service features restrict the type of + call that may originate on a given line or trunk. This PIC is the + point at which relevant restrictions are examined. If no such + restrictions are encountered, the IN call model moves to PIC + CALL_SENT via DP 11 (Origination_Authorized). If a restriction is + encountered that prohibits further processing of the call, DP 10 + + + +Gurbani, et al. Informational [Page 14] + +RFC 3976 Interworking SIP & IN January 2005 + + + (Authorization_Failure) is processed, and control is transferred + to the SIP state machine, which will generate a non-2xx final + response (possibly 404, 488, or 502). Otherwise, DP 11 + (Origination_Authorized) is processed, and the IN layer is + instructed to enter the next PIC, CALL_SENT. + + CALL_SENT: At this point, the request needs to be sent to the + downstream entity. The IN layer waits for a signal confirming + either that the call has been presented to the called party or + that a called party cannot be reached for a particular reason. + The control is transferred to the SIP state machine. The SIP + state machine should now send the call to the next downstream + server determined in PIC SELECT_ROUTE. The IN call model now + blocks until unblocked by the SIP state machine. + + If the above seven PICs have been successfully negotiated, the + SIN-enabled SIP entity now sends the SIP INVITE message to the + next hop server. Further processing now depends on the + provisional responses (if any) and the final response received by + the SIP protocol state machine. The core SIP specification does + not guarantee the delivery of 1xx responses; thus special + processing is needed at the IN layer to transition to the next PIC + (O_ALERTING) from the CALL_SENT PIC. The special processing + needed for responses while the SIP state machine is in the + "Proceeding" state and the IN layer is in the "CALL_SENT" state is + described next. + + A 100 response received at the SIP state machine elicits no + special behavior in the IN layer. + + A 180 response received at the SIP entity enables the + processing of DP 14 (O_Term_Seized), however, a state + transition to O_ALERTING is not undertaken yet. Instead, the + IN layer is instructed to remain in the CALL_SENT PIC until a + final response is received. + + A 2xx response received at the SIP entity enables the + processing of DP 14 (O_Term_Seized), and the immediate + transition to the next state, O_ALERTING (processing in + O_ALERTING is described later). + + A 3xx response received at the SIP entity enables the + processing of DP 12 (Route_Failure). The IN call model from + this point goes back to the SELECT_ROUTE PIC to select a new + route for the contacts in the 3xx final response (not shown in + Figure 5 for brevity). + + + + + +Gurbani, et al. Informational [Page 15] + +RFC 3976 Interworking SIP & IN January 2005 + + + A 486 (Busy Here) response received at the SIP entity enables + the processing of DP 13 (O_Called_Party_Busy) and resources for + the call are released at the IN call model. + + If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or + 6xx final response, DP 21 (O_Calling_Party_Disconnect & + O_Abandon) is processed and control passes to the SIP state + machine. Since a call was not successfully established, both + the IN layer and the SIP state machine can release resources + for the call. + + O_ALERTING - This PIC will be entered as a result of receiving a + 200-class response. Since a 200-class response to an INVITE + indicates acceptance, this PIC is mostly a fall through to the + next PIC, O_ACTIVE via DP 16 (O_Answer). + + O_ACTIVE - At this point, the call is active. Once in this state, + the call may get disconnected only when one of the following three + events occur: (1) the network connection fails, (2) the called + party disconnects the call, or (3) the calling party disconnects + the call. If event (1) occurs, DP 17 (O_Connection_Failure) is + processed and call control is transferred to the SIP protocol + state machine. Since the network failed, there is not much sense + in attempting to send a BYE request; thus, both the SIP protocol + state machine and the IN call layer should release all resources + associated with the call and initialize themselves to the null + state. Event (2) results in the processing of DP 19 + (O_DISCONNECT) and a move to the last PIC, O_DISCONNECT. Event + (3) occurs if the calling party deliberately terminated the call. + In this case, DP 21 (O_Abandon & O_Calling_Party_Disconnect) will + be processed, and control will be passed to the SIP protocol state + machine. The SIP protocol state machine must send a BYE request + and wait for a final response. The IN layer releases all of its + resources and initializes itself to the null state. + + O_DISCONNECT: When the SIP entity receives a BYE request, the IN + layer is instructed to move to the last PIC, O_DISCONNECT via DP + 19. A final response for the BYE is generated and transmitted by + the SIP entity, and the call resources are freed by both the SIP + protocol state machine and the IN layer. + +5.2. Mapping SIP Protocol State Machine to T_BCSM + + The T_BCSM object is created when a SIP INVITE message makes its way + to the terminating SIN-enabled SIP entity. This entity creates the + T_BCSM object and initializes it to the T_NULL PIC. + + + + + +Gurbani, et al. Informational [Page 16] + +RFC 3976 Interworking SIP & IN January 2005 + + + Figure 6 provides a visual map from the SIP protocol state machine to + the terminating half of the IN call model: + + SIP T_BCSM + + | INVITE + V + +----------+ +------------+ + |Proceeding+=========================>+ T_Null +<-------+ + +-+--+--/\-+ +/\----+-----+ | + | | || +-----------+ | | | + | | ||<=======+T_Exception+--------+ +--V-+ +--+-+ + | | || +-/\--------+ |DP22| |DP35| + | | || | +----+ +---+----+------+ +--+-+ + | | || +<---+DP23|<------+Auth._Term._Att+---->+ + | | || | +----+ +------+--------+ | + | | || | | | + | | || | +--V-+ | + | | || | |DP24| | + | | || | +----+ +---+----+------+ | + | | || +<---+DP25|<------+Select_Facility+---->+ + | | || | +----+ +------+--------+ | + | | || | | | + | | || | +--V-+ | + | | || | |DP26| | + | | || | +----+ +---+----+------+ | + | | || +<---+DP27|<------+ Present_Call +---->+ + | | || | +----+ +------+--------+ | + | | || | | | + | | || | +--V-+ | + | | || | |DP28| | + | | || | +----+ +---+----+------+ | + | | || +<---+DP29|<------+ T_Alerting +---->+ + | | || | +----+ +-/\--+---------+ | + | | || +<--------------+ || | | + | | || | || | | + | | ++==========================|===++ | | + | | /\ +-------+ +--V-+ | + | | || | +DP30| | + | | || +-+--+ +---+----+------+ | + | | || |DP31+<-----| T_Active +---->+ + | | || +----+ +-/\-----+------+ + | | || || | + | | || || | +2xx | | ++==============================++ | +sent | | | ++----+ | 3xx - 6xx response +--V-+ +| | sent |DP33| + + + +Gurbani, et al. Informational [Page 17] + +RFC 3976 Interworking SIP & IN January 2005 + + +| +----V-----+ +------+----+----+ +| |Completed | | T_Disconnect | +| +----+-----+ +----------------+ +| | +| | ACK received +| | +| +----V-----+ +| |Confirmed | +| +----+-----+ +| | ++------>| + | + +----V-----+ + |Terminated| + +----------+ + + Legend: + + | Communication between + | states in the same + V protocol + ======> Communication between IN call model and SIP + protocol state machine to transfer call state + + Figure 6. Mapping from SIP to T_BCSM + + The SIP "Proceeding" state has enough functionality to absorb the + first five PICS -- T_Null, Authorize_Termination_Attempt, + Select_Facility, Present_Call, T_Alerting -- as described below: + + T_NULL: At this PIC, the terminating end creates the call at the + IN layer. The incoming call results in the processing of DP 22, + Termination_Attempt, and a transition to the next PIC, + AUTHORIZE_TERMINATION_ATTEMPT, takes place. + + AUTHORIZE_TERMINATION_ATTEMPT: At this PIC, it is ascertained that + the called party wishes to receive the call and that the + facilities of the called party are compatible with those of the + calling party. If any of these conditions is not met, DP 23 + (Termination_Denied) is invoked, and the call control is + transferred to the SIP protocol state machine. The SIP protocol + state machine can format and send a non-2xx final response + (possibly 403, 405, 415, or 480). If the conditions of the PIC + are met, processing of DP 24 (Termination_Authorized) is invoked, + and a transition to the next PIC, SELECT_FACILITY, takes place. + + + + + + +Gurbani, et al. Informational [Page 18] + +RFC 3976 Interworking SIP & IN January 2005 + + + SELECT_FACILITY: In circuit switched networks, this PIC is + intended to select a line or trunk to reach the called party. As + lines or trunks are not applicable in an IP network, a SIN-enabled + SIP entity can use this PIC to interface with a PSTN gateway and + select a line/trunk to route the call. If the called party is + busy, or if a line/trunk cannot be seized, the processing of DP 25 + (T_Called_Party_Busy) is invoked, and the call goes to the SIP + protocol state machine. The SIP protocol state machine must + format and send a non-2xx final response (possibly 486 or 600). + If a line/trunk was successfully seized, the processing of DP 26 + (Terminating_Resource_Available) is invoked, and a transition to + the next PIC, PRESENT_CALL, takes place. + + PRESENT_CALL: At this point, the call is being presented (via the + ISUP ACM message, or Q.931 Alerting message, or simply by ringing + a POTS phone). If there was an error presenting the call, the + processing of DP 27 (Presentation_Failure) is invoked, and the + call control is transferred to the SIP protocol state machine, + which must format and send a non-2xx final response (possibly + 480). If the call was successfully presented, the processing of + DP 28 (T_Term_Seized) is invoked, and a transition to the next + PIC, T_ALERTING, takes place. + + T_ALERTING: At this point, the called party is being "alerted". + Control now passes momentarily to the SIP protocol state machine + so that it can generate and send a "180 Ringing" response to its + peer. Furthermore, since network resources have been allocated + for the call, timers are set to prevent indefinite holding of such + resources. The expiration of the relevant timers results in the + processing of DP 29 (T_No_Answer), and the call control is + transferred to the SIP protocol state machine, which must format + and send a non-2xx final response (possibly 408). If the called + party answers, then DP 30 (T_Answer) is processed, followed by a + transition to the next PIC, T_ACTIVE. + + After the above five PICs have been negotiated, the rest are mapped + as follows: + + T_ACTIVE: The call is now active. Once this state is reached, the + call may become inactive under one of the following three + conditions: (1) The network fails the connection, (2) the called + party disconnects the call, or (3) the calling party disconnects + the call. Event (1) results in the processing of DP 31 + (T_Connection_Failure), and call control is transferred to the SIP + protocol state machine. Since the network failed, there is little + sense in attempting to send a BYE request; thus, both the SIP + protocol state machine and the IN call layer should release all + resources associated with the call and initialize themselves to + + + +Gurbani, et al. Informational [Page 19] + +RFC 3976 Interworking SIP & IN January 2005 + + + the null state. Event (2) results in the processing of DP 33 + (T_Disconnect) and a transition to the next PIC, T_DISCONNECT. + Event (3) occurs at the receipt of a BYE request at the SIP + protocol state machine (not shown in Figure 6). Resources for the + call should be deallocated, and the SIP protocol state machine + must send a 200 OK for the BYE request (not shown in Figure 6). + + T_DISCONNECT: In this PIC, the disconnect treatment associated + with the called party's having disconnected the call is performed + at the IN layer. The SIP protocol state machine sends out a BYE + and awaits a final response for the BYE (not shown in Figure 6). + +6. Examples of Call Flows + + Two examples are provided here to show how SIP protocol state machine + and the IN call model work synchronously with each other. + + In the first example, a SIP UAC originates a call request destined to + an 800 freephone number: + + INVITE sip:18005551212@example.com SIP/2.0 + From: sip:16305551212@example.net;tag=991-7as-66ff + To: sip:18005551212@example.com + Via: SIP/2.0/UDP stn1.example.net + Call-ID: 67188121@example.net + CSeq: 1 INVITE + + The request makes its way to the originating SIP network server + running an IN call model. The SIP network server hands, at the very + least, the To: field and the From: field to the IN layer for + freephone number translation. The IN layer proceeds through its PICs + and at the ANALYSE_INFO PIC consults the SCP for freephone + translation. The translated number is returned to the SIP network + server, which forwards the message to the next hop SIP proxy, with + the freephone number replaced by the translated number: + + INVITE sip:18475551212@example.com SIP/2.0 + From: sip:16305551212@example.net;tag=991-7as-66ff + To: sip:18005551212@example.com + Via: SIP/2.0/UDP ext-stn2.example.net + Via: SIP/2.0/UDP stn1.example.net + Call-ID: 67188121@example.net + CSeq: 1 INVITE + + + + + + + + +Gurbani, et al. Informational [Page 20] + +RFC 3976 Interworking SIP & IN January 2005 + + + In the next example, a SIP UAC originates a call request destined to + a 900 number: + + INVITE sip:19005551212@example.com SIP/2.0 + From: sip:16305551212@example.net;tag=991-7as-66dd + To: sip:19005551212@example.com + Via: SIP/2.0/UDP stn1.example.net + Call-ID: 88112@example.net + CSeq: 1 INVITE + + The request makes its way to the originating SIP network server + running an IN call model. The SIP network server hands, at the very + least, the To: field and the From: field to the IN layer for 900 + number translation. The IN layer proceeds through its PICs and at + the ANALYSE_INFO PIC consults the SCP for the translation. During + the translation, the SCP detects that the originating party is not + allowed to make 900 calls. It passes this information to the + originating SIP network server, which informs the SIP UAC by using a + SIP "403 Forbidden" response status code: + + SIP/2.0 403 Forbidden + From: sip:16305551212@example.net;tag=991-7as-66dd + To: sip:19005551212@example.com;tag=78K-909II + Via: SIP/2.0/UDP stn1.example.net + Call-ID: 88112@example.net + CSeq: 1 INVITE + +7. Security Considerations + + Security considerations for SIN services cover both networks being + used, namely, the PSTN and the Internet. SIN uses the security + measures in place for both the networks. With reference to Figure 2, + the INAP messages between the SCP and the SIN-enabled SIP entity must + be secured by the signaling transport used between the SCP and the + SIN-enabled entity. Likewise, the requests coming into the SIN- + enabled SIP entity must first be authenticated and, if need be, + encrypted as well, using the means and procedures defined in [3] for + SIP requests. + +8. References + +8.1. Normative References + + [1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The + Intelligent Network Standards: Their Application to Services," + McGraw-Hill, 1997. + + + + + +Gurbani, et al. Informational [Page 21] + +RFC 3976 Interworking SIP & IN January 2005 + + + [2] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network + Distributed Functional Plane Architecture," International + Telecommunications Union Standardization Section, Geneva. + + [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + +8.2. Informative References + + [4] ITU-T Q.1208: "General aspects of the Intelligent Network + Application protocol" + + [5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. + + [6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, + Telephony Tones and Telephony Signals", RFC 2833, May 2000. + + [8] ITU-T Q.1218: "Interface Recommendation for Intelligent Network + Capability Set 1". + + [9] ITU-T Q.1228: "Interface Recommendation for Intelligent Network + Capability Set 2". + + [10] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing + over IP (TRIP)", RFC 3219, January 2002. + + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Informational [Page 22] + +RFC 3976 Interworking SIP & IN January 2005 + + +Appendix A: Mapping of 4xx-6xx Responses in SIP to IN Detections Points + + The mapping of error codes 4xx-6xx responses in SIP to the possible + Detection Points in PIC Originating and Terminating Call Handling is + indicated in the table below. The reason phrase in the 4xx-6xx + response is reproduced from [3]. + + SIP response code DP mapping to IN + ----------------- ---------------------- + 200 OK DP 14 + 3xx DP 12 + 403 Forbidden DP 2, DP 21 + 484 Address Incomplete DP 4, DP 21 + 400 Bad Request DP 6, DP 21 + 401 Unauthorized DP 6, DP 21 + 403 Forbidden DP 6, DP 21, DP 23 + 404 Not Found DP 6, DP 21 + 405 Method Not Allowed DP 6, DP 21, DP 23 + 406 Not Acceptable DP 6, DP 21 + 408 Request Timeout DP 29 + 410 Gone DP 6, DP 21 + 414 Request-URI Too Long DP 6, DP 21 + 415 Unsupported Media Type DP 6, DP 21, DP 23 + 416 Unsupported URI Scheme DP 6, DP 21 + 480 Temporarily Unavailable DP 23, DP 27 + 485 Ambiguous DP 6, DP 21 + 486 Busy Here DP 13, DP 21, DP 25 + 488 Not Acceptable Here DP 6, DP 21 + + + + + + + + + + + + + + + + + + + + + + + +Gurbani, et al. Informational [Page 23] + +RFC 3976 Interworking SIP & IN January 2005 + + +Acknowledgments + + Special acknowledgment is due to Hui-Lan Lu for acting as the chair + of the SIN DT and ensuring that the focus of the DT did not veer too + far. The authors would also like to give special thanks to Mr. Ray + C. Forbes from Marconi Communications Limited for his valuable + contribution on the system and network architectural aspects as co- + chair in the ETSI SPAN. Thanks also to Doris Lebovits, Kamlesh + Tewani, Janusz Dobrowloski, Jack Kozik, Warren Montgomery, Lev + Slutsman, Henning Schulzrinne, and Jonathan Rosenberg, who all + contributed to the discussions on the relationship of IN and SIP call + models. + +Author's Addresses + + Vijay K. Gurbani + Lucent Technologies, Inc. + 2000 Lucent Lane, Rm 6G-440 + Naperville, Illinois 60566 + USA + Phone: +1 630 224 0216 + EMail: vkg@lucent.com + + Frans Haerens + Alcatel Bell + Francis Welles Plein,1 + Belgium + Phone: +32 3 240 9034 + EMail: frans.haerens@alcatel.be + + Vidhi Rastogi + Wipro Technologies + Plot No.72, Keonics Electronics City, + Hosur Main Road, + Bangalore 226 560 100 + Phone: +91 80 51381869 + EMail: vidhi.rastogi@wipro.com + + + + + + + + + + + + + + +Gurbani, et al. Informational [Page 24] + +RFC 3976 Interworking SIP & IN January 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org, and except as set + forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the ISOC's procedures with respect to rights in ISOC Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Gurbani, et al. Informational [Page 25] + |