Internet DRAFT - draft-haerens-sip-in
draft-haerens-sip-in
SIP Working Group F.Haerens
Internet Draft Alcatel Bell
Vijay K. Gurbani
Lucent Technologies
Vidhi Rastogi
Wipro Technologies
Document: draft-haerens-sip-in-01.txt Expires: January 2002
Category: Informational
SIP-IN Interworking Protocol Architecture and Procedures
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
This draft gives a first input on the SIP-IN Interworking Protocol
Architecture and Procedures for further discussion into the IETF as
part of the SIP-IN Interworking (SIN design team).
The aim of the SIP/IN Interworking is to consider the support of
existing IN-based applications in a SIP-based IP environment for
IP-Host-to-Phone calls. There are
many telephony applications based on IN: 800 (freephone), PSTN VPN,
credit card calling, to name a few.
This interworking protocol design team work requires:
- Interpreting IN Call Models for the SIP environment
- Mapping IN messages into (sequences of) SIP messages and vice
versa
- Mapping IN parameters into SIP parameters and vice versa
- Defining SIP extensions, if necessary
It was agreed that the contributors on the SIN design team should
first publish respective I-Ds, which are then used as the basis of
SIP-IN Interworking Protocol Expires: Jan 2002
the informational draft that will be the major output of the design
team.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Architecture Model
3.1 Introduction
Figure 1 shows the architecture model involving IN and SIP inter-
working. The possible groupings in the Intelligent SIP servers are
depicted.
The architecture model for accessing IN from SIP/SDP proxy/redirect
servers SHOULD have a minimal support for implementing services that
require explicit handling of the call configuration: The following
capabilities are considered:
(i) Number translation services including the storage of
related information (time of day) for e.g. portability and free
phone based services
(ii) Redirection services
(iii) Virtual Private Network services
(iv) Charging, the charging operations presently defined
need to be extended for the internet supported services including
credit card calling
(v) OA&M functions
It should be noted that the single Intelligent SIP Proxy/Redirect
Server as modeled in this figure can in fact represent several
different physical instances in the network, for example with one
Intelligent SIP server in charge of the terminal or access
network/domain, and another in charge of the interface to the
Switched Circuit Network.
Intelligent Network | IP Network
|
Service/Application |
Layer +---+ |
|SDF| +---|------+
+-+-+ | | +-----------------+
+---+<-------^ |Signaling | |Intelligent SIP |
|SCF|<------------+ |Transport | |Proxy/Redirect...|
+-+-+<-----+ | |Gateway | | Server |
SIP-IN Interworking Protocol Expires: Jan 2002
| | | | | | | and |
| +-+-+ | | | | |Bearer Controller|
+-+-+ |SRF| | | | | | +----+ |
|SSF| +->| |<-+ | | | | | |SSF | |
| | | +-+-+ | +---|---|------|-----|->|(IP)| |
+---+---- | | | | | | +----+----+ |
| |<----+ | | | | | | | |
|CCF|<--------------|-----|---|------|-----|------>|CCF | |
==| |===============|=====|==========|=====|=======|(IP)|====|==
+---+<-------+ | | | | +---|------>+--o-+ |
| | +---|------+ | +----------|------+
| | | | |
Call/Bearer | | +---|------+ | |
Layer | | | +--+ | | +----o---+
| +-----|->|MG|<---|-+ RTP | |
+------------|->| |<---|---------->| SIP |
| +--+ | | TE UA |
| Media | | |
| Gateway | +--------+
+---|------+
|
A MRF box need to be added having a Megaco interface to the CCF and
a RTP media stream.
Figure 1: A SIP based call control configuration using an
intelligent SIP Proxy/Redirect Server and Bearer Control Function
The following Architecture entities are defined in the Intelligent
Network standards:
Service Control Function (SCF):
IN functional entity that contains the IN service logic and handles
service related processing activity.
Service Switching Function (SSF):
IN functional entity that interacts with call control functions.
Call Control Function (CCF):
IN functional entity that refers to call and connection handling in
the classical sense (e.g. that of an exchange).
Service Data Function (SDF):
The SDF contains customer and network data for real-time access by
the SCF in the execution of an IN provided service.
The enhancements to the IN Architecture required for the IN/IP
interworking to support SIP/SDP systems are defined in section 3.2
while the interfaces as identified in figure 1 are given in section
3.3.
SIP-IN Interworking Protocol Expires: Jan 2002
SRF should be added
3.2 Enhancements to the Architecture Entities required for SIP-IN
interworking
The enhancements to the following architecture entities are required
for the IN/IP interworking to support SIP systems:
(i) Call Control Function: CCF(IP)
(ii) Service Switching Function: SSF(IP)
3.2.1 Call Control Function
CCF(IP) is an enhanced functional entity, responsible for handling
call signaling on either network. To support the ISUP signalling the
CCF has to implement the procedures defined by SIP-T. In that case
it appears to the IN side CCF as being another CCF. This
functionality includes handling the management of the call
processing, and call signaling.
A Call Control function could be seen as a logical switch (CCF). A
Call Control Function can require SCF assistance for these routing
decisions, e.g. for 1-800 numbers, number portability, user profile
consultation, VPN support.
The functions related to the Call Control Function Entity are:
i) A sub-function of the Call Control Function is responsible for
passing registration and admission related information to and from
IN service layer, namely the SCF responsible for managing the IP
network services. General functions that need to be supported are:
- Data filtering/parsing/mapping
- Security/Authentication
- Real Time data collection (billing/parsing)
- Configuration/dimensioning
- Flow control
ii) The Call control function contains a high layer resource manager
function call Media Gateway Control (MGC) function. This MGC
function is responsible for controlling the lower layer resource
control function referred to as Media Gateway (MG).
iii) The Call Control function inter-works with and maps to the
underlying call control signalling (SIP/SDP). The call control may
invoke media and connection operations, for legs, media, packages
independent of before or after the IN interaction. Where call
control protocol is encapsulated in SIP (e.g. ISUP in SIP-T),
mapping to this package, or the embedded protocol may also need to
be specified.
v) Circuit switching and ancillary processes are removed
SIP-IN Interworking Protocol Expires: Jan 2002
3.2.2 Service Switching Function:SSF(IP)
The enhanced SSF(IP) interacts with the IN Service Control Function
(SCF) and the IP representation of the Call Control Function (CCF),
mapping the Call Control Protocol into the INAP events trigger
points and procedures, where applicable.
This entity is responsible for passing service related information
to and from IN service layer, namely the SCF, and managing the
service control relationship. As such, the CCF may contain a SSF-
like functionality or subset thereof, to model the pre and post
conditions that are required to interact with an SCF.
The relation of the SSF(IP) to the classical SSF is as follows:
Many processes, such as call control, database and billing are
retained or enhanced.
The interface between the SIP Server and the SSF call control
processes MUST:
(i) Carry sufficient call data for the SSF to function correctly
and to deliver the necessary information to the SCF so that service
logic decisions can be made.
(ii) Allow the SCF (in combination with SSF and CCF Emulator) to
control VoIP calls (e.g. change 'B' party address) and manipulate
call information (such as presentation number).
3.3. Interfaces required for SIP-IN interworking
(i) CCF-to-CCF(IP) interface
This interface reflects the requirement to carry an ISDN control
plane signalling protocol for Multimedia services. This interface
relays the IP Multimedia user plane received from the CCF (Call
control Function). This interface is required for Voice over IP
based services.
This interface may require standardisation but is not expected to be
IN specific, work is progressing on this in ETSI TIPHON, IETF, SG11
BICC and SG16 H.246 Annex C.
(ii) SCF_to-SSF(IP) interface
This interface reflects the requirement to carry an IN-based
signalling protocol for IP and Multimedia services. This interface
relays the IP Multimedia control plane triggered events to and from
the SCF.
This interface may require standardisation.
This interface is required to trigger and control value added
services from a SIP Proxy/Redirect Server function in the IP network
e.g. for multimedia access from the Internet "dial-up" access.
SIP-IN Interworking Protocol Expires: Jan 2002
(iii) CCF(IP)-to-Media Manager (MG) interface
This interface reflects the requirement to carry an ISDN user plane
protocol for Multimedia services. This interface relays the IP
Multimedia user plane received from RTP/RTCP and is defined as the
Media Gateway Control interface.
This interface may require standardisation but is not expected to be
IN specific, work is progressing on this interface in ETSI TIPHON,
IETF, SG11 BICC and SG16.
This interface is required for Voice over IP based services.
4. Requirements for In-Interaction with SIP based systems.
Functional requirements for the IN Interaction with SIP based
systems are listed below :
- Relationship of SSF and CCF to the enhanced functional entities
introduced in Distributed Functional Plane for IN to decompose the
SIP Proxy/Redirect Server (i.e. Call Control Function CCF(IP)).
- Mapping of SIP Registration and Call Signaling messages to INAP
operations.
- Exact set of SIP Registration functionality which needs to be
visible to IN (i.e. need to be monitored or manipulated), if any.
This includes the considerations on the kind of modeling required.
- Possible Separation of the SSF/CCF into different physical
entities.
- The use of multiple SSFs, where one SSF may model the SIP
Registration protocols and another SSF model the SIP Call Control
procedures requires consideration. These SSFs may be physically
distributed.
- The configuration of trigger conditions in the SSF, manage
trigger data from an SCP in the IN domain.
- The same CCF/SSF triggering mechanism applies to processing SIP
based IN-based call. SSF is located at Intelligent SIP
Proxy/Redirect Server to interact with SCP in IN domain.
- Mapping of the CCF(IP) to the CCF.
- For a GW originated IN-based call, the SIP registration server
and the SSF may be distributed in different Intelligent SIP
Proxy/Redirect Server entities. In this case, dynamic DP arming
SHOULD be supported at MGC under the control of Intelligent SIP
Server;
- The Definition of State Driven Events in the SIP Registration
and SIP Call Control Protocols in, there relationship to the CCF
SIP-IN Interworking Protocol Expires: Jan 2002
functions. How these states map into the current IN BCSM models; all
require consideration.
- The SCF will be able to select one or more appropriate SSF/
Intelligent SIP Proxy/Redirect servers dependant on different
parameters (class of service requested by the user, placement of
gateways, tariff, etc.). The SC-GF will be able to perform correct
lower layer protocol and address translation functions.
User Interaction requirements for the IN Interaction with SIP Based
systems are listed below :
- Intelligent SIP Proxy/Redirect Server enhancements for user
interaction (e.g.: does it provide control of speech path connection
and information on tones and announcements).
- The user interaction with SIP User Agent at the terminal may
be realized through a SIP Registration interface. The user
interaction with PSTN user is realized using MGC relay mode. The
information exchange path is Intelligent SIP Proxy/Redirect Server
to GW interface SIP
- The SIP Registration interface may be modified to support user
interaction information exchange. A SIP Registration interface
between Intelligent SIP Proxy/Redirect Server and SIP terminal could
be upgraded to support call-unrelated user access service.
The user interaction enhancements will be treated into a separate
draft RFC.
5. The SIP-IN Protocol Architecture.
5.1 Introduction
The SIP architecture has the following functional elements defined
in [4]:
- User agent client: The SIP functional entity that initiates a
request.
- User agent server: The SIP functional entity that terminates a
request by sending 0 or more provisional SIP responses and one final
SIP response.
- 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, re-
writes the R-URI,and,acting as a UAC, proxies the request to a
downstream UAS. Proxies may retain significant call control state by
inserting them-selves in future SIP transactions beyond the initial
INVITE.
SIP-IN Interworking Protocol Expires: Jan 2002
- 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: An 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: An SIP proxy that is located near the originator
of requests. It receives all outgoing requests from a particular
UAC, including those requests whose Request-URLs identify a host
other than the outbound proxy. The outbound proxy sends these
requests, after any local processing, to the address indicated in
the Request-URI.
This section provides information flows that illustrate an overview
of the interaction of SIP and IN capabilities. In particular it
provides a proposal for the triggering of
IN services as well as a mapping between the IN call states and
related Session Initiation Protocol (SIP) call states.
An overall objective is to ensure that IN control of 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 connect to
present or future networks, simplifies service evolution from
present to future, and leads to more rapid implementation.
This section investigates the possibility of IN service control
based on the SIP proxy Server approach. This means that a locally
configured proxy server is required for outgoing calls that require
legacy service support based on existing IN services. Subsequent
sections will specify the interworking protocol based on the defined
SIP-IN Protocol architecture in this section
The section is organized as follows: Section 5.2 outlines the
proposed functional protocol architecture for the support of SIP-IN
interaction. Section 5.3 briefly describes the concepts for IN
service triggering based on IN Subscription Information.
5.2. SIP-IN Functional Protocol Architecture
The Figure 2 specifies the IP/IN proposed architecture based on the
IETF IP architecture.
+------------------------------+
| +--------------+ |
| +-------+ |+-----------+ | |
| |SCF/SDFo----oSSF(IP) | | |
| +-------+ |+-----o-----+ | |
SIP-IN Interworking Protocol Expires: Jan 2002
| | | | |
| |+-----o-----+ | |
| ||CCF(IP) | | |
| Intelligent |+-----o-----+ | |
| Network | | | |
| Protocol | | | |
| +------|-------+ |
+--------------------|---------+
|
+------o----+
| SIP/SDP |
+-----------+
/ \
+-------+ +---------+
| TCP | | UDP |
+-------+ +---------+
/ \
+----------------------+
| IP v4, IP v6 |
+----------------------+
Figure 2: IETF IP/IN proposed Architecture
The SIP-IN functional protocol architecture at the network level is
given in Figure 3.
+-------+ +-------+
| SCF | | SDF |
+---o---+ +---o---+
| |
+-----+-----------+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF(IP) | | *
* |+-------------+ | *
* || CCF(IP) | | *
* |+------o------+ | *
* +-------|-------------------+ *
* | Extended *
* +-------o-------------------+ SIP *
* | SIP Server | Server *
* +---o---------o---------o---+ *
******|*********|*********|*******************
| | |
(^^^^) +---+ +----o----+ +---+ (^^^^)
( ) | | SIP | | ( )
( +-----o-+ |Terminal | (^^^^ )
( |Gateway| +---------+ ( Packet )
( +-------+ ( Network )
( ) ( +--------+
( SCN ) ( |Terminal|
SIP-IN Interworking Protocol Expires: Jan 2002
(......) (....+--------+
Figure 3: Proposed functional protocol Architecture for SIP-IN
interaction.
5.3 Basic concepts for In service triggering
The following assumptions are made concerning the SIP-IN functional
protocol architecture control flows.
(i) All the call flows show that the SIP Proxy Server and the SSF
have been co-located in order to avoid showing information
flows between the two entities. Standardisation of the
messages for this interface is for further study.
(ii) Originating and terminating SIP Proxy servers MUST operate in
a call-state aware mode.
(iii) As registration with a SIP Proxy server is not mandatory, it
shall be possible to determine whether a registration exists
for that particular subscriber when a subscriber places an
incoming call. This allows the subscriber data information to
be fetched from the home SDF if the subscriber is not
registered. (Note: Absence of the originating subscriber data
does not necessarily mean that the user is not registered,
merely that the originating subscriber data may not exist for
that subscriber).
(iv) The information flows make no consideration for inter-working
with other networks (e.g. PSTN via gateways)
6. Mapping examples of SIP message to the IN State Models
6.1 Mapping of SIP messages to the IN Basic Call State Models
This section deals with the Registration process and how the
Originating (O-BCSM) and Terminating (T-BCSM) Basic Call State Model
Points in Call (PICs) and Detection Points (DPs) or dynamic events
are mapped to the appropriate SIP messages.
Although a mapping is possible, there is not always the same analogy
between the circuit switched environment that the BCSM were designed
for and the IP environment, and as a result a direct mapping is not
always possible.
The state models for the INAP O-BCSM and the T-BCSM are based on the
INAP CS 3.
The mapping examples given in this section allow for an initial
inside of how the detailed IN state models operate. Detailed mapping
examples are provided in Annex A of this RFC draft.
6.2 Registration process
SIP-IN Interworking Protocol Expires: Jan 2002
This section is intended to define the registration process based on
the SIP REGISTER message, which allows subscription of information
to be stored in the SIP Server/SSF.
IETF RFC 2543 [x]defines the term Registrar for registration
purposes and it is the SIP registrar that accepts the REGISTER
method.. With the SIP REGISTER method, it is assumed that
registration with a location server takes place.
The users who wish to receive incoming calls need to register with a
SIP Proxy server and a location server. Callers placing calls are
not required to register.
6.3 Mapping to Originating BCSM for Originating calls
The mapping between the SIP methods and responses for O-BCSM
relating to Originating Calls is shown in Figure 4. Only the
successful case is described.
{1} The Calling User Agent Client initiates a SIP request by
issuing an INVITE method to the SIP Proxy server.
{2} The INVITE message arrives at the proxy server, indicating that
the subscriber has requested to set up a call. The SIP Proxy server
determines if Originating subscriber exists for this user. The
SDF/LDAP functionality in the SIP Proxy is checked to determine if
the calling party has previously registered. If no registration is
found, then step {3} is followed. If the SSF determines that the
calling user has a valid registration then step {4} is followed.
{3} The SSF establishes a dialogue with the SDF or LDAP of the
subscriber's network.
{4} The originating subscriber data is analyzed and if the
necessary triggering criteria are met, the SCF is invoked via an
InitialDP message. The SCF can be invoked at either DP
Origination_Attempt or DP Origination Attempt_Authorised or DP
Collected_Information or DP Analysed_Information.
{5} Instructions are received from the SCF on how the call is to be
routed, together with which EDPs are armed. The state Send_Call
entered and the INVITE method is forwarded to the destination.
{6} A response `180 Ringing' indicates that the destination has
been alerted in session invitation. State O_Aleting is entered, DP
O_Term_Seized may be reported to the SCF and an `180 Ringing' is
sent to the originating party.
{7} A response `200 OK' indicates that the destination has accepted
in session invitation, indicating that a session has been
established. State O_Active is entered, DP O_Active may be reported
to the SCF and an ACK is sent to the originating party.
SIP-IN Interworking Protocol Expires: Jan 2002
(8) Either party may release the call with a BYE method. On receipt
of the BYE, transition to the PIC O_Null takes place and the DP
O_Disconnect may be reported to the SCF.
+-----------+ +--------+ +-----------+
|Originating| |Extended| |Terminating|
| UAC | |Proxy | UAS |
+-----------+ +--------+ +-----------+
| | |
| INVITE [2] [3] |
1 o--------------->o |
| | [4] | +-----------------+
| o-------------------------| O_Null |
| | | +--------o--------+
| | | |
| | | +--------o--------+
| | | | Authorize_ |
| | | | Origination_ |
| | | | Attempt |
| | | +--------o--------+|
| | | |
| | | +--------o--------+
| | | | Collect_ |
| | | | Information |
| | | +--------o--------+
| | | |
| | | +--------o--------+
| | | | Analyse_ |
| | | | Information |
| | | +--------o--------+
| | | |
| | | +--------o--------+
| | | | Select_Route |
| | | +--------o--------+|
| | | |
| | | +--------o--------+
| | | | Authorise_ |
| | | | Call_Setup |
| | | +--------o--------+
| | | |
| | [5] | +-----------------+
| o-------------------------| Send_Call |
| | INVITE | +--------o--------+
| |------------->| |
| | 180 Ringing | |
| 180 Ringing |<-------------| |
|<---------------| [6] | +--------o--------+
| o-------------------------| O_Alerting |
| | | +--------o--------+
| | 200 OK | |
| 200 OK |<-------------| |
|<---------------| [7] | +--------o--------+
| o-------------------------| O_Active |
SIP-IN Interworking Protocol Expires: Jan 2002
| | | +--------o--------+
| | BYE | |
| BYE |<-------------| |
|<---------------| [8] | +--------o--------+
| o-------------------------| O_Null |
| | | +--------o--------+
Figure 4: Mapping to O-BCSM and corresponding PICs for
Successful Originating calls
6.4 Mapping to Terminating BCSM for successful terminating calls
The mapping between the SIP methods and responses for T-BCSM to
Terminating Calls is shown in Figure 5. The information flows for
the successful case are described below:
{1} When the INVITE method arrives at the destination SIP Proxy
server, the server SSF shall determine if a Terminating Subscriber
data exists for the called user
{2} If the terminating subscriber data exists it shall be analyzed
and if the necessary triggering criteria are met, the SCF is invoked
)by establishing a dialogue and e.g. by sending an InitialDP message
between the SSF and SCF. The SCF can be invoked either at DP
Termination_Attempt or DP Termination_Attempt_Authorized.
Transition to state Select_Facility occurs and DP
Facility_Selected_and_Available may be reported. The INVITE will be
sent during the Present_Call PIC.
{3} Call alerts the terminating parting. DP Call_accepted may be
reported to the SCF, the state T_Alerting is entered.
{4} Call answered by the terminating party. DP T_Answer may be
reported to the SCF, state T_Active entered.
{5} Either party may terminate the call by sending a BYE and
transition to PIC T_Null takes place and the DP T_Disconnect may be
reported.
+-----------+ +--------+ +-----------+
|Originating| |Extended| |Terminating|
| UAC | |Proxy | UAS |
+-----------+ +--------+ +-----------+
| | |
| INVITE [1] [2] | +-----------------+
o--------------->o-------------------------| T_Null |
| | | +--------o--------+
| | | |
| 100 Trying | | +--------o--------+
|<---------------o | | Authorize_ |
| | | | Termination_ |
| | | | Attempt |
SIP-IN Interworking Protocol Expires: Jan 2002
| | | +--------o--------+|
| | | |
| | | +--------o--------+
| |[2} | | Select_ |
| o-------------------------| Facility |
| | | +--------o--------+
| | | |
| | [2] | +-----------------+
| o-------------------------| Present_Call |
| | INVITE | +--------o--------+
| |------------->| |
| | 180 Ringing | |
| 180 Ringing |<-------------| |
|<---------------| [3] | +--------o--------+
| o-------------------------| T_Alerting |
| | | +--------o--------+
| | 200 OK | |
| 200 OK |<-------------| |
|<---------------| [4] | +--------o--------+
| o-------------------------| T_Active |
| | | +--------o--------+
| | BYE | |
| BYE |<-------------| |
|<---------------| [5] | +--------o--------+
| o-------------------------| T_Null |
| | | +--------o--------+
Figure 5: Mapping to O-BCSM for Successful Originating calls
6.5 Mapping to Terminating BCSM for unsuccessful terminating calls
This subsection explores the mapping and the reporting of the DPs
that may be encountered when the call is not successfully
established. The information flows are shown in Figure 6 and is
further explained below:
{1} INVITE method arrives at the destination SIP proxy server.
Server/SSF determines if the Terminating subscriber data exists for
the called user.
{2} Terminating subscriber data is analysed and if necessary
triggering criteria are met, SCF is invoked. Transition to state
Present_Call PIC and an INVITE is sent to the terminating
subscriber.
{3} The destination does not accept the incoming call _ reason
response may be any value in 4xx response range. The mapping of
client error codes (4xx) to the possible Detection Points in PIC
Terminating_Call_Handling is performed. For example, DP T_Busy can
be mapped onto ' 486 Busy' . The mapping of the various DP's such
as T_Abandon , T_No_Answer ect. onto the error codes are specified
in the section 8.
SIP-IN Interworking Protocol Expires: Jan 2002
+-----------+ +--------+ +-----------+
|Originating| |Extended| |Terminating|
| UAC | |Proxy | UAS |
+-----------+ +--------+ +-----------+
| | |
| INVITE [1] | +-----------------+
o--------------->o-------------------------| T_Null |
| | | +--------o--------+
| | | |
| 100 Trying | | +--------o--------+
|<---------------o | | Authorize_ |
| | | | Termination_ |
| | | | Attempt |
| | | +--------o--------+|
| | | |
| | | +--------o--------+
| | | | Select_ |
| | | | Facility |
| | | +--------o--------+
| | | |
| | [2] | +-----------------+
| o-------------------------| Present_Call |
| | INVITE | +--------o--------+
| |------------->| |
| |4xx Error Code| |
| 4xx Error Code |<-------------| |
|<---------------| [3] | +--------o--------+
| o-------------------------| T_Null |
| | | +--------o--------+
Figure 6: Mapping to T-BCSM for Unsuccessful Terminating calls
7. Call State Mapping
NOTE:
This section is based on the information contained in [3] and has
been extended as follows:
i) the distinction between 100 Trying, 181 Call Is Being Forwarded,
182 Queued and 183 Session Progress has been handled
ii) the mapping to the IN Abstract Signalling Primitive conventions
has been given.
iii) the IN half call concept has been applied.
The mapping of the PIC's (Points In Call)and the DP (Detection
Point) of the IN call model into SIP can be easily translated for IN
services that have a "query-response" like freephone, originating
call screening, caller name identification.
SIP-IN Interworking Protocol Expires: Jan 2002
IN states will be mapped to the appropriate SIP methods or response
codes. While mapping call states from SIP to IN, it is important to
note that there will not be a 1-to-1 mapping between IN call states
and SIP states.
7.1 SIP and O_BCSM
The PICs of O_BCSM come into play when a call request SIP INVITE
message arrives from a SIP UAC to an SIP server running
the IN Originating call model. This SIP proxy will create a O_BCSM
object and initialize it into the O_NULL PIC.
In the AUTH_ORIG_ATT PIC, a SIP proxy running the IN call model 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 calling party is
authorized to place the call, the BCSM transits to the next PIC,
COLLECT_INFO.
This COLLECT_INFO PIC is responsible for collecting a dial string
from the calling party. The SIP proxy can detect an incomplete
address (e.g. by inter digit timeout or by digit analysis) and may
send to the calling party a "484 Address Incomplete" message and
remain in this state until a valid "dial string" is received via a
subsequent INVITE method. This INVITE contains the same "From" and
"Call-ID" headers. The "To" field is updated to reflect the entire
called number as known so far. Since the "To" field is different,
this INVITE represents a different transaction than the initial
INVITE; consequently, there is no relationship between the CSeq
values in the two INVITE messages.
Once it has obtained a valid dial string, the BCSM transits to the
next PIC, ANALYZE_INFO.
The ANALYZE_INFO PIC can either generate the 100 TRYING if the
analyzed information function has been performed successfully, or
like the COLLECT_INFO PIC, it may also cause the SIP proxy to send a
_484 Address Incomplete_ response (e.g. by inter digit timeout or by
digit analysis) and remain in this state until a valid "dial string'
is received via a subsequent INVITE method.
This PIC is ultimately responsible for translating the dial string
to a routing number. Many IN services such as freephone, LNP, OCS,
etc. are triggered from DP's associated with this PIC. The SIP
proxy can send the SIP URI in the To: field to the IN layer to have
it analyzed. If the analysis succeeds, the BCSM transits to the
next PIC, SELECT_ROUTE.
The next PIC encountered is SELECT_ROUTE. In the circuit-switched
network, the actual physical route has to be selected at this point.
SIP-IN Interworking Protocol Expires: Jan 2002
The SIP analogue of this would be to determine the next hop SIP
server. The next hop SIP server 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 proxy can use a protocol like
TRIP to find the best gateway to egress the request onto the GSTN.
The AUTH_CALL_SETUP PIC is used for certain service features to
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 PICs have been successfully negotiated, the SIP proxy
running the IN call model now sends the Setup.Req.Ind Abstract
Signalling Primitive to the T_BCSM. This will lead to the eventual
processing of the SIP INVITE message at the next hop server. The
next PIC, SENT_CALL is now entered. 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. If in
the SENT_CALL PIC a _181 Call Is Being Forwarded_, a _182 Queued_, a
_183 Session Progress_, or a _100 Trying_ message is received,
control stays in this PIC.
When the SIP proxy running the IN call layer gets back a "180
Ringing" for the call, it instructs the BCSM to transit to 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 proxy running the IN
layer receives a "200 OK". The receipt of this message is followed
by the SIP proxy instructing the BCSM to transit to the next PIC,
O_ACTIVE. The call is now active.
When either of the party hangs up, the SIP proxy 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 BCSM to transit
to O_DISCONNECT DP and perform cleanup. Subsequently, the state of
the call in the SIP server itself is also destroyed.
Figure 7 below provides a the mapping from the SIP server protocol
state machine to the originating half of the IN call model.
SIP O_BCSM
+-----------------+
(1) ===============>| O_NULL PIC |
+--------o--------+
|
+--------V--------+
SIP-IN Interworking Protocol Expires: Jan 2002
(2) <===============| AUTH_ORIG_ATT |
| PIC |
+--------o--------+
|
+--------V--------+
(3) <==============>| COLLECT_INFO PIC|
+--------o--------+
|
+--------V--------+
(4) <===============| ANALYSE_INFO PIC|
(5) <==============>| |
+--------o--------+
|
+--------V--------+
| SELECT_ROUTE PIC|
+--------o--------+
|
+--------V--------+
| AUTH_CALL_SETUP |
| PIC |
+--------+--------+
|
+--------V--------+
(6) <===============| SENT_CALL PIC |------->+---------+
| |-----+ |O_Called_|
+--------o--------+ | |Party_ |
(10) <========================|==============|==|BusyDP |
| +-|->+---------+
+--------V--------+ | |
(7) <===============| O_ALERTING PIC |---+ +->+---------+
| |------->|O_No_ _|
+--------o--------+ |AnswerDP |
(11) <========================|=================| |
| +---------+
+--------V--------+
(8) <===============| O_ACTIVE PIC |
(9) ===============>| |
(12) ===============>| |
+-o------o--+----++
(16) <=================|======|==| | O_Re-AnswerDP
| | +---+
+--------+ | | ^
(13) ===>|O_Discon|<---+ | |
(14) <===|nectDP |<---+ | |
+---- ---+ | +-V--+ |
(15) <=================|====| | | O_SuspendDP
+-o--- +----+-o---+
(8) <===============| O_SUSPENDED PIC |
(9) ===============>| |
(12) ===============>| |
+-----------------+
SIP-IN Interworking Protocol Expires: Jan 2002
Legend:
| Communication between
| states
V
======> Communication between IN layer and SIP
Figure 7: Mapping of the SIP methods to O_BCSM
Note: ABANDON should be included
The following mapping to the IN Abstract Signalling Primitive
conventions and call signalling indications applies:
(1) An Indication is sent from Ingress Server/User to O_BCSM to
initiate call establishment (e.g. Setup.Ind Abstract Signalling
Primitive mapped from a INVITE method).
(2) An Indication is sent from O_BCSM to Ingress Server/User that
network is unable to initiate call (e.g.Release.Req Abstract
Signalling Primitive mapped to 401 Unauthorised).
(3) The Ingress Server/User sends call (dialling) information to
the O_BCSM (e.g. SubsequentAddress Abstract Signalling Primitive
mapped from INVITE method as a result of receiving an 484 Address
Imcomplete from the O_BCSM).
(4) An Indication is sent from O_BCSM to the Ingress Server/User to
terminate the sending of call information (e.g.
CallProgress(Progress).Req Abstract Signalling Primitive mapped to
100 Trying).
(5) An Indication is sent from the Ingress Server/User to the
O_BCSM upon completion of call information (e.g. SubsequentAddress
Abstract Signalling Primitive mapped from INVITE method as a result
of receiving an 484 Address Imcomplete from the O_BCSM)
(6) Ingress Server/User is informed that call has been routed to
another environment of network (e.g. CallProgress(Progress).Req
Abstract Signalling Primitive mapped to either: a 181 Call Is Being
Forwarded; or a 182 Queued, or a 183 Session Progress message
(7) An Indication is sent from the O_BCSM to the Ingress
Server/User when the called party is being alerted (e.g.
CallProgress(Alert).Req Abstract Signalling Primitive mapped to a
180 RINGING).
(8) An Indication is sent from the O_BCSM to the Ingress
Server/User when the call is accepted. (e.g. Setup.Resp Abstract
Signalling Primitive is mapped to 200 OK)
(9) The Ingress Server/User acknowledges that the call is accepted.
(receipt of the ACK method)
(10) The O_BCSM sends an Indication to the Ingress Server/User that
the called party is unable to accept the call, due to busy
condition. (sending of the 484 Busy Here or 600 Busy Everywhere.
(11) The O_BCSM sends an Indication to the Ingress Server/User since
the called party is unable to accept the call, due to no answer
condition. (sending of the 480 Temporarily unavailable)
(12) An Indication is received by the O_BCSM from the Ingress
Server/User to end the call.( receipt of CANEL or BYE method)
SIP-IN Interworking Protocol Expires: Jan 2002
(13) The O_BCSM indicates to the Ingress Server/User that the call
is being disconnected.(sending of BYE method)
(14) The Ingress Server/User acknowledges to the O_BCSM that the
call is being disconnected.(receipt of ACK)
(15) An Indication is sent to the Ingress Server/user when the
connection towards the Called Party is suspended. In SCN networks,
the user can generate a suspend (timer supervised)in order to unplug
the terminal from the socket and plug it in another one.
When a network suspend arrives from the SCN, the server/MGC sends an
INVITE towards the calling user in order to put the media stream on
hold.
(16) An Indication is sent to the Ingress Server/user when the
connection towards the Called Party is reconnected. A resume is sent
once the terminal has been reconnected and the timer has not expired
this will be seen as an network resume. The reception of a resume
triggers another INVITE toward the calling user/Ingress server that
resumes the media stream. For the SIP UAC/UAS the result is an
interruption in the voice path until the other party picks up the
phone again.
7.2. SIP and T_BCSM
The T_BCSM object is created when the termination half call of the
SIP server running the IN layer receives the Setup.Req.Ind Abstract
Signalling Primitive from the O_BCSM. The SIP proxy initializes
T_BCSM object it to the T_NULL PIC.
The T BCSM transits to the next PIC, AUTH_TERM_ATT, during which the
called party wishes that the present type of call is ascertained.
IN services such as Called Line Identification and Call Forwarding
are normally triggered from DPs associated with this PIC.
Once a positive indication is received from the AUTH_TERM_ATT PIC,
the BCSM transits to the next PIC, SELECT_FACILITY. The intent of
this PIC, in traditional circuit networks, is to select a line or a
trunk to reach the called party. In a hybrid (GSTN/IP) network,
where the callee resides on the GSTN, a SIP proxy can use
SELECT_FACILITY PIC to interface with a gateway and select a
line/trunk to route the call. If a facility was thus successfully
seized, the SIP INVITE request is deemed to be successful and
control enters the next PIC, PRESENT_CALL.
In a traditional circuit-switched network, PRESENT_CALL presents
(via ISUP IAM or Q.931 Setup messages) the call to the called party.
When the SIP proxy sends out the INVITE to the UAS, it instructs the
BCSM to transit to this state. The BCSM will remain in this state
until the SIP proxy gets back a "180 Ringing", whereupon it
instructs the BCSM to enter the next state, T_ALERTING.
SIP-IN Interworking Protocol Expires: Jan 2002
T_ALERTING "alerts" the called party by ringing the phone. When the
SIP proxy receives a "200 OK", it instructs the BCSM to enter the
next PIC, T_ACTIVE. The call is now active.
When either of the party hangs up, the SIP proxy 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 proxy instructs the BCSM to transit
to the next PIC, T_DISCONNECT and perform cleanup. Subsequently,
the state of the call in the SIP proxy itself is also destroyed.
Figure 8 below provides a visual mapping from the SIP server
protocol state machine to the terminating half of the IN call model:
SIP O_BCSM
+-----------------+
| T_NULL PIC |
+--------o--------+
|
+--------V--------+
|AUTH_TERMINATION |
+---| _ATTEMPT PIC |================> (1)
| +--------o--------+
| |
+---------+ | +--------V--------+
| |<--+ | SELECT_FACILITY |
|T_BusyDP_| | PIC |
| |<----+ +--------o--------+
+---------+ | |
| +--------V--------+
| | PRESENT_CALL PIC|<===============> (1) to (6)
+--|-| |
| | +--------o--------+
| | |
| | |
+---------+ | | +--------V--------+
|T No_ |<-+ +-| T_ALERTING PIC |
|AnswerDP |<------| |<================ (7)
| | +--------o--------+
+---------+ |
+--------V--------+
| T_ACTIVE PIC |================> (8)
| |================> (11)
| |--------+
++---+---o--------+ |
T_Re-AnswerDP | | |<================|======== (9)
+---+ | |
^ | |
|<====|========================== (10)
| | |
| +-V--+ |
SIP-IN Interworking Protocol Expires: Jan 2002
| | | T_SuspendDP |
+--o-- +----+-o---+ +--V-----+
(8) <===============| T_SUSPENDED PIC | |T_Discon|<=======(13)
(9) ===============>| |---->|nectDP |=======>(14)
(12) ===============>| | +--------+
+-----------------+<======================(12)
Legend:
| Communication between
| states
V
======> Communication between IN layer and SIP
Figure 8: Mapping of the SIP methods to T_BCSM
T-Abandon should be included
The following mapping to the IN Abstract Signalling Primitive
conventions and call signalling indications applies:
(1) An Indication is sent from T_BCSM to the Egress Server/User to
terminate the call to an idle facility (e.g. Setup.Req Abstract
Signalling Primitive mapped to the INVITE method).
(2) An Indication is sent from Egress server/user to T_BCSM
indicating that the Egress server/user cannot accept the call.
(e.g. Release.Req Abstract Signalling Primitive mapped to BYE
method).
The called number can be received in just one INVITE method(`en
bloc' signalling) or in one INVITE method followed by one or several
INVITE's (overlap signalling). In some countries there is no way for
the server to know whether the called party' number is already
complete.
If the server relies on the inter-digit time-out to assume that the
number is complete, the establishment of the connection is delayed.
Alternatively, if the server sends the INVITE request immediately
after receiving the INVITE method, heavy signalling traffic may be
generated. Therefore, an individual server might implement a timer
and/or a stop digit (such as #). All the digits that arrive before
this timer expires will be included in the INVITE sent. The timer
can be bypassed by the user sending the stop digit. This timer
SHOULD not be larger than 5 seconds.
The following signalling indications (3) to (5) treat the case of
overlap based on the following procedures.
(3) An indication is sent from the T_BCSM to forward any remaining
call information to the Egress server/user (e.g. by means of INVITE
request and 484 Address Incomplete responses). Thus, after
receiving the INVITE and possibly one or several INVITE's, the
SIP-IN Interworking Protocol Expires: Jan 2002
server issues an INVITE request towards the called user. The "To"
field contains the digits received so far. If, after sending this
INVITE request, one or more INVITE's are received, the server sends
a new INVITE to the called user. This new INVITE has the same "From"
and "Call-ID" as the previous INVITE sent. The "To" field is
updated and contains all the available digits.`484 Address
Incomplete' responses will be received for all the INVITE's sent
with the incomplete called party number. Thus, all the call legs
(same `Call-ID', different to) created while the digits are arriving
MUST be deleted.
(4) An Indication is sent from the T_BCSM to the Egress server/user
upon the sending of sufficient call information. This can be done by
including a stop digit into the INVITE method sent to the called
user.
(5) An Indication is sent from the Egress server/user to the T_BCSM
upon receipt of sufficient call information (e.g.
CallProgress(Progress).Ind Abstract Signalling Primitive
SubsequentAddress Abstract Signalling Primitive mapped from 100
Trying).
If a provisional response different than 100 Trying arrives
(typically a 183 Session Progress) the server SHOULD send all its
subsequent INVITEs to the server that generated the response. This
avoids in SIP bridging situations sending subsequent INVITEs to
different gateways. This would generate several messages in the
network for just one call (rather than a one initial address message
followed by one or subsequent messages). Therefore, subsequent
INVITE's would contain an updated To field, the same Call-ID and a
Route header built with the Record-route and the Contact headers
received in the provisional response. If two or more provisional
response are received from a different location it means that the
INVITE's generated reached different UAS's.The gateway SHOULD choose
which UAS will handle the call and send a CANCEL specifically
addressed to the rest of UAS's (Record-Route, Contact and tag in
the To field). The server typically SHOULD choose the UAS that
returned the provisional response to the INVITE that contained more
digits
(6) Egress server/user sends an Indication to the T_BCSM that
alerting is taking place (e.g. CallProgress(Alert).Ind Abstract
Signalling Primitive mapped from 180 RINGING).
(7) An Indication is sent from the Egress server/user to the T_BCSM
upon acceptance of the incoming call
(e.g. Setup.Conf Abstract Signalling Primitive mapped from 200 OK).
(8) An Indication is sent from the T_BCSM to the Egress server/user
acknowledging that the call can now be connected. (ACK)
(9) An Indication is sent from the Egress server/user to the T_BCSM
that the Egress server/user suspends the call.15) This is an INVITE
method with a media stream put on hold
(10) An Indication is sent from the Egress server/user to the T_BCSM
that the Egress server/user resumes the call. This is another INVITE
SIP-IN Interworking Protocol Expires: Jan 2002
method in order to resume a previous media stream which was put on
hold
(11) The T_BCSM sends an Indication to the Egress server/user
indicating that the calling party has gone on-hook. This is the BYE
method sent towards the user.
(12) An Indication is received by the T_BCSM from the Egress
server/user to end the call. This is a BYE method received from the
user.
(13) The T_BCSM indicates to the Egress server/user that the call is
being disconnected.
(14) The Egress server/user acknowledges to the T_BCSM that the call
is being disconnected.
7.3. Intra Server BCSM indications
The following figure 9 illustrates the communication between two
call segments in the CCF/SSF for a basic two-party call, as
described in the CCF/SSF Model. It shows the indications that flow
between the originating BCSM and terminating BCSM . All possible
indications are shown, except for any which may occur at the O-
Exception and the T-Exception PICs. Note that these indications are
not intended to be mapped to explicit information flows.
(1) Initiate T_BCSM after the authority to place the call has been
verified. The O_BCSM is currently in the Send_Call PIC. The
originating Basic Call Manager has sent the call attempt to the
terminating Basic Call Manager for further processing, i.e. the
Setup.Req.Ind Abstract Signalling Primitive is sent on the IBI from
the O-BCSM to the T_BCSM.
(2) An Indication is sent from the T_BCSM to O_BCSM that the
terminating user is busy, i.e. the Release.Req.Ind Abstract
Signalling Primitive is sent on the IBI from the T-BCSM to the
O_BCSM.
(Causes Send_Call PIC to O_Called_Party_Busy BCSM transition in
O_BCSM.)
(3) An Indication is sent from the T_BCSM to O_BCSM that the
terminating user is busy, i.e. the Release.Req.Ind Abstract
Signalling Primitive is sent on the IBI from the T-BCSM to the
O_BCSM.
(Causes O_Alerting PIC to O_Called_Party_Busy DP BCSM transition in
O_BCSM.)
(4) An Indication is sent from the T_BCSM to O_BCSM that the call
can not be presented, i.e. the Release.Req.Ind Abstract Signalling
Primitive is sent on the IBI from the T-BCSM to the O_BCSM.
(Causes Send_Call PIC to Select_Route PIC, O_Called_Party_Busy DP,
or O_No_Answer DP.)
(5) An Indication is sent from the T_BCSM to the O_BCSM that an
Called Party has signalled call acceptance with immediate BCSM
transition to an answered condition,i.e. the Setup.Resp.Conf
SIP-IN Interworking Protocol Expires: Jan 2002
Abstract Signalling Primitive is sent on the IBI from the T-BCSM to
the O_BCSM (causes Send_Call PIC to O_Answer DP BCSM transition in
O_BCSM).
(6) An Indication is sent from T_BCSM to O_BCSM that Called Party
is being alerted i.e. the CallProgress(Alert).Req.Ind Abstract
Signalling Primitive is sent on the IBI from the T-BCSM to the
O_BCSM (causes O_BCSM to transit from Send_Call PIC O_Alerting PIC
and prepare to send 180 RINGING response to the Calling Party).
(7) An Indication is sent from T_BCSM to O_BCSM that Called Party
has rejected the call, i.e. the Release.Req.Ind Abstract Signalling
Primitive is sent on the IBI from the T-BCSM to the O_BCSM (this is
indicated to the O_BCSM with a busy cause and causes O_BCSM to
transit from O_Alerting PIC to Select_Route PIC or
O_Called_Party_Busy DP).
(8) An Indication is sent from T_BCSM to O_BCSM that Called Party
has not answered within a specified time period, i.e. the
Release.Req.Ind Abstract Signalling Primitive is sent on the IBI
from the T_BCSM to the O_BCSM (causes O_Alerting PIC to O_No_Answer
DP BCSM transition in O_BCSM).
(9) An Indication is sent from the T_BCSM to the O_BCSM that called
party has not answered within a specified time period, i.e. the
Release.Req.Ind Abstract Signalling Primitive is sent on the IBI
from the T_BCSM to the O_BCSM. (Causes Send_Call PIC to O_No_Answer
DP BCSM transition in O_BCSM.).
(10) An Indication is sent from T_BCSM to O_BCSM that Called Party
has accepted and answered the call attempt, i.e. the Setup.Resp.Conf
Abstract Signalling Primitive is sent on the IBI from the T_BCSM to
the O_BCSM (causes O_Alerting PIC to O_Answer DP BCSM transition in
O_BCSM).
(11) An Indication is sent from the T_BCSM to the O_BCSM that the
called party has accepted and answered the call attempt, i.e. the
Setup.Resp.Conf Abstract Signalling Primitive is sent on the IBI
from the T-BCSM to the O_BCSM. (Causes Send_Call PIC to O_Answer DP
BCSM transition in O_BCSM.)
(12) An Indication is sent from T_BCSM to O_BCSM that Called Party
has disconnected, i.e. the NetworkSuspend.Req.Ind Abstract
Signalling Primitive is sent on the IBI from the T_BCSM to the
O_BCSM (e.g. on-hook), (causes O_Active PIC to O_Suspend DP BCSM
transition in O_BCSM).
(13) An Indication is sent from T_BCSM to O_BCSM that Called Party
re-answers is received before the timer expires , i.e. the
NetworkResume.Req.Ind Abstract Signalling Primitive is sent on the
IBI from the T-BCSM to the O_BCSM (causes O_Suspended PIC to
O_Re_Answer DP BCSM transition in O_BCSM).
SIP-IN Interworking Protocol Expires: Jan 2002
(14) An Indication is sent from O_BCSM to T_BCSM that Calling Party
has disconnected, i.e. the Release.Req.Ind Abstract Signalling
Primitive is sent on the IBI from the O_BCSM to the T_BCSM, while
T_BCSM was in T_Active PIC (causes T_Active PIC to T_Disconnect DP
BCSM transition in T_BCSM).
(15) An Indication is sent from O_BCSM to T_BCSM that Calling Party
has disconnected, , i.e. the Release.Req.Ind Abstract Signalling
Primitive is sent on the IBI from the O_BCSM to the T_BCSM, while
T_BCSM was in T_Suspended PIC (causes T_Suspended PIC to
T_Disconnect DP BCSM transition in T_BCSM).
(16) An Indication is sent from T_BCSM to O_BCSM that Called Party
has disconnected, i.e. the Release.Req.Ind Abstract Signalling
Primitive is sent on the IBI from the T_BCSM to the O_BCSM, (causes
O_Suspended PIC to O_Disconnect DP BCSM transition in O_BCSM).
(17) An Indication is sent from the T_BCSM (T_Disconnect DP) to
O_BCSM that the called party has disconnected, i.e. the
Release.Req.Ind Abstract Signalling Primitive is sent on the IBI
from the T_BCSM to the O_BCSM,. (Causes O_Active PIC to O_Disconnect
DP BCSM transition in O_BCSM.).
(18) An Indication is sent from O_BCSM to T_BCSM that Calling Party
has abandoned, i.e. the Release.Req.Ind Abstract Signalling
Primitive is sent on the IBI from the O_BCSM to the T_BCSM, (causes
Authorize_Termination_Attempt PIC, Select_Facility PIC, Present_Call
PIC or T_Alerting PIC to T_Abandoned DP BCSM transition in T_BCSM).
NOTE:
i) Indications (14) and (16) are mutually exclusive:
ii) All indications are for intra-switch;
iii) The indications do not explicitly include the modelling of
SRFs;
iv) Indications which are preceded by a DP may be affected
depending on whether the DP is active and the SCF response.
*********************************
* Figure to be provided *
*********************************
Figure 9: Intra Server BCSM Indications
7.5. 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.
SIP-IN Interworking Protocol Expires: Jan 2002
Response received from SIP DP mapping to IN
----------------- ----------------------
400 Bad request Route_Select_Failure or T_Exception
401 Unauthorized Origination_Attempt_Denied or
Termination_Attempt_Denied
402 Payment required Route_Select_Failure or T_Exception
403 Forbidden Route_Select_Failure or T_Exception
404 Not found Route_Select_Failure or T_Exception
405 Method not allowed Route_Select_Failure or T_Exception
406 Not acceptable Route_Select_Failure or T_Exception
407 Proxy authentication Origination_Attempt_Denied or
required Termination_Attempt_Denied
408 Request timeout O_Exeption or T_Exception
409 Conflict Route_Select_Failure or T_Exception
410 Gone Route_Select_Failure or T_Exception
411 Length required Route_Select_Failure or T_Exception
413 Request Entity too long Route_Select_Failure or T_Exception
414 Request-URI too long Route_Select_Failure or T_Exception
415 Unsupported media type Route_Select_Failure or T_Exception
420 Bad extension Route_Select_Failure or T_Exception
480 Temporarily unavailable O_No_Answer or T_No_Answer
481 Call leg/transaction
doesn't exist Route_Select_Failure or T_Exception
482 Loop detected Route_Select_Failure or T_Exception
483 Too many hoops Route_Select_Failure or T_Exception
484 Address incomplete see Section 7
485 Ambiguous Route_Select_Failure or T_Exception
486 Busy here O_Called_Party_Busy or T_Busy
500 Server internal error Route_Select_Failure or T_Exception
501 Not implemented Route_Select_Failure or T_Exception
502 Bad gateway Route_Select_Failure or T_Exception
503 Service unavailable Route_Select_Failure or T_Exception
504 Gateway time-out O_Exception or T_Exception
505 Version not supported Route_Select_Failure or T_Exception
600 Busy everywhere O_Called_Party_Busy or T_Busy
603 Decline Route_Select_Failure or T_Exception
Note: further study required on the mapping one other possibility
could be to map this to O_No_Answer or T_No_Answer
604 Does not exist anywhere Route_Select_Failure or T_Exception
606 Not acceptable Route_Select_Failure or T_Exception
The mapping of the error response received from SIP to the cause
values of IN based on the ITU-T Q.850 Recommendation is as follows.
Response received from SIP Cause value mapping to IN
----------------- ----------------------
400 Bad request 127 Interworking
401 Unauthorized 21 Call rejected
402 Payment required 21 Call rejected
403 Forbidden 1 Unallocated number
404 Not found 1 Unallocated number
405 Method not allowed 63 Service/option
SIP-IN Interworking Protocol Expires: Jan 2002
unavailable
406 Not acceptable 79 Service/option not
implemented
407 Proxy authentication required 21 Call rejected
408 Request timeout 102 Recovery on timer expiry
409 Conflict 48 Temporary failure
410 Gone 22 Number changed
411 Length required 127 Interworking
413 Request Entity too long 127 Interworking
414 Request-URI too long 127 Interworking
415 Unsupported media type 79 Service/option not
implemented
420 Bad extension 127 Interworking
480 Temporarily unavailable 18 No user responding
480 Temporarily unavailable 20 Subscriber absent
481 Call leg/transaction doesn't exist 127 Interworking
482 Loop detected 127 Interworking
483 Too many hoops 25 Exchange-routing error
484 Address incomplete 28 Invalid Number Format
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
500 Server internal error 41 Temporary failure
501 Not implemented 38 Network out of order
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Gateway time-out 102 Recovery on timer expiry
505 Version not supported 127 Interworking
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable 38 Network out of order
The mapping of error codes (4xx) _ 6xx received in SIP to the
possible Detection Points in PIC Originating and Terminating Call
Handling is performed as indicated in the mapping from cause to DP
section of the CS3 Core INAP specification ETSI DEN/SPAN-03063-1.2
section 6.3.5 of the SCF-SSF Interface based on the above table.
7.6. Support of mid-call signalling
Pure SIP does not have any provision for carrying any mid-call
control information that is generated during. The INFO method SHOULD
be used for this purpose. Draft-ietf-sip-info-method-04.txt.
Further input will be provided on this topic.
8. Protocol Procedures
Topics to be provide are:
8.1. Mapping of SIP messages containing:
* Methods (how is the Sip OPTIONS method supported)
SIP-IN Interworking Protocol Expires: Jan 2002
* 1xx Information messages
* 2xx OK
* 3xx Redirection
* 4xx Messages (integration of section 7.4 with further protocol
details)
* 5xx Messages (integration of section 7.4 with further protocol
details)
* 6xx Global Failures (integration of section 7.4 with further
protocol details)
8.2. Mapping of SIP URLs
8.3. Mapping of media stream descriptions
8.4. SIP call Forking in Multi-Party Calls
8.5. Third Party Call Control
8.6. Call Transfer
9. Security Considerations
Security is a general property which relates to safe and reliable
operation. The high level requirements of a secure system are:
i) Confidentiality:
This is defined in ITU-T Recommendation X.800 as < the avoidance of
the disclosure of information without the permission of its owner >.
Thus, confidentiality may be considered as a property which ensures
that conversations or interactions remain private.
ii) Integrity:
This is defined in ITU-T Recommendation X.800 as <the property that
data has not been altered or destroyed in an unauthorised manner>.
Integrity may then be considered as a property which ensures that
operations occur as they are expected to.
iii) Availability:
This may be considered as a property relating to the readiness of
resources for authorized use.
iv) Accountability:
This may be considered as a property which ensures that any
operational request can be correctly attributed in case of doubt or
dispute.
The components of an IN system MUST be assembled and operated in
such a way as to provide a defined level of security.
SIP-IN Interworking Protocol Expires: Jan 2002
To assist in this, any interface within the IN functional
architecture may have the need to apply security assisting functions
to the information flows passing across the interface such as:
i) Network access security functions :
This includes user/terminal authentication (i.e. the result of a
process by which a service user proves his or her identity to an IN
system), user profile verification (i.e. the verification that a
user is authorised to use a functionality).
ii) Internetworking security functions:
This includes peer entity authentication (i.e., a process which
allows a communicating entity to prove its identity to another
entity in the network), signalling data or TMN data integrity, non-
repudiation, confidentiality, entity profile verification (i.e. the
verification that an entity is authorised to use a functionality).
A. Best Current Practice for SIP to IN Mapping
To be provided
B. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Gurbani, V., Rastogi, V., "Accessing IN Services from SIP
Networks", IETF I-D, Work in Progress,
http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-
to-in-04.txt, expires August 2001
4 M. Handley, H. Schulzrinne, J. Rosenberg, E. Schooler, "SIP:
Session Initiation Protocol", RFC 2543, March 1999.
C. Acknowledgments
I thank specially 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.
I also thank Hui-Lan Lu, Doris Lebovits, Kamlesh Tewani, Janusz
Dobrowloski, Vijay Gurbani, Jack Kozik, Warren Montgomery, Lev
Slutsman, Igor Faynberg, Henning Schulzrinne and Jonathan Rosenberg
who all contributed to the discussions on the relationship of IN and
SIP call models
D. Changes
Changes since -00
. Included SIP/IN Call Model mapping as described in [3].
. Included comments from ETSI obtained by Frans Haerens.
SIP-IN Interworking Protocol Expires: Jan 2002
. Not all changes discussed on the SIN DT email list have been
included - stay tuned for -02 coming up after 51st IETF.
E. Author's Addresses
Frans Haerens
Alcatel Bell
Francis Welles Plein,1
Belgium
Phone: +32 3 240 9034
Email: frans.haerens@alcatel.be
Vijay K. Gurbani
Lucent Technologies, Inc.
263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60532
USA
Phone: +1 630 224 0216
Email: vkg@lucent.com
Vidhi Rastogi
Wipro Technologies
271, Sri Ganesha Complex
Hosur Main Road, Madiwala
Bangalore - 560 068, INDIA
Phone: +91 80 5539701
Email: vidhi.rastogi@wipro.com
SIP-IN Interworking Protocol Expires: Jan 2002
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process MUST be
followed, or as required to translate it into
