tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4740

 Errata 
Proposed STD
Pages: 72
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: AAA

Diameter Session Initiation Protocol (SIP) Application

Part 1 of 4, p. 1 to 21
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                              M. Garcia-Martin, Ed.
Request for Comments: 4740                                         Nokia
Category: Standards Track                                   M. Belinchon
                                                       M. Pallares-Lopez
                                                   C. Canales-Valenzuela
                                                                Ericsson
                                                                K. Tammi
                                                                   Nokia
                                                           November 2006


         Diameter Session Initiation Protocol (SIP) Application

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

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 SIP and provides a Diameter client co-located with a SIP server,
   with the ability to request the authentication of users and
   authorization of SIP resources usage from a Diameter server.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
   2. Terminology .....................................................5
   3. Definitions .....................................................5
   4. Acronyms ........................................................6
   5. Applicability Statement .........................................6
   6. Overview of Operation ...........................................7
      6.1. General Architecture .......................................7
      6.2. Diameter Server Authenticates the User .....................9
      6.3. Delegating Final Authentication Check to the SIP Server ...12
      6.4. SIP Server Requests Authentication and Authorization ......15
      6.5. Locating the Recipient of the SIP Request .................16
      6.6. Update of the User Profile ................................17
      6.7. SIP Soft State Termination ................................18
      6.8. Diameter Server Discovery .................................19
   7. Advertising Application Support ................................21
   8. Diameter SIP Application Command Codes .........................22
      8.1. User-Authorization-Request (UAR) Command ..................22
      8.2. User-Authorization-Answer (UAA) Command ...................23
      8.3. Server-Assignment-Request (SAR) Command ...................27
      8.4. Server-Assignment-Answer (SAA) Command ....................29
      8.5. Location-Info-Request (LIR) Command .......................33
      8.6. Location-Info-Answer (LIA) Command ........................33
      8.7. Multimedia-Auth-Request (MAR) Command .....................35
      8.8. Multimedia-Auth-Answer (MAA) Command ......................36
      8.9. Registration-Termination-Request (RTR) Command ............39
      8.10. Registration-Termination-Answer (RTA) Command ............39
      8.11. Push-Profile-Request (PPR) Command .......................41
      8.12. Push-Profile-Answer (PPA) Command ........................42
   9. Diameter SIP Application AVPs ..................................44
      9.1. SIP-Accounting-Information AVP ............................46
           9.1.1. SIP-Accounting-Server-URI AVP ......................47
           9.1.2. SIP-Credit-Control-Server-URI AVP ..................47
      9.2. SIP-Server-URI AVP ........................................47
      9.3. SIP-Server-Capabilities AVP ...............................47
           9.3.1. SIP-Mandatory-Capability AVP .......................48
           9.3.2. SIP-Optional-Capability AVP ........................48
      9.4. SIP-Server-Assignment-Type AVP ............................48
      9.5. SIP-Auth-Data-Item AVP ....................................50
           9.5.1. SIP-Authentication-Scheme AVP ......................50
           9.5.2. SIP-Item-Number AVP ................................51
           9.5.3. SIP-Authenticate AVP ...............................51
           9.5.4. SIP-Authorization AVP ..............................52
           9.5.5. SIP-Authentication-Info AVP ........................52
           9.5.6. Digest AVPs ........................................53
      9.6. SIP-Number-Auth-Items AVP .................................55

