SIPPING Internet Draft Y. Shen Document: draft-shen-interaction-ind-04.txt Alcatel-Lucent Expires: November 2008 May 2008 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 needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. 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. Table of Contents Shen Expires November 2008 [Page 1] Service Interaction Indicator May 2008 1. Introduction...................................................2 2. Terminology....................................................2 3. Mechanisms.....................................................3 4. Syntax.........................................................3 5. Forward Indicator..............................................4 6. Backward Indicator.............................................5 7. Proxy Behavior.................................................5 Security Considerations...........................................6 IANA Considerations...............................................6 Reference.........................................................6 Acknowledgments...................................................7 Author's Addresses................................................7 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) 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. A sip application server can also have the role of Service Capability Interaction Manager (SCIM) as defined in 3GPP IMS. This application server can coordinate applications in different sip application servers. Additional service information will be required for keeping service context in the SCIM server. 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. 2. Terminology 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]. Shen Expires - November 2008 [Page 2] Service Interaction Indicator May 2008 3. Mechanisms One private SIP header field "P-Interaction-Indicator" is defined in this document. The "P-Interaction-Indicator" header is 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 in INVITE and ACK, it is applicable for application after the application that sets the indicator. It has the forward direction. If an indicator in 18X and 20x responses, it is applicable for application before the application that sets the indicator. It has the backward direction. 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. 4. 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 indicatorParam )">" as-uri= name-addr indicatorParam = indToken *(HCOLON application) indToken = "allow" / "block" / "invoked" application = application-string *(COMMA application-string) application-string = token/application-extension Shen Expires - November 2008 [Page 3] Service Interaction Indicator May 2008 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. It is an optional "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-string" specifies name of applications, which MUST be understood from end to end. There are several predefined name for supplementary services: ACRCB for Anonymous Communication Rejection and Communication Barring CCBS for Call Completion on Busy Subscriber (monitoring busy subs) CDIV for Communication Diversion Services CFU for Communication Forwarding Unconditional CFB for Communication Forwarding Busy CFNR for Communication Forwarding No Reply CFNL for Communication Forwarding on Not Logged-In CD for Communication Deflection CO for Call Offering CONF for Conference CW for Call Waiting ECT for Explicit Communication Transfer HOLD for Communication Hold OIP for Originating Identification Presentation OIR for Originating Identification Restriction TIP for Terminating Identity Presentation Other application name can be added here. 5. Forward Indicator A forward indicator is used to inform application server on terminating side, which services MUST be blocked or SHALL be activated. Originating application server MAY set a forward indicator to indicate terminating application. Invite: marc@anywhere.com ... Shen Expires - November 2008 [Page 4] Service Interaction Indicator May 2008 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 forwarding CFU and CFB MUST be blocked, Originating Identification Presentation OIP is invoked. Invite: marc@anywhere.com ... P-Interaction-Indicator: The application server "as1.xxx.com" sets a forward indicator in "P- Interaction-Indicator", which indicates that a conference service is already happen. This means this is an invite to join a conference. 6. Backward Indicator A backward indicator is used to inform application server on originating side, which services MUST NOT be allowed or SHALL be activated. Terminating application server MAY sets a backward indicator to indicate originating application. 200 OK P-Interaction-Indicator: The application server "as2.xxx.com" sets a backward indicator, which indicates that conference treatment on the originating side MUST be blocked. Note: Backward indicator is in 18x and 20x responses. 7. Proxy Behavior A proxy in a Trust Domain can receive a message from a node that it trusts, or a node that it does not trust. When a proxy receives a message from a node it does not trust and it contains a P- Interaction-Indicator header field, the proxy MUST remove P- Interaction-Indicator header field. If the proxy receives a message Shen Expires - November 2008 [Page 5] Service Interaction Indicator May 2008 (request or response) from a node that it trusts, it does not remove the P-Interaction-Indicator header field. When a proxy forwards a message to another node, it must first determine if it trusts that node or not. If it does not trust the element, then the proxy MUST remove the P-Interaction-Indicator header field. If it trusts the node, the proxy does not remove the P- Interaction-Indicator header field. 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. Any intermediaries participating in the Trust Domain can inspect P- Interaction-Indicator. 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. 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" that should be registered by the IANA in the SIP header registry. The following are registration information: 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 Shen Expires - November 2008 [Page 6] Service Interaction Indicator May 2008 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. Acknowledgments Author's Addresses Yuzhong Shen Alcatel-Lucent Lorenzstrasse 10 70435, Stuttgart Germany Email: yuzhongshen@gmail.com 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 Shen Expires - November 2008 [Page 7] Service Interaction Indicator May 2008 Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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 - November 2008 [Page 8]