AAA Working Group M. Garcia-Martin, Ed. Internet-Draft M. Belinchon Expires: April 15, 2004 M. Pallares-Lopez C. Canales Ericsson P. McCann Lucent Technologies J. Rajaniemi K. Tammi Nokia Networks October 16, 2003 Diameter Session Initiation Protocol (SIP) Application draft-ietf-aaa-diameter-sip-app-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 15, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies the Diameter Session Initiation Protocol (SIP) Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with the Session Initiation Protocol (SIP), and provides a Diameter Garcia-Martin, et al. Expires April 15, 2004 [Page 1] Internet-Draft Diameter SIP application October 2003 client in a SIP server with the ability to request a Diameter server the authentication of users and authorization of SIP resources usage. This application does not require or is not related to other authentication services provided by the Mobile IP Diameter [7] or the Network Access Server Diameter [8] applications. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 5. Overview of operation . . . . . . . . . . . . . . . . . . 6 5.1 General architecture . . . . . . . . . . . . . . . . . . . 7 5.2 Diameter server authenticates the user . . . . . . . . . . 8 5.3 Diameter server delegates authentication to the SIP server . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4 SIP server authenticates a request . . . . . . . . . . . . 13 5.5 Session attempt . . . . . . . . . . . . . . . . . . . . . 14 5.6 Update of the user profile . . . . . . . . . . . . . . . . 15 5.7 Registration termination . . . . . . . . . . . . . . . . . 16 5.8 Diameter server discovery . . . . . . . . . . . . . . . . 17 6. Advertising Application Support . . . . . . . . . . . . . 19 7. Diameter SIP application Command Codes . . . . . . . . . . 19 7.1 User-Authorization-Request (UAR) Command . . . . . . . . . 20 7.2 User-Authorization-Answer (UAA) Command . . . . . . . . . 21 7.3 Server-Assignment-Request (SAR) Command . . . . . . . . . 24 7.4 Server-Assignment-Answer (SAA) Command . . . . . . . . . . 26 7.5 Location-Info-Request (LIR) Command . . . . . . . . . . . 29 7.6 Location-Info-Answer (LIA) Command . . . . . . . . . . . . 30 7.7 Multimedia-Auth-Request (MAR) Command . . . . . . . . . . 32 7.8 Multimedia-Auth-Answer (MAA) Command . . . . . . . . . . . 33 7.9 Registration-Termination-Request (RTR) Command . . . . . . 36 7.10 Registration-Termination-Answer (RTA) Command . . . . . . 37 7.11 Push-Profile-Request (PPR) Command . . . . . . . . . . . . 39 7.12 Push-Profile-Answer (PPA) Command . . . . . . . . . . . . 39 8. Diameter SIP application AVPs . . . . . . . . . . . . . . 41 8.1 SIP-Accounting-Information AVP . . . . . . . . . . . . . . 43 8.1.1 SIP-Accounting-Server-URI AVP . . . . . . . . . . . . . . 43 8.1.2 SIP-Credit-Control-Server-URI AVP . . . . . . . . . . . . 43 8.2 SIP-Server-URI AVP . . . . . . . . . . . . . . . . . . . . 43 8.3 SIP-Server-Capabilities AVP . . . . . . . . . . . . . . . 44 8.3.1 SIP-Mandatory-Capability AVP . . . . . . . . . . . . . . . 44 8.3.2 SIP-Optional-Capability AVP . . . . . . . . . . . . . . . 44 8.4 SIP-Server-Assignment-Type AVP . . . . . . . . . . . . . . 44 8.5 SIP-Auth-Data-Item AVP . . . . . . . . . . . . . . . . . . 45 8.5.1 SIP-Item-Number AVP . . . . . . . . . . . . . . . . . . . 46 8.5.2 SIP-Authentication-Scheme AVP . . . . . . . . . . . . . . 46 Garcia-Martin, et al. Expires April 15, 2004 [Page 2] Internet-Draft Diameter SIP application October 2003 8.5.3 SIP-Authenticate AVP . . . . . . . . . . . . . . . . . . . 46 8.5.4 SIP-Authorization AVP . . . . . . . . . . . . . . . . . . 47 8.5.5 SIP-Authentication-Info AVP . . . . . . . . . . . . . . . 47 8.5.6 SIP-Authentication-Context AVP . . . . . . . . . . . . . . 47 8.6 SIP-Number-Auth-Items AVP . . . . . . . . . . . . . . . . 48 8.7 SIP-Deregistration-Reason AVP . . . . . . . . . . . . . . 48 8.7.1 SIP-Reason-Code AVP . . . . . . . . . . . . . . . . . . . 48 8.7.2 SIP-Reason-Info AVP . . . . . . . . . . . . . . . . . . . 48 8.8 SIP-AOR AVP . . . . . . . . . . . . . . . . . . . . . . . 48 8.9 SIP-Visited-Network-Id AVP . . . . . . . . . . . . . . . . 49 8.10 SIP-User-Authorization-Type AVP . . . . . . . . . . . . . 49 8.11 SIP-User-Data AVP . . . . . . . . . . . . . . . . . . . . 49 8.12 SIP-User-Data-Already-Available AVP . . . . . . . . . . . 50 8.13 SIP-User-Data-Request-Type AVP . . . . . . . . . . . . . . 50 8.14 SIP-Confidentiality-Key AVP . . . . . . . . . . . . . . . 50 8.15 SIP-Integrity-Key AVP . . . . . . . . . . . . . . . . . . 51 8.16 SIP-Method AVP . . . . . . . . . . . . . . . . . . . . . . 51 8.17 New values for existing AVPs . . . . . . . . . . . . . . . 51 8.17.1 Extension to the Result-Code AVP values . . . . . . . . . 51 9. Authentication Details . . . . . . . . . . . . . . . . . . 53 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 54 10.1 Application Identifier . . . . . . . . . . . . . . . . . . 54 10.2 Command Codes . . . . . . . . . . . . . . . . . . . . . . 54 10.3 AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 54 10.4 Additional values for the Result-Code AVP value . . . . . 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 55 12. Changes with respect previous versions . . . . . . . . . . 55 12.1 Changes from draft-belinchon-aaa-diameter-mm-app-01.txt to draft-ietf-aaa-diameter-sip-app-00.txt . . . . . . . . 55 Normative References . . . . . . . . . . . . . . . . . . . 56 Informational References . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . 59 Garcia-Martin, et al. Expires April 15, 2004 [Page 3] Internet-Draft Diameter SIP application October 2003 1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 2. 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 [6] section 6, apply: o 'Address-of-Record (AOR)' o 'Outbound proxy' o 'Proxy' o 'Server (SIP server)' o 'User Agent (UA)' o 'User Agent Client (UAC)' For the purpose of this document, the following terms and definitions given in RFC 3588 [2] section 1.3, apply: o 'Authorization' o 'Authentication' o 'AVP' o 'Diameter Client' o 'Diameter Server' o 'Home Realm' o 'Relay Agent or Relay' Garcia-Martin, et al. Expires April 15, 2004 [Page 4] Internet-Draft Diameter SIP application October 2003 o 'Redirect Agent' o 'User' 3. Introduction This document specifies the Diameter Session Initiation Protocol (SIP) Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information to a Diameter server for Session Initiation Protocol (SIP) [6] based IP multimedia services. We assume that the SIP server and the Diameter client are located in the same node, so that the SIP server is able to receive and process SIP requests and responses which in turn relies on the AAA infrastructure for authenticating the SIP request and authorizing the usage of particular SIP services. This document provides Diameter procedures to implement certain required functionality when SIP is the protocol chosen to initiate and tear-down multimedia sessions or when SIP is used for other non-session related applications. However, this document does not mandate any particular mapping of SIP procedures to Diameter SIP application procedures, nor does it mandate any particular sequence of events between SIP and Diameter. This document provides useful examples to show the interaction between SIP and the Diameter SIP application in order to achieve the desired functionality. The Applicability section (Section 4) discusses assumptions and configurations assumed by this document. The Overview of Operation chapter (Section 5) provides the reader with informative descriptions of the Diameter SIP application commands and responses and some guidance to their linkage with SIP procedures. Advertising of this application is described in the Advertising Application Support chapter (Section 6). The Diameter SIP application Command Codes chapter (Section 7) provides a normative description of all the new Diameter commands defined by this specification. This application extends the Result-Code Attribute-Value-Pair (AVP) with some new values. Further information is described in the New values for existing AVPs chapter (Section 8.17). This application defines some new AVPs. All these AVPs are described in the Diameter SIP application AVPs chapter (Section 8). Garcia-Martin, et al. Expires April 15, 2004 [Page 5] Internet-Draft Diameter SIP application October 2003 Some extra information about authentication is provided in the Authentication details chapter (Section 9). 4. Applicability This document assumes a general architecture where a Home Realm is composed of one or more nodes implementing Diameter or SIP functions. At least, one of such nodes implements the Diameter Server functionality and the Diameter Server has access to a user database. The user data associated to a particular user is stored in a single point in the network named the user database. There may be more than a single Diameter Server in the network, and all these servers have access to such user database. But at a given time, the data a Diameter Server returns is independent of the Diameter Server that returns the information. Central to the architecture is the fact that the user data is stored in a single point in the network. This restriction does not mandate a particular implementation, e.g., it is possible to implement clusters of databases operating in mirror mode to provide redundancy. The property required by this specification is that the user data the Diameter Server has access to is stored safely in what, from the external point of view, is seen as a single user database. This document allows several configurations of the Home Realm. In one of such configurations, a SIP server is allocated to a user for the purpose of triggering and executing services. The allocation of the SIP server may be done dynamically, e.g., at the time the user registers in the network. This configuration requires a SIP server, typically located at the edge of the network, that supports routing of SIP requests and responses towards the allocated SIP server. Both SIP server nodes implement a Diameter Client. In another configuration, 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, request authorization for SIP requests and performs accounting activities. 5. Overview of operation This section provides an informative description of how the Diameter SIP application can be used together with SIP. This section is not intended to mandate any specific usage of the Diameter SIP application nor does it mandate a specific mapping between SIP and Diameter messages. This section is a collection of examples that show how the required AAA functionality can be achieved in conjunction Garcia-Martin, et al. Expires April 15, 2004 [Page 6] Internet-Draft Diameter SIP application October 2003 with SIP. 5.1 General architecture The Diameter SIP application can be used in a SIP environment where an interface to a AAA infrastructure is required to authenticate, authorize or provide accounting information. Figure 1 below shows a general overview of the integration of the SIP architecture with the AAA architecture. According to Figure 1, there is one or more SIP User Agents (UA) that initiate or terminate SIP traffic through one or more SIP servers. Both SIP servers implement a Diameter client that supports the Diameter application described in this specification. +--------+ UAR/UAA +--->|Diameter|<----+ PPR/PPA LIR/LIA | | server | | MAR/MAA | +--------+ | SAR/SAA | | RTR/RTA | | v v +------+ SIP +--------+ SIP +--------+ SIP +------+ | SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP | | UA | |server 1| |server 2| | UA | +------+ +--------+ +--------+ +------+ ^ ^ UAR/UAA | | PPR/PPA LIR/LIA | | MAR/MAA | +--------+ | SAR/SAA +--->|Diameter|<----+ RTR/RTA | SL | +--------+ Figure 1: Architecture of the Diameter application for SIP In Figure 1, it can be seen that SIP server 1 sends different Diameter commands and receives different responses to those sent and received by SIP server 2. This is because SIP server 1 in Figure 1 is located at the edge of a network, and its main task is to locate SIP server 2. SIP server 2 is requesting and receiving authentication and authorization data from the Diameter server and is not located at the edge of the network. The Diameter Subscriber Locator (SL) serves for the purposes of locating the Diameter server that contains the user related data. Its functionality is further described in Section 5.8. Garcia-Martin, et al. Expires April 15, 2004 [Page 7] Internet-Draft Diameter SIP application October 2003 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 Diameter server authenticates the user In this approach we show an example of an administrative network where the Diameter server is authenticating user requests. This could be the case of a medium size network where the Diameter server is keeping user records and authenticating SIP requests to perform a certain transaction. We have chosen to show a SIP REGISTER request in the example, but the SIP server could request authentication of any other SIP request. Garcia-Martin, et al. Expires April 15, 2004 [Page 8] Internet-Draft Diameter SIP application October 2003 +--------+ +--------+ +--------+ | SIP | |Diameter| | SIP | |server 1| | server | |server 2| +--------+ +--------+ +--------+ | | | 1. SIP REGISTER | | | ---------------->| 2. UAR | | |------------------>| | | 3. UAA | | |<------------------| | | 4. SIP REGISTER | |-------------------------------------->| | | 5. MAR | | |<------------------| | | 6. MAA | | |------------------>| | 7. 401 (Unauthorized) | 8. 401 (Unauth.) |<--------------------------------------| -----------------| | | 9. SIP REGISTER | | | ---------------->| 10. UAR | | |------------------>| | | 11. UAA | | |<------------------| | | 12. SIP REGISTER | |-------------------------------------->| | | 13. MAR | | |<------------------| | | 14. MAA | | |------------------>| | 15. 200 (OK) | | 16. 200 (OK) |<--------------------------------------| <----------------| | | | | | Figure 2: Authentication performed in the Diameter server According to Figure 2 a SIP User Agent Client (UAC) sends a SIP REGISTER request (step 1) to its home domain. SIP server 1 will receive the SIP request. We assume that this SIP server may be located, e.g., at the edge of the administrative home domain. The Diameter client in SIP server 1 will contact its Diameter server by sending a Diameter User-Authorization-Request (UAR) message (step 2) to determine if this user is allowed to receive service, and if so, request the address of a local SIP server capable of handling this user. The Diameter server will answer with a Diameter User-Authorization-Answer (UAA) message (step 3), which will indicate either a list of capabilities that SIP server 1 may use to select an Garcia-Martin, et al. Expires April 15, 2004 [Page 9] Internet-Draft Diameter SIP application October 2003 appropriate SIP server (SIP server 2) or a SIP or SIPS URI pointing to SIP server 2. SIP server 1 will forward the SIP REGISTER request (step 4) to an appropriate SIP server (SIP server 2). The Diameter client in SIP server 2 will then request user authentication from the Diameter server by sending a Diameter Multimedia-Auth-Request (MAR) message (step 5). This request will also serve to make the Diameter server aware of the SIP or SIPS URI of SIP server 2, so as to return subsequent requests for the same user to the same SIP server 2. The Diameter server will respond with a Diameter Multimedia-Auth-Answer (MAA) message (step 6) with Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a challenge, which SIP server 2 will use to map into the WWW-authentication header in the SIP 401 (Unauthorized) response (step 7), which is sent back to SIP server 1 and then to the SIP UAC (step 8). SIP server 1 will receive a next SIP REGISTER request containing the user credentials (step 9). Note that SIP server 1 does not need to keep a state, and even more, there is no guarantee that the SIP request will arrive at the same SIP server 1, there could be a farm of SIP servers 1 operating in redundant configuration. The Diameter client in SIP server 1 will contact a Diameter server by sending a Diameter UAR message (step 10) to determine the SIP server allocated to the user. The Diameter server will send the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11). SIP server 1 will then forward the SIP REGISTER request to SIP server 2 (step 12). SIP server 2 will extract the credentials from the SIP REGISTER request. The Diameter client in SIP server 2 will send those credentials in a Diameter MAR message (step 13)to the Diameter server. At this point, the Diameter server will be able to authenticate the user, and upon success, will return a Diameter MAA message (step 14) with the AVP Result-Code set to the value DIAMETER_SUCCESS. The Diameter MAA message will also include the user profile information, which SIP server 2 will use to give service to the user. SIP server 2 will then generate a SIP 200 (OK) response (step 15) which is forwarded to SIP server 1 and eventually to the SIP UAC (step 16). 5.3 Diameter server delegates authentication to the SIP server An operator with a large base of installed SIP servers may wish to minimize the impact of modifying SIP servers to interact with Diameter servers. This can be achieved by allowing SIP servers to Garcia-Martin, et al. Expires April 15, 2004 [Page 10] Internet-Draft Diameter SIP application October 2003 retain the functionality of authentication, rather than centralizing this capability in a Diameter server. However, it should be noted that this mode will not leverage the extensive array of authentication and authorization services which will already be present regardless in Diameter servers. +--------+ +--------+ +--------+ | SIP | |Diameter| | SIP | |server 1| | server | |server 2| +--------+ +--------+ +--------+ | | | 1. SIP REGISTER | | | ---------------->| 2. UAR | | |------------------>| | | 3. UAA | | |<------------------| | | 4. SIP REGISTER | |-------------------------------------->| | | 5. MAR | | |<------------------| | | 6. MAA | | |------------------>| | 7. 401 (Unauthorized) | 8. 401 (Unauth.) |<--------------------------------------| <----------------| | | 9. SIP REGISTER | | | ---------------->| 10. UAR | | |------------------>| | | 11. UAA | | |<------------------| | | 12. SIP REGISTER | |-------------------------------------->| | | 13. SAR | | |<------------------| | | 14. SAA | | |------------------>| | 15. 200 (OK) | | 16. 200 (OK) |<--------------------------------------| <----------------| | | | | | Figure 3: Delegation of authentication to the SIP server Figure 3 shows an example where a SIP server is dynamically allocated to serve a SIP User Agent with the support of the Diameter server. This may be the case of certain architectures, such as the 3rd Generation Partnership Project (3GPP) IP Core Network Multimedia Garcia-Martin, et al. Expires April 15, 2004 [Page 11] Internet-Draft Diameter SIP application October 2003 Subsystem (IMS). A first SIP server receives a SIP REGISTER request (step 1) addressed to the home network domain. We assume that this SIP server may be located, e.g., at the edge of the administrative home domain. The Diameter client in this SIP server requests authorization from the Diameter server to proceed with the registration, by sending a Diameter User-Authorization-Request (UAR) message (step 2). The message includes, among other Attribute-Value-Pairs (AVP), the SIP address-of-record that is included in the SIP REGISTER request. The Diameter server will verify the SIP address-of-record and if deemed correct, will authorize the user to proceed with the registration in the home domain. The Diameter server will respond with a Diameter User-Authorization-Answer (UAA) message (step 3), which will inform the Diameter client/SIP server about the result of the user authorization. In case of a successful authorization, the Diameter UAA message will indicate either the address of a local SIP server (SIP server 2 in Figure 3) or a list of capabilities that SIP server 1 may use to select an appropriate SIP server 2. When the authorization is successful, SIP server 1 will forward the SIP REGISTER request (step 4) to the appropriate SIP server (SIP server 2). The Diameter client in SIP server 2 will then request authentication parameters by sending a Diameter Multimedia-Auth-Request (MAR) message (step 5) to the Diameter server. This request will also serve to make the Diameter server aware of the SIP or SIPS URI of SIP server 2, so as to return subsequent requests of the same user to the same SIP server 2. The Diameter server will respond with a Diameter Multimedia-Auth-Answer (MAA) message (step 6), which will include all parameters necessary for the designated authentication algorithm associated with the user. SIP server 2 will then create a 401 (Unauthorized) SIP response (step 7), including the authentication material needed by the SIP User Agent Client (UAC) to include the appropriate credentials. SIP server 1 forwards the SIP response to the SIP UAC (step 8). When SIP server 1 receives a next SIP REGISTER request containing the user credentials (step 9), as SIP server 1 does not need to keep a state (even there is no guarantee that the SIP request arrives to the same SIP server 1), the Diameter client in SIP server 1 will contact again the Diameter server by sending a Diameter UAR message (step 10) to determine the SIP server allocated to the user. The Diameter server will send the SIP or SIPS URI of SIP server 2 in a Diameter UAA message (step 11). SIP server 1 will then forward the SIP REGISTER request to SIP server 2 (step 12). SIP server 2 will validate the credentials, and will send a Diameter Server-Assignment-Request (SAR) message (step 13) Garcia-Martin, et al. Expires April 15, 2004 [Page 12] Internet-Draft Diameter SIP application October 2003 requesting the Diameter server to store the SIP or SIPS URI of the SIP server that is currently serving the user. The Diameter SAR message also serves the purpose to request the Diameter server to send the user profile to the SIP server. The Diameter server will respond with a Diameter Server-Assignment-Answer (SAA) message (step 14). If the Result-Code AVP value does not inform about an error, the User-Data AVP will contain the information that SIP server 2 needs in order to provide a service to the user. SIP server 2 generates a SIP 200 (OK) response (step 15) that will be forwarded to SIP server 1 and eventually to the SIP UAC (step 16). 5.4 SIP server authenticates a request Figure 4 depicts a typical scenario where a stateless SIP proxy requests authentication information and authorization to a Diameter server, for the purpose of providing SIP routing services to a SIP User Agent. The SIP proxy server may be configured as an outbound SIP proxy, so that all the requests initiated by the SIP UA traverse the SIP proxy. According to Figure 4, a SIP User Agent sends a SIP request to its outbound SIP proxy server. In this case, the message is a SIP INVITE request (see step 1), but it could be any other SIP request. We assume that this SIP request does not contain any credentials at this time. The outbound SIP proxy server needs to authenticate and authorize the proxy services offered to the user. The Diameter client in the SIP server sends a Multimedia-Auth-Request (MAR) message (step 2). The Diameter server sends a Multimedia-Auth-Answer (MAA) message (step 3) that includes all the data necessary for the SIP server to challenge the user, perhaps with HTTP Digest Authentication or any other suitable mechanism indicated in the MAA message. This data will serve the SIP server to create a SIP 407 Proxy Authentication Required response (step 4) that contains a challenge. The SIP UA will create a new INVITE request (step 5) that contains the credentials. The Diameter client in the SIP server will send the credentials to the Diameter server in a new Diameter MAR message (step 6). The Diameter server will validate the credentials and authorize the SIP transaction in a Diameter MAA message (step 7). The SIP server forwards the SIP INVITE request to its destination (step 8) as per regular SIP procedures. Eventually, the session setup will be confirmed with a 200 OK response (step 9) that is forwarded to the SIP UA (step 10). The session setup is complete. Garcia-Martin, et al. Expires April 15, 2004 [Page 13] Internet-Draft Diameter SIP application October 2003 +--------+ +--------+ +--------+ | UA | |Diameter| | SIP | | | | server | | server | +--------+ +--------+ +--------+ | | | | 1. SIP INVITE | |---------------------------->| | | 2. MAR | | |<----------------| | | 3. MAA | | |---------------->| | 4. SIP 407 Proxy | | Authentication Required | |<----------------------------| | 5. SIP INVITE | |---------------------------->| | | 6. MAR | | |<----------------| | | 7. MAA | | |---------------->| 8. SIP INVITE | | |----------------> | | | 9. SIP 200 OK | 10. SIP 200 OK |<---------------- |<----------------------------| | | | Figure 4: SIP server request authorization 5.5 Session attempt Figure 5 shows the scenario where SIP server 1 may be configured as a SIP edge proxy server, processing SIP traffic at the edge of a network. SIP server 1 receives a SIP INVITE request (step 1). SIP server 1 needs to find the address of SIP server 2, which is serving the addressed UA. Therefore, the Diameter client in SIP server 1 sends Diameter Location-Info-Request (LIR) message (step 2) to the Diameter server. The Diameter server responds with a Diameter Location-Info-Answer (LIA) message (step 3) that contains the SIP or SIPS URI of SIP server 2. SIP server 1 then forwards the SIP INVITE to SIP server 2 (step 4). SIP server 2 will eventually forward the SIP INVITE to the appropriate UAS (step 5). Garcia-Martin, et al. Expires April 15, 2004 [Page 14] Internet-Draft Diameter SIP application October 2003 +--------+ +--------+ +--------+ | SIP | |Diameter| | SIP | |server 1| | server | |server 2| +--------+ +--------+ +--------+ | | | 1. SIP INVITE | | | -------------->| 2. LIR | | |------------------>| | | 3. LIA | | |<------------------| | | 4. SIP INVITE | |-------------------------------------->| | | | 5. SIP INVITE | | |--------------> | | | | | | Figure 5: SIP session attempt: locating the SIP server Although the example shows the connection between a SIP INVITE request and the Diameter LIR message, any other SIP request other than REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message. 5.6 Update of the user profile The Diameter SIP application provides a mechanism for a Diameter server to asynchronously download a user profile to a SIP server whenever there is an update of such user profile. It must be noted that the Diameter server also attaches the user profile in the Diameter Server-Assignment-Request (SAR) message. Although this is valid for most of the daily situations, it may happen that the administrator decides to update or modify the user profile for a particular user, due to, e.g., new services made available to the user. This may involve mechanisms outside the scope of this specification, such as human intervention, in the Diameter server. In this situation, the Diameter server is able to push the new user profile into the SIP server allocated to the user. The scenario is illustrated in Figure 6. Where the user profile changes, the Diameter server will send a Diameter Push-Profile-Request (PPR) message (step 1) to the Diameter client in the SIP server allocated to that user (SIP server 2 in the examples). The Diameter PPR message will contain a SIP-User-Data AVP, a User-Name AVP and zero or more SIP-AOR AVPs. The Diameter client in SIP server 2 will acknowledge the Diameter PPR message by sending a Diameter Push-Profile-Answer (PPA) message (step 2) to the Diameter server. Garcia-Martin, et al. Expires April 15, 2004 [Page 15] Internet-Draft Diameter SIP application October 2003 +--------+ +--------+ |Diameter| | SIP | | server | |server 2| +--------+ +--------+ | | | 1. PPR | |------------------>| | | | 2. PPA | |<------------------| | | Figure 6: Diameter server pushes an update of the user profile 5.7 Registration termination Reasons for terminating a user registration include: o Expiration of the SIP registration timer in the SIP server. o Administrative action taken at the Diameter server. o The SIP UAC generates a SIP REGISTER request setting the Expires header field value to zero or the expires parameter in the Contact header field to zero (e.g., user initiated deregistration). Termination of a user registration can be achieved by either of the following three mechanisms: In the event that NO_STATE_MAINTAINED (i.e., No Diameter user session-id is maintained) has been indicated in a prior Auth-Session-State AVP, termination is handled with a Diameter Session-Termination-Request (STR) message (if it is initiated by the Diameter Client/SIP Proxy) or with a Diameter Registration-Termination-Request (RTR) message (if it is initiated by the Diameter server). Alternatively, if STATE_MAINTAINED has been indicated in a prior Auth-Session-State AVP, the use of Diameter Session-Termination-Request (STR) and Abort-Session-Request (ASR) messages as defined in the Diameter base protocol, RFC 3588 [2] are used to terminate a user registration. Last, if the Diameter server receives a Diameter Server-Assignment-Request (SAR) message that contains a SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the Diameter server will proceed with the deregistration of the user. Garcia-Martin, et al. Expires April 15, 2004 [Page 16] Internet-Draft Diameter SIP application October 2003 5.8 Diameter server discovery The basic architecture assumption of this document is that all the data related to a user is stored in a unique Diameter server. This does not create a single point of failure, as it may be generally though. It is assumed that Diameter servers may be configured in a redundant fashion as an attempt to mitigate the single point of failure problem. In large networks, where the number of users may be significantly high, there might be a need to scale the number of Diameter servers. All the data associated to a user will be still stored in a single (typically redundant) Diameter server. But the data associated to different users may reside in different Diameter servers. This configuration, although scales well, introduces a new problem, namely: giving the SIP AOR (or user) as an input, how to determine which of various Diameter servers is storing the data for that particular SIP AOR. We solve this problem by making usage of the standard Diameter redirection and relay mechanisms, specified in RFC 3588 [2]. 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 map users (SIP AOR) with Diameter server URI. The Diameter server URI points to the actual Diameter server that stores all the data related to a particular user. The Diameter Subscriber Locator acts as either Diameter Relay or Diameter Redirect Agent, dispatching Diameter request (either proxying them to the corresponding Diameter server or sending the redirection URI in the answer). Note that according to the Diameter procedures the redirect functionality in the Diameter client is performed automatically in the Diameter stack, and it does not require any knowledge or support by the Diameter application. The Diameter SL can be replicated in different nodes along the network, for the purpose of building scalability and redundancy. The database or routing tables have to be consistent across all this different Diameter SLs, so that the same Diameter request will produce the same Diameter answer no matter the Diameter SL that processes the request. Garcia-Martin, et al. Expires April 15, 2004 [Page 17] Internet-Draft Diameter SIP application October 2003 +--------+ +--------+ +--------+ +--------+ | SIP | |Diameter| |Diameter| | SIP | |server 1| |SL red. | |server 1| |server 2| +--------+ +--------+ +--------+ +--------+ | | | | 1. SIP INVITE| | | | ------------>| 2. LIR | | | |---------->| | | | 3. LIA | | | |<----------| | | | 4. LIR | | |---------------------->| | | 5. LIA | | |<----------------------| | | 6. SIP INVITE | | |----------------------------------->| 7. SIP INVITE | | | | -------------> | | | | Figure 7: Locating a Diameter server. SL redirecting requests Figure 7 shows an example of operation of a Diameter Subscriber Locator acting in redirect mode. SIP server 1 is receiving an INVITE request (step 1) addressed (in the SIP Request-URI) to a user for which the Diameter client in SIP server 1 does not posses routing information. In other words, the Diameter client in SIP server 1 does not know the URI of Diameter server 1. The Diameter client sends a Diameter LIR message (step 2) to any of the Diameter SLs configured in the network. The address of those SLs is assumed to be pre-provisioned in the Diameter client. The Diameter SL, based on the contents of the SIP-AOR AVP and its own routing tables determines the Diameter server that stores the information allocated to such user. Then it builds a Diameter LIA message (step 3) that includes a Result-Code AVP set to DIAMETER_REDIRECT_INDICATION and one or more Redirect-Host AVPs, whose values are set to one or more URIs of Diameter servers that store the information related to such user. Then the Diameter client in SIP server 1 builds a new LIR message addressed to any of the Diameter servers received in the Redirect-Host AVPs. The rest of procedure is completed as described in previous sections. Garcia-Martin, et al. Expires April 15, 2004 [Page 18] Internet-Draft Diameter SIP application October 2003 +--------+ +--------+ +--------+ +--------+ | SIP | |Diameter| |Diameter| | SIP | |server 1| |SL relay| |server 1| |server 2| +--------+ +--------+ +--------+ +--------+ | | | | 1. SIP INVITE| | | | ------------>| 2. LIR | | | |---------->| 3. LIR | | | |---------->| | | | 4. LIA | | | 5. LIA |<----------| | |<----------| | | | | | | | 6. SIP INVITE | | |----------------------------------->| 7. SIP INVITE | | | | -------------> | | | | Figure 8: Locating a Diameter server. SL relaying messages In another configuration, the Diameter SL is acting as a Diameter relay agent. The scenario is depicted in Figure 8. SIP server 1 is receiving an INVITE request (step 1) addressed (in the SIP Request-URI) to a user for which the Diameter client in SIP server 1 does not posses routing information. In other words, the Diameter client in SIP server 1 does not know the URI of Diameter server 1. The Diameter client sends a Diameter LIR message (step 2) to any of the Diameter SLs configured in the network. The address of those SLs is assumed to be pre-provisioned in the Diameter client. The Diameter SL, based on the contents of the SIP-AOR AVP and its own routing tables, determines the Diameter server that stores the information allocated to such user and it forwards the Diameter LIR message to such Diameter server (step 4). The Diameter server will eventually answer with a Diameter LIA message (LIA) that is forwarded to the Diameter client (step 5). Then the SIP server can proceed forwarding the message to the proper destination. 6. Advertising Application Support Diameter implementations conforming to this specification MAY advertise its support by including the Auth-Application-Id AVP in the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, according to the Diameter base protocol, RFC 3588 [2]. 7. Diameter SIP application Command Codes All the Diameter implementations conforming to this specification MUST implement and support the list of Diameter commands listed in Garcia-Martin, et al. Expires April 15, 2004 [Page 19] Internet-Draft Diameter SIP application October 2003 Table 1. +----------------------------------+-------+-------+----------------+ | Command Name | Abbr. | Code | Reference | +----------------------------------+-------+-------+----------------+ | User-Authorization-Request | UAR | aaa | Section 7.1 | | User-Authorization-Answer | UAA | aaa | Section 7.2 | | Server-Assignment-Request | SAR | bbb | Section 7.3 | | Server-Assignment-Answer | SAA | bbb | Section 7.4 | | Location-Info-Request | LIR | ccc | Section 7.5 | | Location-Info-Answer | LIA | ccc | Section 7.6 | | Multimedia-Auth-Request | MAR | ddd | Section 7.7 | | Multimedia-Auth-Answer | MAA | ddd | Section 7.8 | | Registration-Termination-Request | RTR | eee | Section 7.9 | | Registration-Termination-Answer | RTA | eee | Section 7.10 | | Push-Profile-Request | PPR | fff | Section 7.11 | | Push-Profile-Answer | PPA | fff | Section 7.12 | +----------------------------------+-------+-------+----------------+ Table 1 7.1 User-Authorization-Request (UAR) Command The User-Authorization-Request (UAR) is indicated by the Command-Code set to aaa and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server to request authorization for the SIP User Agent to route a particular SIP request. The Diameter client in the SIP server will request authorization of the REGISTRATION, DE-REGISTRATION or REGISTRATION&CAPABILITIES functions to the Diameter server. See more information in the SIP-User-Authorization-Type AVP (Section 8.10). The user name used for authentication of the user is conveyed in a User-Name AVP (imported from the Diameter base protocol, RFC 3588 [2]). 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 [4], the authentication user name is found in the "username" directive of the SIP Authorization header field value. The SIP or SIPS URI to be registered is conveyed in the SIP-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. Garcia-Martin, et al. Expires April 15, 2004 [Page 20] Internet-Draft Diameter SIP application October 2003 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 ::= < Diameter Header: aaa, REQ, PXY > < Session-ID > < Auth-Application-Id > { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ User-Name ] { SIP-AOR } [ SIP-Visited-Network-Id ] [ SIP-User-Authorization-Type ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 7.2 User-Authorization-Answer (UAA) Command The User-Authorization-Answer (UAA) is indicated by the Command-Code set to aaa and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter User-Authorization-Request (UAR) command. In addition to the values already defined in RFC 3588 [2], the Result-Code AVP may contain one of the values defined in Section 8.17.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 xref="transient-failures-result-code-avp-values" /> and return it in a Diameter UAA message. Upon the reception of the Diameter UAA message, the SIP server will typically request authentication by sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) response back to the originator. Garcia-Martin, et al. Expires April 15, 2004 [Page 21] Internet-Draft Diameter SIP application October 2003 When the authorization procedure succeeds, the Diameter server constructs a User-Authorization-Answer (UAA) message that MUST include either the address of the SIP server already assigned to the user or the capabilities needed by the SIP server (Diameter client) to select another SIP server for the user. This section will be based on the required capabilities of the SIP server to trigger and execute services for the user. The former option is used when the Diameter server is aware of an allocated SIP server to the user, whereas the latter is used when the Diameter server is not aware of an allocated SIP server, letting the SIP server choose, if needed, an appropriate SIP server according to the required capabilities. If a User-Name AVP is present in the Diameter UAR message, then the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter User-Authorization-Answer (UAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN. If a User-Name AVP is present in the Diameter UAR message, then the Diameter server MUST authorize that User-Name AVP value is able to register the SIP or SIPS URI included in the SIP-AOR AVP. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter User-Authorization-Answer (UAA) message. Correlation between User-Name and SIP-AOR AVP values is required just to avoid that any user can register a SIP-AOR allocated to another user. If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message, and the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES then the Diameter server SHOULD verify 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 Garcia-Martin, et al. Expires April 15, 2004 [Page 22] Internet-Draft Diameter SIP application October 2003 message. When the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION then: o If the Diameter server is not aware of any previous registration of the user name (including registrations of other SIP Addresses of Record allocated to the same user name), then the Diameter server does not know of any SIP server allocated to the user. In this case the Diameter server MUST set the Result-Code AVP value to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and the Diameter server SHOULD include the required SIP server capabilities in the SIP-Server-Capabilities AVP value in the Diameter UAA message. The SIP-Server-Capabilities AVP will assist the Diameter client (SIP server) to select an appropriate SIP server for the user, according to the required capabilities. o In some cases, the Diameter server is aware of a previously assigned SIP server for the same or different SIP Addresses of Record allocated to the same user name. In these cases, re-assignment of a new SIP server may or may not be needed, depending on the capabilities of the SIP server. The Diameter server MUST always include the allocated SIP server URI in the SIP-Server-URI AVP of the UAA message. If the Diameter server does not return the SIP capabilities, the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION. Otherwise, if the Diameter server includes a SIP-Server-Capabilities AVP then the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_SERVER_SELECTION. The Diameter client will then determine, based on the received information, whether it needs to select a new SIP server or not. When the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION&CAPABILITIES then 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 Garcia-Martin, et al. Expires April 15, 2004 [Page 23] Internet-Draft Diameter SIP application October 2003 SIP AOR under de-registration, the Diameter server MUST set the Result-Code AVP to DIAMETER_SUCCESS and MUST set the SIP-Server-URI AVP value to the known SIP server, and return them in the Diameter UAA message. o If the Diameter server is not aware of a SIP server assigned to the SIP AOR under de-registration, then the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. Message Format ::= < Diameter Header: aaa, PXY > < Session-Id > { Auth-Application-Id } { Auth-Session-State } { Result-Code } { Origin-Host } { Origin-Realm } [ SIP-Server-URI ] [ SIP-Server-Capabilities ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] * [ Redirect-Host ] 7.3 Server-Assignment-Request (SAR) Command The Server-Assignment-Request (SAR) command is indicated by the Command-Code set to bbb and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server in many cases to request the Diameter server to store the URI of the SIP server that is currently serving the user. During the registration procedure, a SIP server becomes assigned to the user. The Diameter client in the assigned SIP server MUST include its own URI in the SIP-Server-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 Garcia-Martin, et al. Expires April 15, 2004 [Page 24] Internet-Draft Diameter SIP application October 2003 request de-registration of a user, to inform the Diameter server of an authentication failure or just to download the user profile. For a complete description of all the SIP-Server-Assignment-Type AVP values see Section 8.4. Typically the reception of a SIP REGISTER request in a SIP server will trigger the Diameter client in the SIP server to send the Diameter SAR message. However, if a SIP server is receiving other SIP request, such as INVITE, and the SIP server does not have the user profile, the Diameter client in the SIP server may send the Diameter SAR message to the Diameter server in order to download the user profile and make the Diameter server aware of the SIP server assigned to the user. The user profile is an important piece of information that dictates the behavior of the SIP server when triggering or providing services for the user. Typically the user profile is divided into: o Services to be rendered to the user when the user is registered and initiates a SIP request. o Services to be rendered to the user when the user is registered and a SIP request destined to that user arrives to the SIP proxy. o Services to be rendered to the user when the user is not registered and a SIP request destined to that user arrives to the SIP proxy. The Diameter client can request the whole user profile or just the portion of it where the SIP server is interested on. The SIP-User-Data-Request-Type AVP and SIP-User-Data-Already-Available AVP will indicate such request. The SIP-Server-Assignment-Type AVP will indicate the reason why the Diameter client (SIP server) contacted the Diameter server. If the Diameter client sets the SIP-Server-Assignment-Type AVP value to REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT, AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client MUST include exactly one SIP-AOR AVP in the Diameter SAR message. Garcia-Martin, et al. Expires April 15, 2004 [Page 25] Internet-Draft Diameter SIP application October 2003 Message Format ::= < Diameter Header: bbb, REQ, PXY > < Session-Id > { Auth-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ User-Name ] * [ SIP-AOR ] [ SIP-Server-URI ] { SIP-Server-Assignment-Type } { SIP-User-Data-Request-Type } { SIP-User-Data-Already-Available } * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 7.4 Server-Assignment-Answer (SAA) Command The Server-Assignment-Answer (SAA) is indicated by the Command-Code set to bbb and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter Server-Assignment-Request (SAR) command. In addition to the values already defined in RFC 3588 [2], the Result-Code AVP may contain one of the values defined in Section 8.17.1. The Result-Code AVP value in the Diameter SAA message may indicate a success or an error in the execution of the Diameter SAR command. If Result-Code AVP value in the Diameter SAA message does not contain an error code, the SIP-User-Data AVP will typically contain the profile of the user, indicating services that the SIP server can render to that user. 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 xref="transient-failures-result-code-avp-values" /> and return it in a Diameter SAA message. Upon the reception of the Diameter SAA message, the SIP server will typically request authentication by sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) response back to the originator. Garcia-Martin, et al. Expires April 15, 2004 [Page 26] Internet-Draft Diameter SIP application October 2003 If the User-Name AVP is included in the Diameter SAR message, at reception of the Diameter SAR message, the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter Server-Assignment-Answer (SAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN. Then Diameter server MUST authorize that User-Name AVP value is a valid authentication name for the SIP or SIPS URI included in the SIP-AOR AVP of the Diameter SAR message. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter Server-Assignment-Answer (SAA) message. The actions of the Diameter server at the reception of the Diameter SAR message depends on the value of the SIP-Server-Assignment-Type: o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to REGISTRATION or RE_REGISTRATION, the Diameter server SHOULD verify that there is only one SIP-AOR AVP. Otherwise, the Diameter server MUST answer with a Diameter SAA message with the Result-Code AVP value set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP-User-Data AVP. If there is only one SIP-AOR AVP, then the Diameter server SHOULD analyze the requested type of data in the SIP-User-Data-Request-Type and SIP-User-Data-Already-Available AVP values in the Diameter SAR message, and SHOULD include in the SIP-User-Data AVP value of the Diameter SAA message the relevant portion of the user profile associated with the SIP-AOR AVP and all other SIP identities associated with that AVP. Additionally, the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter server considers the SIP AOR authenticated and registered. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to UNREGISTERED_USER then the Diameter server MUST store the SIP server address included in the SIP-Server-URI AVP value. The Diameter server will return the SIP server address in Diameter Location-Info-Answer (LIA) messages. The Diameter server SHOULD analyze the requested type of data in the SIP-User-Data-Request-Type and SIP-User-Data-Already-Available AVP values in the Diameter SAR message. The Diameter server SHOULD include the relevant portion of the user profile data associated with the SIP or SIPS URI (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP value of the Diameter SAA message. The Diameter server MUST set the Result-Code AVP value to Garcia-Martin, et al. Expires April 15, 2004 [Page 27] Internet-Draft Diameter SIP application October 2003 DIAMETER_SUCCESS. The Diameter server considers the SIP AOR UNREGISTERED, but with a SIP server allocated to trigger and provide services for unregistered users. Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type AVP), the Diameter server MUST verify that there is only one SIP-AOR AVP. Otherwise, the Diameter server MUST answer the Diameter SAR message with a Diameter SAA message, it MUST set the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any SIP-User-Data AVP. If the User-Name AVP was not present in the Diameter SAR message and the SIP-AOR is not known for the Diameter server, the Diameter server MUST NOT include a User-Name AVP in the Diameter SAA message and MUST set the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or ADMINISTRATIVE_DEREGISTRATION the Diameter server MUST clear the SIP server address associated with all SIP Addresses of Record indicated in each of the SIP-AOR AVP values included in the Diameter SAR message. The Diameter server considers all of these SIP Addresses of Record as not registered. The Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or USER_DEREGISTRATION_STORE_SERVER_NAME the Diameter server MAY keep the SIP server address associated with the SIP Addresses of Record included in the SIP-AOR AVP values of the Diameter SAR message, even though the SIP Addresses of Record will become unregistered. This feature allows a SIP server to request the Diameter server to remain as an assigned SIP server for those SIP Addresses of Record (SIP-AOR AVP values), and avoid SIP server assignment. The Diameter server MUST consider all these SIP Addresses of Record as not registered. If the Diameter server honors the request of the Diameter client (SIP server) to remain as an allocated SIP server, then the Diameter server MUST keep the SIP server assigned to those SIP Addresses of Record and MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, when the Diameter server does not honor the request of the Diameter client (SIP server) to remain as an allocated SIP server, 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 Garcia-Martin, et al. Expires April 15, 2004 [Page 28] Internet-Draft Diameter SIP application October 2003 message is set to NO_ASSIGNMENT, the Diameter server SHOULD first verify that the SIP-Server-URI AVP value in the Diameter SAR message is the same URI as the as the one assigned to the SIP-AOR AVP value. If they differ, then the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter SAA message. Otherwise, the Diameter server SHOULD analyze the requested type of data in the SIP-User-Data-Request-Type AVP value in the Diameter SAR message, and SHOULD include the requested user profile in the SIP-User-Data AVP value of the Diameter SAA message. o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR message is set to AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there is only SIP-AOR AVP in the Diameter SAR message. If the number of occurrences of the SIP-AOR AVP is not exactly one, the Diameter server MUST set the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message, and SHOULD not take further actions. If there is exactly one SIP-AOR AVP in the Diameter SAR message, the Diameter server MUST clear the address of the SIP server assigned to the SIP Address of Record, and the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter server MUST consider the SIP AOR as not registered. Message Format ::= < Diameter Header: bbb, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ SIP-User-Data ] [ SIP-Accouting-Information ] [ User-Name ] [ Auth-Grace-Period ] [ Authorization-Lifetime ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] * [ Redirect-Host ] 7.5 Location-Info-Request (LIR) Command The Location-Info-Request (LIR) is indicated by the Command-Code set Garcia-Martin, et al. Expires April 15, 2004 [Page 29] Internet-Draft Diameter SIP application October 2003 to ccc and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server to request routing information, e.g., the URI of the SIP server assigned to a particular user. The user is identified by the SIP-AOR AVP value. Message Format ::= < Diameter Header: ccc, REQ, PXY > < Session-Id > { Auth-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { SIP-AOR } * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 7.6 Location-Info-Answer (LIA) Command The Location-Info-Answer (LIA) is indicated by the Command-Code set to ccc and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter Location-Info-Request (LIR) command. In addition to the values already defined in RFC 3588 [2], the Result-Code AVP may contain one of the values defined in Section 8.17.1. When the Diameter server finds an error in processing the Diameter LIR message, the Diameter server MUST stop the process of the message and answer with a Diameter LIA message that includes the appropriate error code in the Result-Code AVP value. When there is no error, the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in the Diameter LIA message. One of the errors that the Diameter server may find is that the SIP-AOR AVP value is not a valid user in the realm. In such cases, the Diameter server MUST set the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message. If the Diameter server cannot process the Diameter SAR command, e.g., due to a database error, the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter LIA message. The Diameter server MUST NOT include any SIP-Server-URI or SIP-Server-Capabilities AVP in the Diameter LIA message. The Diameter server can or cannot be aware of a SIP server assigned Garcia-Martin, et al. Expires April 15, 2004 [Page 30] Internet-Draft Diameter SIP application October 2003 to the user contained in the SIP-AOR AVP value in the Diameter LIR message. If the Diameter server is aware of a SIP server allocated to that particular user, the Diameter server MUST include the URI of such SIP server in the SIP-Server-URI AVP and return it in a Diameter LIA message. This is typically the situation when the user is either registered, or unregistered but there is a SIP server still assigned to the user. When the Diameter server is not aware of a SIP server allocated to the user, typically the case when the user unregistered, the Result-Code AVP value in the Diameter LIA message depends on whether the Diameter server is aware that the user has services defined for unregistered users or not: o Those users who have services defined for unregistered users may require the allocation of a SIP server to trigger and perhaps execute those services. Therefore, when the Diameter server is not aware of an assigned SIP server, but the user has services defined for unregistered users, the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return it in a Diameter LIA message. The Diameter server MAY also include a SIP-Server-Capabilities AVP to facilitate the SIP server (Diameter client) with the selection of an appropriate SIP server with the required capabilities. Absence of the SIP-Server-Capabilities AVP will indicate to the SIP server (Diameter client) that any SIP server is suitable to be allocated for the user. o Those users who do not have service defined for unregistered users do not require further processing. The Diameter server MUST set the Result-Code AVP value to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the Diameter client in a Diameter LIA message. The SIP server (Diameter client) may return the appropriate SIP response (e.g., 480 Temporarily unavailable) to the original SIP request. Garcia-Martin, et al. Expires April 15, 2004 [Page 31] Internet-Draft Diameter SIP application October 2003 Message Format ::= < Diameter Header: ccc, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ SIP-Server-URI ] [ SIP-Server-Capabilities ] [ Auth-Grace-Period ] [ Authorization-Lifetime ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] * [ Redirect-Host ] 7.7 Multimedia-Auth-Request (MAR) Command The Multimedia-Auth-Request (MAR) command is indicated by the Command-Code set to ddd and the Command Flags' 'R' bit set. The Diameter client in a SIP server sends this command to the Diameter server to request the Diameter server to authenticate a user attempt to use some SIP service (in this context, SIP service can be something as simple as a SIP registration or using the proxy services for a SIP request). SIP servers may be operating in a fully stateful mode or in stateless mode. If a stateful SIP server has the guarantee an willingness of further SIP request to traverse the same SIP server, then it can store the SIP server URI in the Diameter server. The Diameter server can return this SIP server URI in Diameter LIR/LIA message. In this case, the Diameter client has to provide a SIP-Server-URI AVP. The SIP-Method AVP MUST include the SIP method name of the SIP request that triggered this Diameter MAR message. The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP indicates the intended Address-of-Record of the SIP request. The value of the AVP is extracted from the SIP request, but the location of such AVP is different depending on the semantics of the SIP request. For SIP REGISTER messages the SIP-AOR AVP value indicates the intended public user identity under registration, and it is the SIP or SIPS URI populated in the To header field value (addr-spec, according to the SIP ABNF) of the SIP REGISTER request. For other types of SIP requests, such as INVITE, SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the intended destination of the request. Garcia-Martin, et al. Expires April 15, 2004 [Page 32] Internet-Draft Diameter SIP application October 2003 This is typically populated in the Request-URI of the SIP request. It is the Diameter client responsibility to extract the SIP-AOR AVP value from the proper SIP header field. Extensions to SIP (new SIP methods or new semantics) may require to extract the SIP-AOR from other parts of the request. If the SIP request includes some sort of authentication information, the Diameter client MUST include the user name, extracted from the authentication information of the SIP request, in the User-Name AVP value. Message Format ::= < Diameter Header: ddd, REQ, PXY > < Session-Id > { Auth-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ User-Name ] { SIP-AOR } { SIP-Method } [ SIP-Server-URI ] [ SIP-Number-Auth-Items ] [ SIP-Auth-Data-Item ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 7.8 Multimedia-Auth-Answer (MAA) Command The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set to ddd and the Command Flags' 'R' bit cleared. The Diameter server sends this command in response to a previously received Diameter Multimedia-Auth-Request (MAR) command. In addition to the values already defined in RFC 3588 [2], the Result-Code AVP may contain one of the values defined in Section 8.17.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 xref="transient-failures-result-code-avp-values" /> and return it in a Diameter MAA message. The Diameter server MAY include a Garcia-Martin, et al. Expires April 15, 2004 [Page 33] Internet-Draft Diameter SIP application October 2003 SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs with authentication information (e.g., a challenge). Upon the reception of the Diameter MAA message, the SIP server will typically request authentication by sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) response back to the originator. If the User-Name AVP is present in the Diameter MAR message, the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm. If the Diameter server does not recognize the user name received in the User-Name AVP, the Diameter server MUST build a Diameter Multimedia-Auth-Answer (MAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN. If the SIP-Method AVP value of the Diameter MAR message is set to REGISTER and a User-Name AVP is present, then the Diameter server MUST authorize that User-Name AVP value is able to use the URI included in the SIP-AOR AVP. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter Multimedia-Auth-Answer (MAA) message. Correlation between User-Name and SIP-AOR AVP values is only required for SIP REGISTER request, just to avoid that any user can register a SIP-AOR allocated to another user. In other types of SIP requests (e.g., INVITE), the SIP-AOR will indicate the intended destination of the request, rather than the originator of it. Then Diameter server MUST verify whether the authentication scheme (SIP-Authentication-Scheme AVP value) indicated in the grouped SIP-Auth-Data-Item AVP is supported or not. If that authentication scheme is not supported, then the Diameter server MUST set the Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send it in a Diameter Multimedia-Auth-Answer (MAA) message. If the received Diameter MAR message contains a SIP-Authorization AVP within the grouped SIP-Auth-Data-Item AVP, the Diameter server considers that the authorization information is being requested after a synchronization failure. In this case, the sequence of the SIP-Auth-Data-Item AVPs would take into account the SIP-Authorization AVP value to synchronize the vectors. The Diameter server MUST set the Result-Code AVP to DIAMETER_SUCCESS. If the SIP-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 Garcia-Martin, et al. Expires April 15, 2004 [Page 34] Internet-Draft Diameter SIP application October 2003 number of SIP-Auth-Data-Item AVPs that is a subset of the authentication data items requested by the Diameter client in the SIP-Number-Auth-Items AVP value of the Diameter MAR message. If the SIP-Server-URI AVP is present in the Diameter MAR message, then the Diameter server MUST compare the stored SIP server assigned to the SIP AOR with the SIP-Server-URI AVP value received in the Diameter MAR message. If there is not a match, the Diameter server MUST update the stored SIP server assigned to the SIP AOR, and MUST set an "authentication pending" flag for the SIP AOR. If there is a match, the Diameter server shall clear the "authentication pending" flag for the SIP AOR. In any other situation, if there is a success in processing the Diameter MAR command and the Diameter server stored the SIP-Server-URI, the Diameter server MUST set the Result-Code AVP value to DIAMETER_SUCCESS and return it in a Diameter MAA message. If there is a success in processing the Diameter MAR command but the Diameter server does not store the SIP-Server-URI because the AVP was not present in the Diameter MAR command, then the Diameter server MUST set the Result-Code AVP value to either: 1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter server is sending authentication vectors to create a challenge 2. DIAMETER_SUCCESS_SERVER_NOT_STORED, if the Diameter server successfully authenticated the user and authorized the SIP server to proceed with the SIP request. Otherwise, the Diameter server MUST set the Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY and it MUST NOT include any SIP-Auth-Data-Item AVP. Garcia-Martin, et al. Expires April 15, 2004 [Page 35] Internet-Draft Diameter SIP application October 2003 Message Format ::= < Diameter Header: ddd, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ User-Name ] [ SIP-AOR ] [ SIP-Number-Auth-Items ] * [ SIP-Auth-Data-Item ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] * [ Redirect-Host ] 7.9 Registration-Termination-Request (RTR) Command The Registration-Termination-Request (RTR) command is indicated by the Command-Code set to eee and the Command Flags' 'R' bit set. The Diameter server sends this command to the Diameter client in a SIP server to inform the SIP server about the de-registration of a user. The Diameter server has the capability to initiate the de-registration of a user and inform the SIP server by means of the Diameter RTR command. The Diameter server can 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 are being deregistered. The Diameter server MUST include a SIP-Deregistration-Reason AVP value to indicate the reason for the deregistration. Garcia-Martin, et al. Expires April 15, 2004 [Page 36] Internet-Draft Diameter SIP application October 2003 Message Format ::= < Diameter Header: eee, REQ, PXY > < Session-Id > { Auth-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } [ Destination-Realm ] [ User-Name ] * [ SIP-AOR ] { SIP-Deregistration-Reason } * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] 7.10 Registration-Termination-Answer (RTA) Command The Registration-Termination-Answer (RTA) is indicated by the Command-Code set to eee and the Command Flags' 'R' bit cleared. The Diameter client sends this command in response to a previously received Diameter Registration-Termination-Request (RTR) command. In addition to the values already defined in RFC 3588 [2], the Result-Code AVP may contain one of the values defined in Section 8.17.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 xref="transient-failures-result-code-avp-values" /> and return it in a Diameter RTA message. Upon the reception of the Diameter RTA message, the SIP server will typically request authentication by sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) response back to the originator. The SIP server (Diameter client) will apply the administrative deregistration to each of the URIs included in each of the SIP-AOR AVP values, or, if there is no SIP-AOR AVP present in the Diameter RTR request, to all the URIs allocated to the User-Name AVP value. The value of the SIP-Deregistration-Reason AVP in the Diameter RTR command will have an effect on the actions performed at the SIP server (Diameter client): o If the value is set to PERMANENT_TERMINATION, then the user has Garcia-Martin, et al. Expires April 15, 2004 [Page 37] Internet-Draft Diameter SIP application October 2003 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, 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 ::= < Diameter Header: eee, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Authorization-Lifetime ] [ Auth-Grace-Period ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] * [ Redirect-Host ] Garcia-Martin, et al. Expires April 15, 2004 [Page 38] Internet-Draft Diameter SIP application October 2003 7.11 Push-Profile-Request (PPR) Command The Push-Profile-Request (PPR) command is indicated by the Command-Code set to fff and the Command Flags' 'R' bit set. The Diameter server sends this command to the Diameter client in a SIP server to update the user profile of an already registered user in that SIP server. Each user has a user profile associated with him/her. The profile may change with time, due to, e.g., addition of new services to the user. When the user profile changes, the Diameter server sends a Diameter Push-Profile-Request (PPR) command to the Diameter client in a SIP server, in order to start applying those new services. The Diameter server sends the new user profile in the SIP-User-Data AVP value. Message Format ::= < Diameter Header: fff, REQ, PXY > < Session-Id > { Auth-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ User-Name ] { SIP-User-Data } * [ SIP-AOR ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] OPEN ISSUE: clarify whether it is User-Name or SIP-AOR what is included, and if both are present, what is the role of each. 7.12 Push-Profile-Answer (PPA) Command The Push-Profile-Answer (PPA) is indicated by the Command-Code set to fff and the Command Flags' 'R' bit cleared. The Diameter client sends this command in response to a previously received Diameter Push-Profile-Request (PPR) command. In addition to the values already defined in RFC 3588 [2], the Garcia-Martin, et al. Expires April 15, 2004 [Page 39] Internet-Draft Diameter SIP application October 2003 Result-Code AVP may contain one of the values defined in Section 8.17.1. If the Diameter server requires a User-Name AVP value to process the Diameter PPR request, but the Diameter PPR message did not contain a User-Name AVP value, the Diameter server MUST set the Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see xref="transient-failures-result-code-avp-values" /> and return it in a Diameter PPA message. Upon the reception of the Diameter PPA message, the SIP server will typically request authentication by sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) response back to the originator. If there is no error when processing the received Diameter PPR message, the SIP server (Diameter client) MUST download the received user profile from the SIP-User-Data AVP value in the Diameter PPR message and stored for all the SIP AORs allocated to the User-Name AVP value. If the SIP server does not recognize or does not support some of the data transferred in the SIP-User-Data AVP value, the Diameter client in the SIP server MUST return a Diameter PPA message that includes a Result-Code AVP set to the value DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA. If the SIP server (Diameter client) receives a Diameter PPR message with a User-Name AVP that is unknown, the Diameter client MUST set the Result-Code AVP value to DIAMETER_ERROR_USER_UNKONWN and MUST return it to the Diameter server in a Diameter PPA message. If the SIP server (Diameter client) receives in the SIP-User-Data AVP value more data than it can accept, it MUST set the Result-Code AVP value to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter server in a Diameter PPA message. The SIP server MUST NOT override the existing user profile with that received in the PPR message. If the Diameter server receives the Result-Code AVP value set to DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD force a new re-registration of the user by sending to the Diameter client a Diameter Registration-Termination-Request (RTR) with the SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This will force a re-registration of the user, and will trigger a selection of a new SIP server. OPEN ISSUE: How to avoid that the same SIP server is chosen again, and we enter a loop. Garcia-Martin, et al. Expires April 15, 2004 [Page 40] Internet-Draft Diameter SIP application October 2003 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 ::= < Diameter Header: fff, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Auth-Session-State } { Origin-Host } { Origin-Realm } * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] * [ Redirect-Host ] 8. Diameter SIP application AVPs This section defines new AVPs used in this Diameter SIP application. Applications compliant to this specification MUST implement these AVPs. The list of AVPs defined in this Diameter SIP application is listed in Table 2 and Table 3 Garcia-Martin, et al. Expires April 15, 2004 [Page 41] Internet-Draft Diameter SIP application October 2003 +-------------------------------+------+-------------+--------------+ | AVP Name | AVP | Reference | Data-Type | | | Code | | | +-------------------------------+------+-------------+--------------+ | SIP-Visited-Network-Id | xx01 | Section 8.9 | UTF8String | | SIP-AOR | xx02 | Section 8.8 | UTF8String | | SIP-Server-URI | xx03 | Section 8.2 | UTF8String | | SIP-Server-Capabilities | xx04 | Section 8.3 | Grouped | | SIP-Mandatory-Capability | xx05 | Section | Unsigned32 | | | | 8.3.1 | | | SIP-Optional-Capability | xx06 | Section | Unsigned32 | | | | 8.3.2 | | | SIP-User-Data | xx07 | Section | OctectString | | | | 8.11 | | | SIP-Number-Auth-Items | xx08 | Section 8.6 | Unsigned32 | | SIP-Auth-Data-Item | xx09 | Section 8.5 | Grouped | | SIP-Item-Number | xx10 | Section | Unsigned32 | | | | 8.5.1 | | | SIP-Authentication-Scheme | xx11 | Section | OctectString | | | | 8.5.2 | | | SIP-Authenticate | xx12 | Section | OctectString | | | | 8.5.3 | | | SIP-Authorization | xx13 | Section | OctectString | | | | 8.5.4 | | | SIP-Authentication-Info | xx14 | Section | OctectString | | | | 8.5.5 | | | SIP-Authentication-Context | xx15 | Section | OctectString | | | | 8.5.6 | | | SIP-Confidentiality-Key | xx16 | Section | OctectString | | | | 8.14 | | | SIP-Integrity-Key | xx17 | Section | OctectString | | | | 8.15 | | | SIP-Server-Assignment-Type | xx18 | Section 8.4 | Enumerated | | SIP-Deregistration-Reason | xx19 | Section 8.7 | Grouped | | SIP-Reason-Code | xx20 | Section | Enumerated | | | | 8.7.1 | | | SIP-Reason-Info | xx21 | Section | UTF8String | | | | 8.7.2 | | | SIP-Accouting-Information | xx22 | Section 8.1 | Grouped | | SIP-Accounting-Server-URI | xx23 | Section | DiameterURI | | | | 8.1.1 | | | SIP-Credit-Control-Server-URI | xx24 | Section | DiameterURI | | | | 8.1.2 | | +-------------------------------+------+-------------+--------------+ Table 2 Garcia-Martin, et al. Expires April 15, 2004 [Page 42] Internet-Draft Diameter SIP application October 2003 +-------------------------------+------+-------------+--------------+ | AVP Name | AVP | Reference | Data-Type | | | Code | | | +-------------------------------+------+-------------+--------------+ | SIP-User-Authorization-Type | xx25 | Section | Enumerated | | | | 8.10 | | | SIP-User-Data-Request-Type | xx26 | Section | Enumerated | | | | 8.13 | | | SIP-User-Data-Already-Availab | xx27 | Section | Enumerated | | le | | 8.12 | | | SIP-Method | xx28 | Section | UTF8String | | | | 8.16 | | +-------------------------------+------+-------------+--------------+ Table 3 8.1 SIP-Accounting-Information AVP The SIP-Accounting-Information (AVP code TBD) is of type Grouped, and contains the Diameter addresses of those nodes that are able to collect accounting information. The Grouped Data field has the following ABNF grammar: SIP-Accounting-Information :: = < AVP Header: TBD > * [ SIP-Accounting-Server-URI ] * [ SIP-Credit-Control-Server-URI ] * [ AVP] 8.1.1 SIP-Accounting-Server-URI AVP The SIP-Accounting-Server-URI AVP (AVP Code TBD) is of type DiameterURI. This AVP contains the address of a Diameter server that is able to receive SIP session related accounting information. 8.1.2 SIP-Credit-Control-Server-URI AVP The Credit-Control-Server-URI AVP (AVP Code TBD) is of type DiameterURI. This AVP contains the address of the a Diameter server that is able to authorize real-time credit control usage. The Diameter Credit Control Application [9] may be used for this purpose. 8.2 SIP-Server-URI AVP The SIP-Server-URI AVP (AVP Code TBD) is of type UTF8String. This AVP contains a SIP or SIPS URI (as defined in RFC 3261 [6]) that identifies a SIP server. Garcia-Martin, et al. Expires April 15, 2004 [Page 43] Internet-Draft Diameter SIP application October 2003 8.3 SIP-Server-Capabilities AVP The SIP-Server-Capabilities AVP (AVP Code TBD) is of type Grouped. The Diameter indicates in this AVP the requirements for a particular SIP capability, so that the Diameter client (SIP server) is able to select another appropriate SIP server to serve the user. SIP-Server-Capability ::= < AVP Header: TBD > * [ SIP-Mandatory-Capability ] * [ SIP-Optional-Capability ] * [ SIP-Server-URI ] * [ AVP ] 8.3.1 SIP-Mandatory-Capability AVP The SIP-Mandatory-Capability AVP (AVP Code TBD) is of type Unsigned32. The value represents a certain capability (or set of capabilities) that the SIP server to be allocated to the user has to fulfil. The semantics of the different values are not standardized, as it is a matter of the administrative network to allocate its own semantics within its own network. Each value has to represent a single capability within the administrative network. 8.3.2 SIP-Optional-Capability AVP The SIP-Optional-Capability AVP (AVP Code TBD) is of type Unsigned32. The value represents a certain capability (or set of capabilities) that the SIP server to be allocated may, optionally, fulfil. The semantics of the different values are not standardized, as it is a matter of the administrative network to allocate its own semantics within its own network. Each value has to represent a single capability within the administrative network. 8.4 SIP-Server-Assignment-Type AVP The SIP-Server-Assignment-Type AVP (AVP code TBD) is of type Enumerated, and indicates the type of server update being performed in a Diameter Server-Assignment-Request (SAR) operation. The following values are defined: o NO_ASSIGNMENT (0) The Diameter client uses this value to request the user profile of a SIP AOR, without affecting the registration state of such identity. Garcia-Martin, et al. Expires April 15, 2004 [Page 44] Internet-Draft Diameter SIP application October 2003 o REGISTRATION (1) First SIP registration of a SIP AOR. o RE_REGISTRATION (2) Subsequent SIP registration of a SIP AOR. o UNREGISTERED_USER (3) The SIP server has received a SIP request (e.g., SIP INVITE) addressed for a SIP AOR that is not registered. o TIMEOUT_DEREGISTRATION (4) The SIP registration timer of an identity has expired. o USER_DEREGISTRATION (5) The SIP server has received a request to de-register a SIP AOR. o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) The SIP registration timer of an identity has expired. The SIP server keeps the user data stored and requests the Diameter server to store the SIP server address. o USER_DEREGISTRATION_STORE_SERVER_NAME (7) The SIP server has received a user initiated de-registration request. The SIP server keeps the user data stored and requests the Diameter server to store the SIP server address. o ADMINISTRATIVE_DEREGISTRATION (8) The SIP server, due to administrative reasons, has de-registered a SIP AOR. o AUTHENTICATION_FAILURE (9) The authentication of a user has failed. o AUTHENTICATION_TIMEOUT (10) The authentication timer has expired. o DEREGISTRATION_TOO_MUCH_DATA (11) The SIP server has requested user profile information from the Diameter server and has received a volume of data higher than it can accept. 8.5 SIP-Auth-Data-Item AVP The SIP-Auth-Data-Item (AVP code TDB) is of type Grouped, and contains the authentication and/or authorization information pertaining to a user. Garcia-Martin, et al. Expires April 15, 2004 [Page 45] Internet-Draft Diameter SIP application October 2003 SIP-Auth-Data-Item :: = < AVP Header: TBD > [ SIP-Item-Number ] [ SIP-Authentication-Scheme ] [ SIP-Authenticate ] [ SIP-Authorization ] [ SIP-Authentication-Info ] [ SIP-Authentication-Context ] [ SIP-Confidentiality-Key ] [ SIP-Integrity-Key ] * [ NAS-Session-Key ] * [ AVP ] 8.5.1 SIP-Item-Number AVP The SIP-Item-Number (AVP code TDB) is of type Unsigned32, and is included in a SIP-Auth-Data-Item grouped AVP in circumstances where there are multiple occurrences of SIP-Auth-Data-Item AVPs and the order of processing is relevant. The AVP indicates the order in which the Grouped SIP-Auth-Data-Item should be processed. Lower values of the SIP-Item-Number AVP indicate that the whole SIP-Auth-Data-Item SHOULD be processed before other SIP-Auth-Data-Item AVP that contain a higher value number in the SIP-Item-Number AVP. 8.5.2 SIP-Authentication-Scheme AVP The SIP-Authentication-Scheme AVP (AVP code TBD) is of type UTF8String and indicates the authentication scheme used in the authentication of SIP services. The currently defined value is "Digest", to indicate HTTP Digest authentication as defined in RFC 2617 [4]. NOTE: Although RFC 2617 [4]defines the Basic and Digest schemes for authenticating HTTP requests, RFC 3261 [6] has imported only HTTP Digest as a mechanism to provide authentication in SIP. 8.5.3 SIP-Authenticate AVP The SIP-Authenticate AVP (AVP code TBD) is of type UTF8String and contains the directive of the WWW-Authenticate or Proxy-Authenticate SIP header field values, if present, in a SIP response. OPEN ISSUE: need to replace the "data portion" term. That term does not exist in SIP. Probably the term refers to the "header field value". An example will also help the reader to understand what is contained in this AVP. Garcia-Martin, et al. Expires April 15, 2004 [Page 46] Internet-Draft Diameter SIP application October 2003 8.5.4 SIP-Authorization AVP The SIP-Authorization AVP (AVP code TBD) is of type UTF8String and contains the data portion of the Authorization or Proxy-Authorization SIP headers if present in a SIP request. OPEN ISSUE: need to replace the "data portion" term. That term does not exist in SIP. Probably the term refers to the "header field value". An example will also help the reader to understand what is contained in this AVP. 8.5.5 SIP-Authentication-Info AVP The SIP-Authentication-Info AVP (AVP Code TBD) is of type OctetString and contains additional authentication information that the Diameter server sends if the authentication scheme is Digest authentication. It follows the format defined in RFC 2617 [4], section 3.2.3, for the Authentication-Info Header. The contents of this AVP are mapped to the SIP Authentication-Info header. OPEN ISSUE: Referring to RFC 2617 is a very loose definition . Need to pinpoint what are the exact contents of the AVP, probably the "header field value". An example will also help the reader to understand what is contained in this AVP. OPEN ISSUE: it seems a bit strange that this AVP is of type OctetString whereas the previous ones, which are similar in contents, are of type UTF8String. In my opinion, this AVP should be of type UTF8String. 8.5.6 SIP-Authentication-Context AVP The SIP-Authentication-Context AVP (AVP code TBD) is of type OctectString, and contains authentication-related information relevant for performing the authentication but that is not part of the SIP authentication headers. Some authentication schemes, such us PGP [3], HTTP Digest with quality of protection set to auth-int [4] or HTTP Digest with predictive nonces [4], request that part of the SIP request is evaluated by the node performing authentication. In such cases the SIP-Authentication-Context AVP contains such data. Note that the actual contents of the AVP are depending on the authentication scheme. Garcia-Martin, et al. Expires April 15, 2004 [Page 47] Internet-Draft Diameter SIP application October 2003 8.6 SIP-Number-Auth-Items AVP The SIP-Number-Auth-Items AVP (AVP Code TBD) is of type Unsigned32 and indicates the number of authentication and/or authorization vectors that the Diameter server included in a Diameter message. When the AVP is present in a request, it indicates the number of SIP-Auth-Data-Items the Diameter client is requesting. This can be used, for instance, when the SIP server is requesting several pre-calculated authentication vectors. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual number of items that the Diameter server included. 8.7 SIP-Deregistration-Reason AVP The SIP-Deregistration-Reason AVP (AVP Code TBD) is of type Grouped, and indicates the reason for a deregistration operation. SIP-Deregistration-Reason::= < AVP Header: TBD > { SIP-Reason-Code } [ SIP-Reason-Info ] * [ AVP ] 8.7.1 SIP-Reason-Code AVP The SIP-Reason-Code AVP (AVP code TBD) is of type Enumerated, and defines the reason for the network initiated de-registration. The following values are defined: o PERMANENT_TERMINATION (0) o NEW_SIP_SERVER_ASSIGNED (1) o SIP_SERVER_CHANGE (2) o REMOVE_SIP_SERVER (3) 8.7.2 SIP-Reason-Info AVP The SIP-Reason-Info AVP (AVP code TBD) is of type UTF8String, and contains textual information that can be rendered to the user, about the reason for a de-registration. 8.8 SIP-AOR AVP The SIP-AOR AVP (AVP Code TBD) is of type UTF8String. The syntax of Garcia-Martin, et al. Expires April 15, 2004 [Page 48] Internet-Draft Diameter SIP application October 2003 this AVP corresponds either to a SIP URI (with the format defined in RFC 3261 [6]) or a TEL URL (with the format defined in RFC 2806 [5]). The Diameter client (SIP server) uses the value found in a SIP Request-URI or a header field value of the SIP request to construct the SIP-AOR AVP. The selection of a Request-URI or a particular header field depends on the semantics of the SIP message and whether the SIP server is acting for originating or terminating requests. For instance, when the SIP server receives an INVITE request addressed to the served user, it maps the SIP Request-URI of the SIP request to this AVP. However, when the SIP server receives an INVITE request originated by the served user, it can map either the P-Asserted-Identity or the From header field values to this AVP. 8.9 SIP-Visited-Network-Id AVP The SIP-Visited-Network-Id AVP (AVP Code TBD) is of type OctetString. This AVP contains an identifier that helps the home network to identify the visited network (e.g. the visited network domain name), in order to authorize roaming to such visited network. 8.10 SIP-User-Authorization-Type AVP The SIP-User-Authorization-Type AVP (AVP code TBD) is of type Enumerated, and indicates the type of user authorization being performed in a User Authorization operation, i.e., The Diameter User-Authorization-Request (UAR) command. The following values are defined: 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. 8.11 SIP-User-Data AVP The SIP-User-Data AVP (AVP Code TBD) is of type OctetString. The Garcia-Martin, et al. Expires April 15, 2004 [Page 49] Internet-Draft Diameter SIP application October 2003 Diameter peers do not need to understand the value of this AVP. The AVP contains the user profile data required for a SIP server to give service to the user. 8.12 SIP-User-Data-Already-Available AVP The SIP-User-Data-Already-Available AVP (AVP code TBD) is of type Enumerated, and gives an indication to the Diameter server about whether the Diameter client (SIP server) already got the portion of the user profile that it needs to serve the user. The following values are defined: o USER_DATA_NOT_AVAILABLE (0) The Diameter client (SIP server) does not have the data that it needs to serve the user. o USER_DATA_ALREADY_AVAILABLE (1) The Diameter client (SIP server) already has got the data that it needs to serve the user. 8.13 SIP-User-Data-Request-Type AVP The SIP-User-Data-Request-Type AVP (AVP code TBD) is of type Enumerated, and indicates the portion of the user profile that the Diameter client (SIP server) is requesting to the Diameter server. The following values are defined: o COMPLETE_PROFILE (0) The Diameter client (SIP server) requests the complete user profile corresponding to one or more SIP AORs. o REGISTERED_PROFILE (1) The Diameter client (SIP server) requests the portion of the user profile that deals with registered states of one or more SIP AORs. o UNREGISTERED_PROFILE (2) The Diameter client (SIP server) request the portion of the user profile that deals with unregistered states of one or more SIP AORs. 8.14 SIP-Confidentiality-Key AVP The SIP-Confidentiality-Key (AVP code TBD) is of type OctetString and contains the Confidentiality Key (CK). Garcia-Martin, et al. Expires April 15, 2004 [Page 50] Internet-Draft Diameter SIP application October 2003 8.15 SIP-Integrity-Key AVP The SIP-Integrity-Key (AVP code TBD) is of type OctetString and contains the Integrity Key (IK). 8.16 SIP-Method AVP The SIP-Method-AVP (AVP code TBD) is of type UTF8String and contains the method of the SIP request that triggered the Diameter message. 8.17 New values for existing AVPs This section defines new values that the Diameter SIP application extends to already existing AVPs. 8.17.1 Extension to the Result-Code AVP values The Result-Code AVP is already defined in RFC 3588 [2]. In addition to the values already defined in RFC 3588 [2], the Diameter SIP application defines the following new Result-Code AVP values: 8.17.1.1 Success Result-Code AVP values A Diameter peer uses Result-Code AVP values that fall into the success category to inform the remote peer that a request has been successfully completed. o DIAMETER_FIRST_REGISTRATION 2xx1 The user was not previously registered. The Diameter server has now authorized the registration. o DIAMETER_SUBSEQUENT_REGISTRATION 2xx2 The user is already registered. The Diameter server has now authorized the re-registration. o DIAMETER_UNREGISTERED_SERVICE 2xx3 The user is not currently registered, but the requested service can still be granted to the user. o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2xx4 The de-registration was successful. The Diameter server does not keep a record of the SIP server assigned to the user. o DIAMETER_SERVER_SELECTION 2xx5 The Diameter server has authorized the registration. The user has already a SIP server assigned, but it may be necessary to select a new SIP server for the user. Garcia-Martin, et al. Expires April 15, 2004 [Page 51] Internet-Draft Diameter SIP application October 2003 o DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2xx6 The requested operation was successfully executed. The Diameter server is sending authentication vectors in the answer message. The Diameter server does not keep a record of the SIP server. o DIAMETER_SUCCESS_SERVER_NOT_STORED 2xx7 The user was successfully authenticate. The Diameter server does not keep a record of the SIP server. 8.17.1.2 Transient Failures Result-Code AVP values A Diameter peer uses a Result-Code AVP value that falls in the transient failures category to inform the remote peer that a request could not be satisfied at the time it was received, but MAY be able to satisfy the request in the future. o DIAMETER_USER_NAME_REQUIRED 4xx1 The Diameter request did not contain a User-Name AVP, and it is required to complete the transaction. The Diameter peer MAY attempt the request again including a User-Name AVP. 8.17.1.3 Permanent failures Result-Code AVP values A Diameter peer uses a Result-Code AVP value that fall into the permanent failure category to inform the remote peer that the request failed and should not be attempted again. o DIAMETER_ERROR_USER_UNKNOWN 5xx1 The SIP-AOR AVP value does not belong to a known user in this realm. o DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5xx2 The value in one of the SIP-AOR AVPs is not allocated to the user specified in the User-Name AVP. o DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5xx3 A query for location information is received for a SIP AOR that has not been registered before. The user to which this identity belongs cannot be given service in this situation. o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5xx4 The user is not allowed to roam to the visited network. o DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5xx5 The identity being registered has already a server assigned and the registration status does not allow that it is overwritten. Garcia-Martin, et al. Expires April 15, 2004 [Page 52] Internet-Draft Diameter SIP application October 2003 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. o DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5xx9 The SIP server informs Diameter server that the received subscription data contained information which was not recognized or supported. 9. Authentication Details Authenticating a user can occur through various mechanisms (HTTP Digest authentication has currently been described), with the actual authentication being performed in either the SIP server or the Diameter server. The choice of the server will determine the AVPs to be utilized in the SIP-Auth-Data-Item grouped AVP, as well as a few AVPs in the Diameter MAR/MAA commands. If the SIP server performs the authentication of a user, the Diameter MAR message that the Diameter client in the SIP server sends to the Diameter server will include the User-Name and SIP-AOR AVPs as necessary, as well as a SIP-Number-Auth-Items AVP to indicate how many authentication vectors (the actual contents of the vector are dependent upon the authentication method) are being requested. In the Diameter MAA message, the Diameter server SHOULD indicate how many SIP-Auth-Data-Item AVPs are present with the SIP-Number-Auth-Items AVP. This number may be different from the one requested in the Diameter MAR message. If multiple SIP-Auth-Data-Item AVPs are present, and their ordering is significant, the Diameter server MUST include a SIP-Item-Number AVP in each grouping to indicate the order. The SIP-Authentication-Scheme and SIP-Authenticate AVPs will contain data (typically a challenge of some kind) that the user can use to authenticate itself. The SIP-Authorization AVP will contain the response which is expected from the user. In order to support some auth methods which combine key distribution with authentication, Garcia-Martin, et al. Expires April 15, 2004 [Page 53] Internet-Draft Diameter SIP application October 2003 SIP-Confidentiality-Key and SIP-Integrity-Key AVPs are included. If the Diameter server performs the authentication of the user, the Diameter MAR message that the Diameter client in the SIP server sends to the Diameter server will include a single SIP-Auth-Data-Item AVP. The SIP-Authentication-Scheme and SIP-Authorization AVPs will contain the relevant parameters from the SIP message, if present. If necessary, the SIP-Authentication-Context AVP will contain any additional information needed to perform the authentication. If the authentication is successful, the Diameter MAA message will contain a Result-Code AVP indicating success, and if necessary, the SIP-Auth-Data-Item AVP may be included to carry session keys back to the SIP server. If the authentication is unsuccessful due to missing credentials, the Diameter MAA message will include an SIP-Auth-Data-Item with the SIP-Authentication-Scheme and SIP-Authenticate AVPs containing data (typically a challenge of some kind) that the user can use to authenticate itself. 10. IANA Considerations This document serves as IANA registration request of a number of items: 10.1 Application Identifier This document defines a standards track Application-ID in the Diameter [2] Application Identifier address space. Application name: Diameter Session Initiation Protocol (SIP) Application. Application Identifier: XXX [IANA to replace XXX with the allocated number] 10.2 Command Codes This document defines new standard commands, whose Command Codes are to be allocated within the Command Codes address space in Diameter [2]. Table 1 in Section 7 contains the detailed list of Command names and Command codes that are part of this Diameter application. 10.3 AVP Codes This document defines new standard AVPs, whose AVP Codes are to be allocated within the AVP Codes address space in Diameter [2]. Garcia-Martin, et al. Expires April 15, 2004 [Page 54] Internet-Draft Diameter SIP application October 2003 Table 2 in Section 8 contains the detailed list of AVP names and AVP codes that are part of this Diameter application. 10.4 Additional values for the Result-Code AVP value This document defines new standard Result-Code AVP values to be allocated within the Result-Code AVP address space defined in Diameter [2]. Section 8.17.1.1 lists the new Result-Code AVP values that fall into the success category, according to RFC 3588 [2] section 7.1.2. Section 8.17.1.2 lists the new Result-Code AVP values that fall into the transient failure category, according to RFC 3588 [2] section 7.1.4. Section 8.17.1.3 lists the new Result-Code AVP values that fall into the permanent failures category, according to RFC 3588 [2] section 7.1.5. 11. Acknowledgements The authors would like to thank Tony Johansson and Kevin Purser for their invaluable contribution to the start up of this application and the continuous progress. The authors would like to thank Daniel Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior and participants in the 3GPP CN4 working group for their valuable comments. 12. Changes with respect previous versions 12.1 Changes from draft-belinchon-aaa-diameter-mm-app-01.txt to draft-ietf-aaa-diameter-sip-app-00.txt o Application name changed to Diameter SIP application. o New Definitions section added. o New Applicability section added. o The problem of locating a Diameter server is addressed with the introduction of a new Diameter Subscriber Locator role. o Added new scenarios to indicate usage in a more generic internet environment. o A few AVPs have been renamed to accurately reflect the intention of the AVP. For instance, SIP-Server-Name becomes SIP-Server-URI, Garcia-Martin, et al. Expires April 15, 2004 [Page 55] Internet-Draft Diameter SIP application October 2003 and SIP-Public-User-ID becomes SIP-AOR. o MAR can be used more genericly. Particularly, it does not assumes a SIP REGISTER message. So we had to add a new SIP-Method AVP to indicate the SIP method that triggered the MAR command. o User-Name is no longer mandatory in requests, as typically a SIP request will not contain a user name. As a result of this change, a new transit failure Result-Code AVP value has been added: DIAMETER_USER_NAME_REQUIRED, to indicate the Diameter client that the request didn't include a User-Name AVP and it is required to process it. Typically SIP servers, upon the reception of this Result-Code AVP value, will generate a SIP 401 (Unauthorized) or 407 (Proxy Authentication Required) to request the user name from the user. o IANA section has been carefully rewritten to give detailed instructions to IANA on what is required to register. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Informational References [3] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [5] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [7] Calhoun, P., Johansson, T. and C. Perkins, "Diameter Mobile IPv4 Application", draft-ietf-aaa-diameter-mobileip-14 (work in progress), April 2003. [8] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter Garcia-Martin, et al. Expires April 15, 2004 [Page 56] Internet-Draft Diameter SIP application October 2003 Network Access Server Application", draft-ietf-aaa-diameter-nasreq-12 (work in progress), July 2003. [9] Hakala, H., "Diameter Credit-control Application", draft-ietf-aaa-diameter-cc-00 (work in progress), June 2003. Authors' Addresses Miguel A. Garcia Martin (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: miguel.a.garcia@ericsson.com Maria-Carmen Belinchon Ericsson Via de los Poblados 13 Madrid 28033 Spain Phone: +34 91 339 3535 EMail: maria.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 April 15, 2004 [Page 57] Internet-Draft Diameter SIP application October 2003 Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566-7050 US Phone: +1 630 713 9359 EMail: mccap@lucent.com Jaakko Rajaniemi Nokia Networks P.O.Box 301 Nokia Group 00045 Finland Phone: +358 50 3391387 EMail: jaakko.rajaniemi@nokia.com Kalle Tammi Nokia Networks P.O.Box 301 Nokia Group 00045 Finland EMail: kalle.tammi@nokia.com Garcia-Martin, et al. Expires April 15, 2004 [Page 58] Internet-Draft Diameter SIP application October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Garcia-Martin, et al. Expires April 15, 2004 [Page 59] Internet-Draft Diameter SIP application October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Garcia-Martin, et al. Expires April 15, 2004 [Page 60]