Top      ToC       Page 3 
      9.7. SIP-Deregistration-Reason AVP .............................55
           9.7.1. SIP-Reason-Code AVP ................................55
           9.7.2. SIP-Reason-Info AVP ................................56
      9.8. SIP-AOR AVP ...............................................56
      9.9. SIP-Visited-Network-Id AVP ................................56
      9.10. SIP-User-Authorization-Type AVP ..........................56
      9.11. SIP-Supported-User-Data-Type AVP .........................57
      9.12. SIP-User-Data AVP ........................................57
           9.12.1. SIP-User-Data-Type AVP ............................58
           9.12.2. SIP-User-Data-Contents AVP ........................58
      9.13. SIP-User-Data-Already-Available AVP ......................58
      9.14. SIP-Method AVP ...........................................59
   10. New Values for Existing AVPs ..................................59
      10.1. Extension to the Result-Code AVP Values ..................59
           10.1.1. Success Result-Code AVP Values ....................59
           10.1.2. Transient Failures Result-Code AVP Values .........60
           10.1.3. Permanent Failures Result-Code AVP Values .........60
   11. Authentication Details ........................................61
   12. Migration from RADIUS .........................................63
      12.1. Gateway from RADIUS Client to Diameter Server ............63
      12.2. Gateway from Diameter Client to RADIUS Server ............63
      12.3. Known Limitations ........................................64
   13. IANA Considerations ...........................................64
      13.1. Application Identifier ...................................64
      13.2. Command Codes ............................................65
      13.3. AVP Codes ................................................65
      13.4. Additional Values for the Result-Code AVP Value ..........65
      13.5. Creation of the SIP-Server-Assignment-Type
            Section in the AAA .......................................66
      13.6. Creation of the SIP-Authentication-Scheme Section
            in the AAA ...............................................66
      13.7. Creation of the SIP-Reason-Code Section in the
            AAA Registry .............................................66
      13.8. Creation of the SIP-User-Authorization-Type
            Section in the AAA .......................................66
      13.9. Creation of the SIP-User-Data-Already-Available
            Section in the ...........................................66
   14. Security Considerations .......................................67
      14.1. Final Authentication Check in the Diameter
            Client/SIP Server ........................................67
   15. Contributors ..................................................68
   16. Acknowledgements ..............................................68
   17. References ....................................................68
      17.1. Normative References .....................................68
      17.2. Informative References ...................................69

