Name

AVP Code

Data Type

Vendor

Accounting-Realtime-Required

483

Enumerated

IETF

Specifies the behavior of a Diameter client in scenarios where accounting record delivery is disrupted. It defines how a client should proceed based on the status of accounting record transmission to the server. This AVP can be included in the response from a Diameter home authorization server or in the Accounting-Answer (ACA) message from an accounting server. Values:

1: DELIVER_AND_GRANT - Service MUST only be granted if there is an active connection to an accounting server. Backup servers may be used.

2: GRANT_AND_STORE - Service SHOULD be granted even if the connection is lost, as long as accounting records can be locally stored.

3: GRANT_AND_LOSE - Service SHOULD be granted even if the accounting records cannot be delivered or stored.

Accounting-Record-Number

485

Unsigned32

IETF

The Accounting-Record-Number AVP uniquely identifies an accounting record within a Diameter session. In combination with the globally unique Session-Id, this AVP ensures global uniqueness, facilitating reliable matching of accounting records and their confirmations.

The value of this AVP is sequential within a session:

0 for EVENT_RECORD and START_RECORD.

1, 2, ... n for each INTERIM_RECORD.

n+1 for the STOP_RECORD.

This approach guarantees ordered processing and simplifies correlation between Diameter accounting messages.

Accounting-Record-Type

480

Enumerated

IETF

Specifies the type of accounting record being transmitted. It is used to distinguish between different phases of an accounting session and event-based accounting records. The AVP helps coordinate session tracking and billing for Diameter clients and servers. Values:

1 EVENT_RECORD: Indicates a one-time event where the start and end occur simultaneously. This record contains all relevant service information in a single record.

2 START_RECORD: Used to indicate the beginning of a measurable-length service session. Contains information relevant to the session initiation.

3 INTERIM_RECORD: Provides cumulative accounting information for an ongoing session. Typically sent during re-authentication, re-authorization, or at application-defined intervals.

4 STOP_RECORD: Sent to terminate a session, containing cumulative accounting details relevant to the completed session.

Accounting-Sub-Session-Id

287

Unsigned64

IETF

Used to identify sub-sessions within an accounting session. This AVP ensures that multiple sub-sessions can be uniquely tracked under the same Session-Id. Its value is incrementally increased by one for each new sub-session, maintaining a monotonically increasing sequence. If this AVP is absent, it indicates that sub-sessions are not in use, except in cases of STOP_RECORD. A STOP_RECORD message without this AVP signals the termination of all sub-sessions associated with the given Session-Id.

Acct-Application-Id

259

Unsigned32

IETF

Used to indicate support for the accounting portion of a Diameter application. This AVP is primarily utilized during the exchange of Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) messages. If it appears in other Diameter messages, its value must align with the Application Id specified in the Diameter message header.

Acct-Multi-Session-Id

50

UTF8String

IETF

Used to link multiple related accounting sessions. Each session will have its own unique Session-Id, but all related sessions will share the same Acct-Multi-Session-Id. This AVP enables logical grouping of sessions for tracking or management purposes. The Diameter server may include this AVP in an Authorization-Answer (AA) message, and it must be included in all accounting messages for sessions that belong to the group identified by the Acct-Multi-Session-Id.

Acct-Session-Id

44

OctetString

IETF

Used exclusively in scenarios where RADIUS/Diameter translation is required. It carries the content of the RADIUS Acct-Session-Id attribute, ensuring compatibility and continuity between RADIUS and Diameter systems. This AVP facilitates the identification and correlation of accounting sessions when transitioning between the two protocols.

Auth-Application-Id

258

Unsigned32

IETF

Utilized to indicate support for the Authentication and Authorization (A&A) functionality of a specific application in Diameter. This AVP is critical for identifying and matching the application context in Diameter messages.

If included in any Diameter message other than CER (Capabilities-Exchange-Request) or CEA (Capabilities-Exchange-Answer), the Auth-Application-Id value must align with the Application-Id in the Diameter message header.

It is fundamental for establishing compatibility between peers supporting different Diameter applications.

Auth-Grace-Period

276

Unsigned32

IETF

The Auth-Grace-Period AVP defines the duration (in seconds) for which the Diameter server will maintain session resources after the Authorization-Lifetime AVP expires. This grace period gives the client an opportunity to renew the session or perform necessary cleanup actions before resources are forcibly reclaimed by the server.

