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 [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 [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 [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 [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 [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 , Internet Engineering Task Force, August 2001, work in progress. [3] F. Haerens, "SIP-IN Interworking Protocol Architecture and Procedures", Internet Draft , 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 [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.