One document matched: draft-gurbani-iptel-sip-to-in-01.txt
Differences from draft-gurbani-iptel-sip-to-in-00.txt
Accessing IN services from SIP networks
<draft-gurbani-iptel-sip-to-in-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
In Internet telephony, the call control functions of a traditional
circuit switch are replaced by a IP-based call controller that must
provide features normally provided by the traditional switch,
including operating as a SSP for IN features. A traditional switch
is armed with an IN call model that provides it a means to reach out
and make service decisions based on intelligence stored elsewhere.
Internet call controllers, by contrast, do not have an IN call model.
Furthermore, since there are many Internet call models with varying
number of states than the IN call model, there has to be a mapping
from the IN call model states to the equivalent states of the
Internet call model if existing services are to be accessed
transparently. To leverage the existing IN services from the
Internet domain, this draft proposes a mapping from the states of the
IN call model to the states of SIP, an Internet call signaling
protocol.
V.Gurbani Internet Draft [Page 1]
Accessing IN services from SIP networks
1. Introduction
In Internet telephony, the call control functions of a traditional
circuit switch are replaced by a device referred to, in different
contexts, as a call agent, a SIP server, a H.323 Gatekeeper, a
feature server, or a soft- switch. This device (which we will simply
refer to as a call agent) is an IP entity that coordinates the calls.
Unlike a traditional switch armed with an IN call model, the Internet
call model on a call agent does not contain IN specific triggers and
states. Also, the number of states in an Internet call model are
much less than those in the IN call model. Currently, there are at
least two different Internet call models - H.323 and SIP - both with
varying number of states than the IN call model. To be precise, the
term Internet call model is a misnomer; a better term is a protocol
state machine.
In order to access IN services transparently using Internet
telephony, the Internet protocol state machine must be mapped to the
IN call model. This has the added benefit of accessing existing IN
services using the same detection points (DPs) from the same well
known point in call (PIC). From the viewpoint of other IN elements
like the service control point (SCP), the fact that the request
originated from a call agent versus a call processing function on a
traditional switch is immaterial. Thus, it is important that the
call agent be able to provide features normally provided by the
traditional switch, including operating as a SSP for IN features.
The call agent should also maintain call state and trigger queries to
IN-based services, just as traditional switches do.
The IN call model consists of two halves: the Originating call model
and the Terminating call model. If the called and calling party
share the same switch, the originating call model is assigned to the
calling party and the terminating call model is assigned to the
called party. If the call has to go through multiple switches to get
to the destination, each of the intervening switch will run the two
halves of the call model, with the destination switch's terminating
call model providing services to the called party. While this model
has worked well for traditional circuit-based switching, it may not
be desirable to implement it in an analogous manner on an Internet
call model. A later section will discuss this issue in more detail.
The most expeditious manner for providing existing IN services in the
Internet telephony domain would be to use the deployed IN
infrastructure as much as possible. The logical point in the
Internet telephony domain to tap into for accessing existing IN
services is the call agent. However, the call agent, as we have
V.Gurbani Internet Draft [Page 2]
Accessing IN services from SIP networks
discovered above, does not run an IN call model. Instead, the
various Internet call agents run their respective native protocol
state machines for call signaling - either Q.931 in H.323 or SIP.
The trick, then, is to overlay this state machine with an IN layer
such that call acceptance and routing is performed by the native
state machine and services are accessed through the IN layer using an
IN call model. This draft proposes using SIP as the native state
machine and accessing IN services by mapping SIP states to the IN
call model states. Doing this enables Internet access to well known
telephony services such as number translation, screening, call
routing and distribution services, which mostly occur before call
setup is complete.
The rest of the paper is organized as follows: Section 2 briefly
discusses the IN and SIP call models. Section 3 discusses some
issues that necessarily arise from mapping call models. Section 4
outlines some possible SIP/IN architectures. Section 5 establishes a
mapping between the IN call model and SIP. Section 6 discusses a few
call flows and section 7 includes a report on our current
implementation status of this I-D.
2. Call models
2.1 Overview of IN calls
In a traditional switch environment, when the SSP recognizes a call
that requires IN treatment, it temporarily suspends the call
processing and sends a query to the SCP. The SCP analyzes the
information it received from the SSP and makes a decision on how to
continue processing the call. The decision is sent to the SSP, which
now continues with further call processing. It is important to
realize that IN treatment for a call is not limited to simple
request-reply transactions. Including simple querying, the following
are the major functions that are part of ITU-T CS-1 and CS-2 [1]:
2.1.1 Querying
The SSP sends a query to the SCP over SS7 in form of a INAP query
message. The SCP analyzes the information in the INAP query and
sends back a INAP response to the SSP which contains instructions on
how to further handle this call.
2.1.2 Caller interaction
Instead of normal query-response, the SSP and SCP may enter an
extended interaction. After receiving a query message from the SSP,
V.Gurbani Internet Draft [Page 3]
Accessing IN services from SIP networks
the SCP may send back to the SSP a INAP conversation with permission
message. This prompts the SSP to collect additional information from
the caller, possibly by involving other IN devices like the
Intelligent Peripheral or a Service Node. The caller may send back
to the SSP dial-pulse digits or DTMF signals. Whatever the format of
the response, the SSP returns this information back to the SCP in a
INAP conversation package message.
2.1.3 Trigger activation/deactivation
Most DPs in a switch are armed by the SMF offline. However, it is
possible for the SCP to inform a switch to arm a DP for the duration
of a call. DPs armed in the former manner are said to be statically
armed and those armed in the latter manner are said to be dynamically
armed. Dynamically armed DPs remain in effect for the duration of
that particular call [2].
2.1.4 Response processing
The SSP, upon receiving a INAP response message from the SCP, must
take the appropriate actions such as routing the call, redirecting
the call, disconnecting the call, playing announcements to the
caller, and so on. The SCP may further control the SSP by requesting
that it be notified when the call ends, or requesting it to monitor
certain facilities.
2.2 IN call model
The IN generic basic call state model (BCSM), independent of any
capability sets, is divided into two halves - an originating call
model (O_BCSM) and a terminating call model (T_BCSM) [4]. 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) [2]. 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. These are:
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
V.Gurbani Internet Draft [Page 4]
Accessing IN services from SIP networks
address.
AUTH_CALL_SETUP: switch ensures the calling party is authorize to
place call.
CALL_SENT: control of call send to terminating side.
O_ALERTING: switch waits for the called party to answer.
O_ACTIVE: connection established; communication ensue.
O_DISCONNECT: connection torn down.
O_EXCEPTION: switch detected an exceptional condition.
T_BCSM has 8 PICS. These are:
T_NULL: starting state; call does not exist yet.
AUTH_TERM_ATT: switch verifies whether call can be send 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. ringing the line.
T_ACTIVE: connection established; communications ensue.
T_DISCONNECT: connection torn down.
T_EXCEPTION: switch detected an exceptional condition.
The state machine for O_BCSM and T_BCSM is provided in [2] page 98
and 103 respectively. This state machine will be used for subsequent
discussion when the IN call states are mapped into SIP.
It is beyond the scope of this document to explain all PICs and DPs
in an IN call model. 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 [2].
2.3 SIP call model
SIP is a lightweight signaling protocol gaining ground and adherents
in the Internet telephony world. SIP has 6 methods -- INVITE, ACK,
OPTIONS, BYE, CANCEL, and REGISTER -- and various response codes
divided among the following 6 classes:
Class Meaning
------------------------
1xx Informational
2xx Success
3xx Redirection
4xx Request failure
5xx Server failure
6xx Global failure
V.Gurbani Internet Draft [Page 5]
Accessing IN services from SIP networks
Table 1: SIP response codes
To establish a mapping between IN call state and SIP, the SIP
protocol state machine can be viewed as essentially consisting of an
INVITE message, interim response codes for the invitation ("100
Trying" or "180 Ringing"), an acceptance (or a decline) of the INVITE
message, and an acknowledgement for the acceptance (or decline). If
the invitation was accepted, SIP provides a BYE message for signaling
the end of the call.
It is beyond the scope of this document to specify SIP to its fullest
extent. It is assumed that the reader has some familiarity with SIP.
More information can be found in [3]
3. Issues in IN call model mappings
One way in which IN services can be invoked transparently from a SIP
server processing a telephony call is to overlay the SIP protocol
state machine with the IN call model. Thus the call receives
treatment from two call models, both working in synchrony; the SIP
state machine handles the acceptance and final delivery of the call
while the IN call model interfaces with the IN to provide services
for the call. Figure 1 demonstrates the SIP server accepting a call,
notifying the IN call handling layer of this event; the IN call
handling layer interfaces with the IN elements to provide services
for the call, ultimately informing the SIP server on how to deliver
the call:
+-----+
| S |
| C |
+---------->| P |
| +-----+
|
V
+------------------------+
| IN call handling |
+------------------------+
| ^ Process |
| / \ call |
| | |
--------->| SIP call handling |----------->
Accept +------------------------+ Deliver call
Call
Figure 1: IN call model overlayed on SIP
V.Gurbani Internet Draft [Page 6]
Accessing IN services from SIP networks
The notion of feature interaction, i.e. the notion about where a call
gets its features serviced from -- SIP or IN -- is not discussed
here. SIP itself has a rich set of features that can be applied on a
call by call basis, as does IN. What we are interested here in
accessing IN services from a SIP-based network, thus the underlying
assumption is that IN is servicing the call by providing it features,
and SIP is simply routing the call based on the decisions made by the
IN layer.
Another fundamental problem here lies in the notion of a call state.
The IN call model is necessarily a stateful one. A SIP server can
operate in either stateful or stateless mode, depending on the needs
of the application. For speed, reliability and scalability, SIP
servers may be run in the stateless mode. The duration and amount of
state maintained at a SIP server are small compared to the
traditional telephone network, where the switch must maintain the
call state for the entire duration of the call. For a SIP server to
run in the call-stateful mode, it has to be configured such that it
remains in the signaling path till the call is disconnected. This is
accomplished using the Record-Route header field.
4. SIP/IN architecture
In order to apply the stateful IN call model to a SIP server, the
originating and terminating SIP network servers must run in call-
state aware mode and have the IN call model layer working in
conjunction with SIP as depicted in Figure 1. Other intervening SIP
servers may remain stateless and have no need to run the IN call
model layer. The originating and terminating SIP network servers
mimic the originating and terminating switches in a traditional phone
network. IN services accessed through DPs on originating or
terminating side can now be handled by the IN layer on the
originating or terminating SIP server. Figure 2 demonstrates this:
V.Gurbani Internet Draft [Page 7]
Accessing IN services from SIP networks
+---+ +---+
| S | | S |
| C |<--+ +-->| C |
| P | | | | P |
+---+ | | +---+
| |
+-------|-------------------------------------|-------+
| | SIP network | |
| V V |
| +-------+ +-------+ |
| | IN | | IN | |
| +-------+ +-------+ +-------+ +-------+ |
Calling | | O SIP |---->| C SIP | ... | C SIP |---->| T SIP | | Called
Party ----|>+-------+ +-------+ +-------+ +-------+-|---> Party
| |
+-----------------------------------------------------+
Legend:
O SIP: Originating SIP network server, running IN call model layer
T SIP: Terminating SIP network server, running IN call model layer
C SIP: Core SIP network servers (may be proxy or redirect)
IN: IN layer
Figure 2: IN-controlled SIP network
There are three other points worth mentioning in Figure 2:
1) If the called party and the calling party are handled by the same
SIP server, both halves of the IN call model will run on that server.
This is analogous to the traditional telephone network.
2) In the traditional telephone network, the interexchange switches
can run both halves of the call model. This can also be accomplished
in the SIP network if desired. Figure 2 shows the IN call model
running on originating and terminating SIP servers. However, any of
the core SIP servers could also have hosted the IN call model if
needed.
3) If the called party and calling party are handled by different SIP
network servers, each with its own IN layer, the IN call state
information has to be propagated between these servers. This draft
does not include any information on such a transaction, except to
note that there are other protocols like SIP+ which address such
problems. Or in fact, the IN layers of the originating and
terminating SIP servers can communicate directly with each other
V.Gurbani Internet Draft [Page 8]
Accessing IN services from SIP networks
using ISUP over IP to share call state between themselves.
Figure 2 showed an end-to-end SIP network, with SIP servers running
the IN call model reaching out to the SCP for service logic. Figure
3 shows a SIP network providing services from the SCP through the IN
call model and routing the call to the PSTN. In this example, it is
assumed that both halves of the IN call model are running on the same
SIP server:
+---+
| S |
| C |<--+
| P | |
+---+ |
|
+-------|-----------------+ +---------- ...
| | SIP network | | PSTN network
| V | |
| +-------+ | |
| | IN | | |
| +-------+ +-------------+ |
Calling | | O SIP |------>| SIP Gateway |------->|
Party ----|>+-------+ +-------------+ |
| | |
+-------------------------+ +---------- ...
Figure 3: SIP network with PSTN gateway
5. Mapping call states
At first glance, it would appear that mapping a 19 PIC and 35 DP IN
call model into SIP is a losing proposition. However, such is not
the case. In fact, certain IN services like freephone, originating
call screening, caller name identification, are very easy to
implement. By and large, IN services that have a "query-response"
nature are easily translated to SIP. On the other hand, services
involving the media path (e.g. "prompt-and-collect", play
announcements during the call) are comparitively harder to implement;
and in fact there may be no general purpose solution for these class
of services yet. In fairness, this is not a problem inherent with
SIP itself, rather this is an artifact of the exiting circuit-
switched telecommunication infrastructure which involves the media
between the communicating entities for such services.
IN states (listed in Section 2.3) will be mapped to the appropriate
SIP methods or response codes (also listed in Section 2.3). While
V.Gurbani Internet Draft [Page 9]
Accessing IN services from SIP networks
mapping call states from SIP to IN, it is important to note that
there will not be a 1-to-1 mapping. IN call states have been
developed for a circuit domain, hence domain specific PICs like
SELECT_ROUTE which selects an outgoing trunk facility, may not have
an equivalent analogy in a packet world.
5.1 SIP and O_BCSM
The 11 PICs of O_BCSM come into play when a call request (SIP INVITE
message) arrives from a SIP UAC to an originating SIP server running
the IN call model. This SIP server will create a O_BCSM object and
initialize it in the O_NULL PIC. The next five IN PICs --
AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO, SELECT_ROUTE and
AUTH_CALL_SETUP -- with the exception of SELECT_ROUTE can all be
mapped to the SIP INVITE message. In IN, SELECT_ROUTE selects the
actual physical route. This, of course, does not have an equivalent
in SIP since the SCP is expecting trunk IDs and SIP is dealing with
URLs.
The SIP INVITE message has enough functionality to absorb these five
PICs as described below:
AUTH_ORIG_ATT- In this PIC, an IN SSP has detected that someone
wishes to make a call. Under some circumstances (e.g. the user is
not allowed to make calls during certain hours), such a call cannot
be placed. SIP has the ability to authorize the calling party
using a set of policy directives 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.
COLLECT_INFO - This PIC is responsible for collecting a a dialing
string from the calling party. The SIP server can detect a
malformed address and may send the calling party a "484 Address
Incomplete" message and remain in this state until a valid "dial
string" is received. Once it has obtained a valid dial string, 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 service such as freephone,
LNP, OCS, etc. occur during this PIC. The SIP server can send the
SIP URI in the To: field to the IN layer to have it analyzed. If
the analysis succeeds, the IN layer is instructed to enter the next
PIC, SELECT_ROUTE.
SELECT_ROUTE - There is no SIP analogue of this PIC. It is
basically a fall- through case to the next PIC.
V.Gurbani Internet Draft [Page 10]
Accessing IN services from SIP networks
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 the above 5 PICs have been successfuly negotiated, the SIP server
running the IN call model now sends the SIP INVITE message to the
next hop server. If the SIP server running the IN call layer gets
back a "100 Trying" message for that call, it can instruct the IN
layer to enter enter the next PIC, CALL_SENT. In IN terms, the
control over the establishment of the call has been transferred to
the T_BCSM object, and the O_BCSM object is waiting for a signal
confirming that either the call has been presented to the called
party or that the called party cannot be reached for a particular
reason.
When the SIP server running the IN call layer gets back a "180
Ringing" for the call, it now instructs the IN layer to enter the
next PIC, O_ALERTING. At this point, O_BCSM is waiting for the
called party to answer. Assuming the called party answers, the SIP
server running the IN layer receives a "200 OK". The receipt of this
message is followed by the SIP server instructing the IN layer to
enter the next PIC, O_ACTIVE. The call is now active.
When either of the party hangs up, the SIP server running the IN call
layer receives a SIP BYE message. Since it is running in call-
stateful mode, it can correlate the BYE message with the call that
needs to be torn down. The SIP server instructs the IN layer to
enter its next PIC, O_DISCONNECT and perform cleanup. Subsequently,
the state of the call in the SIP server itself is also destroyed.
Figure 4 below provides a visual mapping from the SIP server 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.
V.Gurbani Internet Draft [Page 11]
Accessing IN services from SIP networks
SIP O_BCSM
+----------------+ +-----------------+
| INVITE |======================>| O_NULL |
+--+-------------+ +--------+--------+
| /\ |
| || |
| || +--------V--------+
| || | AUTH_ORIG_ATT |
| || +--------+--------+
| || |
| || |
| || +--------V--------+
| ||<======================== | COLLECT_INFO |
| || +--------+--------+
| || |
| || |
| || +--------V--------+
| || | ANALYSE_INFO |
| || +--------+--------+
| || |
| || |
| || +--------V--------+
| || | SELECT_ROUTE |
| || +--------+--------+
| || |
| || |
| || +--------V--------+
| ||========================= | AUTH_CALL_SETUP |
| +-----------------+
|
+--V--------------+ +-----------------+
| 100 Trying |=====================>| CALL_SENT |
+--+--------------+ +--||-------------+
| /\ ||
| || ||
| ||=============================||
|
+--V--------------+ +-----------------+
| 180 Ringing |=====================>| O_ALERTING |
+--+--------------+ +--||-------------+
| /\ ||
| || ||
| ||=============================||
|
+--V--------------+ +-----------------+
V.Gurbani Internet Draft [Page 12]
Accessing IN services from SIP networks
| 200 OK |=====================>| O_ACTIVE |
+-----------------+ +-----------------+
------------------------------------------------------------
Communication established; call active
------------------------------------------------------------
+-----------------+ +-----------------+
| BYE |=====================>| O_DISCONNECT |
+-----------------+ +--||-------------+
/\ ||
|| ||
||==============================||
Legend:
| Communication between
| states in the same
V protocol
======> Communication between IN layer and SIP
Figure 4: Mapping from SIP to O_BCSM
5.2 SIP and T_BCSM
The T_BCSM object is created when a SIP INVITE message makes its way
to the terminating SIP server running the IN layer. The SIP server
creates the T_BCSM object and initializes it to the T_NULL PIC.
The IN layer is instructed to enter the next PIC, AUTH_TERM_ATT,
during which the fact that the called party wishes to receive the
present type of call is ascertained. Once a positive indication is
received, the IN layer is instructed to enter the next PIC,
SELECT_FACILITY. This PIC does not readily map into a SIP model.
The intent of this PIC, in traditional circuit networks, is to select
a line or a trunk to reach the called party. This, of course, does
not apply in SIP, hence this PIC is simply a fall-through to the next
PIC, PRESENT_CALL.
In a traditional circuit-switched network, PRESENT_CALL presents (via
ISUP ACM or Q.931 Alerting messages) the call to the called party.
When the SIP server sends out the INVITE to the UAS, it instructs the
IN layer to enter this state. The IN layer will remain in this state
until the SIP server gets back a "180 Ringing", whereupon it
instructs the IN layer to enter the next state, T_ALERTING.
V.Gurbani Internet Draft [Page 13]
Accessing IN services from SIP networks
T_ALERTING "alerts" the called party by ringing the phone. When the
SIP server receives a "200 OK", it instructs the IN layer to enter
the next PIC, T_ACTIVE. The call is now active.
When either of the party hangs up, the SIP server running the IN call
layer receives a SIP BYE message. Since it is running in call-
stateful mode, it can correlate the BYE message with the call that
needs to be torn down. The SIP server instructs the IN layer to
enter its next PIC, T_DISCONNECT and perform cleanup. Subsequently,
the state of the call in the SIP server itself is also destroyed.
Figure 5 below provides a visual mapping from the SIP server protocol
state machine to the terminating half of the IN call model:
V.Gurbani Internet Draft [Page 14]
Accessing IN services from SIP networks
SIP T_BCSM
+----------------+ +-----------------+
| INVITE |======================>| T_NULL |
+--+-------------+ +--------+--------+
| /\ |
| || |
| || +--------V--------+
| || | AUTH_TERM_ATT |
| || +--------+--------+
| || |
| || |
| || +--------V--------+
| || | SELECT_FACILITY |
| || +--------+--------+
| || |
| || |
| || +--------V--------+
| ||========================= | PRESENT_CALL |
| +-----------------+
|
+--V--------------+ +-----------------+
| 180 Ringing |=====================>| T_ALERTING |
+--+--------------+ +--||-------------+
| /\ ||
| || ||
| ||=============================||
|
+--V--------------+ +-----------------+
| 200 OK |=====================>| T_ACTIVE |
+-----------------+ +-----------------+
------------------------------------------------------------
Communication established; call active
------------------------------------------------------------
+-----------------+ +-----------------+
| BYE |=====================>| T_DISCONNECT |
+-----------------+ +--||-------------+
/\ ||
|| ||
||==============================||
Legend:
| Communication between
V.Gurbani Internet Draft [Page 15]
Accessing IN services from SIP networks
| states in the same
V protocol
======> Communication between IN call model and SIP
protocol state machine
Figure 5: Mapping from SIP to T_BCSM
6. Call flows
Two examples are provided here to understand 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
a 800 freephone number:
INVITE sip:18005551212@gateway.lucent.com SIP/2.0
From: sip:16309795218@il0015vkg1.ih.lucent.com
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
To: sip:18005551212@lucent.com
Call-ID: 67188121@lucent.com
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 in 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 server, with
the freephone number replaced by the translated number:
INVITE sip:+1-630-224-0216@gateway.lucent.com SIP/2.0
From: sip:16309795218@il0015vkg1.ih.lucent.com
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
Via: SIP/2.0/UDP sip-in1.ih.lucent.com
To: sip:18005551212@lucent.com
Call-ID: 67188121@lucent.com
CSeq: 1 INVITE
In the next example, a SIP UAC originates a call request destined to
a 900 number:
INVITE sip:19005551212@gateway.lucent.com SIP/2.0
From: sip:16302240216@lucent.com
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
V.Gurbani Internet Draft [Page 16]
Accessing IN services from SIP networks
To: sip:19005551212@lucent.com
Call-ID: 88112@lucent.com
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 in
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 using SIP
"403 Forbidden" response status code:
SIP/2.0 403 Forbidden
From: sip:16302240216@lucent.com
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
To: sip:19005551212@lucent.com
Call-ID: 88112@lucent.com
CSeq: 1 INVITE
7. Implementation Status
We are currently implementing the idea presented in this IETF I-D.
Our laboratory setup consists of a SIP proxy server and 3 SIP
clients, two of which are hosted on multi-media personal computers,
and the third client co-resides on a media gateway connected to the
PSTN. The SIP proxy server, the multi-media personal computers, and
the media gateway are all connected on a 10-BaseT local area network.
The media gateway is connected to the PSTN through an analog PRI
line.
We have written a portable IN Call Model in C++ and are in the
process of integrating it into the SIP server by mapping the IN PICs
to the SIP server protocol state machine as outlined in figures 4 and
5.
8. Acknowledgements
Many thanks to Alec Brusilovksy, Janet Douglas, Igor Faynberg,
Jonathan Rosenberg, John Stanaway, and Kumar Vemuri for their
insights, inputs, and comments.
9. Abbreviations:
V.Gurbani Internet Draft [Page 17]
Accessing IN services from SIP networks
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
PRI Primary Rate Interface
PSTN Public Switched Telephone Network
SCP Service Control Point
SIP Session Initiation Protocol
SMF Service Management Function
SS7 Signaling System 7
SSP Service Switching Point
T_BCSM Terminating Basic Call State Model
UAC (SIP) User Agent Client
UAS (SIP) User Agent Server
10. References:
[1] Uyless Black, "The Intelligent Network: Customizing
Telecommunications and Services," Prentice Hall, 1998.
[2] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
Intelligent Network Standards: Their Application to
Services," McGraw-Hill, 1997.
[3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP: Session Initiation Protocol", IETF Standards RFC
2543, March 1999.
[4] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network
Distributed Functional Plane Architecture," International
Telecommunications Union Standardization Section, Geneva.
10. Author's Address
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 June 17, 2000
| PAFTECH AB 2003-2026 | 2026-04-23 16:11:34 |