AAA Working Group                                  M. Garcia-Martin, Ed.
Internet-Draft                                                     Nokia
Expires: March 25, 2006                                     M. Belinchon
                                                       M. Pallares-Lopez
                                                              C. Canales
                                                                Ericsson
                                                                K. Tammi
                                                                   Nokia
                                                      September 21, 2005


         Diameter Session Initiation Protocol (SIP) Application
                   draft-ietf-aaa-diameter-sip-app-08

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 March 25, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 1]


Internet-Draft          Diameter SIP Application          September 2005


   information.  This application is designed to be used in conjunction
   with the Session Initiation Protocol (SIP), and provides a Diameter
   client in a SIP server with the ability to request a Diameter server
   the authentication of users and authorization of SIP resources usage.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  7
   5.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  7
     5.1.  General Architecture . . . . . . . . . . . . . . . . . . .  8
     5.2.  Modes of operation . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Diameter Server Authenticates the User, nonce
           generated in the Diameter server . . . . . . . . . . . . .  9
     5.4.  Delegating Final Authentication Check to the SIP
           Server, nonce generated in the Diameter server . . . . . . 13
     5.5.  SIP Server Requests Authentication and Authorization,
           nonce generated in the Diameter server . . . . . . . . . . 16
     5.6.  SIP Server Requests Authentication and Authorization,
           nonce generated in the Diameter client . . . . . . . . . . 17
     5.7.  Locating the recipient of the SIP request  . . . . . . . . 19
     5.8.  Update of the User Profile . . . . . . . . . . . . . . . . 19
     5.9.  SIP Soft State Termination . . . . . . . . . . . . . . . . 20
     5.10. Diameter Server Discovery  . . . . . . . . . . . . . . . . 21
   6.  Advertising Application Support  . . . . . . . . . . . . . . . 23
   7.  Diameter SIP Application Command Codes . . . . . . . . . . . . 24
     7.1.  User-Authorization-Request (UAR) Command . . . . . . . . . 24
     7.2.  User-Authorization-Answer (UAA) Command  . . . . . . . . . 25
     7.3.  Server-Assignment-Request (SAR) Command  . . . . . . . . . 29
     7.4.  Server-Assignment-Answer (SAA) Command . . . . . . . . . . 31
     7.5.  Location-Info-Request (LIR) Command  . . . . . . . . . . . 35
     7.6.  Location-Info-Answer (LIA) Command . . . . . . . . . . . . 36
     7.7.  Multimedia-Auth-Request (MAR) Command  . . . . . . . . . . 37
     7.8.  Multimedia-Auth-Answer (MAA) Command . . . . . . . . . . . 39
     7.9.  Registration-Termination-Request (RTR) Command . . . . . . 42
     7.10. Registration-Termination-Answer (RTA) Command  . . . . . . 42
     7.11. Push-Profile-Request (PPR) Command . . . . . . . . . . . . 44
     7.12. Push-Profile-Answer (PPA) Command  . . . . . . . . . . . . 46
   8.  Diameter SIP Application AVPs  . . . . . . . . . . . . . . . . 47
     8.1.  SIP-Accounting-Information AVP . . . . . . . . . . . . . . 49
       8.1.1.  SIP-Accounting-Server-URI AVP  . . . . . . . . . . . . 50
       8.1.2.  SIP-Credit-Control-Server-URI AVP  . . . . . . . . . . 50
     8.2.  SIP-Server-URI AVP . . . . . . . . . . . . . . . . . . . . 50
     8.3.  SIP-Server-Capabilities AVP  . . . . . . . . . . . . . . . 50
       8.3.1.  SIP-Mandatory-Capability AVP . . . . . . . . . . . . . 51



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 2]


Internet-Draft          Diameter SIP Application          September 2005


       8.3.2.  SIP-Optional-Capability AVP  . . . . . . . . . . . . . 51
     8.4.  SIP-Server-Assignment-Type AVP . . . . . . . . . . . . . . 51
     8.5.  SIP-Auth-Data-Item AVP . . . . . . . . . . . . . . . . . . 52
       8.5.1.  SIP-Authentication-Scheme AVP  . . . . . . . . . . . . 53
       8.5.2.  SIP-Item-Number AVP  . . . . . . . . . . . . . . . . . 53
       8.5.3.  SIP-Authenticate AVP . . . . . . . . . . . . . . . . . 54
       8.5.4.  SIP-Authorization AVP  . . . . . . . . . . . . . . . . 54
       8.5.5.  SIP-Authentication-Info AVP  . . . . . . . . . . . . . 55
       8.5.6.  Digest AVPs  . . . . . . . . . . . . . . . . . . . . . 56
     8.6.  SIP-Number-Auth-Items AVP  . . . . . . . . . . . . . . . . 57
     8.7.  SIP-Deregistration-Reason AVP  . . . . . . . . . . . . . . 58
       8.7.1.  SIP-Reason-Code AVP  . . . . . . . . . . . . . . . . . 58
       8.7.2.  SIP-Reason-Info AVP  . . . . . . . . . . . . . . . . . 58
     8.8.  SIP-AOR AVP  . . . . . . . . . . . . . . . . . . . . . . . 58
     8.9.  SIP-Visited-Network-Id AVP . . . . . . . . . . . . . . . . 59
     8.10. SIP-User-Authorization-Type AVP  . . . . . . . . . . . . . 59
     8.11. SIP-Supported-User-Data-Type AVP . . . . . . . . . . . . . 60
     8.12. SIP-User-Data AVP  . . . . . . . . . . . . . . . . . . . . 60
       8.12.1. SIP-User-Data-Type AVP . . . . . . . . . . . . . . . . 60
       8.12.2. SIP-User-Data-Contents AVP . . . . . . . . . . . . . . 61
     8.13. SIP-User-Data-Already-Available AVP  . . . . . . . . . . . 61
     8.14. SIP-Method AVP . . . . . . . . . . . . . . . . . . . . . . 61
   9.  New Values for Existing AVPs . . . . . . . . . . . . . . . . . 62
     9.1.  Extension to the Result-Code AVP Values  . . . . . . . . . 62
       9.1.1.  Success Result-Code AVP Values . . . . . . . . . . . . 62
       9.1.2.  Transient Failures Result-Code AVP Values  . . . . . . 62
       9.1.3.  Permanent failures Result-Code AVP Values  . . . . . . 63
   10. Authentication Details . . . . . . . . . . . . . . . . . . . . 64
     10.1. Generation of nonces . . . . . . . . . . . . . . . . . . . 65
   11. Migration from RADIUS  . . . . . . . . . . . . . . . . . . . . 66
     11.1. Gateway from RADIUS Client to Diameter Server  . . . . . . 66
     11.2. Gateway from Diameter Client to RADIUS Server  . . . . . . 67
     11.3. Known Limitations  . . . . . . . . . . . . . . . . . . . . 67
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 67
     12.1. Application Identifier . . . . . . . . . . . . . . . . . . 68
     12.2. Command Codes  . . . . . . . . . . . . . . . . . . . . . . 68
     12.3. AVP Codes  . . . . . . . . . . . . . . . . . . . . . . . . 68
     12.4. Additional Values for the Result-Code AVP Value  . . . . . 68
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 69
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 69
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
   16. Changes With Respect Previous Versions . . . . . . . . . . . . 70
     16.1. Changes in draft-ietf-aaa-diameter-sip-app-08.txt from
           -08.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 70
     16.2. Changes in draft-ietf-aaa-diameter-sip-app-07.txt from
           -06.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 70
     16.3. Changes in draft-ietf-aaa-diameter-sip-app-06.txt from
           -05.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 71



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 3]


Internet-Draft          Diameter SIP Application          September 2005


     16.4. Changes in draft-ietf-aaa-diameter-sip-app-05.txt from
           -04.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 71
     16.5. Changes in draft-ietf-aaa-diameter-sip-app-04.txt from
           -03.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 72
     16.6. Changes in draft-ietf-aaa-diameter-sip-app-03.txt from
           -02.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 73
     16.7. Changes in draft-ietf-aaa-diameter-sip-app-02.txt from
           -01.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 73
     16.8. Changes in draft-ietf-aaa-diameter-sip-app-01.txt from
           -00.txt  . . . . . . . . . . . . . . . . . . . . . . . . . 73
     16.9. Changes in draft-ietf-aaa-diameter-sip-app-00.txt from
           draft-belinchon-aaa-diameter-mm-app-01.txt . . . . . . . . 74
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 75
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 75
     17.2. Informational References . . . . . . . . . . . . . . . . . 75
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
   Intellectual Property and Copyright Statements . . . . . . . . . . 79


































Garcia-Martin, et al.    Expires March 25, 2006                 [Page 4]


Internet-Draft          Diameter SIP Application          September 2005


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 [RFC2119] 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 [RFC3261] 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)*
   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:

   o  *Authorization*
   o  *Authentication*
   o  *AVP*
   o  *Diameter Client*
   o  *Diameter Server*
   o  *Home Realm*
   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



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 5]


Internet-Draft          Diameter SIP Application          September 2005


   (SIP) [RFC3261] based IP multimedia services.  We assume that the SIP
   server and the Diameter client are located in the same node, so that
   the SIP server is able to receive and process SIP requests and
   responses which in turn relies on the AAA infrastructure for
   authenticating the SIP request and authorizing the usage of
   particular SIP services.

   This document provides Diameter procedures to implement certain
   required functionality when SIP is the protocol chosen to initiate
   and tear-down multimedia sessions 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 or 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 4 discusses assumptions and configurations assumed by this
   document.

   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 specified in Section 6.

   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 Section 9.

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

   Some extra information about authentication is provided in
   Section 10.



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 6]


Internet-Draft          Diameter SIP Application          September 2005


4.  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 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.

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



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 7]


Internet-Draft          Diameter SIP Application          September 2005


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

   This application provides a limited support for accounting services,
   limited to the Diameter server being 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 is one or more SIP User Agents (UA) that
   initiate or terminate SIP traffic through one or more SIP servers.
   Both SIP servers implement a Diameter client that supports the
   Diameter application described in this specification.

                               +--------+
                  UAR/UAA +--->|Diameter|<----+ PPR/PPA
                  LIR/LIA |    | server |     | MAR/MAA
                          |    +--------+     | SAR/SAA
                          |                   | RTR/RTA
                          |                   |
                          v                   v
   +------+   SIP     +--------+    SIP   +--------+   SIP     +------+
   | SIP  |<--------->|  SIP   |<-------->|  SIP   |<--------->| SIP  |
   |  UA  |           |server 1|          |server 2|           |  UA  |
   +------+           +--------+          +--------+           +------+
                          ^                   ^
                  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 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



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 8]