Authorization-Lifetime

291

Unsigned32

IETF

Specifies the maximum duration (in seconds) of service granted to a user before re-authentication and/or re-authorization is required. It ensures controlled service access and resource management, preventing indefinite access without periodic checks.

Auth-Request-Type

274

Enumerated

IETF

Specifies the type of authentication or authorization operation requested in a Diameter message. It is included in application-specific authentication requests to inform peers of the required action: authentication, authorization, or both. Values:

1 AUTHENTICATE_ONLY: The request is for authentication only, including relevant application-specific authentication AVPs.

2 AUTHORIZE_ONLY: The request is for authorization only, including application-specific AVPs necessary for the service.

3 AUTHORIZE_AUTHENTICATE: The request includes both authentication and authorization information required for the service.

Auth-Session-State

277

Enumerated

IETF

Specifies whether session state is maintained for a particular Diameter session. It can be included in a request as a client hint, but the value provided in the server's response is binding. This AVP defines the expected session management behavior between the client and server. Values:

0 STATE_MAINTAINED: Session state is maintained, requiring the client to send a session termination message when the user’s service ends.

1 NO_STATE_MAINTAINED: No session state is maintained, and the client will not send session termination messages upon service expiration.

Destination-Host

293

DiameterIdentity

IETF

Specifies the fully qualified domain name (FQDN) of the host to which the Diameter message is targeted. This AVP is used to direct messages to a specific Diameter node within a network.

Destination-Realm

283

DiameterIdentity

IETF

Specifies the realm to which a Diameter message should be routed. It is a critical routing AVP included in request messages to ensure the message reaches its intended target realm. It must not appear in response messages.

Realm Identification: Typically represents a domain name, such as example.com.

Routing Decisions: It helps Diameter nodes make routing decisions based on the target realm.

Insertion by Clients: Diameter clients insert the realm portion of the User-Name AVP into this field.

Diameter-Class

25

OctetString

IETF

Used by Diameter servers to store and return state information to access devices. This AVP is essential in maintaining session continuity across re-authorization, session termination, and accounting messages.

Disconnect-Cause

273

Enumerated

IETF

Used in the Disconnect-Peer-Request (DPR) message to inform the receiving peer about the reason for terminating the transport connection. This AVP enables efficient handling of transport connection shutdowns by providing context-specific information about the disconnection. Values:

0 REBOOTING: Indicates an imminent scheduled reboot. The receiver of this DPR value MAY attempt to reconnect.

1 BUSY: Indicates constrained internal resources. The receiver SHOULD NOT attempt to reconnect.

2 DO_NOT_WANT_TO_TALK_TO_YOU: Indicates no need for the connection as no messages are expected. The receiver SHOULD NOT attempt to reconnect.

Error-Message

281

UTF8String

IETF

Provides a human-readable error description, intended to accompany a Result-Code AVP in Diameter messages. This AVP is not designed for automatic error processing but rather for debugging or user interpretation of the error's cause. The Error-Message AVP content is not guaranteed to be parsed or standardized, as it serves a descriptive purpose only.

Error-Reporting-Host

294

DiameterIdentity

IETF

Identifies the Diameter node that set the Result-Code AVP to a value indicating failure (i.e., other than 2001 - Success). It is used in scenarios where the Diameter node that originated the error is different from the one identified in the Origin-Host AVP of the message. This AVP aids in troubleshooting and debugging Diameter network issues.

Event-Timestamp

55

Time

IETF

Records the time at which a specific event occurred. It is represented as the number of seconds since January 1, 1900, 00:00 UTC. This AVP can be included in Accounting-Request and Accounting-Answer messages to provide precise timing information for the reported event.

Experimental-Result

297

Grouped

IETF

Provides vendor-specific result information for Diameter messages, indicating whether a request was successfully completed or if an error occurred. The AVP structure is defined as follows:

Vendor-Id AVP: Identifies the vendor responsible for the result code.

Experimental-Result-Code AVP: Specifies the result of the operation.

This AVP is primarily used in vendor-specific applications and is included in answer messages instead of the standard Result-Code AVP.

Experimental-Result-Code

298

Unsigned32

IETF

