Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8506

Diameter Credit-Control Application

Pages: 130
Proposed Standard
Obsoletes:  4006
Part 6 of 9 – Pages 66 to 82
First   Prev   Next

Top   ToC   RFC8506 - Page 66   prevText

8.10. Value-Digits AVP

The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains the significant digits of the number. If decimal values are needed to present the units, the scaling MUST be indicated with the related Exponent AVP. For example, for the monetary amount $0.05, the value of the Value-Digits AVP MUST be set to 5, and the scaling MUST be indicated with the Exponent AVP set to -2.

8.11. Currency-Code AVP

The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and contains a currency code that specifies in which currency the values of AVPs containing monetary units were given. It is specified by using the numeric values defined in the ISO 4217 standard [ISO4217].

8.12. Cost-Unit AVP

The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is used to display a human-readable string to the end user. It specifies the applicable unit to the Cost-Information AVP when the service cost is a cost per unit (e.g., cost of the service is $1 per minute). The Cost-Unit setting can be minutes, hours, days, kilobytes, megabytes, etc.

8.13. Credit-Control AVP

The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST be included in AA-Request messages when the Service Element has credit-control capabilities. The following values are defined for the Credit-Control AVP: CREDIT_AUTHORIZATION 0 If the home Diameter AAA server determines that the user has a prepaid subscription, this value indicates that the credit-control server MUST be contacted to perform the first interrogation. The value of the Credit-Control AVP MUST always be set to 0 in an AA-Request sent to perform the first interrogation and to initiate a new credit-control session. RE_AUTHORIZATION 1 This value indicates to the Diameter AAA server that a credit-control session is ongoing for the subscriber and that the credit-control server MUST NOT be contacted. The Credit-Control AVP set to the value of 1 is to be used only when the first interrogation has been successfully performed and the credit-control session is ongoing
Top   ToC   RFC8506 - Page 67
   (i.e., re-authorization triggered by authorization lifetime).  This
   value MUST NOT be used in an AA-Request sent to perform the first
   interrogation.

8.14. Credit-Control-Failure-Handling AVP (CCFH)

The CCFH (AVP Code 427) is of type Enumerated. The credit-control client uses information in this AVP to decide what to do if sending credit-control messages to the credit-control server has been, for instance, temporarily prevented due to a network problem. Depending on the service logic, the credit-control server can order the client to terminate the service immediately when there is a reason to believe that the service cannot be charged, or to try failover to an alternative server, if possible. The server could then either terminate or grant the service, should the alternative connection also fail. The following values are defined for the CCFH: TERMINATE 0 When the CCFH is set to TERMINATE, the service MUST only be granted for as long as there is a connection to the credit-control server. If the credit-control client does not receive any Credit-Control- Answer messages before the Tx timer (as defined in Section 13) expires, the credit-control request is regarded as failed, and the end user's service session is terminated. This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server. CONTINUE 1 When the CCFH is set to CONTINUE, the credit-control client SHOULD resend the request to an alternative server in the case of transport or temporary failures, provided that (1) a failover procedure is supported in the credit-control server and the credit-control client and (2) an alternative server is available. Otherwise, the service SHOULD be granted, even if credit-control messages can't be delivered. RETRY_AND_TERMINATE 2 When the CCFH is set to RETRY_AND_TERMINATE, the credit-control client SHOULD resend the request to an alternative server in the case of transport or temporary failures, provided that (1) a failover procedure is supported in the credit-control server and the credit-control client and (2) an alternative server is available.
Top   ToC   RFC8506 - Page 68
   Otherwise, the service SHOULD NOT be granted when the credit-control
   messages can't be delivered.

8.15. Direct-Debiting-Failure-Handling AVP (DDFH)