Internet-Draft          Diameter SIP Application          September 2005


   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 based on the Diameter redirect mechanism, and is
   further described in Section 5.10.

   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.

5.2.  Modes of operation

   This Diameter application provides support for two modes of
   operation.  These modes of operation are related to the generation of
   nonces in HTTP Digest authentication.  HTTP Digest requires the
   authenticating server to generate a nonce.  In the case of the
   Diameter SIP application, the nonce can be generated either in the
   Diameter client (SIP server) or in the Diameter server.  A mixture of
   nonce generation is not supported.

   Whenever a SIP server receives a SIP request, it has to decide
   whether nonces for HTTP Digest authentication will be locally
   generated in the Diameter client or remotely in the Diameter server.
   This is a decision derived from a policy that is configured in the
   SIP server/Diameter server.  Note also that if HTTP Digest
   authentication using AKA [RFC3310] is going to be used, then the only
   possibility is to generate nonces in the Diameter server.
   Section 5.6 provides an example of a configuration to address this
   scenario.  Section 10.1 provides further normative details.

   Note that this memo does not mandate procedures for the SIP server/
   Diameter client with respect actions taken with SIP.  Therefore, the
   support for client-generated nonces does not require, in general,
   extra explanations.

5.3.  Diameter Server Authenticates the User, nonce generated in the
      Diameter server

   This is the generic mechanism to authenticate users where nonces are
   generated in the Diameter server as well.  In this approach we show
   an example of an administrative network where the Diameter server is



Garcia-Martin, et al.    Expires March 25, 2006                 [Page 9]


Internet-Draft          Diameter SIP Application          September 2005


   both generating nonces and 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.













































Garcia-Martin, et al.    Expires March 25, 2006                [Page 10]


Internet-Draft          Diameter SIP Application          September 2005


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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 11]


Internet-Draft          Diameter SIP Application          September 2005


   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) and/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 generate a
   nonce and include in the MAA message 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
   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 or requires to store the address of the
   SIP server in the Diameter server, then the Diameter client will send
   a Diameter SAR message (step 17) to the Diameter server.  The



Garcia-Martin, et al.    Expires March 25, 2006                [Page 12]


Internet-Draft          Diameter SIP Application          September 2005


   Diameter server will reply with a Diameter SAA message (step 18) that
   contains the requested user profile information and the
   acknowledgement of the SIP server address storage.  These actions are
   needed when the SIP server needs to retrieve a user profile used to
   provide services to the served user or when the SIP server will keep
   a state for the user, so the Diameter server needs to store its
   address.

5.4.  Delegating Final Authentication Check to the SIP Server, nonce
      generated in the Diameter 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 nonces
   are generated in the Diameter server, but the Diameter server
   delegates the final authentication check to the SIP server, saving a
   round trip.

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


























Garcia-Martin, et al.    Expires March 25, 2006                [Page 13]


Internet-Draft          Diameter SIP Application          September 2005


                    +--------+           +--------+         +--------+
                    |  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, nonce
   generated in the Diameter 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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 14]


Internet-Draft          Diameter SIP Application          September 2005


   the Diameter server to proceed with the registration, by sending a
   Diameter User-Authorization-Request (UAR) message (step 2).  The
   message includes, among other Attribute-Value-Pairs (AVP), the SIP
   address-of-record that is included in the SIP REGISTER request.  The
   Diameter server will verify the SIP address-of-record and, if it is a
   valid defined user in the home network, will authorize 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) 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 will forward the
   SIP REGISTER request (step 4) to the appropriate SIP server (SIP
   server 2).  The Diameter client in SIP server 2 first takes a
   decision, based on configuration, whether to operate in the mode
   where nonces are generated in the Diameter client or in the Diameter
   server 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 a nonce and all the rest
   of parameters necessary for the designated authentication algorithm
   associated with the user.  Among others, the MAA message will include
   a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617
   [RFC2617]), and allows the Diameter client to calculate the expected
   response.  Then the Diameter client can use this expected response to
   compare it with the response to the challenge sent from the SIP UA.
   If the Digest-HA1 AVP is not present in MAA, it indicates that
   authentication and authorization will take place in the Diameter
   server, as per the scenario described in Section 5.3.

   SIP server 2 will then create 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).

   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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 15]


Internet-Draft          Diameter SIP Application          September 2005


   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 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 will send 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 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 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) that will be
   forwarded to SIP server 1 and eventually to the SIP UAC (step 16).

5.5.  SIP Server Requests Authentication and Authorization, nonce
      generated in the Diameter server

   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.  In this scenario nonces are generated in the Diameter
   server.

   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 all 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 will serve the SIP server to
   create a SIP 407 (Proxy Authentication Required) response (step 4)



Garcia-Martin, et al.    Expires March 25, 2006                [Page 16]


Internet-Draft          Diameter SIP Application          September 2005


   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
   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, nonce generated in the
   Diameter server

5.6.  SIP Server Requests Authentication and Authorization, nonce
      generated in the Diameter client

   Figure 5 presents a variation of the scenario introduced in
   Section 5.5, where now the nonce is generated in the Diameter client



Garcia-Martin, et al.    Expires March 25, 2006                [Page 17]


Internet-Draft          Diameter SIP Application          September 2005


   rather than the Diameter server.  This scenario saves a round trip
   compared to the one in Section 5.5, although ths scenario is not
   compatible with HTTP Digest authentication using AKA [RFC3310].

   According to Figure 5, a SIP User Agent sends a SIP request to its
   outbound SIP proxy server.  We assume that this SIP request does not
   contain any credentials at this time.  The Diameter client locally
   generates a nonce and, together with the rest of the data, creates a
   challenge that is sent in a SIP 407 (Proxy Authentication Required)
   response (step 2).  The SIP UA will create a new INVITE request (step
   3) 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 4).  The Diameter server will validate the
   credentials and authorize the SIP transaction in a Diameter MAA
   message (step 5).  The SIP server forwards the SIP INVITE request to
   its destination (step 6) as per regular SIP procedures.  Eventually,
   the session setup will be confirmed with a SIP 200 (OK) response
   (step 7) that is forwarded to the SIP UA (step 8).  The session setup
   is complete.

                +--------+         +--------+
                |Diameter|         |  SIP   |
                | server |         | server |
                +--------+         +--------+
                    |                   |
                    |                   |
             1. SIP INVITE              |
    ----------------------------------->|
                    |                   |
             2. 407 Proxy
         Authentication Required)       |
    <-----------------------------------|
                    |                   |
             3. SIP INVITE              |
    ----------------------------------->|
                    |      4. MAR       |
                    |<------------------|
                    |      5. MAA       |
                    |------------------>| 6. SIP INVITE
                    |                   |---------------->
                    |                   | 8. SIP 200 (OK)
             8. SIP 200 (OK)            |<----------------
    <-----------------------------------|
                    |                   |

   Figure 5: SIP server requests authorization, nonce generated in the
   Diameter client




Garcia-Martin, et al.    Expires March 25, 2006                [Page 18]


Internet-Draft          Diameter SIP Application          September 2005


5.7.  Locating the recipient of the SIP request

   Figure 6 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 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).

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

   Figure 6: Locating the SIP server of the recipient

   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.

   The scenario described in this section is also applicable in case an
   outbound SIP server is interested not in authenticating the user, but
   requires 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 in Figure 6.

5.8.  Update of the User Profile

   The Diameter SIP application provides a mechanism for a Diameter



Garcia-Martin, et al.    Expires March 25, 2006                [Page 19]


Internet-Draft          Diameter SIP Application          September 2005


   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 7.  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 one or more 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
   server.

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

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

5.9.  SIP Soft State Termination

   SIP can create soft states in SIP nodes based on, e.g., 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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 20]


Internet-Draft          Diameter SIP Application          September 2005


   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 to this specification
   MUST support both mechanisms of session management.

   We provide support for both Diameter client and Diameter server
   initiated session termination.

   Depending on whether Diameter sessions are used or not, termination
   of a SIP soft state can be achieved by either of the following
   methods:

   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 set to the value DE-
   REGISTRATION.

   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 message as
   per regular procedures according to the RFC 3588 [RFC3588].

   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 message
   (see Section 7.9).

   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 message as per regular procedures
   according to the RFC 3588 [RFC3588].

5.10.  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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 21]


Internet-Draft          Diameter SIP Application          September 2005


   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 will be still stored in one
   Diameter server (typically operating in a redundant configuration).
   But the data associated with different users may reside in different
   Diameter servers.

   This configuration, although scales well, 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 by inspiring on 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, 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 in a
   similar way to a Diameter Redirect Agent, dispatching Diameter
   requests (e.g., providing the redirection URI in the answer).  The
   Diameter Subscriber Locator 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
   the equal Diameter answers no matter which Diameter SL processes the
   request.


















Garcia-Martin, et al.    Expires March 25, 2006                [Page 22]


Internet-Draft          Diameter SIP Application          September 2005


           +--------+   +--------+  +--------+  +--------+
           |  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 8: Locating a Diameter server. SL redirecting requests

   Figure 8 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
   (step 4) addressed to any of the Diameter servers received in the
   Redirect-Host AVPs.  The rest of procedure is completed as described
   in previous sections.


6.  Advertising Application Support

   Diameter implementations conforming to this specification MUST
   advertise its support by including an Auth-Application-Id AVP in the
   Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer



Garcia-Martin, et al.    Expires March 25, 2006                [Page 23]


Internet-Draft          Diameter SIP Application          September 2005


   (CEA) commands, according to the Diameter base protocol, RFC 3588
   [RFC3588].  This Auth-Application-Id AVP MUST be set to the value of
   this Diameter SIP application (Section 12.1 indicates the actual
   value allocated by IANA).


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
   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: Defined command codes

   [Note to IANA and the RFC editor: replace aaa, bbb, ccc, and so on
   with the actual values allocated to these commands.]

7.1.  User-Authorization-Request (UAR) Command

   The User-Authorization-Request (UAR) is indicated by the Command-Code
   set to aaa [Note to IANA and the RFC editor: replace aaa with the
   actual value allocated to this command] 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 permission 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.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 24]


Internet-Draft          Diameter SIP Application          September 2005


   The Diameter client in the SIP server will request authorization for
   one of the possible values defined 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 (defined in the Diameter base protocol, RFC 3588
   [RFC3588]).  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 [RFC2617], the authentication user name is found in the
   "username" directive of the SIP Authorization header field value.
   This Diameter SIP application only provides support for HTTP Digest
   authentication in SIP: other authentication mechanisms are not
   currently supported.

   The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP
   (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-Realm }
                 { SIP-AOR }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Visited-Network-Id ]
                 [ SIP-User-Authorization-Type ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace aaa with the actual value
   allocated to this command]