Top      ToC       Page 4 
1.  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 SIP-based IP multimedia services
   (see [RFC3261] about SIP).  Furthermore, this Diameter SIP
   application provides the Diameter client with functions that go
   beyond the typical authorization and authentication, such as the
   ability to download or receive updated user profiles, or rudimentary
   routing functions that can assist a SIP server in finding another SIP
   server allocated to the user.

   We assume that the SIP server (such as SIP proxy server, registrar,
   redirect server, or alike) and the Diameter client are co-located in
   the same node, so that the SIP server is able to receive and process
   SIP requests and responses.  In turn, the SIP server relies on the
   Authentication, Authorization, and Accounting (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.

   This application does not require and is not related to other
   authentication services provided by the Diameter Mobile IPv4
   [RFC4004] or the Diameter Network Access Server [RFC4005]
   applications.

   This Diameter SIP application is loosely related to the Diameter
   credit-control application [RFC4006].  Although both applications are
   independent, the Diameter SIP application is able to supply the
   addresses of credit-control servers that will be implementing the
   Diameter credit-control application [RFC4006].

   Section 5 discusses assumptions and configurations assumed by this
   document.

   Section 6 provides the reader with informative descriptions of the
   Diameter SIP application commands and responses and with some
   guidance about their linkage with SIP procedures.

Top      ToC       Page 5 
   Advertisement of this application is specified in Section 7.

   Section 8 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
   Section 10.

   This application defines some new AVPs.  All these AVPs are described
   in Section 9.

   Some extra information about authentication is provided in
   Section 11.

2.  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 [RFC2119] and indicate requirement
   levels for compliant implementations.

3.  Definitions

   For the purpose of this document, the following terms and definitions
   apply:

   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 [RFC3261] Section 6, apply:

   o  Address-of-Record (AOR)
   o  Outbound proxy
   o  Proxy
   o  Registrar
   o  Server (SIP server)
   o  User Agent (UA)
   o  User Agent Client (UAC)
   o  User Agent Server (UAS)

   For the purpose of this document, the following terms and definitions
   given in RFC 3588 [RFC3588] Section 1.3, apply:

Top      ToC       Page 6 
   o  Authorization
   o  Authentication
   o  Attribute-Value Pair (AVP)
   o  Diameter Client
   o  Diameter Server
   o  Home Realm
   o  Redirect Agent
   o  User

4.  Acronyms

   AKA:  Authentication and Key Agreement
   LIR:  Location-Info-Request
   LIA:  Location-Info-Answer
   MAR:  Multimedia-Auth-Request
   MAA:  Multimedia-Auth-Answer
   PPR:  Push-Profile-Request
   PPA:  Push-Profile-Answer
   RTR:  Registration-Termination-Request
   RTA:  Registration-Termination-Answer
   SAR:  Server-Assignment-Request
   SAA:  Server-Assignment-Answer
   SL:   Subscriber Locator
   UAR:  User-Authorization-Request
   UAA:  User-Authorization-Answer

5.  Applicability Statement

   This document assumes a general architecture where a Home Realm is
   composed of one or more nodes implementing Diameter or SIP functions.
   Users are issuing SIP requests to access SIP resources.  For each
   particular user, the Home Realm needs to authenticate and authorize
   the usage of those resources and/or the route to the appropriate
   node.  We assume that the database containing the user-related data
   is located outside the SIP node that requires authorization.  Data
   belonging to different users may be stored in different nodes in the
   Home Realm, but we assume that all the data related to a particular
   user is stored in a single node.

      Note: 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 is seen, from the external point of view, as a
      single user database.

Top      ToC       Page 7 
   This document allows several configurations of the Home Realm.  In
   one configuration, a SIP server (proxy, registrar, etc.) 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 that 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 User Agent.  The outbound Diameter client in the SIP outbound
   proxy node authenticates the user, requests authorization for SIP
   requests, and performs accounting activities.

6.  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.  We provide a collection of examples that show how
   the required AAA functionality can be achieved in conjunction with
   SIP.

6.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 and
   authorize the usage of SIP resources.  This application provides
   support for SIP User Agents and proxies that implement and use HTTP
   Digest authentication [RFC2617], which is the authentication
   mechanism mandated by SIP [RFC3261].  The application is extensible
   and, if need arises, it can be extended to provide support for other
   authentication mechanisms or extensions to HTTP Digest authentication
   when they occur.

   This application provides limited support for accounting services as
   follows: the Diameter server is able to provide the addresses of
   accounting severs to the Diameter client.  Figure 1, below, shows a
   general overview of the integration of the SIP architecture with the
   AAA architecture.

   According to Figure 1, there are one or more SIP User Agents (UAs)
   that initiate or terminate SIP traffic through one or more SIP
   servers.  Both SIP servers implement a Diameter client that supports
   the Diameter application described in this specification.

Top      ToC       Page 8 
                               +--------+
                  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 |                   |
                  LIR/LIA |                   | MAR/MAA
                          |    +--------+     | SAR/SAA
                          +--->|Diameter|<----+
                               |   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 than 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.

   This Diameter application assumes that all the data pertaining to a
   given user is stored in a single Diameter server.  For redundancy
   purposes, several Diameter servers can be configured in a redundancy
   fashion, in which case all of them keep the data synchronized and
   operate externally as a single Diameter server.

   With respect to SIP server 1 in Figure 1, the Diameter SIP
   application provides support for the existence of a farm of these
   servers, typically configured through one or more DNS records that
   point to several hosts (this is a typical configuration in common SIP
   deployments).  There is no requirement for these types of servers to
   keep state related to the Diameter SIP application.

   The Diameter SIP application provides support for a feature that
   allows an administrative domain to provide a collection of SIP
   servers 2 (as per Figure 1).  Once the user registers for the first
   time, one of these SIP servers is selected and all the SIP requests
   related to the user are processed by the same SIP server.

Top      ToC       Page 9 
   The Diameter Subscriber Locator (SL) serves the purpose of locating
   the Diameter server that contains the user-related data.  Its
   functionality is based on the Diameter redirect mechanism and is
   further described in Section 6.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.

6.2.  Diameter Server Authenticates the User

   This is the generic mechanism to authenticate users.  In this
   approach, we show an example of an administrative network where the
   Diameter server is authenticating SIP 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.

Top      ToC       Page 10 
                    +--------+           +--------+         +--------+
                    |  SIP   |           |Diameter|         |  SIP   |
                    |server 1|           | server |         |server 2|
                    +--------+           +--------+         +--------+
                         |                   |                   |
    1. SIP REGISTER      |                   |                   |
    -------------------->|     2. UAR        |                   |
                         |------------------>|                   |
                         |     3. UAA        |                   |
                         |<------------------|                   |
                         |         4. SIP REGISTER               |
                         |-------------------------------------->|
                         |                   |      5. MAR       |
                         |                   |<------------------|
                         |                   |      6. MAA       |
                         |                   |------------------>|
                         |         7. SIP 401 (Unauthorized)     |
    8. SIP 401 (Unauth.) |<--------------------------------------|
    <--------------------|                   |                   |
    9. SIP REGISTER      |                   |                   |
    -------------------->|     10. UAR       |                   |
                         |------------------>|                   |
                         |     11. UAA       |                   |
                         |<------------------|                   |
                         |         12. SIP REGISTER              |
                         |-------------------------------------->|
                         |                   |      13. MAR      |
                         |                   |<------------------|
                         |                   |      14. MAA      |
                         |                   |------------------>|
                         |         15. SIP 200 (OK)              |
    16. SIP 200 (OK)     |<--------------------------------------|
    <--------------------|                   |                   |
                         |                   |      17. SAR      |
                         |                   |<------------------|
                         |                   |      18. SAA      |
                         |                   |------------------>|
                         |                   |                   |

         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 SIP server 1, which receives the SIP
   request.  In Figure 2, we assume that this SIP server is located at
   the edge of the administrative home domain.  The Diameter client in
   SIP server 1 contacts 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

Top      ToC       Page 11 
   address of a local SIP server capable of handling this user.  The
   Diameter server answers with a Diameter User-Authorization-Answer
   (UAA) message (step 3), which indicates a list of capabilities that
   SIP server 1 may use to select an appropriate SIP server (SIP server
   2) and/or a SIP or SIPS URI pointing to SIP server 2.

   SIP server 1 forwards the SIP REGISTER request (step 4) to an
   appropriate SIP server (SIP server 2).  Then the Diameter client in
   SIP server 2 requests user authentication from the Diameter server by
   sending a Diameter Multimedia-Auth-Request (MAR) message (step 5).
   This request also serves 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 responds
   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 also generates a nonce and includes a challenge in
   the MAA message.  SIP server 2 uses that challenge to map into the
   WWW-Authenticate 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 receives 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
   arrives 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 contacts the Diameter server by sending a Diameter
   UAR message (step 10) to determine the SIP server allocated to the
   user.  The Diameter server sends the SIP or SIPS URI of SIP server 2
   in a Diameter UAA message (step 11).

   Then SIP server 1 forwards the SIP REGISTER request to SIP server 2
   (step 12).  SIP server 2 extracts the credentials from the SIP
   REGISTER request.  The Diameter client in SIP server 2 sends those
   credentials in a Diameter MAR message (step 13) to the Diameter
   server.  At this point, the Diameter server is able to authenticate
   the user, and upon success, returns a Diameter MAA message (step 14)
   with the AVP Result-Code set to the value DIAMETER_SUCCESS.

   Then SIP server 2 generates 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 or is required to store the address of
   the SIP server in the Diameter server, then the Diameter client sends
   a Diameter SAR message (step 17) to the Diameter server.  The
   Diameter server replies with a Diameter SAA message (step 18) that
   contains the requested user profile information and the

Top      ToC       Page 12 
   acknowledgement of the SIP server address storage.  These actions are
   needed when the SIP server has to retrieve a user profile used to
   provide services to the served user, or when the SIP server keeps a
   state for the user, so the Diameter server needs to store the SIP
   server's address.

6.3.  Delegating Final Authentication Check to the SIP Server

   An operator with a large base of installed SIP servers may wish to
   minimize the number of round-trips between the Diameter client and
   the Diameter server.  We provide support for a mechanism where the
   Diameter server delegates the final authentication check to the SIP
   server, thereby saving a round-trip.  Section 14.1 discusses the
   security considerations of this scenario.

   It must noted that this scenario is not applicable when the Diameter
   server is configured to use a session MD5 (MD5-sess) algorithm,
   because the Diameter server requires the client nonce to compute the
   H(A1) before sending it to the Diameter client.  However, the client
   nonce might not be available at that time.

Top      ToC       Page 13 
                    +--------+           +--------+         +--------+
                    |  SIP   |           |Diameter|         |  SIP   |
                    |server 1|           | server |         |server 2|
                    +--------+           +--------+         +--------+
                         |                   |                   |
    1. SIP REGISTER      |                   |                   |
    -------------------->|     2. UAR        |                   |
                         |------------------>|                   |
                         |     3. UAA        |                   |
                         |<------------------|                   |
                         |         4. SIP REGISTER               |
                         |-------------------------------------->|
                         |                   |      5. MAR       |
                         |                   |<------------------|
                         |                   |      6. MAA       |
                         |                   |------------------>|
                         |         7. SIP 401 (Unauthorized)     |
    8. SIP 401 (Unauth.) |<--------------------------------------|
    <--------------------|                   |                   |
    9. SIP REGISTER      |                   |                   |
    -------------------->|     10. UAR       |                   |
                         |------------------>|                   |
                         |     11. UAA       |                   |
                         |<------------------|                   |
                         |         12. SIP REGISTER              |
                         |-------------------------------------->|
                         |                   |      13. SAR      |
                         |                   |<------------------|
                         |                   |      14. SAA      |
                         |                   |------------------>|
                         |         15. SIP 200 (OK)              |
    16. SIP 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 Multimedia Core Network
   Subsystem.

   A first SIP server receives a SIP REGISTER request (step 1) whose
   target is the home network domain.  In Figure 3, we assume that this
   SIP server is located 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

Top      ToC       Page 14 
   Diameter User-Authorization-Request (UAR) message (step 2).  The
   message includes, among other Attribute-Value-Pairs (AVPs), the SIP
   Address-Of-Record (AOR) that is included in the SIP REGISTER request.
   The Diameter server verifies the SIP AOR and, if it is a valid
   defined user in the home network, authorizes the registration to
   proceed.  The Diameter server responds with a Diameter
   User-Authorization-Answer (UAA) message (step 3), which informs the
   Diameter client/SIP server about the result of the user
   authorization.  In case of a successful authorization, the Diameter
   UAA message indicates the address of a local SIP server (SIP server 2
   in Figure 3) and/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 forwards the SIP
   REGISTER request (step 4) to the appropriate SIP server (SIP server
   2).  The Diameter client in SIP server 2 requests authentication
   parameters by sending a Diameter Multimedia-Auth-Request (MAR)
   message (step 5) to the Diameter server.  This request also makes 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 responds with a Diameter
   Multimedia-Auth-Answer (MAA) message (step 6), which includes a nonce
   and all the rest of the parameters necessary for the designated
   authentication algorithm associated with the user.  Among others, the
   MAA message includes a Digest-HA1 AVP that contains H(A1) (as defined
   in RFC 2617 [RFC2617]), and that allows the Diameter client to
   calculate the expected response.  Then the Diameter client can
   compare this expected response with the response to the challenge
   sent from the SIP UA.  The absence of the Digest-HA1 AVP in MAA
   indicates that authentication and authorization take place in the
   Diameter server, as per the scenario described in Section 6.2.

   SIP server 2 creates a SIP 401 (Unauthorized) SIP response (step 7)
   based on the challenge included in the MAA message, 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).

   The SIP server 1 receives the next SIP REGISTER request containing
   the user credentials (step 9).  Because SIP server 1 does not need to
   keep a state (and there is no guarantee that the SIP request arrives
   to the same SIP server 1), the Diameter client in SIP server 1
   contacts the Diameter server again by sending a Diameter UAR message
   (step 10) to determine the SIP server allocated to the user.  The
   Diameter server sends the SIP or SIPS URI of SIP server 2 in a
   Diameter UAA message (step 11).

