Name

AVP Code

Data Type

Vendor

SIP-Accounting-Information

368

Grouped

IETF

Used to provide the Diameter addresses of nodes capable of collecting accounting information within a SIP (Session Initiation Protocol) environment. This AVP facilitates the integration of accounting and credit-control mechanisms in SIP-based services by identifying servers responsible for handling such operations.

The AVP structure is defined as follows:

SIP-Accounting-Server-URI (UTF8String, Optional): Specifies the Diameter URIs of servers responsible for accounting information collection. Supports multiple entries for distributed or redundant configurations.

SIP-Credit-Control-Server-URI (UTF8String, Optional): Identifies servers responsible for credit-control tasks such as session quota management and authorization. Allows multiple URIs for scalability and fault tolerance.

SIP-Accounting-Server-URI

369

DiameterURI

IETF

Used to specify the Diameter server address capable of receiving accounting information related to SIP sessions. It allows seamless integration of accounting mechanisms into SIP-based architectures by providing a standardized means of identifying accounting servers. Typically included within the SIP-Accounting-Information AVP, supporting multiple entries for distributed systems.

This AVP should conform to the DiameterURI format, as defined in [RFC 3588], e.g., aaa://server.example.com:3868.

It must include the transport protocol, such as aaa or aaas, followed by the host and optional port.

SIP-Auth-Data-Item

376

Grouped

IETF

Used to carry authentication and authorization information related to a user in SIP-based Diameter applications. It provides a structured format for transmitting various parameters required for SIP authentication and authorization mechanisms.

When the server includes a SIP-Authenticate AVP within this AVP, it MUST send only one authentication data item, even if the SIP request contains multiple credentials.

Handling multiple credentials requires adherence to the rules specified in Section 11 of [RFC 4740].

The AVP structure is defined as follows:

SIP-Authentication-Scheme (Mandatory): Specifies the authentication scheme used for SIP requests, e.g., Digest, TLS-DSA, or TLS-RSA.

SIP-Item-Number (Optional): Identifies the position of the current authentication item in cases where multiple authentication items are processed sequentially.

SIP-Authenticate (Optional): Contains authentication challenges sent by the server to the client to initiate authentication.

SIP-Authorization (Optional): Includes authorization data sent by the client to the server for authenticating SIP requests.

SIP-Authentication-Info (Optional): Carries additional information regarding the authentication process, such as next-nonce values and algorithm-specific parameters.

SIP-Authenticate

379

Grouped

IETF

Designed to reconstruct the SIP WWW-Authenticate or Proxy-Authentication header fields as specified in [RFC 2617] for the HTTP Digest authentication scheme. It supports the inclusion of authentication parameters required for validating SIP user credentials, enabling secure and standardized authentication in SIP-based Diameter applications.

The AVP structure is defined as follows:

Digest-Realm (Mandatory): Specifies the protection domain or realm used for HTTP Digest authentication. Serves as a namespace within which the credentials are valid.

Digest-Nonce (Mandatory): Contains a server-generated nonce value to ensure uniqueness and prevent replay attacks.

Digest-Domain (Optional): Defines the protection space and specifies the URIs that fall under this realm.

Digest-Opaque (Optional): An optional string provided by the server to maintain session state without revealing internal information.

Digest-Stale (Optional): Indicates whether the provided nonce is stale ('true') or valid ('false'). Helps manage expired or reused nonce values.

Digest-Algorithm (Optional): Specifies the hash algorithm used for generating the digest, e.g., MD5 or SHA-256. Defaults to MD5 if not explicitly provided.

Digest-QoP (Optional): Represents the Quality of Protection (QoP) level applied, such as auth (authentication only) or auth-int (authentication with integrity protection).

Digest-HA1 (Optional): Provides the precomputed hash H(A1) value as defined in [RFC 2617]. Enables efficient verification of authentication responses.

Digest-Auth-Param (Optional, Multiple): Allows the inclusion of additional custom parameters required by specific SIP implementations or extensions.

SIP-Authentication-Info

381

Grouped

IETF

Used to reconstruct the SIP Authentication-Info header, as specified in [RFC 2617] for the HTTP Digest authentication scheme. It is designed to carry authentication-related parameters required for secure SIP session handling and message integrity verification.