7.2.  User-Authorization-Answer (UAA) Command

   The User-Authorization-Answer (UAA) is indicated by the Command-Code
   set to aaa [Note to IANA and the RFC editor: replace aaa with the



Garcia-Martin, et al.    Expires March 25, 2006                [Page 25]


Internet-Draft          Diameter SIP Application          September 2005


   actual value allocated to this command] 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 server may
   indicate 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 [RFC3588], the
   Result-Code AVP may contain one of the values defined in Section 9.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
   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 Section 9.1.2) and return
   it in a Diameter UAA message.  Upon reception of this Diameter UAA
   message with the Result-Code AVP value set to
   DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request
   authentication by generating a SIP 401 (Unauthorized) or SIP 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 with 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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 26]


Internet-Draft          Diameter SIP Application          September 2005


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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 27]


Internet-Draft          Diameter SIP Application          September 2005


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











Garcia-Martin, et al.    Expires March 25, 2006                [Page 28]


Internet-Draft          Diameter SIP Application          September 2005


   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 ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace aaa with the actual value
   allocated to this command]

7.3.  Server-Assignment-Request (SAR) Command

   The Server-Assignment-Request (SAR) command is indicated by the
   Command-Code set to bbb [Note to IANA and the RFC editor: replace bbb
   with the actual value allocated to this command] and the Command
   Flags' 'R' bit set.  The Diameter client in a SIP server sends this
   command to the Diameter server to indicate the completion of the
   authentication process and to request the Diameter server to store
   the URI 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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 29]


Internet-Draft          Diameter SIP Application          September 2005


   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.

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

   The SAR message MAY contain zero or more SIP-Supported-User-Data-Type
   AVPs.  Each of them will contain a type of user data understood by
   the SIP server.  This allows the Diameter client to provide an
   indication to the Diameter server of the different format of user
   data understood by the SIP server.  The Diameter server will use this
   information to select one more SIP-User-Data AVPs that will be
   included in the SAA message.












Garcia-Martin, et al.    Expires March 25, 2006                [Page 30]


Internet-Draft          Diameter SIP Application          September 2005


   Message Format
       <SAR> ::= < Diameter Header: bbb, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-Server-Assignment-Type }
                 { SIP-User-Data-Already-Available }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
               * [ SIP-Supported-User-Data-Type ]
               * [ SIP-AOR ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace bbb with the actual value
   allocated to this command]

7.4.  Server-Assignment-Answer (SAA) Command

   The Server-Assignment-Answer (SAA) is indicated by the Command-Code
   set to bbb [Note to IANA and the RFC editor: replace bbb with the
   actual value allocated to this command] 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 [RFC3588], the
   Result-Code AVP may contain one of the values defined in Section 9.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 SAA message MAY include one more SIP-User-Data AVPs
   that will typically contain the profile of the user, indicating
   services that the SIP server can provide to that user.

   The Diameter server MAY include one or more SIP-Supported-User-Data-
   Type AVPs, each one identifying a type of user data format supported
   in the Diameter server.  If there is not a common supported user data
   type between the Diameter client and the Diameter server, the
   Diameter server SHOULD declare its list of supported user data types
   by including one or more SIP-Supported-User-Data-Type AVPs in a



Garcia-Martin, et al.    Expires March 25, 2006                [Page 31]


Internet-Draft          Diameter SIP Application          September 2005


   Diameter SAA message.  This indication is merely for debugging
   reasons, since there is not a fall-back mechanism that allows the
   Diameter client to retrieve the profile in a supported format.

   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 Section 9.1.2) and return
   it in a Diameter SAA message.  Upon reception of this Diameter SAA
   message with the Result-Code AVP value set to
   DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request
   authentication by generating a SIP 401 (Unauthorized) or SIP 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 the 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 and if the SIP-
      User-Data-Already-Available AVP value is set to
      USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
      one or more user profile data with the SIP or SIPS URI (SIP-AOR
      AVP) and all other SIP identities associated with that AVP in the
      SIP-User-Data AVP value of the Diameter SAA message.  On selecting
      the type of user data, the Diameter server SHOULD take into
      account the supported formats at the SIP server (SIP-Supported-
      User-Data-Type AVP in the SAR message) and the local policy.



Garcia-Martin, et al.    Expires March 25, 2006                [Page 32]


Internet-Draft          Diameter SIP Application          September 2005


      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
      Diameter Location-Info-Answer (LIA) messages.  If the SIP-User-
      Data-Already-Available AVP value is set to
      USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
      one or more 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.  On selecting the type of user
      data, the Diameter server SHOULD take into account the supported
      formats at the SIP server (SIP-Supported-User-Data-Type AVP in the
      SAR message) and the local policy.  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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 33]


Internet-Draft          Diameter SIP Application          September 2005


      (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,
      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 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, if the SIP-User-Data-Already-Available
      AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter
      server SHOULD include the user profile data with the SIP or SIPS
      URI (SIP-AOR AVP) and all other SIP identities associated with
      that AVP in the SIP-User-Data AVP value of the Diameter SAA
      message.  On selecting the type of user data, the Diameter server
      SHOULD take into account the supported formats at the SIP server
      (SIP-Supported-User-Data-Type AVP in the SAR message) and the
      local policy.
   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 exactly one 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.










Garcia-Martin, et al.    Expires March 25, 2006                [Page 34]


Internet-Draft          Diameter SIP Application          September 2005


   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-Accounting-Information ]
               * [ SIP-Supported-User-Data-Type ]
                 [ User-Name ]
                 [ Auth-Grace-Period ]
                 [ Authorization-Lifetime ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace bbb with the actual value
   allocated to this command]

7.5.  Location-Info-Request (LIR) Command

   The Location-Info-Request (LIR) is indicated by the Command-Code set
   to ccc [Note to IANA and the RFC editor: replace ccc with the actual
   value allocated to this command] 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-Realm }
                 { SIP-AOR }
                 [ Destination-Host ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]




Garcia-Martin, et al.    Expires March 25, 2006                [Page 35]


Internet-Draft          Diameter SIP Application          September 2005


   [Note to IANA and the RFC editor: replace ccc with the actual value
   allocated to this command]

7.6.  Location-Info-Answer (LIA) Command

   The Location-Info-Answer (LIA) is indicated by the Command-Code set
   to ccc [Note to IANA and the RFC editor: replace ccc with the actual
   value allocated to this command] 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 [RFC3588], the
   Result-Code AVP may contain one of the values defined in Section 9.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 LIR 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
   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:






Garcia-Martin, et al.    Expires March 25, 2006                [Page 36]


Internet-Draft          Diameter SIP Application          September 2005


   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.

   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 ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace ccc with the actual value
   allocated to this command]

7.7.  Multimedia-Auth-Request (MAR) Command

   The Multimedia-Auth-Request (MAR) command is indicated by the
   Command-Code set to ddd [Note to IANA and the RFC editor: replace ddd
   with the actual value allocated to this command] and the Command
   Flags' 'R' bit set.  The Diameter client in a SIP server sends this



Garcia-Martin, et al.    Expires March 25, 2006                [Page 37]


Internet-Draft          Diameter SIP Application          September 2005


   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 SAR command, MAR does not store any state in the
   Diameter server.

   The MAR command also registers the SIP server's own URI to the
   Diameter server, so that future LIR/LIA messages can return this URI.

   The SIP-Method AVP MUST include the SIP method name of the SIP
   request that triggered this Diameter MAR message.  The Diameter
   server can use this AVP to authorize some SIP requests depending on
   the method.

   The Diameter MAR message MUST include a SIP-AOR AVP.  The SIP-AOR AVP
   indicates the target of the SIP request.  The value of the AVP is
   extracted from different places in SIP request, 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.

















Garcia-Martin, et al.    Expires March 25, 2006                [Page 38]


Internet-Draft          Diameter SIP Application          September 2005


   Message Format
       <MAR> ::= < Diameter Header: ddd, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 { SIP-Method }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
                 [ SIP-Number-Auth-Items ]
                 [ SIP-Auth-Data-Item ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace ddd with the actual value
   allocated to this command]

7.8.  Multimedia-Auth-Answer (MAA) Command

   The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set
   to ddd [Note to IANA and the RFC editor: replace ddd with the actual
   value allocated to this command] 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 [RFC3588], the
   Result-Code AVP may contain one of the values defined in Section 9.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 Section 9.1.2) 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 reception of
   this Diameter MAA message with the Result-Code AVP value set to
   DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request
   authentication by generating a SIP 401 (Unauthorized) or SIP 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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 39]


Internet-Draft          Diameter SIP Application          September 2005


   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-Methods 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
   SIP-Authorization AVP value to synchronize the different
   authentication credentials.  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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 40]


Internet-Draft          Diameter SIP Application          September 2005


   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 credentials to create a
       challenge.
   2.  DIAMETER_SUCCESS_SERVER_NAME_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.

   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 ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace ddd with the actual value



Garcia-Martin, et al.    Expires March 25, 2006                [Page 41]


Internet-Draft          Diameter SIP Application          September 2005


   allocated to this command]

7.9.  Registration-Termination-Request (RTR) Command

   The Registration-Termination-Request (RTR) command is indicated by
   the Command-Code set to eee [Note to IANA and the RFC editor: replace
   eee with the actual value allocated to this command] 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.

   Message Format
       <RTR> ::= < Diameter Header: eee, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Host }
                 { SIP-Deregistration-Reason }
                 [ Destination-Realm ]
                 [ User-Name ]
               * [ SIP-AOR ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace eee with the actual value
   allocated to this command]

7.10.  Registration-Termination-Answer (RTA) Command

   The Registration-Termination-Answer (RTA) is indicated by the



Garcia-Martin, et al.    Expires March 25, 2006                [Page 42]


Internet-Draft          Diameter SIP Application          September 2005


   Command-Code set to eee [Note to IANA and the RFC editor: replace eee
   with the actual value allocated to this command] 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 [RFC3588], the
   Result-Code AVP may contain one of the values defined in Section 9.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 Section 9.1.2) and return
   it in a Diameter RTA message.  Upon reception of this Diameter RTA
   message with the Result-Code AVP value set to
   DIAMETER_USER_NAME_REQUIRED, the SIP server will typically request
   authentication by generating a SIP 401 (Unauthorized) or SIP 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
      (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,



Garcia-Martin, et al.    Expires March 25, 2006                [Page 43]


Internet-Draft          Diameter SIP Application          September 2005


      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 ]
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace eee with the actual value
   allocated to this command]

