Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4740

Diameter Session Initiation Protocol (SIP) Application

Pages: 72
Proposed Standard
Errata
Part 3 of 4 – Pages 44 to 59
First   Prev   Next

Top   ToC   RFC4740 - Page 44   prevText

9. Diameter SIP Application AVPs

This section defines new AVPs used in this Diameter SIP application. Applications compliant with this specification MUST implement these AVPs. Table 2 lists the new AVPs defined in this Diameter SIP application. The following abbreviations are used in the Data-Type column: o DURI: DiameterURI o E: Enumerated o G: Grouped o OS: OctetString o UTF8S: UTF8String o U32: Unsigned32
Top   ToC   RFC4740 - Page 45
   +-----------------------------------+------+----------------+-------+
   | Attribute Name                    | AVP  | Reference      | Data- |
   |                                   | Code |                | Type  |
   +-----------------------------------+------+----------------+-------+
   | SIP-Accounting-Information        |  368 | Section 9.1    | G     |
   | SIP-Accounting-Server-URI         |  369 | Section 9.1.1  | DURI  |
   | SIP-Credit-Control-Server-URI     |  370 | Section 9.1.2  | DURI  |
   | SIP-Server-URI                    |  371 | Section 9.2    | UTF8S |
   | SIP-Server-Capabilities           |  372 | Section 9.3    | G     |
   | SIP-Mandatory-Capability          |  373 | Section 9.3.1  | U32   |
   | SIP-Optional-Capability           |  374 | Section 9.3.2  | U32   |
   | SIP-Server-Assignment-Type        |  375 | Section 9.4    | E     |
   | SIP-Auth-Data-Item                |  376 | Section 9.5    | G     |
   | SIP-Authentication-Scheme         |  377 | Section 9.5.1  | E     |
   | SIP-Item-Number                   |  378 | Section 9.5.2  | U32   |
   | SIP-Authenticate                  |  379 | Section 9.5.3  | G     |
   | SIP-Authorization                 |  380 | Section 9.5.4  | G     |
   | SIP-Authentication-Info           |  381 | Section 9.5.5  | G     |
   | SIP-Number-Auth-Items             |  382 | Section 9.6    | U32   |
   | SIP-Deregistration-Reason         |  383 | Section 9.7    | G     |
   | SIP-Reason-Code                   |  384 | Section 9.7.1  | E     |
   | SIP-Reason-Info                   |  385 | Section 9.7.2  | UTF8S |
   | SIP-Visited-Network-Id            |  386 | Section 9.9    | UTF8S |
   | SIP-User-Authorization-Type       |  387 | Section 9.10   | E     |
   | SIP-Supported-User-Data-Type      |  388 | Section 9.11   | UTF8S |
   | SIP-User-Data                     |  389 | Section 9.12   | G     |
   | SIP-User-Data-Type                |  390 | Section 9.12.1 | UTF8S |
   | SIP-User-Data-Contents            |  391 | Section 9.12.2 | OS    |
   | SIP-User-Data-Already-Available   |  392 | Section 9.13   | E     |
   | SIP-Method                        |  393 | Section 9.14   | UTF8S |
   +-----------------------------------+------+----------------+-------+

                           Table 2: Defined AVPs

   Table 3 expands the table of AVPs included in Section 4.5 of RFC 3588
   [RFC3588].  The table indicates the Diameter AVPs defined in this
   Diameter SIP Application, their possible flag values, and whether the
   AVP may be encrypted.  The acronyms 'M', 'P', and 'V' refer to AVP
   flags whose semantics are described in RFC 3588 [RFC3588].  The value
   of the 'Encr' column is also described in RFC 3588 [RFC3588].