The DDFH (AVP Code 428) is of type Enumerated. The credit-control client uses information in this AVP to decide what to do if sending credit-control messages (Requested-Action AVP set to DIRECT_DEBITING) to the credit-control server has been, for instance, temporarily prevented due to a network problem. The following values are defined for the DDFH: TERMINATE_OR_BUFFER 0 When the DDFH is set to TERMINATE_OR_BUFFER, the service MUST be granted for as long as there is a connection to the credit-control server. If the credit-control client does not receive any Credit-Control-Answer messages before the Tx timer (as defined in Section 13) expires, the credit-control request is regarded as failed. The client SHOULD terminate the service if it can determine from the failed answer that units have not been debited. Otherwise, the credit-control client SHOULD grant the service, store the request in application-level non-volatile storage, and try to resend the request. These requests MUST be marked as possible duplicates by setting the T flag in the command header as described in [RFC6733], Section 3. This is the default behavior if the AVP isn't included in the reply from the authorization server. CONTINUE 1 When the DDFH is set to CONTINUE, the service SHOULD be granted, even if credit-control messages can't be delivered, and the request should be deleted.

8.16. Multiple-Services-Credit-Control AVP

The Multiple-Services-Credit-Control AVP (AVP Code 456) is of type Grouped and contains the AVPs related to the independent credit-control of multiple services. Note that each instance of this AVP carries units related to one or more services or related to a single rating-group. The Service-Identifier AVP and the Rating-Group AVP are used to associate the granted units to a given service or rating-group. If both the Service-Identifier AVP and the Rating-Group AVP are included, the target of the service units is always the service(s) indicated by the value of the Service-Identifier AVP(s). If only the
Top   ToC   RFC8506 - Page 69
   Rating-Group AVP is present, the Multiple-Services-Credit-Control AVP
   relates to all the services that belong to the specified
   rating-group.

   The G-S-U-Pool-Reference AVP allows the server to specify a
   G-S-U-Pool-Identifier identifying a credit pool within which the
   units of the specified type are considered pooled.  If a G-S-U-Pool-
   Reference AVP is present, then actual service units of the specified
   type MUST also be present.  For example, if the G-S-U-Pool-Reference
   AVP specifies a CC-Unit-Type value of TIME (Section 8.32), then the
   CC-Time AVP MUST be present.

   The Requested-Service-Unit AVP MAY contain the amount of requested
   service units or the requested monetary value.  It MUST be present in
   the initial interrogation and within the intermediate interrogations
   in which a new quota is requested.  If the credit-control client does
   not include the Requested-Service-Unit AVP in a request command --
   because, for instance, it has determined that the end user terminated
   the service -- the server MUST debit the used amount from the user's
   account but MUST NOT return a new quota in the corresponding answer.
   The Validity-Time, Result-Code, and Final-Unit-Indication or
   QoS-Final-Unit-Indication AVPs MAY be present in a Credit-Control-
   Answer command as defined in Sections 5.1.2 and 5.6 for graceful
   service termination.

   When both the Tariff-Time-Change AVP and the Tariff-Change-Usage AVP
   are present, the server MUST include two separate instances of the
   Multiple-Services-Credit-Control AVP with the Granted-Service-Unit
   AVP associated to the same service-identifier and/or rating-group.
   Where the two quotas are associated to the same pool or to different
   pools, the credit-pooling mechanism defined in Section 5.1.2 applies.
   When the client is reporting used units before and after the tariff
   time change, it MUST use the Tariff-Change-Usage AVP inside the
   Used-Service-Unit AVP.

   A server not implementing the independent credit-control of multiple
   services MUST treat the Multiple-Services-Credit-Control AVP as an
   invalid AVP.
Top   ToC   RFC8506 - Page 70
   The Multiple-Services-Credit-Control AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

    Multiple-Services-Credit-Control ::= < AVP Header: 456 >
                                         [ Granted-Service-Unit ]
                                         [ Requested-Service-Unit ]
                                        *[ Used-Service-Unit ]
                                         [ Tariff-Change-Usage ]
                                        *[ Service-Identifier ]
                                         [ Rating-Group ]
                                        *[ G-S-U-Pool-Reference ]
                                         [ Validity-Time ]
                                         [ Result-Code ]
                                         [ Final-Unit-Indication ]
                                         [ QoS-Final-Unit-Indication ]
                                        *[ AVP ]

8.17. Granted-Service-Unit AVP

The Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and contains the amount of units that the Diameter Credit-Control client can provide to the end user until the service must be released or the new Credit-Control-Request must be sent. A client is not required to implement all the unit types, and it must treat unknown or unsupported unit types in the Answer message as an incorrect CCA. In this case, the client MUST terminate the credit-control session and indicate the reason as DIAMETER_BAD_ANSWER in the Termination-Cause AVP. The Granted-Service-Unit AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]): Granted-Service-Unit ::= < AVP Header: 431 > [ Tariff-Time-Change ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ AVP ]
Top   ToC   RFC8506 - Page 71