The AVP structure is defined as follows:

Digest-Nextnonce (Optional): Represents a new nonce value issued by the server for subsequent requests, ensuring session continuity and security against replay attacks.

Digest-QoP (Optional): Specifies the Quality of Protection (QoP) parameter, which influences the level of authentication security. Values include auth (authentication only) and auth-int (authentication with integrity protection). If set to auth-int, the Digest-Response-Auth must be computed by the Diameter client.

Digest-Response-Auth (Optional): Contains the server-generated digest response authentication value (rspauth) for validating the SIP request. May be omitted if QoP = auth-int, in which case the Diameter client must compute it dynamically.

Digest-CNonce (Optional): Represents the client-generated nonce used to guarantee uniqueness of the digest computation.

Digest-Nonce-Count (Optional): Tracks the number of requests sent with the same nonce, enabling detection of replay attacks.

SIP-Authentication-Scheme

377

Enumerated

IETF

Specifies the authentication scheme used for SIP service authentication within the Diameter protocol. This AVP corresponds to the auth-scheme parameter in SIP headers, as defined in [RFC 2617], and is primarily used to support HTTP Digest authentication, including AKA authentication [RFC 3310].

Each HTTP Digest directive (parameter) is transported in a corresponding Digest- AVP* (e.g., Digest-Response, Digest-Algorithm), enabling smooth interoperability between RADIUS and Diameter SIP applications.

Enumerated Values:

0 DIGEST: Represents HTTP Digest authentication as specified in [RFC 2617], Section 3.2.1. This includes derivative methods such as HTTP Digest authentication using AKA [RFC 3310].

The Diameter SIP application groups Digest-* AVPs into three Grouped AVPs, corresponding to SIP headers:

SIP-Authenticate: WWW-Authenticate / Proxy-Authenticate

SIP-Authorization: Authorization / Proxy-Authorization

SIP-Authentication-Info: Authentication-Info

SIP-Authorization

380

Grouped

IETF

Used to reconstruct the Authorization and Proxy-Authorization header fields of SIP messages as specified in [RFC 2617]. It supports the HTTP Digest authentication scheme and carries the parameters necessary to authenticate SIP requests.

This AVP enables Diameter servers to handle SIP-specific authorization mechanisms while maintaining compatibility with HTTP Digest authentication. 

When multiple credentials are present in a SIP request, this AVP processes only one at a time, ensuring streamlined handling of authentication data.

The AVP structure is defined as follows:

Digest-Username (Mandatory): Specifies the username used in the Digest calculation. It must match the credentials provided by the user agent.

Digest-Realm (Mandatory): Defines the protection space, often tied to a specific domain, that governs access permissions.

Digest-Nonce (Mandatory): Contains a server-generated nonce used to prevent replay attacks. It is sent by the server in a challenge and returned by the client for validation.

Digest-URI (Mandatory): Represents the URI of the resource the client intends to access. This ensures the request is specific to the authorized resource.

Digest-Response (Mandatory): Holds the calculated response hash used to verify the validity of the provided credentials.

Digest-Algorithm (Optional): Specifies the hash algorithm (e.g., MD5) used for Digest computation. Defaults to MD5 if not explicitly provided.

Digest-CNonce (Optional): Provides a client-generated nonce for additional protection against replay attacks, particularly for quality-of-protection (qop) modes.

Digest-Opaque (Optional): Carries server-provided opaque data that must be returned unchanged to verify session continuity.

Digest-QoP (Optional): Defines the quality of protection, such as auth or auth-int, influencing integrity verification during the Digest computation.

Digest-Nonce-Count (Optional): Tracks the number of times a nonce has been used, protecting against replay attacks by enforcing sequence order.

Digest-Method (Optional): Identifies the HTTP method (e.g., REGISTER, INVITE) associated with the request, ensuring method-specific authorization checks.

Digest-Entity-Body-Hash (Optional): Contains a hash of the SIP message body, used when auth-int quality of protection is specified.

Digest-Auth-Param (Optional, Multiple): Placeholder for additional parameters required by extensions to the Digest authentication scheme or protocol-specific enhancements.