Contains a vendor-assigned value that represents the result of processing a specific Diameter request. This AVP is typically used in conjunction with the Experimental-Result AVP to provide vendor-specific result codes for operations. It follows the conventions and categories of the standard Result-Code AVP, ensuring compatibility and consistent behavior in error handling.

Failed-AVP

279

Grouped

IETF

Provides detailed debugging information in cases where a Diameter request cannot be processed due to errors in one or more AVPs. It is included in a Diameter answer message to highlight the offending AVP(s) that caused the rejection or incomplete processing of the request. The Failed-AVP AVP contains the exact AVP(s) that triggered the error, enabling the sender to identify and correct the issue. Reasons for failure can include:

• Malformed AVP construction.

• Unsupported or unrecognized AVP.

• Invalid AVP value.

• Missing mandatory AVP.

• Excluded AVP that should not be present.

• Exceeding the allowable number of AVP occurrences.

The Result-Code AVP accompanying the Failed-AVP AVP provides the specific reason for the error.

Firmware-Revision

267

Unsigned32

IETF

Informs a Diameter peer about the firmware version of the device issuing the Diameter message. For devices without a specific firmware version (e.g., general-purpose computers running Diameter software modules), this AVP may represent the revision of the Diameter software module instead.

Host-IP-Address

257

Address

IETF

Used to communicate the IP address of the sender in Diameter messages. This AVP ensures that Diameter peers are aware of the sender's reachable IP addresses, particularly when using transport protocols such as SCTP [RFC4960] or DTLS/SCTP [RFC6083]. When included in Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) messages, it advertises all IP addresses that a Diameter node will use as source addresses.

Inband-Security-Id

299

Unsigned32

IETF

Advertises a Diameter peer's support for specific in-band security mechanisms. Its primary purpose is to indicate the security protocols supported by a Diameter node, such as TLS or DTLS. This AVP is typically included in Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) messages, although its usage in these messages is not recommended. Instead, the security capabilities of Diameter entities are expected to be determined through static configuration or Diameter Peer Discovery.

Multi-Round-Time-Out

272

Unsigned32

IETF

Specifies the maximum time (in seconds) that an access device must allocate for a user to respond to an authentication request in multi-round authentication scenarios. This AVP is typically included in application-specific authorization answer messages where the Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. It ensures that the user is given sufficient time to complete multi-round authentication without prematurely terminating the session.

Origin-Host

264

DiameterIdentity

IETF

Identifies the Diameter endpoint that originated the Diameter message. It serves as a unique identifier for the originating host within the network. This AVP is mandatory and must be included in all Diameter messages. Relay agents are prohibited from modifying the value of this AVP, ensuring the integrity of the message's source identification.

Origin-Realm

296

DiameterIdentity

IETF

Identifies the administrative domain (realm) of the Diameter node that originates a Diameter message. It is a mandatory AVP and must be included in all Diameter messages. This AVP facilitates routing of Diameter messages across different domains by providing a clear indication of the source realm.

Origin-State-Id

278

Unsigned32

IETF

Used to represent a monotonically increasing value that reflects the state of a Diameter entity, particularly when it restarts and loses its previous state (e.g., during a reboot). This AVP allows other Diameter entities to determine the validity of sessions associated with an earlier state.

Product-Name

269

UTF8String

IETF

Provides a vendor-assigned name for the product. It serves as an identifier for the product within Diameter messages and is primarily used for informational purposes.

Proxy-Host

280

DiameterIdentity

IETF

Used to identify the Diameter host that inserted a Proxy-Info AVP into a Diameter message. It serves as a traceable marker for each proxy through which the message has passed.

Proxy-Info

284

Grouped

IETF

The Proxy-Info AVP provides details about the Diameter proxy node that handled the message. It includes the identity of the proxy and its local state information. This AVP ensures traceability by appending proxy-specific details to the message at every hop. The AVP structure is defined as follows:

Proxy-Host: The identifier of the proxy that added this AVP. (Mandatory).

Proxy-State: A field used to store state information local to the proxy. (Mandatory).

AVP: Optional additional AVPs that may be added as required by specific applications or implementations. Optional (0 or *).

Proxy-State

33

OctetString

IETF

Carries opaque state information generated by a Diameter proxy node. It enables proxies to maintain state consistency without requiring direct interaction with other Diameter nodes. This AVP is treated as a black box by all Diameter entities except the one that created it.