8.18. Requested-Service-Unit AVP

The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and contains the amount of requested units specified by the Diameter Credit-Control client. A server is not required to implement all the unit types, and it must treat unknown or unsupported unit types as invalid AVPs. The Requested-Service-Unit AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]): Requested-Service-Unit ::= < AVP Header: 437 > [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ AVP ]

8.19. Used-Service-Unit AVP

The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and contains the amount of used units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. Note: The value reported in a Used-Service-Unit AVP is not necessarily related to the grant provided in a Granted-Service-Unit AVP, e.g., the value in this AVP may exceed the value in the grant. The Used-Service-Unit AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]): Used-Service-Unit ::= < AVP Header: 446 > [ Tariff-Change-Usage ] [ CC-Time ] [ CC-Money ] [ CC-Total-Octets ] [ CC-Input-Octets ] [ CC-Output-Octets ] [ CC-Service-Specific-Units ] *[ AVP ]
Top   ToC   RFC8506 - Page 72

8.20. Tariff-Time-Change AVP

The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is sent from the server to the client and includes the time in seconds since January 1, 1900, 00:00 UTC, when the tariff of the service will be changed. The tariff change mechanism is optional for the client and server, and it is not used for time-based services (Section 5). If a client does not support the tariff time change mechanism, it MUST treat the Tariff-Time-Change AVP in the Answer message as an incorrect CCA. In this case, the client terminates the credit-control session and indicates the reason as DIAMETER_BAD_ANSWER in the Termination-Cause AVP. Omission of this AVP means that no tariff change is to be reported.

8.21. CC-Time AVP

The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates the length of the requested, granted, or used time in seconds.

8.22. CC-Money AVP

The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the monetary amount in the given currency. The Currency-Code AVP SHOULD be included. The CC-Money AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]): CC-Money ::= < AVP Header: 413 > { Unit-Value } [ Currency-Code ]

8.23. CC-Total-Octets AVP

The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and contains the total number of requested, granted, or used octets regardless of the direction (sent or received).

8.24. CC-Input-Octets AVP

The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and contains the number of requested, granted, or used octets that can be / have been received from the end user.
Top   ToC   RFC8506 - Page 73

8.25. CC-Output-Octets AVP

The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and contains the number of requested, granted, or used octets that can be / have been sent to the end user.

8.26. CC-Service-Specific-Units AVP

The CC-Service-Specific-Units AVP (AVP Code 417) is of type Unsigned64 and specifies the number of service-specific units (e.g., number of events, points) given in a selected service. The service- specific units always refer to the service identified in the Service- Identifier AVP (or Rating-Group AVP when the Multiple-Services- Credit-Control AVP is used).

8.27. Tariff-Change-Usage AVP

The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and defines whether units are used before or after a tariff change, or whether the units straddled a tariff change during the reporting period. Omission of this AVP means that no tariff change has occurred. In addition, when present in Answer messages as part of the Multiple- Services-Credit-Control AVP, this AVP defines whether units are allocated to be used before or after a tariff change event. When the Tariff-Time-Change AVP is present, omission of this AVP in Answer messages means that the single-quota mechanism applies. Tariff-Change-Usage can be set to one of the following values: UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of units allocated for use before a tariff change occurs. When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used before a tariff change had occurred.
Top   ToC   RFC8506 - Page 74
   UNIT_AFTER_TARIFF_CHANGE    1

   When present in the Multiple-Services-Credit-Control AVP, this value
   indicates the amount of units allocated for use after a tariff change
   occurs.

   When present in the Used-Service-Unit AVP, this value indicates the
   amount of resource units used after a tariff change had occurred.

   UNIT_INDETERMINATE          2

   This value is to be used only in the Used-Service-Unit AVP and
   indicates the amount of resource units that straddle the tariff
   change (e.g., the metering process reports to the credit-control
   client in blocks of n octets, and one block straddled the tariff
   change).

8.28. Service-Identifier AVP

