AAA Working Group M. Garcia-Martin, Ed.
Internet-Draft M. Belinchon
Expires: December 15, 2003 M. Pallares-Lopez
C. Canales
Ericsson
P. McCann
Lucent Technologies
J. Rajaniemi
K. Tammi
Nokia Networks
June 16, 2003
Diameter Multimedia Application
draft-belinchon-aaa-diameter-mm-app-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 15, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies the Diameter Multimedia Application. This is
a Diameter application that allows a Diameter client to request
authentication and authorization information. This application is
designed to be used in conjunction with the Session Initiation
Protocol (SIP), and provides a Diameter client in a SIP server with
Garcia-Martin, et al. Expires December 15, 2003 [Page 1]
Internet-Draft Diameter Multimedia application June 2003
the ability to request a Diameter server the authentication of users
and authorization of SIP resources usage. This application does not
require or is not related to other authentication services provided
by the Mobile IP Diameter [7] or the Network Access Server Diameter
[8] applications.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of operation . . . . . . . . . . . . . . . . . . . 5
3.1 Diameter server authenticates the user . . . . . . . . . . . 6
3.2 SIP server authenticates the user . . . . . . . . . . . . . 8
3.3 Session attempt . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Update of the user profile . . . . . . . . . . . . . . . . . 11
3.5 Registration termination . . . . . . . . . . . . . . . . . . 12
4. Advertising Application Support . . . . . . . . . . . . . . 13
5. Diameter Multimedia Command Codes . . . . . . . . . . . . . 13
5.1 User-Authorization-Request (UAR) Command . . . . . . . . . . 13
5.2 User-Authorization-Answer (UAA) Command . . . . . . . . . . 14
5.3 Server-Assignment-Request (SAR) Command . . . . . . . . . . 17
5.4 Server-Assignment-Answer (SAA) Command . . . . . . . . . . . 19
5.5 Location-Info-Request (LIR) Command . . . . . . . . . . . . 22
5.6 Location-Info-Answer (LIA) Command . . . . . . . . . . . . . 23
5.7 Multimedia-Auth-Request (MAR) Command . . . . . . . . . . . 24
5.8 Multimedia-Auth-Answer (MAA) Command . . . . . . . . . . . . 25
5.9 Registration-Termination-Request (RTR) Command . . . . . . . 27
5.10 Registration-Termination-Answer (RTA) Command . . . . . . . 27
5.11 Push-Profile-Request (PPR) Command . . . . . . . . . . . . . 29
5.12 Push-Profile-Answer (PPA) Command . . . . . . . . . . . . . 30
6. New values for existing AVPs . . . . . . . . . . . . . . . . 31
6.1 Extension to the Result-Code AVP values . . . . . . . . . . 31
6.1.1 Success Result-Code AVP values . . . . . . . . . . . . . . . 31
6.1.2 Permanent failures . . . . . . . . . . . . . . . . . . . . . 32
7. Diameter Multimedia AVPs . . . . . . . . . . . . . . . . . . 33
7.1 SIP-Charging-Information AVP . . . . . . . . . . . . . . . . 34
7.1.1 Primary-Event-Charging-Function-Name AVP . . . . . . . . . . 35
7.1.2 Secondary-Event-Charging-Function-Name AVP . . . . . . . . . 35
7.1.3 Primary-Charging-Collection-Function-Name AVP . . . . . . . 35
7.1.4 Secondary-Charging-Collection-Function-Name AVP . . . . . . 35
7.2 SIP-Server-Name AVP . . . . . . . . . . . . . . . . . . . . 35
7.3 SIP-Server-Capabilities AVP . . . . . . . . . . . . . . . . 35
7.3.1 SIP-Mandatory-Capability AVP . . . . . . . . . . . . . . . . 36
7.3.2 SIP-Optional-Capability AVP . . . . . . . . . . . . . . . . 36
7.4 SIP-Server-Assignment-Type AVP . . . . . . . . . . . . . . . 36
7.5 SIP-Auth-Data-Item AVP . . . . . . . . . . . . . . . . . . . 37
7.5.1 SIP-Item-Number AVP . . . . . . . . . . . . . . . . . . . . 38
7.5.2 SIP-Authentication-Scheme AVP . . . . . . . . . . . . . . . 38
Garcia-Martin, et al. Expires December 15, 2003 [Page 2]
Internet-Draft Diameter Multimedia application June 2003
7.5.3 SIP-Authenticate AVP . . . . . . . . . . . . . . . . . . . . 38
7.5.4 SIP-Authorization AVP . . . . . . . . . . . . . . . . . . . 39
7.5.5 SIP-Authentication-Info AVP . . . . . . . . . . . . . . . . 39
7.5.6 SIP-Authentication-Context AVP . . . . . . . . . . . . . . . 39
7.6 SIP-Number-Auth-Items AVP . . . . . . . . . . . . . . . . . 40
7.7 SIP-Deregistration-Reason AVP . . . . . . . . . . . . . . . 40
7.7.1 SIP-Reason-Code AVP . . . . . . . . . . . . . . . . . . . . 40
7.7.2 SIP-Reason-Info AVP . . . . . . . . . . . . . . . . . . . . 40
7.8 SIP-Public-User-Identity AVP . . . . . . . . . . . . . . . . 40
7.9 SIP-Visited-Network-Identifier AVP . . . . . . . . . . . . . 41
7.10 SIP-User-Authorization-Type AVP . . . . . . . . . . . . . . 41
7.11 SIP-User-Data AVP . . . . . . . . . . . . . . . . . . . . . 42
7.12 SIP-User-Data-Already-Available AVP . . . . . . . . . . . . 42
7.13 SIP-User-Data-Request-Type AVP . . . . . . . . . . . . . . . 42
7.14 SIP-Confidentiality-Key AVP . . . . . . . . . . . . . . . . 43
7.15 SIP-Integrity-Key AVP . . . . . . . . . . . . . . . . . . . 43
8. Authentication Details . . . . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
Normative References . . . . . . . . . . . . . . . . . . . . 44
Informational References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . 48
Garcia-Martin, et al. Expires December 15, 2003 [Page 3]
Internet-Draft Diameter Multimedia application June 2003
1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels
for compliant implementations.
2. Introduction
This document specifies the Diameter Multimedia Application. This is
a Diameter application that allows a Diameter client to request
authentication and authorization information to a Diameter server for
Session Initiation Protocol (SIP) [6] based IP multimedia services.
We assume that the SIP server and the Diameter client are located in
the same node, so that the SIP server is able to receive and process
SIP requests and responses which in turn relies on the AAA
infrastructure for authenticating the SIP request and authorizing the
usage of particular SIP services.
This document provides Diameter procedures to implement certain
required functionality when SIP is the protocol chosen to initiate
and tear-down multimedia sessions. However, this document does not
mandate any particular mapping of SIP procedures to Diameter
Multimedia procedures, nor this document any particular sequence of
events between SIP and Diameter. In some cases, though, this document
provides with useful examples to show the interaction between SIP and
Diameter Multimedia in order to achieve the desired functionality.
The Overview chapter (Section 3) provides the reader with
non-normative description of the Diameter multimedia commands and
responses and some guidance of its linkage with SIP procedures.
Advertising of this application is described in the Advertising
Application Support chapter (Section 4).
The Diameter Multimedia Command Codes chapter (Section 5) provides a
normative description of all the new Diameter commands defined by
this specification.
This application extends the Result-Code Attribute-Value-Pair (AVP)
with some new values. Further information is described in the New
values for existing AVPs chapter (Section 6).
This application defines some new AVPs. All these AVPs are described
in the Diameter Multimedia AVPs chapter (Section 7).
Some extra information about authentication is provided in the
Garcia-Martin, et al. Expires December 15, 2003 [Page 4]
Internet-Draft Diameter Multimedia application June 2003
Authentication details chapter (Section 8).
3. Overview of operation
This section provides an informative description of how the Diameter
Multimedia application can be used together with SIP. By no means
this section mandates any specific usage of the Diameter Multimedia
application nor it mandates a specific mapping between SIP and
Diameter messages. This section is just a collection of examples that
shows how the required AAA functionality can be achieved in
conjunction with SIP.
The Diameter Multimedia Application can be used in a SIP environment
where an interface to a AAA infrastructure is required to
authenticate, authorize or provide accounting information. Figure 1
below shows a general overview of the integration of the SIP
architecture with the AAA architecture.
According to Figure 1, there is one or more SIP User Agents (UA) that
initiate or terminate SIP traffic through one or more SIP servers.
Both SIP servers implement a Diameter client that supports the
Diameter application described in this specification.
+--------+
UAR/UAA +----|Diameter|-----+ PPR/PPA
LIR/LIA | | server | | MAR/MAA
| +--------+ | SAR/SAA
| | RTR/RTA
| |
| |
v v
+------+ SIP +--------+ SIP +--------+ SIP +------+
| SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP |
| UA | |server 1| |server 2| | UA |
+------+ +--------+ +--------+ +------+
Figure 1
In Figure 1, it can be noticed that the SIP server 1 sends different
Diameter commands and responses than the SIP server 2. This is due to
the fact that the SIP server 1 in Figure 1 is located at the edge of
a network, and its main task is to locate SIP server 2. On the
contrary, SIP server 2 is getting authentication and authorization
data from the Diameter server.
It must be noted that this document does not mandate any particular
SIP/AAA architecture. However, the Diameter Multimedia application
provides the functionality needed to accommodate all the different
Garcia-Martin, et al. Expires December 15, 2003 [Page 5]
Internet-Draft Diameter Multimedia application June 2003
architectures where SIP and Diameter is used.
The following subsections provide an informative overview of the
Diameter Multimedia application, its commands, and a possible
interaction with SIP signaling.
3.1 Diameter server authenticates the user
In this approach we show an example of an administrative network
where the Diameter server is authenticating the user requests. This
could be the case of a medium size network where the Diameter server
is keeping user records and authenticating SIP requests to perform a
certain transaction. We have chosen to show a SIP REGISTER request in
the example, but the SIP server could request authentication of any
other SIP request.
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
---------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. 401 (Unauthorized) |
8. 401 (Unauth.) |<--------------------------------------|
-----------------| | |
9. SIP REGISTER | | |
---------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
|-------------------------------------->|
| | 13. MAR |
| |<------------------|
| | 14. MAA |
| |------------------>|
| 15. 200 (OK) | |
16. 200 (OK) |<--------------------------------------|
Garcia-Martin, et al. Expires December 15, 2003 [Page 6]
Internet-Draft Diameter Multimedia application June 2003
<----------------| | |
| | |
Figure 2
According to Figure 2 a SIP User Agent Client (UAC) sends a SIP
REGISTER request (step 1) to its home domain. SIP server 1 will
receive the SIP request. We assume that this SIP server may be
located, e.g., at the edge of the administrative home domain. The
Diameter client in SIP server 1 will contact its Diameter server by
sending a Diameter User-Authorization-Request (UAR) message (step 2)
to determine if this user is allowed to receive service, and if so,
request the address of a local SIP server capable of handling this
user. The Diameter server will answer with a Diameter
User-Authorization-Answer (UAA) message (step 3), which will indicate
either a list of capabilities that the SIP server 1 may use to select
an appropriate SIP server (SIP server 2) or a SIP or SIPS URI
pointing to SIP server 2.
SIP server 1 will forward the SIP REGISTER request (step 4) to an
appropriate SIP server (SIP server 2). The Diameter client in SIP
server 2 will then request user authentication from the Diameter
server by sending a Diameter Multimedia-Auth-Request (MAR) message
(step 5). This request will also serve to make the Diameter server
aware of the SIP or SIPS URI of the SIP server 2, so as to return
subsequent requests of the same user to the same SIP server 2. The
Diameter server will respond with a Diameter Multimedia-Auth-Answer
(MAA) message (step 6) with Result-Code AVP set to the value
DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a
challenge, which the SIP server 2 will use to map into the
WWW-authentication header in the SIP 401 (Unauthorized) response
(step 7), which is sent back to the SIP server 1 and then to the SIP
UAC (step 8).
When the SIP server 1 receives a next SIP REGISTER request containing
the user credentials (step 9), as there SIP server 1 does not need to
keep a state (even there is not guarantee the SIP request to arrive
to the same SIP server 1), the Diameter client in SIP server 1 will
contact again the Diameter server by sending a Diameter UAR message
(step 10) to determine the SIP server allocated to the user. The
Diameter server will send the SIP or SIPS URI of SIP server 2 in a
Diameter UAA message (step 11).
SIP server 1 will then forward the SIP REGISTER request to SIP server
2 (step 12). SIP server 2 will extract the credentials from the SIP
REGISTER request. The Diameter client in SIP server 2 will send those
credentials in a Diameter MAR message (step 13)to the Diameter
server. This message will also enable the Diameter server to identify
Garcia-Martin, et al. Expires December 15, 2003 [Page 7]
Internet-Draft Diameter Multimedia application June 2003
the URI of SIP server 2, so as to return subsequent requests to the
same SIP server 2. At this point, the Diameter server will be able to
authenticate the user, and upon success, will return a Diameter MAA
message (step 14) with the AVP Result-Code set to the value
DIAMETER_SUCCESS. The Diameter MAA message will also include the user
profile information, which the SIP server 2 will use to give service
to the user.
SIP server 2 will then generate a SIP 200 (OK) response (step 15)
which is forwarded to SIP server 1 and eventually to the SIP UAC
(step 16).
3.2 SIP server authenticates the user
An operator with a large base of installed SIP servers may wish to
minimize the impact of modifying SIP servers to interact with
Diameter servers. This can be achieved by allowing SIP servers to
retain the functionality of authentication, rather than centralizing
this capability in a Diameter server. However, it should be noted
that this mode will not leverage the extensive array of
authentication and authorization services which will already be
present regardless in Diameter servers.
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
---------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. 401 (Unauthorized) |
8. 401 (Unauth.) |<--------------------------------------|
<----------------| | |
9. SIP REGISTER | | |
---------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
Garcia-Martin, et al. Expires December 15, 2003 [Page 8]
Internet-Draft Diameter Multimedia application June 2003
|-------------------------------------->|
| | 13. SAR |
| |<------------------|
| | 14. SAA |
| |------------------>|
| 15. 200 (OK) | |
16. 200 (OK) |<--------------------------------------|
<----------------| | |
| | |
Figure 3
Figure 3 shows an example where a SIP server is dynamically allocated
to serve a SIP User Agent with the support of the Diameter server.
This may be the case of certain architectures, such as the 3rd
Generation Partnership Project (3GPP) IP Core Network Multimedia
Subsystem (IMS).
A first SIP server receives a SIP REGISTER request (step 1) addressed
to the home network domain. We assume that this SIP server may be
located, e.g., at the edge of the administrative home domain. The
Diameter client in this SIP server requests authorization to the
Diameter server to proceed with the registration, by sending a
Diameter User-Authorization-Request (UAR) message (step 2). The
message includes, among other Attribute-Value-Pairs (AVP), the SIP
address-of-record that is included in the SIP REGISTER request. The
Diameter server will verify the SIP address-of-record and if deemed
correct, will authorize the user to proceed with the registration in
the home domain. The Diameter server will respond with a Diameter
User-Authorization-Answer (UAA) message (step 3), which will inform
the Diameter client/SIP server about the result of the user
authorization. In case of a successful authorization, the Diameter
UAA message will indicate either the address of a local SIP server
(SIP server 2 in Figure 3) or a list of capabilities that SIP server
1 may use to select an appropriate SIP server 2.
When the authorization is successful, SIP server 1 will forward the
SIP REGISTER request (step 4) to the appropriate SIP server (SIP
server 2). The Diameter client in SIP server 2 will then request
authentication parameters by sending a Diameter
Multimedia-Auth-Request (MAR) message (step 5) to the Diameter
server. This request will also serve to make the Diameter server
aware of the SIP or SIPS URI of the SIP server 2, so as to return
subsequent requests of the same user to the same SIP server 2. The
Diameter server will respond with a Diameter Multimedia-Auth-Answer
(MAA) message (step 6), which will include all parameters necessary
for the designated authentication algorithm associated with the user.
SIP server 2 will then create a 401 (Unauthorized) SIP response (step
Garcia-Martin, et al. Expires December 15, 2003 [Page 9]
Internet-Draft Diameter Multimedia application June 2003
7), including the authentication material needed by the SIP User
Agent Client (UAC) to include the appropriate credentials. SIP server
1 forwards the SIP response to the SIP UAC (step 8).
When the SIP server 1 receives a next SIP REGISTER request containing
the user credentials (step 9), as the SIP server 1 does not need to
keep a state (even there is no guarantee that the SIP request arrives
to the same SIP server 1), the Diameter client in SIP server 1 will
contact again the Diameter server by sending a Diameter UAR message
(step 10) to determine the SIP server allocated to the user. The
Diameter server will send the SIP or SIPS URI of SIP server 2 in a
Diameter UAA message (step 11).
SIP server 1 will then forward the SIP REGISTER request to SIP server
2 (step 12). SIP server 2 will validate the credentials, and will
send a Diameter Server-Assignment-Request (SAR) message (step 13)
requesting the Diameter server to store the SIP or SIPS URI of the
SIP server that is currently serving the user. The Diameter SAR
message also serves the purpose to request the Diameter server to
send the user profile to the SIP server. The Diameter server will
respond with a Diameter Server-Assignment-Answer (SAA) message (step
14). If the Result-Code AVP value does not inform about an error, the
User-Data AVP will contain the information that SIP server 2 needs in
order to provide a service to the user.
The SIP server 2 will generate then a SIP 200 (OK) response (step 15)
that will be forwarded to SIP server 1 and eventually to the SIP UAC
(step 16).
3.3 Session attempt
Figure 4 shows the scenario where the SIP server 1 receives a SIP
INVITE request (step 1). The SIP server 1 needs to find the address
of the SIP server 2, which is serving the addressed UA. Therefore,
the Diameter client in SIP server 1 sends Diameter
Location-Info-Request (LIR) message (step 2) to the Diameter server.
The Diameter server responds with a Diameter Location-Info-Answer
(LIA) message (step 3) that contains the SIP or SIPS URI of the SIP
server 2. SIP server 1 then forwards the SIP INVITE to SIP server 2
(step 4). SIP server 2 will eventually forward the SIP INVITE to the
appropriate UAS (step 5).
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP INVITE | | |
Garcia-Martin, et al. Expires December 15, 2003 [Page 10]
Internet-Draft Diameter Multimedia application June 2003
-------------->| 2. LIR | |
|------------------>| |
| 3. LIA | |
|<------------------| |
| 4. SIP INVITE |
|-------------------------------------->|
| | | 5. SIP INVITE
| | |-------------->
| | |
| | |
Figure 4
Although the example shows the connection between a SIP INVITE
request and the Diameter LIR message, any other SIP request (such as
SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message.
3.4 Update of the user profile
The Diameter Multimedia application provides a mechanism for a
Diameter server to asynchronously download a user profile to a SIP
server whenever there is an update of such user profile. It must be
noted that the Diameter server also attaches the user profile in the
Diameter Server-Assignment-Request (SAR) message. Although this is
valid for most of the daily situations, it may happen that the
administrator decides to update or modify the user profile for a
particular user, due to, e.g., new services made available to the
user. This may involve a human intervention in the Diameter server or
some mechanism outside the scope of this specification. In this
situation, the Diameter server is able to push the new user profile
into the SIP server allocated to the user.
The scenario is described in Figure 5. In case the user profile
changes, the Diameter server will send a Diameter
Push-Profile-Request (PPR) message (step 1) to the Diameter client in
the SIP server allocated to that user (SIP server 2 in the examples).
The Diameter PPR message will contain a SIP-User-Data AVP, a
User-Name AVP and zero or more SIP-Public-User-Identity AVPs. The
presence of the User-Name AVP without any SIP-Public-User-Identity
AVPs serves to indicate that the entire user profile (included in the
SIP-User-Data AVP) associated with the User-Name AVP is updated. A
Diameter PPR message with a User-Name AVP and one or more
SIP-Public-User-Identity AVPs serves to indicate that the user
profile data associated with each of the SIP-Public-User-Identity
AVPs is updated. The Diameter client in SIP server 2 will acknowledge
the Diameter PPR message by sending a Diameter Push-Profile-Answer
(PPA) message (step 2) to the Diameter server.
Garcia-Martin, et al. Expires December 15, 2003 [Page 11]
Internet-Draft Diameter Multimedia application June 2003
+--------+ +--------+
|Diameter| | SIP |
| server | |server 2|
+--------+ +--------+
| |
| 1. PPR |
|------------------>|
| |
| 2. PPA |
|<------------------|
| |
Figure 5
3.5 Registration termination
Termination of a user registration can be achieved by either of the
following three mechanisms:
In the event that NO_STATE_MAINTAINED (i.e., No Diameter user
session-id is maintained) has been indicated in a prior
Auth-Session-State AVP, termination is handled with a Diameter
Session-Termination-Request (STR) message (if it is initiated by the
Diameter Client/SIP Proxy) or with a Diameter
Registration-Termination-Request (RTR) message (if it is initiated by
the Diameter server).
On the other hand, if STATE_MAINTAINED has been indicated in a prior
Auth-Session-State AVP, the use of Diameter
Session-Termination-Request (STR) and Abort-Session-Request (ASR)
messages as defined in the base Diameter specification [2] are used
to terminate a user registration.
Last, if the Diameter server receives a Diameter
Server-Assignment-Request (SAR) message that contains a
SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the
Diameter server will proceed with the deregistration of the user.
Reasons for terminating a user registration include:
o Expiration of the SIP registration timer in the SIP server.
o Administrative action taken at the Diameter server.
o The SIP UAC generates a SIP REGISTER request setting the Expires
header field value to zero or the expires parameter in the Contact
header field to zero (e.g., user initiated deregistration).
Garcia-Martin, et al. Expires December 15, 2003 [Page 12]
Internet-Draft Diameter Multimedia application June 2003
4. Advertising Application Support
Diameter nodes conforming to this specification MAY advertise its
support by including the Auth-Application-Id AVP in the
Capabilities-Exchange-Request and Capabilities-Exchange-Answer
commands, according to the Diameter base protocol [2].
5. Diameter Multimedia Command Codes
All the Diameter nodes conforming to this specification MUST
implement and support the list of Diameter commands listed in Table
1.
+----------------------------------+-------+-------+----------------+
| Command Name | Abbr. | Code | Reference |
+----------------------------------+-------+-------+----------------+
| User-Authorization-Request | UAR | aaa | Section 5.1 |
| User-Authorization-Answer | UAA | aaa | Section 5.2 |
| Server-Assignment-Request | SAR | bbb | Section 5.3 |
| Server-Assignment-Answer | SAA | bbb | Section 5.4 |
| Location-Info-Request | LIR | ccc | Section 5.5 |
| Location-Info-Answer | LIA | ccc | Section 5.6 |
| Multimedia-Auth-Request | MAR | ddd | Section 5.7 |
| Multimedia-Auth-Answer | MAA | ddd | Section 5.8 |
| Registration-Termination-Request | RTR | eee | Section 5.9 |
| Registration-Termination-Answer | RTA | eee | Section 5.10 |
| Push-Profile-Request | PPR | fff | Section 5.11 |
| Push-Profile-Answer | PPA | fff | Section 5.12 |
+----------------------------------+-------+-------+----------------+
Table 1
5.1 User-Authorization-Request (UAR) Command
The User-Authorization-Request (UAR) is indicated by the Command-Code
set to aaa and the Command Flags' 'R' bit set. The Diameter client in
a SIP server sends this command to the Diameter server to request
registration related authorization for a SIP User Agent.
The Diameter client in the SIP server will request authorization of
the REGISTRATION, DE-REGISTRATION or REGISTRATION&CAPABILITIES to the
Diameter server. See more information in the
SIP-User-Authorization-Type AVP (Section 7.10).
The user name used for authentication of the user is conveyed in a
User-Name AVP (imported from the Diameter baseprotocol [2]). The
location of the authentication user name in the SIP REGISTER request
Garcia-Martin, et al. Expires December 15, 2003 [Page 13]
Internet-Draft Diameter Multimedia application June 2003
varies depending on the authentication mechanism. When the
authentication mechanism is HTTP Digest as defined in RFC 2617 [4],
the authentication user name is found in the "username" directive of
the SIP Authorization header field value.
The SIP or SIPS URI to be registered is conveyed in the
SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP or
SIPS URI is found in the To header field value of the SIP REGISTER
request that triggered the Diameter UAR message.
The SIP-Visited-Network-Identifier AVP indicates the network that is
providing SIP services (e.g., SIP proxy functionality or any other
kind of services) to the SIP User Agent.
Message Format
<UAR> ::= < Diameter Header: aaa, REQ, PXY >
< Session-ID >
< Auth-Application-Id >
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
{ SIP-Public-User-Identity }
[ SIP-Visited-Network-Identifier ]
[ SIP-User-Authorization-Type ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
OPEN ISSUE: according to the above description, the User-Name AVP
is mandatory in the UAR message. This AVP is always available in a
3GPP environment, because 3GPP has mandated the private user
identity to be present in every REGISTER request. However, in a
general SIP environment, a SIP client will not insert any identity
without being challenged. Therefore, the User-Name AVP may not be
present. Action: investigate if this AVP can be set to optional.
5.2 User-Authorization-Answer (UAA) Command
The User-Authorization-Answer (UAA) is indicated by the Command-Code
set to aaa and the Command Flags' 'R' bit cleared. The Diameter
server sends this command in response to a previously received
Diameter User-Authorization-Request (UAR) command.
In addition to the values already defined in the Diameter base
Garcia-Martin, et al. Expires December 15, 2003 [Page 14]
Internet-Draft Diameter Multimedia application June 2003
protocol [2], the Result-Code AVP may contain one of the values
defined in Section 6.1.
Whenever the Diameter server fails to process the Diameter UAR
message, it MUST stop processing and return the concerned error in
the Diameter UAA message. When there is success in the process, the
Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter
UAA message.
When the authorization procedure succeeds, the Diameter server
constructs a User-Authorization-Answer (UAA) message that MUST
include either the address of the SIP server already assigned to the
user or the capabilities needed by the SIP server (Diameter client)
to select another SIP server for the user. This section will be based
on the required capabilities of the SIP server to trigger and execute
services for the user. The former option is used when the Diameter
server is aware of an allocated SIP server to the user, whereas the
latter is used when the Diameter server is not aware of an allocated
SIP server, letting the SIP server to choose, if needed, an
appropriate SIP server according to the required capabilities.
At reception of the Diameter UAR message, the Diameter server MUST
verify the existence of the user in the realm, i.e., the User-Name
AVP value is a valid user within that realm. If the Diameter server
does not recognize the user name received in the User-Name AVP, the
Diameter server MUST build a Diameter User-Authorization-Answer (UAA)
message and MUST set the Result-Code AVP to
DIAMETER_ERROR_USER_UNKNOWN.
Then Diameter server MUST authorize that User-Name AVP value is able
to register the SIP or SIPS URI included in the
SIP-Public-User-Identity AVP. If this authorization fails, the
Diameter server must set the Result-Code AVP to
DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
User-Authorization-Answer (UAA) message.
If there is a SIP-Visited-Network-Identifier AVP in the Diameter UAR
message, and the SIP-User-Authorization-Type AVP value received in
the Diameter UAR message is set to REGISTRATION or
REGISTRATION&CAPABILITIES then the Diameter server SHOULD verify
whether the user is allowed to roam into the network specified in the
SIP-Visited-Network-Identifier AVP in the Diameter UAR message. If
the user is not allowed to roam into such network, the Diameter AAA
server MUST set the Result-Code AVP value in the Diameter UAA message
to DIAMETER_ERROR_ROAMING_NOT_ALLOWED.
The Diameter server SHOULD verify whether the
SIP-Public-User-Identity AVP value is authorized to register in the
Garcia-Martin, et al. Expires December 15, 2003 [Page 15]
Internet-Draft Diameter Multimedia application June 2003
home realm. In case the Public Identity is not authorized to register
in the home realm, the Diameter server MUST set the Result-Code AVP
to DIAMETER_AUTHORIZATION_REJECTED and send it in a Diameter UAA
message.
In case that the SIP-User-Authorization-Type AVP value received in
the Diameter UAR message is set to REGISTRATION then:
o If the Diameter server is not aware of any previous registration
of the user name (including registrations of other public user
identities allocated to the same user name), then the Diameter
server does not know of any SIP server allocated to the user. In
this case the Diameter server MUST set the Result-Code AVP value
to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and
the Diameter server SHOULD include the required SIP server
capabilities in the SIP-Server-Capabilities AVP value in the
Diameter UAA message. The SIP-Server-Capabilities AVP will assist
the Diameter client (SIP server) to select an appropriate SIP
server for the user, according to the required capabilities.
o In some cases, the Diameter server is aware of a previously
assigned SIP server for the same or different public user identity
allocated to the same user name. In these cases, re-assignment of
a new SIP server may or may not be needed, depending on the
capabilities of the SIP server. The Diameter server MUST always
include the allocated SIP server URI in the SIP-Server-Name AVP of
the UAA message. If the Diameter server does not return the SIP
capabilities, the Diameter server MUST set the Result-Code AVP in
the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION.
Otherwise, if the Diameter server includes a
SIP-Server-Capabilities AVP then the Diameter server MUST set the
Result-Code AVP in the Diameter UAA message to
DIAMETER_SERVER_SELECTION. The Diameter client will then
determine, based on the received information, whether it needs to
select a new SIP server or not.
In case that the SIP-User-Authorization-Type AVP value received in
the Diameter UAR message is set to REGISTRATION&CAPABILITIES then
Diameter Server MUST return the list of capabilities in the
SIP-Server-Capabilities AVP value of the Diameter UAA message, it
MUST set the Result-Code to DIAMETER_SUCCESS and it MUST NOT return a
SIP-Server-Name AVP. The SIP-Server-Capabilities AVP enables the SIP
server (Diameter Client) to select another appropriate SIP server for
invoking and executing services for the user, depending on the
required capabilities. The Diameter server MAY leave the list of
capabilities empty to indicate that any SIP proxy can be selected.
In case that the SIP-User-Authorization-Type AVP value received in
Garcia-Martin, et al. Expires December 15, 2003 [Page 16]
Internet-Draft Diameter Multimedia application June 2003
the Diameter UAR message is set to DE-REGISTRATION then:
o If the Diameter server is aware of a SIP server assigned to the
public user identity under de-registration, the Diameter server
MUST set the Result-Code AVP in the Diameter UAA message to
DIAMETER_SUCCESS.
o If the Diameter server is not aware of a SIP server assigned to
the public user identity under de-registration, then the Diameter
server MUST set the Result-Code AVP in the Diameter UAA message to
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.
Message Format
<UAA> ::= < Diameter Header: aaa, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-Name ]
[ SIP-Server-Capabilities ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.3 Server-Assignment-Request (SAR) Command
The Server-Assignment-Request (SAR) command is indicated by the
Command-Code set to bbb and the Command Flags' 'R' bit set. The
Diameter client in a SIP server sends this command to the Diameter
server mainly to request the Diameter server to store the URI of the
SIP server that is currently serving the user.
During the registration procedure, a SIP server becomes assigned to
the user. The Diameter client in the assigned SIP server MUST include
its own URI in the SIP-Server-Name AVP of the
Server-Assignment-Request (SAR) Diameter message and send it to the
Diameter server. The Diameter server then becomes aware of the
allocation of the SIP server and its URI.
The Diameter client in the SIP server MAY send a Diameter SAR message
because of other reasons. These reasons are identified in the
SIP-Server-Assignment-Type AVP value (Section 7.4). For instance, a
Garcia-Martin, et al. Expires December 15, 2003 [Page 17]
Internet-Draft Diameter Multimedia application June 2003
Diameter client in a SIP server may contact the Diameter server to
request de-registration of a user, to inform the Diameter server of
an authentication failure or just to download the user profile. For a
complete description of all the SIP-Server-Assignment-Type AVP values
see Section 7.4.
Typically the reception of a SIP REGISTER request in a SIP server
will trigger the Diameter client in the SIP server to send the
Diameter SAR message. However, if a SIP server is receiving other SIP
request, such as INVITE, and the SIP server does not have the user
profile, the Diameter client in the SIP server may send the Diameter
SAR message to the Diameter server in order to download the user
profile and make the Diameter server aware of the SIP server assigned
to the user.
The user profile is an important piece of information that dictates
the behavior of the SIP server when triggering or providing services
for the user. Typically the user profile is divided into:
o Services to be rendered to the user when the user is registered
and initiates a SIP request.
o Services to be rendered to the user when the user is registered
and a SIP request destined to that user arrives to the SIP proxy.
o Services to be rendered to the user when the user is not
registered and a SIP request destined to that user arrives to the
SIP proxy.
The Diameter client can request the whole user profile or just the
portion of it where the SIP server is interested on. The
SIP-User-Data-Request-Type AVP and SIP-User-Data-Already-Available
AVP will indicate such request.
The SIP-Server-Assignment-Type AVP will indicate the reason why the
Diameter client (SIP server) contacted the Diameter server. If the
Diameter client sets the SIP-Server-Assignment-Type AVP value to
REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT,
AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client
MUST include exactly one SIP-Public-User-Identity AVP in the Diameter
SAR message.
Message Format
<SAR> ::= < Diameter Header: bbb, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
Garcia-Martin, et al. Expires December 15, 2003 [Page 18]
Internet-Draft Diameter Multimedia application June 2003
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ User-Name ]
* [ SIP-Public-User-Identity ]
[ SIP-Server-Name ]
{ SIP-Server-Assignment-Type }
{ SIP-User-Data-Request-Type }
{ SIP-User-Data-Already-Available }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.4 Server-Assignment-Answer (SAA) Command
The Server-Assignment-Answer (SAA) is indicated by the Command-Code
set to bbb and the Command Flags' 'R' bit cleared. The Diameter
server sends this command in response to a previously received
Diameter Server-Assignment-Request (SAR) command.
In addition to the values already defined in the Diameter base
protocol [2], the Result-Code AVP may contain one of the values
defined in Section 6.1.
The Result-Code AVP value in the Diameter SAA message may indicate a
success or an error in the execution of the Diameter SAR command. If
Result-Code AVP value in the Diameter SAA message does not contain an
error code, the SIP-User-Data AVP will typically contain the profile
of the user, indicating services that the SIP server can render to
such user.
At reception of the Diameter SAR message, the Diameter server MUST
verify the existence of the user in the realm, i.e., the User-Name
AVP value is a valid user within that realm. If the Diameter server
does not recognize the user name received in the User-Name AVP, the
Diameter server MUST build a Diameter Server-Assignment-Answer (SAA)
message and MUST set the Result-Code AVP to
DIAMETER_ERROR_USER_UNKNOWN.
Then Diameter server MUST authorize that User-Name AVP value is a
valid authentication name for the SIP or SIPS URI included in the
SIP-Public-User-Identity AVP of the Diameter SAR message. If this
authorization fails, the Diameter server must set the Result-Code AVP
to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
Server-Assignment-Answer (SAA) message.
The actions of the Diameter server at the reception of the Diameter
Garcia-Martin, et al. Expires December 15, 2003 [Page 19]
Internet-Draft Diameter Multimedia application June 2003
SAR message depends on the value of the SIP-Server-Assignment-Type:
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
message is set to REGISTRATION or RE_REGISTRATION, the Diameter
server SHOULD verify that there is only one
SIP-Public-User-Identity AVP. Otherwise, the Diameter server MUST
answer with a Diameter SAA message with the Result-Code AVP value
set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any
SIP-User-Data AVP. If there is only one SIP-Public-User-Identity
AVP, then the Diameter server SHOULD analyze the requested type of
data in the SIP-User-Data-Request-Type and
SIP-User-Data-Already-Available AVP values in the Diameter SAR
message, and SHOULD include in the SIP-User-Data AVP value of the
Diameter SAA message the relevant portion of the user profile
associated to the SIP-Public-User-Identity AVP and all other SIP
identities associated to that AVP. Additionally, the Diameter
server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in
the Diameter SAA message. The Diameter server considers the SIP
public identity authenticated and registered.
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
message is set to UNREGISTERED_USER then the Diameter server MUST
store the SIP server address included in the SIP-Server-Name AVP
value. The Diameter server will return the SIP server address in
Diameter Location-Info-Answer (LIA) messages. The Diameter server
SHOULD analyze the requested type of data in the
SIP-User-Data-Request-Type and SIP-User-Data-Already-Available AVP
values in the Diameter SAR message. The Diameter server SHOULD
include the relevant portion of the user profile data associated
to the SIP or SIPS URI (SIP-Public-User-Identity AVP) and
associated identities in the SIP-User-Data AVP value of the
Diameter SAA message. The Diameter server MUST set the Result-Code
AVP value to DIAMETER_SUCCESS. The Diameter server considers the
SIP public identity UNREGISTERED, but with a SIP server allocated
to trigger and provide services for unregistered users. Note that
in case of UNREGISTERED_USER (SIP-Server-Assignment-Type AVP), the
Diameter server MUST verify that there is only one
SIP-Public-User-Identity AVP. Otherwise, the Diameter server MUST
answer the Diameter SAR message with a Diameter SAA message, it
MUST set the Result-Code AVP value to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any
SIP-User-Data AVP.
If the User-Name AVP was not present in the Diameter SAR message
and the SIP-Public-User-Identity is not known for the Diameter
server, the Diameter server MUST NOT include a User-Name AVP in
the Diameter SAA message and MUST set the Result-Code AVP value to
DIAMETER_ERROR_USER_UNKNOWN.
Garcia-Martin, et al. Expires December 15, 2003 [Page 20]
Internet-Draft Diameter Multimedia application June 2003
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION,
DEREGISTRATION_TOO_MUCH_DATA or ADMINISTRATIVE_DEREGISTRATION the
Diameter server MUST clear the SIP server address associated to
all SIP Public user identities indicated in each of the
SIP-Public-User-Identity AVP values included in the Diameter SAR
message. The Diameter server considers all these SIP Public user
identities as not registered. The Diameter server MUST set the
Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
message.
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or
USER_DEREGISTRATION_STORE_SERVER_NAME the Diameter server has the
possibility to keep the SIP server address associated to the SIP
Public user identities included in the SIP-Public-User-Identity
AVP values of the Diameter SAR message, in spite that the SIP
Public user identities will become unregistered. This feature
allows a SIP server to request the Diameter server to remain as an
assigned SIP server for those SIP public user identities
(SIP-Public-User-Identity AVP values), and avoid SIP server
assignment. The Diameter server MUST consider all these SIP Public
user identities as not registered. If the Diameter server honors
the request of the Diameter client (SIP server) to remain as an
allocated SIP server, then the Diameter server MUST keep the SIP
server assigned to those SIP public user identities and MUST set
the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
message. Otherwise, when the Diameter server does not honor the
request of the Diameter client (SIP server) to remain as an
allocated SIP server, the Diameter server MUST clear the SIP
server name assigned to those SIP Public user identities and it
MUST set the Result-Code AVP value to
DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter SAA
message.
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
message is set to NO_ASSIGNMENT, the Diameter server SHOULD first
verify that the SIP-Server-Name AVP value in the Diameter SAR
message is the same SIP server address as is assigned to the
SIP-Public-User-Identity AVP value. If they differ, then the
Diameter server MUST set the Result-Code AVP value to
DIAMETER_UNABLE_TO_COMPLY in the Diameter SAA message. Otherwise,
the Diameter server SHOULD analyze the requested type of data in
the SIP-User-Data-Request-Type AVP value in the Diameter SAR
message, and SHOULD include the requested user profile in the
SIP-User-Data AVP value of the Diameter SAA message.
o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
Garcia-Martin, et al. Expires December 15, 2003 [Page 21]
Internet-Draft Diameter Multimedia application June 2003
message is set to AUTHENTICATION_FAILURE or
AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there
is only SIP-Public-User-Identity AVP in the Diameter SAR message.
If the number of the SIP-Public-User-Identity AVP is not exactly
one, the Diameter server MUST set the Result-Code AVP value to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message,
and SHOULD not take further actions. If there is exactly one
SIP-Public-User-Identity AVP in the Diameter SAR message, the
Diameter server MUST clear the address of the SIP server assigned
to the Public user identity, and the Diameter server MUST set the
Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
message. The Diameter server MUST consider the SIP Public user
identity as not registered.
Message Format
<SAA> ::= < Diameter Header: bbb, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ SIP-User-Data ]
[ SIP-Charging-Information ]
[ User-Name ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.5 Location-Info-Request (LIR) Command
The Location-Info-Request (LIR) is indicated by the Command-Code set
to ccc and the Command Flags' 'R' bit set. The Diameter client in a
SIP server sends this command to the Diameter server to request the
URI of the SIP server assigned to a particular user. The user is
identified by the SIP-Public-User-Identity AVP value.
Message Format
<LIR> ::= < Diameter Header: ccc, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
Garcia-Martin, et al. Expires December 15, 2003 [Page 22]
Internet-Draft Diameter Multimedia application June 2003
[ Destination-Host ]
{ Destination-Realm }
{ SIP-Public-User-Identity }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.6 Location-Info-Answer (LIA) Command
The Location-Info-Answer (LIA) is indicated by the Command-Code set
to ccc and the Command Flags' 'R' bit cleared. The Diameter server
sends this command in response to a previously received Diameter
Location-Info-Request (LIR) command.
In addition to the values already defined in the Diameter base
protocol [2], the Result-Code AVP may contain one of the values
defined in Section 6.1. When the Diameter server finds an error in
processing the Diameter LIR message, the Diameter server MUST stop
the process of the message and answer with a Diameter LIA message
that includes the appropriate error code in the Result-Code AVP
value. When there is no error, the Diameter server MUST set the
Result-Code AVP value to DIAMETER_SUCCESS in the Diameter LIA
message.
One of the errors that the Diameter server may find is that the
SIP-Public-User-Identity AVP value is not a valid user in the realm.
In such case, the Diameter server MUST set the Result-Code AVP value
to DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA
message.
If the Diameter server cannot process the Diameter SAR command, e.g.,
due to a database error, the Diameter server MUST set the Result-Code
AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter
LIA message. The Diameter server MUST NOT include any SIP-Server-Name
or SIP-Server-Capabilities AVP in the Diameter LIA message.
The Diameter server can or cannot be aware of a SIP server assigned
to the user contained in the SIP-Public-User-Identity AVP value in
the Diameter LIR message. If the Diameter server is aware of a SIP
server allocated to that particular user, the Diameter server MUST
include the URI of such SIP server in the SIP-Server-Name AVP and
return it in a Diameter LIA message. This is typically the situation
when the user is either registered, or unregistered but there is a
SIP server still assigned to the user.
When the Diameter server is not aware of a SIP server allocated to
the user, typically the case when the user unregistered, the
Garcia-Martin, et al. Expires December 15, 2003 [Page 23]
Internet-Draft Diameter Multimedia application June 2003
Result-Code AVP value in the Diameter LIA message depends on whether
the Diameter server is aware that the user has services defined for
unregistered users or not:
o Those users who have services defined for unregistered users may
require the allocation of a SIP server where to trigger and
perhaps execute those services. Therefore, when the Diameter
server is not aware of an assigned SIP server, but the user has
services defined for unregistered users, the Diameter server MUST
set the Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and
return it in a Diameter LIA message. The Diameter server MAY also
include a SIP-Server-Capabilities AVP to facilitate the SIP server
(Diameter client) the selection of an appropriate SIP server with
the required capabilities. Absence of the SIP-Server-Capabilities
AVP will indicate the SIP server (Diameter client) that any SIP
server is suitable to be allocated to the user.
o Those users who do not have service defined for unregistered users
do not require further processing. The Diameter server MUST set
the Result-Code AVP value to
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the
Diameter client in a Diameter LIA message. The SIP server
(Diameter client) may return the appropriate SIP response (e.g.,
480 Temporarily unavailable) to the original SIP request.
Message Format
<LIA> ::= < Diameter Header: ccc, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-Name ]
[ SIP-Server-Capabilities ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.7 Multimedia-Auth-Request (MAR) Command
The Multimedia-Auth-Request (MAR) command is indicated by the
Command-Code set to ddd and the Command Flags' 'R' bit set. The
Diameter client in a SIP server sends this command to the Diameter
Garcia-Martin, et al. Expires December 15, 2003 [Page 24]
Internet-Draft Diameter Multimedia application June 2003
server to request the Diameter server the authentication of a user.
Message Format
<MAR> ::= < Diameter Header: ddd, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
{ User-Name }
{ SIP-Public-User-Identity }
{ SIP-Server-Name }
[ SIP-Number-Auth-Items ]
[ SIP-Auth-Data-Item ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.8 Multimedia-Auth-Answer (MAA) Command
The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set
to ddd and the Command Flags' 'R' bit cleared. The Diameter server
sends this command in response to a previously received Diameter
Multimedia-Auth-Request (MAR) command.
In addition to the values already defined in the Diameter base
protocol [2], the Result-Code AVP may contain one of the values
defined in Section 6.1.
At reception of the Diameter MAR message, the Diameter server MUST
verify the existence of the user in the realm, i.e., the User-Name
AVP value is a valid user within that realm. If the Diameter server
does not recognize the user name received in the User-Name AVP, the
Diameter server MUST build a Diameter Multimedia-Auth-Answer (MAA)
message and MUST set the Result-Code AVP to
DIAMETER_ERROR_USER_UNKNOWN.
Then Diameter server MUST authorize that User-Name AVP value is able
to use the URI included in the SIP-Public-User-Identity AVP. If this
authorization fails, the Diameter server must set the Result-Code AVP
to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
Multimedia-Auth-Answer (MAA) message.
Then Diameter server MUST verify whether the authentication scheme
(SIP-Authentication-Scheme AVP value) indicated in the grouped
Garcia-Martin, et al. Expires December 15, 2003 [Page 25]
Internet-Draft Diameter Multimedia application June 2003
SIP-Auth-Data-Item AVP is supported or not. If that authentication
scheme is not supported, then the Diameter server MUST set the
Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send
it in a Diameter Multimedia-Auth-Answer (MAA) message.
If the received Diameter MAR message contains a SIP-Authorization AVP
within the grouped SIP-Auth-Data-Item AVP, the Diameter server
considers that the authorization information is being requested after
a synchronization failure. In this case, the sequence of the
SIP-Auth-Data-Item AVPs would take into account the SIP-Authorization
AVP value to synchronize the vectors. The Diameter server MUST set
the Result-Code AVP to DIAMETER_SUCCESS.
If the SIP-Auth-Data-Items AVP is present in the Diameter MAR
message, it will indicate the number of authentication data items
that the Diameter client is requesting. It is RECOMMENDED that he
Diameter server, when building the Diameter MAA message, includes a
number of SIP-Auth-Data-Item AVPs that is less than or equal to the
number of authentication data items requested by the Diameter client
in the SIP-Auth-Data-Items AVP value of the Diameter MAR message.
The Diameter server MUST compare the stored SIP server assigned to
the public user identity with the SIP-Server-Name AVP value received
in the Diameter MAR message. If there is not a match, the Diameter
server MUST update the stored SIP server assigned to the public user
identity, and MUST set an "authentication pending" flag for the
public user identity. If there is a match, the Diameter server shall
clear the "authentication pending" flag for the public user identity.
At any case, if there is a success in processing the Diameter MAR
command, the Diameter server must set the Result-Code AVP value to
DIAMETER_SUCCESS and return it in a Diameter MAA message. Otherwise,
the Diameter server MUST set the Result-Code AVP value to
DIAMETER_UNABLE_TO_COMPLY and it MUST NOT include any
SIP-Auth-Data-Item AVP.
Message Format
<MAA> ::= < Diameter Header: ddd, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ SIP-Public-User-Identity ]
[ SIP-Number-Auth-Items ]
* [ SIP-Auth-Data-Item ]
Garcia-Martin, et al. Expires December 15, 2003 [Page 26]
Internet-Draft Diameter Multimedia application June 2003
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.9 Registration-Termination-Request (RTR) Command
The Registration-Termination-Request (RTR) command is indicated by
the Command-Code set to eee and the Command Flags' 'R' bit set. The
Diameter server sends this command to the Diameter client in a SIP
server to inform the SIP server about the de-registration of a user.
The Diameter server has the capability to initiate the
de-registration of a user and inform the SIP server by means of the
Diameter RTR command. The Diameter server can decided whether only
one public user identity is going to be deregistered, a list of
public user identities, or all the public user identities allocated
to the user.
The absence of a SIP-Public-User-Identity AVP in the Diameter RTR
message indicates that all the public user identities allocated to
the user are being deregistered.
The Diameter server MUST include a SIP-Deregistration-Reason AVP
value to indicate the reason for the deregistration.
Message Format
<RTR> ::= < Diameter Header: eee, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ User-Name }
* [ SIP-Public-User-Identity ]
{ SIP-Deregistration-Reason }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.10 Registration-Termination-Answer (RTA) Command
The Registration-Termination-Answer (RTA) is indicated by the
Garcia-Martin, et al. Expires December 15, 2003 [Page 27]
Internet-Draft Diameter Multimedia application June 2003
Command-Code set to eee and the Command Flags' 'R' bit cleared. The
Diameter client sends this command in response to a previously
received Diameter Registration-Termination-Request (RTR) command.
In addition to the values already defined in the Diameter base
protocol [2], the Result-Code AVP may contain one of the values
defined in Section 6.1.
The SIP server (Diameter client) will apply the administrative
deregistration to each of the URIs included in each the
SIP-Public-User-Identity AVP values, or, if there is no
SIP-Public-User-Identity AVP present in the Diameter RTR request, to
all the URIs allocated to the User-Name AVP value.
The value of the SIP-Deregistration-Reason AVP in the Diameter RTR
command will have an effect on the actions performed at the SIP
server (Diameter client):
o If the value is set to PERMANENT_TERMINATION, then the user has
terminated his/her registration to the realm. The SIP server
(Diameter client), if supported through SIP procedures, SHOULD
inform the interested parties (e.g., subscribers to the
registration event) about the administrative de-registration and
SHOULD NOT request a new user registration. The SIP server SHOULD
clear the registration state of the de-registered public user
identities.
o If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter
server informs the SIP server (Diameter client) that a new SIP
server has been allocated to the user, due to some reason. The SIP
server, if supported through SIP procedures, SHOULD inform the
interested parties (e.g., subscribers to the registration event)
about the administrative de-registration at this SIP server and
SHOULD NOT request a new user registration. The SIP server SHOULD
clear the registration state of the de-registered public user
identities.
o If the value is set to SIP_SERVER_CHANGE, the Diameter server
informs the SIP server (Diameter client) that a new SIP server has
to be allocated to the user, due to e.g. user's capabilities
requiring a new SIP server, or not enough resources in the current
SIP server. The SIP server, if supported through SIP procedures,
SHOULD inform the interested parties (e.g., subscribers to the
registration event) about the administrative de-registration at
this SIP server and SHOULD request a new user registration. The
SIP server SHOULD clear the registration state of the
de-registered public user identities.
Garcia-Martin, et al. Expires December 15, 2003 [Page 28]
Internet-Draft Diameter Multimedia application June 2003
o If the value is set to REMOVE_SIP_SERVER, the Diameter server
informs the SIP server (Diameter client) that the SIP server will
no longer be bound in the Diameter server with such user. The SIP
server can delete all data related to the user.
Message Format
<RTA> ::= < Diameter Header: eee, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.11 Push-Profile-Request (PPR) Command
The Push-Profile-Request (PPR) command is indicated by the
Command-Code set to fff and the Command Flags' 'R' bit set. The
Diameter server sends this command to the Diameter client in a SIP
server to update the user profile of an already registered user in
such SIP server.
Each user has a user profile associated to him/her. The profile may
change with time, due to, e.g., addition of new services to the user.
In case the user profile changes, the Diameter server sends a
Diameter Push-Profile-Request (PPR) command to the Diameter client in
a SIP server, in order to start applying those new services.
The Diameter server sends the new user profile in the SIP-User-Data
AVP value.
Message Format
<PPR> ::= < Diameter Header: fff, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ User-Name }
Garcia-Martin, et al. Expires December 15, 2003 [Page 29]
Internet-Draft Diameter Multimedia application June 2003
{ SIP-User-Data }
* [ SIP-Public-User-Identity ]
[Authorization-Lifetime ]
[Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
OPEN ISSUE: clarify whether it is User-Name or
SIP-Public-User-Identity what is included, and if both are
present, what is the role of each.
5.12 Push-Profile-Answer (PPA) Command
The Push-Profile-Answer (PPA) is indicated by the Command-Code set to
fff and the Command Flags' 'R' bit cleared. The Diameter client sends
this command in response to a previously received Diameter
Push-Profile-Request (PPR) command.
In addition to the values already defined in the Diameter base
protocol [2], the Result-Code AVP may contain one of the values
defined in Section 6.1.
If there is no error when processing the received Diameter PPR
message, the SIP server (Diameter client) MUST download the received
user profile from the SIP-User-Data AVP value in the Diameter PPR
message and stored for all the public user identities allocated to
the User-Name AVP value.
If the SIP server does not recognize or does not support some of the
data transferred in the SIP-User-Data AVP value, the Diameter client
in the SIP server MUST return a Diameter PPA message that includes a
Result-Code AVP set to the value
DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA.
If the SIP server (Diameter client) receives a Diameter PPR message
with a User-Name AVP that is unknown, the Diameter client MUST set
the Result-Code AVP value to DIAMETER_ERROR_USER_UNKONWN and MUST
return it to the Diameter server in a Diameter PPA message.
If the SIP server (Diameter client) receives in the SIP-User-Data AVP
value more data than it can accept, it MUST set the Result-Code AVP
value to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the
Diameter server in a Diameter PPA message. The SIP server MUST NOT
overrided the existing user profile with the received in the PPR
message.
Garcia-Martin, et al. Expires December 15, 2003 [Page 30]
Internet-Draft Diameter Multimedia application June 2003
If the Diameter server receives the Result-Code AVP value set to
DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD
force a new re-registration of the user by sending to the Diameter
client a Diameter Registration-Termination-Request (RTR) with the
SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This
will force a re-registration of the user, and will trigger a
selection of a new SIP server.
OPEN ISSUE: How to avoid that the same SIP server is chosen again,
and we enter a loop.
If the Diameter client is not able to honor the command, for any
other reason, it MUST set the Result-Code AVP value to
DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA
message.
Message Format
<PPA> ::= < Diameter Header: fff, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
6. New values for existing AVPs
This section defines new values that the Diameter Multimedia
application extends to already existing AVPs.
6.1 Extension to the Result-Code AVP values
The Result-Code AVP is already defined in the base Diameter
specification [2]. In addition to the values already defined in the
base Diameter specification [2], the Diameter Multimedia application
defines the following new Result-Code AVP values:
6.1.1 Success Result-Code AVP values
A Diameter peer uses Result-Code AVP values that fall into the
success category to inform the remote peer that a request has been
successfully completed.
o DIAMETER_FIRST_REGISTRATION 2xx1
Garcia-Martin, et al. Expires December 15, 2003 [Page 31]
Internet-Draft Diameter Multimedia application June 2003
The user was not previously registered. The Diameter server has
now authorized the registration.
o DIAMETER_SUBSEQUENT_REGISTRATION 2xx2
The user is already registered. The Diameter server has now
authorized the re-registration.
o DIAMETER_UNREGISTERED_SERVICE 2xx3
The user is not currently registered, but the requested service
can still be granted to the user.
o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2xx4
The de-registration was successful. The Diameter server does not
keep a record of the SIP server assigned to the user.
o DIAMETER_SERVER_SELECTION 2xx5
The Diameter server has authorized the registration. The user has
already a SIP server assigned, but it may be necessary to select a
new SIP server for the user.
6.1.2 Permanent failures
A Diameter peer uses Result-Code AVP values that fall into the
success category to inform the remote peer that a request has been
successfully completed.
o DIAMETER_ERROR_USER_UNKNOWN 5xx1
The SIP-Public-User-Identity AVP value does not belong to a known
user in this realm.
o DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5xx2
The value in one of the SIP-Public-User-Identity AVPs is not
allocated to the user specified in the User-Name AVP.
o DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5xx3
A query for location information is received for a public identity
that has not been registered before. The user to which this
identity belongs cannot be given service in this situation.
o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5xx4
The user is not allowed to roam to the visited network.
o DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5xx5
The identity being registered has already a server assigned and
the registration status does not allow that it is overwritten.
o DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5xx6
Garcia-Martin, et al. Expires December 15, 2003 [Page 32]
Internet-Draft Diameter Multimedia application June 2003
The authentication scheme indicated in an authentication request
is not supported.
o DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5xx7
The SIP server address sent in the SIP-Server-Name AVP value of
the Diameter Server-Assignment-Request (SAR) command is the same
SIP server address that is currently assigned, but the
SIP-Server-Assignment-Type AVP is not allowed, e.g., the user is
registered and the Server-Assignment-Request indicates the
assignment for an unregistered user.
o DIAMETER_ERROR_TOO_MUCH_DATA 5xx8
The Diameter peer in the SIP server receives more data than it can
accept. The SIP server cannot overwrite the already stored data.
o DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5xx9
The SIP server informs Diameter server that the received
subscription data contained information which was not recognized
or supported.
7. Diameter Multimedia AVPs
This section defines new AVPs used in this Diameter Multimedia
application. Applications compliant to this specification MUST
implement these AVPs.
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
SIP-Visited- x01 UTF8String | | | | | N |
Network-Identifier | | | | | |
SIP-Public- x02 UTF8String | | | | | N |
User-Identity | | | | | |
SIP-Server-Name x03 UTF8String | | | | | N |
SIP-Server- x04 Grouped | | | | | N |
Capabilities | | | | | |
SIP-Mandatory- x05 Unsigned32 | | | | | N |
Capability | | | | | |
SIP-Optional- x06 Unsigned32 | | | | | N |
Capability | | | | | |
SIP-User-Data x07 OctectString | | | | | N |
SIP-Number- x08 Unsigned32 | | | | | N |
Auth-Items | | | | | |
SIP-Auth-Data- x09 Grouped | | | | | N |
Garcia-Martin, et al. Expires December 15, 2003 [Page 33]
Internet-Draft Diameter Multimedia application June 2003
Item | | | | | |
SIP- x10 Unsigned32 | | | | | N |
Item-Number | | | | | |
SIP- x11 UTF8String | | | | | N |
Authentication-Scheme | | | | | |
SIP- x12 OctetString | | | | | N |
Authenticate | | | | | |
SIP- x13 OctetString | | | | | N |
Authorization | | | | | |
SIP- x14 OctetString | | | | | N |
Authentication-Info | | | | | |
SIP- x15 OctetString | | | | | N |
Authentication-Context | | | | | |
SIP- x16 OctetString | | | | | N |
Confidentiality-Key | | | | | |
SIP-Integrity- x17 OctetString | | | | | N |
Key | | | | | |
SIP-Server- x18 Enumerated | | | | | N |
Assignment-Type | | | | | |
SIP- x19 Grouped | | | | | N |
Deregistration-Reason | | | | | |
SIP-Reason- x20 Enumerated | | | | | N |
Code | | | | | |
SIP-Reason- x21 UTF8String | | | | | N |
Info | | | | | |
SIP-Charging- x22 Grouped | M | P | | | N |
Information | | | | | |
Primary- x23 DiameterURI | M | P | | | N |
Event-Charging-Function-Name | | | | | |
Secondary- x24 DiameterURI | M | P | | | N |
Event-Charging-Function-Name | | | | | |
Primary- x25 DiameterURI | M | P | | | N |
Charging-Collection-Function-Name | | | | | |
Secondary- x26 DiameterURI | M | P | | | N |
Charging-Collection-Function-Name | | | | | |
SIP-User- x27 Enumerated | | | | | N |
Authorization-Type | | | | | |
SIP-User- x28 Enumerated | | | | | N |
Data-Request-Type | | | | | |
SIP-User- x29 Enumerated | | | | | N |
Data-Already-Available | | | | | |
Table 2: List of Diameter Multimedia AVPs
7.1 SIP-Charging-Information AVP
The SIP-Charging-Information (AVP code TBD) is of type Grouped, and
Garcia-Martin, et al. Expires December 15, 2003 [Page 34]
Internet-Draft Diameter Multimedia application June 2003
contains the addresses of the nodes that will be collecting charging
information. The Grouped Data field has the following ABNF grammar:
SIP-Charging-Information :: = < AVP Header: TBD >
[ Primary-Event-Charging-Function-Name ]
[ Secondary-Event-Charging-Function-Name ]
[ Primary-Charging-Collection-Function-Name ]
[ Secondary-Charging-Collection-Function-Name ]
* [ AVP]
7.1.1 Primary-Event-Charging-Function-Name AVP
The Primary-Event-Charging-Function-Name AVP (AVP Code TBD) is of
type DiameterURI. This AVP contains the address of the Primary Event
Charging Function, i.e., the main node that is able to receive event
(e.g., non-session) related charging information.
7.1.2 Secondary-Event-Charging-Function-Name AVP
The Secondary-Event-Charging-Function-Name AVP (AVP Code TBD) is of
type DiameterURI. This AVP contains the address of the Secondary
Event Charging Function, i.e., the backup node that is able to
receive event (e.g., non-session) related charging information.
7.1.3 Primary-Charging-Collection-Function-Name AVP
The Primary-Charging-Collection-Function-Name AVP (AVP Code TBD) is
of type DiameterURI. This AVP contains the address of the Primary
Charging Collection Function, i.e., the main node that is able to
receive session related charging information.
7.1.4 Secondary-Charging-Collection-Function-Name AVP
The Secondary-Charging-Collection-Function-Name AVP (AVP Code TBD) is
of type DiameterURI. This AVP contains the address of the Secondary
Event Charging Function, i.e., the backup node that is able to
receive session related charging information.
7.2 SIP-Server-Name AVP
The SIP-Server-Name AVP (AVP Code TBD) is of type UTF8String. This
AVP contains a SIP or SIPS URI (as defined in RFC 3261 [6]) that
identifies a SIP server.
7.3 SIP-Server-Capabilities AVP
The SIP-Server-Capabilities AVP (AVP Code TBD) is of type Grouped.
Garcia-Martin, et al. Expires December 15, 2003 [Page 35]
Internet-Draft Diameter Multimedia application June 2003
The Diameter indicates in this AVP the requirements for a particular
SIP capability, so that the Diameter client (SIP server) is able to
select another appropriate SIP server to serve the user.
SIP-Server-Capability ::= < AVP Header: TBD >
* [ SIP-Mandatory-Capability ]
* [ SIP-Optional-Capability ]
* [ SIP-Server-Name ]
* [ AVP ]
7.3.1 SIP-Mandatory-Capability AVP
The SIP-Mandatory-Capability AVP (AVP Code TBD) is of type
Unsigned32. The value represents a certain capability (or set of
capabilities) that the SIP server to be allocated to the user has to
fulfil.
The semantics of the different values are not standardized, as it is
a matter of the administrative network to allocate its own semantics
within its own network. Each value has to represent a single
capability within the administrative network.
7.3.2 SIP-Optional-Capability AVP
The SIP-Optional-Capability AVP (AVP Code TBD) is of type Unsigned32.
The value represents a certain capability (or set of capabilities)
that the SIP server to be allocated may, optionally, fulfill.
The semantics of the different values are not standardized, as it is
a matter of the administrative network to allocate its own semantics
within its own network. Each value has to represent a single
capability within the administrative network.
7.4 SIP-Server-Assignment-Type AVP
The SIP-Server-Assignment-Type AVP (AVP code TBD) is of type
Enumerated, and indicates the type of server update being performed
in a Diameter Server-Assignment-Request (SAR) operation. The
following values are defined:
o NO_ASSIGNMENT (0)
The Diameter client uses this value to request the user profile of
a public identity, without affecting the registration state of
such identity.
o REGISTRATION (1)
First SIP registration of a public user identity.
Garcia-Martin, et al. Expires December 15, 2003 [Page 36]
Internet-Draft Diameter Multimedia application June 2003
o RE_REGISTRATION (2)
Subsequent SIP registration of a public user identity.
o UNREGISTERED_USER (3)
The SIP server has received a SIP request (e.g., SIP INVITE)
addressed for a public user identity that is not registered.
o TIMEOUT_DEREGISTRATION (4)
The SIP registration timer of an identity has expired.
o USER_DEREGISTRATION (5)
The SIP server has received a request to de-register a public user
identity.
o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6)
The SIP registration timer of an identity has expired. The SIP
server keeps the user data stored and requests the Diameter server
to store the SIP server address.
o USER_DEREGISTRATION_STORE_SERVER_NAME (7)
The SIP server has received a user initiated de-registration
request. The SIP server keeps the user data stored and requests
the Diameter server to store the SIP server address.
o ADMINISTRATIVE_DEREGISTRATION (8)
The SIP server, due to administrative reasons, has de-registered a
public user identity.
o AUTHENTICATION_FAILURE (9)
The authentication of a user has failed.
o AUTHENTICATION_TIMEOUT (10)
The authentication timer has expired.
o DEREGISTRATION_TOO_MUCH_DATA (11)
The SIP server has requested user profile information from the
Diameter server and has received a volume of data higher than it
can accept.
7.5 SIP-Auth-Data-Item AVP
The SIP-Auth-Data-Item (AVP code TDB) is of type Grouped, and
contains the authentication and/or authorization information
pertaining to a user.
SIP-Auth-Data-Item :: = < AVP Header: TBD >
[ SIP-Item-Number ]
Garcia-Martin, et al. Expires December 15, 2003 [Page 37]
Internet-Draft Diameter Multimedia application June 2003
[ SIP-Authentication-Scheme ]
[ SIP-Authenticate ]
[ SIP-Authorization ]
[ SIP-Authentication-Info ]
[ SIP-Authentication-Context ]
[ SIP-Confidentiality-Key ]
[ SIP-Integrity-Key ]
* [ NAS-Session-Key ]
* [ AVP ]
7.5.1 SIP-Item-Number AVP
The SIP-Item-Number (AVP code TDB) is of type Unsigned32, and is
included in a SIP-Auth-Data-Item grouped AVP in circumstances where
there are multiple occurrences of SIP-Auth-Data-Item AVPs and the
order of processing is relevant. The AVP indicates the order in
which the Grouped SIP-Auth-Data-Item should be processed. Lower
values of the SIP-Item-Number AVP indicate that the whole
SIP-Auth-Data-Item SHOULD be processed before other
SIP-Auth-Data-Item AVP that contain a higher value number in the
SIP-Item-Number AVP.
7.5.2 SIP-Authentication-Scheme AVP
The SIP-Authentication-Scheme AVP (AVP code TBD) is of type
UTF8String and indicates the authentication scheme used in the
authentication of SIP services. The currently defined value is
"Digest", to indicate HTTP Digest authentication as defined in RFC
2617 [4].
NOTE: Although RFC 2617 [4]defines the Basic and Digest schemes
for authenticating HTTP requests, RFC 3261 [6] has imported only
HTTP Digest for SIP purposes.
7.5.3 SIP-Authenticate AVP
The SIP-Authenticate AVP (AVP code TBD) is of type UTF8String and
contains the directive of the WWW-Authenticate or Proxy-Authenticate
SIP header field values, if present, in a SIP response.
OPEN ISSUE: need to replace the "data portion" term. That term
does not exist in SIP. Probably the term refers to the "header
field value". An example will also help the reader to understand
what is contained in this AVP.
Garcia-Martin, et al. Expires December 15, 2003 [Page 38]
Internet-Draft Diameter Multimedia application June 2003
7.5.4 SIP-Authorization AVP
The SIP-Authorization AVP (AVP code TBD) is of type UTF8String and
contains the data portion of the Authorization or Proxy-Authorization
SIP headers if present in a SIP request.
OPEN ISSUE: need to replace the "data portion" term. That term
does not exist in SIP. Probably the term refers to the "header
field value". An example will also help the reader to understand
what is contained in this AVP.
7.5.5 SIP-Authentication-Info AVP
The SIP-Authentication-Info AVP (AVP Code TBD) is of type OctetString
and contains additional authentication information that the Diameter
server sends if the authentication scheme is Digest authentication.
It follows the format defined in RFC 2617 [4], section 3.2.3, for the
Authentication-Info Header.
The contents of this AVP are mapped to the SIP Authentication-Info
header.
OPEN ISSUE: Referring to RFC 2617 is a very loose definition .
Need to pinpoint what are the exact contents of the AVP, probably
the "header field value". An example will also help the reader to
understand what is contained in this AVP.
OPEN ISSUE: it seems a bit strange that this AVP is of type
OctetString whereas the previous ones, which are similar in
contents, are of type UTF8String. In my opinion, this AVP should
be of type UTF8String.
7.5.6 SIP-Authentication-Context AVP
The SIP-Authentication-Context AVP (AVP code TBD) is of type
OctectString, and contains authentication-related information
relevant for performing the authentication but that is not part of
the SIP authentication headers.
Some authentication schemes, such us PGP [3], HTTP Digest with
quality of protection set to auth-int [4] or HTTP Digest with
predictive nonces [4], request that part of the SIP request is
evaluated by the node performing authentication. In such cases the
SIP-Authentication-Context AVP contains such data. Note that the
actual contents of the AVP are depending on the authentication
scheme.
Garcia-Martin, et al. Expires December 15, 2003 [Page 39]
Internet-Draft Diameter Multimedia application June 2003
7.6 SIP-Number-Auth-Items AVP
The SIP-Number-Auth-Items AVP (AVP Code TBD) is of type Unsigned32
and indicates the number of authentication and/or authorization
vectors that the Diameter server included in a Diameter message.
When the AVP is present in a request, it indicates the number of
SIP-Auth-Data-Items the Diameter client is requesting. This can be
used, for instance, when the SIP server is requesting several
pre-calculated authentication vectors. In the answer message, the
SIP-Number-Auth-Items AVP indicates the actual number of items that
the Diameter server included.
7.7 SIP-Deregistration-Reason AVP
The SIP-Deregistration-Reason AVP (AVP Code TBD) is of type Grouped,
and indicates the reason for a deregistration operation.
SIP-Deregistration-Reason::= < AVP Header: TBD >
{ SIP-Reason-Code }
[ SIP-Reason-Info ]
* [ AVP ]
7.7.1 SIP-Reason-Code AVP
The SIP-Reason-Code AVP (AVP code TBD) is of type Enumerated, and
defines the reason for the network initiated de-registration. The
following values are defined:
o PERMANENT_TERMINATION (0)
o NEW_SIP_SERVER_ASSIGNED (1)
o SIP_SERVER_CHANGE (2)
o REMOVE_SIP_SERVER (3)
7.7.2 SIP-Reason-Info AVP
The SIP-Reason-Info AVP (AVP code TBD) is of type UTF8String, and
contains textual information that can be rendered to the user, about
the reason for a de-registration.
7.8 SIP-Public-User-Identity AVP
The SIP-Public-User-Identity AVP (AVP Code TBD) is of type
Garcia-Martin, et al. Expires December 15, 2003 [Page 40]
Internet-Draft Diameter Multimedia application June 2003
UTF8String. The syntax of this AVP corresponds either to a SIP URI
(with the format defined in RFC 3261 [6]>) or a TEL URL (with the
format defined in RFC 2806 [5]).
The Diameter client (SIP server) uses the value found in a SIP
Request-URI or a header field value of the SIP request to construct
the SIP-Public-User-Identity AVP. The selection of a Request-URI or a
particular header field depends on the semantics of the SIP message
and whether the SIP server is acting for originating or terminating
requests. For instance, when the SIP server receives an INVITE
request addressed to the served user, it maps the SIP Request-URI of
the SIP request to this AVP. However, when the SIP server receives an
INVITE request originated by the served user, it can map either the
P-Asserted-Identity or the From header field values to this AVP.
7.9 SIP-Visited-Network-Identifier AVP
The SIP-Visited-Network-Identifier AVP (AVP Code TBD) is of type
OctetString. This AVP contains an identifier that helps the home
network to identify the visited network (e.g. the visited network
domain name), in order to authorize roaming to such visited network.
7.10 SIP-User-Authorization-Type AVP
The SIP-User-Authorization-Type AVP (AVP code TBD) is of type
Enumerated, and indicates the type of user authorization being
performed in a User Authorization operation, i.e., The Diameter
User-Authorization-Request (UAR) command. The following values are
defined:
o REGISTRATION (0)
This value is used in case of the initial registration or
re-registration.
This is the default value.
o DE_REGISTRATION (1)
This value is used in case of the de-registration.
o REGISTRATION_AND_CAPABILITIES (2)
This value is used in case of initial registration or
re-registration when the SIP server explicitly requests the
Diameter server to get capability information. This capability
information will help the SIP server to allocate another SIP
server to serve the user.
Garcia-Martin, et al. Expires December 15, 2003 [Page 41]
Internet-Draft Diameter Multimedia application June 2003
7.11 SIP-User-Data AVP
The SIP-User-Data AVP (AVP Code TBD) is of type OctetString. The
Diameter peers do not need to understand the value of this AVP.
Th AVP contains the user profile data required for a SIP server to
give service to the user.
7.12 SIP-User-Data-Already-Available AVP
The SIP-User-Data-Already-Available AVP (AVP code TBD) is of type
Enumerated, and gives an indication to the Diameter server about
whether the Diameter client (SIP server) already got the portion of
the user profile that it needs to serve the user. The following
values are defined:
o USER_DATA_NOT_AVAILABLE (0)
The Diameter client (SIP server) does not have the data that it
needs to serve the user.
o USER_DATA_ALREADY_AVAILABLE (1)
The Diameter client (SIP server) already has got the data that it
needs to serve the user.
7.13 SIP-User-Data-Request-Type AVP
The SIP-User-Data-Request-Type AVP (AVP code TBD) is of type
Enumerated, and indicates the portion of the user profile that the
Diameter client (SIP server) is requesting to the Diameter server.
The following values are defined:
o COMPLETE_PROFILE (0)
The Diameter client (SIP server) requests the complete user
profile corresponding to one or more public user identities.
o REGISTERED_PROFILE (1)
The Diameter client (SIP server) requests the portion of the user
profile that deals with registered states of one or more public
user identities.
o UNREGISTERED_PROFILE (2)
The Diameter client (SIP server) request the portion of the user
profile that deals with unregistered states of one or more public
user identities.
Garcia-Martin, et al. Expires December 15, 2003 [Page 42]
Internet-Draft Diameter Multimedia application June 2003
7.14 SIP-Confidentiality-Key AVP
The SIP-Confidentiality-Key (AVP code TBD) is of type OctetString,
and contains the Confidentiality Key (CK).
7.15 SIP-Integrity-Key AVP
The SIP-Integrity-Key (AVP code TBD) is of type OctetString, and
contains the Integrity Key (IK).
8. Authentication Details
Authenticating a user can occur through various mechanisms (HTTP
Digest authentication have currently been described), with the actual
authentication being performed in either the SIP server or the
Diameter server. The choice of the server will determine the AVPs to
be utilized in the SIP-Auth-Data-Item grouped AVP, as well as a few
AVPs in the Diameter MAR/MAA commands.
If the SIP server performs the authentication of a user, the Diameter
MAR message that the Diameter client in the SIP server sends to the
Diameter server will include the SIP-User-Name and
SIP-Public-User-Identity AVPs as necessary, as well as a
SIP-Number-Auth-Items AVP to indicate how many authentication vectors
(the actual contents of the vector are dependent upon the
authentication method) are being requested. In the Diameter MAA
message, the Diameter server SHOULD indicate how many
SIP-Auth-Data-Item AVPs are present with the SIP-Number-Auth-Items
AVP. This number may be different from the one requested in the
Diameter MAR message. If multiple SIP-Auth-Data-Item AVPs are
present, and their ordering is significant, the Diameter server MUST
include a SIP-Item-Number AVP in each grouping to indicate the order.
The SIP-Authentication-Scheme and SIP-Authenticate AVPs will contain
data (typically a challenge of some kind) that the user can use to
authenticate itself. The SIP-Authorization AVP will contain the
response which is expected from the user. In order to support some
auth methods which combine key distribution with authentication,
SIP-Confidentiality-Key and SIP-Integrity-Key AVPs are included.
If the Diameter server performs the authentication of the user, the
Diameter MAR message that the Diameter client in the SIP server sends
to the Diameter server will include a single SIP-Auth-Data-Item AVP.
The SIP-Authentication-Scheme and SIP-Authorization AVPs will contain
the relevant parameters from the SIP message, if present. If
necessary, the SIP-Authentication-Context AVP will contain any
additional information needed to perform the authentication. If the
authentication is successful, the Diameter MAA message will contain a
Result-Code AVP indicating success, and if necessary, the
Garcia-Martin, et al. Expires December 15, 2003 [Page 43]
Internet-Draft Diameter Multimedia application June 2003
SIP-Auth-Data-Item AVP may be included to carry session keys back to
the SIP server. If the authentication is unsuccessful due to missing
credentials, the Diameter MAA message will include an
SIP-Auth-Data-Item with the SIP-Authentication-Scheme and
SIP-Authenticate AVPs containing data (typically a challenge of some
kind) that the user can use to authenticate itself.
9. IANA Considerations
The Application-Id for the multimedia application has to be assigned
by IANA.
Command Code values are assigned by IANA according to the Provisional
Diameter Command Codes for 3GPP.
The Diameter multimedia application will make use of the values
300-305.
OPEN ISSUE: This section requires a substantial rework and
clarifications.
10. Acknowledgements
The authors would like to thank Tony Johansson and Kevin Purser for
their invaluable contribution to the start up of this application and
the continuous progress.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Calhoun, P., "Diameter Base Protocol",
draft-ietf-aaa-diameter-17 (work in progress), January 2003.
Informational References
[3] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
Garcia-Martin, et al. Expires December 15, 2003 [Page 44]
Internet-Draft Diameter Multimedia application June 2003
[6] 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.
[7] Perkins, C., Calhoun, P. and T. Johansson, "Diameter Mobile
IPv4 Application", draft-ietf-aaa-diameter-mobileip-14 (work in
progress), April 2003.
[8] Zorn, G., Calhoun, P., Mitton, D. and D. Spence, "Diameter
Network Access Server Application",
draft-ietf-aaa-diameter-nasreq-11 (work in progress), February
2003.
[9] 3GPP, "TS 23.003 Numbering, addressing and identification
(Release 5)", September 2002, <ftp://ftp.3gpp.org/Specs/
archive/23_series/23.003/>.
[10] 3GPP, "TS 23.060:General Packet Radio Service (GRPS); Service
Description; Stage 2", September 2002, <ftp://ftp.3gpp.org/
Specs/archive/23_series/23.060/>.
[11] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) -
Release 5", September 2002, <ftp://ftp.3gpp.org/Specs/archive/
23_series/23.228/>.
[12] 3GPP, "TS 24.228: Signaling flows for the IP Multimedia call
control based on SIP and SDP", September 2002, <ftp://
ftp.3gpp.org/Specs/archive/24_series/24.228/>.
[13] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) -
Release 5", September 2002, <ftp://ftp.3gpp.org/Specs/archive/
24_series/24.229/>.
[14] 3GPP, "TS 32.225: Telecommunication Management; Charging
Management; Charging Data Description for IP Multimedia
Subsystem; (Release 5)", September 2002, <ftp://ftp.3gpp.org/
Specs/archive/32_series/32.225/>.
[15] 3GPP, "TS 32.203: 3G Security; Access security for IP based
services; (Release 5)", September 2002, <ftp://ftp.3gpp.org/
Specs/archive/33_series/33.203/>.
[17] ITU-T, "Recommendation E.164 (05/97): The international public
telecommunication numbering plan", May 1997, <http://
www.itu.int/rec/
recommendation.asp?type=folders&lang=e&parent=T-REC-E.164>.
Garcia-Martin, et al. Expires December 15, 2003 [Page 45]
Internet-Draft Diameter Multimedia application June 2003
Authors' Addresses
Miguel A. Garcia Martin (editor)
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: miguel.a.garcia@ericsson.com
Maria-Carmen Belinchon
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 3535
EMail: maria.c.belinchon@ericsson.com
Miguel A. Pallares-Lopez
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 4222
EMail: miguel.pallares@ericsson.com
Carolina Canales-Valenzuela
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 2680
EMail: carolina.canales-valenzuela@ece.ericsson.se
Garcia-Martin, et al. Expires December 15, 2003 [Page 46]
Internet-Draft Diameter Multimedia application June 2003
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566-7050
US
Phone: +1 630 713 9359
EMail: mccap@lucent.com
Jaakko Rajaniemi
Nokia Networks
P.O.Box 301
Nokia Group 00045
Finland
Phone: +358 50 3391387
EMail: jaakko.rajaniemi@nokia.com
Kalle Tammi
Nokia Networks
P.O.Box 301
Nokia Group 00045
Finland
EMail: kalle.tammi@nokia.com
Garcia-Martin, et al. Expires December 15, 2003 [Page 47]
Internet-Draft Diameter Multimedia application June 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Garcia-Martin, et al. Expires December 15, 2003 [Page 48]
Internet-Draft Diameter Multimedia application June 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Garcia-Martin, et al. Expires December 15, 2003 [Page 49]