Top      ToC       Page 15 
   SIP server 1 forwards the SIP REGISTER request to SIP server 2 (step
   12).  SIP server 2 validates the credentials by comparing the
   response supplied by the SIP UA with the expected response calculated
   by the SIP server 2 (based on the H(A1) received from the Diameter
   server).

   If the credentials are valid, SIP server 2 sends a Diameter
   Server-Assignment-Request (SAR) message (step 13) requesting the
   Diameter server to confirm the completion of the authentication
   procedure and to confirm the SIP or SIPS URI of the SIP server that
   is currently serving the user.  The Diameter SAR message also serves
   the purpose of requesting that the Diameter server send the user
   profile to the SIP server.  The Diameter server responds with a
   Diameter Server-Assignment-Answer (SAA) message (step 14).  If the
   Result-Code AVP value does not inform SIP Server 2 of an error, the
   SAA message can include zero or more SIP-User-Data AVPs containing
   the information that SIP server 2 needs in order to provide a service
   to the user.

   SIP server 2 generates a SIP 200 (OK) response (step 15), which is
   forwarded to SIP server 1 and eventually to the SIP UAC (step 16).

6.4.  SIP Server Requests Authentication and Authorization

   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 generates a nonce and sends a
   Multimedia-Auth-Answer (MAA) message (step 3) that includes the nonce
   and the rest of the data necessary for the SIP server to challenge
   the user, typically with HTTP Digest Authentication indicated in the
   MAA message.  This data enables the SIP server to create a SIP 407
   (Proxy Authentication Required) response (step 4) that contains a
   challenge.  The SIP UA creates a new INVITE request (step 5) that
   contains the credentials.  The Diameter client in the SIP server
   sends the credentials to the Diameter server in a new Diameter MAR
   message (step 6).  The Diameter server validates the credentials and