The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and contains the identifier of a service. The specific service the request relates to is uniquely identified by the combination of the Service-Context-Id AVP and the Service-Identifier AVP. A usage example of this AVP is illustrated in Appendix A.9.

8.29. Rating-Group AVP

The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and contains the identifier of a rating-group. All the services subject to the same rating type are part of the same rating-group. The specific rating-group the request relates to is uniquely identified by the combination of the Service-Context-Id AVP and the Rating-Group AVP. A usage example of this AVP is illustrated in Appendix A.9.

8.30. G-S-U-Pool-Reference AVP

The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It is used in the Credit-Control-Answer message and associates the Granted-Service-Unit AVP within which it appears with a credit pool within the session. The G-S-U-Pool-Identifier AVP specifies the credit pool from which credit is drawn for this unit type.
Top   ToC   RFC8506 - Page 75
   The CC-Unit-Type AVP specifies the type of units for which credit is
   pooled.

   The Unit-Value AVP specifies the multiplier, which converts between
   service units of type CC-Unit-Type and abstract service units within
   the credit pool (and thus to service units of any other services or
   rating-groups associated with the same pool).

   The G-S-U-Pool-Reference AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

           G-S-U-Pool-Reference ::= < AVP Header: 457 >
                                    { G-S-U-Pool-Identifier }
                                    { CC-Unit-Type }
                                    { Unit-Value }

8.31. G-S-U-Pool-Identifier AVP

The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 and identifies a credit pool within the session.

8.32. CC-Unit-Type AVP

The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and specifies the type of units considered to be pooled into a credit pool. The following values are defined for the CC-Unit-Type AVP: TIME 0 MONEY 1 TOTAL-OCTETS 2 INPUT-OCTETS 3 OUTPUT-OCTETS 4 SERVICE-SPECIFIC-UNITS 5

8.33. Validity-Time AVP

The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is sent from the credit-control server to the credit-control client. The Validity-Time AVP contains the validity time of the granted service units. The measurement of the Validity-Time is started upon receipt of the Credit-Control-Answer message containing this AVP. If the granted service units have not been consumed within the validity time specified in this AVP, the credit-control client MUST send a Credit-Control-Request message to the server, with CC-Request-Type set to UPDATE_REQUEST. The value field of the Validity-Time AVP is given in seconds.
Top   ToC   RFC8506 - Page 76
   The Validity-Time AVP is also used for graceful service termination
   (see Section 5.6) to indicate to the credit-control client how long
   the subscriber is allowed to use network resources after the
   specified action (i.e., REDIRECT or RESTRICT_ACCESS) started.  When
   the Validity-Time elapses, a new intermediate interrogation is sent
   to the server.

8.34. Final-Unit-Indication AVP