7.11.  Push-Profile-Request (PPR) Command

   The Push-Profile-Request (PPR) command is indicated by the Command-
   Code set to fff [Note to IANA and the RFC editor: replace fff with
   the actual value allocated to this command] 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.

   A PPR command MAY contain a SIP-Accounting-Information AVP that



Garcia-Martin, et al.    Expires March 25, 2006                [Page 44]


Internet-Draft          Diameter SIP Application          September 2005


   updates the addresses of the accounting servers.  Changes in the
   addresses of the accounting servers take effect immediately.  The
   Diameter client SHOULD close any existing accounting session with the
   existing server and start providing accounting information to the
   newly acquired accounting server.

   The Diameter server sends the new user profile in one or more SIP-
   User-Data AVP value.  On selecting the type of user data, the
   Diameter server SHOULD take into account the supported formats at the
   SIP server (SIP-Supported-User-Data-Type AVP sent in a previous SAR
   message) and the local policy.

   The user to who the profile is applicable is indicated by the User-
   Name AVP.





































Garcia-Martin, et al.    Expires March 25, 2006                [Page 45]


Internet-Draft          Diameter SIP Application          September 2005


   Message Format
       <PPR> ::= < Diameter Header: fff, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
               * { SIP-User-Data }
                 { User-Name }
                 [ SIP-Accounting-Information ]
                 [ Destination-Host ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace fff with the actual value
   allocated to this command]

7.12.  Push-Profile-Answer (PPA) Command

   The Push-Profile-Answer (PPA) is indicated by the Command-Code set to
   fff [Note to IANA and the RFC editor: replace fff with the actual
   value allocated to this command] 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 [RFC3588], the
   Result-Code AVP may contain one of the values defined in Section 9.1.

   If there is no error when processing the received Diameter PPR
   message, the SIP server (Diameter client) MUST download the received
   user profile from the SIP-User-Data AVP values in the Diameter PPR
   message and store it associated with the user specified in 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 values, 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_UNKNOWN and MUST
   return it to the Diameter server in a Diameter PPA message.



Garcia-Martin, et al.    Expires March 25, 2006                [Page 46]


Internet-Draft          Diameter SIP Application          September 2005


   If the SIP server (Diameter client) receives in the SIP-User-Data-
   Content AVP value (of the grouped SIP-User-Data AVP) 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.

   If the Diameter client is not able to honor the command, for any
   other reason, it MUST set the Result-Code AVP value to
   DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA
   message.

   Message Format
       <PPA> ::= < Diameter Header: fff, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
               * [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

   [Note to IANA and the RFC editor: replace fff with the actual value
   allocated to this command]


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.

   Table 2 lists the new AVPs defined in this Diameter SIP application.





Garcia-Martin, et al.    Expires March 25, 2006                [Page 47]


Internet-Draft          Diameter SIP Application          September 2005


      The following abbreviations are used in the Data-Type column:

      *  DURI: DiameterURI
      *  E: Enumerated
      *  G: Grouped
      *  OS: OctetString
      *  UTF8S: UTF8String
      *  U32: Unsigned32

   +---------------------------------+------+----------------+---------+
   | AVP Name                        | AVP  | Reference      | Data-Ty |
   |                                 | Code |                | pe      |
   +---------------------------------+------+----------------+---------+
   | SIP-Accounting-Information      | xx01 | Section 8.1    | G       |
   | SIP-Accounting-Server-URI       | xx02 | Section 8.1.1  | DURI    |
   | SIP-Credit-Control-Server-URI   | xx03 | Section 8.1.2  | DURI    |
   | SIP-Server-URI                  | xx04 | Section 8.2    | UTF8S   |
   | SIP-Server-Capabilities         | xx05 | Section 8.3    | G       |
   | SIP-Mandatory-Capability        | xx06 | Section 8.3.1  | U32     |
   | SIP-Optional-Capability         | xx07 | Section 8.3.2  | U32     |
   | SIP-Server-Assignment-Type      | xx08 | Section 8.4    | E       |
   | SIP-Auth-Data-Item              | xx09 | Section 8.5    | G       |
   | SIP-Authentication-Scheme       | xx10 | Section 8.5.1  | E       |
   | SIP-Item-Number                 | xx11 | Section 8.5.2  | U32     |
   | SIP-Authenticate                | xx12 | Section 8.5.3  | G       |
   | SIP-Authorization               | xx13 | Section 8.5.4  | G       |
   | SIP-Authentication-Info         | xx14 | Section 8.5.5  | G       |
   | SIP-Number-Auth-Items           | xx15 | Section 8.6    | U32     |
   | SIP-Deregistration-Reason       | xx16 | Section 8.7    | G       |
   | SIP-Reason-Code                 | xx17 | Section 8.7.1  | E       |
   | SIP-Reason-Info                 | xx18 | Section 8.7.2  | UTF8S   |
   | SIP-Visited-Network-Id          | xx19 | Section 8.9    | UTF8S   |
   | SIP-User-Authorization-Type     | xx20 | Section 8.10   | E       |
   | SIP-Supported-User-Data-Type    | xx21 | Section 8.11   | UTF8S   |
   | SIP-User-Data                   | xx22 | Section 8.12   | G       |
   | SIP-User-Data-Type              | xx23 | Section 8.12.1 | UTF8S   |
   | SIP-User-Data-Contents          | xx24 | Section 8.12.2 | OS      |
   | SIP-User-Data-Already-Available | xx25 | Section 8.13   | E       |
   | SIP-Method                      | xx26 | Section 8.14   | UTF8S   |
   +---------------------------------+------+----------------+---------+

                           Table 2: Defined AVPs

   [Note to IANA and the RFC editor: replace xx01, xx02, xx03, and so on
   with the actual values allocated to these AVPs.]

   Table 3 expands the table of AVPs included in Section 4.5 of RFC 3588
   [RFC3588].  The table indicates the Diameter AVPs defined in this



Garcia-Martin, et al.    Expires March 25, 2006                [Page 48]


Internet-Draft          Diameter SIP Application          September 2005


   Diameter SIP Application, their possible flag values, and whether the
   AVP may be encrypted.  The acronyms 'M', 'P', and 'V' refer to AVP
   flags whose semantics are described in RFC 3588 [RFC3588].  The value
   of the 'Encr' column is also described in RFC 3588 [RFC3588].

   +----------------------------------+------+-----+-----+------+------+
   | AVP Name                         | MUST | MAY | SHD | MUST | Encr |
   |                                  |      |     | NOT |  NOT |      |
   +----------------------------------+------+-----+-----+------+------+
   | SIP-Accounting-Information       |   M  |  P  |     |   V  |   N  |
   | SIP-Accounting-Server-URI        |   M  |  P  |     |   V  |   N  |
   | SIP-Credit-Control-Server-URI    |   M  |  P  |     |   V  |   N  |
   | SIP-Server-URI                   |   M  |  P  |     |   V  |   N  |
   | SIP-Server-Capabilities          |   M  |  P  |     |   V  |   N  |
   | SIP-Mandatory-Capability         |   M  |  P  |     |   V  |   N  |
   | SIP-Optional-Capability          |   M  |  P  |     |   V  |   N  |
   | SIP-Server-Assignment-Type       |   M  |  P  |     |   V  |   N  |
   | SIP-Auth-Data-Item               |   M  |  P  |     |   V  |   N  |
   | SIP-Authentication-Scheme        |   M  |  P  |     |   V  |   N  |
   | SIP-Item-Number                  |   M  |  P  |     |   V  |   N  |
   | SIP-Authenticate                 |   M  |  P  |     |   V  |   N  |
   | SIP-Authorization                |   M  |  P  |     |   V  |   N  |
   | SIP-Authentication-Info          |   M  |  P  |     |   V  |   N  |
   | SIP-Number-Auth-Items            |   M  |  P  |     |   V  |   N  |
   | SIP-Deregistration-Reason        |   M  |  P  |     |   V  |   N  |
   | SIP-Reason-Code                  |   M  |  P  |     |   V  |   N  |
   | SIP-Reason-Info                  |   M  |  P  |     |   V  |   N  |
   | SIP-Visited-Network-Id           |   M  |  P  |     |   V  |   N  |
   | SIP-User-Authorization-Type      |   M  |  P  |     |   V  |   N  |
   | SIP-Supported-User-Data-Type     |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data                    |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Type               |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Contents           |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Already-Available  |   M  |  P  |     |   V  |   N  |
   | SIP-Method                       |   M  |  P  |     |   V  |   N  |
   +----------------------------------+------+-----+-----+------+------+

                  Table 3: Summary of the new AVPs flags

8.1.  SIP-Accounting-Information AVP

   The SIP-Accounting-Information (AVP code xx01) [Note to IANA and the
   RFC editor: replace xx01 with the actual value allocated to this AVP]
   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:





Garcia-Martin, et al.    Expires March 25, 2006                [Page 49]


Internet-Draft          Diameter SIP Application          September 2005


      SIP-Accounting-Information :: = < AVP Header: xx01 >
                                    * [ SIP-Accounting-Server-URI ]
                                    * [ SIP-Credit-Control-Server-URI ]
                                    * [ AVP]

   [Note to IANA and the RFC editor: replace xx01 with the actual value
   allocated to this AVP]

8.1.1.  SIP-Accounting-Server-URI AVP

   The SIP-Accounting-Server-URI AVP (AVP Code xx02) [Note to IANA and
   the RFC editor: replace xx02 with the actual value allocated to this
   AVP] 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 SIP-Credit-Control-Server-URI AVP (AVP Code xx03) [Note to IANA
   and the RFC editor: replace xx03 with the actual value allocated to
   this AVP] 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 [RFC4006] may
   be used for this purpose.

8.2.  SIP-Server-URI AVP

   The SIP-Server-URI AVP (AVP Code xx04) [Note to IANA and the RFC
   editor: replace xx04 with the actual value allocated to this AVP] is
   of type UTF8String.  This AVP contains a SIP or SIPS URI (as defined
   in RFC 3261 [RFC3261]) that identifies a SIP server.

8.3.  SIP-Server-Capabilities AVP

   The SIP-Server-Capabilities AVP (AVP Code xx05) [Note to IANA and the
   RFC editor: replace xx05 with the actual value allocated to this AVP]
   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-Capabilities ::= < AVP Header: xx05 >
                                 * [ SIP-Mandatory-Capability ]
                                 * [ SIP-Optional-Capability ]
                                 * [ SIP-Server-URI ]
                                 * [ AVP ]

   [Note to IANA and the RFC editor: replace xx05 with the actual value



Garcia-Martin, et al.    Expires March 25, 2006                [Page 50]


Internet-Draft          Diameter SIP Application          September 2005


   allocated to this AVP]

8.3.1.  SIP-Mandatory-Capability AVP

   The SIP-Mandatory-Capability AVP (AVP Code xx06) [Note to IANA and
   the RFC editor: replace xx06 with the actual value allocated to this
   AVP] 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 xx07) [Note to IANA and the
   RFC editor: replace xx07 with the actual value allocated to this AVP]
   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 xx08) [Note to IANA and
   the RFC editor: replace xx08 with the actual value allocated to this
   AVP] 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.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 51]