Top   ToC   RFC4740 - Page 46
   +----------------------------------+------+-----+-----+------+------+
   | Attribute Name                   | MUST | MAY | SHD | MUST | Encr |
   |                                  |      |     | NOT |  NOT |      |
   +----------------------------------+------+-----+-----+------+------+
   | SIP-Accounting-Information       |   M  |  P  |     |   V  |   N  |
   | SIP-Accounting-Server-URI        |   M  |  P  |     |   V  |   N  |
   | SIP-Credit-Control-Server-URI    |   M  |  P  |     |   V  |   N  |
   | SIP-Server-URI                   |   M  |  P  |     |   V  |   N  |
   | SIP-Server-Capabilities          |   M  |  P  |     |   V  |   N  |
   | SIP-Mandatory-Capability         |   M  |  P  |     |   V  |   N  |
   | SIP-Optional-Capability          |   M  |  P  |     |   V  |   N  |
   | SIP-Server-Assignment-Type       |   M  |  P  |     |   V  |   N  |
   | SIP-Auth-Data-Item               |   M  |  P  |     |   V  |   N  |
   | SIP-Authentication-Scheme        |   M  |  P  |     |   V  |   N  |
   | SIP-Item-Number                  |   M  |  P  |     |   V  |   N  |
   | SIP-Authenticate                 |   M  |  P  |     |   V  |   N  |
   | SIP-Authorization                |   M  |  P  |     |   V  |   N  |
   | SIP-Authentication-Info          |   M  |  P  |     |   V  |   N  |
   | SIP-Number-Auth-Items            |   M  |  P  |     |   V  |   N  |
   | SIP-Deregistration-Reason        |   M  |  P  |     |   V  |   N  |
   | SIP-Reason-Code                  |   M  |  P  |     |   V  |   N  |
   | SIP-Reason-Info                  |   M  |  P  |     |   V  |   N  |
   | SIP-Visited-Network-Id           |   M  |  P  |     |   V  |   N  |
   | SIP-User-Authorization-Type      |   M  |  P  |     |   V  |   N  |
   | SIP-Supported-User-Data-Type     |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data                    |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Type               |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Contents           |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Already-Available  |   M  |  P  |     |   V  |   N  |
   | SIP-Method                       |   M  |  P  |     |   V  |   N  |
   +----------------------------------+------+-----+-----+------+------+

                  Table 3: Summary of the new AVPs flags

9.1. SIP-Accounting-Information AVP

The SIP-Accounting-Information (AVP Code 368) is of type Grouped, and contains the Diameter addresses of those nodes that are able to collect accounting information. The SIP-Accounting-Information AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]): SIP-Accounting-Information ::= < AVP Header: 368 > * [ SIP-Accounting-Server-URI ] * [ SIP-Credit-Control-Server-URI ] * [ AVP]
Top   ToC   RFC4740 - Page 47

9.1.1. SIP-Accounting-Server-URI AVP

The SIP-Accounting-Server-URI AVP (AVP Code 369) is of type DiameterURI. This AVP contains the address of a Diameter server that is able to receive SIP-session-related accounting information.

9.1.2. SIP-Credit-Control-Server-URI AVP

The SIP-Credit-Control-Server-URI AVP (AVP Code 370) is of type DiameterURI. This AVP contains the address of a Diameter server that is able to authorize real-time credit control usage. The Diameter Credit-Control Application [RFC4006] may be used for this purpose.

9.2. SIP-Server-URI AVP

The SIP-Server-URI AVP (AVP Code 371) is of type UTF8String. This AVP contains a SIP or SIPS URI (as defined in RFC 3261 [RFC3261]) that identifies a SIP server.

9.3. SIP-Server-Capabilities AVP