The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and indicates that the Granted-Service-Unit AVP in the Credit-Control- Answer or in the AA-Answer contains the final units for the service. After these units have expired, the Diameter Credit-Control client is responsible for executing the action indicated in the Final-Unit- Action AVP (see Section 5.6). If more than one unit type is received in the Credit-Control-Answer, the unit type that first expired SHOULD cause the credit-control client to execute the specified action. In the first interrogation, the Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS can also be present with no Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA-Answer. This indicates to the Diameter Credit-Control client that the client is to execute the specified action immediately. If the home service provider policy is to terminate the service, naturally, the server SHOULD return the appropriate transient failure (see Section 9.1) in order to implement the policy- defined action. The Final-Unit-Action AVP defines the behavior of the Service Element when the user's account cannot cover the cost of the service and MUST always be present if the Final-Unit-Indication AVP is included in a command. If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit- Indication group AVP MUST NOT contain any other AVPs. If the Final-Unit-Action AVP is set to REDIRECT, the Redirect-Server AVP or the Redirect-Server-Extension AVP (at least one) MUST be present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is also allowed to access other services that are not accessible through the address given in the Redirect-Server AVP. If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
Top   ToC   RFC8506 - Page 77
   The Filter-Id AVP is defined in [RFC7155].  The Filter-Id AVP can be
   used to reference an IP filter list installed in the access device by
   means other than the Diameter Credit-Control application, e.g.,
   locally configured or configured by another entity.

   If the Final-Unit-Action AVP is set to REDIRECT and the type of
   server is not one of the enumerations in the Redirect-Address-Type
   AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together
   with the Redirect-Server-Extension AVP instead of the Final-Unit-
   Indication AVP.

   If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
   and the classification of the restricted traffic cannot be expressed
   using an IPFilterRule, or if actions (e.g., QoS) other than just
   allowing traffic need to be enforced, then the QoS-Final-Unit-
   Indication AVP SHOULD be used instead of the Final-Unit-Indication
   AVP.  However, if the credit-control server wants to preserve
   backward compatibility with credit-control clients that support only
   [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with
   the Filter-Id AVP.

   The Final-Unit-Indication AVP is defined as follows (per
   grouped-avp-def as defined in [RFC6733]):

         Final-Unit-Indication ::= < AVP Header: 430 >
                                   { Final-Unit-Action }
                                  *[ Restriction-Filter-Rule ]
                                  *[ Filter-Id ]
                                   [ Redirect-Server ]

8.35. Final-Unit-Action AVP

The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and indicates to the credit-control client the action to be taken when the user's account cannot cover the service cost. Final-Unit-Action can be set to one of the following values: TERMINATE 0 The credit-control client MUST terminate the service session. This is the default handling, applicable whenever the credit-control client receives an unsupported Final-Unit-Action value, and it MUST be supported by all the Diameter Credit-Control client implementations conforming to this specification.
Top   ToC   RFC8506 - Page 78
   REDIRECT          1

   The Service Element MUST redirect the user to the address specified
   in the Redirect-Server-Address AVP or one of the AVPs included in the
   Redirect-Server-Extension AVP.  The redirect action is defined in
   Section 5.6.2.

   RESTRICT_ACCESS   2

   The access device MUST restrict the user's access according to the
   filter AVPs contained in the applied Grouped AVP: according to IP
   packet filters defined in the Restriction-Filter-Rule AVP, according
   to the packet classifier filters defined in the Filter-Rule AVP, or
   according to the packet filters identified by the Filter-Id AVP.  All
   of the packets not matching any restriction filters (see
   Section 5.6.3) MUST be dropped.

8.36. Restriction-Filter-Rule AVP

The Restriction-Filter-Rule AVP (AVP Code 438) is of type IPFilterRule and provides filter rules corresponding to services that are to remain accessible even if there are no more service units granted. The access device has to configure the specified filter rules for the subscriber and MUST drop all the packets not matching these filters. Zero, one, or more such AVPs MAY be present in a Credit-Control-Answer message or in an AA-Answer message.

8.37. Redirect-Server AVP

The Redirect-Server AVP (AVP Code 434) is of type Grouped and contains the address information of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end user is to be connected when the account cannot cover the service cost. It MUST be present when the Final-Unit-Action AVP is set to REDIRECT. The Redirect-Server AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]): Redirect-Server ::= < AVP Header: 434 > { Redirect-Address-Type } { Redirect-Server-Address }
Top   ToC   RFC8506 - Page 79

8.38. Redirect-Address-Type AVP

The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated and defines the address type of the address given in the Redirect- Server-Address AVP. Redirect-Address-Type can be set to one of the following values: IPv4 Address 0 The address type is in the form of a "dotted-decimal" IPv4 address, as defined in [RFC791]. IPv6 Address 1 The address type is in the form of an IPv6 address, as defined in [RFC4291]. The address MUST conform to the textual representation of the address according to [RFC5952]. Because [RFC5952] is more restrictive than the "RFC 3513" format required by [RFC4006], some legacy implementations may not be compliant with the new requirements. Accordingly, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted, without raising an error. URL 2 The address type is in the form of a Uniform Resource Locator, as defined in [RFC3986]. SIP URI 3 The address type is in the form of a SIP Uniform Resource Identifier, as defined in [RFC3261].

8.39. Redirect-Server-Address AVP

The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String and defines the address of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end user is to be connected when the account cannot cover the service cost.
Top   ToC   RFC8506 - Page 80

8.40. Multiple-Services-Indicator AVP

The Multiple-Services-Indicator AVP (AVP Code 455) is of type Enumerated and indicates whether the Diameter Credit-Control client is capable of handling multiple services independently within a (sub-)session. The absence of this AVP means that independent credit-control of multiple services is not supported. A server not implementing the independent credit-control of multiple services MUST treat the Multiple-Services-Indicator AVP as an invalid AVP. The following values are defined for the Multiple-Services-Indicator AVP: MULTIPLE_SERVICES_NOT_SUPPORTED 0 The client does not support independent credit-control of multiple services within a (sub-)session. MULTIPLE_SERVICES_SUPPORTED 1 The client supports independent credit-control of multiple services within a (sub-)session.