Internet-Draft          Diameter SIP Application          September 2005


   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
      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 xx09) [Note to IANA and the RFC
   editor: replace xx09 with the actual value allocated to this AVP] is
   of type Grouped and contains the authentication and/or authorization
   information pertaining to a user.

   When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to
   include a SIP-Authenticate AVP, the Diameter server MUST send a
   maximum of one authentication data item (e.g., in case the SIP
   request contained several credentials).  Section 10 contains a
   detailed discussion and normative text of the case when a SIP request
   contains several credentials.

          SIP-Auth-Data-Item :: = < AVP Header: xx09 >
                                  { SIP-Authentication-Scheme }
                                  [ SIP-Item-Number ]
                                  [ SIP-Authenticate ]
                                  [ SIP-Authorization ]
                                  [ SIP-Authentication-Info ]
                                * [ AVP ]

   [Note to IANA and the RFC editor: replace xx09 with the actual value
   allocated to this AVP]



Garcia-Martin, et al.    Expires March 25, 2006                [Page 52]


Internet-Draft          Diameter SIP Application          September 2005


8.5.1.  SIP-Authentication-Scheme AVP

   The SIP-Authentication-Scheme AVP (AVP code xx10) [Note to IANA and
   the RFC editor: replace xx10 with the actual value allocated to this
   AVP] 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 [RFC2617]).
   The only currently defined value is:

   o  DIGEST (0) to indicate HTTP Digest authentication as specified in
      RFC 2617 [RFC2617] Section 3.2.1.  Derivative work is also
      considered Digest authentication scheme, 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 [RFC3310].

   Each HTTP Digest directive (parameter) is transported in a
   corresponding AVP, whose name follows the pattern Digest-*.  The
   Digest-* AVPs are RADIUS attributes imported from the RADIUS
   Extension for Digest Authentication [I-D.ietf-radext-digest-auth]
   namespace, allowing a smooth transition between RADIUS and Diameter
   applications supporting SIP.  The Diameter SIP application goes a
   step further by grouping the Digest-* AVPs into the SIP-Authenticate,
   SIP-Authorization, and SIP-Authentication-Info grouped AVPs, that
   correspond to the SIP WWW-Authenticate/Proxy-Authenticate,
   Authorization/Proxy-authorization and Authentication-Info headers
   fields, respectively.

      NOTE: Due to the fact that HTTP Digest authentication [RFC2617] 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 [RFC3310].
      Extensions to this memo can register new values and new AVPs to
      provide support for other authentication schemes.

      NOTE: Although RFC 2617 [RFC2617] defines the Basic and Digest
      schemes for authenticating HTTP requests, RFC 3261 [RFC3261] 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 xx11) [Note to IANA and the RFC editor:
   replace xx11 with the actual value allocated to this AVP] 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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 53]


Internet-Draft          Diameter SIP Application          September 2005


   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 xx12) [Note to IANA and the RFC
   editor: replace xx12 with the actual value allocated to this AVP] is
   of type Grouped and contains a reconstruction of either the SIP WWW-
   Authenticate or Proxy-Authenticate header fields specified in RFC
   2617 [RFC2617] for the HTTP Digest authentication scheme.
   Additionally, the AVP may include a Digest-HA1 AVP that contains
   H(A1) (as defined in RFC 2617 [RFC2617]).  H(A1) allows the Diameter
   client to create an expected response and compare it with the Digest
   response received from the SIP UA.

      SIP-Authenticate ::= < AVP Header: xx12 >
                           { Digest-Realm }
                           { Digest-Nonce }
                           [ Digest-Domain ]
                           [ Digest-Opaque ]
                           [ Digest-Stale ]
                           [ Digest-Algorithm ]
                           [ Digest-QoP ]
                           [ Digest-HA1]
                         * [ Digest-Auth-Param ]
                         * [ AVP ]

   [Note to IANA and the RFC editor: replace xx12 with the actual value
   allocated to this AVP]

8.5.4.  SIP-Authorization AVP

   The SIP-Authorization AVP (AVP code xx13) [Note to IANA and the RFC
   editor: replace xx13 with the actual value allocated to this AVP] is
   of type Grouped and contains a reconstruction of either the SIP
   Authorization or Proxy-Authorization header fields specified in RFC
   2617 [RFC2617] for the HTTP Digest authentication scheme.












Garcia-Martin, et al.    Expires March 25, 2006                [Page 54]


Internet-Draft          Diameter SIP Application          September 2005


      SIP-Authorization ::= < AVP Header: xx13 >
                            { Digest-Username }
                            { Digest-Realm }
                            { Digest-Nonce }
                            { Digest-URI }
                            { Digest-Response }
                            [ Digest-Algorithm ]
                            [ Digest-CNonce ]
                            [ Digest-Opaque ]
                            [ Digest-QoP ]
                            [ Digest-Nonce-Count ]
                            [ Digest-Method]
                            [ Digest-Entity-Body-Hash ]
                          * [ Digest-Auth-Param ]
                          * [ AVP ]

   [Note to IANA and the RFC editor: replace xx13 with the actual value
   allocated to this AVP]

8.5.5.  SIP-Authentication-Info AVP

   The SIP-Authentication-Info AVP (AVP Code xx14) [Note to IANA and the
   RFC editor: replace xx14 with the actual value allocated to this AVP]
   is of type Grouped and contains a reconstruction of the SIP
   Authentication-Info header specified in RFC 2617 [RFC2617] for the
   HTTP Digest authentication scheme.

      SIP-Authentication-Info ::= < AVP Header: xx14 >
                                  { Digest-Nextnonce }
                                  [ Digest-QoP ]
                                  [ Digest-Response-Auth ]
                                  [ Digest-CNonce ]
                                  [ Digest-Nonce-Count ]
                                * [ AVP ]

   [Note to IANA and the RFC editor: replace xx14 with the actual value
   allocated to this AVP]

   Note that, in some cases, the Digest-Response-Auth AVP cannot be
   calculated at the Diameter server, but has to be calculated at the
   Diameter client (SIP server).  For example, if the value of the
   quality of protection (qop) parameter in Digest is set to "auth-int",
   then the response-digest (rspauth parameter value in Digest) is
   calculated with the hash of the body of the SIP response, which is
   not available at the Diameter server.  In this case, the Diameter
   client (SIP server) must calculate the response-digest once the body
   of the SIP response will be calculated.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 55]


Internet-Draft          Diameter SIP Application          September 2005


   Therefore, a value of "auth-int" in the Digest-QoP AVP of the SIP-
   Authentication-Info AVP indicates that the Diameter client (SIP
   server) MUST compute the Digest "rspauth" parameter value at the
   Diameter client (SIP server).

8.5.6.  Digest AVPs

   The following AVPs are RADIUS attributes defined in the RADIUS
   Extension for Digest Authentication [I-D.ietf-radext-digest-auth] and
   imported by this specification: Digest-AKA-Auts, Digest-Algorithm,
   Digest-Auth-Param, Digest-CNonce, Digest-Domain, Digest-Entity-Body-
   Hash, Digest-HA1, Digest-Method, Digest-Nextnonce, Digest-Nonce,
   Digest-Nonce-Count, Digest-Opaque, Digest-QoP, Digest-Realm, Digest-
   Response, Digest-Response-Auth, Digest-URI, Digest-Username, and
   Digest-Stale.

8.5.6.1.  Considerations about Digest-HA1 AVP

   The Digest-HA1 AVP contains the value, pre-calculated at the Diameter
   server, of H(A1) as defined in RFC 2617 [RFC2617].  The Diameter
   client can use H(A1) to calculate the expected Digest response,
   according to this challenge.  If the SIP UA is in possession of the
   credentials, the calculated expected response and the response sent
   from the SIP UA will match.  The Diameter server MAY include this AVP
   to enable and assist the SIP server in authenticating the SIP UA.

   This scenario is applicable when the Diameter server is configured to
   use the MD5 Message-Digest algorithm in the HTTP Digest
   authentication.  If the Diameter server is configured to use a
   session MD5 (MD5-sess) algorithm, then the Diameter server requires
   the client nonce to compute the H(A1) before sending it to the
   Diameter client, and the client nonce might not be available at the
   time the computation of H(A1) is done.  Therefore, it is RECOMMENDED
   to configure the Diameter server to use MD5 as the algorithm in HTTP
   Digest, if the final authentication is delegated to the Diameter
   client.

   It is up to the Diameter server to include a Digest-HA1 AVP.  The
   Diameter server calculates the Digest H(A1) with the username,
   password, realm, (and nonce and cnonce if applicable), as inputs, and
   places the result in the Digest-HA1 AVP value.  For more details of
   the A1 computation see RFC 2617 [RFC2617] Section 3.2.2.2.  The
   Diameter client can calculate the Digest expected response with H(A1)
   as input, as described in RFC 2617 [RFC2617] Section 3.2.2.

   Section 10 provide further normative details about the usage of the
   Digest-HA1 AVP.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 56]


Internet-Draft          Diameter SIP Application          September 2005


8.5.6.2.  Considerations about Digest-Entity-Body-Hash AVP

   The Digest-Entity-Body-Hash AVP contains a hash of the entity body
   contained in the SIP message.  This hash is required by 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 HTTP
   Digest is the authentication mechanism and the Diameter server
   requires to verify the integrity of the entity body (e.g., qop
   parameter set to "auth-int").

   The clarifications described in Section 22.4 of RFC 3261 [RFC3261]
   about the hash of empty entity bodies apply to the Digest-Entity-
   Body-Hash AVP.

8.5.6.3.  Considerations about Digest-Auth-Param AVP

   The Digest-Auth-Param AVP 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 stand-alone 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/value combination per AVP value.  If
   the Digest header contains several 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 Section
   3.2.1 of RFC 2617 [RFC2617].

   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.6.  SIP-Number-Auth-Items AVP

   The SIP-Number-Auth-Items AVP (AVP Code xx15) [Note to IANA and the
   RFC editor: replace xx15 with the actual value allocated to this
   AVP]is of type Unsigned32 and indicates the number of authentication
   and/or authorization credentials that the Diameter server included in
   a Diameter message.

   When the AVP is present in a request, it indicates the number of SIP-