The SIP-Server-Capabilities AVP (AVP Code 372) is of type Grouped. The Diameter indicates in this AVP the requirements for a particular SIP capability, so that the Diameter client (SIP server) is able to select another appropriate SIP server to serve the user. The SIP-Server-Capabilities AVP allows a Diameter client (SIP server) to select another SIP server for triggering or executing services to the user. A user may have enabled some services that require the implementation of certain capabilities in the SIP server that triggers or executes those services. For example, the SIP server that triggers or executes services to this user may need to implement SIP servlets [JSR-000116], Call Processing Language (CPL) [RFC3880], or any other kind of capability. Or perhaps that user belongs to a premium users group that has a certain stringent quality-of-service agreement that requires a fast SIP server. The capabilities required or recommended to a given user are conveyed in the SIP-Server-Capabilities AVP. When it receives them, the Diameter client (SIP server) that does the SIP server selection needs to have the means to find out available SIP servers that meet the required or optional capabilities. Such means are outside the scope of this specification. Note that the SIP-Server-Capabilities AVP assists the Diameter client (SIP server) to produce a subset of all the available SIP servers to be allocated to the user in the Home Realm; this is the subset that conforms the requirements of capabilities on a per-user basis. Typically this subset will be formed of more than a single SIP
Top   ToC   RFC4740 - Page 48
   server, so once the subset of those SIP servers is identified, it is
   possible that several instances of these SIP servers exist, in which
   case the Diameter client (SIP server) should choose one particular
   SIP server to execute and trigger services to this user.  It is
   expected that at this point the SIP server (Diameter client) will
   follow the procedures of RFC 3263 [RFC3263] to allocate one SIP
   server to the user.

   The SIP-Server-Capabilities AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Server-Capabilities ::= < AVP Header: 372 >
                                * [ SIP-Mandatory-Capability ]
                                * [ SIP-Optional-Capability ]
                                * [ SIP-Server-URI ]
                                * [ AVP ]

9.3.1. SIP-Mandatory-Capability AVP

The SIP-Mandatory-Capability AVP (AVP Code 373) is of type Unsigned32. The value represents a certain capability (or set of capabilities) that have to be fulfilled by the SIP server allocated to the user. The semantics of the different values are not standardized, as it is a matter of the administrative network to allocate its own semantics within its own network. Each value has to represent a single capability within the administrative network.

9.3.2. SIP-Optional-Capability AVP

The SIP-Optional-Capability AVP (AVP Code 374) is of type Unsigned32. The value represents a certain capability (or set of capabilities) that, optionally, may be fulfilled by the SIP server allocated to the user. The semantics of the different values are not standardized, as it is a matter of the administrative network to allocate its own semantics within its own network. Each value has to represent a single capability within the administrative network.

9.4. SIP-Server-Assignment-Type AVP

The SIP-Server-Assignment-Type AVP (AVP Code 375) is of type Enumerated and indicates the type of server update being performed in a Diameter Server-Assignment-Request (SAR) operation. The following values are defined:
Top   ToC   RFC4740 - Page 49
   o  NO_ASSIGNMENT (0)
      The Diameter client uses this value to request the user profile of
      a SIP AOR, without affecting the registration state of that
      identity.

   o  REGISTRATION (1)
      First SIP registration of a SIP AOR.

   o  RE_REGISTRATION (2)
      Subsequent SIP registration of a SIP AOR.

   o  UNREGISTERED_USER (3)
      The SIP server has received a SIP request (e.g., SIP INVITE)
      addressed for a SIP AOR that is not registered.

   o  TIMEOUT_DEREGISTRATION (4)
      The SIP registration timer of an identity has expired.

   o  USER_DEREGISTRATION (5)
      The SIP server has received a request to deregister a SIP AOR.

   o  TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6)
      The SIP registration timer of an identity has expired.  The SIP
      server keeps the user data stored and requests the Diameter server
      to store the SIP server address.

   o  USER_DEREGISTRATION_STORE_SERVER_NAME (7)
      The SIP server has received a user-initiated deregistration
      request.  The SIP server keeps the user data stored and requests
      the Diameter server to store the SIP server address.

   o  ADMINISTRATIVE_DEREGISTRATION (8)
      The SIP server, due to administrative reasons, has deregistered a
      SIP AOR.

   o  AUTHENTICATION_FAILURE (9)
      The authentication of a user has failed.

   o  AUTHENTICATION_TIMEOUT (10)
      The authentication timer has expired.

   o  DEREGISTRATION_TOO_MUCH_DATA (11)
      The SIP server has requested user profile information from the
      Diameter server and has received a volume of data higher than it
      can accept.
