RFC 4740
Diameter Session Initiation Protocol (SIP) Application
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
+-----------------------------------+------+----------------+-------+ | 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].
+----------------------------------+------+-----+-----+------+------+
| 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]
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
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:
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.
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
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.
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.
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
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].
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)
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:
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]):
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.
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)
