SIPPING Working Group S. Loreto Internet-Draft S. Terrill Expires: December 18, 2006 Ericsson June 16, 2006 Input 3rd-Generation Partnership Project (3GPP) Communications Service Identifiers Requirements on the Session Initiation Protocol (SIP) draft-loreto-sipping-3gpp-ics-requirements-00.txt 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 18, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The 3rd-Generation Partnership Project (3GPP) is developing the capability to support different communication services on IP Multimedia Subsystem (IMS) as a SIP infrastructure, such as push-to- talk over cellular (PoC), Multimedia Telephony or IMS messaging. As there are different services and is not safe to rely on the expressed media as a means to identify the requested communication service because the media may be used in different communication services, Loreto & Terrill Expires December 18, 2006 [Page 1] Internet-Draft SIP Communications Service Identifiers June 2006 then there is the need to have an unambiguous way of identifying communication services and applications utilizing the logic of communication services as explicitly as possible. In this document, we express the requirements identified by 3GPP to support the identification of communication services and applications on a Session Initiation Protocol (SIP) infrastructure and IMS applications using them. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements on the identification of communication services . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Requirements on the identification of applications using the communication services. . . . . . . . . . . . . 6 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informational References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Loreto & Terrill Expires December 18, 2006 [Page 2] Internet-Draft SIP Communications Service Identifiers June 2006 1. Introduction The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses the Session Initiation Protocol (SIP) [1] as its main signaling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [2] and 3GPP TS 24.229 [3]). During the definition of the IMS, 3GPP has adopted the approach of defining a number of procedures and protocols, aggregated in a number of communication services to be used by a number of service applications. With a system that supports a number of applications, each of them utilizing one or more communication services leads to the need of identifying both the communication service and application being invoked. In Release 7 3GPP has identified a set of requirements for the identification of IMS communication services [4] and IMS applications using them. In addition the IMS architecture has been adopted by a number of standardization organizations which themselves, as well as 3GPP, have been defining communication services which can operate over the IMS architecture. These communication services often require the support from particular application server functionality defined for the communication service. The remainder of this document is organized as follows. Section 3 gives an overview of the 3GPP scenarios and Section 4 discusses the requirements derived from these scenarios. Section 5 discusses the security properties. 1.1. Terminology and Acronyms Application : An application uses a communication service in order to provide a specific service to the end-user. Application Server (AS) : It is a SIP entity that hosts and executes services. Depending on the actual service the AS can operate in SIP proxy mode, SIP UA mode, or SIP B2BUA. Communication service : It is a type of communication defined by a service definition that specifies the rules and procedures and allowed medias for a specific type of communication. S-CSCF : It is essentially a SIP server, but it performs session control as well. All the SIP signaling the IMS terminals sends, and all the SIP signaling the IMS terminal receives, traverse the allocated S-CSCF. The S-CSCF inspects every SIP message and determines whether the SIP signaling should visit one or more application servers en route toward the final destination. Loreto & Terrill Expires December 18, 2006 [Page 3] Internet-Draft SIP Communications Service Identifiers June 2006 2. Overview In the IETF SIP standardization it has been assumed that the media components of a session could uniquely identify the communication service. In a multi-service architecture like IMS, a particular media can be used by a number of services. One such example is audio (RTP media) that is used in both push-to-talk and IMS Multimedia Telephony, but with totally different behaviour. For this reason a certain type of medium does not unambiguously identify a service. In the same way the full set of the medium involved in a particular service could not unambiguously identify a service. The IMS is a multi-service architecture, implying that a number of communication services can be built on a common architecture. A description of a communication service contains a description of the procedures for communication between different terminals. A communication service may be used to contact other users, as well as other services. As the IMS is based on SIP, the majority of the SIP procedures are common amongst the different communication services, though there may be specific usages of the procedures or functions in the network to support the service. 3GPP describes an IMS Communication Service as an aggregation of one or several media components and the service logic managing their aggregation represented in the protocol used. That means in IMS it is possible to introduce new services where for the same media different service logic can be applied, and different media handling could occur for different services. The logic of each of the standardized communication service can be utilized by a number of applications, each of them implementing a particular end-user service. Indeed other than the Default Application for the specific communication service it is also possible to define different applications using the same communication service. It is therefore necessary to design a mechanism that is separate from the media to identify both communication services and end-user- applications utilizing a set of communication services. A communication service identifier and an application reference provide a framework for the identification of communication services and applications. This could be seen as a means to identify the context upon which to interpret the SIP signaling, e.g. the media authorization policy can Loreto & Terrill Expires December 18, 2006 [Page 4] Internet-Draft SIP Communications Service Identifiers June 2006 be different for different services using the same media, or the identification of a service can be used in when the network is experiencing overload, where either some service may be prioritized over other services. Additionally it has to be identified in which end-user application context each communication service is used, specially having in mind that each of communication services can be simultaneously used by a number of applications. At terminals, the use of a communication service identifier is similar to the use of the address and port concept in TCP/IP, in that it allows applications in a terminal and the network that use SIP for communication purposes to be identified. In the terminal this means dispatching a SIP message to the correct application. It means that a SIP message can be dispatched to the correct communication service and a correct application can be invoked and receive this message. 3. Requirements 3.1. Requirements on the identification of communication services This section lists the requirements the communication service should fulfill: REQ-1: The Communication Service Identifier identifies the communication services and shall be included in the relevant SIP methods. REQ-2: It shall be possible for all entities in the networks, which evaluate the different possible protocol elements in order to determine which communications service is requested, arrive at the same result. REQ-3: It shall be possible for the UA and an Application Server (AS) to set the Communication Service Identifier in a SIP request, e.g. in the REGISTER and INVITE request. REQ-4: Based on operator policy the S-CSCF or an AS shall be able to validate a Communication Service Identifier in a SIP request. REQ-5: It shall be possible for the UA to identify a communication service uniquely by the Communication Service Identifier. REQ-6: It shall be possible for the UA to use the Communication Service Identifier as a key for dispatching the SIP Message to the appropriate communication service logic. REQ-7: It shall be possible for the UA to indicate its service capabilities to the network, e.g. during registration, using the Communication Service Identifier. Loreto & Terrill Expires December 18, 2006 [Page 5] Internet-Draft SIP Communications Service Identifiers June 2006 REQ-8: The structure of the Communication Service Identifier shall be as simple as possible, i.e. the Communication Service Identifier shall be limited to identify a service. REQ-9: Based on operator policy, the Communication Service Identifier shall be able to be used as a means to authorize and comunicate to the UA whether a subscriber is allowed to initiate or receive requests for a communication service. REQ-10: It shall be possible to take into account the Communication Service Identifier when selecting the correct UA(s) (i.e. in order to direct a terminating communication request towards a UA that understands the communication service). REQ-11: The usage of Communication Service Identifier shall not adversely affect interoperability between IMS networks and interoperability with external SIP networks. The behaviour of a network receiving the IMS requests without a Communication Service Identifier is a matter of operator policy. Usage of communication service identifier shall not decrease the level of interoperability with networks and UAs that are unaware of the communication service identifier. REQ-12: The usage of Communication Service Identifiers shall not restrict the inherent capabilities of SIP REQ-13: The usage of Communication Service Identifiers shall not require additional user interaction, i.e. the Communication Service Identifier is assumed to be "added" by the UA that initiates the communication. REQ-14: It shall be possible for the S-CSCF to invoke appropriate service logic based on the communication service identifier, as for all other information elements contained in a SIP request, e.g. route a SIP request containing a communication identifier to the correct AS. 3.2. Requirements on the identification of applications using the communication services. REQ-1: The Application Reference identifies the application that is using a communication service and shall be possible included in the relevant SIP methods. REQ-2: It shall be possible for the UA and an Application Server (AS) to set the Application Reference in a SIP request, e.g. in the REGISTER and INVITE request. REQ-3: It shall be possible for the UA to identify an end-user application uniquely by the Application Reference contained in a received SIP request. REQ-4: It shall be possible for the UA to invoke appropriate application that is using a communication service based on the Application Reference. Loreto & Terrill Expires December 18, 2006 [Page 6] Internet-Draft SIP Communications Service Identifiers June 2006 REQ-5: It shall be possible for the AS to identify the application or the end-user application context that is using a communication service through the use of Application Reference. REQ-6: It shall be possible for the UA to indicate its end-user service capabilities to the network, e.g. during registration, using the Application Reference. REQ-7: The structure of the Application Reference shall be as simple as possible, i.e. the Application Reference shall be limited to identify the application. REQ-8: The usage of Application Reference shall not restrict the inherent capabilities of SIP REQ-9: The usage of Application Reference shall not require additional user interaction, i.e. the Application Reference is assumed to be "added" by the UA the initiates the communication. 4. IANA considerations No actions from the IANA are requested. 5. Security Considerations This document discusses high-level requirements for SIP Communications Service and Applications Identifiers. Communication Service has some specific security requirements, which will be summarized here at a very high level. All of the operations and functions described in this document need to be authorized by the user or the network. It is expected that Communication Service will be governed by a set of authorization rules defined as a part of the Communication Service policy. These Communication Service security requirements will be discussed in detail in the protocol documents. 6. References 6.1. Normative References [1] 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. Loreto & Terrill Expires December 18, 2006 [Page 7] Internet-Draft SIP Communications Service Identifiers June 2006 6.2. Informational References [2] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 7.3.0, March 2006. [3] 3GPP, "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 7.3.0, March 2006. [4] 3GPP, "Identification of communication services in IMS", 3GPP TR 23.816 7.0.0, March 2006. Loreto & Terrill Expires December 18, 2006 [Page 8] Internet-Draft SIP Communications Service Identifiers June 2006 Authors' Addresses Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Salvatore.Loreto@ericsson.com Stephen Terrill Ericsson Via de los Poblados, 13 Madrid 28033 Spain Email: Stephen.Terrill@ericsson.com Loreto & Terrill Expires December 18, 2006 [Page 9] Internet-Draft SIP Communications Service Identifiers June 2006 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Loreto & Terrill Expires December 18, 2006 [Page 10]