[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/