Network Working Group D. Lebovits
Internet Draft AT&T
draft-lebovits-sip-in-input-00.txt
Expires January 2002
SIP/IN Interworking
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 obsolete 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 provides input on SIP-IN Interworking to the SIP-IN design
team for consideration in the development of the informational RFC for
SIP-IN Interworking. This is complementary to SIP-IN Interworking and
Protocol Architecture and Procedures being evaluated by the SIP-IN
design team. SIP-IN Interworking is in support of service delivery in
converging networks.
Prior drafts discussed in the IETF have dealt with some of these
aspects.
2. Introduction
This draft provides input on SIP-IN Interworking to the SIP-IN design
team for consideration in the development of the informational RFC for
SIP-IN Interworking. This is complementary to SIP-IN Interworking and
Protocol Architecture and Procedures being evaluated by the SIP-IN
design team. SIP-IN Interworking is in support of service delivery in
converging networks.
This draft discusses the topics of Mapping Between SIP and IN; Example
of SIP to INAP mapping using Call Flows; Examples of Mapping of SIP
parameters to INAP parameters/operations; Examples of Mapping of
parameters between INAP parameters/operations and INVITE message;
Example of Mapping of the INAP serviceInteractionIndicators parameter;
Example of Mapping of the INAP EstablishTemporaryConnection operation;
Example of Mapping of parameters from INVITE to
AssistRequestInstruction; Example of Mapping of parameters from
InitiateCallAttempt to INVITE; Examples of Mapping of parameters
between INAP parameters/operations and SIP messages and parameters.
SIP-IN-Lebovits July 2001
<draft-lebovits-sip-in-input-00.txt> [Page 2]
Prior drafts discussed in the IETF have dealt with some of these
aspects.
3. Terminology
The key words "MUST","MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in RFC-2119.
4. Background
The IETF SIP-IN design team was formed to work on the SIP-IN
interworking IETF informational RFC. The SIP-IN design team aspects
include, 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.
5. Example of Mapping Between SIP and IN
A clear mapping between SIP and INAP messages SHALL be provided which
reflects similar meaning in call sequence.
Call message sequence SHALL be maintained in both directions.
The mapping between SIP and INAP is described using call flow
descriptions.
There are details such as some retransmissions and some states (e.g.
waiting for ACK,..etc.), that are not described.
5.1 Example of SIP to INAP mapping using Call Flows
The following call flows illustrate the order of messages in
typical success and error cases when setting up a call initiated
from the SIP network.
(1) When a SIP user wishes to begin a session with a INAP user,
the SIP node issues an INVITE request.
(2) Upon receipt of an INVITE request, the gateway maps it to an
INAP message and sends it to the INAP network.
(3) The remote INAP node indicates that the address is sufficient
to set up a call by sending back an ACK message.
(4) The "called party status" code in the ACK message is mapped
to a SIP provisional response and returned to the SIP node. This
response may contain SDP to establish an early media stream
(as shown in the diagram). If no SDP is present, the audio
will be established in both directions after step 12.
SIP-IN-Lebovits July 2001
<draft-lebovits-sip-in-input-00.txt> [Page 3]
(5) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(6) The PRACK is confirmed
(7) The remote INAP node may issue a variety of call process (CPG)
messages to indicate, for example, that the call is being forwarded.
(8) Upon receipt of a CPG message, the gateway will map the event
code to a SIP provisional response and send it to the SIP node.
(9) The SIP node sends a PRACK message to confirm receipt of the
provisional response.
(10)The PRACK is confirmed
(11)Once the INAP user answers, an answer message (ANM) message will be
sent to the gateway.
(12)Upon receipt of the ANM, the gateway will send a message
to the SIP node.
(13)The SIP node, upon receiving an INVITE final response,
will send an ACK to acknowledge receipt.
6. Examples of Mapping of parameters between INAP parameters/operations and
INVITE message
6.1 Example of Mapping of the INAP serviceInteractionIndicators parameter
The INAP serviceInteractionIndicators parameter contains information that is:
ò only of local significance, i.e. to be treated in the SSF;
ò relevant for the originating local exchange; or
ò relevant for the destination local exchange.
The SCF uses the RequestReportBCSMEvent operation to request the SSF to monitor
for call-related events. The monitor mode is indicated in the operation as
either "interrupted" or "notifyAndContinue".
In the "notifyAndContinue" mode the event is reported as EDP-N (notification
mode) in the EventReportBCSM operation or a DP specific operation,
respectively, to the SCF and normal call processing continues as IN basic call.
In the "interrupted" mode the event is reported as EDP-R (request mode) in the
EventReportBCSM operation or a DP specific operation, respectively, and the SSF
will wait for instructions from the SCF.
SIP-IN-Lebovits July 2001
<draft-lebovits-sip-in-input-00.txt> [Page 4]
The SCF logic may generate new service interaction information for the call.
In this case the indicators of the INAP serviceInteractionIndicators parameter
relevant for the forward direction, i.e. to be mapped into the INVITE.
The handling of the indicators relevant for the backward direction is however
different:
ò The indicators contained in the received INAP serviceInteractionIndicators
parameter are compared one by one against the indicators that are stored
in the SSF, i.e. that have been received in an earlier INAP operation.
ò If the received value of an indicator differs from the one that is stored
in the SSF, then this indicator is mapped to the corresponding value in
the appropriate SIP parameter.
ò If the received value of an indicator is equal to the one that is stored
in the SSF, then this indicator is mapped to the value "no indication" in
the appropriate SIP parameter.
6.2 Example of Mapping of the INAP EstablishTemporaryConnection operation
This section illustrates the mapping of parameters received in the INAP
EstablishTemporaryConnection operation to parameters sent in the INVITE
message.
The following INAP parameters include:
assistingSSPIPRoutingAddress
serviceInteractionIndicators
correlationID
scfID
NOTE - Optional parameters may be absent, i.e. they are only mapped, if
received.
The INAP correlationID and scfID parameters are mapped to the corresponding SIP
parameters in the INVITE message.
On receipt of the EstablishTemporaryConnection operation from the SCF a
connection will be established. For routing of the call the called party number
is derived from the assistingSSPIPRoutingAddress.
6.3 Example of Mapping of parameters from INVITE to AssistRequestInstruction
This section illustrates the mapping of parameters from INVITE message to the
INAP AssistRequestInstruction operation.
The following INAP parameters include:
correlationID
ConnectToResource
NOTE - Optional parameters may be absent, i.e. they are only mapped, if
received.
SIP-IN-Lebovits July 2001
<draft-lebovits-sip-in-input-00.txt> [Page 5]
The INAP correlationID and ConnectToResource parameters are mapped to the
corresponding SIP parameters in the INVITE message.
6.4 Example of Mapping of parameters from InitiateCallAttempt to INVITE
This section illustrates the mapping of parameters from INAP
InitiateCallAttempt operation to INVITE message.
The following INAP parameters include:
destinationRoutingAddress
callingPartyNumber
serviceInteractionIndicators
NOTE - Optional parameters may be absent, i.e. they are only mapped, if
received.
The Mapping of the INAP serviceInteractionIndicators is discussed in
Section 6.1 of this document. The INAP destinationRoutingAddress and
callingPartyNumber parameters are mapped to the corresponding SIP
parameters in the INVITE message.
6. Work item for standardization.
It is the proposal of this document to be input to the draft
informational RFC on SIP-IN interworking.
7. The Relation of the Proposal to the Existing Work in the IETF
This proposal is targeted to the SIP-IN Design Team, working on an
informational RFC on SIP-IN Interworking.
8. The Relation of the Proposal to the Work of Other Standards Bodies
ITU-T Study Group 11 is responsible for the Q.12xx Intelligent Network
Capability Set Recommendations, including the definition of interfaces
between IN functional entities and INAP protocol.
9. Security Considerations
No Security issues are identified in this document.
10. Conclusion
This draft provides input on SIP-IN Interworking to the SIP-IN design
team for consideration in the development of the informational RFC for
SIP-IN Interworking. This is complementary to SIP-IN Interworking and
Protocol Architecture and Procedures being evaluated by the SIP-IN
design team.
SIP-IN-Lebovits July 2001
<draft-lebovits-sip-in-input-00.txt> [Page 6]
SIP-IN Interworking is in support of service delivery in converging networks.
This draft discusses the topics of Mapping Between SIP and IN; Example
of SIP to INAP mapping using Call Flows; Examples of Mapping of SIP
parameters to INAP parameters/operations; Examples of Mapping of
parameters between INAP parameters/operations and INVITE message;
Example of Mapping of the INAP serviceInteractionIndicators parameter;
Example of Mapping of the INAP EstablishTemporaryConnection operation;
Example of Mapping of parameters from INVITE to
AssistRequestInstruction; Example of Mapping of parameters from
InitiateCallAttempt to INVITE; Examples of Mapping of parameters
between INAP parameters/operations and SIP messages and parameters.
Prior drafts discussed in the IETF have dealt with some of these aspects.
11. References
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543bis,
DRAFT-IETF-SIP-RFC2543BIS-02.PS, November 2000.
[2] V. Gurbani, "Accessing IN Services from SIP Networks," Internet
Draft <draft-gurbani-iptel-sip-to-in-04.txt>, Internet Engineering Task
Force, August 2001, work in progress.
[3] F. Haerens, "SIP-IN Interworking Protocol Architecture and Procedures",
Internet Draft <draft-haerens-sip-inap-00.txt>, February 2001, work in
progress.
[4] ITU-T Q.1224 Recommendation, "Distributed functional plane for
Intelligent Network Capability Set 2", approved 1997.
[5] ITU-T Q.1238 Recommendation, "Interface Recommendation for
Intelligent Network Capability Set 3", approved 2000.
11. Author's Address
Doris Lebovits
AT&T
180 Park Ave.
Florham Park, New Jersey, 07932
Phone: (973) 236-6776
Email: dlebovits@att.com
SIP-IN-Lebovits July 2001
<draft-lebovits-sip-in-input-00.txt> [Page 7]
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 implementation 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 followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.