Re-Auth-Request-Type

285

Enumerated

IETF

Specifies the action required from a Diameter client when the Authorization-Lifetime expires. It informs the client whether a re-authorization only or a combined re-authorization and re-authentication is expected. This AVP is typically included in application-specific authentication answer messages containing a positive Authorization-Lifetime value. Values:

0 AUTHORIZE_ONLY: A re-authorization only is required when the Authorization-Lifetime expires.

1 AUTHORIZE_AUTHENTICATE: Both re-authorization and re-authentication are required upon expiration.

Redirect-Host

292

DiameterURI

IETF

Specifies one or more alternative Diameter nodes to which a request should be forwarded. It is included in answer messages when redirection is required. This AVP is used in conjunction with the Redirect-Host-Usage AVP to indicate how the redirect behavior should be applied. The Redirect-Host AVP is mandatory in Diameter messages where the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the 'E' bit is enabled in the Diameter header. 

Redirect-Host-Usage

261

Enumerated

IETF

Provides instructions for how the host specified in the Redirect-Host AVP should be utilized for routing. This AVP is included in answer messages where the E bit is set, and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. It defines the scope and duration of redirection applicability, such as whether the redirection applies to all sessions, specific realms, or particular applications. Values:

0 DONT_CACHE: Do not cache the host specified in the Redirect-Host AVP. Default behavior.

1 ALL_SESSION: Use the Redirect-Host for all messages in the same session.

2 ALL_REALM: Use the Redirect-Host for all messages destined for the same realm.

3 REALM_AND_APPLICATION: Use the Redirect-Host for all messages for the specified application within the same realm.

4 ALL_APPLICATION: Use the Redirect-Host for all messages for the specified application.

5 ALL_HOST: Use the Redirect-Host for all messages destined for the host that generated the redirection.

6 ALL_USER: Use the Redirect-Host for all messages for the specified user.

Redirect-Max-Cache-Time

262

Unsigned32

IETF

Specifies the maximum duration, in seconds, that peers and routing table entries created as a result of a Redirect-Host AVP should be cached. This AVP ensures efficient management of redirection resources while limiting stale or unreachable entries. This AVP must be included in Diameter answer messages when:

• The E bit is set.

• The Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.

• The Redirect-Host-Usage AVP is set to a non-zero value.

Once a host is deemed unreachable, all associated cache, peer, and routing table entries must be removed.

Result-Code

268

Unsigned32

IETF

Indicates the outcome of a Diameter request, specifying whether the operation was successful or if an error occurred. It is a mandatory AVP in all Diameter answer messages for IETF-defined Diameter application specifications.

The Result-Code values are divided into five classes based on the leading digit of the 32-bit unsigned integer. These classes provide a high-level categorization of the result:

1xxx: Informational responses

2xxx: Successful responses

3xxx: Protocol errors

4xxx: Transient failures

5xxx: Permanent failures

When a non-successful Result-Code is used (a value other than a 2xxx or DIAMETER_REDIRECT_INDICATION), the Error-Reporting-Host AVP must be included if the entity setting the Result-Code is different from the origin host. 

Route-Record

282

DiameterIdentity

IETF

Used to capture the routing path taken by a Diameter message. It is of type DiameterIdentity and contains the identity of each node in the route. When a Diameter node processes a request, it appends its Origin-Host value into the Route-Record AVP to record the routing path. This AVP must align with the Origin-Host AVP from the corresponding Capabilities-Exchange message. 

Session-Binding

270

Bitmask (Unsigned32)

IETF

A bitmask-type AVP that informs the Diameter client about specific session binding requirements for re-authentication, session termination, and accounting messages. It indicates whether these messages must exclude the Destination-Host AVP and be routed to the same authorization server as the original session. The AVP defines three key bits to control behavior:

RE_AUTH (Bit 1): Determines whether re-authentication messages must omit the Destination-Host AVP.

STR (Bit 2): Specifies whether Session-Termination-Request (STR) messages must omit the Destination-Host AVP.

ACCOUNTING (Bit 4): Indicates whether accounting messages must omit the Destination-Host AVP.

When the bits are set (1), the respective message type must not include the Destination-Host AVP. When the bits are cleared (0, default), the Destination-Host AVP must be present.

Session-Id

263

UTF8String

IETF

