SIPPING Internet Draft Y. Shen Document: draft-shen-interaction-ind-02.txt Alcatel-Lucent Expires: August 2007 February 2007 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. Conventions used in this document Shen Expires – August 2007 [Page 1] Service Interaction Indicator February 2007 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..............................................5 5. Backward Indicator.............................................5 6. Application Gateway/Router.....................................6 7. Application Server Chain.......................................6 Security Considerations...........................................6 IANA Considerations...............................................7 Reference.........................................................7 Acknowledgments...................................................8 Author's Addresses................................................8 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. Shen Expires - August 2007 [Page 2] Service Interaction Indicator February 2007 2. Mechanisms Three private SIP header fields, "P-Interaction-Indicator", "P-App- Gateway" and "P-App-Chain" are 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. The "P-App-Gateway" header is used for identifying the application server who as the role of SCIM. The SCIM application server can coordinate application servers for one session. The "P-App-Chain" header is for tracking session information in each application server. Because original dialog/session information like call ID, To and From can changed if the application server acts as B2BUA mode. 3. Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [2]. Shen Expires - August 2007 [Page 3] Service Interaction Indicator February 2007 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 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: HOLD for Communication Hold TIP for Terminating Identity Presentation OIP for Originating Identification Presentation OIR for Originating Identification Restriction CONF for Conference 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 CW for Call Waiting ACRCB for Anonymous Communication Rejection and Communication Barring ECT for Explicit Communication Transfer CCBS for Call Completion on Busy Subscriber (monitoring busy subs) Any name for additional application name. PAppGateway = "P-App-Gateway" HCOLON appID appID = "<" as-uri SEMI sessionID SEMI regionID ">" as-uri = name-addr Shen Expires - August 2007 [Page 4] Service Interaction Indicator February 2007 sessionID = "session=" token regionID = "region=" "originating" / "terminating" PAppChain = "P-App-Chain" HCOLON appSessionID *( COMMA appSessionID ) appSessionID = "<" as-uri SEMI sessionID ">" sessionID = "session=" token 4. 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 ... 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. 5. 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. Shen Expires - August 2007 [Page 5] Service Interaction Indicator February 2007 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. 6. Application Gateway/Router Application Gateway is the sip application server that can coordinate applications in different server. This application server (AS0) can forward a sip request to a sip application server (AS1). Based on the result of apps 1, can the application forwards this request (maybe changed) to another application server (AS2). The Application AS0 is the only application server, which is visible for S-CSCF in context of 3GPP IMS. The "P-App-Gateway" header helps application servers behind the application server AS0 to know where is the application server master (AS0) for composition of applications. The session information of AS0 and the role application (originating or terminating) are also parts of this header. Example: P-App-Gateway: 7. Application Server Chain Since application servers in a chain for processing a sip session can act as B2BUA, session information in a SIP request and the request itself can be changed. Keeping own session information in each sip application server can help application server identifying related session in his session table. Appending own session information and keeping the P-App-Gateway header indicate that an application server wants to join the application composition in application server P- App-Gateway. Example: P-App-Chain: , 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. Shen Expires - August 2007 [Page 6] Service Interaction Indicator February 2007 Any intermediaries participating in the Trust Domain can inspect p- Interaction-Indicator, P-App-Gateway and P-App-Chain. 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 three new SIP private header fields "P- Interaction-Indicator", "P-App-Gateway" and "P-App-Chain" which 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 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: P-App-Gateway Compact Form: none RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: P-App-Chain 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 Shen Expires - August 2007 [Page 7] Service Interaction Indicator February 2007 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: yshen@alcatel-lucent.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 IETF Trust (2007). 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. Shen Expires - August 2007 [Page 8] Service Interaction Indicator February 2007 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 - August 2007 [Page 9]