likely to happen in everyday situations, it is desirable to have a
mechanism to inform the UA that his current registration is being
cancelled. The UA may initiate another registration process that
will lead to the selection of a new SIP serving proxy.
4.3.5.4. Network-initiated De-registration, Network/Traffic Determined
The system must support a mechanism to avoid inconsistent information
storage and to remove any redundant registration information. This
case will occur when a subscriber roams to a different network
without a prior de-registration. This case occurs in normal mobility
procedures when the user roams from one access network to another, or
when new service conditions are imposed on roamers.
4.3.5.5. Network-initiated De-registration, Administrative
For different reasons (e.g., subscription termination, stolen
terminal, etc.) a home network administrative function may determine
a need to clear a user’s SIP registration. It is desirable to have a
mechanism whereby the SIP serving proxy can inform the UA that its
registration is being cancelled.
There must be a procedure for the SIP serving proxy to de-register
users. The de-registration information must be available at all the
proxies that keep registration state and the UA.
We believe that a procedure based on SIP-specific event notification
[12] and a registration event package [14] will meet this
requirement.
4.4. SIP Compression
The radio interface is a scarce resource, and typically the available
bandwidth over the radio interface is limited. These two factors
seem to limit the transport of possibly large SIP messages over the
air interface. Particularly, the session setup time might be
extended due to the time needed to transport SIP messages over a
limited bandwidth channel.
On the other hand, the number and size of certain SIP header values,
such as Via or Record-Route, seems not to be limited. A mobile
device UA may present limitations in the available memory to store
this kind of information.
Therefore, there must be a mechanism to efficiently transport SIP
signaling packets over the radio interface, by compressing the SIP
messages between the mobile device UA and the SIP outbound proxy, and
between the SIP outbound proxy and the mobile device UA. Note that
compression of IP and transport layer protocol headers that carry
these SIP messages is also a requirement, although we believe that
this does not have an impact on SIP.
4.4.1. Compression Algorithm Independence
The chosen solution(s) must be able to allow the operation under
several different compression algorithms.
4.4.2. Extensibility of the SIP Compression
The chosen solution(s) must be extensible to facilitate the
incorporation of new and improved compression algorithms in a
backward-compatible way, as they become available.
4.4.3. Minimal Impact of SIP Compression on the Network
Application-specific compression must minimize impacts on existing
3GPP access networks (such as base stations transceivers). On the
other hand, the compression mechanism should be independent of the
access; e.g., the compression must be defined between the mobile
device UA and the outbound SIP proxy.
4.4.4. Optionality of SIP Compression
It must be possible to leave the usage of compression for SIP
signaling optional. To facilitate mobile terminal roaming between
networks that are using compression, the mobile terminal should
always support SIP signaling compression. If compression is not
supported, communication may continue without compression, depending
on the local policy of the visited network.
4.4.4.1. Compression Reliability
The compression mechanism should be reliable and able to recover
automatically from errors generated during the decompression.
4.5. QoS Requirements Related to SIP
4.5.1. Independence between QoS Signaling and SIP
The selection of QoS signaling and resource allocation schemes must
be independent of the selected session control protocols. This
allows for independent evolution of QoS control and SIP.
4.5.2. Coordination between SIP and QoS/Resource Allocation
4.5.2.1. Allocation before Alerting
In establishing a SIP session, it must be possible for an application
to request that the resources needed for bearer establishment are
successfully allocated before the destination user is alerted. Note,
however, that it must be also possible for an SIP application in a
terminal to alert the user before the radio resources are established
(e.g., if the user wants to participate in the media negotiation).
We believe that this requirement is met by Integration of Resource
Management and SIP [15].
4.5.2.2. Destination User Participates in the Bearer Negotiation
In establishing a SIP session, it must be possible for a terminating
application to allow the destination user to participate in
determining which bearers will be established. However, it must be
possible to establish the SIP session without user intervention.
We believe that this requirement is met by the standard SDP
negotiation described in SIP [2], the SDP offer/answer model [11] and
the extensions described in Integration of Resource Management and
SIP
4.5.2.3. Successful Bearer Establishment
Successful bearer establishment must include the completion of any
required end-to-end QoS signaling, negotiation, and resource
allocation.
We believe that this requirement is met by the procedures described
in the Integration of Resource Management and SIP [15].
4.6. Prevention of Theft of Service
Typically, users are allocated QoS resources. There is an admission
control mechanism that prevents users exceeding the limits negotiated
with the network. The network must prevent unauthorized users to
make use of non-authorized resources. For instance, the network must
provide a mechanism to prevent a user from using the resources
allocated to a second user, and for which this second user may be
paying.
We believe that this requirement may be met by the procedures
described in the Private SIP extensions for Media Authorization [16].
4.7. Radio Resource Authorization
As radio resources are very valuable, the network must be able to
manage them in a controlled manner. The network must be able to
identify who is using these resources and to authorize their usage.
For example, a mobile device terminal could execute an unlimited and
uncontrolled resource reservation procedure if the network does not
supervise the usage of radio resources.
We believe that this requirement is met by the procedures described
in the Private SIP extensions for Media Authorization [16].
4.8. Prevention of Malicious Usage
The 3GPP IMS must prevent mobile devices from making malicious use of
the network. For instance, a malicious UA could not obey the
procedures related to the Record-Route header field: when sending
subsequent requests the UA could bypass proxies which inserted a
Record-Route header during the initial transaction.
4.9. Prevention of Denial of Service
The risk that a proxy will receive a denial of service attack should
be minimized. For instance, a malicious mobile device could learn a
SIP proxy IP address and port number (e.g., in a Record-Route header
value) and establish an attack upon that proxy.
4.10. Identification of Users
4.10.1. Private User Identity
In order to use the 3GPP IMS, a user is assigned a private user
identity. The home network operator assigns the private user
identity, which is used to identify the user uniquely from a network
perspective. The private user identity is used, for example, for
authentication, authorization, administration, and, possibly,
accounting purposes. Note that the private user identity is not used
for routing of SIP messages.
The private user identity is a unique global identity defined by the
Home Network Operator. The identity takes the form of a Network
Access Identifier (NAI) as defined in RFC 2486 [6].
The end user does not have access to the private user identity.
Typically the identity is stored in a Subscriber Identity Module
card.
The private user identity is permanently allocated to a user (it is
not a dynamic identity), and is valid for the duration of the user’s
business subscription with the home network.
4.10.1.1. Private User ID in Registrations
The mobile UA must deliver the private user identity to the SIP
outbound proxy and the registrar at registration time.
The private user identity is used as the basis for authentication
during registration of the mobile user. The term authentication is
used in this document with the same meaning as it is defined in RFC
2828 [7].
We believe that this requirement is met by populating the username
field of the Authorization: header value of the REGISTER request with
the private user identity.
4.10.2. Public User Identities
In order to use the 3GPP IMS, a user is assigned one or more public
user identities. The user will make use of the public user identity/
identities when requesting communication to other users. For
example, the public user identity might be included on a business
card.
Different public user identities may be grouped into a user profile.
A user may have different profiles, each one containing different
public user identities. A public user identity can be part of a
single user profile.
The user may need to register one or more public user identities
prior to receiving communications addressed to that public user
identity.
We believe that this requirement is met by populating the From: and
To: header values of a REGISTER message with the public user
identity.
4.10.2.1. Format of the Public User Identities
The public user identity must take the form of a SIP URI (as defined
in RFC 3261 [2] and RFC 2396 [4]) or of a E.164 [34] number.
We believe that this requirement is met by using SIP URLs and
telephone numbers represented in SIP URLs as described in SIP [3].
In addition, tel: URLs as specified in RFC 3966 [35] can be used to
fulfill the requirement.
4.10.2.2. Registration of Public User IDs
It must be possible to register globally (i.e., through one single UA
request) a user that has more than one public identity that belongs
to the same user profile, via a mechanism within the IMS. In this
case, the user will be registered with all the public identities
associated to a user profile.
We believe this requirement may be accomplished by external
procedures. For example, the user’s profile may contain a list of
alias identities that the registrar considers active if the primary
identity is registered. The user may get informed of the
automatically registered public user IDs by subscribing to its own
registration state.
4.10.2.3. Authentication of the public user ID
Public user identities are not authenticated by the 3GPP IMS.
However, the network authorizes that the public user identity is
associated with the registered private user identity.
There is a list of public user identities associated with each
private user ID within the IMS. IMS will reject attempts to use
other public identities with this private user ID.
4.10.3. Delivery of the Dialed Public User ID
Typically a UA will be registered under a set of different public
user IDs. As such, sessions destined to the user can be placed with
any of the registered public user IDs. The serving proxy and
application server(s) in the termination network may apply certain
filtering rules or services based on the public user ID contained in
the Request-URI. The UA may also apply certain filtering rules or
services based on the called public user ID.
Therefore, it must be possible for all sessions to deliver the dialed
public user ID to the terminating entities, such as the serving
proxy, application servers, and terminating UA.
4.11. Identifiers Used for Routing
Routing of SIP signaling within IMS must use SIP URLs as defined in
SIP [2]. E.164 [34] format public user identities must not be used
for routing within IMS, and session requests based on E.164 format
public user identities will require conversion into SIP URI format
for internal IMS usage.
We believe that this requirement is achieved by translating E.164
numbers into SIP URIs. A database, such as ENUM [9], might do the
job.
4.12. Hiding Requirements
Although the requirements included in this section are not optional,
the hiding feature is optional to use through configuration. This
means that a network operator can, at his desire, switch the hiding
functionality on or off.
4.12.1. Hiding of the Network Structure
A network operator need not be required to reveal the internal
network structure to another network (in Via, Route, or other
headers) that may contain indication of the number of SIP proxies,
domain name of the SIP proxies, capabilities of the SIP proxies, or
capacity of the network.
4.12.2. Hiding of IP Addresses
A network need not be required to expose the explicit IP addresses of
the nodes within the network (excluding firewalls and border
gateways).
4.12.3. SIP Hiding Proxy
In order to support the hiding requirements, a SIP hiding proxy may
be included in the SIP signaling path. This additional proxy may be
used to shield the internal structure of a network from other
networks.
4.13. Cell-ID
The identity of the cell through which the 3GPP UA is accessing the
IMS (Cell-ID) may be used by the home network to provide localized
services or information on the location of the terminal during an
emergency call (when emergency calls are handled in IMS; see also the
requirement stated in Section 4.16).
4.13.1. Cell-ID in Signaling from the UA to the Visited and Home
Networks
Assuming that the Cell-ID is obtained by the UA by other mechanisms
outside the scope of SIP, the Cell-ID must be transported at least in
the following procedures:
o Registration
o Session Establishment (Mobile Originated)
o Session Establishment (Mobile Terminated)
o Session Release
The Cell-ID is private information and only of interest in the UA
home network. Therefore, the Cell-ID should be removed prior to
sending the SIP signaling beyond the originating home network.
4.13.2. Format of the Cell-ID
The cell-ID must be sent in any of the formats described in the 3GPP
Technical Specification 23.003 [26].
4.14. Release of Sessions
In addition to the normal mechanisms for releasing a SIP session
(e.g., BYE), two cases are considered in this section: the ungraceful
session release (e.g., the terminal moves to an out-of-coverage zone)
and the graceful session release ordered by the network (e.g.,
prepaid caller runs out of credit).
We believe that this requirement is met by a SIP entity acting as a
so-called transparent back-to-back UA.
4.14.1. Ungraceful Session Release
If an ungraceful session termination occurs (e.g., a flat battery or
a mobile leaves coverage), when a call stateful SIP proxy server
(such as the SIP serving proxy at home) is involved in a session,
memory leaks and, eventually, server failure can occur due to hanging
state machines. To ensure stable server operation and carrier grade
service, a mechanism to handle the ungraceful session termination
issue must be provided. We assume that there is a mechanism by which
the SIP outbound proxy is notified, by a mechanism external to SIP,
of the ungraceful session termination. This allows transforming the
ungraceful session release into a graceful session release ordered by
the network (see the next section). For example, upon reception of
the notification of loss of mobile radio coverage, the SIP outbound
proxy could send a BYE request on behalf of the terminal, although
this BYE cannot be authenticated.
4.14.2. Graceful Session Release
There must be a mechanism whereby an entity in the network may order
the release of resources to other entities. This may be used, for
example, in prepaid calls when the user runs out of credit.
This release must not involve any request to the UA to send out a
release request (BYE), as the UA might not follow this request. The
receiving entity needs the guarantee that resources are released when
requested by the ordering entity.
The following objectives must be met:
o Accurately report the termination to the charging subsystem.
o Release the associated network resources: bearer resources and
signaling resources.
o Notify other parties to the session, if any, of the session
termination.
When feasible, this mechanism should be at the SIP protocol level in
order to guarantee access independence for the system.
4.15. Routing of SIP Messages
4.15.1. SIP Outbound Proxy
The 3GPP architecture includes a SIP outbound proxy that is typically
located in the visited network (although it may be located in the
home network). This outbound proxy provides local services such as
compression of SIP messages or security functions. In addition, the
outbound proxy may interact with the media reservation mechanism to
provide authentication and authorization support for media
reservation.
All mobile terminal originated session setup attempts must transit
the outbound proxy so that the services provided by the outbound
proxy can be delivered to the mobile terminal.
4.15.2. SIP Serving Proxy in the Home Network
The serving proxy in the home network allows triggering of user-
customized services that are typically executed in an application
server.
All mobile terminal originated session setup attempts must transit
the serving proxy in the home network so that the proxy can properly
trigger the SIP services allocated to the user (e.g., speed dial
substitution). This implies a requirement for some sort of source-
routing mechanism to ensure these proxies are transited correctly.
4.15.3. INVITE Might Follow a Different Path than REGISTER
The path taken by an INVITE request need not be restricted to the
specific path taken by a mobile terminal originated REGISTER request;
e.g., the INVITE may traverse just the SIP outbound proxy and the SIP
serving proxy, without passing through any other proxies. However,
the path taken by the INVITE may follow the same path taken by the
REGISTER.
4.15.4. SIP Inbound Proxy
The visited network may apply certain services and policies to
incoming sessions (such as establishment of security services or
interaction with the media reservation mechanism). Therefore, the
visited network may contain a SIP inbound proxy for terminating
sessions. In general, the SIP inbound proxy and the SIP outbound
proxy are the same SIP proxy.
4.15.5. Distribution of the Source Routing Set of Proxies
Sections 4.15.2 and 4.15.4 assume that a source-routing mechanism is
used to effect traversal of the required SIP proxies during session
setup.
There must be some means of dynamically informing the node that adds
the source-routing set of proxies that the INVITE has to traverse
(e.g., the outbound proxy or serving proxy) of what that set of
proxies should be.
The hiding requirements expressed in Section 4.12 also apply to the
said set of proxies.
4.16. Emergency Sessions
3GPP networks already contain alternative procedures for delivering
emergency sessions. Release 5 of the 3GPP specifications does not
add any requirement for SIP emergency sessions.
4.17. Identities Used for Session Establishment
4.17.1. Remote Party Identification Presentation
It must be possible to present to the caller the identity of the
party to which he/she may dial back to return a call.
We believe that this requirement is met by the procedures described
in RFC 3325 [17].
4.17.2. Remote Party Identification Privacy
In addition to the previous requirement, the called party must be
able to request that his/her identity not be revealed to the caller.
We believe that this requirement is met by the procedures described
in RFC 3323 [18].
4.17.3. Remote Party Identification Blocking
Regulatory agencies, as well as subscribers, may require the ability
of callers to block the display of their caller identification. The
destination subscriber’s SIP serving proxy may be perform this
function. In this way, the destination subscriber is still able to
do a session-return, session-trace, transfer, or any other
supplementary service.
Therefore, it must be possible that the caller request to block the
display of his/her identity on the callee’s display.
We believe that this requirement is met by the procedures described
in RFC 3323 [18].
4.17.4. Anonymity
Procedures are required for anonymous session establishment.
However, sessions are not intended to be anonymous to the originating
or terminating network operators.
We believe that this requirement is met by the procedures described
in RFC 3323 [18] and RFC 3325 [17].
4.17.5. Anonymous Session Establishment
If the caller requests that the session be anonymous, the User Agent
Client (UAC) must not reveal any identity information to the User
Agent Server (UAS).
If the caller requests that the session be anonymous, the terminating
network must not reveal any identity or signaling routing information
to the destination endpoint. The terminating network should
distinguish at least two cases: first, whether the caller intended
the session to be anonymous, and second, whether the caller’s
identity was deleted by a transit network.
We believe that this requirement is met by the procedures described
in RFC 3323 [18] and RFC 3325 [17].
4.18. Charging
The 3GPP charging implications are described in the 3GPP Technical
Specification 32.225 [31].
4.18.1. Support of Both Prepaid and Postpaid Models
Operators may choose to offer prepaid and/or postpaid services. The
prepaid model is accomplished with the support of the online charging
model. The postpaid model is accomplished with the support of the
offline charging model.
Online charging is the process whereby charging information can
affect, in real-time, the service rendered to the user, such as a
request for a graceful release of an existing session. Online
charging interacts with the SIP signaling.
Offline charging is the process whereby charging information does not
affect, in real-time, the service rendered to the user.
4.18.2. Charging Correlation Levels
The following levels of correlation for IMS charging are considered:
o Correlation within a session. A session may comprise a number of
media components. It must be possible to correlate the charging
data of the different media components belonging to a session.
o Correlation at media-component level. For a session comprising
several media types (such as audio and video), charging data is
generated for each media type and needs to be correlated between
network elements. For this, a media identifier will be unique and
will clearly identify which media type of a session this charging
information belongs to. This component identifier is not
exchanged between network elements and is based on the ordering of
media flows in the SDP. This ordering is the same as that used in
the binding information passed to the GPRS network.
4.18.3. Charging Correlation Principles
To support the correlation of charging information, the following
principles apply to both offline and online charging:
o The correlation of charging information for an IMS session is
based on the use of IMS Charging Identifiers (ICID).
o The first IMS network entity within the SIP signaling path is
responsible for assigning an ICID. This ICID will then be passed
along the whole session path in an end-to-end manner. However,
this will not preclude further elements (other SIP proxies) along
the session path from generating additional identifiers to be
passed along.
o The ICID is passed to all IMS network entities in the session
signaling path. This is performed using SIP signaling.
o The addresses of the charging functions are passed by the serving
SIP proxy to all IMS network entities in the session signaling
path. This is to provide a common destination for all the
charging records generated by each IMS network entity with the
same ICID.
o For the charging correlation between the GPRS network and the IMS,
one or more GPRS Charging IDs, which identify the PDP contexts of
the session, are passed from the GPRS network to the IMS.