Top   ToC   RFC4740 - Page 50

9.5. SIP-Auth-Data-Item AVP

The SIP-Auth-Data-Item (AVP Code 376) is of type Grouped and contains the authentication and/or authorization information pertaining to a user. When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to include a SIP-Authenticate AVP, the Diameter server MUST send a maximum of one authentication data item (e.g., in case the SIP request contained several credentials). Section 11 contains a detailed discussion and normative text of the case when a SIP request contains several credentials. The SIP-Auth-Data-Item AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]): SIP-Auth-Data-Item ::= < AVP Header: 376 > { SIP-Authentication-Scheme } [ SIP-Item-Number ] [ SIP-Authenticate ] [ SIP-Authorization ] [ SIP-Authentication-Info ] * [ AVP ]

9.5.1. SIP-Authentication-Scheme AVP

The SIP-Authentication-Scheme AVP (AVP Code 377) is of type Enumerated and indicates the authentication scheme used in the authentication of SIP services. RFC 2617 identifies this value as an "auth-scheme" (see Section 1.2 of RFC 2617 [RFC2617]). The only currently defined value is: o DIGEST (0) to indicate HTTP Digest authentication as specified in RFC 2617 [RFC2617] Section 3.2.1. Derivative work is also considered Digest authentication scheme, as long as the "auth-scheme" is identified as Digest in the SIP headers carrying the HTTP authentication. This includes, e.g., the HTTP Digest authentication using AKA [RFC3310]. Each HTTP Digest directive (parameter) is transported in a corresponding AVP, whose name follows the pattern Digest-*. The Digest-* AVPs are RADIUS attributes imported from the RADIUS Extension for Digest Authentication [RFC4590] namespace, allowing a smooth transition between RADIUS and Diameter applications supporting SIP. The Diameter SIP application goes a step further by grouping the Digest-* AVPs into the SIP-Authenticate, SIP-Authorization, and
Top   ToC   RFC4740 - Page 51
   SIP-Authentication-Info grouped AVPs that correspond to the SIP WWW-
   Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization,
   and Authentication-Info headers fields, respectively.

      Note: Due to the fact that HTTP Digest authentication [RFC2617] is
      the only mandatory authentication mechanism in SIP, this memo only
      provides support for HTTP Digest authentication and derivative
      work such as HTTP Digest authentication using AKA [RFC3310].
      Extensions to this memo can register new values and new AVPs to
      provide support for other authentication schemes or extensions to
      HTTP Digest authentication.

      Note: Although RFC 2617 [RFC2617] defines the Basic and Digest
      schemes for authenticating HTTP requests, RFC 3261 [RFC3261] only
      imports HTTP Digest as a mechanism to provide authentication in
      SIP.

   Due to syntactic requirements, HTTP Digest authentication has to
   escape quote characters in contents of HTTP Digest directives.  When
   translating directives into Digest-* AVPs, the Diameter client or
   server removes the surrounding quotes where present, as required by
   the syntax of the Digest-* attributes defined in the "RADIUS
   Extension for Digest Authentication" [RFC4590].

9.5.2. SIP-Item-Number AVP

The SIP-Item-Number (AVP Code 378) is of type Unsigned32 and is included in a SIP-Auth-Data-Item grouped AVP in circumstances where there are multiple occurrences of SIP-Auth-Data-Item AVPs and the order of processing is relevant. The AVP indicates the order in which the Grouped SIP-Auth-Data-Item should be processed. Lower values of the SIP-Item-Number AVP indicate that the whole SIP-Auth-Data-Item SHOULD be processed before other SIP-Auth-Data-Item AVPs that contain higher values in the SIP-Item-Number AVP.