SIP-Credit-Control-Server-URI

370

DiameterURI

IETF

Used to specify the address of a Diameter server capable of authorizing and managing real-time credit control functions for SIP services. This AVP facilitates interactions between the SIP application and the Diameter Credit-Control Application to handle charging, balance checks, and service authorization before allowing access or continuing SIP sessions. It MUST be present when SIP sessions require prepaid or usage-based billing models where credit checks are mandatory before service delivery. The AVP can be used in conjunction with the SIP-Accounting-Server-URI AVP for comprehensive charging and accounting setups in SIP-based networks. 

SIP-Deregistration-Reason

383

Grouped

IETF

Provides information regarding the reason for a SIP deregistration operation. It is used to communicate the cause of the deregistration, offering both a predefined reason code and optional descriptive information. This AVP is crucial for managing SIP session lifecycle events, particularly in scenarios where users explicitly unregister their devices or when network events force deregistration. It enables detailed reporting and logging of deregistration causes, supporting fault detection and analytics.

This AVP MUST be included in deregistration-related messages where the reason for deregistration is relevant, such as network-initiated deregistration due to timeout or user-requested termination.

The AVP structure is defined as follows:

SIP-Reason-Code (Mandatory): Enumerated value indicating the specific reason for deregistration.

SIP-Reason-Info (Optional): A UTF8 string providing additional context or explanation related to the deregistration reason, such as error descriptions or debugging messages.

SIP-Item-Number

378

Unsigned32

IETF

Specifies the processing order of multiple SIP-Auth-Data-Item AVPs within a grouped AVP structure. It is used when multiple authentication data items are included in a message, ensuring that they are processed in the correct sequence. Lower values of the SIP-Item-Number AVP indicate higher processing priority, meaning the AVPs with smaller values should be processed first. If only one SIP-Auth-Data-Item is included, this AVP MAY be omitted.

SIP-Mandatory-Capability

373

Unsigned32

IETF

Specifies a capability (or set of capabilities) that must be supported by the SIP server allocated to the user. It allows networks to enforce specific requirements for SIP server capabilities to ensure compatibility and functional compliance. The values carried in this AVP are not standardized and are specific to the administrative policies of the network. It is the responsibility of the administrative network to define and maintain the semantics of these values, ensuring proper interpretation and enforcement within the network. If the SIP server does not support one or more mandatory capabilities specified, it should reject the request or indicate an error response.

SIP-Method

393

UTF8String

IETF

Identifies the SIP method used in the SIP request that triggered the Diameter message. It is primarily intended for authorizing SIP requests within Diameter signaling and must not be utilized for computing Digest authentication. Instead, the Digest-Method AVP should be used for such purposes.

Typical SIP methods that may appear in this AVP include standard SIP methods like INVITE, REGISTER, MESSAGE, OPTIONS, ACK, BYE, CANCEL, INFO, PRACK, SUBSCRIBE, NOTIFY, PUBLISH, and REFER.

SIP-Number-Auth-Items

382

Unsigned32

IETF

Used to specify the number of authentication and/or authorization credentials included in a Diameter message. It facilitates coordination between SIP servers and Diameter servers regarding the expected and actual number of authentication items exchanged during authentication and authorization procedures.

In Requests:

• Indicates the number of SIP-Auth-Data-Items that the Diameter client is requesting from the Diameter server. Useful for scenarios requiring multiple pre-calculated authentication credentials, such as when handling multiple authentication challenges in a single SIP session.

In Responses:

• Specifies the actual number of SIP-Auth-Data-Items provided by the Diameter server in the answer message. Ensures alignment between the requested and supplied credentials, allowing clients to handle cases where fewer or more items are returned than initially requested.

SIP-Optional-Capability

374

Unsigned32

IETF

Used to indicate optional capabilities that may be supported by a SIP server assigned to a user. Unlike mandatory capabilities, the features described by this AVP are not required but can enhance functionality if implemented.

The semantics of these values are not standardized and are left to the discretion of the administrative network, allowing flexibility in defining and implementing capabilities.

