Internet DRAFT - draft-gurbani-iptel-sip-in-imp
draft-gurbani-iptel-sip-in-imp
INTERNET-DRAFT Vijay Gurbani
November 10, 2000 Lucent Technologies, Inc.
Expires: May, 2001
SIP enabled IN Services - an implementation report
<draft-gurbani-iptel-sip-in-imp-01.txt>
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. Section 5 outlines some of
the security considerations.
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" <sip:vkg@lucent.com>
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" <sip:vkg@lucent.com>
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" <sip:vkg@lucent.com>
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" <sip:vkg@lucent.com>
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. Security Considerations
This work did not take in account any extra security considerations
beyond those identified in [9].
6. 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.
7. 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
8. 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 <draft-gurbani-iptel-sip-to-in-03.txt>;
work in progress; expires May 2001.
[3] Kumar Vemuri, Lucent Technologies, Inc. "Call Model Integration
Framework", IETF I-D <draft-vemuri-cmi-framework-00.txt>; 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, June 2000.
[6] Steve Donovan, MCI Worldcom. "The SIP INFO Method", IETF I-D
<draft-ietf-sip-info-method-03.txt>; 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
<draft-ietf-sip-100rel-02.txt>; work in progress; expires
December 2000.
[9] Vijay Gurbani, "Accessing IN Services from SIP Networks", IETF I-D
<draft-gurbani-iptel-sip-to-in-03.txt>, work in progress; expires
May 2001.
8. Author's Address
V.Gurbani Internet Draft [Page 10]
SIP enabled IN Services - an implementation report
Vijay K. Gurbani
E-mail: vkg@lucent.com
Telephone: +1-630-224-0216
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA
INTERNET-DRAFT Expires May 2001
V.Gurbani Internet Draft [Page 11]