Garcia-Martin, et al.    Expires March 25, 2006                [Page 57]


Internet-Draft          Diameter SIP Application          September 2005


   Auth-Data-Items the Diameter client is requesting.  This can be used,
   for instance, when the SIP server is requesting several pre-
   calculated authentication credentials.  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 xx16) [Note to IANA and
   the RFC editor: replace xx16 with the actual value allocated to this
   AVP] is of type Grouped, and indicates the reason for a
   deregistration operation.

      SIP-Deregistration-Reason ::= < AVP Header: xx16 >
                                    { SIP-Reason-Code }
                                    [ SIP-Reason-Info ]
                                  * [ AVP ]

   [Note to IANA and the RFC editor: replace xx16 with the actual value
   allocated to this AVP]

8.7.1.  SIP-Reason-Code AVP

   The SIP-Reason-Code AVP (AVP code xx17) [Note to IANA and the RFC
   editor: replace xx17 with the actual value allocated to this AVP] 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 xx18) [Note to IANA and the RFC
   editor: replace xx18 with the actual value allocated to this AVP] 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 is a RADIUS attribute imported from the RADIUS
   Extension for Digest Authentication [I-D.ietf-radext-digest-auth]
   namespace, allowing a smooth transition between RADIUS and Diameter
   applications supporting SIP.  The SIP-AOR AVP carries the URI of the
   intended user related to the SIP request (whose location in SIP may
   vary depending on the actual SIP request and whether the SIP server



Garcia-Martin, et al.    Expires March 25, 2006                [Page 58]


Internet-Draft          Diameter SIP Application          September 2005


   is acting on Diameter due to a SIP originated or terminating
   requests).

   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 to create the value of the SIP-AOR AVP 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 (e.g.,
   the SIP server is receiving a terminating SIP request), 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.  If the SIP server is acting as a SIP registrar,
   then it maps the To header field of the REGISTER request to the SIP-
   AOR AVP.

8.9.  SIP-Visited-Network-Id AVP

   The SIP-Visited-Network-Id AVP (AVP Code xx19) [Note to IANA and the
   RFC editor: replace xx19 with the actual value allocated to this AVP]
   is of type UTF8String.  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 xx20) [Note to IANA and
   the RFC editor: replace xx20 with the actual value allocated to this
   AVP] is of type Enumerated, and indicates the type of user
   authorization being performed in a User Authorization operation,
   i.e., the Diameter User-Authorization-Request (UAR) command.  The
   following values are defined:

   o  REGISTRATION (0)
      This value is used in case of the initial registration or re-
      registration.
      This is the default value.
   o  DE_REGISTRATION (1)
      This value is used in case of the de-registration.
   o  REGISTRATION_AND_CAPABILITIES (2)
      This value is used in case of initial registration or re-
      registration when the SIP server explicitly requests the Diameter
      server to get capability information.  This capability information
      will help the SIP server to allocate another SIP server to serve
      the user.



Garcia-Martin, et al.    Expires March 25, 2006                [Page 59]


Internet-Draft          Diameter SIP Application          September 2005


8.11.  SIP-Supported-User-Data-Type AVP

   The SIP-Supported-User-Data-Type AVP (AVP Code xx21) [Note to IANA
   and the RFC editor: replace xx21 with the actual value allocated to
   this AVP] is of type UTF8String, and contains a string that
   identifies the type of supported user data (user profile, see SIP-
   User-Data AVP (Section 8.12)) supported in the node.  The AVP can be
   repeated, if the SIP server supports several user data types.  In
   case of repetition, the Diameter client should order the different
   instances of this AVP according to its preferences.

   When the Diameter client inserts this AVP in a SAR message, it allows
   the Diameter client to provide an indication to the Diameter server
   of the types of user data supported by the SIP server.  The Diameter
   server, upon inspection of these AVPs, will return a suitable SIP-
   User-Data AVP (Section 8.12) of the type indicated in the SIP-User-
   Data-Type AVP (Section 8.12.1).

8.12.  SIP-User-Data AVP

   The SIP-User-Data AVP (AVP Code xx22) [Note to IANA and the RFC
   editor: replace xx22 with the actual value allocated to this AVP] is
   of type Grouped.  This AVP allows the Diameter server to transport
   user specific data, such as a user profile, to the SIP server (in the
   Diameter client).  The Diameter server selects a type of user data
   that is understood by the SIP server in the Diameter client, and has
   been indicated in a SIP-Supported-User-Data-Type AVP.  In case the
   Diameter client indicated support for several types of user data, the
   Diameter server SHOULD choose the first type supported by the client.

   The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP, that
   indicates the type of user data included in the SIP-User-Data-
   Contents-AVP.

      SIP-User-Data ::= < AVP Header: xx22 >
                        { SIP-User-Data-Type }
                        { SIP-User-Data-Contents }
                      * [ AVP ]

   [Note to IANA and the RFC editor: replace xx22 with the actual value
   allocated to this AVP]

8.12.1.  SIP-User-Data-Type AVP

   The SIP-User-Data AVP (AVP Code xx23) [Note to IANA and the RFC
   editor: replace xx23 with the actual value allocated to this AVP] is
   of type UTF8String, and contains a string that identifies the type of
   user data included in the SIP-User-Data AVP (Section 8.12).



Garcia-Martin, et al.    Expires March 25, 2006                [Page 60]


Internet-Draft          Diameter SIP Application          September 2005


   This document does not specify a convention to characterize the type
   of user data contained in the SIP-User-Data AVP (Section 8.12).  It
   is believed that in most cases this feature will be used in
   environments controlled by a network administrator who can configure
   both the client and server to assign the same value type at the
   client and server.  It is also RECOMMENDED that organizations
   developing their own profile of SIP-User-Data AVP (Section 8.12)
   allocate a type based on their canonical DNS name.  For instance,
   organization "example.com" can define several types of SIP-User-Data
   and allocate the types "type1.dsa.example.com",
   "type2.dsa.example.com", and so on.  This convention will avoid a
   clash in the allocation of types of SIP-User-Data AVP (Section 8.12).

8.12.2.  SIP-User-Data-Contents AVP

   The SIP-User-Data-Contents AVP (AVP Code xx24) [Note to IANA and the
   RFC editor: replace xx24 with the actual value allocated to this AVP]
   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.13.  SIP-User-Data-Already-Available AVP

   The SIP-User-Data-Already-Available AVP (AVP code xx25) [Note to IANA
   and the RFC editor: replace xx25 with the actual value allocated to
   this AVP] 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.14.  SIP-Method AVP

   The SIP-Method-AVP (AVP code xx26) [Note to IANA and the RFC editor:
   replace xx26 with the actual value allocated to this AVP] is of type
   UTF8String and contains the method of the SIP request that triggered
   the Diameter message.  The Diameter server MUST use this AVP solely
   to for authorization of SIP requests, and MUST NOT use it to compute
   the Digest authentication.  To compute the Digest authentication, the
   Diameter server MUST use the Digest-Method AVP instead.



Garcia-Martin, et al.    Expires March 25, 2006                [Page 61]


Internet-Draft          Diameter SIP Application          September 2005


9.  New Values for Existing AVPs

   This section defines new values that the Diameter SIP application
   extends to already existing AVPs.

9.1.  Extension to the Result-Code AVP Values

   The Result-Code AVP is already defined in RFC 3588 [RFC3588].  In
   addition to the values already defined in RFC 3588 [RFC3588], the
   Diameter SIP application defines the following new Result-Code AVP
   values:

9.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.

   [Note to IANA and the RFC editor: replace 2xxy with the actual values
   allocated to the Result-Code AVP]

   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 request operation was successfully processed.  The Diameter
      server does not keep a record of the SIP server address 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 a number of authentication credentials in the
      answer message.  The Diameter server does not keep a record of the
      SIP server.

9.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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 62]


Internet-Draft          Diameter SIP Application          September 2005


   could not be satisfied at the time it was received, but MAY be able
   to satisfy the request in the future.

   [Note to IANA and the RFC editor: replace 4xxy with the actual values
   allocated to the Result-Code AVP]

   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.

9.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.

   [Note to IANA and the RFC editor: replace 5xxy with the actual values
   allocated to the Result-Code AVP]

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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 63]


Internet-Draft          Diameter SIP Application          September 2005


   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.


10.  Authentication Details

   Authenticating a user can occur through various mechanisms.
   Currently HTTP Digest authentication is supported.  The actual
   authentication is performed in either the SIP server or the Diameter
   server.

   If the Diameter server wants to assure that authentication will take
   place in the own Diameter server (as opposed to a delegated
   authentication taking place in the SIP server), it MUST NOT include a
   Digest-HA1 AVP (part of the grouped SIP-Authenticate AVP which in
   turn is part of the SIP-Auth-Data-Item AVP) in a MAA message.  The
   Diameter server MAY include a pre-calculated Digest-HA1 AVP in the
   MAA message if it wants to delegate authentication of the user to the
   SIP server.

   Note that on systems where the SIP User Agent is using HTTP Digest
   authentication [RFC2617] inside of TLS [RFC2246], where only the SIP
   proxy server has a certificate, delegating authentication to the SIP
   server (by making Digest-HA1 available to the SIP server) might
   reduce the load on the Diameter server.

   When requesting authentication, the Diameter client indicates in the
   SIP-Number-Auth-Items AVP value of a Diameter MAR message how many
   authentication credentials are being requested.  In the Diameter MAA
   message, the Diameter server MAY include more than one SIP-Auth-Data-
   Item AVP, but it is only useful for the Diameter client if the the
   Digest-QoP AVP was set to 'auth-int' (in the MAR message), and if
   future authenticatiosn will have the same realm.  On including more
   than one SIP-Auth-Data-Item AVP the Diameter server SHOULD indicate
   how many instances of 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 AVP will
   indicate "Digest" and the SIP-Authenticate AVP 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



Garcia-Martin, et al.    Expires March 25, 2006                [Page 64]


