RFC 8506
Diameter Credit-Control Application
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
(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.
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
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.
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 ]
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 ]
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.
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.
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.
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 58.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.
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.
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.
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 }
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.
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.
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.
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)
