INTERNET-DRAFT V. Gurbani May 30, 2000 Lucent Technologies, Inc. Expires: November, 2000 SIP enabled IN Services - an implementation report Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT SIP [1] is an excellent vehicle for the converged network services of the future; of that there is no doubt. However, even in the near term, SIP is an equally powerful solution to bridge the PSTN and VoIP networks by its application to the IN (Intelligent Network) services domain. This Internet Draft details our experiences of applying SIP to the said domain. We use a SIP call controller to execute IN services by mapping IN call model states to those of the SIP protocol state machine [2]. [2] uses the notion of call model integration [3], an example of which is to use the IN call model as a canonical call model to map the protocol states of IP (Internet Protocol) based call controllers (SIP, H.323,...) to those of the IN call model. 1. Introduction V.Gurbani Internet Draft [Page 1] SIP enabled IN Services - an implementation report As the PSTN and VoIP networks converge, availability of existing services and the applicability of novel services is emerging to be the key differentiator between the two networks. IN stands to gain from this differentiation since it already disassociates service access and fulfillment from the call signaling mechansim. While these new converged services are being defined and worked upon, SIP can be used as the next generation signaling protocol to provide access to existing PSTN-services from IP (or SIP) endpoints. The IN call model is a half call model (so called because it has two halves: originating half or O_BCSM [Originating Basic Call State Model] and terminating half or T_BCSM [Terminating Basic Call State Mode]). It rigorously defines the PICs (point-in-call) -- corresponding to states in the call model -- and DPs (detection points) -- points in the model where call processing is suspended and other actions (initiation of queries normally related to service fulfillment) are invoked [4]. One simple manner for accessing IN services from SIP networks would be to overlay an IN call model on a SIP protocol state machine [2]. This has the benefit of accessing existing IN services using the same DPs (detection points) from the same well known PIC (point in call) of the IN call model. From the viewpoint of other IN elements like the SCP (service control point), the fact that the request originated from a SIP server versus a call processing function on a traditional switch is immaterial. Thus, it is important that the SIP server be able to provide features normally provided by the traditional switch, including operating as a SSP for IN features. The SIP server should maintain call state and trigger queries to IN-based services, just as traditional switches do. We have authored two pieces of software to demonstrate this mapping concept. First is a portable IN call model which is a software layer written in C++, and the second is a proxy SIP server that has hooks to this portable IN call layer. The IN call model, embodied by our portable IN call layer, can be mapped to IN-incapable call controllers, of which a SIP proxy and H.323 are good examples. Once the mapping between the IN call model states and the native protocol state machine (SIP, or Q.931 in the case of H.323) has been specified, the portable IN call layer is then embedded into the native protocol state machine (for the duration of this I-D, we will assume that the native protocol state machine is SIP). We have applied the portable IN call layer to two IP call controllers so far: Q.931 in H.323 [5] and SIP [2]. In both cases, we were able to provide the same set of services without source-level changes to V.Gurbani Internet Draft [Page 2] SIP enabled IN Services - an implementation report the portable IN call layer, thus demonstrating the power of this approach (well, actually we had to make one minor change in the portable IN call layer when using SIP as the IP call controller - we had to increase the buffer size used to store a call ID; SIP Call-IDs tend to be much longer then H.323 CRVs). In a SIP network with access to IN services, call requests are received by the SIP proxy, which intimates the portable IN call layer of this event through a functional interface, passing it parameters that include the caller's E.164 number, the callee's E.164 number and other pertinent information. The portable IN call layer then steps through its PICs and if a DP is armed, it will trigger the service provided by that DP. Services are executed by the portable IN call layer sending a TCAP (or INAP) request and transmitting it (over IP) to the SCP. The SCP responds with the pertinent answer encoded within the response TCAP (or INAP) payload. Once the call request has been thus serviced, control is returned back to the SIP proxy, which continues processing the call. The portable IN call layer and the SIP proxy have to execute in lockstep since events can occur in either of the state machines to effect the other. For example, if the caller hangs up, the SIP proxy will get notified of this event first. It must now propagate this event to the IN call layer so that it (the IN call layer) can clean up any state associated with that call. Likewise, if the IN call layer gets the notification to drop the call as a result of a service execution, it must notify the SIP proxy so it can clean state associated with the call. The rest of this paper is organized as follows: section 2 details the network topology used in our laboratory to program and test these concepts. Section 3 details the IN services provided by the IN- capable SIP proxy server (including SIP call flows). Section 4 discusses some issues we encountered during implementation and outlines some next steps for this work. 2. Network Topology Our laboratory setup consisted of several SIP endpoints (each running a SIP user agent client and a SIP user agent server), a SIP proxy server fortified with the portable IN call layer, and a next- generation SCP simulation engine which serviced requests. Figure 1 depicts this setup: V.Gurbani Internet Draft [Page 3] SIP enabled IN Services - an implementation report Local Area Network (10Mbps Ethernet) ==o==================o================o======== | | | +-+--------+ +---+------+ +---+------+ |SIP proxy | +---------+ | | SCP sim- | |server | +--------+ |-+ | ulation | +----------+ | SIP UA |-+ +----------+ +--------+ Figure 1: Laboratory setup There are other elements that have been omitted from the above figure for brevity. However, for the sake of completeness, these included a graphical representation of the transitioning call states (very helpful for debugging and explaining to viewers), and simple service provisioning using the Apache web server. Each SIP UA was configured, upon bootup, to register with the SIP proxy server using an E.164 number. This is important; the intent is to mimic IN services offered on the PSTN, hence endpoints are identified using E.164 numbers and not the more powerful and generic email-like SIP URI. The SCP was configured with the data pertaining to all the services (see next section) and users in this system. 3. SIP-enabled IN services We demonstrated the following IN services from SIP endpoints: 1) Originating call screening (OCS) 2) Local number portability (LNP) 3) Call forwarding 4) Calling name delivery Note that these services fall within the "signaling" realm; i.e. they do not involve any dependencies on media (tone detection, for example). In general, services that depend entirely on the signaling aspect are the easiest to realize. When we embarked on this work, the SIP INFO method extension [6] was not yet ripe, so we focused our attention to services that fell within the signaling realm only. We now taxonomize the services outlined above on two criterion: where in the IN BCSM half they occur (O_BCSM or T_BCSM) and the DP that needs to be armed for these services: V.Gurbani Internet Draft [Page 4] SIP enabled IN Services - an implementation report Occurs in/DP Service -------------+------------------------------------------------ O_BCSM/5 | OCS O_BCSM/7 | LNP T_BCSM/22 | Call forwarding T_BCSM/22 | Calling name delivery Table 1: IN Service taxonomy and precedence Notice that many services can be triggered from the same detection point. In such cases, a precedence rule is necessary. The precedence we established in our call model for the two services triggered from T_BCSM/DP 22 is provided in Table 1. The portable IN call layer triggered each of these services in the order that they are listed in the table. SIP call flows for the services follows next. 3.1 OCS OCS is a service whereby the O_BCSM ensures that the caller is authorized to initiate a call to the dialed number (or the callee). The OCS service is accessed by arming the Collected_Info trigger (DP 5) of the O_BCSM of the IN call model. When the SIP proxy server receives an INVITE request, it extracts the Request-URI (an E.164 number) of the party being invited and sends it, along with other information, to the portable IN call layer. The IN call layer proceeds through its PICs and on reaching an armed DP 5, triggers a TCAP (or INAP) request to the SCP. The SCP analyzes this request and instructs the SIP proxy server on what to do next with the call. The SCP has access to a user profile database which contains, among other fields, a field which restricts the caller from making certain calls (for example, 900 number calls, which in the US are billed at higher-than-normal rates; hence the need to restrict such calls). In the call flow examples below, the letters C, S, N are used to identify the SIP User Agent Server (caller), the SIP Proxy server running the portable IN call layer, and the next hop SIP proxy, respectively. Example 1: C wants to initiate a call to a 900 number: C->S: INVITE sip:9005551111@lucent.com;user=phone From: "Vijay K. Gurbani" To: sip:9005551111@lucent.com Via: SIP/2.0/UDP temphost1.lucent.com V.Gurbani Internet Draft [Page 5] SIP enabled IN Services - an implementation report Call-ID: CC6677901AF@temphost1.lucent.com CSeq: 1 INVITE ... S extracts the SIP Request-URI (sip:9005551111@lucent.com), the value of the To: and From: fields and sends them to the portable IN call layer. The IN call layer formats a TCAP (or INAP) request, sends it to the SCP, and is told that the caller does not have sufficient privileges to continue with the call. S sends the following SIP (final) response to C: S->C: SIP/2.0 403 Forbidden From: "Vijay K. Gurbani" To: sip:9005551111@lucent.com Via: SIP/2.0/UDP temphost1.lucent.com Call-ID: CC6677901AF@temphost1.lucent.com CSeq: 1 INVITE Content-Length: 0 3.2 LNP Number portability can be classified into three types: Service Portability, Service Provider Portability, and Location Portability [7]. We focused our efforts on Service Provider portability only. Service Provider portability is defined as the "ability of an end user to retain the same E.164 international public telecommunication number when when changing from one service provider to another." [7]. The LNP service is accessed by arming the Analysed_Info trigger (DP 7) of the O_BCSM of the IN call model. Example 2: C calls a number, which has been ported: C->S: INVITE sip:6302240216@lucent.com;user=phone From: "Vijay K. Gurbani" To: sip:6302240216@lucent.com Via: SIP/2.0/UDP temphost1.lucent.com Call-ID: CB6677901AF@temphost1.lucent.com CSeq: 1 INVITE ... When the SIP proxy server receives an INVITE request, it extracts the Request-URI (an E.164 number) of the party being invited and sends it, along with other information, to the portable IN call layer. The IN call layer proceeds through its PICs and on reaching an armed DP 7, triggers a LNP TCAP (or INAP) request to the SCP. The SCP analyzes this request, and after consulting a LNP database returns V.Gurbani Internet Draft [Page 6] SIP enabled IN Services - an implementation report the new routing number to the SIP proxy server. The SIP proxy server forwards the request to the next hop SIP server, after modifying the Request-URI to include the new routing number: S->N: INVITE sip:6307130184@lucent.com;user=phone From: "Vijay K. Gurbani" To: sip:6302240216@lucent.com Via: SIP/2.0/UDP isip.ih.lucent.com Via: SIP/2.0/UDP temphost1.lucent.com Call-ID: CB6677901AF@temphost1.lucent.com CSeq: 1 INVITE ... The determination of the next hop SIP server can be done various means. In our case, the next hop SIP server happened to be a properly registered User Agent Server belonging to the callee, so the INVITE was simply proxied to it. The DP 7 logic for LNP is not strictly IN -- in reality, the new routing number identifies a switch, not the actual called party, so the original number must also be retained in the INVITE. The new routing number thus replaces the number in the Request-URI but not the number in the "To:" line. When the call reaches the switch/server identified by the routing number, it can retrieve the actual called party from the "To:" line and use it to deliver the call to the user. (This mimics the ISUP action of placing the routing number in the Called Party Address parameter and the original number in a Generic Address parameter). 3.3 Call forwarding and calling name delivery Call forwarding is another well known service whereby the incoming phone call to the callee is forwarded to another number. Unlinke the previous two services, this is a terminating side service. This service is accessed by dynamically arming the Termination_Attempt trigger (DP 22) of the T_BCSM in the IN call model. The SIP call messages for this service are similar to that of LNP (section 3.2), with the only difference being that the SIP proxy server where this processing occurs is on the terminating side of the call. Calling name delivery is also a well known service. This service is a termination side service as well, accessed by arming the Termination_Attempt trigger (DP 22) of the T_BCSM in the IN call model. Interestingly enough, in SIP, this service could turn out to V.Gurbani Internet Draft [Page 7] SIP enabled IN Services - an implementation report be a no-op if the From header of the SIP INVITE message contains the display name. If the display name is absent, then the portable IN call layer uses the E.164 address to perform a TCAP (or INAP) query against the subscriber database to retrieve this information. 4. Issues and implementation experience We uncovered a couple of SIP call signaling issues during implementation of the project, none of which were unsurmountable for the IN services we implemented. It is very much possible that the mapping of the call models in [2] may need to be adjusted to account for this. The two issues are discussed below. The first issue was the lack of acknowledgements for provisional responses in SIP. SIP proxy servers do not guarantee that 1xx messages are reliably delivered. A downstream (or upstream) SIP proxy server will proxy a 1xx response, but will not guarantee its delivery. In mapping IN call model states to SIP protocol states, [2] establishes the following mapping for O_BCSM: 100 Trying -------------> Call_Sent 180 Ringing ------------> O_Alerting and the following mapping for T_BCSM: 180 Ringing ------------> T_Alerting Clearly, IN services that are triggered from DPs leading to the Call_Sent, O_Alerting and T_Alerting PICs will not execute if the SIP proxy server running the IN call layer never receives these provisional responses. The second issue was that 1xx messages are optional; a SIP User Agent Server that receives an INVITE may choose not to send out a 100 Trying or 180 Ringing, but rather transmit a 200 OK directly (if it decides to accept a call). There are three ways to combat these problems: a) use a provisional response acknowledgement mechanism, b) use TCP as the SIP signaling transport, or c) map Call_Sent, O_Alerting and T_Alerting to a final response (200 OK). Each one has its set of drawbacks. (a) may require implementing an extension to SIP for guaranteeing reliability of provisional responses [8]. (b) may not help at all if the callee's SIP User Agent Server never emits provisional responses; and the last solution has the unfortunate side effect of loosing granularity of services when a SIP proxy receives a 200 OK. After V.Gurbani Internet Draft [Page 8] SIP enabled IN Services - an implementation report all, which service takes precedence in this case? The one associated with Call_Sent, O_Alerting, or O_Active (or T_Alerting and T_Active)? Luckily, in our implementation, we were able to sidestep this problem entirely since none of the services we were interested in used these PICs. Other issues that we did not specifically address, but would like to document for further prototypes related to this work include: o Should enhancement of IN itself be investigated (to return non- digit URIs, for example)? o Does the IN call model constrain SIP or H.323 call controllers to operate in a particular manner? (especially in the assumption that in a switched circuit network, the basic call processing and bearer control functions are located in the same equipment -- an assumption that does not hold for Internet telephony) o Providing originating side services from an H.323 endpoint and terminating side services on a SIP endpoint. The H.323 endpoint will be using a H.323 Gatekeeper running the portable IN call layer and the SIP endpoint will be using a SIP proxy server running the portable IN call layer. o Using services that involve the media or mid-call triggers. Now that a SIP extension is being proposed to propagate mid-call events [6], such services are rendered possible. 5. Acknowledgements Thanks to Janet Douglas, a co-implementor of this effort. Also, many thanks to Igor Faynberg, Al Varney and all the others who reviewed the draft and provided valuable insights, inputs, and comments. 6. Abbreviations: V.Gurbani Internet Draft [Page 9] SIP enabled IN Services - an implementation report DP Detection Point IN Intelligent Network INAP Intelligent Network Application Protocol IP Internet Protocol or Intelligent Peripheral LNP Local Number Portability O_BCSM Originating Basic Call State Model OCS Originating Call Screening PIC Point In Call PSTN Public Switched Telephone Network SCP Service Control Point SIP Session Initiation Protocol SSP Service Switching Point T_BCSM Terminating Basic Call State Model 7. References [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", IETF Standards RFC 2543, March 1999. [2] Vijay K. Gurbani, Lucent Technologies, Inc. "Accessing IN services from SIP networks", IETF I-D ; work in progress; expires November 2000. [3] Kumar Vemuri, Lucent Technologies, Inc. "Call Model Integration Framework", IETF I-D ; work in progress; expires June 20, 2000. [4] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network Distributed Functional Plane Architecture," International Telecommunications Union Standardization Section, Geneva. [5] T.C. Chiang, J. Douglas, V. Gurbani, et. al. "IN Services for (Converged) Internet Telephony". IEEE Communication Magazine special issue on Intelligent Networks, to be published in June 2000. [6] Steve Donovan, MCI Worldcom. "The SIP INFO Method", IETF I-D ; March 2000, work in progress. [7] ITU-T, Supplement 3 to ITU Q-Series Recommendations: Number Portability - Scope and capability set architecture, May 1998. [8] Jonathan Rosenberg and Henning Schulzrinne, "Reliability of Provisional Responses in SIP", IETF I-D ; work in progress; expires July 2000. 8. Author's Address Vijay K. Gurbani E-mail: vkg@lucent.com Telephone: +1-630-224-0216 V.Gurbani Internet Draft [Page 10] SIP enabled IN Services - an implementation report Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA INTERNET-DRAFT Expires November 2000 V.Gurbani Internet Draft [Page 11]