Top      ToC       Page 16 
   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 is confirmed with a SIP 200 (OK) response (step 9) that is
   forwarded to the SIP UA (step 10).  The session setup is complete.

                +--------+         +--------+
                |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 requests authorization

6.5.  Locating the Recipient of the SIP Request

   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 recipient of the SIP request.  The Diameter client in SIP server
   1 sends a 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

Top      ToC       Page 17 
   SIPS URI of SIP server 2.  SIP server 1 then forwards the SIP INVITE
   to SIP server 2 (step 4).  SIP server 2 eventually forwards the SIP
   INVITE to the appropriate UAS (step 5).

             +--------+         +--------+      +--------+
             |  SIP   |         |Diameter|      |  SIP   |
             |server 1|         | server |      |server 2|
             +--------+         +--------+      +--------+
                  |                 |                |
   1. SIP INVITE  |                 |                |
   -------------->|     2. LIR      |                |
                  |---------------->|                |
                  |     3. LIA      |                |
                  |<----------------|                |
                  |         4. SIP INVITE            |
                  |--------------------------------->|
                  |                 |                | 5. SIP INVITE
                  |                 |                |-------------->
                  |                 |                |
                  |                 |                |

            Figure 5: Locating the SIP server of the recipient

   Although the example shows the connection between a SIP INVITE
   request and the Diameter LIR message, any 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 Figure 2 and Figure 3.)

   The scenario described in this section is also applicable in case an
   outbound SIP server is not interested in authenticating the user, but
   is required to locate a further SIP server to route the outbound SIP
   requests.  In this case, the outbound SIP server is mapped to SIP
   server 1 as shown in Figure 5.

