view doc/rt_busypeers.conf.sample @ 1327:82b386714795

Set callback data also when only setting expire callback (and not answer callback as well). It is used when calling the expire callback, so not setting it makes no sense.
author Thomas Klausner <tk@giga.or.at>
date Mon, 27 Nov 2017 15:21:20 +0100
parents 7ee7b95701c9
children
line wrap: on
line source

# This file contains information for configuring the rt_busypeers extension.
# To find how to have freeDiameter load this extension, please refer to the freeDiameter documentation.
#
# The rt_busypeers extension has two purposes. 
# - when the local peer receives an error DIAMETER_TOO_BUSY from a peer, 
#   this extension catchs this error and attempts to retransmit the query to another peer if it makes sense, i.e.:
#      * the peer issuing the error is not the peer referenced in the Destination-Host AVP of the message,
#      * we have a direct link with the peer that issued the error (see parameter RetryDistantPeers below)
#
# - When a request is forwarded by the local peer, start a timer and if the corresponding answer/error has
#   not been received within RelayTimeout seconds, either send to another peer or return a DIAMETER_TOO_BUSY
#   error, depending on the RetryMaxPeers parameter.
#
# This extension is mainly useful for Diameter agents, for Diameter clients it is recommended to 
# implement this logic directly in the client application. 


# Parameter: SkipTooBusyErrors
# If defined, this parameter disables the handling of Diameter Errors message with a Result-Code set to DIAMETER_TOO_BUSY in this extension.
# When this parameter is defined, the parameter RetryDistantPeer has no effect.
# Default: parameter is not defined.
#SkipTooBusyErrors;


# Parameter: RetryDistantPeers
# By default, the extension only retries to send messages if the peer that issued the DIAMETER_TOO_BUSY error is directly connected to
# the local peer (not through a Diameter agent). This avoids the situation where the message is sent to a different relay that will deliver
# to the same busy peer afterwards. If the parameter is defined, then the extension will also retry sending messages for errors generated in
# distant peers. This should increase the chance that the message is delivered, but also can increase the load of the network unnecessarily.
# Default: parameter is not defined.
#RetryDistantPeers;


# Parameter: RetryMaxPeers
# This parameter specifies the limit on the number of times a request can be re-sent to a different peer, before the local relay gives up and 
# forwards the error to upstream.
# Default: 0, meaning all possible candidates are attempted before give up.
#RetryMaxPeers=0;


# Parameter: RelayTimeout
# If the value of this parameter is not 0, it specifies the number of milliseconds (1/1000 s) that the local relay waits for an answer to a 
# forwarded request before considering the remote peer is busy and taking corrective action (similar as if that relay had returned TOO_BUSY status).
# Note: this parameter does not apply for requests issued locally. In that case, the extension issuing the request should directly specify the timeout.
# Default: 0, meaning that there is no timeout parameter.
#RelayTimeout=0;

"Welcome to our mercurial repository"