Each capability must be uniquely represented by a single value, ensuring compatibility across network elements within the same administrative domain.

SIP-Reason-Code

384

Enumerated

IETF

Used to specify the reason for a network-initiated deregistration of a SIP user. It provides predefined values that describe the cause of deregistration, enabling consistent interpretation across network components. This AVP is included in the SIP-Deregistration-Reason AVP as part of a grouped AVP structure to convey deregistration details.

Enumerated Values:

0 - PERMANENT_TERMINATION: Indicates that the SIP session is permanently terminated, and re-registration is not allowed.

1 - NEW_SIP_SERVER_ASSIGNED: Specifies that the user has been assigned to a new SIP server, requiring re-registration with the new server.

2 - SIP_SERVER_CHANGE: Denotes that a change in the SIP server configuration requires the user to re-register.

3 - REMOVE_SIP_SERVER: Implies that the SIP server associated with the user is being removed, prompting deregistration and migration to a different server or service.

SIP-Reason-Info

385

UTF8String

IETF

Provides textual information regarding the reason for a deregistration. It is intended to convey human-readable details that can be presented to the user, enhancing transparency and improving user experience during network-initiated deregistration events. It should be used to supplement the enumerated SIP-Reason-Code by adding contextual information specific to the deregistration scenario.

SIP-Server-Assignment-Type

375

Enumerated

IETF

Used in Diameter Server-Assignment-Request (SAR) operations to indicate the type of server update being performed for a SIP Address of Record (AOR). It provides context for registration, deregistration, and profile updates, ensuring accurate session management and authentication processes within SIP environments.

Enumerated Values:

0 - NO_ASSIGNMENT: Requests the user profile of a SIP AOR without altering its registration state.

1 - REGISTRATION: Indicates the first SIP registration of a SIP AOR.

2 - RE_REGISTRATION: Used for subsequent registrations of a SIP AOR, maintaining continuity.

3 - UNREGISTERED_USER: Signifies an attempt to address an unregistered SIP AOR in a SIP request (e.g., SIP INVITE).

4 - TIMEOUT_DEREGISTRATION: Occurs when the registration timer expires, triggering deregistration.

5 - USER_DEREGISTRATION: Reflects a user-initiated deregistration request for a SIP AOR.

6 - TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME: Similar to timeout deregistration, but stores the SIP server address for later use.

7 - USER_DEREGISTRATION_STORE_SERVER_NAME: Indicates a user-initiated deregistration request while retaining stored data and the SIP server address.

8 - ADMINISTRATIVE_DEREGISTRATION: Specifies deregistration for administrative reasons by the SIP server.

9 - AUTHENTICATION_FAILURE: Used when authentication of a user fails, leading to deregistration or restricted access.

10 - AUTHENTICATION_TIMEOUT: Occurs when the authentication timer expires, preventing further registration attempts.

11 - DEREGISTRATION_TOO_MUCH_DATA: Reflects a scenario where the Diameter server provides more data than the SIP server can handle, requiring deregistration.

SIP-Server-Capabilities

372

Grouped

IETF

Conveys the capabilities required or recommended for a SIP server to handle specific services requested by a user. It allows the Diameter client (SIP server) to evaluate whether available SIP servers can meet the specified requirements and select an appropriate SIP server for service execution or triggering.

This AVP helps ensure that the selected SIP server supports the features or performance standards required by a user, such as premium quality-of-service agreements or support for SIP servlets and Call Processing Language (CPL).

The selection process is outside the scope of this specification but is expected to use mechanisms like [RFC 3263] for SIP server discovery.

The AVP structure is defined as follows:

SIP-Mandatory-Capability (Optional, Multiple): A list of Unsigned32 values representing mandatory features or capabilities that the SIP server must support. These are non-negotiable requirements, and a server lacking any specified capability cannot be selected.

SIP-Optional-Capability (Optional, Multiple): A list of Unsigned32 values representing optional features or capabilities that are desirable but not required. Servers that meet these capabilities are preferred but not mandatory.

SIP-Server-URI (Optional, Multiple): A list of DiameterURI values identifying available SIP server addresses that may fulfill the specified capabilities. These URIs can include hostnames, IP addresses, and port numbers.