6.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 to the
   Diameter Server-Assignment-Answer (SAA) message.  This is valid for
   most of the daily situations; however, the administrator may decide
   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

Top      ToC       Page 18 
   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.  When the user profile
   changes, the Diameter server sends 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 contains one or more SIP-User-Data AVPs, a User-Name AVP
   and zero or more SIP-AOR AVPs.  The Diameter client in SIP server 2
   acknowledges the Diameter PPR message by sending a Diameter
   Push-Profile-Answer (PPA) message (step 2) to the Diameter server.

                   +--------+          +--------+
                   |Diameter|          |  SIP   |
                   | server |          |server 2|
                   +--------+          +--------+
                       |                   |
                       |     1. PPR        |
                       |------------------>|
                       |                   |
                       |     2. PPA        |
                       |<------------------|
                       |                   |

      Figure 6: Diameter server pushes an update of the user profile

6.7.  SIP Soft State Termination

   SIP can create soft states in SIP nodes based on events such as SIP
   registrations or SIP event subscriptions.  These states are
   periodically refreshed, and cease to exist if they are not refreshed.
   Additionally, an administrative action can be taken to terminate a
   SIP soft state, or the SIP UA can explicitly terminate a SIP soft
   state.

   The Diameter base protocol offers a mechanism to create and delete
   states in Diameter nodes.  These states are called Diameter user
   sessions.  The Diameter server decides whether to use a Diameter user
   session as a mechanism to map to a SIP soft state.  If the Diameter
   server decides to use Diameter user sessions, the termination of a
   Diameter user session implies the termination of the corresponding
   SIP soft state (e.g., registration, event subscription), and vice
   versa.  If the Diameter server does not use Diameter user sessions,
   this Diameter SIP application offers specific commands to manage the
   SIP soft states.  Implementations compliant with this specification
   MUST support both mechanisms of session management.