Internet-Draft          Diameter SIP Application          September 2005


   Diameter MAR message that the Diameter client sends to the Diameter
   server MUST include all the authentication credentials supplied by
   the SIP UA (there might be more than one credential, e.g., different
   realms, authentication of proxies, etc.).  Each credential is
   inserted in a grouped SIP-Authorization AVP (part of the grouped SIP-
   Auth-Data-Item AVP).  The Diameter client MUST insert a SIP-Number-
   Auth-Items AVP with the value set to the number of credentials
   enclosed.  If necessary, the Digest-Entity-Body-Hash AVP will contain
   a hash of the body, 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 Diameter
   server MAY include one or more SIP-Auth-Data-Item AVPs to provide
   further authentication credentials to the SIP server.  If the
   authentication is unsuccessful due to missing credentials, the
   Diameter MAA message will include an SIP-Auth-Data-Item AVP 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.

   There are situations where a SIP request traverses several proxies,
   and each of the proxies request to authenticate the SIP UA.  In this
   situation, it is a valid scenario that a SIP request received at a
   SIP server contains several sets of credentials.  The 'realm'
   directive in HTTP is the key that the Diameter client can use to
   determine which credential is applicable.  It may happen also that
   none of the realms are of interests to the Diameter client, in which
   case the Diameter client MUST consider that no credentials (of
   interest) were sent.  In any case, a Diameter client MUST send zero
   or exactly one credential to the Diameter server.  The Diameter
   client MUST choose the credential based on the 'realm' directive in
   the Authorization/Proxy-Authorization header field, and it MUST match
   the realm of the Diameter client.

10.1.  Generation of nonces

   This Diameter SIP application provides support for generating nonces
   in either the Diameter client of the Diameter server.  Both Diameter
   clients and servers MUST support both modes of operation.

   The Diameter SIP application does not provide a mechanism to
   negotiate where the nonce is generated.  The behaviour is
   preprovisioned in both the Diameter client and servers or, otherwise,
   derived from the operation.

   If HTTP Digest authentication using AKA [RFC3310] is used, then the
   Diameter server MUST generate always nonces and the Diameter client
   MUST NOT generate nonces.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 65]


Internet-Draft          Diameter SIP Application          September 2005


   On receiving a SIP request that does not contain credentials, the SIP
   server (Diameter client) first decides whether nonces for the
   challenge will be generated locally in the Diameter client or
   remotely in the Diameter server.  This, as indicated before, is
   typically a policy decision.  If the result of such decision is that
   nonces are locally generated, then the SIP server/Diameter client
   MUST generate a challenge (including a nonce), that will be part of a
   SIP 401/407 (Proxy) Authentication Required.  If the result of the
   decision is to generate the nonces in the Diameter server, then the
   Diameter client MUST send a Diameter Multimedia-Auth-Request (MAR)
   message to the Diameter server that does not contain a Digest-Nonce
   AVP, according to the procedures described in Section 7.7


11.  Migration from RADIUS

   RADIUS offers support for HTTP Digest authentication in the RADIUS
   Extension for Digest Authentication [I-D.ietf-radext-digest-auth].  A
   number of AVPs (the Digest-* AVPs) of this Diameter SIP application
   are imported from the RADIUS attributes namespace, thus making the
   migration from RADIUS to Diameter smooth.

   Note that the RADIUS Extension for Digest Authentication [I-D.ietf-
   radext-digest-auth] provides a more limited scope than this Diameter
   SIP application, especially, the RADIUS extension for Digest
   Authentiation merely provides support for HTTP Digest authentication,
   whereas the Diameter SIP application provides, e.g., support for user
   location, profile downloading and update, etc.

   The following sections discuss several configurations in which a
   gateway translates RADIUS to Diameter and vice versa:

11.1.  Gateway from RADIUS Client to Diameter Server

   The gateway maps Access-Request messages to MAR request.  If a RADIUS
   Access-Request message contains at least one Digest-* attribute, the
   gateway maps all Digest-* attributes to the AVPs of a Diameter SIP-
   Authorization AVP, constructs a MAR message and sends it to the
   Diameter server.  If the RADIUS Access-Request message does not
   contain any Digest-* attribute, then RADIUS client does not want to
   apply HTTP Digest authentication, in which case, actions at the
   gateway are outside the scope of this document.

   The Diameter Server responds with a MAA message.  If the MAA message
   contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH
   and challenge parameters in a SIP-Authenticate AVP, then the gateway
   translates the AVPs of SIP-Authenticate AVP and puts the resulting
   RADIUS attributes into an Access-Challenge message.  It sends the



Garcia-Martin, et al.    Expires March 25, 2006                [Page 66]


Internet-Draft          Diameter SIP Application          September 2005


   Access-Challenge message to the RADIUS client.

   If the MAA message contains a SIP-Authentication-Info and a Digest-
   Response AVP.  The gateway converts these AVPs to the corresponding
   RADIUS attributes and constructs a RADIUS message.  If the Result-
   Code AVP is DIAMETER_SUCCESS, an Access-Accept is sent.  In all other
   cases, an Access-Reject is sent.

11.2.  Gateway from Diameter Client to RADIUS Server

   The Diameter client sends a Diameter MAR meesage to the gateway.  If
   the MAR message does not contain SIP-Auth-Data-Item AVPs, the gateway
   constructs an Access-Request message and maps the SIP-AOR and SIP-
   Method AVPs to RADIUS attributes.  The gateway sends the Access-
   Request message to the RADIUS server which will respond with an
   Access-Challenge.  The gateway creates a MAA message with a Result-
   Code AVP set to DIAMETER_MULTI_ROUND_AUTH and maps the Digest-*
   attributes to Diameter AVPs in a SIP-Authenticate AVP.  The gateway
   sends the resulting MAA to the Diameter client, which will respond
   with a new MAR.

   The gateway checks the SIP-Auth-Data-Item AVPs of this MAR for an AVP
   where the Digest-Realm AVP matches the locally configured realm
   value.  It takes the AVPs from this SIP-Auth-Data-Item AVP, converts
   them into the corresponding RADIUS attributes and constructs a RADIUS
   Access-Request message.  The gateway sends the Access-Request message
   to the RADIUS server.  If the RADIUS server responds with an Access-
   Accept message, the gateway converts the RADIUS attributes to
   Diameter AVPs, constructs a MAA message with a Result-Code AVP set to
   DIAMETER_SUCCESS and sends this message to the Diameter client.  If
   the RADIUS server responds with an Access-Reject message, the gateway
   converts the RADIUS attributes to Diameter AVPs, constructs a MAA
   message with a Result-Code AVP set to
   DIAMETER_ERROR_IDENTITIES_DONT_MATCH and sends this message to the
   Diameter client.

11.3.  Known Limitations

   As mentioned earlier, there is not a 100% match between the Diameter
   SIP application and the RADIUS Extension for Digest Authentication
   [I-D.ietf-radext-digest-auth].  In particular, the RADIUS Extension
   for Digest Authentication [I-D.ietf-radext-digest-auth] does not
   offer equivalent functionality to the Diameter UAR/UAA, SAR/SAA, LIR/
   LIA, RTR/RTA and PPR/PPA messages defined by this specification.


12.  IANA Considerations




Garcia-Martin, et al.    Expires March 25, 2006                [Page 67]


Internet-Draft          Diameter SIP Application          September 2005


   This document serves as IANA registration request for a number of
   items that should be registered in the AAA parameters registry.

12.1.  Application Identifier

   This document defines a standards-track Application-ID that falls
   into the Application Identifier standards-track address space defined
   by RFC 3588 [RFC3588] Section 11.3.  This Application ID should be
   registered in the Application IDs sub-registry of the AAA parameters
   registry with the following data:


    ID values     Name                                Reference
   -----------    ------------------------            ---------
         XXX      Diameter Session Initiation         [RFC YYYY]
                  Protocol (SIP) Application

   [Note to IANA and the RFC Editor: replace XXX with the allocated
   number, YYYY with the RFC number of this specification]

12.2.  Command Codes

   This document defines new standard commands, whose Command Codes are
   to be allocated within the standard permanent Command Codes address
   space defined in RFC 3588 [RFC3588] Section 11.2.1.  These command
   codes should be registered in the Command Codes sub-registry of the
   AAA parameters registry.

   Table 1 in Section 7 contains the detailed list of Command Code names
   and values that are part of this Diameter application.

12.3.  AVP Codes

   This document defines new standard AVPs, whose AVP Codes are to be
   allocated within the AVP Codes address space defined in RFC 3588
   [RFC3588] Section 11.4.  These AVP codes should be registered in the
   AVP Codes sub-registry of the AAA parameters registry.

   Table 2 in Section 8 contains the detailed list of AVP names and AVP
   codes that are part of this Diameter application.

12.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 RFC
   3588 [RFC3588] Section 14.4.1.  These values should be listed in the
   Result-Code AVP values section of the AVP Specific Values sub-
   registry of the AAA parameters registry.



Garcia-Martin, et al.    Expires March 25, 2006                [Page 68]


Internet-Draft          Diameter SIP Application          September 2005


   Section 9.1.1 lists the new Result-Code AVP values that fall into the
   success category, according to RFC 3588 [RFC3588] Section 7.1.2.

   Section 9.1.2 lists the new Result-Code AVP values that fall into the
   transient failure category, according to RFC 3588 [RFC3588] Section
   7.1.4.

   Section 9.1.3 lists the new Result-Code AVP values that fall into the
   permanent failures category, according to RFC 3588 [RFC3588] Section
   7.1.5.


13.  Security Considerations

   This memo does not describe a stand-alone protocol, but a particular
   application for the Diameter protocol [RFC3588].  Consequently, all
   the security considerations applicable to Diameter automatically
   apply to this memo.  In particular, section 13 of RFC 3588 applies to
   this memo.

   This Diameter SIP application allows a Diameter client to use the
   properties of HTTP Digest authentication [RFC2617] by evaluating or
   sending to the Diameter server the credentials supplied by a user.
   When Section 4 of RFC 2617 [RFC2617] discusses HTTP Digest
   authentication, it is also applicable to this memo.

   This Diameter SIP application also allows a Diameter client to use
   the properties of HTTP Digest authentication using AKA [RFC3310] by
   evaluating or sending to the Diameter server the credentials supplied
   by a user.  Section 5 of RFC 3310 [RFC3310] is also applicable to
   this memo.


14.  Contributors

   The authors would like to thank the following contributors who made
   substantial contributions to this work:

          Pete McCann           Lucent
          Jaako Rajaniemi       Nokia

   Wolfgang Beck (Deutsche Telekom AG) provided the text in the
   Migration to RADIUS Section.


15.  Acknowledgements

   The authors would like to thank Tony Johansson and Kevin Purser for



Garcia-Martin, et al.    Expires March 25, 2006                [Page 69]


Internet-Draft          Diameter SIP Application          September 2005


   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,
   Wolfgang Beck, Ulrich Wiehe, Cullen Jennings, and Anu Leinonen for
   their reviews and valuable comments.

   The Diameter SIP Application is based on the Diameter Application for
   the Cx interface of the 3GPP IP Multimedia Subsystem [3GPP.29.229].
   The authors would like to thank 3GPP Working Group CN4 for this work.


