Internet DRAFT - draft-loreto-sipping-3gpp-ics-requirements
draft-loreto-sipping-3gpp-ics-requirements
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]