Top      ToC       Page 19 
   We provide support for both Diameter client- and Diameter
   server-initiated session termination.  Depending on whether Diameter
   sessions are used, termination of a SIP soft state can be achieved by
   one of the following methods:

   o  When the Diameter client (SIP proxy) wants to terminate the SIP
      soft state and Diameter user sessions are not maintained (i.e.,
      the Auth-Session-State AVP has been previously set to
      NO_STATE_MAINTAINED), the Diameter client MUST send a
      Server-Assignment-Request (SAR) message with the
      SIP-Server-Assignment-Type AVP (Section 9.4) set to any of the
      deregistration values:  TIMEOUT_DEREGISTRATION,
      USER_DEREGISTRATION, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME,
      USER_DEREGISTRATION_STORE_SERVER_NAME,
      ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA.

   o  When the Diameter client (SIP proxy) wants to terminate the SIP
      soft state and Diameter user sessions are maintained (i.e., the
      Auth-Session-State AVP has been previously set to
      STATE_MAINTAINED), the Diameter client MUST send a Session-
      Termination-Request (STR) message as per regular procedures
      according to RFC 3588 [RFC3588].

   o  When the Diameter server wants to terminate the SIP soft state and
      Diameter user sessions are not maintained (i.e., the
      Auth-Session-State AVP has been previously set to
      NO_STATE_MAINTAINED), the Diameter server MUST send a
      Registration-Termination-Request (RTR) message (see Section 8.9).

   o  When the Diameter server wants to terminate the SIP soft state and
      Diameter user sessions are maintained (i.e., the
      Auth-Session-State AVP has been previously set to
      STATE_MAINTAINED), the Diameter server MUST send an
      Abort-Session-Request (ASR) message as per regular procedures
      according to RFC 3588 [RFC3588].

6.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.
   Contrary to general opinion, this does not create a single point of
   failure.  It is assumed that Diameter servers are configured in a
   redundant fashion in 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 with a user is still stored in one Diameter

Top      ToC       Page 20 
   server (typically, operating in a redundant configuration), but the
   data associated with different users may reside in different Diameter
   servers.

   Although this configuration scales well, it introduces a new problem,
   namely: given the user's 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 with inspiration from the Diameter
   redirection mechanism specified in RFC 3588 [RFC3588].  We include in
   the architecture a new Diameter node that, for the purpose of this
   document, is known as Diameter Subscriber Locator (SL).  The Diameter
   SL contains a database or routing tables that map SIP AORs to
   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 SL acts in a similar way to a Diameter Redirect
   Agent, dispatching Diameter requests (e.g., providing the redirection
   URI in the answer).  The Diameter SL can redirect all the request
   pertaining to a user by setting the Redirect-Host-Usage AVP with a
   value ALL_USER, as specified in RFC 3588 [RFC3588].

   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 equal Diameter requests will produce
   equal Diameter answers, no matter which Diameter SL processes the
   request.

           +--------+   +--------+  +--------+  +--------+
           |  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

Top      ToC       Page 21 
   Figure 7 shows an example of operation of a Diameter SL acting in
   redirect mode.  SIP server 1 receives 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 possess routing information.  In
   other words, the Diameter client in SIP server 1 does not know the
   URI of the 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 Redirect-Host AVP,
   whose value is set to the URI of the Diameter server that stores the
   information related to such user.  Then the Diameter client in SIP
   server 1 builds a new LIR message (step 4) addressed to the Diameter
   server received in the Redirect-Host AVP.  The rest of the procedure
   is completed as described in previous sections.



(page 21 continued on part 2)

Next RFC Part