SIP-Server-URI

371

UTF8String

IETF

Specifies the Uniform Resource Identifier (URI) of a SIP or SIPS server. It is used to identify and locate SIP servers, enabling proper routing and handling of SIP requests.

The URI format must comply with [RFC 3261], supporting both SIP (sip:) and SIPS (sips:) schemes. These URIs typically include the server hostname, IP address, port number, and transport protocol where required.

SIP-Supported-User-Data-Type

388

UTF8String

IETF

Specifies the type of user data supported by the SIP server. It is primarily used to indicate the format or profile type that the SIP server can process for user-related information, such as service profiles or preferences.

This AVP may appear multiple times to indicate support for multiple user data types.

If repeated, the Diameter client should order the AVPs based on its preference, with the most preferred type appearing first.

When included in a Server-Assignment-Request (SAR), this AVP allows the Diameter client to inform the Diameter server about supported user data types (SIP-User-Data-Type AVP).

The Diameter server evaluates these preferences and responds with a SIP-User-Data AVP [RFC 4740](Section 9.12) containing user data of a type specified in this AVP.

SIP-User-Authorization-Type

387

Enumerated

IETF

Specifies the type of user authorization being performed in a User Authorization operation. It is primarily used in the Diameter User-Authorization-Request (UAR) command to define whether the operation relates to registration, deregistration, or registration with capability retrieval.

Enumerated Values:

REGISTRATION (0): Used for initial registration or re-registration of a SIP user.

Default value if no explicit authorization type is specified.

DEREGISTRATION (1): Used to deregister a user, removing the existing registration state from the system.

REGISTRATION_AND_CAPABILITIES (2): Combines registration with a request for capability information about the user. Enables the SIP server to request additional capabilities from the Diameter server to assist in selecting an alternative SIP server for serving the user.

SIP-User-Data

389

Grouped

IETF

Used to transport user-specific data, such as a user profile, from the Diameter server to the SIP server (Diameter client). This AVP enables the transfer of data types that are supported by the client, facilitating service provisioning and user-specific configuration in SIP-enabled networks. When multiple data types are supported, the server SHOULD choose the first type listed by the client.

The AVP structure is defined as follows:

SIP-User-Data-Type (Mandatory): Specifies the type of user data included in the SIP-User-Data-Contents AVP.

SIP-User-Data-Contents (Mandatory): Contains the actual user-specific data, such as service configurations, authentication information, or profile settings as per the type specified in the SIP-User-Data-Type.

SIP-User-Data-Already-Available

392

Enumerated

IETF

Used to inform the Diameter server whether the Diameter client (SIP server) already has the portion of the user profile required to serve the user.

When the client has no data, the server must send the necessary profile information.

When the client already has the required data, no additional profile information needs to be transmitted.

Enumerated Values:

USER_DATA_NOT_AVAILABLE (0): Indicates that the Diameter client (SIP server) does not have the required user data to serve the user. The Diameter server should send the SIP-User-Data AVP with the necessary profile information.

USER_DATA_ALREADY_AVAILABLE (1): Indicates that the Diameter client (SIP server) already has the required user data to serve the user. The Diameter server does not need to resend profile information.

SIP-User-Data-Contents

391

OctetString

IETF

Used to carry user profile data required by a SIP server to deliver services to the user. The content of this AVP is opaque to Diameter peers—it is treated as a binary or text payload that does not require interpretation by intermediate nodes.

SIP-User-Data-Type

390

UTF8String

IETF

Used to specify the type of user data included in the SIP-User-Data AVP (AVP Code 389). It helps categorize the content carried within the SIP-User-Data AVP for interpretation by the SIP server. Organizations defining custom data types should use a canonical DNS-based naming convention to avoid conflicts. Both client and server must be pre-configured with matching interpretations for the specified type to ensure proper handling of data.

SIP-Visited-Network-Id

386

UTF8String

IETF

Used to identify the visited network in a roaming scenario. It typically contains the domain name or identifier of the visited network, enabling the home network to authorize and validate the roaming request. The AVP must be treated as trusted information and should be validated to avoid spoofing attacks or unauthorized access attempts.