9.5.3. SIP-Authenticate AVP

The SIP-Authenticate AVP (AVP Code 379) is of type Grouped and contains a reconstruction of either the SIP WWW-Authenticate or Proxy-Authentication header fields specified in RFC 2617 [RFC2617] for the HTTP Digest authentication scheme. Additionally, the AVP may include a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617 [RFC2617]). H(A1) allows the Diameter client to create an expected response and compare it with the Digest response received from the SIP UA.
Top   ToC   RFC4740 - Page 52
   The SIP-Authenticate AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

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

9.5.4. SIP-Authorization AVP

The SIP-Authorization AVP (AVP Code 380) is of type Grouped and contains a reconstruction of either the SIP Authorization or Proxy-Authorization header fields specified in RFC 2617 [RFC2617] for the HTTP Digest authentication scheme. The SIP-Authorization AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]): SIP-Authorization ::= < AVP Header: 380 > { Digest-Username } { Digest-Realm } { Digest-Nonce } { Digest-URI } { Digest-Response } [ Digest-Algorithm ] [ Digest-CNonce ] [ Digest-Opaque ] [ Digest-QoP ] [ Digest-Nonce-Count ] [ Digest-Method] [ Digest-Entity-Body-Hash ] * [ Digest-Auth-Param ] * [ AVP ]

9.5.5. SIP-Authentication-Info AVP

The SIP-Authentication-Info AVP (AVP Code 381) is of type Grouped and contains a reconstruction of the SIP Authentication-Info header specified in RFC 2617 [RFC2617] for the HTTP Digest authentication scheme.
Top   ToC   RFC4740 - Page 53
   The SIP-Authentication-Info AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

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

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

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

9.5.6. Digest AVPs

The following AVPs are RADIUS attributes defined in the RADIUS Extension for Digest Authentication [RFC4590] and imported by this specification: Digest-AKA-Auts, Digest-Algorithm, Digest-Auth-Param, Digest-CNonce, Digest-Domain, Digest-Entity-Body-Hash, Digest-HA1, Digest-Method, Digest-Nextnonce, Digest-Nonce, Digest-Nonce-Count, Digest-Opaque, Digest-QoP, Digest-Realm, Digest-Response, Digest-Response-Auth, Digest-URI, Digest-Username, and Digest-Stale.
9.5.6.1. Considerations about Digest-HA1 AVP
The Digest-HA1 AVP contains the value, pre-calculated at the Diameter server, of H(A1) as defined in RFC 2617 [RFC2617]. The Diameter client can use H(A1) to calculate the expected Digest response, according to this challenge. If the SIP UA is in possession of the credentials, the calculated expected response and the response sent from the SIP UA will match. The Diameter server MAY include this AVP to enable and assist the SIP server in authenticating the SIP UA. This scenario is not applicable when the Diameter server is configured to use a session MD5 (MD5-sess) algorithm, because the
Top   ToC   RFC4740 - Page 54
   Diameter server requires the client nonce to compute the H(A1) before
   sending it to the Diameter client, and the client nonce might not be
   available when the computation of H(A1) is done.  Therefore, if the
   final authentication is delegated to the Diameter client, it is
   RECOMMENDED to configure the Diameter server to use algorithms
   different than MD5-sess in HTTP Digest.

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

   Section 11 provides further normative details about the usage of the
   Digest-HA1 AVP.

