tech-invite   World Map     

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

RFC 4740

 
 
 

Diameter Session Initiation Protocol (SIP) Application

Part 3 of 4, p. 44 to 59
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 44 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part