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 .
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.