9.5.6.2. Considerations about Digest-Entity-Body-Hash AVP
The Digest-Entity-Body-Hash AVP contains a hash of the entity body contained in the SIP message. This hash is required by HTTP Digest with quality of protection set to "auth-int". Diameter clients MUST use this AVP to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the Diameter server requires verification of the integrity of the entity body (e.g., qop parameter set to "auth-int"). The clarifications described in Section 22.4 of RFC 3261 [RFC3261] about the hash of empty entity bodies apply to the Digest-Entity-Body-Hash AVP.
9.5.6.3. Considerations about Digest-Auth-Param AVP
The Digest-Auth-Param AVP is the mechanism whereby the Diameter client and Diameter server can exchange possible extension parameters contained in Digest headers that are either not understood by the Diameter client or for which there are no corresponding stand-alone AVPs. Unlike the previously listed Digest-* AVPs, the Digest-Auth-Param contains not only the value, but also the parameter name, since it is unknown to the Diameter client. The Diameter node MUST insert one Digest parameter/value combination per AVP value. If the Digest header contains several unknown parameters, then the Diameter implementation MUST repeat this AVP and each instance MUST contain one different unknown Digest parameter/value combination. This AVP corresponds to the "auth-param" parameter defined in Section 3.2.1 of RFC 2617 [RFC2617].
Top   ToC   RFC4740 - Page 55
   Example: Assume that the Diameter server wants the SIP server to send
   a "foo" parameter with the value set to "bar", so that the SIP server
   sends that combination in a SIP WWW-Authenticate header field.  The
   Diameter server builds a grouped SIP-Authenticate AVP that contains a
   Digest-Auth-Param whose value is set to foo="bar".  Then the SIP
   server creates the WWW-Authenticate header field with all the digest
   parameters (received in Digest-* AVPs) and adds the foo="bar"
   parameter to that header field.

9.6. SIP-Number-Auth-Items AVP

The SIP-Number-Auth-Items AVP (AVP Code 382) is of type Unsigned32 and indicates the number of authentication and/or authorization credentials that the Diameter server included in a Diameter message. When the AVP is present in a request, it indicates the number of SIP-Auth-Data-Items the Diameter client is requesting. This can be used, for instance, when the SIP server is requesting several pre-calculated authentication credentials. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual number of items that the Diameter server included.

9.7. SIP-Deregistration-Reason AVP

The SIP-Deregistration-Reason AVP (AVP Code 383) is of type Grouped and indicates the reason for a deregistration operation. The SIP-Deregistration-Reason AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]): SIP-Deregistration-Reason ::= < AVP Header: 383 > { SIP-Reason-Code } [ SIP-Reason-Info ] * [ AVP ]

9.7.1. SIP-Reason-Code AVP

The SIP-Reason-Code AVP (AVP Code 384) is of type Enumerated and defines the reason for the network initiated deregistration. The following values are defined: o PERMANENT_TERMINATION (0) o NEW_SIP_SERVER_ASSIGNED (1) o SIP_SERVER_CHANGE (2) o REMOVE_SIP_SERVER (3)
Top   ToC   RFC4740 - Page 56

9.7.2. SIP-Reason-Info AVP

The SIP-Reason-Info AVP (AVP Code 385) is of type UTF8String and contains textual information that can be rendered to the user, about the reason for a deregistration.

9.8. SIP-AOR AVP

The SIP-AOR AVP is a RADIUS attribute imported from the RADIUS Extension for Digest Authentication [RFC4590] namespace, allowing a smooth transition between RADIUS and Diameter applications supporting SIP. The SIP-AOR AVP carries the URI of the intended user related to the SIP request (whose location in SIP may vary depending on the actual SIP request and whether the SIP server is acting on Diameter due to a SIP-originated or terminating requests). The Diameter client (SIP server) uses the value found in a SIP Request-URI or a header field value of the SIP request to construct the SIP-AOR AVP. The selection of a Request-URI or a particular header field to create the value of the SIP-AOR AVP depends on the semantics of the SIP message and whether the SIP server is acting for originating or terminating requests. For instance, when the SIP server receives an INVITE request addressed to the served user (e.g., the SIP server is receiving a terminating SIP request), it maps the SIP Request-URI of the SIP request to this AVP. However, when the SIP server receives an INVITE request originated by the served user, it can map either the P-Asserted-Identity or the From header field values to this AVP. If the SIP server is acting as a SIP registrar, then it maps the To header field of the REGISTER request to the SIP-AOR AVP.

