ACR AVP Descriptions
This section provides individual AVP descriptions.
Session-Id AVP (263)
Uniquely identifies this session. It is a string value and is delimited by semi-colons. This AVP is created according to the Session-Id AVP (AVP Code 263) specified in IETF RFC 3588. An example of a Session-Id from the SBC is as follows, acmesystem;0;1.
Origin-Host AVP (264)
Contains the account-server configuration element’s hostname parameter followed by the "@" character, followed by the account-server configuration element’s origin-realm parameter. For example: acmesystem@wancom.com.
Origin-Realm AVP (296)
Contains the account server configuration element’s origin-realm and domain-name-suffix parameters where the server request is sent.
Destination-Realm AVP (283)
Contains the value of the Origin-Realm AVP in the CEA received from the accounting server for this connection.
Destination-Host AVP (293)
Contains the value of the Origin-Host AVP in the CEA received from the accounting server for this connection.
Accounting-Record-Type AVP (480)
Contains the value indicating the type of accounting message being sent.
- event record = 1
- start record = 2
- interim record = 3
- stop record = 4
Accounting-Record-Number AVP (485)
A value that uniquely identifies this message in the session (i.e., a sequence number for this connection). The sequence number is assigned sequentially starting with 0 as described below. This is compliant with RFC 3588. The combination of the Accounting-Record-Number AVP and the Session-Id AVP (both of which are unique for the given session) are used to match accounting records with confirmations. This is done by assigning the noted values to the records listed below:
- Event Record — the system assigns this record a value of 0 to this record.
- Start Record — the system assigns this record a value of 0 to this record.
- Interim Record — the system assigns this record a value of 1 to the first record of this type for the session, and increments the value by 1 for each subsequent Interim_record until the value for the Stop_record is more for the last Interim_record for the session.
- Stop Record — (see description for Interim_record in the previous bullet) — If there is no Interim_record for the session, the system assigns a value to this record of 1.
The following example call flow shows a Register Event that shows that the Event record in the Accounting-Record-Number AVP is always populated with 0.
Register Event Call Flow Example
The following example call flow shows session accounting messages with no Interim records. Note that the Start Accounting-Record-Number equals 0 and the Stop Accounting-Record-Number equals 1.
Call Flow Example Showing Session Accounting Messages with No Interim Records
The following example call flow shows session accounting messages with Interim records. Note that the Start record Accounting-Record-Number equals 0 and that the Interim Accounting-Record-Numbers start with a value of 1 and increase by 1 with the second Interim record. The Stop Accounting-Record-Number equals 3.
Call Flow Example Showing Session Accounting Messages with Interim Records
Acct-Application-Id AVP (259)
Set to value "3". This value indicates Diameter-based accounting messages.
User-Name AVP (1)
Contains the account-server configuration element’s hostname parameter followed by the "@" character, followed by the account-server configuration element’s origin-realm parameter. For example: acmesystem@wancom.com.
Event-Timestamp AVP (55)
Contains the number of seconds since January 1, 1900 when this accounting event took place.
Event-Type AVP (823)
A grouped AVP containing information about the signaling event. It contains the following AVPs:
- SIP-Method AVP (824)—Contains the exact string payload from the SIP request line; i.e., the Method that triggered the accounting event.
- Content-Type AVP (826)—Contains the exact string payload from the "Content-Type" SIP header of the message that triggered the accounting event.
- Content-Length AVP (827)—Contains the exact string payload from the Content-Length" SIP header of the message that triggered the accounting event.
Role-of-Node AVP (829)
Set to the value 2 which indicates that the SBC is operating in a PROXY role.
Calling-Party-Address AVP (831)
The Calling-Party-Address AVP (AVP code 831) is of type UTF8String and holds the address (SIP URI or TEL URI) which identifies the party (Public User Identity or Public Service Identity) initiating a SIP transaction. . It is obtained from the P-Asserted-Identity header of any non-REGISTER SIP Request, either initiating a dialog or a standalone transaction. This AVP may appear several times when the P-Asserted-Identity header contains both a SIP URI and a TEL URI. In case no P-Asserted-Identity is known, this AVP list shall include one item with the value "unknown".
Called-Party-Address AVP (832)
The Called-Party-Address AVP (AVP code 832) is of type UTF8String. In IMS charging (except for SIP Register and SIP Subscription transactions), it holds the address (SIP URI, TEL URI or URN) of the party (Public User ID or Public Service ID) to whom the SIP transaction is posted. The Called Party Address shall be populated with the SIP URI or TEL URI contained in the Request-URI of the outgoing request.
For a registration procedure, this field holds the party (Public User ID) to be registered. In this case, the Called Party Address field is obtained from the To SIP header of the SIP Request. For a subscription procedure this field holds the address of the resource for which the originator wants to receive notifications of change of states. In this case, the Called Party Address field is obtained from the outgoing Request-URI of the SIP Request.
Time-Stamps AVP (833)
A grouped AVP that contains timestamps for the related SIP signaling. It contains the following AVPs.
- SIP-Request-Timestamp AVP (834)—A UTC formatted timestamp that corresponds to when the SIP INVITE that started the session was received.
- SIP-Response-Timestamp AVP (835)—A UTC formatted timestamp that corresponds to when the SIP 200 OK response to the INVITE that started the session was received.
Inter-Operator-Identifier AVP (838)
A grouped AVP that indicates the ingress and egress networks from the SBC’s perspective. It contains the following AVPs.
- Originating-IOI AVP (839)—The realm where the SBC received the SIP signaling messages.
- Terminated-IOI AVP (840)—The realm where the SIP signaling message exit the SBC.
SDP-Session-Description AVP (842)
This AVP may occur multiple times in an ACR message. It is populated with SDP attribute-lines from the SIP messages to which this ACR Start or Interim message refers. Thus, all "i=", "c=", "b=", "k=", "a=", etc.., lines comprise multiple instances of this AVP.
If the SBC is configured to generate Start events on the INVITE, the calling SDP will be used; if the SBC is configured to generate Start events on the OK, the called SDP will be used. ONLY IN ACR Start.
Session-Media-Component AVP (845)
A grouped AVP that contains information about the media session. It contains the following AVPs. ONLY IN ACR Start.
- SDP-Media-Name AVP (844)—populated with the "m=" line from the SDP being used.
- SDP-Media-Description AVP (845)—this AVP may occur multiple times in this grouped AVP. It is populated with SDP attribute-lines from the media component as specified by the media described in the SDP-Media-Name AVP. Thus, all "i=", "c=", "b=", "k=", "a=", etc..., lines related to the above specified "m=" line comprise multiple instances of this AVP.
Cause AVP (860)
A grouped AVP that contains the reason for the termination event and the role/function of the node where the call was terminated. It contains the following AVPs.
- Cause-Code AVP (861)—See Values for Cause Code AVP (861) below.
- Node-Functionality AVP (862)—Set to value 0.
Reason-Header AVP (3401)
The Reason-Header AVP (3401), is a UTF8 string that contains the content of the Reason-header detected by the SBC in SIP BYE, CANCEL, and SIP error responses. It may contain multiple entries if the system detects multiple reason headers. The system includes this AVP in the ACR for Accounting-Record-Type [STOP/EVENT] when there is an active account-config running diameter, and you have enabled the add-reason-header parameter in the sip-config.
The SBC expects this AVP in an ACR message, as follows follow.
| AVP | Number | AVP Type | Reference | Start | Interim | Stop | Event |
|---|---|---|---|---|---|---|---|
| [ Reason-Header AVP ] | 3401 | UTF8 String | Base | N | N | Y | Y |
The syntax of the Reason-Header AVP is:
AVP: Reason-Header(3401) l=49 f=VM- vnd=TGPP val=Q.850;cause=16;text="Call Terminated"
AVP Code: 3401 Reason-Header
AVP Flags: 0xc0,Vendor-Specific: Set, Mandatory: Set
AVP Length: 49
AVP Vendor Id: 3GPP (10415)
Reason-Header: Q.850;cause=16;text="Call Terminated"
Padding: 000000- AVP: Reason-Header(3401) l=49 f=VM- vnd=TGPP val=Q.850;cause=16;text="Call Terminated"
- AVP Code: 3401 Reason-Header
- AVP Flags: 0xc0,
- Vendor-Specific: Set, Mandatory: Set
- AVP Length: 49
- AVP Vendor Id: 3GPP (10415)
- Reason-Header: Q.850;cause=16;text="Call Terminated"
- Padding: 000000
Values for Cause Code AVP (861)
As described in 3GPP TS32.229, the Cause-Code AVP 861 includes the cause code value sent by the IMS node. It is used in stop and/or event messages.
If the session terminated as a result of a specific known SIP error code, the SIP error code is used as the cause code value. Otherwise, cause code values less than or equal to 0 are used for successful causes while values greater than or equal to 1 are used for failure causes.
- Cause code value set to 0 — indicates "Normal end of session" and is used in Accounting-request[stop] message to indicate that an ongoing SIP session has been normally released either by the user or by the network (SIP BYE message initiated by the user or initiated by the network has been received by the IMS node after the reception of the SIP ACK message).
- Cause code value set to "2xx Final Response" (except 200) — used when the SIP transaction is terminated due to an IMS node receiving/initiating a 2xx Final response.
- Cause code value set to "2xx Final Redirection"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 3xx response.
- Cause code value set to "1"— indicates "Unspecified error" and is used when the SIP transaction is terminated due to an unknown error.
- Cause code value set to "4xx Request failure"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 4xx error response.
- Cause code value set to "5xx Server failure"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 5xx error response.
- Cause code value set to "6xx Global failure"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 6xx error response.
- Cause code value set to "Unsuccessful session setup"— used in the Accounting-request[stop] when the SIP session has not been successfully established (i.e. Timer H expires and SIP ACK is not received or SIP BYE is received after reception of the 200OK final response and SIP ACK is not received).
- Cause code value set to "Internal error"— used when the SIP transaction is terminated due to an IMS node internal error (e.g. error in processing a request/response).
STIR/SHAKEN AVPs
The SBC issues custom AVPs that capture STIR/SHAKEN information within ACRs. These are in addition to the AVPs that are common to all traffic.
This table lists STIR/SHAKEN AVPs for DIAMETER CDRs and captures the applicable CDR message types.
| AVP Name | Number | Start | Interim | Stop | Message Type = INVITE | AVP Type |
|---|---|---|---|---|---|---|
| Stir-Signed-Request | 104 | Yes
(On 200OK of invite) |
Yes | Yes | Yes | String |
| Stir-Signed-Request-Exception-Id | 105 | Yes
(On 200OK of invite) |
Yes | Yes | Yes | String |
| Stir-Verified-Request | 106 | Yes | Yes | Yes | Yes | String |
| Stir-Verified-Request-Exception-Id | 107 | Yes | Yes | Yes | Yes | String |
| Stir-VS-Verstat | 108 | Yes | Yes | Yes | Yes | UTF8String |
| Stir-VS-Reason | 109 | Yes | Yes | Yes | Yes | String |
| Stir-TN-Used-For-AS-VS-Request | 110 | Yes | Yes | Yes | Yes | String |
| Stir-Div-Signed-Request | 111 | Yes (If generate-start = OK) | Yes | Yes | Yes | String |
| Stir-Div-Verified-Request | 112 | Yes | Yes | Yes | Yes | String |
Stir-Signed-Request AVP (104)
This AVP indicates that the SBC has sent the signing request to the STI-AS and received a response. Values for this AVP mean:
- 1— The SBC has signed the INVITE.
- 0—The SBC has not signed the INVITE.
- 2—Signing is not applicable for the INVITE.
Stir-Signed-Request-Exception-Id AVP (105)
This AVP indicates that the SBC did not sign the request because of a failure request from the STI-AS. It includes the ATIS defined service or policy exception code. Potential values are in the next table.
| Exception ID | Exception Text | HTTP Status Code |
|---|---|---|
| SVC4000 | Missing request body. | 400 |
| SVC4001 | Missing mandatory parameter ‘%1’ | 400 |
| SVC4002 | Requested response body type ‘%1’is not supported | 406 |
| SVC4003 | Requested resource was not found | 404 |
| SVC4004 | Unsupported request body type, expected ‘%1’ | 415 |
| SVC4005 | Invalid ‘%1’ parameter value: %2 | 400 |
| SVC4006 | Failed to parse received message body: %1 | 400 |
| SVC4007 | Missing mandatory Content-Length header 411 | 411 |
| POL4050 | Method not allowed | 405 |
| POL5000 | Internal Server Error. Please try again later | 500 |
Stir-Verified-Request AVP (106)
This AVP indicates that the SBC has sent the verification request to the STI-VS and received a response. Values for this AVP mean:
- 1— The SBC has verified the request.
- 0—The SBC has not signed verified the request.
- 2—Request verification is not applicable for the call.
Stir-Verified-Request-Exception-Id AVP (107)
This AVP indicates that the SBC did not verify the request because of a failure request from the STI-VS. It includes the ATIS defined service or policy exception code. Potential values are in the next table.
| Exception ID | Exception Text | HTTP Status Code |
|---|---|---|
| SVC4000 | Missing request body | 400 |
| SVC4001 | Missing mandatory parameter ‘%1’ | 400 |
| SVC4002 | Requested response body type ‘%1’is not supported | 406 |
| SVC4003 | Requested resource was not found | 404 |
| SVC4004 | Unsupported request body type, expected ‘%1’ | 415 |
| SVC4005 | Invalid ‘%1’ parameter value: %2 | 400 |
| SVC4006 | Failed to parse received message body: %1 | 400 |
| SVC4007 | Missing mandatory Content-Length header 411 | 411 |
| POL4050 | Method not allowed | 405 |
| POL5000 | Internal Server Error. Please try again later | 500 |
Stir-VS-Verstat (108)
The SBC populates the Stir-VS-Verstat RADIUS attribute with the verstat values the SBC includes in the SIP INVITE following the Stir Shaken trigger with the values include TN-Validation-Passed, TN-Validation-Failed or No-TN-Validation in the cases below. DIV verification apply to 3GPP mode only.
The SBC includes a verstat in the INVITE and CDR:
- For SHAKEN verifications, when the SBC receives a verstat value parameter in the HTTP response from STI-VS server.
- For DIV verifications, when the SBC receives multiple verstat value parameters in a single HTTP response from the STI-VS server, and a specified final verstat value.
- For both DIV and SHAKEN verifications, when the SBC does not send a VS request to the STI-VS server, it adds the No-TN-Validation verstat to the egress INVITE. This may happen, for example, when the ingress INVITE doesn’t have the Identity header.
- For both DIV and SHAKEN verifications, when the SBC does not receive any response from the STI-VS server, it adds the No-TN-Validation verstat to the egress INVITE. An example of this is a timeout.
- The SBC populates Stir-VS-Verstat with an
empty string in the following cases:
- For all authentication scenarios
- If there is a timeout
- If the system does not send a request to the STI-VS because there is an existing Identity header
- For verification scenarios wherein the system receives a 4xx/5xx response from the STI-VS because the verstat and reason fields are not included in the json response
- If the STI-VS response does not have a Verstat Value
- For ATIS deployments, if the STI-VS response has empty reasoncode and reasontext fields
Enable the account-config, cdr-output-inclusive parameter to include the empty strings for the scenarios above. If disabled, the system does not include the AVP in the CDR file.
Stir-VS-Reason (109)
From a high level, this AVP reflects what the SBC includes in the SIP egress INVITE following the Stir Shaken trigger. The SBC populates the Stir-VS-Reason attribute with received reason information in the cases below, based on operating mode.
- When operating in ATIS mode, if you have enabled the reason-json-sip-translation feature and the system receives the reasoncode and reasontext parameters in the HTTP response
- When operating in 3GPP mode, if you have enabled the reason-json-sip-translation feature and the system receives an error response, either 4xx or 5xx, from the STI-VS, the SBC uses the HTTP error code and reason phrase (if available) to populate a reason header in the egress INVITE
- When the reason-json-sip-translation feature is disabled
- For all authentication scenarios, regardless of whether the feature is enabled or disabled
- If there is a timeout
- If the system does not send a request to the STI-VS because there is an existing Identity header
- For both DIV and SHAKEN verifications, when the feature is enabled and the
system receives a 4xx or a 5xx verification response because the verstat and
reason fields are not included in the json response
Note:
This is only true for ATIS 3GPP deployments.
Enable the account-config, cdr-output-inclusive parameter to include the empty strings for the scenarios above. If it’s disabled, the system does not include the AVP in the CDR file.
Stir-TN-Used-For-AS-VS-Request (110)
This AVP contains the TN number captured by the SBC. The TN to be used in the CDRs uses the following priority order:
- From the Tel PAI (if present)
- From the SIP PAI (if present, and Tel PAI is not present)
- From the “From” header if both Tel and SIP PAI are not present.
Stir-Div-Signed-Request (111)
Upon sending the div signing request to the STI-AS and receiving a 200 OK successful response from STIR-AS, the SBC enumerates the results as follows:
- “1” for div signing the INVITE
- “0” for not div signing the INVITE
- “2” when div signing is not applicable on the INVITE
Stir-Div-Verified-Request (112)
Upon sending the div verify request to the STI-AS and receiving a 200 OK successful response from STIR-VS, the SBC enumerates the results as follows:
- “1” for div verification of the INVITE
- “0” for no div verification of the INVITE
- “2” when div verification is not applicable on the INVITE
Stir-VS-Invite-State (118)
The SBC populates this attribute only if the attribute has a valid value extracted from the signaling, such as Stir-VS-Invite-State: “Terminated”.
If there is no value extracted for this attribute, the SBC leaves this field empty.
When collecting traffic for server configured as an STI-VS, the SBC populates this field with “Terminated” for rejecting the INVITE due to call rejection, and with “Continued” for when the SBC does not reject the INVITE. When collecting for an STI-AS, the SBC leaves this field empty.