Uniquely identifies a specific session and must be included in all Diameter messages related to the session. It is globally and eternally unique, ensuring consistency throughout the session's lifecycle. The Session-Id plays a critical role in correlating historical authentication information with accounting records. The AVP must be included only once per message. Its value remains unchanged for the duration of the session. When present, it should appear immediately after the Diameter header. The Session-Id includes two parts:

Mandatory Portion: Contains the sender's identity, formatted as a DiameterIdentity type.

Implementation-Defined Portion: Guarantees eternal uniqueness and may include additional identifiers.

Session-Server-Failover

271

Enumerated

IETF

Specifies the behavior of a Diameter client when a re-auth or Session-Termination-Request (STR) message fails due to delivery issues. It informs the client how to proceed when delivery fails and whether to retry or terminate the session. This AVP may be present in application-specific authorization answer messages. If absent, the default behavior is REFUSE_SERVICE. It is often used when the Session-Binding AVP is not included or its bits are set to zero. Values:

0 REFUSE_SERVICE: Terminate service without retrying if the re-auth or STR message delivery fails.

1 TRY_AGAIN: Resend the failed message without the Destination-Host AVP if delivery fails.

2 ALLOW_SERVICE: Assume re-authorization succeeded if re-auth message fails. Terminate the session if STR fails.

3 TRY_AGAIN_ALLOW_SERVICE: Retry without the Destination-Host AVP. If retry fails for re-auth, assume success; if for STR, terminate session.

Session-Timeout

27

Unsigned32

IETF

Specifies the maximum duration, in seconds, that a user session is allowed to remain active before being terminated. It ensures proper session management by defining a time limit for the session's validity. If both Session-Timeout and Authorization-Lifetime AVPs are present in an answer message, the value of Session-Timeout MUST be greater than or equal to Authorization-Lifetime. If the session times out, the access device MUST issue a Session-Termination-Request (STR), unless agreed otherwise between the access device and the home server.

Supported-Vendor-Id

265

Unsigned32

IETF

Used in Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) messages to specify the support for Vendor-Specific AVPs defined by a particular vendor. This AVP contains the IANA "SMI Network Management Private Enterprise Codes" value, which uniquely identifies the vendor whose AVPs are supported by the Diameter node.

Termination-Cause

295

Enumerated

IETF

Used to specify the reason for the termination of a session on the access device. This AVP is helpful in understanding why a session ended and can be included in various Diameter messages to aid in session lifecycle tracking. The enumerated values for this AVP are defined in the IANA registry for Termination-Cause AVP Values (IANATCV). Values:

1 DIAMETER_LOGOUT: The user terminated the session voluntarily (e.g., logged out).

2 DIAMETER_SERVICE_NOT_PROVIDED: The session was terminated because the requested service was not provided.

3 DIAMETER_BAD_ANSWER: The session was terminated due to an invalid or incomplete answer from a Diameter server.

4 DIAMETER_ADMIN: The session was terminated by an administrator's action.

Note: Additional values may exist in the IANA registry for vendor-specific or custom implementations.

User-Name

1

UTF8String

IETF

Contains the user's identifier in a format consistent with the Network Access Identifier (NAI) specification (RFC4282). This AVP is used in Diameter messages to identify the user in various scenarios, such as authentication, authorization, and accounting processes. The value is typically represented as a UTF-8 encoded string, allowing for compatibility with internationalized usernames.

Vendor-Id

266

Unsigned32

IETF

Identifies the Diameter software vendor using the IANA "SMI Network Management Private Enterprise Codes" (ENTERPRISE) value. This AVP is primarily used for vendor identification and debugging purposes, as part of Capabilities Exchange Requests (CER) or Answers (CEA).

Vendor-Specific-Application-Id

260

Grouped

IETF

Used to advertise support for a vendor-specific Diameter application. It enables Diameter nodes to signal their capability to handle specific vendor-assigned application IDs for authentication or accounting purposes. This AVP must contain either an Auth-Application-Id AVP or an Acct-Application-Id AVP, but not both. It may also include a Vendor-Id AVP identifying the vendor responsible for defining the application. The AVP structure is defined as follows:

Vendor-Specific-Application-Id: Identifies the vendor responsible for the application ID.

Auth-Application-Id: Specifies the application ID for authentication and authorization.

Acct-Application-Id: Specifies the application ID for accounting.