Request for Comments: 4083 Nokia
Category: Informational May 2005
Input 3rd-Generation Partnership Project (3GPP)
Release 5 Requirements on the Session Initiation Protocol (SIP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The 3rd-Generation Partnership Project (3GPP) has selected Session
Initiation Protocol (SIP) as the session establishment protocol for
the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of
Release 5 of the 3GPP specifications. Although SIP is a protocol
that fulfills most of the requirements for establishing a session in
an IP network, SIP has never been evaluated against the specific 3GPP
requirements for operation in a cellular network. In this document,
we express the requirements identified by 3GPP to support SIP for
Release 5 of the 3GPP IMS in cellular networks.
Table of Contents
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Overview of the 3GPP IMS ........................................5
4. 3GPP Requirements on SIP ........................................7
4.1. General Requirements .......................................7
4.1.1. Efficient Use of the Radio Interface ................7
4.1.2. Minimum Session Setup Time ..........................7
4.1.3. Minimum Support Required in the Terminal ............8
4.1.4. Roaming and Non-roaming .............................8
4.1.5. Terminal Mobility Management ........................8
4.1.6. IP Version 6 ........................................8
4.2. SIP Outbound Proxy .........................................8
4.2.1. SIP Outbound Proxy ..................................8
4.2.2. Discovery of the SIP Outbound Proxy .................8
4.3. Registration ...............................................9
4.3.1. Registration Required ...............................9
4.3.2. Efficient Registration .............................10
4.3.3. Registration for Roaming and Non-roaming Cases .....10
4.3.4. Visited Domain Name ................................10
4.3.5. De-registration ....................................10
4.4. SIP Compression ...........................................11
4.4.1. Compression Algorithm Independence .................12
4.4.2. Extensibility of the SIP Compression ...............12
4.4.3. Minimal Impact of SIP Compression on the Network ...12
4.4.4. Optionality of SIP Compression .....................12
4.5. QoS Requirements Related to SIP ...........................13
4.5.1. Independence between QoS Signaling and SIP .........13
4.5.2. Coordination between SIP and QoS/Resource
Allocation .........................................13
4.6. Prevention of Theft of Service ............................14
4.7. Radio Resource Authorization ..............................14
4.8. Prevention of Malicious Usage .............................14
4.9. Prevention of Denial of Service ...........................14
4.10. Identification of Users ..................................15
4.10.1. Private User Identity ............................15
4.10.2. Public User Identities ...........................15
4.10.3. Delivery of the Dialed Public User ID ............17
4.11. Identifiers Used for Routing .............................17
4.12. Hiding Requirements ......................................17
4.12.1. Hiding of the Network Structure ..................17
4.12.2. Hiding of IP Addresses ...........................17
4.12.3. SIP Hiding Proxy .................................18
4.13. Cell-ID ..................................................18
4.13.1. Cell-ID in Signaling from the UA to the
Visited and Home .................................18
4.13.2. Format of the Cell-ID ............................18
4.14. Release of Sessions ......................................18
4.14.1. Ungraceful Session Release .......................19
4.14.2. Graceful Session Release .........................19
4.15. Routing of SIP Messages ..................................20
4.15.1. SIP Outbound Proxy ...............................20
4.15.2. SIP Serving Proxy in the Home Network ............20
4.15.3. INVITE Might Follow a Different Path than
REGISTER .........................................20
4.15.4. SIP Inbound Proxy ................................20
4.15.5. Distribution of the Source Routing Set of
Proxies ..........................................21
4.16. Emergency Sessions .......................................21
4.17. Identities Used for Session Establishment ................21
4.17.1. Remote Party Identification Presentatio ..........21
4.17.2. Remote Party Identification Privacy ..............21
4.17.3. Remote Party Identification Blocking .............21
4.17.4. Anonymity ........................................22
4.17.5. Anonymous Session Establishment ..................22
4.18. Charging .................................................22
4.18.1. Support of Both Prepaid and Postpaid Models ......22
4.18.2. Charging Correlation Levels ......................23
4.18.3. Charging Correlation Principles ..................23
4.18.4. Collection of Session Detailed Information .......24
4.19. General Support of Additional Capabilities ...............24
4.19.1. Additional Capabilities ..........................24
4.19.2. DTMF Signaling ...................................24
4.19.3. Early Media ......................................25
4.20. Exchange of Session Description ..........................25
4.21. Prohibition of Certain SDP Parameters ....................26
4.21.1. Prohibition of Codecs ............................26
4.21.2. Prohibition of Media Types .......................26
4.22. Network-initiated Re-authentication ......................26
4.23. Security Model ...........................................27
4.24. Access Domain Security ...................................28
4.24.1. General Requirements .............................28
4.24.2. Authentication ...................................29
4.24.3. Message Protection ...............................29
4.24.4. Negotiation of Mechanisms ........................31
4.24.5. Verification of Messages .........................31
4.25. Network Domain Security ..................................32
5. Security Considerations ........................................32
6. Contributors ...................................................32
7. References .....................................................32
7.1. Normative References ......................................32
7.2. Informative References ....................................33
1. Introduction
3GPP has selected SIP [2] as the protocol to establish and tear down
multimedia sessions in the IP Multimedia Subsystem (IMS). 3GPP
Technical Specification 23.228 [28] describes the IMS. 3GPP
Technical Specification 24.228 [29] contains a comprehensive set of
session flows. 3GPP Technical Specification 24.229 [30] describes
the usage of SIP by the various IMS nodes.
This document is an effort to define the requirements applicable to
the usage of the SIP protocol suite in cellular networks,
particularly in the 3GPP IMS for Release 5 of the 3GPP
specifications. Further releases of the 3GPP specifications may
contain additional SIP requirements. This document focuses on the
requirements identified for the 3GPP Release 5 IMS.
The rest of this document is structured as follows:
o Section 3 offers an overview of the 3GPP IMS. Readers who are not
familiar with it should carefully read this section.
o Section 4 contains the 3GPP requirements to SIP. Requirements are
grouped by category. Some requirements include statements on
possible solutions that would be able to fulfill them. Note that,
as a particular requirement might be fulfilled by different
solutions, not all the solutions might have an impact on SIP.
This document is advisory in nature. Its primary purpose is to help
the IETF understand the IMS environment. Given this better
understanding, we expect that the IETF can more effectively evolve
the SIP protocol. The IETF will not respond to the requirements
given in this document on a point-for-point basis. Some requirements
have been and/or will be met by extensions to the SIP protocol.
Others may be addressed by effectively using existing capabilities in
SIP or other protocols, and we expect that individual members of the
SIP community will work with 3GPP to achieve a better understanding
of these mechanisms. Some of the requirements in this document may
not be addressed at all by the IETF, although we believe that the act
of documenting and discussing them is in itself helpful in achieving
a better all-around understanding of the task at hand.
2. Conventions
This document does not specify any protocol of any kind. Therefore,
the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document, as described in RFC 2119 [1], does not
apply.
3. Overview of the 3GPP IMS
This section gives the reader an overview of the 3GPP IM CN Subsystem
(IMS). It is not intended to be comprehensive, but it provides
enough information to understand the basis of the 3GPP IMS. Readers
are encouraged to find a more detailed description in the 3GPP
Technical Specifications 23.060 [27], 23.228 [28], and 24.228 [29].
For a particular cellular device, the 3GPP IMS network is further
decomposed in a home network and a visited network.
An IMS subscriber belongs to his or her home network. Services are
triggered and may be executed in the home network. One or more SIP
servers are deployed in the SIP home network to support the IP
Multimedia Subsystem. Among those SIP servers, there is a SIP
serving proxy, which is also acting as a SIP registrar.
Authentication/Authorization servers may be part of the home network
as well. Users are authenticated in the home network.
A SIP outbound proxy is provided to support the User Agent (UA). The
SIP outbound proxy is typically located in the visited network,
although it may be located in the home network as well. The SIP
outbound proxy maintains security associations between itself and the
terminals, and interworks with the resource management in the packet
network.
The SIP outbound proxy is assigned after the mobile device has
connected to the access network. Once this proxy is assigned, it
does not change while the mobile remains connected to the access
network. Thus the mobile can move freely within the access network
without SIP outbound proxy reassignment.
The home network may also support one or more SIP edge proxies.
These nodes may act as the first entry points for SIP signaling to
the home network and may determine (with the help of location
servers) which SIP registrar server to assign to a particular user.
Typically the address of the home network SIP edge proxy is
configured in DNS in the form of a DNS Naming Authority Pointer
(NAPTR) and Service (SRV) records for SIP.
Additionally, home and visited networks may deploy, if required, a
SIP-hiding proxy. The main purpose of the SIP-hiding proxy is to
hide the network configuration.
The 3GPP IM CN Subsystem is designed to be access independent.
Access is granted from 3GPP cellular terminals or from other
terminals that use other accesses out of the scope of 3GPP.
3GPP cellular IP Multimedia terminals use the existing General Packet
Radio Service (GPRS) [27] as a transport network for IP datagrams.
The terminals first connect to the GPRS network to get an IPv6
prefix. In order to do this, the terminals must perform a GPRS
Attach procedure followed by a GPRS PDP Context Activation procedure.
These GPRS procedures are required to be completed before any IP
Multimedia session can be established.
As a result of the above-mentioned GPRS procedures, the terminal has
built an IPv6 address. The IPv6 address belongs to the same network
address space as does the SIP outbound proxy. The address does not
change, as the mobile terminal moves while still attached to the same
network address space.
If the terminal moves from a GPRS access to another GPRS access, the
above-mentioned GPRS procedures needs to start from the beginning to
allocate an IPv6 address to the terminal.
Figure 1 shows an overview of the 3GPP architecture for IM CN
Subsystem.
+-------------+ +----------------+ +----------------+
| | | | | +------+ |
| | | | | | SIP | |
| | | | | |server| |
| | | | | | +------+ |
+-|+ | | | | | / |
| | | | | +------+ | | +------+ |
| | | | | | SIP | | | | SIP | |
| | ---|-------------|--|----|server|----|---|-|server| |
+--+ | | | +------+ | | +------+ |
| | | | | |
SIP | GPRS access | | Visited Network| | Home Network |
dev. +-------------+ +----------------+ +----------------+
Figure 1: Overview of the 3GPP IMS architecture
Another possible future configuration is depicted in Figure 2. In
that case, a general-purpose computer (e.g., a laptop computer) is
connected to a GPRS terminal. The computer hosts the Multimedia
application (comprising SIP, SDP, RTP, etc.). The GPRS terminal
handles the radio access and the GPRS connectivity. Note that, for
the sake of clarity, in this example the home network has not been
depicted in the figure.
+-------------+ +----------------+
+-------+ | | | | |
| | +-|+ | | | |
| | | | | | | +------+ |
+-------+ | | | | | | SIP | |
/ / --------| | ---|-------------|-------|server|------
/-------/ +--+ | | | +------+ |
| | | |
SIP GPRS | GPRS access | | Visited Network|
client terminal +-------------+ +----------------+
Figure 2: A computer connected to a GPRS terminal
Services are typically executed in an application server. The
interface between the SIP server and the application server is based
on SIP. However, certain operators may want to reuse the existing
technology, and therefore, they may need to interoperate SIP with
protocols such as CAMEL/Intelligent-Network or Open Services
Architecture (OSA).
4. 3GPP Requirements on SIP
4.1. General Requirements
This section does not specify any particular requirement for SIP.
However, it includes a list of general requirements that must be
considered when developing solutions to particular requirements.
4.1.1. Efficient Use of the Radio Interface
The radio interface is a scarce resource. As such, the exchange of
signaling messages between the mobile terminal and the network should
be minimized. All the mechanisms developed should make an efficient
use of the radio interface.
See also the related requirements in Section 4.4.
4.1.2. Minimum Session Setup Time
All the procedures and mechanisms should have a minimum impact on the
session setup time as perceived by the user. When there is a choice
between performing tasks at session establishment and prior to
session establishment, then tasks should be performed prior to
session establishment.
See also the related requirements in Section 4.4.
4.1.3. Minimum Support Required in the Terminal
As terminals could be rather small devices, memory requirements,
power consumption, processing power, etc., should be kept to a
minimum. Mandating support for additional protocols in the terminal
must meet this requirement.
4.1.4. Roaming and Non-roaming
All the requirements must be met for both roaming and non-roaming
scenarios. There should not be a significant change in the signaling
procedures between roaming and non-roaming scenarios.
4.1.5. Terminal Mobility Management
As terminal mobility is managed by the access network, there is no
need to support terminal mobility management in SIP.
4.1.6. IP Version 6
3GPP IMS is solely designed to use IP version 6. As a consequence,
all protocols must support IPv6 addresses.
4.2. SIP Outbound Proxy
4.2.1. SIP Outbound Proxy
A SIP outbound proxy is provided to support both roaming and
non-roaming scenarios. The SIP outbound proxy may be located either
in the home network or in the visited network.
4.2.2. Discovery of the SIP Outbound Proxy
There must be a general mechanism whereby the mobile device (UA)
learns the SIP outbound proxy address.
The DHCPv6 option for SIP servers in RFC 3319 [19] seems to fulfill
the requirement.
In addition to the above-expressed requirement, the 3GPP access
network may provide the SIP outbound proxy address during access
network bearer establishment. This is considered a less general
mechanism, though.
4.3. Registration
The home network must maintain one or more SIP registrars. The SIP
registrar authenticates the user and registers the IP address where
the user can be located.
Once the terminal is switched on, the mobile device UA reads its
configuration data. This data may be stored in a SIM card or in any
other memory device. The configuration data contains an
identification of the home network. The device finds the SIP
registrar address from the home network domain name. The terminal
sends the registration through the SIP outbound proxy.
In order to support the search of the registrar, the home network
contains one or more SIP servers that may be configured in DNS with
the NAPTR/SRV record of SIP. These are the home network edge
proxies. Their mission is to serve as the first points of contact in
the home network, and to decide (with the help of location servers)
which SIP registrar server to assign to a particular user.
The procedures specified in RFC 3263 [10] applied to a REGISTER
message seem to be sufficient to meet this requirement.
4.3.1. Registration Required
A user must register to the IMS before he/she can receive any
invitation to any sessions. In addition, it is desirable for the
user to register before initiating any sessions. The following
factors contribute to the rationale behind this:
1. The SIP serving proxy in the home network needs to know when and
from which terminal the user is available, in order to route
received SIP requests for sessions and services.
2. The user can be pre-authenticated early so that authentication
does not contribute to post-dial delay. The procedure should not
have a penalty on the session setup time (see also the
requirement stated in Section 4.1.2).
3. The user is assigned a particular serving proxy. The serving
proxy downloads the service profile for that user to trigger
services.
Therefore, 3GPP has mandated the mobile device UA to register before
the mobile device UA initiates any session.
4.3.2. Efficient Registration
Due to the scarce radio interface resource, a single registration
must be sufficient to ensure that the mobile UA is reachable from
both the home and the visited networks.
A single REGISTER message, addressed to the registrar, may traverse
the SIP outbound proxy. This can install, if needed, soft
registration states in the SIP outbound proxy.
4.3.3. Registration for Roaming and Non-roaming Cases
Independent of whether the UA is roaming, it is desirable for the
registration procedure to be the same.
4.3.4. Visited Domain Name
The home network must be able to validate the existence of a roaming
agreement between the home and the visited network. The home network
needs to validate that the user is allowed to roam to such a visited
network. Therefore, there must be a mechanism whereby the visited
network identity is known at registration time at the home network.
It is acceptable to represent the visited network identity either as
a visited network domain name or as a string.
4.3.5. De-registration
4.3.5.1. De-registration of Users
There must be a procedure for a user to de-register from the network.
This procedure may be used, for example, when the user deactivates
the terminal.
We believe that a REGISTER with an expiration timer of 0 will meet
the requirement.
4.3.5.2. Network-initiated De-registration or Re-registration
In a number of situations a network needs to de-register or trigger a
re-registration of a previously registered UA. Examples of usage are
described in sections 4.3.6.3, 4.3.6.4, and 4.3.6.5.
This implies a need for a notification mechanism whereby the UA can
be notified of the de-registration, or of a request for
re-registration.
We believe that this requirement is met by the SIP-specific event
notification [12] and a registration event package [14].
4.3.5.3. Network-initiated De-registration, Network Maintenance
There might be cases in which the SIP serving proxy has to shutdown;
e.g., due to maintenance operation. Although this situation is not