RFC 8506
Diameter Credit-Control Application
5.6. Graceful Service Termination
When the user's account runs out of money, the user may not be allowed to compile additional chargeable events. However, the home service provider may offer some services -- for instance, access to a service portal where it is possible to refill the account -- from which the user is allowed to benefit for a limited time. The length of this time is usually dependent on the home service provider policy. This section defines the optional graceful service termination feature. This feature MAY be supported by the credit-control server. Credit-control client implementations MUST support the Final-Unit- Indication AVP or QoS-Final-Unit-Indication AVP with at least the teardown of the ongoing service session once the subscriber has consumed all the final granted units.
Where independent credit-control of multiple services in a single credit-control (sub-)session is supported, it is possible to use graceful service termination for each of the services/rating-groups independently. Naturally, the graceful service termination process defined in the following subsections will apply to the specific service/rating-group as requested by the server. In some service environments (e.g., NAS), graceful service termination may be used to redirect the subscriber to a service portal for online balance refill or other services offered by the home service provider. In this case, the graceful service termination process installs a set of packet filters to restrict the user's access capability only to/from the specified destinations. All the IP packets not matching the filters will be dropped or, possibly, redirected to the service portal. The user may also be sent an appropriate notification as to why the access has been limited. These actions may be communicated explicitly from the server to the client or may be configured "per service" at the client. Explicitly signaled redirection or restriction instructions always take precedence over configured ones. It is also possible to use graceful service termination to connect the prepaid user to a top-up server that plays an announcement and prompts the user to replenish the account. In this case, the credit-control server sends only the address of the top-up server where the prepaid user shall be connected after the final granted units have been consumed. An example of this case is given in Appendix A.7. The credit-control server MAY initiate graceful service termination by including the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP in the Credit-Control-Answer to indicate that the message contains the final units for the service. When the credit-control client receives the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP in the answer from the server, its behavior depends on the value indicated in the Final-Unit-Action AVP. The server may request the following actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS. Figure 6 illustrates the graceful service termination procedure described in the following subsections.
Diameter End User Service Element AAA Server CC Server (CC Client) | Service Delivery | | | |<----------------->| | | | |CCR(Update, Used-Units) | | |-------------------->|CCR(Update, Used-Units) | : | |-------------------->| | : | |CCA(Final-Unit, Action) | : | |<--------------------| | |CCA(Final-Unit, Action) | | |<--------------------| | | | | | | : | | | | : | | | | /////////////// |CCR(Update, Used-Units) | |/Final Units End/->|-------------------->|CCR(Update, Used-Units) |/Action and // | |-------------------->| |/Restrictions // | | CCA(Validity-Time)| |/Start // | CCA(Validity-Time)|<--------------------| | ///////////// |<--------------------| | | : | | | | : | | | | Replenish account | +-------+ | |<--------------------------------------------->|Account| | | | | +-------+ | | | | RAR | | + | RAR |<====================| | | |<====================| | | | | RAA | | | ///////////// | |====================>| RAA | | /If supported / | | CCR(Update) |====================>| | /by CC Server/ | |====================>| CCR(Update) | | ///////////// | | |====================>| | | | | CCA(Granted-Units)| | | | CCA(Granted-Units)|<====================| | Restrictions ->+ |<====================| | | removed | | | | : | | | | OR | CCR(Update) | | | Validity-Time ->|-------------------->| CCR(Update) | | expires | |-------------------->| | | | CCA(Granted-Units)| | | CCA(Granted-Units)|<--------------------| | Restrictions ->|<--------------------| | | removed | | | Figure 6: Optional Graceful Service Termination Procedure
In addition, the credit-control server MAY reply with the Final-Unit- Indication AVP or QoS-Final-Unit-Indication AVP holding a Granted- Service-Unit (G-S-U) with a zero grant, indicating that the service SHOULD be terminated immediately, and no further reporting is required. Figure 7 illustrates a graceful service termination procedure that applies immediately after receiving a zero grant. Diameter End User Service Element AAA Server CC Server (CC Client) | Service Delivery | | | |<----------------->| | | | |CCR(Update, Used-Units) | | |--------------------->|CCR(Update, Used-Units) | : | |-------------------->| | : | |CCA(Final-Unit, Action, | : | | Zero G-S-U) | : | |<--------------------| | |CCA(Final-Unit, Action, | | | Zero G-S-U) | | |<---------------------| | | /////////////// | | | |/Action and // | | | |/Restrictions // | | | |/Start // | | | | ///////////// | | | | : | | | | : | | | Figure 7: Optional Immediate Graceful Service Termination Procedure5.6.1. Terminate Action
The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP with Final-Unit-Action set to TERMINATE does not include any other information. When the subscriber has consumed the final granted units, the Service Element MUST terminate the service. This is the default handling applicable whenever the credit-control client receives an unsupported Final-Unit-Action value and MUST be supported by all the Diameter Credit-Control client implementations conforming to this specification. A final Credit-Control-Request message to the credit-control server MUST be sent if the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was present at the command level. The CC-Request-Type AVP in the request is set to the value TERMINATION_REQUEST.
5.6.2. Redirect Action
The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT indicates to the Service Element supporting this action that, upon consumption of the final granted units, the user MUST be redirected to the address specified in the Redirect-Server AVP or Redirect-Server-Extension AVP as follows. The credit-control server sends the Redirect-Server AVP or Redirect- Server-Extension AVP in the Credit-Control-Answer message. In such a case, the Service Element MUST redirect or connect the user to the destination specified in the Redirect-Server AVP or Redirect-Server- Extension AVP, if possible. When the end user is redirected (by using protocols other than Diameter) to the specified server or connected to the top-up server, an additional authorization (and possibly authentication) may be needed before the subscriber can replenish the account; however, this scenario is out of scope for this specification. In addition to the Redirect-Server AVP or Redirect-Server-Extension AVP, the credit-control server MAY include one or more Restriction- Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more Filter-Id AVPs in the Credit-Control-Answer message to enable the user to access other services (for example, zero-rated services). In such a case, the access device MUST treat all packets according to the Restriction-Filter-Rule AVPs, Filter-Rule AVPs, and the rules referred to by the Filter-Id AVP. After treatment is applied according to these rules, all traffic that has not been dropped or already forwarded MUST be redirected to the destination specified in the Redirect-Server AVP or Redirect-Server-Extension AVP. An entity other than the credit-control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter Credit-Control application. This case is considered in Section 5.6.3. When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The purpose of this interrogation is to indicate to the credit-control server that the specified action started and to report the used units. The credit-control server MUST deduct the used amount from the end user's account but MUST NOT make a new credit reservation. The credit-control client, however, may send intermediate interrogations before all the final granted units have been consumed for which rating and money reservation may be needed -- for instance, upon Validity-Time expiration or upon mid-session service events that affect the rating of the current service. Therefore, the
credit-control client MUST NOT include any rating-related AVPs in the request sent once all the final granted units have been consumed, as an indication to the server that (1) the requested final unit action started and (2) rating and money reservation are not required (when the Multiple-Services-Credit-Control AVP is used, the Service- Identifier AVP or the Rating-Group AVP is included to indicate the services concerned). Naturally, the Credit-Control-Answer message does not contain any granted service units and MUST include the Validity-Time AVP to indicate to the credit-control client how long the subscriber is allowed to use network resources before a new intermediate interrogation is sent to the server. At the expiry of Validity-Time, the credit-control client sends a Credit-Control-Request (UPDATE_REQUEST) as usual. This message does not include the Used-Service-Unit AVP, as there is no allotted quota to report. The credit-control server processes the request and MUST perform the credit reservation. If during this time the subscriber did not replenish their account, whether they will be disconnected or will be granted access to services not controlled by a credit-control server for an unlimited time is dependent on the home service provider policy. (Note: The latter option implies that the Service Element should not remove the restriction filters upon termination of the credit-control.) The server will return the appropriate Result-Code (see Section 9.1) in the Credit-Control-Answer message in order to implement the policy-defined action. Otherwise, a new quota will be returned, and the Service Element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit-control session and service session as usual. The credit-control client may not wait until the expiration of the Validity-Time and may send a spontaneous update (a new Credit-Control-Request) if the Service Element can determine, for instance, that communication between the end user and the top-up server took place. An example of this case is given in Appendix A.8 (Figure 18). Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. When the credit-control client receives (at either the session level or a service-specific level) a Final-Unit-Indication AVP or QoS-Final- Unit-Indication AVP, together with Validity-Time AVPs, but without a Granted-Service-Unit AVP, it immediately starts the graceful service termination process without sending any messages to the server. An example of this case is illustrated in Appendix A.8 (Figure 18).
5.6.3. Restrict Access Action
A Final-Unit-Indication AVP with Final-Unit-Action set to RESTRICT_ACCESS indicates to the device supporting this action that, upon consumption of the final granted units, the user's access MUST be restricted according to the IP packet filters given in the Restriction-Filter-Rule AVP(s) or according to the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Restriction-Filter-Rule AVP or the Filter-Id AVP in the Final-Unit-Indication group AVP of the Credit-Control-Answer message. A QoS-Final-Unit-Indication AVP with Final-Unit-Action set to RESTRICT_ACCESS indicates to the device supporting this action that, upon consumption of the final granted units, the actions specified in Filter-Rule AVP(s) MUST restrict the traffic according to the classifiers in the Filter-Rule AVP(s). If one or more Filter-Id AVPs are provided in the Credit-Control-Answer message, the credit-control client MUST restrict the traffic according to the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Filter-Rule AVP or the Filter-Id AVP in the QoS-Final-Unit-Indication group AVP of the Credit-Control-Answer message. If both the Final-Unit-Indication AVP and the QoS-Final-Unit- Indication AVP exist in the Credit-Control-Answer message, a credit-control client that supports the QoS-Final-Unit-Indication AVP SHOULD follow the directives included in the QoS-Final-Unit- Indication AVP and SHOULD ignore the Final-Unit-Indication AVP. An entity other than the credit-control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter Credit-Control application. Such an entity may, for instance, configure the access device with IP flows to be passed when the Diameter Credit-Control application indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP packets according to the filter rules that may have been received in the Credit-Control-Answer message, in addition to those rules that may have been configured by the other entity. However, when the user's account cannot cover the cost of the requested service, the action taken is the responsibility of the credit-control server that controls the prepaid subscriber. If another entity working in conjunction with the Diameter Credit-Control application already provisions the access device with all the required filter rules for the end user, the credit-control server presumably need not send any additional filters. Therefore, it is RECOMMENDED that credit-control server implementations
supporting graceful service termination be configurable for sending the Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, or none of the above. When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The credit-control client and the credit-control server process this intermediate interrogation and execute subsequent procedures, as specified in Section 5.6.2. The credit-control server may initiate graceful service termination when replying with the action RESTRICT_ACCESS for the first interrogation. This is similar to the behavior specified in Section 5.6.2.5.6.4. Usage of the Server-Initiated Credit Re-authorization
Once the subscriber replenishes the account, they presumably expect all the restrictions applied by the graceful service termination procedure to be removed immediately and unlimited service access to be resumed. For the best user experience, the credit-control server implementation MAY support the server-initiated credit re-authorization (see Section 5.5). In such a case, upon the successful account top-up, the credit-control server sends the Re-Auth-Request (RAR) message to solicit the credit re-authorization. The credit-control client initiates the credit re-authorization by sending the Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included in the request, as there is no allotted quota to report. The Requested-Service-Unit AVP MAY be included in the request. After the credit-control client successfully receives the Credit-Control- Answer with a new Granted-Service-Unit AVP, all the possible restrictions activated for the purpose of graceful service termination MUST be removed in the Service Element. The credit-control session and the service session continue as usual.5.7. Failure Procedures
The CCFH, as described in this section, determines the behavior of the credit-control client in fault situations. The CCFH may be (1) received from the Diameter home AAA server, (2) received from the credit-control server, or (3) configured locally. The CCFH value received from the home AAA server overrides the locally configured value. The CCFH value received from the credit-control server in the Credit-Control-Answer message always overrides any existing values.
The authorization server MAY include the Accounting-Realtime-Required AVP to determine what to do if the sending of accounting records to the accounting server has been temporarily prevented, as defined in [RFC6733]. It is RECOMMENDED that the client complement the credit-control failure procedures with a backup accounting flow toward an accounting server. By using different combinations of the Accounting-Realtime-Required AVP and the CCFH, different safety levels can be built. For example, by choosing a CCFH equal to CONTINUE for the credit-control flow and an Accounting-Realtime- Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the service can be granted to the end user even if the connection to the credit-control server is down, as long as the accounting server is able to collect the accounting information and information exchange is taking place between the accounting server and credit-control server. As the credit-control application is based on real-time bidirectional communication between the credit-control client and the credit-control server, the usage of alternative destinations and the buffering of messages may not be sufficient in the event of communication failures. Because the credit-control server has to maintain session states, moving the credit-control message stream to a backup server requires a complex context transfer solution. Whether the credit-control message stream is moved to a backup credit-control server during an ongoing credit-control session depends on the value of the CC-Session-Failover AVP. However, failover may occur at any point in the path between the credit-control client and the credit-control server if a transport failure is detected with a peer, as described in [RFC6733]. As a consequence, the credit-control server might receive duplicate messages. These duplicate or out-of-sequence messages can be detected in the credit-control server based on the credit-control server session state machine (Section 7), Session-Id AVP, and CC-Request-Number AVP. If a failure occurs during an ongoing credit-control session, the credit-control client may move the credit-control message stream to an alternative server if the credit-control server indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP. A secondary credit-control server name, either received from the home Diameter AAA server or configured locally, can be used as an address of the backup server. If the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be moved to a backup server.
For new credit-control sessions, failover to an alternative credit-control server SHOULD be performed, if possible. For instance, if an implementation of the credit-control client can determine primary credit-control server unavailability, it can establish the new credit-control sessions with a possibly available secondary credit-control server. The AAA transport profile [RFC3539] defines an application-layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) (defined in [RFC3539]). The recommended default initial value for Tw (Twinit) is 30 seconds. Twinit may be set as low as 6 seconds; however, according to [RFC3539], setting too low a value for Twinit is likely to result in an increased probability of duplicates, as well as an increase in spurious failover and failback attempts. The Diameter base protocol [RFC6733] is common to several different types of Diameter AAA applications that may be run in the same Service Element. Therefore, tuning the timer for Twinit to a lower value in order to satisfy the requirements of real-time applications, such as the Diameter Credit-Control application, will certainly cause the above-mentioned problems. For prepaid services, however, the end user expects an answer from the network in a reasonable time. Thus, the Diameter Credit-Control client will react more quickly than would the underlying base protocol. Therefore, this specification defines the Tx timer (as defined in Section 13), which is used by the credit-control client to supervise communication with the credit-control server. When the Tx timer elapses, the credit-control client takes action for the end user according to the CCFH. When the Tx timer expires, the Diameter Credit-Control client always terminates the service if the CCFH is set to the value TERMINATE. The credit-control session may be moved to an alternative server only if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before the Tx timer expires. Therefore, the value TERMINATE is not appropriate if proper failover behavior is desired. If the CCFH is set to the value CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the end user when the Tx timer expires. An Answer message with granted units may arrive later if the base protocol transport failover occurred in the path to the credit-control server. (The Twinit default value is 3 times more than the recommended Tx timeout value.) The credit-control client SHOULD grant the service to the end user, start monitoring resource usage, and wait for the possible late answer until the timeout of the request (e.g., 120 seconds). If the request fails and the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the
credit-control client terminates or continues the service -- depending on the value set in the CCFH -- and MUST free all the reserved resources for the credit-control session. If the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or the request times out and the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the credit-control client MAY send the request to a backup server, if possible. If the credit-control client receives a successful answer from the backup server, it continues the credit-control session with such a server. If the retransmitted request also fails, the credit-control client terminates or continues the service -- depending on the value set in the CCFH -- and MUST free all the reserved resources for the credit-control session. If a communication failure occurs during the graceful service termination procedure, the Service Element SHOULD always terminate the ongoing service session. If the credit-control server detects a failure during an ongoing credit-control session, it will terminate the credit-control session and return the reserved units back to the end user's account. The supervision session timer Tcc (as defined in Section 13) is used in the credit-control server to supervise the credit-control session. In order to support failover between credit-control servers, information transfer about the credit-control session and account state SHOULD take place between the primary and secondary credit-control servers. Implementations supporting credit-control session failover MUST also ensure proper detection of duplicate or out-of-sequence messages. Communication between the servers is regarded as an implementation issue and is outside the scope of this specification.6. One-Time Event
The one-time event is used when there is no need to maintain any state in the Diameter Credit-Control server -- for example, inquiring about the price of the service. The use of a one-time event implies that the user has been authenticated and authorized beforehand.
The one-time event can be used when the credit-control client wants to know the cost of the service event or to check the account balance without any credit reservations. It can also be used for refunding service units on the user's account or for direct debiting without any credit reservations. The one-time event is shown in Figure 8. Diameter End User Service Element AAA Server CC Server (CC Client) | Service Request | | | |------------------>| | | | | CCR(Event) | | | |------------------->| CCR(Event) | | | |------------------->| | | | CCA(Granted-Units)| | | CCA(Granted-Units)|<-------------------| | Service Delivery |<-------------------| | |<----------------->| | | Figure 8: One-Time Event In environments such as the 3GPP architecture, the one-time event can be sent from the Service Element directly to the credit-control server.6.1. Service Price Inquiry
The credit-control client may need to know the price of the service event. Services offered by application service providers whose prices are not known in the credit-control client might exist. The end user might also want to get an estimate of the price of a service event before requesting it. A Diameter Credit-Control client requesting the cost information MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include the Requested-Action AVP set to PRICE_ENQUIRY, and set the requested service event information in the Service-Identifier AVP in the Credit-Control-Request message. Additional service event information may be sent as service-specific AVPs or within the Service-Parameter- Info AVP. The Service-Context-Id AVP indicates the service-specific document applicable to the request. The credit-control server calculates the cost of the requested service event, but it does not perform any account-balance checks or credit reservations from the account.
The estimated cost of the requested service event is returned to the credit-control client in the Cost-Information AVP in the Credit-Control-Answer message.6.2. Balance Checks
The Diameter Credit-Control client may only have to verify that the end user's account balance covers the cost of a certain service without reserving any units from the account at the time of the inquiry. This method does not guarantee that credit would be left when the Diameter Credit-Control client requests the debiting of the account with a separate request. A Diameter Credit-Control client requesting a balance check MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include a Requested- Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP or Subscription-Id-Extension AVP in order to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service-specific document applicable to the request. The credit-control server makes the balance check, but it does not make any credit reservations from the account. The result of the balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to the credit-control client in the Check-Balance-Result AVP in the Credit-Control-Answer message.6.3. Direct Debiting
There are certain service events for which service execution is always successful in the service environment. The delay between the service invocation and the actual service delivery to the end user can be sufficiently long that the use of session-based credit-control would lead to unreasonably long credit-control sessions. In these cases, the Diameter Credit-Control client can use the one-time event scenario for direct debiting. The Diameter Credit-Control client SHOULD be sure that the requested service event execution would be successful when this scenario is used. In the Credit-Control-Request message, the CC-Request-Type AVP is set to the value EVENT_REQUEST and the Requested-Action AVP is set to DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id- Extension AVP SHOULD be included to identify the end user in the credit-control server. The Event-Timestamp AVP SHOULD be included in the request and contain the time when the service event is requested in the Service Element. The Service-Context-Id AVP indicates the service-specific document applicable to the request.
If it knows the cost of the service event, the Diameter Credit-Control client MAY include in the Requested-Service-Unit AVP the monetary amount to be charged. If the Diameter Credit-Control client does not know the cost of the service event, the Requested- Service-Unit AVP MAY contain the number of requested service events. The Service-Identifier AVP always indicates the service concerned. Additional service event information to be rated MAY be sent as service-specific AVPs or within the Service-Parameter-Info AVP. The credit-control server SHOULD rate the service event and deduct the corresponding monetary amount from the end user's account. If the type of the Requested-Service-Unit AVP is "money", no rating is needed, but the corresponding monetary amount is deducted from the end user's account. The credit-control server returns the Granted-Service-Unit AVP in the Credit-Control-Answer message to the Diameter Credit-Control client. The Granted-Service-Unit AVP contains the amount of service units that the Diameter Credit-Control client can provide to the end user. The type of the Granted-Service-Unit can be time, volume, service- specific, or money, depending on the type of service event. If the credit-control server determines that no credit-control is needed for the service, it can include the result code indicating that the credit-control is not applicable (e.g., the service is free of charge). For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP containing the estimated total cost of the requested service.6.4. Refunds
Some services may refund service units to the end user's account -- for example, gaming services. The credit-control client MUST set the CC-Request-Type AVP to the value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the Credit-Control-Request message. The Subscription-Id AVP or Subscription-Id-Extension AVP SHOULD be included to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service-specific document applicable to the request. The Diameter Credit-Control client MAY include the monetary amount to be refunded in the Requested-Service-Unit AVP. The Service- Identifier AVP always indicates the service concerned. If the Diameter Credit-Control client does not know the monetary amount to
be refunded, in addition to the Service-Identifier AVP it MAY send service-specific AVPs or the Service-Parameter-Info AVP containing additional service event information to be rated. For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP containing the estimated monetary amount of refunded units.6.5. Failure Procedure
Failover to an alternative credit-control server is allowed for a one-time event, as the server is not maintaining session states. For instance, if the credit-control client receives a protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can resend the request to an alternative server, if possible. There MAY be protocol-transparent Diameter relays and redirect agents or Diameter Credit-Control proxies between the credit-control client and credit-control server. Failover may occur at any point in the path between the credit-control client and the credit-control server if a transport failure is detected with a peer, as described in [RFC6733]. Because there can be duplicate requests for various reasons, the credit-control server is responsible for real-time duplicate detection. Implementation issues for duplicate detection are discussed in [RFC6733], Appendix C. When the credit-control client detects a communication failure with the credit-control server, its behavior depends on the requested action. The Tx timer (as defined in Section 13) is used in the credit-control client to supervise communication with the credit-control server. If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and a communication failure is detected, the credit-control client SHOULD forward the request messages to an alternative credit-control server, if possible. The secondary credit-control server name, if received from the home Diameter AAA server, can be used as an address of the backup server. If the requested action is DIRECT_DEBITING, the DDFH controls the credit-control client's behavior. The DDFH may be received from the home Diameter AAA server or may be locally configured. The credit-control server may also send the DDFH in any CCA messages to be used for direct-debiting events compiled thereafter. The DDFH value received from the home Diameter AAA server overrides the locally configured value, and the DDFH value received from the credit-control server in a Credit-Control-Answer message always overrides any existing values.
If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT grant the service if, after a possible retransmission attempt to an alternative credit-control server, the credit-control client can eventually determine from the result code or error code in the Answer message that units have not been debited. Otherwise, the credit-control client SHOULD grant the service to the end user and store the request in credit-control application-level non-volatile storage. (Note that resending the request at a later time is not a guarantee that the service will be debited, as the user's account may be empty when the server successfully processes the request.) The credit-control client MUST mark these request messages as possible duplicates by setting the T flag in the command header as described in [RFC6733], Section 3. If the DDFH is set to CONTINUE, the service SHOULD be granted, even if credit-control messages cannot be delivered and messages are not buffered. If the Tx timer expires, the credit-control client MUST continue the service and wait for a possible late answer. If the request times out, the credit-control client retransmits the request (marked with the T flag) to a backup credit-control server, if possible. If the retransmitted request also times out or if a temporary error is received in answer, the credit-control client buffers the request if the value of the DDFH is set to TERMINATE_OR_BUFFER. If a failed answer is received for the retransmitted request, the credit-control client frees all the resources reserved for the event message and deletes the request regardless of the value of the DDFH. The Credit-Control-Request with the requested action REFUND_ACCOUNT should always be stored in credit-control application-level non-volatile storage in case a temporary failure occurs. The credit-control client MUST mark the retransmitted request message as a possible duplicate by setting the T flag in the command header as described in [RFC6733], Section 3. For stored requests, the implementation may choose to limit the number of retransmission attempts and to define a retransmission interval. Note that only one entity in the credit-control system SHOULD be responsible for duplicate detection. If there is only one credit-control server within the given realm, the credit-control server may perform duplicate detection. If there is more than one credit-control server in a given realm, only one entity in the credit-control system should be responsible, to ensure that the end user's account is not debited or credited multiple times for the same service event.
(next page on part 5)