8.41. Requested-Action AVP

The Requested-Action AVP (AVP Code 436) is of type Enumerated and contains the requested action being sent in a Credit-Control-Request command where the CC-Request-Type is set to EVENT_REQUEST. The following values are defined for the Requested-Action AVP: DIRECT_DEBITING 0 This indicates a request to decrease the end user's account according to information specified in the Requested-Service-Unit AVP and/or Service-Identifier AVP (additional rating information may be included in service-specific AVPs or in the Service-Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-Control-Answer command contains the debited units.
Top   ToC   RFC8506 - Page 81
   REFUND_ACCOUNT    1

   This indicates a request to increase the end user's account according
   to information specified in the Requested-Service-Unit AVP and/or
   Service-Identifier AVP (additional rating information may be included
   in service-specific AVPs or in the Service-Parameter-Info AVP).  The
   Granted-Service-Unit AVP in the Credit-Control-Answer command
   contains the refunded units.

   CHECK_BALANCE     2

   This indicates a balance-check request.  In this case, the checking
   of the account balance is done without any credit reservations from
   the account.  The Check-Balance-Result AVP in the Credit-Control-
   Answer command contains the result of the balance check.

   PRICE_ENQUIRY     3

   This indicates a price-inquiry request.  In this case, neither
   checking of the account balance nor reservation from the account will
   be done; only the price of the service will be returned in the
   Cost-Information AVP in the Credit-Control-Answer command.

8.42. Service-Context-Id AVP

The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and contains a unique identifier of the Diameter Credit-Control service- specific document (as defined in Section 4.1.2) that applies to the request. This is an identifier allocated by the service provider, the Service Element manufacturer, or a standardization body, and MUST uniquely identify a given Diameter Credit-Control service-specific document. The format of the Service-Context-Id is: "service-context" "@" "domain" service-context = Token The Token is an arbitrary string of characters and digits. "domain" represents the entity that allocated the Service-Context-Id. It can be ietf.org, 3gpp.org, etc. if the identifier is allocated by a standardization body, or it can be the Fully Qualified Domain Name (FQDN) of the service provider (e.g., provider.example.com) or the vendor (e.g., vendor.example.com) if the identifier is allocated by a private entity. This AVP SHOULD be placed as close to the Diameter header as possible.
Top   ToC   RFC8506 - Page 82
   Service-specific documents that are for private use only (i.e., for
   one provider's own use, where no interoperability is deemed useful)
   may define private identifiers without a need for coordination.
   However, when interoperability is desired, coordination of the
   identifiers via, for example, publication of an informational RFC is
   RECOMMENDED in order to make the Service-Context-Id AVP globally
   available.

8.43. Service-Parameter-Info AVP

The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and contains service-specific information used for price calculation or rating. The Service-Parameter-Type AVP defines the service parameter type, and the Service-Parameter-Value AVP contains the parameter value. The actual contents of these AVPs are not within the scope of this document and SHOULD be defined in another Diameter application, in standards written by other standardization bodies, or in service- specific documentation. In the case of an unknown service request (e.g., unknown Service- Parameter-Type), the corresponding Answer message MUST contain the error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message with this error MUST contain one or more Failed-AVP AVPs containing the Service-Parameter-Info AVPs that caused the failure. The Service-Parameter-Info AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]): Service-Parameter-Info ::= < AVP Header: 440 > { Service-Parameter-Type } { Service-Parameter-Value }

8.44. Service-Parameter-Type AVP

The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) and defines the type of the service-event-specific parameter (e.g., it can be the end-user location or service name). The different parameters and their types are service specific, and the meanings of these parameters are not defined in this document. Whoever allocates the Service-Context-Id (i.e., a unique identifier of a service- specific document) is also responsible for assigning Service- Parameter-Type values for the service and ensuring their uniqueness within the given service. The Service-Parameter-Value AVP contains the value associated with the service parameter type.


(next page on part 7)

Next Section