AAA Working Group M. Garcia-Martin, Ed.
Internet-Draft Nokia
Expires: October 1, 2004 M. Belinchon
M. Pallares-Lopez
C. Canales
Ericsson
K. Tammi
Nokia
April 2, 2004
Diameter Session Initiation Protocol (SIP) Application
draft-ietf-aaa-diameter-sip-app-02
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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 October 1, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document specifies the Diameter Session Initiation Protocol
(SIP) 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
Garcia-Martin, et al. Expires October 1, 2004 [Page 1]
Internet-Draft Diameter SIP application April 2004
client in a SIP server with 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 . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
5. Overview of operation . . . . . . . . . . . . . . . . . . 7
5.1 General architecture . . . . . . . . . . . . . . . . . . . 7
5.2 Diameter server authenticates the user . . . . . . . . . . 9
5.3 Diameter server delegates authentication to the SIP
server . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4 SIP server authenticates a request . . . . . . . . . . . . 14
5.5 Session attempt . . . . . . . . . . . . . . . . . . . . . 15
5.6 Update of the user profile . . . . . . . . . . . . . . . . 16
5.7 Registration termination . . . . . . . . . . . . . . . . . 17
5.8 Diameter server discovery . . . . . . . . . . . . . . . . 18
6. Advertising Application Support . . . . . . . . . . . . . 20
7. Diameter SIP application Command Codes . . . . . . . . . . 20
7.1 User-Authorization-Request (UAR) Command . . . . . . . . . 21
7.2 User-Authorization-Answer (UAA) Command . . . . . . . . . 22
7.3 Server-Assignment-Request (SAR) Command . . . . . . . . . 25
7.4 Server-Assignment-Answer (SAA) Command . . . . . . . . . . 27
7.5 Location-Info-Request (LIR) Command . . . . . . . . . . . 31
7.6 Location-Info-Answer (LIA) Command . . . . . . . . . . . . 31
7.7 Multimedia-Auth-Request (MAR) Command . . . . . . . . . . 33
7.8 Multimedia-Auth-Answer (MAA) Command . . . . . . . . . . . 34
7.9 Registration-Termination-Request (RTR) Command . . . . . . 37
7.10 Registration-Termination-Answer (RTA) Command . . . . . . 38
7.11 Push-Profile-Request (PPR) Command . . . . . . . . . . . . 40
7.12 Push-Profile-Answer (PPA) Command . . . . . . . . . . . . 40
8. Diameter SIP application AVPs . . . . . . . . . . . . . . 42
8.1 SIP-Accounting-Information AVP . . . . . . . . . . . . . . 45
8.1.1 SIP-Accounting-Server-URI AVP . . . . . . . . . . . . . . 45
8.1.2 SIP-Credit-Control-Server-URI AVP . . . . . . . . . . . . 45
8.2 SIP-Server-URI AVP . . . . . . . . . . . . . . . . . . . . 45
8.3 SIP-Server-Capabilities AVP . . . . . . . . . . . . . . . 45
8.3.1 SIP-Mandatory-Capability AVP . . . . . . . . . . . . . . . 46
8.3.2 SIP-Optional-Capability AVP . . . . . . . . . . . . . . . 46
8.4 SIP-Server-Assignment-Type AVP . . . . . . . . . . . . . . 46
8.5 SIP-Auth-Data-Item AVP . . . . . . . . . . . . . . . . . . 47
8.5.1 SIP-Authentication-Scheme AVP . . . . . . . . . . . . . . 47
8.5.2 SIP-Item-Number AVP . . . . . . . . . . . . . . . . . . . 48
Garcia-Martin, et al. Expires October 1, 2004 [Page 2]
Internet-Draft Diameter SIP application April 2004
8.5.3 SIP-Authenticate AVP . . . . . . . . . . . . . . . . . . . 48
8.5.4 SIP-Authorization AVP . . . . . . . . . . . . . . . . . . 48
8.5.5 SIP-Authentication-Info AVP . . . . . . . . . . . . . . . 49
8.5.6 SIP-Authentication-Context AVP . . . . . . . . . . . . . . 49
8.5.7 Digest-Realm AVP . . . . . . . . . . . . . . . . . . . . . 50
8.5.8 Digest-Domain AVP . . . . . . . . . . . . . . . . . . . . 50
8.5.9 Digest-Nonce AVP . . . . . . . . . . . . . . . . . . . . . 50
8.5.10 Digest-Opaque AVP . . . . . . . . . . . . . . . . . . . . 51
8.5.11 Digest-Stale AVP . . . . . . . . . . . . . . . . . . . . . 51
8.5.12 Digest-Algorithm AVP . . . . . . . . . . . . . . . . . . . 51
8.5.13 Digest-Qop AVP . . . . . . . . . . . . . . . . . . . . . . 51
8.5.14 Digest-Auth-Param AVP . . . . . . . . . . . . . . . . . . 51
8.5.15 Digest-Username AVP . . . . . . . . . . . . . . . . . . . 52
8.5.16 Digest-Digest-URI AVP . . . . . . . . . . . . . . . . . . 52
8.5.17 Digest-Response AVP . . . . . . . . . . . . . . . . . . . 52
8.5.18 Digest-Cnonce AVP . . . . . . . . . . . . . . . . . . . . 52
8.5.19 Digest-Nonce-Count AVP . . . . . . . . . . . . . . . . . . 52
8.5.20 Digest-Nextnonce AVP . . . . . . . . . . . . . . . . . . . 53
8.5.21 Digest-Response-Auth AVP . . . . . . . . . . . . . . . . . 53
8.5.22 Digest-AKA-Auts AVP . . . . . . . . . . . . . . . . . . . 53
8.6 SIP-Number-Auth-Items AVP . . . . . . . . . . . . . . . . 53
8.7 SIP-Deregistration-Reason AVP . . . . . . . . . . . . . . 53
8.7.1 SIP-Reason-Code AVP . . . . . . . . . . . . . . . . . . . 54
8.7.2 SIP-Reason-Info AVP . . . . . . . . . . . . . . . . . . . 54
8.8 SIP-AOR AVP . . . . . . . . . . . . . . . . . . . . . . . 54
8.9 SIP-Visited-Network-Id AVP . . . . . . . . . . . . . . . . 54
8.10 SIP-User-Authorization-Type AVP . . . . . . . . . . . . . 54
8.11 SIP-User-Data AVP . . . . . . . . . . . . . . . . . . . . 55
8.12 SIP-User-Data-Already-Available AVP . . . . . . . . . . . 55
8.13 SIP-User-Data-Request-Type AVP . . . . . . . . . . . . . . 55
8.14 SIP-Method AVP . . . . . . . . . . . . . . . . . . . . . . 56
8.15 New values for existing AVPs . . . . . . . . . . . . . . . 56
8.15.1 Extension to the Result-Code AVP values . . . . . . . . . 56
9. Authentication Details . . . . . . . . . . . . . . . . . . 58
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 59
10.1 Application Identifier . . . . . . . . . . . . . . . . . . 59
10.2 Command Codes . . . . . . . . . . . . . . . . . . . . . . 59
10.3 AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 59
10.4 Additional values for the Result-Code AVP value . . . . . 59
11. Security Considerations . . . . . . . . . . . . . . . . . 60
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 60
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 60
14. Changes with respect previous versions . . . . . . . . . . 60
14.1 Changes from draft-ietf-aaa-diameter-sip-app-01.txt to
-02.txt . . . . . . . . . . . . . . . . . . . . . . . . . 60
14.2 Changes from draft-ietf-aaa-diameter-sip-app-00.txt to
-01.txt . . . . . . . . . . . . . . . . . . . . . . . . . 61
14.3 Changes from draft-belinchon-aaa-diameter-mm-app-01.txt
Garcia-Martin, et al. Expires October 1, 2004 [Page 3]
Internet-Draft Diameter SIP application April 2004
to draft-ietf-aaa-diameter-sip-app-00.txt . . . . . . . . 62
Normative References . . . . . . . . . . . . . . . . . . . 62
Informational References . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . 65
Garcia-Martin, et al. Expires October 1, 2004 [Page 4]
Internet-Draft Diameter SIP application April 2004
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. Definitions
For the purpose of this document, the following terms and definitions
apply.
o 'Node: ' an addressable device attached to a computer network that
implements SIP functionality, Diameter functionality or a
combination of both.
For the purpose of this document, the following terms and definitions
given in RFC 3261 [3] section 6, apply:
o 'Address-of-Record (AOR)'
o 'Outbound proxy'
o 'Proxy'
o 'Server (SIP server)'
o 'User Agent (UA)'
o 'User Agent Client (UAC)'
For the purpose of this document, the following terms and definitions
given in RFC 3588 [5] section 1.3, apply:
o 'Authorization'
o 'Authentication'
o 'AVP'
o 'Diameter Client'
o 'Diameter Server'
o 'Home Realm'
o 'Relay Agent or Relay'
o 'Redirect Agent'
o 'User'
3. Introduction
This document specifies the Diameter Session Initiation Protocol
(SIP) 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) [3] based IP multimedia services. We assume that the SIP server
and the Diameter client are located in the same node, so that the SIP
Garcia-Martin, et al. Expires October 1, 2004 [Page 5]
Internet-Draft Diameter SIP application April 2004
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 or when SIP is used for other
non-session related applications. However, this document does not
mandate any particular mapping of SIP procedures to Diameter SIP
application procedures, nor does it mandate any particular sequence
of events between SIP and Diameter. This document provides useful
examples to show the interaction between SIP and the Diameter SIP
application in order to achieve the desired functionality.
The Applicability section (Section 4) discusses assumptions and
configurations assumed by this document.
The Overview of Operation chapter (Section 5) provides the reader
with informative descriptions of the Diameter SIP application
commands and responses and some guidance to their linkage with SIP
procedures.
Advertising of this application is described in the Advertising
Application Support chapter (Section 6).
The Diameter SIP application Command Codes chapter (Section 7)
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 8.15).
This application defines some new AVPs. All these AVPs are described
in the Diameter SIP application AVPs chapter (Section 8).
Some extra information about authentication is provided in the
Authentication details chapter (Section 9).
4. Applicability
This document assumes a general architecture where a Home Realm is
composed of one or more nodes implementing Diameter or SIP functions.
At least, one of such nodes implements the Diameter Server
functionality and the Diameter Server has access to a user database.
The user data associated to a particular user is stored in a single
point in the network referred to as the user database. There may be
more than a single Diameter Server in the network, and all these
Garcia-Martin, et al. Expires October 1, 2004 [Page 6]
Internet-Draft Diameter SIP application April 2004
servers have access to such user database. But at a given time, the
data a Diameter Server returns is independent of the Diameter Server
that returns the information.
Central to the architecture is the fact that the user data is
stored in a single point in the network. This restriction does not
mandate a particular implementation, e.g., it is possible to
implement clusters of databases operating in mirror mode to
provide redundancy. The property required by this specification is
that the user data the Diameter Server has access to is stored
safely in what, from the external point of view, is seen as a
single user database.
This document allows several configurations of the Home Realm. In one
of such configurations, a SIP server is allocated to a user for the
purpose of triggering and executing services. The allocation of the
SIP server may be done dynamically, e.g., at the time the user
registers in the network. This configuration requires a SIP server,
typically located at the edge of the network, that is able to
allocate another SIP server for the user and also supports routing of
SIP requests and responses towards that allocated SIP server. Both
SIP server nodes implement a Diameter Client.
In another configuration, the address of a SIP outbound proxy is
configured (by means outside the scope of this specification) into
the SIP endpoint. The outbound Diameter Client in the SIP outbound
proxy node authenticates the user, requests authorization for SIP
requests and performs accounting activities.
5. Overview of operation
This section provides an informative description of how the Diameter
SIP application can be used together with SIP. This section is not
intended to mandate any specific usage of the Diameter SIP
application nor does it mandate a specific mapping between SIP and
Diameter messages. This section is a collection of examples that show
how the required AAA functionality can be achieved in conjunction
with SIP.
5.1 General architecture
The Diameter SIP 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
Garcia-Martin, et al. Expires October 1, 2004 [Page 7]
Internet-Draft Diameter SIP application April 2004
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 |
+------+ +--------+ +--------+ +------+
^ ^
UAR/UAA | | PPR/PPA
LIR/LIA | | MAR/MAA
| +--------+ | SAR/SAA
+--->|Diameter|<----+ RTR/RTA
| SL |
+--------+
Figure 1: Architecture of the Diameter application for SIP
In Figure 1, it can be seen that SIP server 1 sends different
Diameter commands and receives different responses to those sent and
received by SIP server 2. This is because SIP server 1 in Figure 1 is
located at the edge of a network, and its main task is to locate SIP
server 2. SIP server 2 is requesting and receiving authentication and
authorization data from the Diameter server and is not located at the
edge of the network.
The Diameter Subscriber Locator (SL) serves for the purposes of
locating the Diameter server that contains the user related data. Its
functionality is further described in Section 5.8.
It should be noted that this document does not mandate any particular
SIP/AAA architecture. However, the Diameter SIP application provides
the functionality needed to accommodate all the different
architectures where SIP and Diameter are used.
The following subsections provide an informative overview of the
Diameter SIP application, its commands, and a possible interaction
with SIP signaling.
Garcia-Martin, et al. Expires October 1, 2004 [Page 8]
Internet-Draft Diameter SIP application April 2004
5.2 Diameter server authenticates the user
In this approach we show an example of an administrative network
where the Diameter server is authenticating 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) |<--------------------------------------|
<----------------| | |
| | 17. SAR |
| |<------------------|
| | 18. SAA |
| |------------------>|
| | |
Garcia-Martin, et al. Expires October 1, 2004 [Page 9]
Internet-Draft Diameter SIP application April 2004
Figure 2: Authentication performed in the Diameter server
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 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 SIP server 2, so as to return
subsequent requests for 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 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 SIP server 1 and then to the SIP UAC
(step 8).
SIP server 1 will receive a next SIP REGISTER request containing the
user credentials (step 9). Note that SIP server 1 does not need to
keep a state, and even more, there is no guarantee that the SIP
request will arrive at the same SIP server 1, there could be a farm
of SIP servers 1 operating in redundant configuration. The Diameter
client in SIP server 1 will contact a 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. 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
Garcia-Martin, et al. Expires October 1, 2004 [Page 10]
Internet-Draft Diameter SIP application April 2004
DIAMETER_SUCCESS.
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).
If the Diameter client in SIP server 2 is interested in downloading
the user profile information, then it will send a Diameter SAR
message (step 17) to the Diameter server. The Diameter server will
reply with a Diameter SAA message (step 18) that contains the
requested user profile information. These actions are only needed
when the SIP server needs to retrieve a user profile used to provide
services to the served user.
5.3 Diameter server delegates authentication to the SIP server
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
available in Diameter servers.
Garcia-Martin, et al. Expires October 1, 2004 [Page 11]
Internet-Draft Diameter SIP application April 2004
+--------+ +--------+ +--------+
| 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. SAR |
| |<------------------|
| | 14. SAA |
| |------------------>|
| 15. 200 (OK) | |
16. 200 (OK) |<--------------------------------------|
<----------------| | |
| | |
Figure 3: Delegation of authentication to the SIP server
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 that of the
3rd Generation Partnership Project (3GPP) IP Core Network Multimedia
Subsystem (IMS).
A first SIP server receives a SIP REGISTER request (step 1) whose
target is 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 from the
Diameter server to proceed with the registration, by sending a
Garcia-Martin, et al. Expires October 1, 2004 [Page 12]
Internet-Draft Diameter SIP application April 2004
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 it is a
valid defined user in the home network, will authorize the the
registration to proceed. 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 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
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 SIP server 1 receives a next SIP REGISTER request containing the
user credentials (step 9), as 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
Garcia-Martin, et al. Expires October 1, 2004 [Page 13]
Internet-Draft Diameter SIP application April 2004
order to provide a service to the user.
SIP server 2 generates a SIP 200 (OK) response (step 15) that will be
forwarded to SIP server 1 and eventually to the SIP UAC (step 16).
5.4 SIP server authenticates a request
Figure 4 depicts a typical scenario where a stateless SIP proxy
requests authentication information and authorization to a Diameter
server, for the purpose of providing SIP routing services to a SIP
User Agent. The SIP proxy server may be configured as an outbound SIP
proxy, so that all the requests initiated by the SIP UA traverse the
SIP proxy.
According to Figure 4, a SIP User Agent sends a SIP request to its
outbound SIP proxy server. In this case, the message is a SIP INVITE
request (see step 1), but it could be any other SIP request. We
assume that this SIP request does not contain any credentials at this
time. The outbound SIP proxy server needs to authenticate and
authorize the proxy services offered to the user. The Diameter client
in the SIP server sends a Multimedia-Auth-Request (MAR) message (step
2). The Diameter server sends a Multimedia-Auth-Answer (MAA) message
(step 3) that includes all the data necessary for the SIP server to
challenge the user, typically with HTTP Digest Authentication
indicated in the MAA message. This data will serve the SIP server to
create a SIP 407 Proxy Authentication Required response (step 4) that
contains a challenge. The SIP UA will create a new INVITE request
(step 5) that contains the credentials. The Diameter client in the
SIP server will send the credentials to the Diameter server in a new
Diameter MAR message (step 6). The Diameter server will validate the
credentials and authorize the SIP transaction in a Diameter MAA
message (step 7). The SIP server forwards the SIP INVITE request to
its destination (step 8) as per regular SIP procedures. Eventually,
the session setup will be confirmed with a 200 OK response (step 9)
that is forwarded to the SIP UA (step 10). The session setup is
complete.
Garcia-Martin, et al. Expires October 1, 2004 [Page 14]
Internet-Draft Diameter SIP application April 2004
+--------+ +--------+ +--------+
| UA | |Diameter| | SIP |
| | | server | | server |
+--------+ +--------+ +--------+
| | |
| 1. SIP INVITE |
|---------------------------->|
| | 2. MAR |
| |<----------------|
| | 3. MAA |
| |---------------->|
| 4. SIP 407 Proxy |
| Authentication Required |
|<----------------------------|
| 5. SIP INVITE |
|---------------------------->|
| | 6. MAR |
| |<----------------|
| | 7. MAA |
| |---------------->| 8. SIP INVITE
| | |---------------->
| | | 9. SIP 200 OK
| 10. SIP 200 OK |<----------------
|<----------------------------|
| | |
Figure 4: SIP server request authorization
5.5 Session attempt
Figure 5 shows the scenario where SIP server 1 may be configured as a
SIP edge proxy server, processing SIP traffic at the edge of a
network. SIP server 1 receives a SIP INVITE request (step 1). SIP
server 1 needs to find the address of 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 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).
Garcia-Martin, et al. Expires October 1, 2004 [Page 15]
Internet-Draft Diameter SIP application April 2004
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP INVITE | | |
-------------->| 2. LIR | |
|------------------>| |
| 3. LIA | |
|<------------------| |
| 4. SIP INVITE |
|-------------------------------------->|
| | | 5. SIP INVITE
| | |-------------->
| | |
| | |
Figure 5: SIP session attempt: locating the SIP server
Although the example shows the connection between a SIP INVITE
request and the Diameter LIR message, any other SIP request other
than REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the
same Diameter message (A SIP REGISTER request will trigger a Diameter
UAR message, as indicated in Figures Figure 2 and Figure 3.
5.6 Update of the user profile
The Diameter SIP 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-Answer (SAA) 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 mechanisms outside the scope of this
specification, such as human intervention, in the Diameter server. 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 illustrated in Figure 6. Where 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-AOR AVPs. 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
Garcia-Martin, et al. Expires October 1, 2004 [Page 16]
Internet-Draft Diameter SIP application April 2004
server.
+--------+ +--------+
|Diameter| | SIP |
| server | |server 2|
+--------+ +--------+
| |
| 1. PPR |
|------------------>|
| |
| 2. PPA |
|<------------------|
| |
Figure 6: Diameter server pushes an update of the user profile
5.7 Registration termination
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).
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).
Alternatively, 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 Diameter base protocol, RFC 3588 [5] 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.
Garcia-Martin, et al. Expires October 1, 2004 [Page 17]
Internet-Draft Diameter SIP application April 2004
5.8 Diameter server discovery
The basic architecture assumption of this document is that all the
data related to a user is stored in a unique Diameter server. This
does not create a single point of failure, as it may be generally
thought. It is assumed that Diameter servers will be configured in a
redundant fashion as an attempt to mitigate the single point of
failure problem.
In large networks, where the number of users may be significantly
high, there might be a need to scale the number of Diameter servers.
All the data associated to a user will be still stored in a single
(typically redundant) Diameter server. But the data associated to
different users may reside in different Diameter servers.
This configuration, although scales well, introduces a new problem,
namely: giving the SIP AOR as an input, how to determine which of
various Diameter servers is storing the data for that particular SIP
AOR. We solve this problem by making usage of the standard Diameter
redirection and relay mechanisms, specified in RFC 3588 [5]. We
include in the architecture a new Diameter node that, for the purpose
of this document, it is known as Diameter Subscriber Locator (SL).
The Diameter Subscriber Locator contains a database or routing tables
that maps SIP AORs with Diameter server URIs. A particular Diameter
server URI points to the actual Diameter server that stores all the
data related to a particular SIP AOR, and in consequence, to the user
who owns the SIP AOR. The Diameter Subscriber Locator acts as either
Diameter Relay or Diameter Redirect Agent, dispatching Diameter
request (either proxying them to the corresponding Diameter server or
sending the redirection URI in the answer).
Note that according to the Diameter procedures the redirect
functionality in the Diameter client is performed automatically in
the Diameter stack, and it does not require any knowledge or
support by the Diameter application.
The Diameter SL can be replicated in different nodes along the
network, for the purpose of building scalability and redundancy. The
database or routing tables have to be consistent across all these
different Diameter SLs, so that the same Diameter request will
produce the same Diameter answer no matter the Diameter SL that
processes the request.
Garcia-Martin, et al. Expires October 1, 2004 [Page 18]
Internet-Draft Diameter SIP application April 2004
+--------+ +--------+ +--------+ +--------+
| SIP | |Diameter| |Diameter| | SIP |
|server 1| |SL red. | |server 1| |server 2|
+--------+ +--------+ +--------+ +--------+
| | | |
1. SIP INVITE| | | |
------------>| 2. LIR | | |
|---------->| | |
| 3. LIA | | |
|<----------| | |
| 4. LIR | |
|---------------------->| |
| 5. LIA | |
|<----------------------| |
| 6. SIP INVITE | |
|----------------------------------->| 7. SIP INVITE
| | | | ------------->
| | | |
Figure 7: Locating a Diameter server. SL redirecting requests
Figure 7 shows an example of operation of a Diameter Subscriber
Locator acting in redirect mode. SIP server 1 is receiving an INVITE
request (step 1) addressed (in the SIP Request-URI) to a user for
which the Diameter client in SIP server 1 does not posses routing
information. In other words, the Diameter client in SIP server 1 does
not know the URI of Diameter server 1. The Diameter client sends a
Diameter LIR message (step 2) to any of the Diameter SLs configured
in the network. The address of those SLs is assumed to be
pre-provisioned in the Diameter client. The Diameter SL, based on the
contents of the SIP-AOR AVP and its own routing tables determines the
Diameter server that stores the information allocated to such user.
Then it builds a Diameter LIA message (step 3) that includes a
Result-Code AVP set to DIAMETER_REDIRECT_INDICATION and one or more
Redirect-Host AVPs, whose values are set to one or more URIs of
Diameter servers that store the information related to such user.
Then the Diameter client in SIP server 1 builds a new LIR message
addressed to any of the Diameter servers received in the
Redirect-Host AVPs. The rest of procedure is completed as described
in previous sections.
Garcia-Martin, et al. Expires October 1, 2004 [Page 19]
Internet-Draft Diameter SIP application April 2004
+--------+ +--------+ +--------+ +--------+
| SIP | |Diameter| |Diameter| | SIP |
|server 1| |SL relay| |server 1| |server 2|
+--------+ +--------+ +--------+ +--------+
| | | |
1. SIP INVITE| | | |
------------>| 2. LIR | | |
|---------->| 3. LIR | |
| |---------->| |
| | 4. LIA | |
| 5. LIA |<----------| |
|<----------| | |
| | | |
| 6. SIP INVITE | |
|----------------------------------->| 7. SIP INVITE
| | | | ------------->
| | | |
Figure 8: Locating a Diameter server. SL relaying messages
In another configuration, the Diameter SL is acting as a Diameter
relay agent. The scenario is depicted in Figure 8. SIP server 1 is
receiving an INVITE request (step 1) addressed (in the SIP
Request-URI) to a user for which the Diameter client in SIP server 1
does not posses routing information. In other words, the Diameter
client in SIP server 1 does not know the URI of Diameter server 1.
The Diameter client sends a Diameter LIR message (step 2) to any of
the Diameter SLs configured in the network. The address of those SLs
is assumed to be pre-provisioned in the Diameter client. The Diameter
SL, based on the contents of the SIP-AOR AVP and its own routing
tables, determines the Diameter server that stores the information
allocated to such user and it forwards the Diameter LIR message to
such Diameter server (step 4). The Diameter server will eventually
answer with a Diameter LIA message (LIA) that is forwarded to the
Diameter client (step 5). Then the SIP server can proceed forwarding
the message to the proper destination.
6. Advertising Application Support
Diameter implementations conforming to this specification MUST
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, RFC 3588 [5].
7. Diameter SIP application Command Codes
All the Diameter implementations conforming to this specification
MUST implement and support the list of Diameter commands listed in
Garcia-Martin, et al. Expires October 1, 2004 [Page 20]
Internet-Draft Diameter SIP application April 2004
Table 1.
+----------------------------------+-------+-------+----------------+
| Command Name | Abbr. | Code | Reference |
+----------------------------------+-------+-------+----------------+
| User-Authorization-Request | UAR | aaa | Section 7.1 |
| User-Authorization-Answer | UAA | aaa | Section 7.2 |
| Server-Assignment-Request | SAR | bbb | Section 7.3 |
| Server-Assignment-Answer | SAA | bbb | Section 7.4 |
| Location-Info-Request | LIR | ccc | Section 7.5 |
| Location-Info-Answer | LIA | ccc | Section 7.6 |
| Multimedia-Auth-Request | MAR | ddd | Section 7.7 |
| Multimedia-Auth-Answer | MAA | ddd | Section 7.8 |
| Registration-Termination-Request | RTR | eee | Section 7.9 |
| Registration-Termination-Answer | RTA | eee | Section 7.10 |
| Push-Profile-Request | PPR | fff | Section 7.11 |
| Push-Profile-Answer | PPA | fff | Section 7.12 |
+----------------------------------+-------+-------+----------------+
Table 1
7.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
authorization for the SIP User Agent to route a SIP REGISTER request.
As the SIP REGISTER request implicitly carries a permision to bind an
AOR to a contact address, the Diameter client uses the Diameter UAR
as a first authorization request towards the Diameter server to
authorize the registration. For instance, the Diameter server can
verify that the AOR is a legitimate user of the realm.
The Diameter client in the SIP server will request authorization of
the REGISTRATION, DE-REGISTRATION or REGISTRATION&CAPABILITIES
functions to the Diameter server. See more information in the
SIP-User-Authorization-Type AVP (Section 8.10).
The user name used for authentication of the user is conveyed in a
User-Name AVP (imported from the Diameter base protocol, RFC 3588
[5]). The location of the authentication user name in the SIP
REGISTER request varies depending on the authentication mechanism.
When the authentication mechanism is HTTP Digest as defined in RFC
2617 [2], 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-AOR AVP
Garcia-Martin, et al. Expires October 1, 2004 [Page 21]
Internet-Draft Diameter SIP application April 2004
(Section 8.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-Id 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-AOR }
[ SIP-Visited-Network-Id ]
[ SIP-User-Authorization-Type ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
7.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. The Diameter
server indicates the result of the requested registration
authorization. Additionally, the Diameter serve may indicate the a
collection of SIP capabilities that assists the Diameter client to
select a SIP proxy to the AOR under registration.
In addition to the values already defined in RFC 3588 [5], the
Result-Code AVP may contain one of the values defined in Section
8.15.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.
If the Diameter server requires a User-Name AVP value to process the
Garcia-Martin, et al. Expires October 1, 2004 [Page 22]
Internet-Draft Diameter SIP application April 2004
Diameter UAR request, but the Diameter UAR message did not contain a
User-Name AVP value, the Diameter server MUST set the Result-Code AVP
value to DIAMETER_USER_NAME_REQUIRED (see and return it in a
Diameter UAA message. Upon the reception of the Diameter UAA message,
the SIP server will typically request authentication by sending a 401
(Unauthorized) or 407 (Proxy Authentication Required) response back
to the originator.
When the authorization procedure succeeds, the Diameter server
constructs a User-Authorization-Answer (UAA) message that MUST
include the address of the SIP server already assigned to the user,
the capabilities needed by the SIP server (Diameter client) to select
another SIP server for the user or a combination of the previous two
options.
The Diameter UAA message contains the address of the SIP server
allocated to the user if the Diameter server is already aware of an
allocated SIP server to the user.
The Diameter UAA message contains the capabilities required by a SIP
server when there is a possibility that the Diameter client (in the
SIP server) needs to allocate another SIP server that will be
handling all the requests associated to this user, and possibly
triggering and executing services.
If a User-Name AVP is present in the Diameter UAR message, then 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.
If a User-Name AVP is present in the Diameter UAR message, then the
Diameter server MUST authorize that User-Name AVP value is able to
register the SIP or SIPS URI included in the SIP-AOR 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.
Correlation between User-Name and SIP-AOR AVP values is required
just to avoid that any user can register a SIP-AOR allocated to
another user.
If there is a SIP-Visited-Network-Id 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
Garcia-Martin, et al. Expires October 1, 2004 [Page 23]
Internet-Draft Diameter SIP application April 2004
whether the user is allowed to roam into the network specified in the
SIP-Visited-Network-Id 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.
If 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 SIP-AOR AVP value is
authorized to register in the home realm. Where the SIP Address of
Record 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.
When the SIP-User-Authorization-Type AVP is not present in the
Diameter UAR message, or it is present and its value 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 SIP Addresses
of Record 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 SIP Addresses of
Record 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-URI 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.
When the SIP-User-Authorization-Type AVP value received in the
Diameter UAR message is set to REGISTRATION&CAPABILITIES then
Garcia-Martin, et al. Expires October 1, 2004 [Page 24]
Internet-Draft Diameter SIP application April 2004
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-URI 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 server can be selected.
When the SIP-User-Authorization-Type AVP value received in the
Diameter UAR message is set to DE-REGISTRATION then:
o If the Diameter server is aware of a SIP server assigned to the
SIP AOR under de-registration, the Diameter server MUST set the
Result-Code AVP to DIAMETER_SUCCESS and MUST set the
SIP-Server-URI AVP value to the known SIP server, and return them
in the Diameter UAA message.
o If the Diameter server is not aware of a SIP server assigned to
the SIP AOR 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-URI ]
[ SIP-Server-Capabilities ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
7.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 in many cases to request the Diameter server to store the URI
Garcia-Martin, et al. Expires October 1, 2004 [Page 25]
Internet-Draft Diameter SIP application April 2004
of the SIP server that is currently serving the user. The Diameter
SAR command has the main function to inform and store/clear in the
Diameter server the URI of the SIP server allocated to the user.
Additionally, the Diameter client can request to download the user
profile or part of it.
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-URI 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 8.4). For instance, a
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 8.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.
OPEN ISSUE: need to write an example to support this case in the
flows.
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
Garcia-Martin, et al. Expires October 1, 2004 [Page 26]
Internet-Draft Diameter SIP application April 2004
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-AOR AVP in the Diameter SAR message.
Message Format
<SAR> ::= < Diameter Header: bbb, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ User-Name ]
* [ SIP-AOR ]
[ SIP-Server-URI ]
{ SIP-Server-Assignment-Type }
{ SIP-User-Data-Request-Type }
{ SIP-User-Data-Already-Available }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
7.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. The response may
include the user profile or part of it, if requested.
In addition to the values already defined in RFC 3588 [5], the
Result-Code AVP may contain one of the values defined in Section
8.15.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
that user.
Garcia-Martin, et al. Expires October 1, 2004 [Page 27]
Internet-Draft Diameter SIP application April 2004
If the Diameter server requires a User-Name AVP value to process the
Diameter SAR request, but the Diameter SAR message did not contain a
User-Name AVP value, the Diameter server MUST set the Result-Code AVP
value to DIAMETER_USER_NAME_REQUIRED (see and return it in a
Diameter SAA message. Upon the reception of the Diameter SAA message,
the SIP server will typically request authentication by sending a 401
(Unauthorized) or 407 (Proxy Authentication Required) response back
to the originator.
If the User-Name AVP is included in the Diameter SAR message, 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-AOR 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
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-AOR 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-AOR 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 with the SIP-AOR AVP and
all other SIP identities associated with 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 AOR 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-URI AVP
value. The Diameter server will return the SIP server address in
Garcia-Martin, et al. Expires October 1, 2004 [Page 28]
Internet-Draft Diameter SIP application April 2004
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
with the SIP or SIPS URI (SIP-AOR 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 AOR
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-AOR 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-AOR 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.
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 with
all SIP Addresses of Record indicated in each of the SIP-AOR AVP
values included in the Diameter SAR message. The Diameter server
considers all of these SIP Addresses of Record 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 MAY keep
the SIP server address associated with the SIP Addresses of Record
included in the SIP-AOR AVP values of the Diameter SAR message,
even though the SIP Addresses of Record will become unregistered.
This feature allows a SIP server to request the Diameter server to
remain as an assigned SIP server for those SIP Addresses of Record
(SIP-AOR AVP values), and avoid SIP server assignment. The
Diameter server MUST consider all these SIP Addresses of Record 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 Addresses of Record 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,
Garcia-Martin, et al. Expires October 1, 2004 [Page 29]
Internet-Draft Diameter SIP application April 2004
the Diameter server MUST clear the SIP server name assigned to
those SIP Addresses of Record 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-URI AVP value in the Diameter SAR
message is the same URI as the as the one assigned to the SIP-AOR
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
message is set to AUTHENTICATION_FAILURE or
AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there
is only SIP-AOR AVP in the Diameter SAR message. If the number of
occurrences of the SIP-AOR 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-AOR AVP in the Diameter SAR message, the Diameter server MUST
clear the address of the SIP server assigned to the SIP Address of
Record, 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 AOR 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-Accouting-Information ]
[ User-Name ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
Garcia-Martin, et al. Expires October 1, 2004 [Page 30]
Internet-Draft Diameter SIP application April 2004
7.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
routing information, e.g., the URI of the SIP server assigned to a
particular user. The user is identified by the SIP-AOR AVP value.
Message Format
<LIR> ::= < Diameter Header: ccc, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ SIP-AOR }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
7.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 RFC 3588 [5], the
Result-Code AVP may contain one of the values defined in Section
8.15.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-AOR AVP value is not a valid user in the realm. In such cases,
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-URI
Garcia-Martin, et al. Expires October 1, 2004 [Page 31]
Internet-Draft Diameter SIP application April 2004
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-AOR 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-URI 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
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 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) with the selection of an appropriate SIP server
with the required capabilities. Absence of the
SIP-Server-Capabilities AVP will indicate to the SIP server
(Diameter client) that any SIP server is suitable to be allocated
for 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.
Garcia-Martin, et al. Expires October 1, 2004 [Page 32]
Internet-Draft Diameter SIP application April 2004
Message Format
<LIA> ::= < Diameter Header: ccc, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-URI ]
[ SIP-Server-Capabilities ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
7.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
server to request the Diameter server to authenticate and authorize a
user attempt to use some SIP service (in this context, SIP service
can be something as simple as a SIP subscription or using the proxy
services for a SIP request). Unlike the Diameter UAR command, MAR
does not store any state in the Diameter server.
This Diameter application provides Diameter clients in SIP servers
with a centralized routing information functionality, so that if a
Diameter client in a SIP server wants to find out routing information
for a particular user, the Diameter server can return (in a Diameter
LIA message) the SIP URI of the SIP server allocated to the user.
This allows SIP servers operating in a stateful mode to receive all
the SIP traffic addressed to the user. For this functionality to
work, the SIP server allocated to the user ought to register its URI
to the Diameter server. This is accomplished with the SIP-Server-URI
AVP provided in the Diameter MAR command that we describe in this
section.
The SIP-Method AVP MUST include the SIP method name of the SIP
request that triggered this Diameter MAR message.
The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP
indicates the intended Address-of-Record of the SIP request. The
Garcia-Martin, et al. Expires October 1, 2004 [Page 33]
Internet-Draft Diameter SIP application April 2004
value of the AVP is extracted from the SIP request, but the location
of such AVP is different depending on the semantics of the SIP
request. For SIP REGISTER messages the SIP-AOR AVP value indicates
the intended public user identity under registration, and it is the
SIP or SIPS URI populated in the To header field value (addr-spec,
according to the SIP ABNF) of the SIP REGISTER request. For other
types of SIP requests, such as INVITE, SUBSCRIBE, MESSAGE, etc., the
SIP-AOR AVP value indicates the intended destination of the request.
This is typically populated in the Request-URI of the SIP request. It
is the Diameter client responsibility to extract the SIP-AOR AVP
value from the proper SIP header field. Extensions to SIP (new SIP
methods or new semantics) may require to extract the SIP-AOR from
other parts of the request.
If the SIP request includes some sort of authentication information,
the Diameter client MUST include the user name, extracted from the
authentication information of the SIP request, in the User-Name AVP
value.
Message Format
<MAR> ::= < Diameter Header: ddd, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ User-Name ]
{ SIP-AOR }
{ SIP-Method }
[ SIP-Server-URI ]
[ SIP-Number-Auth-Items ]
[ SIP-Auth-Data-Item ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
7.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 RFC 3588 [5], the
Result-Code AVP may contain one of the values defined in Section
Garcia-Martin, et al. Expires October 1, 2004 [Page 34]
Internet-Draft Diameter SIP application April 2004
8.15.1.
If the Diameter server requires a User-Name AVP value to process the
Diameter MAR request, but the Diameter MAR message did not contain a
User-Name AVP value, the Diameter server MUST set the Result-Code AVP
value to DIAMETER_USER_NAME_REQUIRED (see and return it in a
Diameter MAA message. The Diameter server MAY include a
SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs
with authentication information (e.g., a challenge). Upon the
reception of the Diameter MAA message, the SIP server will typically
request authentication by sending a 401 (Unauthorized) or 407 (Proxy
Authentication Required) response back to the originator.
If the User-Name AVP is present in 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.
If the SIP-Method AVP value of the Diameter MAR message is set to
REGISTER and a User-Name AVP is present, then the Diameter server
MUST authorize that User-Name AVP value is able to use the URI
included in the SIP-AOR 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.
Correlation between User-Name and SIP-AOR AVP values is only
required for SIP REGISTER request, just to avoid that any user can
register a SIP-AOR allocated to another user. In other types of
SIP requests (e.g., INVITE), the SIP-AOR will indicate the
intended destination of the request, rather than the originator of
it.
Then Diameter server MUST verify whether the authentication scheme
(SIP-Authentication-Scheme AVP value) indicated in the grouped
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 grouped
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
Garcia-Martin, et al. Expires October 1, 2004 [Page 35]
Internet-Draft Diameter SIP application April 2004
SIP-Authorization AVP value to synchronize the vectors. The Diameter
server MUST set the Result-Code AVP to DIAMETER_SUCCESS.
If the SIP-Number-Auth-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 the
Diameter server, when building the Diameter MAA message, includes a
number of SIP-Auth-Data-Item AVPs that is a subset of the
authentication data items requested by the Diameter client in the
SIP-Number-Auth-Items AVP value of the Diameter MAR message.
If the SIP-Server-URI AVP is present in the Diameter MAR message,
then the Diameter server MUST compare the stored SIP server assigned
to the SIP AOR with the SIP-Server-URI 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 SIP AOR, and MUST
set an "authentication pending" flag for the SIP AOR. If there is a
match, the Diameter server shall clear the "authentication pending"
flag for the SIP AOR.
In any other situation, if there is a success in processing the
Diameter MAR command and the Diameter server stored the
SIP-Server-URI, the Diameter server MUST set the Result-Code AVP
value to DIAMETER_SUCCESS and return it in a Diameter MAA message.
If there is a success in processing the Diameter MAR command but the
Diameter server does not store the SIP-Server-URI because the AVP was
not present in the Diameter MAR command, then the Diameter server
MUST set the Result-Code AVP value to either:
1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter
server is sending authentication vectors to create a challenge
2. DIAMETER_SUCCESS_SERVER_NOT_STORED, if the Diameter server
successfully authenticated the user and authorized the SIP server
to proceed with the SIP request.
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.
Garcia-Martin, et al. Expires October 1, 2004 [Page 36]
Internet-Draft Diameter SIP application April 2004
Message Format
<MAA> ::= < Diameter Header: ddd, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ SIP-AOR ]
[ SIP-Number-Auth-Items ]
* [ SIP-Auth-Data-Item ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
7.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 indicate the SIP server that one or more SIP AORs have to
be de-registered. The command allows an operator to administratively
cancel the registration of a user from a centralized Diameter server.
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 decide whether only one
SIP AOR is going to be deregistered, a list of SIP AORs, or all the
SIP AORs allocated to the user.
The absence of a SIP-AOR AVP in the Diameter RTR message indicates
that all the SIP Addresses of Record allocated to the user identified
by the User-Name AVP are being deregistered.
The Diameter server MUST include a SIP-Deregistration-Reason AVP
value to indicate the reason for the deregistration.
Garcia-Martin, et al. Expires October 1, 2004 [Page 37]
Internet-Draft Diameter SIP application April 2004
Message Format
<RTR> ::= < Diameter Header: eee, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
[ Destination-Realm ]
[ User-Name ]
* [ SIP-AOR ]
{ SIP-Deregistration-Reason }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
7.10 Registration-Termination-Answer (RTA) Command
The Registration-Termination-Answer (RTA) is indicated by the
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 RFC 3588 [5], the
Result-Code AVP may contain one of the values defined in Section
8.15.1.
If the Diameter server requires a User-Name AVP value to process the
Diameter RTR request, but the Diameter RTR message did not contain a
User-Name AVP value, the Diameter server MUST set the Result-Code AVP
value to DIAMETER_USER_NAME_REQUIRED (see and return it in a
Diameter RTA message. Upon the reception of the Diameter RTA message,
the SIP server will typically request authentication by sending a 401
(Unauthorized) or 407 (Proxy Authentication Required) response back
to the originator.
The SIP server (Diameter client) will apply the administrative
deregistration to each of the URIs included in each of the SIP-AOR
AVP values, or, if there is no SIP-AOR 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
Garcia-Martin, et al. Expires October 1, 2004 [Page 38]
Internet-Draft Diameter SIP application April 2004
(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 AORs.
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 SIP AORs.
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 SIP AORs.
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 ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
Garcia-Martin, et al. Expires October 1, 2004 [Page 39]
Internet-Draft Diameter SIP application April 2004
7.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
that SIP server. This allows an operator to modify the data of a user
profile and push it to the SIP server where the user is registered.
Each user has a user profile associated with him/her. The profile may
change with time, due to, e.g., addition of new services to the user.
When 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-Host ]
{ Destination-Realm }
[ User-Name ]
{ SIP-User-Data }
* [ SIP-AOR ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
OPEN ISSUE: clarify whether it is User-Name or SIP-AOR what is
included, and if both are present, what is the role of each.
7.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 RFC 3588 [5], the
Result-Code AVP may contain one of the values defined in Section
Garcia-Martin, et al. Expires October 1, 2004 [Page 40]
Internet-Draft Diameter SIP application April 2004
8.15.1.
If the Diameter server requires a User-Name AVP value to process the
Diameter PPR request, but the Diameter PPR message did not contain a
User-Name AVP value, the Diameter server MUST set the Result-Code AVP
value to DIAMETER_USER_NAME_REQUIRED (see and return it in a
Diameter PPA message. Upon the reception of the Diameter PPA message,
the SIP server will typically request authentication by sending a 401
(Unauthorized) or 407 (Proxy Authentication Required) response back
to the originator.
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 SIP AORs 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
override the existing user profile with that received in the PPR
message.
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
Garcia-Martin, et al. Expires October 1, 2004 [Page 41]
Internet-Draft Diameter SIP application April 2004
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 ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
8. Diameter SIP application AVPs
This section defines new AVPs used in this Diameter SIP application.
Applications compliant to this specification MUST implement these
AVPs.
The list of AVPs defined in this Diameter SIP application is listed
in Table 2 and Table 3
Garcia-Martin, et al. Expires October 1, 2004 [Page 42]
Internet-Draft Diameter SIP application April 2004
+-------------------------------+------+-------------+--------------+
| AVP Name | AVP | Reference | Data-Type |
| | Code | | |
+-------------------------------+------+-------------+--------------+
| SIP-Visited-Network-Id | xx01 | Section 8.9 | UTF8String |
| SIP-AOR | xx02 | Section 8.8 | UTF8String |
| SIP-Server-URI | xx03 | Section 8.2 | UTF8String |
| SIP-Server-Capabilities | xx04 | Section 8.3 | Grouped |
| SIP-Mandatory-Capability | xx05 | Section | Unsigned32 |
| | | 8.3.1 | |
| SIP-Optional-Capability | xx06 | Section | Unsigned32 |
| | | 8.3.2 | |
| SIP-User-Data | xx07 | Section | OctetString |
| | | 8.11 | |
| SIP-Number-Auth-Items | xx08 | Section 8.6 | Unsigned32 |
| SIP-Auth-Data-Item | xx09 | Section 8.5 | Grouped |
| SIP-Item-Number | xx10 | Section | Unsigned32 |
| | | 8.5.2 | |
| SIP-Authentication-Scheme | xx11 | Section | Enumerated |
| | | 8.5.1 | |
| SIP-Authenticate | xx12 | Section | Grouped |
| | | 8.5.3 | |
| SIP-Authorization | xx13 | Section | Grouped |
| | | 8.5.4 | |
| SIP-Authentication-Info | xx14 | Section | Grouped |
| | | 8.5.5 | |
| SIP-Authentication-Context | xx15 | Section | Grouped |
| | | 8.5.6 | |
| SIP-Server-Assignment-Type | xx18 | Section 8.4 | Enumerated |
| SIP-Deregistration-Reason | xx19 | Section 8.7 | Grouped |
| SIP-Reason-Code | xx20 | Section | Enumerated |
| | | 8.7.1 | |
| SIP-Reason-Info | xx21 | Section | UTF8String |
| | | 8.7.2 | |
| SIP-Accouting-Information | xx22 | Section 8.1 | Grouped |
| SIP-Accounting-Server-URI | xx23 | Section | DiameterURI |
| | | 8.1.1 | |
| SIP-Credit-Control-Server-URI | xx24 | Section | DiameterURI |
| | | 8.1.2 | |
+-------------------------------+------+-------------+--------------+
Table 2
Garcia-Martin, et al. Expires October 1, 2004 [Page 43]
Internet-Draft Diameter SIP application April 2004
+-------------------------------+------+-------------+--------------+
| AVP Name | AVP | Reference | Data-Type |
| | Code | | |
+-------------------------------+------+-------------+--------------+
| SIP-User-Authorization-Type | xx25 | Section | Enumerated |
| | | 8.10 | |
| SIP-User-Data-Request-Type | xx26 | Section | Enumerated |
| | | 8.13 | |
| SIP-User-Data-Already-Availab | xx27 | Section | Enumerated |
| le | | 8.12 | |
| SIP-Method | xx28 | Section | UTF8String |
| | | 8.14 | |
| Digest-Entity-Body-Hash | xx29 | Section | OctetString |
| | | 8.5.6.1 | |
| Digest-Realm | xx30 | Section | UTF8String |
| | | 8.5.7 | |
| Digest-Domain | xx31 | Section | UTF8String |
| | | 8.5.8 | |
| Digest-Nonce | xx32 | Section | UTF8String |
| | | 8.5.9 | |
| Digest-Opaque | xx33 | Section | UTF8String |
| | | 8.5.10 | |
| Digest-Stale | xx34 | Section | UTF8String |
| | | 8.5.11 | |
| Digest-Algorithm | xx35 | Section | UTF8String |
| | | 8.5.12 | |
| Digest-Qop | xx36 | Section | UTF8String |
| | | 8.5.13 | |
| Digest-Auth-Param | xx37 | Section | UTF8String |
| | | 8.5.14 | |
| Digest-Username | xx38 | Section | UTF8String |
| | | 8.5.15 | |
| Digest-Digest-URI | xx39 | Section | UTF8String |
| | | 8.5.16 | |
| Digest-Response | xx40 | Section | UTF8String |
| | | 8.5.17 | |
| Digest-Cnonce | xx41 | Section | UTF8String |
| | | 8.5.18 | |
| Digest-Nonce-Count | xx44 | Section | UTF8String |
| | | 8.5.19 | |
| Digest-Nextnonce | xx45 | Section | UTF8String |
| | | 8.5.20 | |
| Digest-Response-Auth | xx46 | Section | UTF8String |
| | | 8.5.21 | |
| Digest-AKA-auts | xx47 | Section | UTF8String |
| | | 8.5.22 | |
+-------------------------------+------+-------------+--------------+
Garcia-Martin, et al. Expires October 1, 2004 [Page 44]
Internet-Draft Diameter SIP application April 2004
Table 3
8.1 SIP-Accounting-Information AVP
The SIP-Accounting-Information (AVP code TBD) is of type Grouped, and
contains the Diameter addresses of those nodes that are able to
collect accounting information. The Grouped Data field has the
following ABNF grammar:
SIP-Accounting-Information :: = < AVP Header: TBD >
* [ SIP-Accounting-Server-URI ]
* [ SIP-Credit-Control-Server-URI ]
* [ AVP]
8.1.1 SIP-Accounting-Server-URI AVP
The SIP-Accounting-Server-URI AVP (AVP Code TBD) is of type
DiameterURI. This AVP contains the address of a Diameter server that
is able to receive SIP session related accounting information.
8.1.2 SIP-Credit-Control-Server-URI AVP
The Credit-Control-Server-URI AVP (AVP Code TBD) is of type
DiameterURI. This AVP contains the address of the a Diameter server
that is able to authorize real-time credit control usage. The
Diameter Credit Control Application [9] may be used for this purpose.
8.2 SIP-Server-URI AVP
The SIP-Server-URI AVP (AVP Code TBD) is of type UTF8String. This AVP
contains a SIP or SIPS URI (as defined in RFC 3261 [3]) that
identifies a SIP server.
8.3 SIP-Server-Capabilities AVP
The SIP-Server-Capabilities AVP (AVP Code TBD) is of type Grouped.
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-URI ]
* [ AVP ]
Garcia-Martin, et al. Expires October 1, 2004 [Page 45]
Internet-Draft Diameter SIP application April 2004
8.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.
8.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, 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.
8.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 SIP AOR, without affecting the registration state of such
identity.
o REGISTRATION (1)
First SIP registration of a SIP AOR.
o RE_REGISTRATION (2)
Subsequent SIP registration of a SIP AOR.
o UNREGISTERED_USER (3)
The SIP server has received a SIP request (e.g., SIP INVITE)
addressed for a SIP AOR 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 SIP AOR.
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
Garcia-Martin, et al. Expires October 1, 2004 [Page 46]
Internet-Draft Diameter SIP application April 2004
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
SIP AOR.
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.
8.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-Authentication-Scheme }
[ SIP-Item-Number ]
[ SIP-Authenticate ]
[ SIP-Authorization ]
[ SIP-Authentication-Info ]
[ SIP-Authentication-Context ]
* [ AVP ]
8.5.1 SIP-Authentication-Scheme AVP
The SIP-Authentication-Scheme AVP (AVP code TBD) is of type
Enumerated and indicates the authentication scheme used in the
authentication of SIP services. RFC 2617 identifies this value as an
"auth-scheme" (see section 1.2 of RFC 2617 [2]). The is currently
only one defined value:
o DIGEST (0) to indicate HTTP Digest authentication as specified in
RFC 2617 [2] section 3.2.1. Derivative work is also considered
Digest authentication sheme, as long as the "auth-scheme" is
identified as Digest in the SIP headers carrying the HTTP
authentication. This includes, e.g., the HTTP Digest
authentication using AKA [4].
Garcia-Martin, et al. Expires October 1, 2004 [Page 47]
Internet-Draft Diameter SIP application April 2004
NOTE: Due to the fact that HTTP Digest authentication [2] is the
only mandatory authentication mechanism in SIP, this memo only
provides support for HTTP Digest authentication and derivative
work such as HTTP Digest authentication using AKA [4]. Extensions
to this memo can register new values and new AVPs to provide
support for other authentication schemes.
NOTE: Although RFC 2617 [2]defines the Basic and Digest schemes
for authenticating HTTP requests, RFC 3261 [3] only imports HTTP
Digest as a mechanism to provide authentication in SIP.
8.5.2 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.
8.5.3 SIP-Authenticate AVP
The SIP-Authenticate AVP (AVP code TBD) is of type Grouped and
contains a reconstruction of either the SIP WWW-Authenticate or
Proxy-Authenticate header fields specified in RFC 2617 [2]for the
HTTP Digest authentication scheme.
SIP-Authenticate ::= < AVP Header: TBD >
{ Digest-Realm }
{ Digest-Nonce }
[ Digest-Domain ]
[ Digest-Opaque ]
[ Digest-Stale ]
[ Digest-Algorithm ]
[ Digest-Qop ]
* [ Digest-Auth-Param ]
* [ AVP ]
8.5.4 SIP-Authorization AVP
The SIP-Authorization AVP (AVP code TBD) is of type Grouped and
contains a reconstruction of either the SIP Authorization or
Proxy-Authorization header fields specified in RFC 2617 [2] for the
HTTP Digest authentication scheme.
Garcia-Martin, et al. Expires October 1, 2004 [Page 48]
Internet-Draft Diameter SIP application April 2004
SIP-Authorization ::= < AVP Header: TBD >
{ Digest-Username }
{ Digest-Relam }
{ Digest-Nonce }
{ Digest-Digest-URI }
{ Digest-Response }
[ Digest-Algorithm ]
[ Digest-Cnonce ]
[ Digest-Opaque ]
[ Digest-Qop ]
[ Digest-Nonce-Count ]
* [ Digest-Auth-Param ]
* [ AVP ]
8.5.5 SIP-Authentication-Info AVP
The SIP-Authentication-Info AVP (AVP Code TBD) is of type Grouped and
contains a reconstruction of the SIP Authentication-Info header
specified in RFC 2617 [2] for the HTTP Digest authentication scheme.
SIP-Authentication-Info ::= < AVP Header: TBD >
{ Digest-Nextnonce }
[ Digest-Qop ]
[ Digest-Nonce ]
[ Digest-Cnonce ]
[ Digest-Nonce-Count ]
* [ AVP ]
8.5.6 SIP-Authentication-Context AVP
The SIP-Authentication-Context AVP (AVP code TBD) is of type Grouped
and contains authentication-related information relevant for
performing the authentication that is not part of the SIP
authentication headers.
Some authentication schemes, such us HTTP Digest [2] with quality of
protection set to "auth-int" or HTTP Digest with predictive nonces,
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.
For instance, HTTP Digest with quality of protection set to
"auth-int" requires a hash of the entity body (e.g., SDP). We provide
a Digest-Entity-Body-Hash AVP whose purpose is to send the hash of
Garcia-Martin, et al. Expires October 1, 2004 [Page 49]
Internet-Draft Diameter SIP application April 2004
the entity body.
SIP-Authentication-Context:: = < AVP Header: TBD >
[ Digest-Entity-Body-Hash ]
* [ AVP ]
Diameter clients MUST send a SIP-Authentication-Context AVP when the
authentication mechanism requires processing of extra information not
contained in other existing AVPs or SIP headers, for instance, when
the authentication mechanism requires to verify the entity body of
the SIP request.
8.5.6.1 Digest-Entity-Body-Hash AVP
The Digest-Entity-Body-Hash AVP (AVP Code TBD) is of type OctetString
and contains a hash of the entity body contained in the SIP message.
This hash is required by certain authentication mechanisms, such as
HTTP Digest with quality of protection set to "auth-int". Diameter
clients MUST use this AVP to transport the hash of the entity body
when the authentication mechanism is HTTP Digest and there is a need
the Diameter server requires to verify the integrity of the entity
body (e.g., qop set to "auth-int"). Extensions to this document may
define support for authentication mechanisms other than HTTP Digest.
Such extensions may define new AVPs in the SIP-Authentication-Context
AVP that support the particular mechanism.
The clarifications described in Section 22.4 of RFC 3261 [3] about
the hash of empty entity bodies apply to the Digest-Entity-Body-Hash
AVP.
8.5.7 Digest-Realm AVP
The Digest-Realm AVP (AVP code TBD) is of type UTF8String and
contains the value of the "realm" parameter included in the Digest
header (known as "realm-value" according to RFC 2617 section 1.2).
Note that "realm-value" is a quoted string, thus, the Digest-Realm
AVP value includes quotes as well.
8.5.8 Digest-Domain AVP
The Digest-Domain AVP (AVP code TBD) is of type UTF8String and
contains the value of the "domain" parameter included in the Digest
header. Note that the "domain" parameter contains a quoted string,
thus, the Digest-Domain AVP value includes quotes as well.
8.5.9 Digest-Nonce AVP
The Digest-Nonce AVP (AVP code TBD) is of type UTF8String and
Garcia-Martin, et al. Expires October 1, 2004 [Page 50]
Internet-Draft Diameter SIP application April 2004
contains the value of the "nonce" parameter included in the Digest
header (known as "nonce-value" according to RFC 2617 section 3.2.1).
Note that "nonce-value" is a quoted string, thus, the Digest-Nonce
AVP value includes quotes as well.
8.5.10 Digest-Opaque AVP
The Digest-Opaque AVP (AVP code TBD) is of type UTF8String and
contains the value of the "opaque" parameter included in the Digest
header (known as "opaque-value" according to RFC 2617 section 3.2.1).
Note that "opaque-value" is a quoted string, thus, the Digest-Opaque
AVP value includes quotes as well.
8.5.11 Digest-Stale AVP
The Digest-Stale AVP (AVP code TBD) is of type UTF8String and
contains the value of the "stale" parameter included in the Digest
header (see RFC 2617 section 3.2.1). Note that the "stale" parameter
contains a quoted string, thus, the Digest-Stale AVP value includes
quotes as well.
8.5.12 Digest-Algorithm AVP
The Digest-Algorithm AVP (AVP code TBD) is of type UTF8String and
contains the value of the "algorithm" parameter included in the
Digest header (see RFC 2617 section 3.2.1). Note that the "algorithm"
parameter contains a quoted string, thus, the Digest-Algorithm AVP
value includes quotes as well.
8.5.13 Digest-Qop AVP
The Digest-Qop AVP (AVP code TBD) is of type UTF8String and contains
the value of the "qop" parameter included in the Digest header (see
"qop-options" in section 3.2.1 in RFC 2617 or "message-qop" in
section 3.2.2 in RFC 2617). Note that the "qop" parameter contains a
quoted string, thus, the Digest-Qop AVP value includes quotes as
well.
8.5.14 Digest-Auth-Param AVP
The Digest-Auth-Param AVP (AVP code TBD) is of type UTF8String and is
the mechanism whereby the Diameter client and Diameter server can
exchange possible extension parameters contained in Digest headers
that are not understood by the Diameter client and for which there
are no corresponding standalone AVPs. Unlike the previously listed
Digest-* AVPs, the Digest-Auth-Param contains not only the value, but
also the parameter name, since the parameter name is unknown to the
Diameter client. The Diameter node MUST insert one Digest parameter/
Garcia-Martin, et al. Expires October 1, 2004 [Page 51]
Internet-Draft Diameter SIP application April 2004
value combination per AVP value. If the Digest header contains serval
unknown parameters, then the Diameter implementation MUST repeat this
AVP and each instance MUST contain one different unknown Digest
parameter/value combination. This AVP corresponds to the "auth-param"
parameter defined in RFC 2617 section 3.2.1.
Example: Assume that the Diameter server wants the SIP server to send
a "foo" parameter with the value set to "bar", so that the SIP server
sends that combination in a SIP WWW-Authenticate header field. The
Diameter server builds a grouped SIP-Authenticate AVP that contains a
Digest-Auth-Param whose value is set to foo="bar". Then the SIP
server creates the WWW-Authenticate header field with all the digest
parameters (received in Digest-* AVPs) and adds the foo="bar"
parameter to that header field.
8.5.15 Digest-Username AVP
The Digest-Username AVP (AVP code TBD) is of type UTF8String and
contains the value of the "username" parameter included in the Digest
header (see RFC 2617 section 3.2.2).
8.5.16 Digest-Digest-URI AVP
The Digest-Digest-URI AVP (AVP code TBD) is of type UTF8String and
contains the value of the "uri" parameter in the Digest header (known
as "digest-uri-value" in RFC 2617 section 3.2.2).
8.5.17 Digest-Response AVP
The Digest-Response AVP (AVP code TBD) is of type UTF8String and
contains the value of the "response" parameter included in the Digest
header (known as "request-digest" in RFC 2617 section 3.2.2). Note
that "request-digest" is a quoted string, thus, the Digest-Response
AVP value includes quotes as well.
8.5.18 Digest-Cnonce AVP
The Digest-Cnonce AVP (AVP code TBD) is of type UTF8String and
contains the value of the "cnonce" parameter included in the Digest
header (known as "cnonce-value" according to RFC 2617 section 3.2.2).
Note that "cnonce-value" is a quoted string, thus, the Digest-Cnonce
AVP value includes quotes as well.
8.5.19 Digest-Nonce-Count AVP
The Digest-Nonce-Count AVP (AVP code TBD) is of type UTF8String and
contains the value of the "nc" parameter included in the Digest
header (known as "nc-value" according to RFC 2617 section 3.2.2).
Garcia-Martin, et al. Expires October 1, 2004 [Page 52]
Internet-Draft Diameter SIP application April 2004
8.5.20 Digest-Nextnonce AVP
The Digest-Nextnonce AVP (AVP code TBD) is of type UTF8String and
contains the value of the "nextnonce" parameter included in the
Digest header (known as "nonce-value" in RFC 2617 section 3.2.3).
Note that "nonce-value" is a quoted string, thus, the
Digest-Nextnonce AVP value includes quotes as well.
8.5.21 Digest-Response-Auth AVP
The Digest-Response-Auth AVP (AVP code TBD) is of type UTF8String and
contains the value of the "rspauth" parameter included in the Digest
header (known as "response-digest" according to RFC 2617 section
3.2.3). Note that "response-digest" is a quoted string, thus, the
Digest-Response-Auth AVP value includes quotes as well.
8.5.22 Digest-AKA-Auts AVP
The Digest-AKA-Auts AVP (AVP code TBD) is of type UTF8String and
contains the value of the "auts" parameter included in the Digest AKA
header ("auts-param" according to RFC 3310 section 3.4). Note that
"auts-param" includes quotes, thus, the Digest-AKA-Auts AVP value
includes quotes as well.
8.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.
8.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 ]
Garcia-Martin, et al. Expires October 1, 2004 [Page 53]
Internet-Draft Diameter SIP application April 2004
8.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)
8.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.
8.8 SIP-AOR AVP
The SIP-AOR AVP (AVP Code TBD) is of type UTF8String. The syntax of
this AVP corresponds either to a SIP URI (with the format defined in
RFC 3261 [3]) or a TEL URL (with the format defined in RFC 2806 [6]).
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-AOR 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.
8.9 SIP-Visited-Network-Id AVP
The SIP-Visited-Network-Id 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.
8.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:
Garcia-Martin, et al. Expires October 1, 2004 [Page 54]
Internet-Draft Diameter SIP application April 2004
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.
OPEN ISSUE: If we consider a non-3GPP case, where the user may not
be registered, authorization may be needed for non REGISTER
requests. For instance, every request may be authorized on a case
by case basis. Therefore, it seems reasonable to add more values
to authorize an INVITE, SUBSCRIBE, NOTIFY, MESSAGE, etc. Perhaps
we need to replace the Enumerated type by a Grouped type that
contains the SIP method (e.g., INVITE, SUBSCRIBE, etc.),
Request-URI (the destination), and the Expiration time.
8.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.
The AVP contains the user profile data required for a SIP server to
give service to the user.
8.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.
8.13 SIP-User-Data-Request-Type AVP
The SIP-User-Data-Request-Type AVP (AVP code TBD) is of type
Garcia-Martin, et al. Expires October 1, 2004 [Page 55]
Internet-Draft Diameter SIP application April 2004
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 SIP AORs.
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 SIP AORs.
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 SIP
AORs.
8.14 SIP-Method AVP
The SIP-Method-AVP (AVP code TBD) is of type UTF8String and contains
the method of the SIP request that triggered the Diameter message.
8.15 New values for existing AVPs
This section defines new values that the Diameter SIP application
extends to already existing AVPs.
8.15.1 Extension to the Result-Code AVP values
The Result-Code AVP is already defined in RFC 3588 [5]. In addition
to the values already defined in RFC 3588 [5], the Diameter SIP
application defines the following new Result-Code AVP values:
8.15.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
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
Garcia-Martin, et al. Expires October 1, 2004 [Page 56]
Internet-Draft Diameter SIP application April 2004
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.
o DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2xx6
The requested operation was successfully executed. The Diameter
server is sending authentication vectors in the answer message.
The Diameter server does not keep a record of the SIP server.
o DIAMETER_SUCCESS_SERVER_NOT_STORED 2xx7
The user was successfully authenticate. The Diameter server does
not keep a record of the SIP server.
8.15.1.2 Transient Failures Result-Code AVP values
A Diameter peer uses a Result-Code AVP value that falls in the
transient failures category to inform the remote peer that a request
could not be satisfied at the time it was received, but MAY be able
to satisfy the request in the future.
o DIAMETER_USER_NAME_REQUIRED 4xx1
The Diameter request did not contain a User-Name AVP, and it is
required to complete the transaction. The Diameter peer MAY
attempt the request again including a User-Name AVP.
8.15.1.3 Permanent failures Result-Code AVP values
A Diameter peer uses a Result-Code AVP value that fall into the
permanent failure category to inform the remote peer that the request
failed and should not be attempted again.
o DIAMETER_ERROR_USER_UNKNOWN 5xx1
The SIP-AOR 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-AOR 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 SIP AOR 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
The authentication scheme indicated in an authentication request
Garcia-Martin, et al. Expires October 1, 2004 [Page 57]
Internet-Draft Diameter SIP application April 2004
is not supported.
o DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5xx7
The SIP server address sent in the SIP-Server-URI 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.
9. Authentication Details
Authenticating a user can occur through various mechanisms (HTTP
Digest authentication has 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 User-Name and SIP-AOR 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) which the user can use for
her authentication. The grouped SIP-Authorization AVP will contain
the AVPs that conform the response which is expected from the user.
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 AVPs that conform the relevant parameters from the SIP message,
if present. If necessary, the SIP-Authentication-Context AVP will
Garcia-Martin, et al. Expires October 1, 2004 [Page 58]
Internet-Draft Diameter SIP application April 2004
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 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.
10. IANA Considerations
This document serves as IANA registration request of a number of
items:
10.1 Application Identifier
This document defines a standards track Application-ID in the
Diameter [5] Application Identifier address space.
Application name: Diameter Session Initiation Protocol (SIP)
Application.
Application Identifier: XXX [IANA to replace XXX with the
allocated number]
10.2 Command Codes
This document defines new standard commands, whose Command Codes are
to be allocated within the Command Codes address space in Diameter
[5].
Table 1 in Section 7 contains the detailed list of Command names and
Command codes that are part of this Diameter application.
10.3 AVP Codes
This document defines new standard AVPs, whose AVP Codes are to be
allocated within the AVP Codes address space in Diameter [5].
Table 2 in Section 8 contains the detailed list of AVP names and AVP
codes that are part of this Diameter application.
10.4 Additional values for the Result-Code AVP value
This document defines new standard Result-Code AVP values to be
allocated within the Result-Code AVP address space defined in
Diameter [5].
Garcia-Martin, et al. Expires October 1, 2004 [Page 59]
Internet-Draft Diameter SIP application April 2004
Section 8.15.1.1 lists the new Result-Code AVP values that fall into
the success category, according to RFC 3588 [5] section 7.1.2.
Section 8.15.1.2 lists the new Result-Code AVP values that fall into
the transient failure category, according to RFC 3588 [5] section
7.1.4.
Section 8.15.1.3 lists the new Result-Code AVP values that fall into
the permanent failures category, according to RFC 3588 [5] section
7.1.5.
11. Security Considerations
This memo does not describe a stand-alone protocol, but a particular
application for the Diameter protocol [5]. Consequently, all the
security considerations applicable to Diameter automatically apply to
this memo. In particular, section 13 of RFC 3588 applies to this
memo.
12. Contributors
The authors would like to thank the following contributors who made
substantial contributions to this work:
Pete McCann Lucent
Jaako Rajaniemi Nokia
13. 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. The authors would like to thank Daniel
Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior for
their valuable comments.
The Diameter SIP Application is based on the Diameter Application for
the Cx interface of the 3GPP IP Multimedia Subsystem [10]. The
authors would like to thank 3GPP Working Group CN4 for this work.
14. Changes with respect previous versions
Note to the RFC editor: Delete this section before publication as
RFC.
14.1 Changes from draft-ietf-aaa-diameter-sip-app-01.txt to -02.txt
Garcia-Martin, et al. Expires October 1, 2004 [Page 60]
Internet-Draft Diameter SIP application April 2004
o We have changed the type of the SIP-Authenticate,
SIP-Authorization, SIP-Authentication-Info AVPs. Now, each is a
grouped AVP and contains one or more AVPs that maps to the
corresponding Digest parameter. This means that the Diameter
server will receive in a different AVP each of the values of the
different parameters contained in the Digest headers. This
approach relieves the Diameter server of implementing a SIP parser
to determine the values of each of the parameters.
o Specifically added support for Digest AKA operation, as per RFC
3310 [4]. A Digest-AKA-Auts AVP is added.
o List of auhors trimmed. Contributors section added.
o The SIP-Entity-Body-Hash is renamed to Digest-Entity-Body-Hash to
be aligned with the rest of the Digest-* AVPs.
o The NAS-Session-Key AVP has been deleted. We never knew why this
AVP was here.
o We have removed the support for key distribution. Specifically we
have removed the Confidentiality-Key and Integrity-Key AVPs.
14.2 Changes from draft-ietf-aaa-diameter-sip-app-00.txt to -01.txt
o The SIP-Authentication-Info AVP was mistakenly typed as
OctetString. We changed it to UTF8String. Since SIP is encoded in
UTF8String, there is no point in having an OctetString AVP here.
o The SIP-Authentication-Context AVP is changed to be a grouped AVP.
It contains an SIP-Entity-Body-Hash AVP that contains the hash of
the entity body (e.g., the hash of the SDP). This is because some
authentication mechanisms require to make a hash of the entity
body. Instead of sending the whole entity body to the Diameter
server, it is more efficient to send the hash of the body.
o Added an descriptive text indicating the intended use/actions of
each command.
o Removed references to PGP since it is deprecated in SIP.
o We have focused on providing support for HTTP Digest
authentication in SIP, since it is the mandatory authentication
mechanism in SIP. Other documents can extend this one adding
support for other authentication mechanisms if that is required in
the future.
o Added a Security Considerations section.
o The scenario "Diameter server authenticates the user" had an
error, because it was assuming that the MAR/MAA commands were used
to download the user profile. However, MAR/MAA do not contain
provisions to donwload any user profile. The solution is to add a
SAR/SAA commands that allow the SIP server to get the user profile
stored in the Diameter server.
o Added the missing Redirect-Host-Usage and Redirect-Max-Cache-Time
to all the answers.
Garcia-Martin, et al. Expires October 1, 2004 [Page 61]
Internet-Draft Diameter SIP application April 2004
14.3 Changes from draft-belinchon-aaa-diameter-mm-app-01.txt to
draft-ietf-aaa-diameter-sip-app-00.txt
o Application name changed to Diameter SIP application.
o New Definitions section added.
o New Applicability section added.
o The problem of locating a Diameter server is addressed with the
introduction of a new Diameter Subscriber Locator role.
o Added new scenarios to indicate usage in a more generic internet
environment.
o A few AVPs have been renamed to accurately reflect the intention
of the AVP. For instance, SIP-Server-Name becomes SIP-Server-URI,
and SIP-Public-User-ID becomes SIP-AOR.
o MAR command can be used more generically. Particularly, it does
not assume a SIP REGISTER message. So we had to add a new
SIP-Method AVP to indicate the SIP method that triggered the MAR
command.
o User-Name is no longer mandatory in requests, as typically a SIP
request will not contain a user name. As a result of this change,
a new transit failure Result-Code AVP value has been added:
DIAMETER_USER_NAME_REQUIRED, to indicate the Diameter client that
the request didn't include a User-Name AVP and it is required to
process it. Typically SIP servers, upon the reception of this
Result-Code AVP value, will generate a SIP 401 (Unauthorized) or
407 (Proxy Authentication Required) to request the user name from
the user.
o IANA section has been carefully rewritten to give detailed
instructions to IANA on what is required to register.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] 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.
[4] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
Garcia-Martin, et al. Expires October 1, 2004 [Page 62]
Internet-Draft Diameter SIP application April 2004
Informational References
[6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[7] Calhoun, P., Johansson, T. and C. Perkins, "Diameter Mobile
IPv4 Application", draft-ietf-aaa-diameter-mobileip-15 (work in
progress), October 2003.
[8] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application",
draft-ietf-aaa-diameter-nasreq-13 (work in progress), October
2003.
[9] Hakala, H., "Diameter Credit-control Application",
draft-ietf-aaa-diameter-cc-02 (work in progress), December
2003.
[10] 3GPP, "Cx and Dx interfaces based on the Diameter protocol;
Protocol details", 3GPP TS 29.229, October 2003.
Authors' Addresses
Miguel A. Garcia Martin (editor)
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 480 4586
EMail: miguel.an.garcia@nokia.com
Maria-Carmen Belinchon
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 3535
EMail: maria.carmen.belinchon@ericsson.com
Garcia-Martin, et al. Expires October 1, 2004 [Page 63]
Internet-Draft Diameter SIP application April 2004
Miguel A. Pallares-Lopez
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 4222
EMail: miguel-angel.pallares@ericsson.com
Carolina Canales-Valenzuela
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 2680
EMail: carolina.canales@ericsson.com
Kalle Tammi
Nokia
P.O.Box 301
Nokia Group 00045
Finland
EMail: kalle.tammi@nokia.com
Garcia-Martin, et al. Expires October 1, 2004 [Page 64]
Internet-Draft Diameter SIP application April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Garcia-Martin, et al. Expires October 1, 2004 [Page 65]
