This command configures whether to continue or terminate calls when Diameter server or the OCS becomes unreachable.
Privilege
Security Administrator, Administrator
Mode
Exec > ACS Configuration > Credit Control Configuration
active-charging service service_name > credit-control
Entering the above command sequence results in the following prompt:
[local]host_name(config-dcca)#
Syntax
In 12.1 and earlier releases:
servers-unreachable { initial-request { continue | terminate [ after-timer-expiry timeout_period ] } | update-request { continue | terminate [ after-quota-expiry | after-timer-expiry timeout_period ] } }
no servers-unreachable { initial-request | update-request }
In 12.2 and later releases:
servers-unreachable { behavior-triggers { initial-request | update-request } result-code { any-error | result-code [ to end-result-code ] } | transport-failure [ response-timeout | tx-expiry ] | initial-request { continue [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | terminate [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count | after-timer-expiry timeout_period ] } | update-request { continue [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | terminate [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | after-quota-expiry | after-timer-expiry timeout_period ] } }
no servers-unreachable { initial-request | update-request }
default servers-unreachable behavior-triggers { initial-request | update-request }
no
Deletes the current servers-unreachable configuration.
In 15.0 and later releases, to remove the error result code configuration, the no command syntax is no servers-unreachable behavior-triggers { initial-request | update-request } result-code { any-error | result-code [ to end-result-code ] } .
To maintain backward compatibility i.e. in case of no servers unreachable behavior triggers configured for error result codes, the default hard coded values are applicable.
behavior-triggers { initial-request | update-request } { result-code { any-error | result-code [ to end-result-code ] } | transport-failure [ response-timeout | tx-expiry ] }
This keyword is used to determine when to apply server-unreachable action. This supports three configurable options to apply
server-unreachable action either at transport failure, Tx expiry or at response timeout. Out of these three options, the transport
failure is the default option.
-
initial-request : Specifies the behavior when Diameter server(s)/OCS become unreachable during initial session establishment.
-
update-request : Specifies the behavior when Diameter server(s)/OCS become unreachable during mid-session.
-
result-code { any-error | result-code [ to end-result-code ] } : Specifies to configure any Diameter error result code or a range of result codes to trigger entering server unreachable
mode.
result-code must be an integer ranging from 3000 to 5999.
-
transport-failure [ response-timeout | tx-expiry ] : This keyword specifies to trigger the behavior either at transport failure or response timeout OR at Transport failure or
Tx expiry.
initial-request { continue | terminate [ after-timer-expiry timeout_period ] }
Important
|
This section applies only to 12.1 and earlier releases.
|
Specifies behavior when Diameter server(s)/OCS become unreachable during initial session establishment.
-
continue : Specifies to continue call if Diameter server(s) becomes unreachable.
-
terminate : Specifies to terminate call if Diameter server(s) becomes unreachable.
after-timer-expiry timeout_period : On detecting transport failure, this keyword variable specifies the time limit for which the subscriber session will remain
in offline state before the call is terminated.
timeout_period specifies the timeout period, in seconds, and must be an integer from 1 through 4294967295.
initial-request { continue [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | terminate [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | after-timer-expiry timeout_period }
Important
|
This section applies only to 12.2 and later releases.
|
Specifies behavior when Diameter server(s)/OCS become unreachable during initial session establishment.
update-request { continue | terminate [ after-quota-expiry | after-timer-expiry timeout_period ] }
Important
|
This section applies only to 12.1 and earlier releases.
|
Specifies behavior when Diameter server(s)/OCS become unreachable during mid session.
update-request { continue [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | terminate [ { [ after-interim-time timeout_period ] [ after-interim-volume quota_value ] } server-retries retry_count ] | after-quota-expiry | after-timer-expiry timeout_period ] }
Important
|
This section applies only to 12.2 and later releases.
|
Specifies behavior when Diameter server(s)/OCS become unreachable during mid session.
Usage Guidelines
Use this command to configure whether to continue/terminate calls when Diameter server(s)/OCS are unreachable. This command
can be used to verify the functionality of the configurable action if the OCS becomes unreachable.
In 12.1 and earlier releases, the OCS is considered down/unreachable when all transport/TCP connections are down for that
OCS.
In 12.2 and later releases, the OCS is declared unreachable when all transport connections are down OR message timeouts happen
(for example, a Tx expiry or response timeout, for all available OCS servers) owing to slow response from the OCS (may be
due to network congestion or other network related issues).
The following set of actions are performed if the servers become unreachable:
This command works on the same lines as the failure-handling command, which is very generic for each of the xxx-requests and applies for Credit-Control-Failure-Handling (CCFH) during:.
-
Application-level (Tx) timeout: Here message is sent out but server does not respond for the configured "pending-timeout"
so application does CCFH actions.
-
Diabase-level request timeout: Here message is sent out but server does not respond and Diabase detects timeout of the application
message and application does CCFH actions.
-
TCP connection error: Here message is NOT sent out due to no TCP connection and application does CCFH actions.
The servers-unreachable CLI command is specifically for TCP connection error. In the event of TCP connection failure, the failure-handling and/or servers-unreachable commands can be used. This way, the operator has the flexibility to configure CCFH independent of OCS-unreachable feature,
that is having two different failure handlings for same request types.
Important
|
Please note that the flexibility to configure CCFH independent of OCS-unreachable feature is applicable only to 12.1 and earlier
releases. In 12.2 and later releases, if configured, the servers-unreachable takes precedence over the failure-handling command.
|
This command can also be used to control the triggering of behavior based on transport failure, response message timeouts
or Tx expiry when OCS becomes unreachable. The OCS could be unreachable due to no TCP connection and the message timeout could
be due to network congestion or any other network related issues.
The following are the possible and permissible configurations with respect to behavior triggering:
-
servers-unreachable behavior-triggers { initial-request | update-request } transport-failure
-
servers-unreachable behavior-triggers { initial-request | update-request } transport-failure response-timeout
-
servers-unreachable behavior-triggers { initial-request | update-request } transport-failure tx-expiry
Of these configurations, the first one is considered to be the default configuration and it will take care of backward compatibility
with 12.0 implementation.
If the server returns the CC-Failure-Handling AVP, it would apply for transport-failure/response-timeout/tx-expiry when the
CLI command servers-unreachable is not configured. If the servers-unreachable is configured for a set of behavior-triggers, then servers-unreachable configuration will be applied for them. For those
behavior-triggers for which servers-unreachable is not configured, the CC-Failure-Handling value provided by the server will
be applied.
By default, Result-Code such as 3002 (Unable-To-Deliver), 3004 (Too-Busy) and 3005 (Loop-Detected) falls under delivery failure
category and will be treated similar to response-timeout configuration.
Example
The following command configures the duration of 1111 seconds, for the subscriber session to be in offline state, after which the initial request calls will be terminated. servers-unreachable initial-request terminate after-timer-expiry 1111