SIPPING Internet Draft Y. Shen Document: draft-shen-interaction-ind-01.txt Alcatel Expires: January 2007 August 2006 Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server need to set some indication in SIP message to indicate next application server, what are allowed and what are not allowed. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network. Conventions used in this document Shen Expires – January 2007 [Page 1] Service Interaction Indicator August 2006 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 [1]. Table of Contents 1. Introduction...................................................2 2. Mechanisms.....................................................3 3. Syntax.........................................................3 4. Forward Indicator..............................................4 5. Backward Indicator.............................................5 Security Considerations...........................................5 IANA Considerations...............................................6 Reference.........................................................6 Acknowledgments...................................................6 Author's Addresses................................................6 1. Introduction In SIP-based networks (RFC3261 [3]), there are several mechanisms for feature interactions. They may be grouped in three categories: - Identification interaction (who is calling, who will be called) - History interaction (what happened in this request: it was forwarded. And reasons for these happens) - Capability interaction (Indicating user agent capabilities) But there is also a need to provide interaction indicator for further actions of involving applications. For example, for a session between user A and B, there is an application server AS1 at originating side and an application server AS2 at the terminating side. The AS1 has launched an application for user A like alarm call (alerting users in a certain physical location for a emergence case). It makes no sense if this call will be forwarded. The "alarm call" application want to indicate that a call diversion on terminating side is not wished. Interaction of services is depending on behavior of services on a SIP node like application server and proxy. This document describes a mechanism for service interaction in SIP. It is extensible if certain applications need more indicators. In PSTN/PLMN world, a parameter "service interaction indicator" in INAP is used for exchanging service information between SCP and LEXs. This enables service inter working between supplement services in LEXs and IN services in SCP. The specification can be found in INAP CS2 (EN 301 140-1 V1.3.4 (1999-06) [4]). Shen Expires - January 2007 [Page 2] Service Interaction Indicator August 2006 2. Mechanisms A private SIP header fields, "P-Interaction-Indicator", is defined in this document for transporting interaction indicator that indicates application behaviors in SIP nodes in the next steps. Next steps mean time after the setting of "P-Interaction-Indicator". It has also an indication of direction. If an indicator is applicable for application after the application that set the indicator, then it has the direction indicator "forward". If an indicator is applicable for application before the application that set the indicator, then it has the direction indicator "backward". "P-Interaction-Indicator" can be inserted in INVITE, ACK in "forward" case and can be inserted in 18X and 20x responses in "backward" case. Typical use cases for "P-Interaction-Indicator" are a configuration with an application server on originating side and an application server on terminating side for a call. The originating application can use the forward "P-Interaction-Indicator" to indicate the terminating application server what SHALL be allowed or not allowed. The terminating application can use the backward "P-Interaction- Indicator" to indicate the originating application server what are allowed or not allowed. The "P-Interaction-Indicator" can also be used in case of multiple application servers on terminating or originating side. For example, one application server on the terminating can also set a forward indicator for other application server behind him. The "P-Interaction-Indicator" can also be used for applications in other SIP UA and SIP Proxy. 3. Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [2]. PIndicator = "P-Interaction-Indicator" HCOLON indicatorEntry *(COMMA Indicator-entry) indicatorEntry = "<" as-uri (SEMI indicationDirection) *( SEMI indicatorParam )">" as-uri= name-addr indicationDirection = "forward"/ "backward" indicatorParam = indToken *(HCOLON application) indToken = "allow" / "block" / "invoked" application = application-string *(COMMA application-string) Shen Expires - January 2007 [Page 3] Service Interaction Indicator August 2006 application-string = "conferenceRequest"/ "callCompletionRequest"/"callDiversion"/application-extension application-extension = token The P-Interaction-Indicator fully describes the interaction indicator. Its parameters are described below: "as-uri" specifies the URI of a SIP end point (a application server or other) that sets the interaction indicator. "indicationDirection" specifies the direction of the indicator: "forward" means it is applicable for applications on the terminating side. "backward" means it is applicable for applications on the originating side. "inToken" specifies the attribute of a set of "application". "allow" means certain "application" SHALL be enabled. "invoked" means certain "application" are already executed. "block" means certain "application" MUST be blocked to execute. "application" specifies name of applications, which MUST be understood from end to end. There are three predefined name: "conference" for treatment of conference. "callDiversion" is for call diversion like call forwarding "callCompletionRequest" is for a request to create a monitoring of state of call completion "application-extension" are for any additional application name. 4. Forward Indicator A forward indicator is used to inform application server on terminating side, which services MUST NOT be allowed or SHALL be activated. Originating application server MAY set a forward indicator to indicate terminating application. Invite: marc@anywhere.com ... P-Interaction-Indicator: The application server "as1.xxx.com" sets a forward indicator in "P- Interaction-Indicator", which indicates that requests for call completion SHALL be accepted, call diversion MUST NOT be allowed. Invite: marc@anywhere.com Shen Expires - January 2007 [Page 4] Service Interaction Indicator August 2006 ... P-Interaction-Indicator: , The application server "as2.xxx.com" appends a backward indicator, which indicates that conference treatment on the originating side MUST NOT be allowed. Note: Backward indicator MAY be set in 18x and 20x response and send back to originating side. Security Considerations The mechanism provided in this document is a partial consideration of the problem of service interaction in SIP. Some interactions in this document result in the transfer of confidential information. P-Interaction-Indicator can be inspected by any intermediaries participating in the Trust Domain. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust. It MUST be removed at border of the trusted domain. Shen Expires - January 2007 [Page 5] Service Interaction Indicator August 2006 When a trusted entity sends a message to any destination the P- Interaction-Indicator header field, the entity MUST take precautions to protect the identity information from eavesdropping and interception to protect the confidentiality and integrity of that identity information. The use of transport or network layer hop-by- hop security mechanisms, such as TLS or IPSec with appropriate cipher suites, can satisfy this requirement. IANA Considerations This document defines one new SIP private header field "P- Interaction-Indicator" which should be registered by the IANA in the SIP header registry. The following is the registration for the P-Interaction-Indicator header field: RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: P-Interaction-Indicator Compact Form: none Reference 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 3 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 4 ESTI, Intelligent Network Application Protocol (INAP) Capability Set 2 (CS2) Part 1: Protocol specification (EN 301 140-1 V1.3.4 1999-06) Acknowledgments Author's Addresses Yuzhong Shen Alcatel Shen Expires - January 2007 [Page 6] Service Interaction Indicator August 2006 Lorenzstrasse 10 70435, Stuttgart, Germany Email: yshen@alcatel.de Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Shen Expires - January 2007 [Page 7]