idnits 2.17.1 draft-ietf-aaa-diameter-sip-app-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2975. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2991), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 68 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([7], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 970 has weird spacing: '...ED (see and r...' == Line 1207 has weird spacing: '...ED (see and r...' == Line 1533 has weird spacing: '...ED (see and r...' == Line 1689 has weird spacing: '...ED (see and r...' == Line 1802 has weird spacing: '...ED (see and r...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 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 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2004) is 7231 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2617 (ref. '2') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3310 (ref. '4') ** Obsolete normative reference: RFC 3588 (ref. '5') (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 2806 (ref. '6') (Obsoleted by RFC 3966) == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-18 == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-14 == Outdated reference: A later version (-06) exists of draft-ietf-aaa-diameter-cc-05 Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA Working Group M. Garcia-Martin, Ed. 2 Internet-Draft Nokia 3 Expires: January 6, 2005 M. Belinchon 4 M. Pallares-Lopez 5 C. Canales 6 Ericsson 7 K. Tammi 8 Nokia 9 July 8, 2004 11 Diameter Session Initiation Protocol (SIP) Application 12 draft-ietf-aaa-diameter-sip-app-03 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 6, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document specifies the Diameter Session Initiation Protocol 46 (SIP) Application. This is a Diameter application that allows a 47 Diameter client to request authentication and authorization 48 information. This application is designed to be used in conjunction 49 with the Session Initiation Protocol (SIP), and provides a Diameter 50 client in a SIP server with the ability to request a Diameter server 51 the authentication of users and authorization of SIP resources usage. 52 This application does not require or is not related to other 53 authentication services provided by the Mobile IP Diameter [7] or the 54 Network Access Server Diameter [8] applications. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Overview of operation . . . . . . . . . . . . . . . . . . . 7 63 5.1 General architecture . . . . . . . . . . . . . . . . . . . 7 64 5.2 Diameter server authenticates the user . . . . . . . . . . 9 65 5.3 Diameter server delegates authentication to the SIP 66 server . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.4 SIP server authenticates a request . . . . . . . . . . . . 14 68 5.5 Session attempt . . . . . . . . . . . . . . . . . . . . . 16 69 5.6 Update of the user profile . . . . . . . . . . . . . . . . 17 70 5.7 SIP soft state termination . . . . . . . . . . . . . . . . 18 71 5.8 Diameter server discovery . . . . . . . . . . . . . . . . 19 72 6. Advertising Application Support . . . . . . . . . . . . . . 21 73 7. Diameter SIP application Command Codes . . . . . . . . . . . 22 74 7.1 User-Authorization-Request (UAR) Command . . . . . . . . . 22 75 7.2 User-Authorization-Answer (UAA) Command . . . . . . . . . 23 76 7.3 Server-Assignment-Request (SAR) Command . . . . . . . . . 27 77 7.4 Server-Assignment-Answer (SAA) Command . . . . . . . . . . 28 78 7.5 Location-Info-Request (LIR) Command . . . . . . . . . . . 32 79 7.6 Location-Info-Answer (LIA) Command . . . . . . . . . . . . 32 80 7.7 Multimedia-Auth-Request (MAR) Command . . . . . . . . . . 35 81 7.8 Multimedia-Auth-Answer (MAA) Command . . . . . . . . . . . 36 82 7.9 Registration-Termination-Request (RTR) Command . . . . . . 39 83 7.10 Registration-Termination-Answer (RTA) Command . . . . . 40 84 7.11 Push-Profile-Request (PPR) Command . . . . . . . . . . . 42 85 7.12 Push-Profile-Answer (PPA) Command . . . . . . . . . . . 42 86 8. Diameter SIP application AVPs . . . . . . . . . . . . . . . 44 87 8.1 SIP-Accounting-Information AVP . . . . . . . . . . . . . . 46 88 8.1.1 SIP-Accounting-Server-URI AVP . . . . . . . . . . . . 46 89 8.1.2 SIP-Credit-Control-Server-URI AVP . . . . . . . . . . 46 90 8.2 SIP-Server-URI AVP . . . . . . . . . . . . . . . . . . . . 47 91 8.3 SIP-Server-Capabilities AVP . . . . . . . . . . . . . . . 47 92 8.3.1 SIP-Mandatory-Capability AVP . . . . . . . . . . . . . 47 93 8.3.2 SIP-Optional-Capability AVP . . . . . . . . . . . . . 47 94 8.4 SIP-Server-Assignment-Type AVP . . . . . . . . . . . . . . 48 95 8.5 SIP-Auth-Data-Item AVP . . . . . . . . . . . . . . . . . . 48 96 8.5.1 SIP-Authentication-Scheme AVP . . . . . . . . . . . . 49 97 8.5.2 SIP-Item-Number AVP . . . . . . . . . . . . . . . . . 49 98 8.5.3 SIP-Authenticate AVP . . . . . . . . . . . . . . . . . 50 99 8.5.4 SIP-Authorization AVP . . . . . . . . . . . . . . . . 50 100 8.5.5 SIP-Authentication-Info AVP . . . . . . . . . . . . . 50 101 8.5.6 SIP-Authentication-Context AVP . . . . . . . . . . . . 51 102 8.5.7 Digest-Realm AVP . . . . . . . . . . . . . . . . . . . 52 103 8.5.8 Digest-Domain AVP . . . . . . . . . . . . . . . . . . 52 104 8.5.9 Digest-Nonce AVP . . . . . . . . . . . . . . . . . . . 52 105 8.5.10 Digest-Opaque AVP . . . . . . . . . . . . . . . . . 52 106 8.5.11 Digest-Stale AVP . . . . . . . . . . . . . . . . . . 52 107 8.5.12 Digest-Algorithm AVP . . . . . . . . . . . . . . . . 53 108 8.5.13 Digest-Qop AVP . . . . . . . . . . . . . . . . . . . 53 109 8.5.14 Digest-Auth-Param AVP . . . . . . . . . . . . . . . 53 110 8.5.15 Digest-Username AVP . . . . . . . . . . . . . . . . 53 111 8.5.16 Digest-Digest-URI AVP . . . . . . . . . . . . . . . 54 112 8.5.17 Digest-Response AVP . . . . . . . . . . . . . . . . 54 113 8.5.18 Digest-Cnonce AVP . . . . . . . . . . . . . . . . . 54 114 8.5.19 Digest-Nonce-Count AVP . . . . . . . . . . . . . . . 54 115 8.5.20 Digest-Nextnonce AVP . . . . . . . . . . . . . . . . 54 116 8.5.21 Digest-Response-Auth AVP . . . . . . . . . . . . . . 54 117 8.5.22 Digest-AKA-Auts AVP . . . . . . . . . . . . . . . . 55 118 8.5.23 Digest-Expected-Response AVP . . . . . . . . . . . . 55 119 8.6 SIP-Number-Auth-Items AVP . . . . . . . . . . . . . . . . 55 120 8.7 SIP-Deregistration-Reason AVP . . . . . . . . . . . . . . 56 121 8.7.1 SIP-Reason-Code AVP . . . . . . . . . . . . . . . . . 56 122 8.7.2 SIP-Reason-Info AVP . . . . . . . . . . . . . . . . . 56 123 8.8 SIP-AOR AVP . . . . . . . . . . . . . . . . . . . . . . . 56 124 8.9 SIP-Visited-Network-Id AVP . . . . . . . . . . . . . . . . 56 125 8.10 SIP-User-Authorization-Type AVP . . . . . . . . . . . . 57 126 8.11 SIP-User-Data AVP . . . . . . . . . . . . . . . . . . . 57 127 8.12 SIP-User-Data-Already-Available AVP . . . . . . . . . . 57 128 8.13 SIP-User-Data-Request-Type AVP . . . . . . . . . . . . . 58 129 8.14 SIP-Method AVP . . . . . . . . . . . . . . . . . . . . . 58 130 8.15 New values for existing AVPs . . . . . . . . . . . . . . 58 131 8.15.1 Extension to the Result-Code AVP values . . . . . . 58 132 9. Authentication Details . . . . . . . . . . . . . . . . . . . 60 133 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 61 134 10.1 Application Identifier . . . . . . . . . . . . . . . . . 61 135 10.2 Command Codes . . . . . . . . . . . . . . . . . . . . . 62 136 10.3 AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 62 137 10.4 Additional values for the Result-Code AVP value . . . . 62 138 11. Security Considerations . . . . . . . . . . . . . . . . . . 62 139 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 62 140 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 141 14. Changes with respect previous versions . . . . . . . . . . . 63 142 14.1 Changes in draft-ietf-aaa-diameter-sip-app-03.txt 143 from -02.txt . . . . . . . . . . . . . . . . . . . . . . 63 144 14.2 Changes in draft-ietf-aaa-diameter-sip-app-02.txt 145 from -01.txt . . . . . . . . . . . . . . . . . . . . . . 63 146 14.3 Changes in draft-ietf-aaa-diameter-sip-app-01.txt 147 from -00.txt . . . . . . . . . . . . . . . . . . . . . . 64 148 14.4 Changes in draft-ietf-aaa-diameter-sip-app-00.txt 149 from draft-belinchon-aaa-diameter-mm-app-01.txt . . . . 64 150 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 151 15.1 Normative References . . . . . . . . . . . . . . . . . . . 65 152 15.2 Informational References . . . . . . . . . . . . . . . . . 66 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 66 154 Intellectual Property and Copyright Statements . . . . . . . 68 156 1. Terminology 158 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 159 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 160 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 161 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 162 compliant implementations. 164 2. Definitions 166 For the purpose of this document, the following terms and definitions 167 apply. 169 o 'Node: ' an addressable device attached to a computer network that 170 implements SIP functionality, Diameter functionality or a 171 combination of both. 173 For the purpose of this document, the following terms and definitions 174 given in RFC 3261 [3] section 6, apply: 176 o 'Address-of-Record (AOR)' 177 o 'Outbound proxy' 178 o 'Proxy' 179 o 'Server (SIP server)' 180 o 'User Agent (UA)' 181 o 'User Agent Client (UAC)' 183 For the purpose of this document, the following terms and definitions 184 given in RFC 3588 [5] section 1.3, apply: 186 o 'Authorization' 187 o 'Authentication' 188 o 'AVP' 189 o 'Diameter Client' 190 o 'Diameter Server' 191 o 'Home Realm' 192 o 'Redirect Agent' 193 o 'User' 195 3. Introduction 197 This document specifies the Diameter Session Initiation Protocol 198 (SIP) Application. This is a Diameter application that allows a 199 Diameter client to request authentication and authorization 200 information to a Diameter server for Session Initiation Protocol 201 (SIP) [3] based IP multimedia services. We assume that the SIP 202 server and the Diameter client are located in the same node, so that 203 the SIP server is able to receive and process SIP requests and 204 responses which in turn relies on the AAA infrastructure for 205 authenticating the SIP request and authorizing the usage of 206 particular SIP services. 208 This document provides Diameter procedures to implement certain 209 required functionality when SIP is the protocol chosen to initiate 210 and tear-down multimedia sessions or when SIP is used for other 211 non-session related applications. However, this document does not 212 mandate any particular mapping of SIP procedures to Diameter SIP 213 application procedures, nor does it mandate any particular sequence 214 of events between SIP and Diameter. This document provides useful 215 examples to show the interaction between SIP and the Diameter SIP 216 application in order to achieve the desired functionality. 218 The Applicability section (Section 4) discusses assumptions and 219 configurations assumed by this document. 221 The Overview of Operation chapter (Section 5) provides the reader 222 with informative descriptions of the Diameter SIP application 223 commands and responses and some guidance to their linkage with SIP 224 procedures. 226 Advertising of this application is described in the Advertising 227 Application Support chapter (Section 6). 229 The Diameter SIP application Command Codes chapter (Section 7) 230 provides a normative description of all the new Diameter commands 231 defined by this specification. 233 This application extends the Result-Code Attribute-Value-Pair (AVP) 234 with some new values. Further information is described in the New 235 values for existing AVPs chapter (Section 8.15). 237 This application defines some new AVPs. All these AVPs are described 238 in the Diameter SIP application AVPs chapter (Section 8). 240 Some extra information about authentication is provided in the 241 Authentication details chapter (Section 9). 243 4. Applicability 245 This document assumes a general architecture where a Home Realm is 246 composed of one or more nodes implementing Diameter or SIP functions. 247 At least, one of such nodes implements the Diameter Server 248 functionality and the Diameter Server has access to a user database. 249 The user data associated to a particular user is stored in a single 250 point in the network referred to as the user database. There may be 251 more than a single Diameter Server in the network, and all these 252 servers have access to such user database. But at a given time, the 253 data a Diameter Server returns is independent of the Diameter Server 254 that returns the information. 256 Central to the architecture is the fact that the user data is 257 stored in a single point in the network. This restriction does 258 not mandate a particular implementation, e.g., it is possible to 259 implement clusters of databases operating in mirror mode to 260 provide redundancy. The property required by this specification 261 is that the user data the Diameter Server has access to is stored 262 safely in what, from the external point of view, is seen as a 263 single user database. 265 This document allows several configurations of the Home Realm. In 266 one of such configurations, a SIP server is allocated to a user for 267 the purpose of triggering and executing services. The allocation of 268 the SIP server may be done dynamically, e.g., at the time the user 269 registers in the network. This configuration requires a SIP server, 270 typically located at the edge of the network, that is able to 271 allocate another SIP server for the user and also supports routing of 272 SIP requests and responses towards that allocated SIP server. Both 273 SIP server nodes implement a Diameter Client. 275 In another configuration, the address of a SIP outbound proxy is 276 configured (by means outside the scope of this specification) into 277 the SIP endpoint. The outbound Diameter Client in the SIP outbound 278 proxy node authenticates the user, requests authorization for SIP 279 requests and performs accounting activities. 281 5. Overview of operation 283 This section provides an informative description of how the Diameter 284 SIP application can be used together with SIP. This section is not 285 intended to mandate any specific usage of the Diameter SIP 286 application nor does it mandate a specific mapping between SIP and 287 Diameter messages. This section is a collection of examples that 288 show how the required AAA functionality can be achieved in 289 conjunction with SIP. 291 5.1 General architecture 293 The Diameter SIP application can be used in a SIP environment where 294 an interface to a AAA infrastructure is required to authenticate, 295 authorize or provide accounting information. Figure 1 below shows a 296 general overview of the integration of the SIP architecture with the 297 AAA architecture. 299 According to Figure 1, there is one or more SIP User Agents (UA) that 300 initiate or terminate SIP traffic through one or more SIP servers. 301 Both SIP servers implement a Diameter client that supports the 302 Diameter application described in this specification. 304 +--------+ 305 UAR/UAA +--->|Diameter|<----+ PPR/PPA 306 LIR/LIA | | server | | MAR/MAA 307 | +--------+ | SAR/SAA 308 | | RTR/RTA 309 | | 310 v v 311 +------+ SIP +--------+ SIP +--------+ SIP +------+ 312 | SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP | 313 | UA | |server 1| |server 2| | UA | 314 +------+ +--------+ +--------+ +------+ 315 ^ ^ 316 UAR/UAA | | PPR/PPA 317 LIR/LIA | | MAR/MAA 318 | +--------+ | SAR/SAA 319 +--->|Diameter|<----+ RTR/RTA 320 | SL | 321 +--------+ 323 Figure 1: Architecture of the Diameter application for SIP 325 In Figure 1, it can be seen that SIP server 1 sends different 326 Diameter commands and receives different responses to those sent and 327 received by SIP server 2. This is because SIP server 1 in Figure 1 328 is located at the edge of a network, and its main task is to locate 329 SIP server 2. SIP server 2 is requesting and receiving 330 authentication and authorization data from the Diameter server and is 331 not located at the edge of the network. 333 The Diameter Subscriber Locator (SL) serves for the purposes of 334 locating the Diameter server that contains the user related data. 335 Its functionality is further described in Section 5.8. 337 It should be noted that this document does not mandate any particular 338 SIP/AAA architecture. However, the Diameter SIP application provides 339 the functionality needed to accommodate all the different 340 architectures where SIP and Diameter are used. 342 The following subsections provide an informative overview of the 343 Diameter SIP application, its commands, and a possible interaction 344 with SIP signaling. 346 5.2 Diameter server authenticates the user 348 This is the generic mechanism to authenticate users. In this 349 approach we show an example of an administrative network where the 350 Diameter server is authenticating SIP user requests. This could be 351 the case of a medium size network where the Diameter server is 352 keeping user records and authenticating SIP requests to perform a 353 certain transaction. We have chosen to show a SIP REGISTER request 354 in the example, but the SIP server could request authentication of 355 any other SIP request. 357 +--------+ +--------+ +--------+ 358 | SIP | |Diameter| | SIP | 359 |server 1| | server | |server 2| 360 +--------+ +--------+ +--------+ 361 | | | 362 1. SIP REGISTER | | | 363 ---------------->| 2. UAR | | 364 |------------------>| | 365 | 3. UAA | | 366 |<------------------| | 367 | 4. SIP REGISTER | 368 |-------------------------------------->| 369 | | 5. MAR | 370 | |<------------------| 371 | | 6. MAA | 372 | |------------------>| 373 | 7. 401 (Unauthorized) | 374 8. 401 (Unauth.) |<--------------------------------------| 375 -----------------| | | 376 9. SIP REGISTER | | | 377 ---------------->| 10. UAR | | 378 |------------------>| | 379 | 11. UAA | | 380 |<------------------| | 381 | 12. SIP REGISTER | 382 |-------------------------------------->| 383 | | 13. MAR | 384 | |<------------------| 385 | | 14. MAA | 386 | |------------------>| 387 | 15. 200 (OK) | | 388 16. 200 (OK) |<--------------------------------------| 389 <----------------| | | 390 | | 17. SAR | 391 | |<------------------| 392 | | 18. SAA | 393 | |------------------>| 394 | | | 396 Figure 2: Authentication performed in the Diameter server 398 According to Figure 2 a SIP User Agent Client (UAC) sends a SIP 399 REGISTER request (step 1) to its home domain. SIP server 1 will 400 receive the SIP request. We assume that this SIP server may be 401 located, e.g., at the edge of the administrative home domain. The 402 Diameter client in SIP server 1 will contact its Diameter server by 403 sending a Diameter User-Authorization-Request (UAR) message (step 2) 404 to determine if this user is allowed to receive service, and if so, 405 request the address of a local SIP server capable of handling this 406 user. The Diameter server will answer with a Diameter 407 User-Authorization-Answer (UAA) message (step 3), which will indicate 408 either a list of capabilities that SIP server 1 may use to select an 409 appropriate SIP server (SIP server 2) or a SIP or SIPS URI pointing 410 to SIP server 2. 412 SIP server 1 will forward the SIP REGISTER request (step 4) to an 413 appropriate SIP server (SIP server 2). The Diameter client in SIP 414 server 2 will then request user authentication from the Diameter 415 server by sending a Diameter Multimedia-Auth-Request (MAR) message 416 (step 5). This request will also serve to make the Diameter server 417 aware of the SIP or SIPS URI of SIP server 2, so as to return 418 subsequent requests for the same user to the same SIP server 2. The 419 Diameter server will respond with a Diameter Multimedia-Auth-Answer 420 (MAA) message (step 6) with Result-Code AVP set to the value 421 DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a 422 challenge, which SIP server 2 will use to map into the 423 WWW-authentication header in the SIP 401 (Unauthorized) response 424 (step 7), which is sent back to SIP server 1 and then to the SIP UAC 425 (step 8). 427 SIP server 1 will receive a next SIP REGISTER request containing the 428 user credentials (step 9). Note that SIP server 1 does not need to 429 keep a state, and even more, there is no guarantee that the SIP 430 request will arrive at the same SIP server 1, there could be a farm 431 of SIP servers 1 operating in redundant configuration. The Diameter 432 client in SIP server 1 will contact a Diameter server by sending a 433 Diameter UAR message (step 10) to determine the SIP server allocated 434 to the user. The Diameter server will send the SIP or SIPS URI of 435 SIP server 2 in a Diameter UAA message (step 11). 437 SIP server 1 will then forward the SIP REGISTER request to SIP server 438 2 (step 12). SIP server 2 will extract the credentials from the SIP 439 REGISTER request. The Diameter client in SIP server 2 will send 440 those credentials in a Diameter MAR message (step 13) to the Diameter 441 server. At this point, the Diameter server will be able to 442 authenticate the user, and upon success, will return a Diameter MAA 443 message (step 14) with the AVP Result-Code set to the value 444 DIAMETER_SUCCESS. 446 SIP server 2 will then generate a SIP 200 (OK) response (step 15) 447 which is forwarded to SIP server 1 and eventually to the SIP UAC 448 (step 16). 450 If the Diameter client in SIP server 2 is interested in downloading 451 the user profile information, then it will send a Diameter SAR 452 message (step 17) to the Diameter server. The Diameter server will 453 reply with a Diameter SAA message (step 18) that contains the 454 requested user profile information. These actions are only needed 455 when the SIP server needs to retrieve a user profile used to provide 456 services to the served user. 458 5.3 Diameter server delegates authentication to the SIP server 460 An operator with a large base of installed SIP servers may wish to 461 minimize the impact of modifying SIP servers to interact with 462 Diameter servers. This can be achieved by allowing SIP servers to 463 retain the functionality of authentication, rather than centralizing 464 this capability in a Diameter server. However, it should be noted 465 that this mode will not leverage the extensive array of 466 authentication and authorization services which will already be 467 available in Diameter servers. It must be also noted that this 468 scenario is only applicable when the authentication of the user does 469 not use client nonces, since the mechanism is based on the 470 computation of an expected response in the Diameter server, which 471 makes it available to the SIP server. 473 +--------+ +--------+ +--------+ 474 | SIP | |Diameter| | SIP | 475 |server 1| | server | |server 2| 476 +--------+ +--------+ +--------+ 477 | | | 478 1. SIP REGISTER | | | 479 ---------------->| 2. UAR | | 480 |------------------>| | 481 | 3. UAA | | 482 |<------------------| | 483 | 4. SIP REGISTER | 484 |-------------------------------------->| 485 | | 5. MAR | 486 | |<------------------| 487 | | 6. MAA | 488 | |------------------>| 489 | 7. 401 (Unauthorized) | 490 8. 401 (Unauth.) |<--------------------------------------| 491 <----------------| | | 492 9. SIP REGISTER | | | 493 ---------------->| 10. UAR | | 494 |------------------>| | 495 | 11. UAA | | 496 |<------------------| | 497 | 12. SIP REGISTER | 498 |-------------------------------------->| 499 | | 13. SAR | 500 | |<------------------| 501 | | 14. SAA | 502 | |------------------>| 503 | 15. 200 (OK) | | 504 16. 200 (OK) |<--------------------------------------| 505 <----------------| | | 506 | | | 508 Figure 3: Delegation of authentication to the SIP server 510 Figure 3 shows an example where a SIP server is dynamically allocated 511 to serve a SIP User Agent with the support of the Diameter server. 512 This may be the case of certain architectures, such as that of the 513 3rd Generation Partnership Project (3GPP) IP Core Network Multimedia 514 Subsystem (IMS). 516 A first SIP server receives a SIP REGISTER request (step 1) whose 517 target is the home network domain. We assume that this SIP server 518 may be located, e.g., at the edge of the administrative home domain. 519 The Diameter client in this SIP server requests authorization from 520 the Diameter server to proceed with the registration, by sending a 521 Diameter User-Authorization-Request (UAR) message (step 2). The 522 message includes, among other Attribute-Value-Pairs (AVP), the SIP 523 address-of-record that is included in the SIP REGISTER request. The 524 Diameter server will verify the SIP address-of-record and, if it is a 525 valid defined user in the home network, will authorize the the 526 registration to proceed. The Diameter server will respond with a 527 Diameter User-Authorization-Answer (UAA) message (step 3), which will 528 inform the Diameter client/SIP server about the result of the user 529 authorization. In case of a successful authorization, the Diameter 530 UAA message will indicate either the address of a local SIP server 531 (SIP server 2 in Figure 3) or a list of capabilities that SIP server 532 1 may use to select an appropriate SIP server 2. 534 When the authorization is successful, SIP server 1 will forward the 535 SIP REGISTER request (step 4) to the appropriate SIP server (SIP 536 server 2). The Diameter client in SIP server 2 will then request 537 authentication parameters by sending a Diameter 538 Multimedia-Auth-Request (MAR) message (step 5) to the Diameter 539 server. This request will also serve to make the Diameter server 540 aware of the SIP or SIPS URI of SIP server 2, so as to return 541 subsequent requests of the same user to the same SIP server 2. The 542 Diameter server will respond with a Diameter Multimedia-Auth-Answer 543 (MAA) message (step 6), which will include all parameters necessary 544 for the designated authentication algorithm associated with the user. 545 Among others, the MAA message will include a Digest-Expected-Response 546 AVP that contains the expected response to the challenge provided by 547 the Diameter server. If the Digest-Expected-Response AVP is not 548 present in MAA, it indicates that authentication and authorization 549 will take place in the Diameter server, as per the scenario described 550 in Section 5.2. 552 SIP server 2 will then create a 401 (Unauthorized) SIP response (step 553 7) based on the challenge included in the MAA message, including the 554 authentication material needed by the SIP User Agent Client (UAC) to 555 include the appropriate credentials. SIP server 1 forwards the SIP 556 response to the SIP UAC (step 8). 558 When SIP server 1 receives a next SIP REGISTER request containing the 559 user credentials (step 9), as SIP server 1 does not need to keep a 560 state (even there is no guarantee that the SIP request arrives to the 561 same SIP server 1), the Diameter client in SIP server 1 will contact 562 again the Diameter server by sending a Diameter UAR message (step 10) 563 to determine the SIP server allocated to the user. The Diameter 564 server will send the SIP or SIPS URI of SIP server 2 in a Diameter 565 UAA message (step 11). 567 SIP server 1 will then forward the SIP REGISTER request to SIP server 568 2 (step 12). If the credentials include a client nounce, then SIP 569 server 2 falls back to the authentication in the Diameter server (see 570 Section 5.2>. Otherwise, SIP server 2 will validate the credentials 571 by comparing the response supplied by the SIP UA with the expected 572 response supplied by the Diameter server. 574 If the credentials are valid, SIP server will send a Diameter 575 Server-Assignment-Request (SAR) message (step 13) requesting the 576 Diameter server to store the SIP or SIPS URI of the SIP server that 577 is currently serving the user. The Diameter SAR message also serves 578 the purpose to request the Diameter server to send the user profile 579 to the SIP server. The Diameter server will respond with a Diameter 580 Server-Assignment-Answer (SAA) message (step 14). If the Result-Code 581 AVP value does not inform about an error, the User-Data AVP will 582 contain the information that SIP server 2 needs in order to provide a 583 service to the user. 585 SIP server 2 generates a SIP 200 (OK) response (step 15) that will be 586 forwarded to SIP server 1 and eventually to the SIP UAC (step 16). 588 5.4 SIP server authenticates a request 590 Figure 4 depicts a typical scenario where a stateless SIP proxy 591 requests authentication information and authorization to a Diameter 592 server, for the purpose of providing SIP routing services to a SIP 593 User Agent. The SIP proxy server may be configured as an outbound 594 SIP proxy, so that all the requests initiated by the SIP UA traverse 595 the SIP proxy. 597 According to Figure 4, a SIP User Agent sends a SIP request to its 598 outbound SIP proxy server. In this case, the message is a SIP INVITE 599 request (see step 1), but it could be any other SIP request. We 600 assume that this SIP request does not contain any credentials at this 601 time. The outbound SIP proxy server needs to authenticate and 602 authorize the proxy services offered to the user. The Diameter 603 client in the SIP server sends a Multimedia-Auth-Request (MAR) 604 message (step 2). The Diameter server sends a Multimedia-Auth-Answer 605 (MAA) message (step 3) that includes all the data necessary for the 606 SIP server to challenge the user, typically with HTTP Digest 607 Authentication indicated in the MAA message. This data will serve 608 the SIP server to create a SIP 407 Proxy Authentication Required 609 response (step 4) that contains a challenge. The SIP UA will create 610 a new INVITE request (step 5) that contains the credentials. The 611 Diameter client in the SIP server will send the credentials to the 612 Diameter server in a new Diameter MAR message (step 6). The Diameter 613 server will validate the credentials and authorize the SIP 614 transaction in a Diameter MAA message (step 7). The SIP server 615 forwards the SIP INVITE request to its destination (step 8) as per 616 regular SIP procedures. Eventually, the session setup will be 617 confirmed with a 200 OK response (step 9) that is forwarded to the 618 SIP UA (step 10). The session setup is complete. 620 +--------+ +--------+ +--------+ 621 | UA | |Diameter| | SIP | 622 | | | server | | server | 623 +--------+ +--------+ +--------+ 624 | | | 625 | 1. SIP INVITE | 626 |---------------------------->| 627 | | 2. MAR | 628 | |<----------------| 629 | | 3. MAA | 630 | |---------------->| 631 | 4. SIP 407 Proxy | 632 | Authentication Required | 633 |<----------------------------| 634 | 5. SIP INVITE | 635 |---------------------------->| 636 | | 6. MAR | 637 | |<----------------| 638 | | 7. MAA | 639 | |---------------->| 8. SIP INVITE 640 | | |----------------> 641 | | | 9. SIP 200 OK 642 | 10. SIP 200 OK |<---------------- 643 |<----------------------------| 644 | | | 646 Figure 4: SIP server request authorization 648 5.5 Session attempt 650 Figure 5 shows the scenario where SIP server 1 may be configured as a 651 SIP edge proxy server, processing SIP traffic at the edge of a 652 network. SIP server 1 receives a SIP INVITE request (step 1). SIP 653 server 1 needs to find the address of SIP server 2, which is serving 654 the addressed UA. Therefore, the Diameter client in SIP server 1 655 sends Diameter Location-Info-Request (LIR) message (step 2) to the 656 Diameter server. The Diameter server responds with a Diameter 657 Location-Info-Answer (LIA) message (step 3) that contains the SIP or 658 SIPS URI of SIP server 2. SIP server 1 then forwards the SIP INVITE 659 to SIP server 2 (step 4). SIP server 2 will eventually forward the 660 SIP INVITE to the appropriate UAS (step 5). 662 +--------+ +--------+ +--------+ 663 | SIP | |Diameter| | SIP | 664 |server 1| | server | |server 2| 665 +--------+ +--------+ +--------+ 666 | | | 667 1. SIP INVITE | | | 668 -------------->| 2. LIR | | 669 |------------------>| | 670 | 3. LIA | | 671 |<------------------| | 672 | 4. SIP INVITE | 673 |-------------------------------------->| 674 | | | 5. SIP INVITE 675 | | |--------------> 676 | | | 677 | | | 679 Figure 5: SIP session attempt: locating the SIP server 681 Although the example shows the connection between a SIP INVITE 682 request and the Diameter LIR message, any other SIP request other 683 than REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the 684 same Diameter message (A SIP REGISTER request will trigger a Diameter 685 UAR message, as indicated in Figures Figure 2 and Figure 3. 687 5.6 Update of the user profile 689 The Diameter SIP application provides a mechanism for a Diameter 690 server to asynchronously download a user profile to a SIP server 691 whenever there is an update of such user profile. It must be noted 692 that the Diameter server also attaches the user profile in the 693 Diameter Server-Assignment-Answer (SAA) message. Although this is 694 valid for most of the daily situations, it may happen that the 695 administrator decides to update or modify the user profile for a 696 particular user, due to, e.g., new services made available to the 697 user. This may involve mechanisms outside the scope of this 698 specification, such as human intervention, in the Diameter server. 699 In this situation, the Diameter server is able to push the new user 700 profile into the SIP server allocated to the user. 702 The scenario is illustrated in Figure 6. Where the user profile 703 changes, the Diameter server will send a Diameter 704 Push-Profile-Request (PPR) message (step 1) to the Diameter client in 705 the SIP server allocated to that user (SIP server 2 in the examples). 706 The Diameter PPR message will contain a SIP-User-Data AVP, a 707 User-Name AVP and zero or more SIP-AOR AVPs. The Diameter client in 708 SIP server 2 will acknowledge the Diameter PPR message by sending a 709 Diameter Push-Profile-Answer (PPA) message (step 2) to the Diameter 710 server. 712 +--------+ +--------+ 713 |Diameter| | SIP | 714 | server | |server 2| 715 +--------+ +--------+ 716 | | 717 | 1. PPR | 718 |------------------>| 719 | | 720 | 2. PPA | 721 |<------------------| 722 | | 724 Figure 6: Diameter server pushes an update of the user profile 726 5.7 SIP soft state termination 728 SIP can create soft states in SIP nodes based on, e.g., SIP 729 registrations or SIP event subscriptions. These states are 730 periodically refreshed, and cease to exist if they are not refreshed. 731 Additionally, an administrative action can be taken to terminate a 732 SIP soft state, or the SIP UA can explicitly terminate a SIP soft 733 state. 735 The Diameter base protocol offers a mechanism to create and delete 736 states in Diameter nodes. These states are called Diameter user 737 sessions. The Diameter server decides whether to use a Diameter user 738 session as a mechanism to map to a SIP soft state. If the Diameter 739 server decides to use Diameter user sessions, the termination of a 740 Diameter user session implies the termination of the corresponding 741 SIP soft state (e.g., registration, event subscription), and vice 742 versa. If the Diameter server does not use Diameter user sessions, 743 this Diameter SIP application offers specific commands to manage the 744 SIP soft states. Implementations compliant to this specification 745 MUST support both mechanisms of session management. 747 Termination of the session can be initiated either by the Diameter 748 client or the Diameter server. We provide support for both Diameter 749 client and Diameter server initiated session termination. 751 Depending on whether Diameter sessions are used or not, termination 752 of a SIP soft state can be achieved by either of the following 753 methods: 755 When the Diameter client (SIP proxy) wants to terminate the SIP soft 756 state and Diameter user sessions are not maintained (i.e., the 757 Auth-Session-State AVP has been previously set to 758 NO_STATE_MAINTAINED), the Diameter client MUST send a 759 Server-Assignment-Request (SAR) message with the 760 SIP-Server-Assignment-Type AVP set to the value DE-REGISTRATION. 762 When the Diameter client (SIP proxy) wants to terminate the SIP soft 763 state and Diameter user sessions are maintained (i.e., the 764 Auth-Session-State AVP has been previously set to STATE_MAINTAINED) 765 the Diameter client MUST send a Session-Termination-Request message 766 as per regular procedures according to the RFC 3588 [5]. 768 When the Diameter server wants to terminate the SIP soft state and 769 Diameter user sessions are not maintained (i.e., the 770 Auth-Session-State AVP has been previously set to 771 NO_STATE_MAINTAINED), the Diameter server MUST send a 772 Registration-Termination-Request message (see Section 7.9). 774 When the Diameter server wants to terminate the SIP soft state and 775 Diameter user sessions are maintained (i.e., the Auth-Session-State 776 AVP has been previously set to STATE_MAINTAINED), the Diameter server 777 MUST send a client MUST send an Abort-Session-Request message as per 778 regular procedures according to the RFC 3588 [5]. 780 5.8 Diameter server discovery 782 The basic architecture assumption of this document is that all the 783 data related to a user is stored in a unique Diameter server. This 784 does not create a single point of failure, as it may be generally 785 thought. It is assumed that Diameter servers will be configured in a 786 redundant fashion as an attempt to mitigate the single point of 787 failure problem. 789 In large networks, where the number of users may be significantly 790 high, there might be a need to scale the number of Diameter servers. 791 All the data associated to a user will be still stored in a single 792 (typically redundant) Diameter server. But the data associated to 793 different users may reside in different Diameter servers. 795 This configuration, although scales well, introduces a new problem, 796 namely: giving the SIP AOR as an input, how to determine which of 797 various Diameter servers is storing the data for that particular SIP 798 AOR. We solve this problem by making usage of the standard Diameter 799 redirection mechanism specified in RFC 3588 [5]. We include in the 800 architecture a new Diameter node that, for the purpose of this 801 document, it is known as Diameter Subscriber Locator (SL). The 802 Diameter Subscriber Locator contains a database or routing tables 803 that maps SIP AORs with Diameter server URIs. A particular Diameter 804 server URI points to the actual Diameter server that stores all the 805 data related to a particular SIP AOR, and in consequence, to the user 806 who owns the SIP AOR. The Diameter Subscriber Locator acts as a 807 Diameter Redirect Agent, dispatching Diameter requests (e.g., 808 providing the redirection URI in the answer). 810 Note that according to the Diameter procedures the redirect 811 functionality in the Diameter client is performed automatically in 812 the Diameter stack, and it does not require any knowledge or 813 support by the Diameter application. 815 The Diameter SL can be replicated in different nodes along the 816 network, for the purpose of building scalability and redundancy. The 817 database or routing tables have to be consistent across all these 818 different Diameter SLs, so that equal Diameter requests will produce 819 the equal Diameter answers no matter which Diameter SL processes the 820 request. 822 +--------+ +--------+ +--------+ +--------+ 823 | SIP | |Diameter| |Diameter| | SIP | 824 |server 1| |SL red. | |server 1| |server 2| 825 +--------+ +--------+ +--------+ +--------+ 826 | | | | 827 1. SIP INVITE| | | | 828 ------------>| 2. LIR | | | 829 |---------->| | | 830 | 3. LIA | | | 831 |<----------| | | 832 | 4. LIR | | 833 |---------------------->| | 834 | 5. LIA | | 835 |<----------------------| | 836 | 6. SIP INVITE | | 837 |----------------------------------->| 7. SIP INVITE 838 | | | | -------------> 839 | | | | 841 Figure 7: Locating a Diameter server. SL redirecting requests 843 Figure 7 shows an example of operation of a Diameter Subscriber 844 Locator acting in redirect mode. SIP server 1 is receiving an INVITE 845 request (step 1) addressed (in the SIP Request-URI) to a user for 846 which the Diameter client in SIP server 1 does not posses routing 847 information. In other words, the Diameter client in SIP server 1 848 does not know the URI of Diameter server 1. The Diameter client 849 sends a Diameter LIR message (step 2) to any of the Diameter SLs 850 configured in the network. The address of those SLs is assumed to be 851 pre-provisioned in the Diameter client. The Diameter SL, based on 852 the contents of the SIP-AOR AVP and its own routing tables determines 853 the Diameter server that stores the information allocated to such 854 user. Then it builds a Diameter LIA message (step 3) that includes a 855 Result-Code AVP set to DIAMETER_REDIRECT_INDICATION and one or more 856 Redirect-Host AVPs, whose values are set to one or more URIs of 857 Diameter servers that store the information related to such user. 858 Then the Diameter client in SIP server 1 builds a new LIR message 859 addressed to any of the Diameter servers received in the 860 Redirect-Host AVPs. The rest of procedure is completed as described 861 in previous sections. 863 6. Advertising Application Support 865 Diameter implementations conforming to this specification MUST 866 advertise its support by including the Auth-Application-Id AVP in the 867 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 868 commands, according to the Diameter base protocol, RFC 3588 [5]. 870 7. Diameter SIP application Command Codes 872 All the Diameter implementations conforming to this specification 873 MUST implement and support the list of Diameter commands listed in 874 Table 1. 876 +----------------------------------+-------+-------+----------------+ 877 | Command Name | Abbr. | Code | Reference | 878 +----------------------------------+-------+-------+----------------+ 879 | User-Authorization-Request | UAR | aaa | Section 7.1 | 880 | User-Authorization-Answer | UAA | aaa | Section 7.2 | 881 | Server-Assignment-Request | SAR | bbb | Section 7.3 | 882 | Server-Assignment-Answer | SAA | bbb | Section 7.4 | 883 | Location-Info-Request | LIR | ccc | Section 7.5 | 884 | Location-Info-Answer | LIA | ccc | Section 7.6 | 885 | Multimedia-Auth-Request | MAR | ddd | Section 7.7 | 886 | Multimedia-Auth-Answer | MAA | ddd | Section 7.8 | 887 | Registration-Termination-Request | RTR | eee | Section 7.9 | 888 | Registration-Termination-Answer | RTA | eee | Section 7.10 | 889 | Push-Profile-Request | PPR | fff | Section 7.11 | 890 | Push-Profile-Answer | PPA | fff | Section 7.12 | 891 +----------------------------------+-------+-------+----------------+ 893 Table 1 895 7.1 User-Authorization-Request (UAR) Command 897 The User-Authorization-Request (UAR) is indicated by the Command-Code 898 set to aaa and the Command Flags' 'R' bit set. The Diameter client 899 in a SIP server sends this command to the Diameter server to request 900 authorization for the SIP User Agent to route a SIP REGISTER request. 901 As the SIP REGISTER request implicitly carries a permision to bind an 902 AOR to a contact address, the Diameter client uses the Diameter UAR 903 as a first authorization request towards the Diameter server to 904 authorize the registration. For instance, the Diameter server can 905 verify that the AOR is a legitimate user of the realm. 907 The Diameter client in the SIP server will request authorization of 908 the REGISTRATION, DE-REGISTRATION or REGISTRATION&CAPABILITIES 909 functions to the Diameter server. See more information in the 910 SIP-User-Authorization-Type AVP (Section 8.10). 912 The user name used for authentication of the user is conveyed in a 913 User-Name AVP (imported from the Diameter base protocol, RFC 3588 914 [5]). The location of the authentication user name in the SIP 915 REGISTER request varies depending on the authentication mechanism. 916 When the authentication mechanism is HTTP Digest as defined in RFC 917 2617 [2], the authentication user name is found in the "username" 918 directive of the SIP Authorization header field value. 920 The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP 921 (Section 8.8). Typically this SIP or SIPS URI is found in the To 922 header field value of the SIP REGISTER request that triggered the 923 Diameter UAR message. 925 The SIP-Visited-Network-Id AVP indicates the network that is 926 providing SIP services (e.g., SIP proxy functionality or any other 927 kind of services) to the SIP User Agent. 929 Message Format 930 ::= < Diameter Header: aaa, REQ, PXY > 931 < Session-ID > 932 < Auth-Application-Id > 933 { Auth-Session-State } 934 { Origin-Host } 935 { Origin-Realm } 936 { Destination-Realm } 937 { SIP-AOR } 938 [ Destination-Host ] 939 [ User-Name ] 940 [ SIP-Visited-Network-Id ] 941 [ SIP-User-Authorization-Type ] 942 * [ Proxy-Info ] 943 * [ Route-Record ] 944 * [ AVP ] 946 7.2 User-Authorization-Answer (UAA) Command 948 The User-Authorization-Answer (UAA) is indicated by the Command-Code 949 set to aaa and the Command Flags' 'R' bit cleared. The Diameter 950 server sends this command in response to a previously received 951 Diameter User-Authorization-Request (UAR) command. The Diameter 952 server indicates the result of the requested registration 953 authorization. Additionally, the Diameter serve may indicate the a 954 collection of SIP capabilities that assists the Diameter client to 955 select a SIP proxy to the AOR under registration. 957 In addition to the values already defined in RFC 3588 [5], the 958 Result-Code AVP may contain one of the values defined in Section 959 8.15.1. 961 Whenever the Diameter server fails to process the Diameter UAR 962 message, it MUST stop processing and return the concerned error in 963 the Diameter UAA message. When there is success in the process, the 964 Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter 965 UAA message. 967 If the Diameter server requires a User-Name AVP value to process the 968 Diameter UAR request, but the Diameter UAR message did not contain a 969 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 970 value to DIAMETER_USER_NAME_REQUIRED (see and return it in a 971 Diameter UAA message. Upon the reception of the Diameter UAA 972 message, the SIP server will typically request authentication by 973 sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) 974 response back to the originator. 976 When the authorization procedure succeeds, the Diameter server 977 constructs a User-Authorization-Answer (UAA) message that MUST 978 include the address of the SIP server already assigned to the user, 979 the capabilities needed by the SIP server (Diameter client) to select 980 another SIP server for the user or a combination of the previous two 981 options. 983 The Diameter UAA message contains the address of the SIP server 984 allocated to the user if the Diameter server is already aware of an 985 allocated SIP server to the user. 987 The Diameter UAA message contains the capabilities required by a SIP 988 server when there is a possibility that the Diameter client (in the 989 SIP server) needs to allocate another SIP server that will be 990 handling all the requests associated to this user, and possibly 991 triggering and executing services. 993 If a User-Name AVP is present in the Diameter UAR message, then the 994 Diameter server MUST verify the existence of the user in the realm, 995 i.e., the User-Name AVP value is a valid user within that realm. If 996 the Diameter server does not recognize the user name received in the 997 User-Name AVP, the Diameter server MUST build a Diameter 998 User-Authorization-Answer (UAA) message and MUST set the Result-Code 999 AVP to DIAMETER_ERROR_USER_UNKNOWN. 1001 If a User-Name AVP is present in the Diameter UAR message, then the 1002 Diameter server MUST authorize that User-Name AVP value is able to 1003 register the SIP or SIPS URI included in the SIP-AOR AVP. If this 1004 authorization fails, the Diameter server must set the Result-Code AVP 1005 to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1006 User-Authorization-Answer (UAA) message. 1008 Correlation between User-Name and SIP-AOR AVP values is required 1009 just to avoid that any user can register a SIP-AOR allocated to 1010 another user. 1012 If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message, 1013 and the SIP-User-Authorization-Type AVP value received in the 1014 Diameter UAR message is set to REGISTRATION or 1015 REGISTRATION&CAPABILITIES then the Diameter server SHOULD verify 1016 whether the user is allowed to roam into the network specified in the 1017 SIP-Visited-Network-Id AVP in the Diameter UAR message. If the user 1018 is not allowed to roam into such network, the Diameter AAA server 1019 MUST set the Result-Code AVP value in the Diameter UAA message to 1020 DIAMETER_ERROR_ROAMING_NOT_ALLOWED. 1022 If the SIP-User-Authorization-Type AVP value received in the Diameter 1023 UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES then 1024 the Diameter server SHOULD verify whether the SIP-AOR AVP value is 1025 authorized to register in the home realm. Where the SIP Address of 1026 Record is not authorized to register in the home realm, the Diameter 1027 server MUST set the Result-Code AVP to 1028 DIAMETER_AUTHORIZATION_REJECTED and send it in a Diameter UAA 1029 message. 1031 When the SIP-User-Authorization-Type AVP is not present in the 1032 Diameter UAR message, or it is present and its value is set to 1033 REGISTRATION then: 1035 o If the Diameter server is not aware of any previous registration 1036 of the user name (including registrations of other SIP Addresses 1037 of Record allocated to the same user name), then the Diameter 1038 server does not know of any SIP server allocated to the user. In 1039 this case the Diameter server MUST set the Result-Code AVP value 1040 to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and 1041 the Diameter server SHOULD include the required SIP server 1042 capabilities in the SIP-Server-Capabilities AVP value in the 1043 Diameter UAA message. The SIP-Server-Capabilities AVP will assist 1044 the Diameter client (SIP server) to select an appropriate SIP 1045 server for the user, according to the required capabilities. 1046 o In some cases, the Diameter server is aware of a previously 1047 assigned SIP server for the same or different SIP Addresses of 1048 Record allocated to the same user name. In these cases, 1049 re-assignment of a new SIP server may or may not be needed, 1050 depending on the capabilities of the SIP server. The Diameter 1051 server MUST always include the allocated SIP server URI in the 1052 SIP-Server-URI AVP of the UAA message. If the Diameter server 1053 does not return the SIP capabilities, the Diameter server MUST set 1054 the Result-Code AVP in the Diameter UAA message to 1055 DIAMETER_SUBSEQUENT_REGISTRATION. Otherwise, if the Diameter 1056 server includes a SIP-Server-Capabilities AVP then the Diameter 1057 server MUST set the Result-Code AVP in the Diameter UAA message to 1058 DIAMETER_SERVER_SELECTION. The Diameter client will then 1059 determine, based on the received information, whether it needs to 1060 select a new SIP server or not. 1062 When the SIP-User-Authorization-Type AVP value received in the 1063 Diameter UAR message is set to REGISTRATION&CAPABILITIES then 1064 Diameter Server MUST return the list of capabilities in the 1065 SIP-Server-Capabilities AVP value of the Diameter UAA message, it 1066 MUST set the Result-Code to DIAMETER_SUCCESS and it MUST NOT return a 1067 SIP-Server-URI AVP. The SIP-Server-Capabilities AVP enables the SIP 1068 server (Diameter Client) to select another appropriate SIP server for 1069 invoking and executing services for the user, depending on the 1070 required capabilities. The Diameter server MAY leave the list of 1071 capabilities empty to indicate that any SIP server can be selected. 1073 When the SIP-User-Authorization-Type AVP value received in the 1074 Diameter UAR message is set to DE-REGISTRATION then: 1076 o If the Diameter server is aware of a SIP server assigned to the 1077 SIP AOR under de-registration, the Diameter server MUST set the 1078 Result-Code AVP to DIAMETER_SUCCESS and MUST set the 1079 SIP-Server-URI AVP value to the known SIP server, and return them 1080 in the Diameter UAA message. 1081 o If the Diameter server is not aware of a SIP server assigned to 1082 the SIP AOR under de-registration, then the Diameter server MUST 1083 set the Result-Code AVP in the Diameter UAA message to 1084 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. 1086 Message Format 1087 ::= < Diameter Header: aaa, PXY > 1088 < Session-Id > 1089 { Auth-Application-Id } 1090 { Auth-Session-State } 1091 { Result-Code } 1092 { Origin-Host } 1093 { Origin-Realm } 1094 [ SIP-Server-URI ] 1095 [ SIP-Server-Capabilities ] 1096 [ Authorization-Lifetime ] 1097 [ Auth-Grace-Period ] 1098 * [ Redirect-Host ] 1099 [ Redirect-Host-Usage ] 1100 [ Redirect-Max-Cache-Time ] 1101 * [ Proxy-Info ] 1102 * [ Route-Record ] 1103 * [ AVP ] 1105 7.3 Server-Assignment-Request (SAR) Command 1107 The Server-Assignment-Request (SAR) command is indicated by the 1108 Command-Code set to bbb and the Command Flags' 'R' bit set. The 1109 Diameter client in a SIP server sends this command to the Diameter 1110 server in many cases to request the Diameter server to store the URI 1111 of the SIP server that is currently serving the user. The Diameter 1112 SAR command has the main function to inform and store/clear in the 1113 Diameter server the URI of the SIP server allocated to the user. 1114 Additionally, the Diameter client can request to download the user 1115 profile or part of it. 1117 During the registration procedure, a SIP server becomes assigned to 1118 the user. The Diameter client in the assigned SIP server MUST 1119 include its own URI in the SIP-Server-URI AVP of the 1120 Server-Assignment-Request (SAR) Diameter message and send it to the 1121 Diameter server. The Diameter server then becomes aware of the 1122 allocation of the SIP server and its URI. 1124 The Diameter client in the SIP server MAY send a Diameter SAR message 1125 because of other reasons. These reasons are identified in the 1126 SIP-Server-Assignment-Type AVP value (Section 8.4). For instance, a 1127 Diameter client in a SIP server may contact the Diameter server to 1128 request de-registration of a user, to inform the Diameter server of 1129 an authentication failure or just to download the user profile. For 1130 a complete description of all the SIP-Server-Assignment-Type AVP 1131 values see Section 8.4. 1133 Typically the reception of a SIP REGISTER request in a SIP server 1134 will trigger the Diameter client in the SIP server to send the 1135 Diameter SAR message. However, if a SIP server is receiving other 1136 SIP request, such as INVITE, and the SIP server does not have the 1137 user profile, the Diameter client in the SIP server may send the 1138 Diameter SAR message to the Diameter server in order to download the 1139 user profile and make the Diameter server aware of the SIP server 1140 assigned to the user. 1142 The user profile is an important piece of information that dictates 1143 the behavior of the SIP server when triggering or providing services 1144 for the user. Typically the user profile is divided into: 1146 o Services to be rendered to the user when the user is registered 1147 and initiates a SIP request. 1148 o Services to be rendered to the user when the user is registered 1149 and a SIP request destined to that user arrives to the SIP proxy. 1150 o Services to be rendered to the user when the user is not 1151 registered and a SIP request destined to that user arrives to the 1152 SIP proxy. 1154 The Diameter client can request the whole user profile or just the 1155 portion of it where the SIP server is interested on. The 1156 SIP-User-Data-Request-Type AVP and SIP-User-Data-Already-Available 1157 AVP will indicate such request. 1159 The SIP-Server-Assignment-Type AVP will indicate the reason why the 1160 Diameter client (SIP server) contacted the Diameter server. If the 1161 Diameter client sets the SIP-Server-Assignment-Type AVP value to 1162 REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT, 1163 AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client 1164 MUST include exactly one SIP-AOR AVP in the Diameter SAR message. 1166 Message Format 1167 ::= < Diameter Header: bbb, REQ, PXY > 1168 < Session-Id > 1169 { Auth-Application-Id } 1170 { Auth-Session-State } 1171 { Origin-Host } 1172 { Origin-Realm } 1173 { Destination-Realm } 1174 { SIP-Server-Assignment-Type } 1175 { SIP-User-Data-Request-Type } 1176 { SIP-User-Data-Already-Available } 1177 [ Destination-Host ] 1178 [ User-Name ] 1179 [ SIP-Server-URI ] 1180 * [ SIP-AOR ] 1181 * [ Proxy-Info ] 1182 * [ Route-Record ] 1183 * [ AVP ] 1185 7.4 Server-Assignment-Answer (SAA) Command 1187 The Server-Assignment-Answer (SAA) is indicated by the Command-Code 1188 set to bbb and the Command Flags' 'R' bit cleared. The Diameter 1189 server sends this command in response to a previously received 1190 Diameter Server-Assignment-Request (SAR) command. The response may 1191 include the user profile or part of it, if requested. 1193 In addition to the values already defined in RFC 3588 [5], the 1194 Result-Code AVP may contain one of the values defined in Section 1195 8.15.1. 1197 The Result-Code AVP value in the Diameter SAA message may indicate a 1198 success or an error in the execution of the Diameter SAR command. If 1199 Result-Code AVP value in the Diameter SAA message does not contain an 1200 error code, the SIP-User-Data AVP will typically contain the profile 1201 of the user, indicating services that the SIP server can render to 1202 that user. 1204 If the Diameter server requires a User-Name AVP value to process the 1205 Diameter SAR request, but the Diameter SAR message did not contain a 1206 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1207 value to DIAMETER_USER_NAME_REQUIRED (see and return it in a 1208 Diameter SAA message. Upon the reception of the Diameter SAA 1209 message, the SIP server will typically request authentication by 1210 sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) 1211 response back to the originator. 1213 If the User-Name AVP is included in the Diameter SAR message, at 1214 reception of the Diameter SAR message, the Diameter server MUST 1215 verify the existence of the user in the realm, i.e., the User-Name 1216 AVP value is a valid user within that realm. If the Diameter server 1217 does not recognize the user name received in the User-Name AVP, the 1218 Diameter server MUST build a Diameter Server-Assignment-Answer (SAA) 1219 message and MUST set the Result-Code AVP to 1220 DIAMETER_ERROR_USER_UNKNOWN. 1222 Then Diameter server MUST authorize that User-Name AVP value is a 1223 valid authentication name for the SIP or SIPS URI included in the 1224 SIP-AOR AVP of the Diameter SAR message. If this authorization 1225 fails, the Diameter server must set the Result-Code AVP to 1226 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1227 Server-Assignment-Answer (SAA) message. 1229 The actions of the Diameter server at the reception of the Diameter 1230 SAR message depends on the value of the SIP-Server-Assignment-Type: 1232 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1233 message is set to REGISTRATION or RE_REGISTRATION, the Diameter 1234 server SHOULD verify that there is only one SIP-AOR AVP. 1235 Otherwise, the Diameter server MUST answer with a Diameter SAA 1236 message with the Result-Code AVP value set to 1237 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any 1238 SIP-User-Data AVP. If there is only one SIP-AOR AVP, then the 1239 Diameter server SHOULD analyze the requested type of data in the 1240 SIP-User-Data-Request-Type and SIP-User-Data-Already-Available AVP 1241 values in the Diameter SAR message, and SHOULD include in the 1242 SIP-User-Data AVP value of the Diameter SAA message the relevant 1243 portion of the user profile associated with the SIP-AOR AVP and 1244 all other SIP identities associated with that AVP. Additionally, 1245 the Diameter server MUST set the Result-Code AVP value to 1246 DIAMETER_SUCCESS in the Diameter SAA message. The Diameter server 1247 considers the SIP AOR authenticated and registered. 1249 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1250 message is set to UNREGISTERED_USER then the Diameter server MUST 1251 store the SIP server address included in the SIP-Server-URI AVP 1252 value. The Diameter server will return the SIP server address in 1253 Diameter Location-Info-Answer (LIA) messages. The Diameter server 1254 SHOULD analyze the requested type of data in the 1255 SIP-User-Data-Request-Type and SIP-User-Data-Already-Available AVP 1256 values in the Diameter SAR message. The Diameter server SHOULD 1257 include the relevant portion of the user profile data associated 1258 with the SIP or SIPS URI (SIP-AOR AVP) and associated identities 1259 in the SIP-User-Data AVP value of the Diameter SAA message. The 1260 Diameter server MUST set the Result-Code AVP value to 1261 DIAMETER_SUCCESS. The Diameter server considers the SIP AOR 1262 UNREGISTERED, but with a SIP server allocated to trigger and 1263 provide services for unregistered users. Note that in case of 1264 UNREGISTERED_USER (SIP-Server-Assignment-Type AVP), the Diameter 1265 server MUST verify that there is only one SIP-AOR AVP. Otherwise, 1266 the Diameter server MUST answer the Diameter SAR message with a 1267 Diameter SAA message, it MUST set the Result-Code AVP value to 1268 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any 1269 SIP-User-Data AVP. 1270 If the User-Name AVP was not present in the Diameter SAR message 1271 and the SIP-AOR is not known for the Diameter server, the Diameter 1272 server MUST NOT include a User-Name AVP in the Diameter SAA 1273 message and MUST set the Result-Code AVP value to 1274 DIAMETER_ERROR_USER_UNKNOWN. 1275 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1276 message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, 1277 DEREGISTRATION_TOO_MUCH_DATA or ADMINISTRATIVE_DEREGISTRATION the 1278 Diameter server MUST clear the SIP server address associated with 1279 all SIP Addresses of Record indicated in each of the SIP-AOR AVP 1280 values included in the Diameter SAR message. The Diameter server 1281 considers all of these SIP Addresses of Record as not registered. 1282 The Diameter server MUST set the Result-Code AVP value to 1283 DIAMETER_SUCCESS in the Diameter SAA message. 1284 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1285 message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or 1286 USER_DEREGISTRATION_STORE_SERVER_NAME the Diameter server MAY keep 1287 the SIP server address associated with the SIP Addresses of Record 1288 included in the SIP-AOR AVP values of the Diameter SAR message, 1289 even though the SIP Addresses of Record will become unregistered. 1290 This feature allows a SIP server to request the Diameter server to 1291 remain as an assigned SIP server for those SIP Addresses of Record 1292 (SIP-AOR AVP values), and avoid SIP server assignment. The 1293 Diameter server MUST consider all these SIP Addresses of Record as 1294 not registered. If the Diameter server honors the request of the 1295 Diameter client (SIP server) to remain as an allocated SIP server, 1296 then the Diameter server MUST keep the SIP server assigned to 1297 those SIP Addresses of Record and MUST set the Result-Code AVP 1298 value to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, 1299 when the Diameter server does not honor the request of the 1300 Diameter client (SIP server) to remain as an allocated SIP server, 1301 the Diameter server MUST clear the SIP server name assigned to 1302 those SIP Addresses of Record and it MUST set the Result-Code AVP 1303 value to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter 1304 SAA message. 1305 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1306 message is set to NO_ASSIGNMENT, the Diameter server SHOULD first 1307 verify that the SIP-Server-URI AVP value in the Diameter SAR 1308 message is the same URI as the as the one assigned to the SIP-AOR 1309 AVP value. If they differ, then the Diameter server MUST set the 1310 Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter 1311 SAA message. Otherwise, the Diameter server SHOULD analyze the 1312 requested type of data in the SIP-User-Data-Request-Type AVP value 1313 in the Diameter SAR message, and SHOULD include the requested user 1314 profile in the SIP-User-Data AVP value of the Diameter SAA 1315 message. 1316 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR 1317 message is set to AUTHENTICATION_FAILURE or 1318 AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there 1319 is only SIP-AOR AVP in the Diameter SAR message. If the number of 1320 occurrences of the SIP-AOR AVP is not exactly one, the Diameter 1321 server MUST set the Result-Code AVP value to 1322 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message, 1323 and SHOULD not take further actions. If there is exactly one 1324 SIP-AOR AVP in the Diameter SAR message, the Diameter server MUST 1325 clear the address of the SIP server assigned to the SIP Address of 1326 Record, and the Diameter server MUST set the Result-Code AVP value 1327 to DIAMETER_SUCCESS in the Diameter SAA message. The Diameter 1328 server MUST consider the SIP AOR as not registered. 1330 Message Format 1331 ::= < Diameter Header: bbb, PXY > 1332 < Session-Id > 1333 { Auth-Application-Id } 1334 { Result-Code } 1335 { Auth-Session-State } 1336 { Origin-Host } 1337 { Origin-Realm } 1338 [ SIP-User-Data ] 1339 [ SIP-Accouting-Information ] 1340 [ User-Name ] 1341 [ Auth-Grace-Period ] 1342 [ Authorization-Lifetime ] 1343 * [ Redirect-Host ] 1344 [ Redirect-Host-Usage ] 1345 [ Redirect-Max-Cache-Time ] 1346 * [ Proxy-Info ] 1347 * [ Route-Record ] 1348 * [ AVP ] 1350 7.5 Location-Info-Request (LIR) Command 1352 The Location-Info-Request (LIR) is indicated by the Command-Code set 1353 to ccc and the Command Flags' 'R' bit set. The Diameter client in a 1354 SIP server sends this command to the Diameter server to request 1355 routing information, e.g., the URI of the SIP server assigned to a 1356 particular user. The user is identified by the SIP-AOR AVP value. 1358 Message Format 1359 ::= < Diameter Header: ccc, REQ, PXY > 1360 < Session-Id > 1361 { Auth-Application-Id } 1362 { Auth-Session-State } 1363 { Origin-Host } 1364 { Origin-Realm } 1365 { Destination-Realm } 1366 { SIP-AOR } 1367 [ Destination-Host ] 1368 * [ Proxy-Info ] 1369 * [ Route-Record ] 1370 * [ AVP ] 1372 7.6 Location-Info-Answer (LIA) Command 1374 The Location-Info-Answer (LIA) is indicated by the Command-Code set 1375 to ccc and the Command Flags' 'R' bit cleared. The Diameter server 1376 sends this command in response to a previously received Diameter 1377 Location-Info-Request (LIR) command. 1379 In addition to the values already defined in RFC 3588 [5], the 1380 Result-Code AVP may contain one of the values defined in Section 1381 8.15.1. When the Diameter server finds an error in processing the 1382 Diameter LIR message, the Diameter server MUST stop the process of 1383 the message and answer with a Diameter LIA message that includes the 1384 appropriate error code in the Result-Code AVP value. When there is 1385 no error, the Diameter server MUST set the Result-Code AVP value to 1386 DIAMETER_SUCCESS in the Diameter LIA message. 1388 One of the errors that the Diameter server may find is that the 1389 SIP-AOR AVP value is not a valid user in the realm. In such cases, 1390 the Diameter server MUST set the Result-Code AVP value to 1391 DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message. 1393 If the Diameter server cannot process the Diameter SAR command, e.g., 1394 due to a database error, the Diameter server MUST set the Result-Code 1395 AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter 1396 LIA message. The Diameter server MUST NOT include any SIP-Server-URI 1397 or SIP-Server-Capabilities AVP in the Diameter LIA message. 1399 The Diameter server can or cannot be aware of a SIP server assigned 1400 to the user contained in the SIP-AOR AVP value in the Diameter LIR 1401 message. If the Diameter server is aware of a SIP server allocated 1402 to that particular user, the Diameter server MUST include the URI of 1403 such SIP server in the SIP-Server-URI AVP and return it in a Diameter 1404 LIA message. This is typically the situation when the user is either 1405 registered, or unregistered but there is a SIP server still assigned 1406 to the user. 1408 When the Diameter server is not aware of a SIP server allocated to 1409 the user, typically the case when the user unregistered, the 1410 Result-Code AVP value in the Diameter LIA message depends on whether 1411 the Diameter server is aware that the user has services defined for 1412 unregistered users or not: 1414 o Those users who have services defined for unregistered users may 1415 require the allocation of a SIP server to trigger and perhaps 1416 execute those services. Therefore, when the Diameter server is 1417 not aware of an assigned SIP server, but the user has services 1418 defined for unregistered users, the Diameter server MUST set the 1419 Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return 1420 it in a Diameter LIA message. The Diameter server MAY also 1421 include a SIP-Server-Capabilities AVP to facilitate the SIP server 1422 (Diameter client) with the selection of an appropriate SIP server 1423 with the required capabilities. Absence of the 1424 SIP-Server-Capabilities AVP will indicate to the SIP server 1425 (Diameter client) that any SIP server is suitable to be allocated 1426 for the user. 1427 o Those users who do not have service defined for unregistered users 1428 do not require further processing. The Diameter server MUST set 1429 the Result-Code AVP value to 1430 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the 1431 Diameter client in a Diameter LIA message. The SIP server 1432 (Diameter client) may return the appropriate SIP response (e.g., 1433 480 Temporarily unavailable) to the original SIP request. 1435 Message Format 1436 ::= < Diameter Header: ccc, PXY > 1437 < Session-Id > 1438 { Auth-Application-Id } 1439 { Result-Code } 1440 { Auth-Session-State } 1441 { Origin-Host } 1442 { Origin-Realm } 1443 [ SIP-Server-URI ] 1444 [ SIP-Server-Capabilities ] 1445 [ Auth-Grace-Period ] 1446 [ Authorization-Lifetime ] 1447 * [ Redirect-Host ] 1448 [ Redirect-Host-Usage ] 1449 [ Redirect-Max-Cache-Time ] 1450 * [ Proxy-Info ] 1451 * [ Route-Record ] 1452 * [ AVP ] 1454 7.7 Multimedia-Auth-Request (MAR) Command 1456 The Multimedia-Auth-Request (MAR) command is indicated by the 1457 Command-Code set to ddd and the Command Flags' 'R' bit set. The 1458 Diameter client in a SIP server sends this command to the Diameter 1459 server to request the Diameter server to authenticate and authorize a 1460 user attempt to use some SIP service (in this context, SIP service 1461 can be something as simple as a SIP subscription or using the proxy 1462 services for a SIP request). Unlike the Diameter UAR command, MAR 1463 does not store any state in the Diameter server. 1465 This Diameter application provides Diameter clients in SIP servers 1466 with a centralized routing information functionality, so that if a 1467 Diameter client in a SIP server wants to find out routing information 1468 for a particular user, the Diameter server can return (in a Diameter 1469 LIA message) the SIP URI of the SIP server allocated to the user. 1470 This allows SIP servers operating in a stateful mode to receive all 1471 the SIP traffic addressed to the user. For this functionality to 1472 work, the SIP server allocated to the user ought to register its URI 1473 to the Diameter server. This is accomplished with the SIP-Server-URI 1474 AVP provided in the Diameter MAR command that we describe in this 1475 section. 1477 The SIP-Method AVP MUST include the SIP method name of the SIP 1478 request that triggered this Diameter MAR message. 1480 The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP 1481 indicates the target of the SIP request. The value of the AVP is 1482 extracted from different places in SIP request, depending on the 1483 semantics of the SIP request. For SIP REGISTER messages the SIP-AOR 1484 AVP value indicates the intended public user identity under 1485 registration, and it is the SIP or SIPS URI populated in the To 1486 header field value (addr-spec, according to the SIP ABNF) of the SIP 1487 REGISTER request. For other types of SIP requests, such as INVITE, 1488 SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the 1489 intended destination of the request. This is typically populated in 1490 the Request-URI of the SIP request. It is the Diameter client 1491 responsibility to extract the SIP-AOR AVP value from the proper SIP 1492 header field. Extensions to SIP (new SIP methods or new semantics) 1493 may require to extract the SIP-AOR from other parts of the request. 1495 If the SIP request includes some sort of authentication information, 1496 the Diameter client MUST include the user name, extracted from the 1497 authentication information of the SIP request, in the User-Name AVP 1498 value. 1500 Message Format 1501 ::= < Diameter Header: ddd, REQ, PXY > 1502 < Session-Id > 1503 { Auth-Application-Id } 1504 { Auth-Session-State } 1505 { Origin-Host } 1506 { Origin-Realm } 1507 { Destination-Realm } 1508 { SIP-AOR } 1509 { SIP-Method } 1510 [ Destination-Host ] 1511 [ User-Name ] 1512 [ SIP-Server-URI ] 1513 [ SIP-Number-Auth-Items ] 1514 [ SIP-Auth-Data-Item ] 1515 * [ Proxy-Info ] 1516 * [ Route-Record ] 1517 * [ AVP ] 1519 7.8 Multimedia-Auth-Answer (MAA) Command 1521 The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set 1522 to ddd and the Command Flags' 'R' bit cleared. The Diameter server 1523 sends this command in response to a previously received Diameter 1524 Multimedia-Auth-Request (MAR) command. 1526 In addition to the values already defined in RFC 3588 [5], the 1527 Result-Code AVP may contain one of the values defined in Section 1528 8.15.1. 1530 If the Diameter server requires a User-Name AVP value to process the 1531 Diameter MAR request, but the Diameter MAR message did not contain a 1532 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1533 value to DIAMETER_USER_NAME_REQUIRED (see and return it in a 1534 Diameter MAA message. The Diameter server MAY include a 1535 SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs 1536 with authentication information (e.g., a challenge). Upon the 1537 reception of the Diameter MAA message, the SIP server will typically 1538 request authentication by sending a 401 (Unauthorized) or 407 (Proxy 1539 Authentication Required) response back to the originator. 1541 If the User-Name AVP is present in the Diameter MAR message, the 1542 Diameter server MUST verify the existence of the user in the realm, 1543 i.e., the User-Name AVP value is a valid user within that realm. If 1544 the Diameter server does not recognize the user name received in the 1545 User-Name AVP, the Diameter server MUST build a Diameter 1546 Multimedia-Auth-Answer (MAA) message and MUST set the Result-Code AVP 1547 to DIAMETER_ERROR_USER_UNKNOWN. 1549 If the SIP-Method AVP value of the Diameter MAR message is set to 1550 REGISTER and a User-Name AVP is present, then the Diameter server 1551 MUST authorize that User-Name AVP value is able to use the URI 1552 included in the SIP-AOR AVP. If this authorization fails, the 1553 Diameter server must set the Result-Code AVP to 1554 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter 1555 Multimedia-Auth-Answer (MAA) message. 1557 Correlation between User-Name and SIP-AOR AVP values is only 1558 required for SIP REGISTER request, just to avoid that any user can 1559 register a SIP-AOR allocated to another user. In other types of 1560 SIP requests (e.g., INVITE), the SIP-AOR will indicate the 1561 intended destination of the request, rather than the originator of 1562 it. 1564 Then Diameter server MUST verify whether the authentication scheme 1565 (SIP-Authentication-Scheme AVP value) indicated in the grouped 1566 SIP-Auth-Data-Item AVP is supported or not. If that authentication 1567 scheme is not supported, then the Diameter server MUST set the 1568 Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send 1569 it in a Diameter Multimedia-Auth-Answer (MAA) message. 1571 If the received Diameter MAR message contains a grouped 1572 SIP-Authorization AVP within the grouped SIP-Auth-Data-Item AVP, the 1573 Diameter server considers that the authorization information is being 1574 requested after a synchronization failure. In this case, the 1575 sequence of the SIP-Auth-Data-Item AVPs would take into account the 1576 SIP-Authorization AVP value to synchronize the vectors. The Diameter 1577 server MUST set the Result-Code AVP to DIAMETER_SUCCESS. 1579 If the SIP-Number-Auth-Items AVP is present in the Diameter MAR 1580 message, it will indicate the number of authentication data items 1581 that the Diameter client is requesting. It is RECOMMENDED that the 1582 Diameter server, when building the Diameter MAA message, includes a 1583 number of SIP-Auth-Data-Item AVPs that is a subset of the 1584 authentication data items requested by the Diameter client in the 1585 SIP-Number-Auth-Items AVP value of the Diameter MAR message. 1587 If the SIP-Server-URI AVP is present in the Diameter MAR message, 1588 then the Diameter server MUST compare the stored SIP server assigned 1589 to the SIP AOR with the SIP-Server-URI AVP value received in the 1590 Diameter MAR message. If there is not a match, the Diameter server 1591 MUST update the stored SIP server assigned to the SIP AOR, and MUST 1592 set an "authentication pending" flag for the SIP AOR. If there is a 1593 match, the Diameter server shall clear the "authentication pending" 1594 flag for the SIP AOR. 1596 In any other situation, if there is a success in processing the 1597 Diameter MAR command and the Diameter server stored the 1598 SIP-Server-URI, the Diameter server MUST set the Result-Code AVP 1599 value to DIAMETER_SUCCESS and return it in a Diameter MAA message. 1601 If there is a success in processing the Diameter MAR command but the 1602 Diameter server does not store the SIP-Server-URI because the AVP was 1603 not present in the Diameter MAR command, then the Diameter server 1604 MUST set the Result-Code AVP value to either: 1606 1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter 1607 server is sending authentication vectors to create a challenge 1608 2. DIAMETER_SUCCESS_SERVER_NOT_STORED, if the Diameter server 1609 successfully authenticated the user and authorized the SIP server 1610 to proceed with the SIP request. 1612 Otherwise, the Diameter server MUST set the Result-Code AVP value to 1613 DIAMETER_UNABLE_TO_COMPLY and it MUST NOT include any 1614 SIP-Auth-Data-Item AVP. 1616 Message Format 1617 ::= < Diameter Header: ddd, PXY > 1618 < Session-Id > 1619 { Auth-Application-Id } 1620 { Result-Code } 1621 { Auth-Session-State } 1622 { Origin-Host } 1623 { Origin-Realm } 1624 [ User-Name ] 1625 [ SIP-AOR ] 1626 [ SIP-Number-Auth-Items ] 1627 * [ SIP-Auth-Data-Item ] 1628 [ Authorization-Lifetime ] 1629 [ Auth-Grace-Period ] 1630 * [ Redirect-Host ] 1631 [ Redirect-Host-Usage ] 1632 [ Redirect-Max-Cache-Time ] 1633 * [ Proxy-Info ] 1634 * [ Route-Record ] 1635 * [ AVP ] 1637 7.9 Registration-Termination-Request (RTR) Command 1639 The Registration-Termination-Request (RTR) command is indicated by 1640 the Command-Code set to eee and the Command Flags' 'R' bit set. The 1641 Diameter server sends this command to the Diameter client in a SIP 1642 server to indicate the SIP server that one or more SIP AORs have to 1643 be de-registered. The command allows an operator to administratively 1644 cancel the registration of a user from a centralized Diameter server. 1646 The Diameter server has the capability to initiate the 1647 de-registration of a user and inform the SIP server by means of the 1648 Diameter RTR command. The Diameter server can decide whether only 1649 one SIP AOR is going to be deregistered, a list of SIP AORs, or all 1650 the SIP AORs allocated to the user. 1652 The absence of a SIP-AOR AVP in the Diameter RTR message indicates 1653 that all the SIP Addresses of Record allocated to the user identified 1654 by the User-Name AVP are being deregistered. 1656 The Diameter server MUST include a SIP-Deregistration-Reason AVP 1657 value to indicate the reason for the deregistration. 1659 Message Format 1660 ::= < Diameter Header: eee, REQ, PXY > 1661 < Session-Id > 1662 { Auth-Application-Id } 1663 { Auth-Session-State } 1664 { Origin-Host } 1665 { Origin-Realm } 1666 { Destination-Host } 1667 { SIP-Deregistration-Reason } 1668 [ Destination-Realm ] 1669 [ User-Name ] 1670 * [ SIP-AOR ] 1671 * [ Proxy-Info ] 1672 * [ Route-Record ] 1673 * [ AVP ] 1675 7.10 Registration-Termination-Answer (RTA) Command 1677 The Registration-Termination-Answer (RTA) is indicated by the 1678 Command-Code set to eee and the Command Flags' 'R' bit cleared. The 1679 Diameter client sends this command in response to a previously 1680 received Diameter Registration-Termination-Request (RTR) command. 1682 In addition to the values already defined in RFC 3588 [5], the 1683 Result-Code AVP may contain one of the values defined in Section 1684 8.15.1. 1686 If the Diameter server requires a User-Name AVP value to process the 1687 Diameter RTR request, but the Diameter RTR message did not contain a 1688 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1689 value to DIAMETER_USER_NAME_REQUIRED (see and return it in a 1690 Diameter RTA message. Upon the reception of the Diameter RTA 1691 message, the SIP server will typically request authentication by 1692 sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) 1693 response back to the originator. 1695 The SIP server (Diameter client) will apply the administrative 1696 deregistration to each of the URIs included in each of the SIP-AOR 1697 AVP values, or, if there is no SIP-AOR AVP present in the Diameter 1698 RTR request, to all the URIs allocated to the User-Name AVP value. 1700 The value of the SIP-Deregistration-Reason AVP in the Diameter RTR 1701 command will have an effect on the actions performed at the SIP 1702 server (Diameter client): 1704 o If the value is set to PERMANENT_TERMINATION, then the user has 1705 terminated his/her registration to the realm. The SIP server 1706 (Diameter client), if supported through SIP procedures, SHOULD 1707 inform the interested parties (e.g., subscribers to the 1708 registration event) about the administrative de-registration and 1709 SHOULD NOT request a new user registration. The SIP server SHOULD 1710 clear the registration state of the de-registered AORs. 1711 o If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter 1712 server informs the SIP server (Diameter client) that a new SIP 1713 server has been allocated to the user, due to some reason. The 1714 SIP server, if supported through SIP procedures, SHOULD inform the 1715 interested parties (e.g., subscribers to the registration event) 1716 about the administrative de-registration at this SIP server and 1717 SHOULD NOT request a new user registration. The SIP server SHOULD 1718 clear the registration state of the de-registered SIP AORs. 1719 o If the value is set to SIP_SERVER_CHANGE, the Diameter server 1720 informs the SIP server (Diameter client) that a new SIP server has 1721 to be allocated to the user, due to e.g. user's capabilities 1722 requiring a new SIP server, or not enough resources in the current 1723 SIP server. The SIP server, if supported through SIP procedures, 1724 SHOULD inform the interested parties (e.g., subscribers to the 1725 registration event) about the administrative de-registration at 1726 this SIP server and SHOULD request a new user registration. The 1727 SIP server SHOULD clear the registration state of the 1728 de-registered SIP AORs. 1729 o If the value is set to REMOVE_SIP_SERVER, the Diameter server 1730 informs the SIP server (Diameter client) that the SIP server will 1731 no longer be bound in the Diameter server with such user. The SIP 1732 server can delete all data related to the user. 1734 Message Format 1735 ::= < Diameter Header: eee, PXY > 1736 < Session-Id > 1737 { Auth-Application-Id } 1738 { Result-Code } 1739 { Auth-Session-State } 1740 { Origin-Host } 1741 { Origin-Realm } 1742 [ Authorization-Lifetime ] 1743 [ Auth-Grace-Period ] 1744 * [ Redirect-Host ] 1745 [ Redirect-Host-Usage ] 1746 [ Redirect-Max-Cache-Time ] 1747 * [ Proxy-Info ] 1748 * [ Route-Record ] 1749 * [ AVP ] 1751 7.11 Push-Profile-Request (PPR) Command 1753 The Push-Profile-Request (PPR) command is indicated by the 1754 Command-Code set to fff and the Command Flags' 'R' bit set. The 1755 Diameter server sends this command to the Diameter client in a SIP 1756 server to update the user profile of an already registered user in 1757 that SIP server. This allows an operator to modify the data of a 1758 user profile and push it to the SIP server where the user is 1759 registered. 1761 Each user has a user profile associated with him/her. The profile 1762 may change with time, due to, e.g., addition of new services to the 1763 user. When the user profile changes, the Diameter server sends a 1764 Diameter Push-Profile-Request (PPR) command to the Diameter client in 1765 a SIP server, in order to start applying those new services. 1767 The Diameter server sends the new user profile in the SIP-User-Data 1768 AVP value. 1770 Message Format 1771 ::= < Diameter Header: fff, REQ, PXY > 1772 < Session-Id > 1773 { Auth-Application-Id } 1774 { Auth-Session-State } 1775 { Origin-Host } 1776 { Origin-Realm } 1777 { Destination-Realm } 1778 { SIP-User-Data } 1779 [ Destination-Host ] 1780 [ User-Name ] 1781 * [ SIP-AOR ] 1782 [ Authorization-Lifetime ] 1783 [ Auth-Grace-Period ] 1784 * [ Proxy-Info ] 1785 * [ Route-Record ] 1786 * [ AVP ] 1788 7.12 Push-Profile-Answer (PPA) Command 1790 The Push-Profile-Answer (PPA) is indicated by the Command-Code set to 1791 fff and the Command Flags' 'R' bit cleared. The Diameter client 1792 sends this command in response to a previously received Diameter 1793 Push-Profile-Request (PPR) command. 1795 In addition to the values already defined in RFC 3588 [5], the 1796 Result-Code AVP may contain one of the values defined in Section 1797 8.15.1. 1799 If the Diameter server requires a User-Name AVP value to process the 1800 Diameter PPR request, but the Diameter PPR message did not contain a 1801 User-Name AVP value, the Diameter server MUST set the Result-Code AVP 1802 value to DIAMETER_USER_NAME_REQUIRED (see and return it in a 1803 Diameter PPA message. Upon the reception of the Diameter PPA 1804 message, the SIP server will typically request authentication by 1805 sending a 401 (Unauthorized) or 407 (Proxy Authentication Required) 1806 response back to the originator. 1808 If there is no error when processing the received Diameter PPR 1809 message, the SIP server (Diameter client) MUST download the received 1810 user profile from the SIP-User-Data AVP value in the Diameter PPR 1811 message and stored for all the SIP AORs allocated to the User-Name 1812 AVP value. 1814 If the SIP server does not recognize or does not support some of the 1815 data transferred in the SIP-User-Data AVP value, the Diameter client 1816 in the SIP server MUST return a Diameter PPA message that includes a 1817 Result-Code AVP set to the value 1818 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA. 1820 If the SIP server (Diameter client) receives a Diameter PPR message 1821 with a User-Name AVP that is unknown, the Diameter client MUST set 1822 the Result-Code AVP value to DIAMETER_ERROR_USER_UNKONWN and MUST 1823 return it to the Diameter server in a Diameter PPA message. 1825 If the SIP server (Diameter client) receives in the SIP-User-Data AVP 1826 value more data than it can accept, it MUST set the Result-Code AVP 1827 value to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the 1828 Diameter server in a Diameter PPA message. The SIP server MUST NOT 1829 override the existing user profile with that received in the PPR 1830 message. 1832 If the Diameter server receives the Result-Code AVP value set to 1833 DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD 1834 force a new re-registration of the user by sending to the Diameter 1835 client a Diameter Registration-Termination-Request (RTR) with the 1836 SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This 1837 will force a re-registration of the user, and will trigger a 1838 selection of a new SIP server. 1840 If the Diameter client is not able to honor the command, for any 1841 other reason, it MUST set the Result-Code AVP value to 1842 DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA 1843 message. 1845 Message Format 1846 ::= < Diameter Header: fff, PXY > 1847 < Session-Id > 1848 { Auth-Application-Id } 1849 { Result-Code } 1850 { Auth-Session-State } 1851 { Origin-Host } 1852 { Origin-Realm } 1853 * [ Redirect-Host ] 1854 [ Redirect-Host-Usage ] 1855 [ Redirect-Max-Cache-Time ] 1856 * [ Proxy-Info ] 1857 * [ Route-Record ] 1858 * [ AVP ] 1860 8. Diameter SIP application AVPs 1862 This section defines new AVPs used in this Diameter SIP application. 1863 Applications compliant to this specification MUST implement these 1864 AVPs. 1866 The list of AVPs defined in this Diameter SIP application is listed 1867 in Table 2 and Table 3 1869 +-------------------------------+------+-------------+--------------+ 1870 | AVP Name | AVP | Reference | Data-Type | 1871 | | Code | | | 1872 +-------------------------------+------+-------------+--------------+ 1873 | SIP-Visited-Network-Id | xx01 | Section 8.9 | UTF8String | 1874 | SIP-AOR | xx02 | Section 8.8 | UTF8String | 1875 | SIP-Server-URI | xx03 | Section 8.2 | UTF8String | 1876 | SIP-Server-Capabilities | xx04 | Section 8.3 | Grouped | 1877 | SIP-Mandatory-Capability | xx05 | Section | Unsigned32 | 1878 | | | 8.3.1 | | 1879 | SIP-Optional-Capability | xx06 | Section | Unsigned32 | 1880 | | | 8.3.2 | | 1881 | SIP-User-Data | xx07 | Section | OctetString | 1882 | | | 8.11 | | 1883 | SIP-Number-Auth-Items | xx08 | Section 8.6 | Unsigned32 | 1884 | SIP-Auth-Data-Item | xx09 | Section 8.5 | Grouped | 1885 | SIP-Item-Number | xx10 | Section | Unsigned32 | 1886 | | | 8.5.2 | | 1887 | SIP-Authentication-Scheme | xx11 | Section | Enumerated | 1888 | | | 8.5.1 | | 1889 | SIP-Authenticate | xx12 | Section | Grouped | 1890 | | | 8.5.3 | | 1891 | SIP-Authorization | xx13 | Section | Grouped | 1892 | | | 8.5.4 | | 1893 | SIP-Authentication-Info | xx14 | Section | Grouped | 1894 | | | 8.5.5 | | 1895 | SIP-Authentication-Context | xx15 | Section | Grouped | 1896 | | | 8.5.6 | | 1897 | SIP-Server-Assignment-Type | xx18 | Section 8.4 | Enumerated | 1898 | SIP-Deregistration-Reason | xx19 | Section 8.7 | Grouped | 1899 | SIP-Reason-Code | xx20 | Section | Enumerated | 1900 | | | 8.7.1 | | 1901 | SIP-Reason-Info | xx21 | Section | UTF8String | 1902 | | | 8.7.2 | | 1903 | SIP-Accouting-Information | xx22 | Section 8.1 | Grouped | 1904 | SIP-Accounting-Server-URI | xx23 | Section | DiameterURI | 1905 | | | 8.1.1 | | 1906 | SIP-Credit-Control-Server-URI | xx24 | Section | DiameterURI | 1907 | | | 8.1.2 | | 1908 +-------------------------------+------+-------------+--------------+ 1910 Table 2 1912 +-------------------------------+------+-------------+--------------+ 1913 | AVP Name | AVP | Reference | Data-Type | 1914 | | Code | | | 1915 +-------------------------------+------+-------------+--------------+ 1916 | SIP-User-Authorization-Type | xx25 | Section | Enumerated | 1917 | | | 8.10 | | 1918 | SIP-User-Data-Request-Type | xx26 | Section | Enumerated | 1919 | | | 8.13 | | 1920 | SIP-User-Data-Already-Availab | xx27 | Section | Enumerated | 1921 | le | | 8.12 | | 1922 | SIP-Method | xx28 | Section | UTF8String | 1923 | | | 8.14 | | 1924 | Digest-Entity-Body-Hash | xx29 | Section | OctetString | 1925 | | | 8.5.6.1 | | 1926 | Digest-Realm | xx30 | Section | UTF8String | 1927 | | | 8.5.7 | | 1928 | Digest-Domain | xx31 | Section | UTF8String | 1929 | | | 8.5.8 | | 1930 | Digest-Nonce | xx32 | Section | UTF8String | 1931 | | | 8.5.9 | | 1932 | Digest-Opaque | xx33 | Section | UTF8String | 1933 | | | 8.5.10 | | 1934 | Digest-Stale | xx34 | Section | UTF8String | 1935 | | | 8.5.11 | | 1936 | Digest-Algorithm | xx35 | Section | UTF8String | 1937 | | | 8.5.12 | | 1938 | Digest-Qop | xx36 | Section | UTF8String | 1939 | | | 8.5.13 | | 1940 | Digest-Auth-Param | xx37 | Section | UTF8String | 1941 | | | 8.5.14 | | 1942 | Digest-Username | xx38 | Section | UTF8String | 1943 | | | 8.5.15 | | 1944 | Digest-Digest-URI | xx39 | Section | UTF8String | 1945 | | | 8.5.16 | | 1946 | Digest-Response | xx40 | Section | UTF8String | 1947 | | | 8.5.17 | | 1948 | Digest-Cnonce | xx41 | Section | UTF8String | 1949 | | | 8.5.18 | | 1950 | Digest-Nonce-Count | xx44 | Section | UTF8String | 1951 | | | 8.5.19 | | 1952 | Digest-Nextnonce | xx45 | Section | UTF8String | 1953 | | | 8.5.20 | | 1954 | Digest-Response-Auth | xx46 | Section | UTF8String | 1955 | | | 8.5.21 | | 1956 | Digest-AKA-Auts | xx47 | Section | UTF8String | 1957 | | | 8.5.22 | | 1958 | Digest-Expected-Response | xx48 | Section | UTF8String | 1959 | | | 8.5.23 | | 1960 +-------------------------------+------+-------------+--------------+ 1962 Table 3 1964 8.1 SIP-Accounting-Information AVP 1966 The SIP-Accounting-Information (AVP code TBD) is of type Grouped, and 1967 contains the Diameter addresses of those nodes that are able to 1968 collect accounting information. The Grouped Data field has the 1969 following ABNF grammar: 1971 SIP-Accounting-Information :: = < AVP Header: TBD > 1972 * [ SIP-Accounting-Server-URI ] 1973 * [ SIP-Credit-Control-Server-URI ] 1974 * [ AVP] 1976 8.1.1 SIP-Accounting-Server-URI AVP 1978 The SIP-Accounting-Server-URI AVP (AVP Code TBD) is of type 1979 DiameterURI. This AVP contains the address of a Diameter server that 1980 is able to receive SIP session related accounting information. 1982 8.1.2 SIP-Credit-Control-Server-URI AVP 1984 The Credit-Control-Server-URI AVP (AVP Code TBD) is of type 1985 DiameterURI. This AVP contains the address of the a Diameter server 1986 that is able to authorize real-time credit control usage. The 1987 Diameter Credit Control Application [9] may be used for this purpose. 1989 8.2 SIP-Server-URI AVP 1991 The SIP-Server-URI AVP (AVP Code TBD) is of type UTF8String. This 1992 AVP contains a SIP or SIPS URI (as defined in RFC 3261 [3]) that 1993 identifies a SIP server. 1995 8.3 SIP-Server-Capabilities AVP 1997 The SIP-Server-Capabilities AVP (AVP Code TBD) is of type Grouped. 1998 The Diameter indicates in this AVP the requirements for a particular 1999 SIP capability, so that the Diameter client (SIP server) is able to 2000 select another appropriate SIP server to serve the user. 2002 SIP-Server-Capability ::= < AVP Header: TBD > 2003 * [ SIP-Mandatory-Capability ] 2004 * [ SIP-Optional-Capability ] 2005 * [ SIP-Server-URI ] 2006 * [ AVP ] 2008 8.3.1 SIP-Mandatory-Capability AVP 2010 The SIP-Mandatory-Capability AVP (AVP Code TBD) is of type 2011 Unsigned32. The value represents a certain capability (or set of 2012 capabilities) that the SIP server to be allocated to the user has to 2013 fulfil. 2015 The semantics of the different values are not standardized, as it is 2016 a matter of the administrative network to allocate its own semantics 2017 within its own network. Each value has to represent a single 2018 capability within the administrative network. 2020 8.3.2 SIP-Optional-Capability AVP 2022 The SIP-Optional-Capability AVP (AVP Code TBD) is of type Unsigned32. 2023 The value represents a certain capability (or set of capabilities) 2024 that the SIP server to be allocated may, optionally, fulfil. 2026 The semantics of the different values are not standardized, as it is 2027 a matter of the administrative network to allocate its own semantics 2028 within its own network. Each value has to represent a single 2029 capability within the administrative network. 2031 8.4 SIP-Server-Assignment-Type AVP 2033 The SIP-Server-Assignment-Type AVP (AVP code TBD) is of type 2034 Enumerated, and indicates the type of server update being performed 2035 in a Diameter Server-Assignment-Request (SAR) operation. The 2036 following values are defined: 2038 o NO_ASSIGNMENT (0) 2039 The Diameter client uses this value to request the user profile of 2040 a SIP AOR, without affecting the registration state of such 2041 identity. 2042 o REGISTRATION (1) 2043 First SIP registration of a SIP AOR. 2044 o RE_REGISTRATION (2) 2045 Subsequent SIP registration of a SIP AOR. 2046 o UNREGISTERED_USER (3) 2047 The SIP server has received a SIP request (e.g., SIP INVITE) 2048 addressed for a SIP AOR that is not registered. 2049 o TIMEOUT_DEREGISTRATION (4) 2050 The SIP registration timer of an identity has expired. 2051 o USER_DEREGISTRATION (5) 2052 The SIP server has received a request to de-register a SIP AOR. 2053 o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) 2054 The SIP registration timer of an identity has expired. The SIP 2055 server keeps the user data stored and requests the Diameter server 2056 to store the SIP server address. 2057 o USER_DEREGISTRATION_STORE_SERVER_NAME (7) 2058 The SIP server has received a user initiated de-registration 2059 request. The SIP server keeps the user data stored and requests 2060 the Diameter server to store the SIP server address. 2061 o ADMINISTRATIVE_DEREGISTRATION (8) 2062 The SIP server, due to administrative reasons, has de-registered a 2063 SIP AOR. 2064 o AUTHENTICATION_FAILURE (9) 2065 The authentication of a user has failed. 2066 o AUTHENTICATION_TIMEOUT (10) 2067 The authentication timer has expired. 2068 o DEREGISTRATION_TOO_MUCH_DATA (11) 2069 The SIP server has requested user profile information from the 2070 Diameter server and has received a volume of data higher than it 2071 can accept. 2073 8.5 SIP-Auth-Data-Item AVP 2075 The SIP-Auth-Data-Item (AVP code TDB) is of type Grouped and contains 2076 the authentication and/or authorization information pertaining to a 2077 user. 2079 SIP-Auth-Data-Item :: = < AVP Header: TBD > 2080 { SIP-Authentication-Scheme } 2081 [ SIP-Item-Number ] 2082 [ SIP-Authenticate ] 2083 [ SIP-Authorization ] 2084 [ SIP-Authentication-Info ] 2085 [ SIP-Authentication-Context ] 2086 * [ AVP ] 2088 8.5.1 SIP-Authentication-Scheme AVP 2090 The SIP-Authentication-Scheme AVP (AVP code TBD) is of type 2091 Enumerated and indicates the authentication scheme used in the 2092 authentication of SIP services. RFC 2617 identifies this value as an 2093 "auth-scheme" (see section 1.2 of RFC 2617 [2]). The is currently 2094 only one defined value: 2096 o DIGEST (0) to indicate HTTP Digest authentication as specified in 2097 RFC 2617 [2] section 3.2.1. Derivative work is also considered 2098 Digest authentication sheme, as long as the "auth-scheme" is 2099 identified as Digest in the SIP headers carrying the HTTP 2100 authentication. This includes, e.g., the HTTP Digest 2101 authentication using AKA [4]. 2103 NOTE: Due to the fact that HTTP Digest authentication [2] is the 2104 only mandatory authentication mechanism in SIP, this memo only 2105 provides support for HTTP Digest authentication and derivative 2106 work such as HTTP Digest authentication using AKA [4]. Extensions 2107 to this memo can register new values and new AVPs to provide 2108 support for other authentication schemes. 2110 NOTE: Although RFC 2617 [2]defines the Basic and Digest schemes 2111 for authenticating HTTP requests, RFC 3261 [3] only imports HTTP 2112 Digest as a mechanism to provide authentication in SIP. 2114 8.5.2 SIP-Item-Number AVP 2116 The SIP-Item-Number (AVP code TDB) is of type Unsigned32, and is 2117 included in a SIP-Auth-Data-Item grouped AVP in circumstances where 2118 there are multiple occurrences of SIP-Auth-Data-Item AVPs and the 2119 order of processing is relevant. The AVP indicates the order in 2120 which the Grouped SIP-Auth-Data-Item should be processed. Lower 2121 values of the SIP-Item-Number AVP indicate that the whole 2122 SIP-Auth-Data-Item SHOULD be processed before other 2123 SIP-Auth-Data-Item AVP that contain a higher value number in the 2124 SIP-Item-Number AVP. 2126 8.5.3 SIP-Authenticate AVP 2128 The SIP-Authenticate AVP (AVP code TBD) is of type Grouped and 2129 contains a reconstruction of either the SIP WWW-Authenticate or 2130 Proxy-Authenticate header fields specified in RFC 2617 [2] for the 2131 HTTP Digest authentication scheme. Additionally, the AVP may include 2132 a Digest-Expected-Response AVP that assist the Diameter client in 2133 comparing the Digest response from the SIP UA. 2135 SIP-Authenticate ::= < AVP Header: TBD > 2136 { Digest-Realm } 2137 { Digest-Nonce } 2138 [ Digest-Domain ] 2139 [ Digest-Opaque ] 2140 [ Digest-Stale ] 2141 [ Digest-Algorithm ] 2142 [ Digest-Qop ] 2143 * [ Digest-Auth-Param ] 2144 * [ Digest-Expected-Response] 2145 * [ AVP ] 2147 8.5.4 SIP-Authorization AVP 2149 The SIP-Authorization AVP (AVP code TBD) is of type Grouped and 2150 contains a reconstruction of either the SIP Authorization or 2151 Proxy-Authorization header fields specified in RFC 2617 [2] for the 2152 HTTP Digest authentication scheme. 2154 SIP-Authorization ::= < AVP Header: TBD > 2155 { Digest-Username } 2156 { Digest-Realm } 2157 { Digest-Nonce } 2158 { Digest-Digest-URI } 2159 { Digest-Response } 2160 [ Digest-Algorithm ] 2161 [ Digest-Cnonce ] 2162 [ Digest-Opaque ] 2163 [ Digest-Qop ] 2164 [ Digest-Nonce-Count ] 2165 * [ Digest-Auth-Param ] 2166 * [ AVP ] 2168 8.5.5 SIP-Authentication-Info AVP 2170 The SIP-Authentication-Info AVP (AVP Code TBD) is of type Grouped and 2171 contains a reconstruction of the SIP Authentication-Info header 2172 specified in RFC 2617 [2] for the HTTP Digest authentication scheme. 2174 SIP-Authentication-Info ::= < AVP Header: TBD > 2175 { Digest-Nextnonce } 2176 [ Digest-Qop ] 2177 [ Digest-Nonce ] 2178 [ Digest-Cnonce ] 2179 [ Digest-Nonce-Count ] 2180 * [ AVP ] 2182 8.5.6 SIP-Authentication-Context AVP 2184 The SIP-Authentication-Context AVP (AVP code TBD) is of type Grouped 2185 and contains authentication-related information relevant for 2186 performing the authentication that is not part of the SIP 2187 authentication headers. 2189 Some authentication schemes, such us HTTP Digest [2] with quality of 2190 protection set to "auth-int" or HTTP Digest with predictive nonces, 2191 request that part of the SIP request is evaluated by the node 2192 performing authentication. In such cases the 2193 SIP-Authentication-Context AVP contains such data. Note that the 2194 actual contents of the AVP are depending on the authentication 2195 scheme. 2197 For instance, HTTP Digest with quality of protection set to 2198 "auth-int" requires a hash of the entity body (e.g., SDP). We 2199 provide a Digest-Entity-Body-Hash AVP whose purpose is to send the 2200 hash of the entity body. 2202 SIP-Authentication-Context:: = < AVP Header: TBD > 2203 [ Digest-Entity-Body-Hash ] 2204 * [ AVP ] 2206 Diameter clients MUST send a SIP-Authentication-Context AVP when the 2207 authentication mechanism requires processing of extra information not 2208 contained in other existing AVPs or SIP headers, for instance, when 2209 the authentication mechanism requires to verify the entity body of 2210 the SIP request. 2212 8.5.6.1 Digest-Entity-Body-Hash AVP 2214 The Digest-Entity-Body-Hash AVP (AVP Code TBD) is of type OctetString 2215 and contains a hash of the entity body contained in the SIP message. 2216 This hash is required by certain authentication mechanisms, such as 2217 HTTP Digest with quality of protection set to "auth-int". Diameter 2218 clients MUST use this AVP to transport the hash of the entity body 2219 when the authentication mechanism is HTTP Digest and there is a need 2220 the Diameter server requires to verify the integrity of the entity 2221 body (e.g., qop set to "auth-int"). Extensions to this document may 2222 define support for authentication mechanisms other than HTTP Digest. 2223 Such extensions may define new AVPs in the SIP-Authentication-Context 2224 AVP that support the particular mechanism. 2226 The clarifications described in Section 22.4 of RFC 3261 [3] about 2227 the hash of empty entity bodies apply to the Digest-Entity-Body-Hash 2228 AVP. 2230 8.5.7 Digest-Realm AVP 2232 The Digest-Realm AVP (AVP code TBD) is of type UTF8String and 2233 contains the value of the "realm" parameter included in the Digest 2234 header (known as "realm-value" according to RFC 2617 section 1.2). 2235 Note that "realm-value" is a quoted string, thus, the Digest-Realm 2236 AVP value includes quotes as well. 2238 8.5.8 Digest-Domain AVP 2240 The Digest-Domain AVP (AVP code TBD) is of type UTF8String and 2241 contains the value of the "domain" parameter included in the Digest 2242 header. Note that the "domain" parameter contains a quoted string, 2243 thus, the Digest-Domain AVP value includes quotes as well. 2245 8.5.9 Digest-Nonce AVP 2247 The Digest-Nonce AVP (AVP code TBD) is of type UTF8String and 2248 contains the value of the "nonce" parameter included in the Digest 2249 header (known as "nonce-value" according to RFC 2617 section 3.2.1). 2250 Note that "nonce-value" is a quoted string, thus, the Digest-Nonce 2251 AVP value includes quotes as well. 2253 8.5.10 Digest-Opaque AVP 2255 The Digest-Opaque AVP (AVP code TBD) is of type UTF8String and 2256 contains the value of the "opaque" parameter included in the Digest 2257 header (known as "opaque-value" according to RFC 2617 section 3.2.1). 2258 Note that "opaque-value" is a quoted string, thus, the Digest-Opaque 2259 AVP value includes quotes as well. 2261 8.5.11 Digest-Stale AVP 2263 The Digest-Stale AVP (AVP code TBD) is of type UTF8String and 2264 contains the value of the "stale" parameter included in the Digest 2265 header (see RFC 2617 section 3.2.1). Note that the "stale" parameter 2266 contains a quoted string, thus, the Digest-Stale AVP value includes 2267 quotes as well. 2269 8.5.12 Digest-Algorithm AVP 2271 The Digest-Algorithm AVP (AVP code TBD) is of type UTF8String and 2272 contains the value of the "algorithm" parameter included in the 2273 Digest header (see RFC 2617 section 3.2.1). Note that the 2274 "algorithm" parameter contains a quoted string, thus, the 2275 Digest-Algorithm AVP value includes quotes as well. 2277 8.5.13 Digest-Qop AVP 2279 The Digest-Qop AVP (AVP code TBD) is of type UTF8String and contains 2280 the value of the "qop" parameter included in the Digest header (see 2281 "qop-options" in section 3.2.1 in RFC 2617 or "message-qop" in 2282 section 3.2.2 in RFC 2617). Note that the "qop" parameter contains a 2283 quoted string, thus, the Digest-Qop AVP value includes quotes as 2284 well. 2286 8.5.14 Digest-Auth-Param AVP 2288 The Digest-Auth-Param AVP (AVP code TBD) is of type UTF8String and is 2289 the mechanism whereby the Diameter client and Diameter server can 2290 exchange possible extension parameters contained in Digest headers 2291 that are not understood by the Diameter client and for which there 2292 are no corresponding standalone AVPs. Unlike the previously listed 2293 Digest-* AVPs, the Digest-Auth-Param contains not only the value, but 2294 also the parameter name, since the parameter name is unknown to the 2295 Diameter client. The Diameter node MUST insert one Digest parameter/ 2296 value combination per AVP value. If the Digest header contains 2297 serval unknown parameters, then the Diameter implementation MUST 2298 repeat this AVP and each instance MUST contain one different unknown 2299 Digest parameter/value combination. This AVP corresponds to the 2300 "auth-param" parameter defined in RFC 2617 section 3.2.1. 2302 Example: Assume that the Diameter server wants the SIP server to send 2303 a "foo" parameter with the value set to "bar", so that the SIP server 2304 sends that combination in a SIP WWW-Authenticate header field. The 2305 Diameter server builds a grouped SIP-Authenticate AVP that contains a 2306 Digest-Auth-Param whose value is set to foo="bar". Then the SIP 2307 server creates the WWW-Authenticate header field with all the digest 2308 parameters (received in Digest-* AVPs) and adds the foo="bar" 2309 parameter to that header field. 2311 8.5.15 Digest-Username AVP 2313 The Digest-Username AVP (AVP code TBD) is of type UTF8String and 2314 contains the value of the "username" parameter included in the Digest 2315 header (see RFC 2617 section 3.2.2). 2317 Note that the Digest-Username AVP will contain the same value as 2318 the Username AVP used somewhere else. We created the 2319 Digest-Username AVP for completeness of the Digest AVPs set. 2321 8.5.16 Digest-Digest-URI AVP 2323 The Digest-Digest-URI AVP (AVP code TBD) is of type UTF8String and 2324 contains the value of the "uri" parameter in the Digest header (known 2325 as "digest-uri-value" in RFC 2617 section 3.2.2). 2327 8.5.17 Digest-Response AVP 2329 The Digest-Response AVP (AVP code TBD) is of type UTF8String and 2330 contains the value of the "response" parameter included in the Digest 2331 header (known as "request-digest" in RFC 2617 section 3.2.2). Note 2332 that "request-digest" is a quoted string, thus, the Digest-Response 2333 AVP value includes quotes as well. 2335 8.5.18 Digest-Cnonce AVP 2337 The Digest-Cnonce AVP (AVP code TBD) is of type UTF8String and 2338 contains the value of the "cnonce" parameter included in the Digest 2339 header (known as "cnonce-value" according to RFC 2617 section 3.2.2). 2340 Note that "cnonce-value" is a quoted string, thus, the Digest-Cnonce 2341 AVP value includes quotes as well. 2343 8.5.19 Digest-Nonce-Count AVP 2345 The Digest-Nonce-Count AVP (AVP code TBD) is of type UTF8String and 2346 contains the value of the "nc" parameter included in the Digest 2347 header (known as "nc-value" according to RFC 2617 section 3.2.2). 2349 8.5.20 Digest-Nextnonce AVP 2351 The Digest-Nextnonce AVP (AVP code TBD) is of type UTF8String and 2352 contains the value of the "nextnonce" parameter included in the 2353 Digest header (known as "nonce-value" in RFC 2617 section 3.2.3). 2354 Note that "nonce-value" is a quoted string, thus, the 2355 Digest-Nextnonce AVP value includes quotes as well. 2357 8.5.21 Digest-Response-Auth AVP 2359 The Digest-Response-Auth AVP (AVP code TBD) is of type UTF8String and 2360 contains the value of the "rspauth" parameter included in the Digest 2361 header (known as "response-digest" according to RFC 2617 section 2362 3.2.3). Note that "response-digest" is a quoted string, thus, the 2363 Digest-Response-Auth AVP value includes quotes as well. 2365 8.5.22 Digest-AKA-Auts AVP 2367 The Digest-AKA-Auts AVP (AVP code TBD) is of type UTF8String and 2368 contains the value of the "auts" parameter included in the Digest AKA 2369 header ("auts-param" according to RFC 3310 section 3.4). Note that 2370 "auts-param" includes quotes, thus, the Digest-AKA-Auts AVP value 2371 includes quotes as well. 2373 8.5.23 Digest-Expected-Response AVP 2375 The Digest-Expected-Response AVP (AVP code TBD) is of type UTF8String 2376 and contains the value, pre-calculated at the Diameter server, of the 2377 Digest response that the SIP UA is expected to include in the 2378 response parameter in the Digest authentication. The Diameter server 2379 MAY include this AVP to enable and assist the SIP server in 2380 authenticating the SIP UA. This pre-authentication mechanism is only 2381 applicable when the SIP UA does not use client nounces (see below). 2383 It is up to the Diameter server to include a Digest-Expected-Response 2384 AVP. The Diameter server calculates the Digest expected response 2385 with the username, password, realm and nounce as inputs, and places 2386 the result in the Digest-Expected-Response AVP value. Please note 2387 that the expected response calculation does not take into account any 2388 client nonces, since the Diameter server does not have them at the 2389 time of calculation. Therefore, the Diameter client MUST NOT use the 2390 Digest-Expected-Response AVP if the SIP UA sent a expected response 2391 based on client nonces (e.g., if the "qop" parameter is present in 2392 the Digest header). 2394 Section 9 provide further normative details about the usage of the 2395 Digest-Expected-Response AVP. 2397 8.6 SIP-Number-Auth-Items AVP 2399 The SIP-Number-Auth-Items AVP (AVP Code TBD) is of type Unsigned32 2400 and indicates the number of authentication and/or authorization 2401 vectors that the Diameter server included in a Diameter message. 2403 When the AVP is present in a request, it indicates the number of 2404 SIP-Auth-Data-Items the Diameter client is requesting. This can be 2405 used, for instance, when the SIP server is requesting several 2406 pre-calculated authentication vectors. In the answer message, the 2407 SIP-Number-Auth-Items AVP indicates the actual number of items that 2408 the Diameter server included. 2410 8.7 SIP-Deregistration-Reason AVP 2412 The SIP-Deregistration-Reason AVP (AVP Code TBD) is of type Grouped, 2413 and indicates the reason for a deregistration operation. 2415 SIP-Deregistration-Reason::= < AVP Header: TBD > 2416 { SIP-Reason-Code } 2417 [ SIP-Reason-Info ] 2418 * [ AVP ] 2420 8.7.1 SIP-Reason-Code AVP 2422 The SIP-Reason-Code AVP (AVP code TBD) is of type Enumerated, and 2423 defines the reason for the network initiated de-registration. The 2424 following values are defined: 2426 o PERMANENT_TERMINATION (0) 2427 o NEW_SIP_SERVER_ASSIGNED (1) 2428 o SIP_SERVER_CHANGE (2) 2429 o REMOVE_SIP_SERVER (3) 2431 8.7.2 SIP-Reason-Info AVP 2433 The SIP-Reason-Info AVP (AVP code TBD) is of type UTF8String, and 2434 contains textual information that can be rendered to the user, about 2435 the reason for a de-registration. 2437 8.8 SIP-AOR AVP 2439 The SIP-AOR AVP (AVP Code TBD) is of type UTF8String. The syntax of 2440 this AVP corresponds either to a SIP URI (with the format defined in 2441 RFC 3261 [3]) or a TEL URL (with the format defined in RFC 2806 [6]). 2443 The Diameter client (SIP server) uses the value found in a SIP 2444 Request-URI or a header field value of the SIP request to construct 2445 the SIP-AOR AVP. The selection of a Request-URI or a particular 2446 header field depends on the semantics of the SIP message and whether 2447 the SIP server is acting for originating or terminating requests. 2448 For instance, when the SIP server receives an INVITE request 2449 addressed to the served user, it maps the SIP Request-URI of the SIP 2450 request to this AVP. However, when the SIP server receives an INVITE 2451 request originated by the served user, it can map either the 2452 P-Asserted-Identity or the From header field values to this AVP. 2454 8.9 SIP-Visited-Network-Id AVP 2456 The SIP-Visited-Network-Id AVP (AVP Code TBD) is of type OctetString. 2458 This AVP contains an identifier that helps the home network to 2459 identify the visited network (e.g. the visited network domain name), 2460 in order to authorize roaming to such visited network. 2462 8.10 SIP-User-Authorization-Type AVP 2464 The SIP-User-Authorization-Type AVP (AVP code TBD) is of type 2465 Enumerated, and indicates the type of user authorization being 2466 performed in a User Authorization operation, i.e., the Diameter 2467 User-Authorization-Request (UAR) command. The following values are 2468 defined: 2470 o REGISTRATION (0) 2471 This value is used in case of the initial registration or 2472 re-registration. 2473 This is the default value. 2474 o DE_REGISTRATION (1) 2475 This value is used in case of the de-registration. 2476 o REGISTRATION_AND_CAPABILITIES (2) 2477 This value is used in case of initial registration or 2478 re-registration when the SIP server explicitly requests the 2479 Diameter server to get capability information. This capability 2480 information will help the SIP server to allocate another SIP 2481 server to serve the user. 2483 8.11 SIP-User-Data AVP 2485 The SIP-User-Data AVP (AVP Code TBD) is of type OctetString. The 2486 Diameter peers do not need to understand the value of this AVP. 2488 The AVP contains the user profile data required for a SIP server to 2489 give service to the user. 2491 8.12 SIP-User-Data-Already-Available AVP 2493 The SIP-User-Data-Already-Available AVP (AVP code TBD) is of type 2494 Enumerated, and gives an indication to the Diameter server about 2495 whether the Diameter client (SIP server) already got the portion of 2496 the user profile that it needs to serve the user. The following 2497 values are defined: 2499 o USER_DATA_NOT_AVAILABLE (0) 2500 The Diameter client (SIP server) does not have the data that it 2501 needs to serve the user. 2502 o USER_DATA_ALREADY_AVAILABLE (1) 2503 The Diameter client (SIP server) already has got the data that it 2504 needs to serve the user. 2506 8.13 SIP-User-Data-Request-Type AVP 2508 The SIP-User-Data-Request-Type AVP (AVP code TBD) is of type 2509 Enumerated, and indicates the portion of the user profile that the 2510 Diameter client (SIP server) is requesting to the Diameter server. 2511 The following values are defined: 2513 o COMPLETE_PROFILE (0) 2514 The Diameter client (SIP server) requests the complete user 2515 profile corresponding to one or more SIP AORs. 2516 o REGISTERED_PROFILE (1) 2517 The Diameter client (SIP server) requests the portion of the user 2518 profile that deals with registered states of one or more SIP AORs. 2519 o UNREGISTERED_PROFILE (2) 2520 The Diameter client (SIP server) request the portion of the user 2521 profile that deals with unregistered states of one or more SIP 2522 AORs. 2524 8.14 SIP-Method AVP 2526 The SIP-Method-AVP (AVP code TBD) is of type UTF8String and contains 2527 the method of the SIP request that triggered the Diameter message. 2529 8.15 New values for existing AVPs 2531 This section defines new values that the Diameter SIP application 2532 extends to already existing AVPs. 2534 8.15.1 Extension to the Result-Code AVP values 2536 The Result-Code AVP is already defined in RFC 3588 [5]. In addition 2537 to the values already defined in RFC 3588 [5], the Diameter SIP 2538 application defines the following new Result-Code AVP values: 2540 8.15.1.1 Success Result-Code AVP values 2542 A Diameter peer uses Result-Code AVP values that fall into the 2543 success category to inform the remote peer that a request has been 2544 successfully completed. 2546 o DIAMETER_FIRST_REGISTRATION 2xx1 2547 The user was not previously registered. The Diameter server has 2548 now authorized the registration. 2549 o DIAMETER_SUBSEQUENT_REGISTRATION 2xx2 2550 The user is already registered. The Diameter server has now 2551 authorized the re-registration. 2552 o DIAMETER_UNREGISTERED_SERVICE 2xx3 2553 The user is not currently registered, but the requested service 2554 can still be granted to the user. 2555 o DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2xx4 2556 The de-registration was successful. The Diameter server does not 2557 keep a record of the SIP server assigned to the user. 2558 o DIAMETER_SERVER_SELECTION 2xx5 2559 The Diameter server has authorized the registration. The user has 2560 already a SIP server assigned, but it may be necessary to select a 2561 new SIP server for the user. 2562 o DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2xx6 2563 The requested operation was successfully executed. The Diameter 2564 server is sending authentication vectors in the answer message. 2565 The Diameter server does not keep a record of the SIP server. 2566 o DIAMETER_SUCCESS_SERVER_NOT_STORED 2xx7 2567 The user was successfully authenticate. The Diameter server does 2568 not keep a record of the SIP server. 2570 8.15.1.2 Transient Failures Result-Code AVP values 2572 A Diameter peer uses a Result-Code AVP value that falls in the 2573 transient failures category to inform the remote peer that a request 2574 could not be satisfied at the time it was received, but MAY be able 2575 to satisfy the request in the future. 2577 o DIAMETER_USER_NAME_REQUIRED 4xx1 2578 The Diameter request did not contain a User-Name AVP, and it is 2579 required to complete the transaction. The Diameter peer MAY 2580 attempt the request again including a User-Name AVP. 2582 8.15.1.3 Permanent failures Result-Code AVP values 2584 A Diameter peer uses a Result-Code AVP value that fall into the 2585 permanent failure category to inform the remote peer that the request 2586 failed and should not be attempted again. 2588 o DIAMETER_ERROR_USER_UNKNOWN 5xx1 2589 The SIP-AOR AVP value does not belong to a known user in this 2590 realm. 2591 o DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5xx2 2592 The value in one of the SIP-AOR AVPs is not allocated to the user 2593 specified in the User-Name AVP. 2594 o DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5xx3 2595 A query for location information is received for a SIP AOR that 2596 has not been registered before. The user to which this identity 2597 belongs cannot be given service in this situation. 2598 o DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5xx4 2599 The user is not allowed to roam to the visited network. 2600 o DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5xx5 2601 The identity being registered has already a server assigned and 2602 the registration status does not allow that it is overwritten. 2603 o DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5xx6 2604 The authentication scheme indicated in an authentication request 2605 is not supported. 2606 o DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5xx7 2607 The SIP server address sent in the SIP-Server-URI AVP value of the 2608 Diameter Server-Assignment-Request (SAR) command is the same SIP 2609 server address that is currently assigned, but the 2610 SIP-Server-Assignment-Type AVP is not allowed, e.g., the user is 2611 registered and the Server-Assignment-Request indicates the 2612 assignment for an unregistered user. 2613 o DIAMETER_ERROR_TOO_MUCH_DATA 5xx8 2614 The Diameter peer in the SIP server receives more data than it can 2615 accept. The SIP server cannot overwrite the already stored data. 2616 o DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5xx9 2617 The SIP server informs Diameter server that the received 2618 subscription data contained information which was not recognized 2619 or supported. 2621 9. Authentication Details 2623 Authenticating a user can occur through various mechanisms. 2624 Currently HTTP Digest authentication is supported. The actual 2625 authentication is performed in either the SIP server or the Diameter 2626 server. 2628 If the Diameter server wants to retain authentication of the user, it 2629 MUST NOT include a Digest-Expected-Response AVP (part of the grouped 2630 SIP-Authenticate AVP which in turn is part of the SIP-Auth-Data-Item 2631 AVP) in a MAA message. The Diameter server MAY include a 2632 pre-calculated Digest-Expected-Response AVP in the MAA message if it 2633 wants to delegate authentication of the user to the SIP server. 2635 The fact that the SIP server is enabled to perform authentication 2636 (i.e., the Digest-Expected-Response AVP is available to the SIP 2637 server) is not enough to conclude that authentication will take place 2638 in the SIP server. It might be still possible that the SIP UA 2639 includes client nounces in the expected response (e.g., "qop" 2640 parameter present in the Digest header), in which case the 2641 pre-calculated expected response is not valid anymore. In this case 2642 the SIP server MUST request authentication to the Diameter server and 2643 MUST send a MAR message to the Diameter server, which includes a 2644 grouped SIP-Authorization AVP (part of the grouped SIP-Auth-Data-Item 2645 AVP) that mimics the Digest header containing the credentials. 2647 When requesting authentication, the Diameter client indicates in the 2648 SIP-Number-Auth-Items AVP value of a Diameter MAR message how many 2649 authentication vectors are being requested. In the Diameter MAA 2650 message, the Diameter server SHOULD indicate how many instances of 2651 SIP-Auth-Data-Item AVPs are present with the SIP-Number-Auth-Items 2652 AVP. This number may be different from the one requested in the 2653 Diameter MAR message. If multiple SIP-Auth-Data-Item AVPs are 2654 present, and their ordering is significant, the Diameter server MUST 2655 include a SIP-Item-Number AVP in each grouping to indicate the order. 2656 The SIP-Authentication-Scheme and SIP-Authenticate AVPs will contain 2657 data (typically a challenge of some kind) which the user can use for 2658 her authentication. The grouped SIP-Authorization AVP will contain 2659 the AVPs that conform the response which is expected from the user. 2661 If the Diameter server performs the authentication of the user, the 2662 Diameter MAR message that the Diameter client sends to the Diameter 2663 server MUST include all the authentication credentials supplied by 2664 the SIP UA (there might be more than a single credential, e.g., 2665 different realms, authentication of proxies, etc.). Each credential 2666 is inserted in a grouped SIP-Authorization AVP (part of the grouped 2667 SIP-Auth-Data-Item AVP). The Diameter client MUST insert a 2668 SIP-Number-Auth-Items AVP with the value set to the number of 2669 credentials enclosed. If necessary, the SIP-Authentication-Context 2670 AVP will contain any additional information (e.g., a hash of the 2671 body) needed to perform the authentication. If the authentication is 2672 successful, the Diameter MAA message will contain a Result-Code AVP 2673 indicating success, and if necessary, the Diameter server MAY include 2674 one or more SIP-Auth-Data-Item AVPs to provide further authentication 2675 vectors to the SIP server. If the authentication is unsuccessful due 2676 to missing credentials, the Diameter MAA message will include an 2677 SIP-Auth-Data-Item AVP with the SIP-Authentication-Scheme and 2678 SIP-Authenticate AVPs containing data (typically a challenge of some 2679 kind) that the user can use to authenticate itself. 2681 10. IANA Considerations 2683 This document serves as IANA registration request of a number of 2684 items: 2686 10.1 Application Identifier 2688 This document defines a standards track Application-ID in the 2689 Diameter [5] Application Identifier address space. 2691 Application name: Diameter Session Initiation Protocol (SIP) 2692 Application. 2693 Application Identifier: XXX [IANA to replace XXX with the 2694 allocated number] 2696 10.2 Command Codes 2698 This document defines new standard commands, whose Command Codes are 2699 to be allocated within the Command Codes address space in Diameter 2700 [5]. 2702 Table 1 in Section 7 contains the detailed list of Command names and 2703 Command codes that are part of this Diameter application. 2705 10.3 AVP Codes 2707 This document defines new standard AVPs, whose AVP Codes are to be 2708 allocated within the AVP Codes address space in Diameter [5]. 2710 Table 2 in Section 8 contains the detailed list of AVP names and AVP 2711 codes that are part of this Diameter application. 2713 10.4 Additional values for the Result-Code AVP value 2715 This document defines new standard Result-Code AVP values to be 2716 allocated within the Result-Code AVP address space defined in 2717 Diameter [5]. 2719 Section 8.15.1.1 lists the new Result-Code AVP values that fall into 2720 the success category, according to RFC 3588 [5] section 7.1.2. 2722 Section 8.15.1.2 lists the new Result-Code AVP values that fall into 2723 the transient failure category, according to RFC 3588 [5] section 2724 7.1.4. 2726 Section 8.15.1.3 lists the new Result-Code AVP values that fall into 2727 the permanent failures category, according to RFC 3588 [5] section 2728 7.1.5. 2730 11. Security Considerations 2732 This memo does not describe a stand-alone protocol, but a particular 2733 application for the Diameter protocol [5]. Consequently, all the 2734 security considerations applicable to Diameter automatically apply to 2735 this memo. In particular, section 13 of RFC 3588 applies to this 2736 memo. 2738 12. Contributors 2740 The authors would like to thank the following contributors who made 2741 substantial contributions to this work: 2743 Pete McCann Lucent 2744 Jaako Rajaniemi Nokia 2746 13. Acknowledgements 2748 The authors would like to thank Tony Johansson and Kevin Purser for 2749 their invaluable contribution to the start up of this application and 2750 the continuous progress. The authors would like to thank Daniel 2751 Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior for 2752 their valuable comments. 2754 The Diameter SIP Application is based on the Diameter Application for 2755 the Cx interface of the 3GPP IP Multimedia Subsystem [10]. The 2756 authors would like to thank 3GPP Working Group CN4 for this work. 2758 14. Changes with respect previous versions 2760 Note to the RFC editor: Delete this section before publication as 2761 RFC. 2763 14.1 Changes in draft-ietf-aaa-diameter-sip-app-03.txt from -02.txt 2765 o A Diameter Subscriber Locator was either a Diameter Relay or a 2766 Diameter Redirect node. We have removed the Diameter Relay 2767 functionality, since Diameter relays will not relay CER/CEA 2768 messages, thus, a Diameter client will never be able to determine 2769 which Diameter applications are running in a given Diameter 2770 server. So a Diameter Subscriber Locator is implemented as a 2771 Diameter redirect node. 2772 o Section "Registration termination" has been rewritten. Now the 2773 procedures speak about SIP soft state management, rather than SIP 2774 registration, so this procedures are applicable to SIP event 2775 subscriptions as well. A discussion on how to couple Diameter 2776 user sessions with SIP soft states is also added 2777 o Added a new Digest-Expected-Response AVP that allows the Diameter 2778 server to send a pre-calculated expected digest response to the 2779 Diameter client. This is only applicable to the case when the SIP 2780 UA does not use client nounces. 2781 o The Authentication Details Section has been updated with the 2782 latest details of the authentication process. 2784 14.2 Changes in draft-ietf-aaa-diameter-sip-app-02.txt from -01.txt 2786 o We have changed the type of the SIP-Authenticate, 2787 SIP-Authorization, SIP-Authentication-Info AVPs. Now, each is a 2788 grouped AVP and contains one or more AVPs that maps to the 2789 corresponding Digest parameter. This means that the Diameter 2790 server will receive in a different AVP each of the values of the 2791 different parameters contained in the Digest headers. This 2792 approach relieves the Diameter server of implementing a SIP parser 2793 to determine the values of each of the parameters. 2794 o Specifically added support for Digest AKA operation, as per RFC 2795 3310 [4]. A Digest-AKA-Auts AVP is added. 2796 o List of auhors trimmed. Contributors section added. 2797 o The SIP-Entity-Body-Hash is renamed to Digest-Entity-Body-Hash to 2798 be aligned with the rest of the Digest-* AVPs. 2799 o The NAS-Session-Key AVP has been deleted. We never knew why this 2800 AVP was here. 2801 o We have removed the support for key distribution. Specifically we 2802 have removed the Confidentiality-Key and Integrity-Key AVPs. 2804 14.3 Changes in draft-ietf-aaa-diameter-sip-app-01.txt from -00.txt 2806 o The SIP-Authentication-Info AVP was mistakenly typed as 2807 OctetString. We changed it to UTF8String. Since SIP is encoded 2808 in UTF8String, there is no point in having an OctetString AVP 2809 here. 2810 o The SIP-Authentication-Context AVP is changed to be a grouped AVP. 2811 It contains an SIP-Entity-Body-Hash AVP that contains the hash of 2812 the entity body (e.g., the hash of the SDP). This is because some 2813 authentication mechanisms require to make a hash of the entity 2814 body. Instead of sending the whole entity body to the Diameter 2815 server, it is more efficient to send the hash of the body. 2816 o Added an descriptive text indicating the intended use/actions of 2817 each command. 2818 o Removed references to PGP since it is deprecated in SIP. 2819 o We have focused on providing support for HTTP Digest 2820 authentication in SIP, since it is the mandatory authentication 2821 mechanism in SIP. Other documents can extend this one adding 2822 support for other authentication mechanisms if that is required in 2823 the future. 2824 o Added a Security Considerations section. 2825 o The scenario "Diameter server authenticates the user" had an 2826 error, because it was assuming that the MAR/MAA commands were used 2827 to download the user profile. However, MAR/MAA do not contain 2828 provisions to donwload any user profile. The solution is to add a 2829 SAR/SAA commands that allow the SIP server to get the user profile 2830 stored in the Diameter server. 2831 o Added the missing Redirect-Host-Usage and Redirect-Max-Cache-Time 2832 to all the answers. 2834 14.4 Changes in draft-ietf-aaa-diameter-sip-app-00.txt from 2835 draft-belinchon-aaa-diameter-mm-app-01.txt 2837 o Application name changed to Diameter SIP application. 2839 o New Definitions section added. 2840 o New Applicability section added. 2841 o The problem of locating a Diameter server is addressed with the 2842 introduction of a new Diameter Subscriber Locator role. 2843 o Added new scenarios to indicate usage in a more generic internet 2844 environment. 2845 o A few AVPs have been renamed to accurately reflect the intention 2846 of the AVP. For instance, SIP-Server-Name becomes SIP-Server-URI, 2847 and SIP-Public-User-ID becomes SIP-AOR. 2848 o MAR command can be used more generically. Particularly, it does 2849 not assume a SIP REGISTER message. So we had to add a new 2850 SIP-Method AVP to indicate the SIP method that triggered the MAR 2851 command. 2852 o User-Name is no longer mandatory in requests, as typically a SIP 2853 request will not contain a user name. As a result of this change, 2854 a new transit failure Result-Code AVP value has been added: 2855 DIAMETER_USER_NAME_REQUIRED, to indicate the Diameter client that 2856 the request didn't include a User-Name AVP and it is required to 2857 process it. Typically SIP servers, upon the reception of this 2858 Result-Code AVP value, will generate a SIP 401 (Unauthorized) or 2859 407 (Proxy Authentication Required) to request the user name from 2860 the user. 2861 o IANA section has been carefully rewritten to give detailed 2862 instructions to IANA on what is required to register. 2864 15. References 2866 15.1 Normative References 2868 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2869 Levels", BCP 14, RFC 2119, March 1997. 2871 [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2872 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 2873 Basic and Digest Access Authentication", RFC 2617, June 1999. 2875 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2876 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2877 Session Initiation Protocol", RFC 3261, June 2002. 2879 [4] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer 2880 Protocol (HTTP) Digest Authentication Using Authentication and 2881 Key Agreement (AKA)", RFC 3310, September 2002. 2883 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 2884 "Diameter Base Protocol", RFC 3588, September 2003. 2886 15.2 Informational References 2888 [6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2889 2000. 2891 [7] Calhoun, P., Johansson, T., Perkins, C. and T. Hiller, 2892 "Diameter Mobile IPv4 Application", 2893 draft-ietf-aaa-diameter-mobileip-18 (work in progress), May 2894 2004. 2896 [8] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 2897 Network Access Server Application", 2898 draft-ietf-aaa-diameter-nasreq-14 (work in progress), February 2899 2004. 2901 [9] Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. 2902 Hakala, "Diameter Credit-control Application", 2903 draft-ietf-aaa-diameter-cc-05 (work in progress), May 2004. 2905 [10] 3GPP, "Cx and Dx interfaces based on the Diameter protocol; 2906 Protocol details", 3GPP TS 29.229, October 2003. 2908 Authors' Addresses 2910 Miguel A. Garcia Martin (editor) 2911 Nokia 2912 P.O. Box 407 2913 NOKIA GROUP, FIN 00045 2914 Finland 2916 Phone: +358 50 480 4586 2917 EMail: miguel.an.garcia@nokia.com 2919 Maria-Carmen Belinchon 2920 Ericsson 2921 Via de los Poblados 13 2922 Madrid 28033 2923 Spain 2925 Phone: +34 91 339 3535 2926 EMail: maria.carmen.belinchon@ericsson.com 2927 Miguel A. Pallares-Lopez 2928 Ericsson 2929 Via de los Poblados 13 2930 Madrid 28033 2931 Spain 2933 Phone: +34 91 339 4222 2934 EMail: miguel-angel.pallares@ericsson.com 2936 Carolina Canales-Valenzuela 2937 Ericsson 2938 Via de los Poblados 13 2939 Madrid 28033 2940 Spain 2942 Phone: +34 91 339 2680 2943 EMail: carolina.canales@ericsson.com 2945 Kalle Tammi 2946 Nokia 2947 P.O.Box 301 2948 Nokia Group 00045 2949 Finland 2951 EMail: kalle.tammi@nokia.com 2953 Intellectual Property Statement 2955 The IETF takes no position regarding the validity or scope of any 2956 Intellectual Property Rights or other rights that might be claimed to 2957 pertain to the implementation or use of the technology described in 2958 this document or the extent to which any license under such rights 2959 might or might not be available; nor does it represent that it has 2960 made any independent effort to identify any such rights. Information 2961 on the procedures with respect to rights in RFC documents can be 2962 found in BCP 78 and BCP 79. 2964 Copies of IPR disclosures made to the IETF Secretariat and any 2965 assurances of licenses to be made available, or the result of an 2966 attempt made to obtain a general license or permission for the use of 2967 such proprietary rights by implementers or users of this 2968 specification can be obtained from the IETF on-line IPR repository at 2969 http://www.ietf.org/ipr. 2971 The IETF invites any interested party to bring to its attention any 2972 copyrights, patents or patent applications, or other proprietary 2973 rights that may cover technology that may be required to implement 2974 this standard. Please address the information to the IETF at 2975 ietf-ipr@ietf.org. 2977 Disclaimer of Validity 2979 This document and the information contained herein are provided on an 2980 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2981 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2982 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2983 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2984 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2985 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2987 Copyright Statement 2989 Copyright (C) The Internet Society (2004). This document is subject 2990 to the rights, licenses and restrictions contained in BCP 78, and 2991 except as set forth therein, the authors retain all their rights. 2993 Acknowledgment 2995 Funding for the RFC Editor function is currently provided by the 2996 Internet Society.