16.  Changes With Respect Previous Versions

   Note to the RFC editor: Delete this section before publication as
   RFC.

16.1.  Changes in draft-ietf-aaa-diameter-sip-app-08.txt from -08.txt

   o  This version of the specification added support for the generation
      of nonces in the Diameter client.  This change had impact
      throughout the whole document.
   o  Fixed some errors indicating that the final verification of the
      user's credentials could only take place in the Diameter client if
      client nonces wheren't used.  Now the text clarifies that this
      scenario is not possible when the combination of client nonces and
      MD5-sess happens.
   o  The Migration from RADIUS Section has been imported from the
      RADIUS draft.

16.2.  Changes in draft-ietf-aaa-diameter-sip-app-07.txt from -06.txt

   o  Added Table 3 that includes a summary of all the AVPs defined by
      this specification are the AVP flags.
   o  Title in Section 5.4 is changed to "SIP Server Requests
      Authentication and Authorization"
   o  Fixed typo in Section 7.7 that compared MAR with UAR (about
      storing state).  The comparison should have been done with SAR.
   o  Section 8.5 wrongly indicated that the Diameter client could send
      a SIP-Authenticate AVP.  Actually, the Diameter *** server *** is
      the peer that sends SIP-Authenticate AVPs.
   o  The draft used to speak about "authentication vectors".  The
      terminology has been replaced by "a number of authentication
      credentials", which is more aligned with HTTP Digest.
   o  On Section 10, a paragraph that used to couple Digest-HA1 with the
      qop value has been removed: it was a left over from a previous
      version of the document.





Garcia-Martin, et al.    Expires March 25, 2006                [Page 70]


Internet-Draft          Diameter SIP Application          September 2005


16.3.  Changes in draft-ietf-aaa-diameter-sip-app-06.txt from -05.txt

   o  The SIP-AOR AVP is now imported from the RADIUS Extension for
      Digest Authentication [I-D.ietf-radext-digest-auth].  More
      information of how to derive the SIP-AOR from the SIP message is
      provided.
   o  The Authentication Details section now tries to clarify the
      possibility of delegation of authentication to the SIP server, and
      cases where it might unload the Diameter server.

16.4.  Changes in draft-ietf-aaa-diameter-sip-app-05.txt from -04.txt

   o  The Digest-* AVPs are imported from the RADIUS Extension for
      Digest Authentication [I-D.ietf-radext-digest-auth].  An
      introduction paragraph has been added in Section 8.5.1.
   o  As a side effect of the above change, the SIP-Authentication-
      Context disappeared.  This was a grouped AVP that only contained a
      Digest-Entity-Body-Hash AVP.  The latter will remain (in the
      RADIUS draft).
   o  The Digest-Expected-Response was considered not secure enough.
      Instead, the Digest-Expected-Response has been replaced by Digest-
      HA1, which contains a hash of A1 (see RFC 2617 [RFC2617] Section
      3.2.2 for more details.  This allows the Diameter server to
      delegate the final authentication to the Diameter client in a
      secure way.  The Digest-HA1 AVP is also imported from RADIUS
      Extension for Digest Authentication [I-D.ietf-radext-digest-auth].
   o  The Digest-Digest-URI has been renamed as Digest-URI, as it is now
      imported from RADIUS Extension for Digest Authentication
      [I-D.ietf-radext-digest-auth].
   o  The SIP-Accounting-Information AVP was originally specified in the
      SAA command.  It has been also added to the PPR command, so that
      it is possible that PPR updates the addresses of the accounting
      servers.
   o  It has been clarified that when the Diameter client receives a
      answer command that contains the Result-Code AVP set to
      DIAMETER_USER_NAME_REQUIRED the SIP server will typically request
      authentication.  Previously, the description seemed to indicate
      that this typical action applied to any Result-Code.
   o  The TEL URI (RFC 2806bis) is now known as RFC 3966.
   o  If multiple SIP proxies are authenticating the user, the SIP
      request may contain several Proxy-Authorization headers.  The
      Diameter server cannot send all the credentials, since the
      Diameter server may be serving several common realms for which
      credentials exist.  In this situation the Diameter server will not
      known which credentials to use.  It has been clarified that the
      Diameter client MUST send only one set of credentials at a time,
      those belonging to the served realm.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 71]


Internet-Draft          Diameter SIP Application          September 2005


   o  Reference added to RFC 3588 when a Subscriber Locator Function can
      populate the Redirect-Host-Usage with the value ALL_USER.
   o  The IANA registration section has clarified what are the registry
      and sub-registries where IANA needs to take an action.

16.5.  Changes in draft-ietf-aaa-diameter-sip-app-04.txt from -03.txt

   o  DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED and
      DIAMETER_SUCCESS_SERVER_NOT_STORED have the same semantics: the
      former is kept, the latter is deleted.
   o  Added a new Digest-Method AVP.  This AVP contains the method used
      to compute the Digest authentication, and it is independent from
      the SIP-Method AVP.  It has been clarified that Digest-Method is
      used for authentication whereas SIP-Method is used for
      authorization.
   o  SIP-User-Data-Request-Type AVP is removed.  Its purpose was to
      retrieve a fraction of the user profile.  This seems to create
      expensive complexity, and we don't seem to have requirements to
      support this function anymore.
   o  Fixed the general section layout.  Some sections got, by accident,
      buried in deep level section.
   o  The grouped SIP-Authenticate AVP allowed multiple instances of the
      Digest-Expected-Response AVP.  However, since there can be only
      one expected response computed at the Diameter server, we now
      allow a single Digest-Expected-Response.
   o  A note is added indicating that if Digest-Qop is set to "auth-int"
      in the SIP-Authentication-Info AVP, then the Diameter client (SIP
      server) is responsible to compute the "rspauth" value in the
      Digest Authentication-Info header.
   o  This version of the draft provides support to identify the type of
      user data included in the SIP-User-Data AVP (this can contain a
      user profile).  The following changes has been made:
   o
      *  Added a new SIP-Supported-User-Data-Type AVP.
      *  The old SIP-User-Data AVP is now a grouped AVP that contains
         two AVPs: SIP-User-Data-Type and SIP-User-Data-Contents.
      *  Added a new SIP-User-Data-Type AVP.
      *  Added a new SIP-User-Data-Contents (that contains the profile).
         This is equivalent to the old SIP-User-Data AVP.
      *  All the above AVPs are visible in SAR, SAA, and PPR commands.
      *  The new SIP-User-Data and SIP-Supported-User-Data-Type allows
         repetition (a server could potential send more than one
         profile; a client can express support for more than one type of
         profile).
   o  Fixed a typo that defined the SIP-Visited-Network-Id AVP as an
      OctetString AVP rather than UTF-8.





Garcia-Martin, et al.    Expires March 25, 2006                [Page 72]


Internet-Draft          Diameter SIP Application          September 2005


16.6.  Changes in draft-ietf-aaa-diameter-sip-app-03.txt from -02.txt

   o  A Diameter Subscriber Locator was either a Diameter Relay or a
      Diameter Redirect node.  We have removed the Diameter Relay
      functionality, since Diameter relays will not relay CER/CEA
      messages, thus, a Diameter client will never be able to determine
      which Diameter applications are running in a given Diameter
      server.  So a Diameter Subscriber Locator is implemented as a
      Diameter redirect node.
   o  Section "Registration termination" has been rewritten.  Now the
      procedures speak about SIP soft state management, rather than SIP
      registration, so this procedures are applicable to SIP event
      subscriptions as well.  A discussion on how to couple Diameter
      user sessions with SIP soft states is also added
   o  Added a new Digest-Expected-Response AVP that allows the Diameter
      server to send a pre-calculated expected digest response to the
      Diameter client.  This is only applicable to the case when the SIP
      UA does not use client nonces.
   o  The Authentication Details Section has been updated with the
      latest details of the authentication process.

16.7.  Changes in draft-ietf-aaa-diameter-sip-app-02.txt from -01.txt

   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 [RFC3310].  A Digest-AKA-Auts AVP is added.
   o  List of authors 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.

16.8.  Changes in draft-ietf-aaa-diameter-sip-app-01.txt from -00.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.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 73]


Internet-Draft          Diameter SIP Application          September 2005


   o  The SIP-Authentication-Context AVP is changed to be a grouped AVP.
      It contains a SIP-Entity-Body-Hash AVP that contains the hash of
      the entity body (e.g., the hash of the SDP [RFC2327]).  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 a 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 download 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.

16.9.  Changes in draft-ietf-aaa-diameter-sip-app-00.txt from
       draft-belinchon-aaa-diameter-mm-app-01.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 reception of this



Garcia-Martin, et al.    Expires March 25, 2006                [Page 74]


Internet-Draft          Diameter SIP Application          September 2005


      Result-Code AVP value, will generate a SIP 401 (Unauthorized) or
      SIP 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.


17.  References

17.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2617]  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.

   [RFC3261]  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.

   [RFC3310]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
              Protocol (HTTP) Digest Authentication Using Authentication
              and Key Agreement (AKA)", RFC 3310, September 2002.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [I-D.ietf-radext-digest-auth]
              Sterman, B., "RADIUS Extension for Digest Authentication",
              draft-ietf-radext-digest-auth-05 (work in progress),
              September 2005.

17.2.  Informational References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2327]  Handley, M. and V. Jacobson, "SDP: Session Description
              Protocol", RFC 2327, April 1998.

   [RFC4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
              P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
              August 2005.




Garcia-Martin, et al.    Expires March 25, 2006                [Page 75]


Internet-Draft          Diameter SIP Application          September 2005


   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

   [3GPP.29.229]
              3GPP, "Cx and Dx interfaces based on the Diameter
              protocol; Protocol details", 3GPP TS 29.229 5.10.0,
              April 2005.







































Garcia-Martin, et al.    Expires March 25, 2006                [Page 76]


Internet-Draft          Diameter SIP Application          September 2005


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


   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











Garcia-Martin, et al.    Expires March 25, 2006                [Page 77]


Internet-Draft          Diameter SIP Application          September 2005


   Kalle Tammi
   Nokia
   P.O.Box 785
   Tampere  33101
   Finland

   Phone: +358 40 505 8670
   Email: kalle.tammi@nokia.com











































Garcia-Martin, et al.    Expires March 25, 2006                [Page 78]


Internet-Draft          Diameter SIP Application          September 2005


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 procedures with respect to rights in RFC 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 (2005).  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 March 25, 2006                [Page 79]