9.9. SIP-Visited-Network-Id AVP

The SIP-Visited-Network-Id AVP (AVP Code 386) is of type UTF8String. This AVP contains an identifier that helps the home network identify the visited network (e.g., the visited network domain name), in order to authorize roaming to that visited network.

9.10. SIP-User-Authorization-Type AVP

The SIP-User-Authorization-Type AVP (AVP Code 387) is of type Enumerated and indicates the type of user authorization being performed in a User Authorization operation, i.e., the Diameter User-Authorization-Request (UAR) command. The following values are defined:
Top   ToC   RFC4740 - Page 57
   o  REGISTRATION (0)
      This value is used for initial registration or re-registration.
      This is the default value.

   o  DEREGISTRATION (1)
      This value is used for deregistration.

   o  REGISTRATION_AND_CAPABILITIES (2)
      This value is used for initial registration or re-registration
      when the SIP server explicitly requests the Diameter server to get
      capability information.  This capability information helps the SIP
      server to allocate another SIP server to serve the user.

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

The SIP-Supported-User-Data-Type AVP (AVP Code 388) is of type UTF8String and contains a string that identifies the type of supported user data (user profile, see SIP-User-Data AVP (Section 9.12)) supported in the node. The AVP can be repeated, if the SIP server supports several user data types. In case of repetition, the Diameter client should order the different instances of this AVP according to its preferences. When the Diameter client inserts this AVP in a SAR message, it allows the Diameter client to provide an indication to the Diameter server of the types of user data supported by the SIP server. The Diameter server, upon inspection of these AVPs, will return a suitable SIP-User-Data AVP (Section 9.12) of the type indicated in the SIP-User-Data-Type AVP (Section 9.12.1).

9.12. SIP-User-Data AVP

The SIP-User-Data AVP (AVP Code 389) is of type Grouped. This AVP allows the Diameter server to transport user-specific data, such as a user profile, to the SIP server (in the Diameter client). The Diameter server selects a type of user data that is understood by the SIP server in the Diameter client, and has been indicated in a SIP-Supported-User-Data-Type AVP. In case the Diameter client indicated support for several types of user data, the Diameter server SHOULD choose the first type supported by the client. The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP that indicates the type of user data included in the SIP-User-Data-Contents-AVP. The SIP-User-Data AVP is defined as follows (per the grouped-avp-def of RFC 3588 [RFC3588]):
Top   ToC   RFC4740 - Page 58
      SIP-User-Data ::= < AVP Header: 389 >
                        { SIP-User-Data-Type }
                        { SIP-User-Data-Contents }
                      * [ AVP ]

9.12.1. SIP-User-Data-Type AVP

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

9.12.2. SIP-User-Data-Contents AVP

The SIP-User-Data-Contents AVP (AVP Code 391) is of type OctetString. The Diameter peers do not need to understand the value of this AVP. The AVP contains the user profile data required for a SIP server to give service to the user.

9.13. SIP-User-Data-Already-Available AVP

The SIP-User-Data-Already-Available AVP (AVP Code 392) is of type Enumerated and gives an indication to the Diameter server about whether the Diameter client (SIP server) already received the portion of the user profile needed in order to serve the user. The following values are defined: o USER_DATA_NOT_AVAILABLE (0) The Diameter client (SIP server) does not have the data that it needs to serve the user. o USER_DATA_ALREADY_AVAILABLE (1) The Diameter client (SIP server) already has received the data that it needs to serve the user.
Top   ToC   RFC4740 - Page 59

9.14. SIP-Method AVP

The SIP-Method-AVP (AVP Code 393) is of type UTF8String and contains the method of the SIP request that triggered the Diameter message. The Diameter server MUST use this AVP solely for authorization of SIP requests, and MUST NOT use it to compute the Digest authentication. To compute the Digest authentication, the Diameter server MUST use the Digest-Method AVP instead.


(page 59 continued on part 4)

Next Section