Provided by: erlang-manpages_20.2.2+dfsg-1ubuntu2_all 
NAME
diameter_app - Callback module of a Diameter application.
DESCRIPTION
A diameter service as started by diameter:start_service/2 configures one of more Diameter
applications, each of whose configuration specifies a callback that handles messages
specific to the application. The messages and AVPs of the application are defined in a
dictionary file whose format is documented in diameter_dict(5) while the callback module
is documented here. The callback module implements the Diameter application-specific
functionality of a service.
A callback module must export all of the functions documented below. The functions
themselves are of three distinct flavours:
* peer_up/3 and peer_down/3 signal the attainment or loss of connectivity with a
Diameter peer.
* pick_peer/4, prepare_request/3, prepare_retransmit/3, handle_answer/4 and
handle_error/4 are (or may be) called as a consequence of a call to diameter:call/4 to
send an outgoing Diameter request message.
* handle_request/3 is called in response to an incoming Diameter request message.
The arities for the the callback functions here assume no extra arguments. All functions
will also be passed any extra arguments configured with the callback module itself when
calling diameter:start_service/2 and, for the call-specific callbacks, any extra arguments
passed to diameter:call/4.
DATA TYPES
capabilities() = #diameter_caps{}:
A record containing the identities of the local Diameter node and the remote Diameter
peer having an established transport connection, as well as the capabilities as
determined by capabilities exchange. Each field of the record is a 2-tuple consisting
of values for the (local) host and (remote) peer. Optional or possibly multiple values
are encoded as lists of values, mandatory values as the bare value.
message() = diameter_codec:message():
The representation of a Diameter message as passed to diameter:call/4 or returned from
a handle_request/3 callback.
packet() = diameter_codec:packet():
A container for incoming and outgoing Diameter messages that's passed through
encode/decode and transport. Fields should not be set in return values except as
documented.
peer_ref() = term():
A term identifying a transport connection with a Diameter peer.
peer() = {peer_ref(), capabilities()}:
A tuple representing a Diameter peer connection.
state() = term():
The state maintained by the application callback functions peer_up/3, peer_down/3 and
(optionally) pick_peer/4. The initial state is configured in the call to
diameter:start_service/2 that configures the application on a service. Callback
functions returning a state are evaluated in a common service-specific process while
those not returning state are evaluated in a request-specific process.
EXPORTS
Mod:peer_up(SvcName, Peer, State) -> NewState
Types:
SvcName = diameter:service_name()
Peer = peer()
State = NewState = state()
Invoked to signal the availability of a peer connection on the local Erlang node.
In particular, capabilities exchange with the peer has indicated support for the
application in question, the RFC 3539 watchdog state machine for the connection has
reached state OKAY and Diameter messages can be both sent and received.
Note:
A watchdog state machine can reach state OKAY from state SUSPECT without a new
capabilities exchange taking place. A new transport connection (and capabilities
exchange) results in a new peer_ref().
Note:
There is no requirement that a callback return before incoming requests are
received: handle_request/3 callbacks must be handled independently of peer_up/3 and
peer_down/3.
Mod:peer_down(SvcName, Peer, State) -> NewState
Types:
SvcName = diameter:service_name()
Peer = peer()
State = NewState = state()
Invoked to signal that a peer connection on the local Erlang node is no longer
available following a previous call to peer_up/3. In particular, that the RFC 3539
watchdog state machine for the connection has left state OKAY and the peer will no
longer be a candidate in pick_peer/4 callbacks.
Mod:pick_peer(LocalCandidates, RemoteCandidates, SvcName, State) -> Selection | false
Types:
LocalCandidates = RemoteCandidates = [peer()]
SvcName = diameter:service_name()
State = NewState = state()
Selection = {ok, Peer} | {Peer, NewState}
Peer = peer() | false
Invoked as a consequence of a call to diameter:call/4 to select a destination peer
for an outgoing request. The return value indicates the selected peer.
The candidate lists contain only those peers that have advertised support for the
Diameter application in question during capabilities exchange, that have not be
excluded by a filter option in the call to diameter:call/4 and whose watchdog state
machine is in the OKAY state. The order of the elements is unspecified except that
any peers whose Origin-Host and Origin-Realm matches that of the outgoing request
(in the sense of a {filter, {all, [host, realm]}} option to diameter:call/4) will
be placed at the head of the list. LocalCandidates contains peers whose transport
process resides on the local Erlang node while RemoteCandidates contains peers that
have been communicated from other nodes by services of the same name.
A callback that returns a peer() will be followed by a prepare_request/3 callback
and, if the latter indicates that the request should be sent, by either
handle_answer/4 or handle_error/4 depending on whether or not an answer message is
received from the peer. If the transport becomes unavailable after
prepare_request/3 then a new pick_peer/4 callback may take place to failover to an
alternate peer, after which prepare_retransmit/3 takes the place of
prepare_request/3 in resending the request. There is no guarantee that a
pick_peer/4 callback to select an alternate peer will be followed by any additional
callbacks since a retransmission to an alternate peer is abandoned if an answer is
received from a previously selected peer.
The return values false and {false, State} (that is, NewState = State) are
equivalent, as are {ok, Peer} and {Peer, State}.
Note:
The diameter:service_opt() use_shared_peers determines whether or not a service
uses peers shared from other nodes. If not then RemoteCandidates is the empty list.
Warning:
The return value {Peer, NewState} is only allowed if the Diameter application in
question was configured with the diameter:application_opt() {call_mutates_state,
true}. Otherwise, the State argument is always the initial value as configured on
the application, not any subsequent value returned by a peer_up/3 or peer_down/3
callback.
Mod:prepare_request(Packet, SvcName, Peer) -> Action
Types:
Packet = packet()
SvcName = diameter:service_name()
Peer = peer()
Action = Send | Discard | {eval_packet, Action, PostF}
Send = {send, packet() | message()}
Discard = {discard, Reason} | discard
PostF = diameter:eval()}
Invoked to return a request for encoding and transport. Allows the sender to use
the selected peer's capabilities to modify the outgoing request. Many
implementations may simply want to return {send, Packet}
A returned packet() should set the request to be encoded in its msg field and can
set the transport_data field in order to pass information to the transport process.
Extra arguments passed to diameter:call/4 can be used to communicate transport (or
any other) data to the callback.
A returned packet() can set the header field to a #diameter_header{} to specify
values that should be preserved in the outgoing request, values otherwise being
those in the header record contained in Packet. A returned length, cmd_code or
application_id is ignored.
A returned PostF will be evaluated on any encoded #diameter_packet{} prior to
transmission, the bin field containing the encoded binary. The return value is
ignored.
Returning {discard, Reason} causes the request to be aborted and the
diameter:call/4 for which the callback has taken place to return {error, Reason}.
Returning discard is equivalent to returning {discard, discarded}.
Mod:prepare_retransmit(Packet, SvcName, Peer) -> Action
Types:
Packet = packet()
SvcName = diameter:service_name()
Peer = peer()
Action = Send | Discard | {eval_packet, Action, PostF}
Send = {send, packet() | message()}
Discard = {discard, Reason} | discard
PostF = diameter:eval()}
Invoked to return a request for encoding and retransmission. Has the same role as
prepare_request/3 in the case that a peer connection is lost an an alternate peer
selected but the argument packet() is as returned by the initial prepare_request/3.
Returning {discard, Reason} causes the request to be aborted and a handle_error/4
callback to take place with Reason as initial argument. Returning discard is
equivalent to returning {discard, discarded}.
Mod:handle_answer(Packet, Request, SvcName, Peer) -> Result
Types:
Packet = packet()
Request = message()
SvcName = diameter:service_name()
Peer = peer()
Result = term()
Invoked when an answer message is received from a peer. The return value is
returned from diameter:call/4 unless the detach option was specified.
The decoded answer record and undecoded binary are in the msg and bin fields of the
argument packet() respectively. Request is the outgoing request message as was
returned from prepare_request/3 or prepare_retransmit/3.
For any given call to diameter:call/4 there is at most one handle_answer/4
callback: any duplicate answer (due to retransmission or otherwise) is discarded.
Similarly, only one of handle_answer/4 or handle_error/4 is called.
By default, an incoming answer message that cannot be successfully decoded causes
the request process to fail, causing diameter:call/4 to return {error, failure}
unless the detach option was specified. In particular, there is no handle_error/4
callback in this case. The diameter:application_opt() answer_errors can be set to
change this behaviour.
Mod:handle_error(Reason, Request, SvcName, Peer) -> Result
Types:
Reason = timeout | failover | term()
Request = message()
SvcName = diameter:service_name()
Peer = peer()
Result = term()
Invoked when an error occurs before an answer message is received in response to an
outgoing request. The return value is returned from diameter:call/4 unless the
detach option was specified.
Reason timeout indicates that an answer message has not been received within the
time specified with the corresponding diameter:call_opt(). Reason failover
indicates that the transport connection to the peer to which the request has been
sent has become unavailable and that not alternate peer was not selected.
Mod:handle_request(Packet, SvcName, Peer) -> Action
Types:
Packet = packet()
SvcName = term()
Peer = peer()
Action = Reply | {relay, [Opt]} | discard | {eval|eval_packet, Action, PostF}
Reply = {reply, packet() | message()} | {answer_message, 3000..3999|5000..5999}
| {protocol_error, 3000..3999}
Opt = diameter:call_opt()
PostF = diameter:eval()
Invoked when a request message is received from a peer. The application in which
the callback takes place (that is, the callback module as configured with
diameter:start_service/2) is determined by the Application Identifier in the header
of the incoming request message, the selected module being the one whose
corresponding dictionary declares itself as defining either the application in
question or the Relay application.
The argument packet() has the following signature.
#diameter_packet{header = #diameter_header{},
avps = [#diameter_avp{}],
msg = record() | undefined,
errors = [Unsigned32() | {Unsigned32(), #diameter_avp{}}],
bin = binary(),
transport_data = term()}
The msg field will be undefined in case the request has been received in the relay
application. Otherwise it contains the record representing the request as outlined
in diameter_dict(5).
The errors field specifies any results codes identifying errors found while
decoding the request. This is used to set Result-Code and/or Failed-AVP in a
returned answer unless the callback returns a #diameter_packet{} whose errors field
is set to either a non-empty list of its own, in which case this list is used
instead, or the atom false to disable any setting of Result-Code and Failed-AVP.
Note that the errors detected by diameter are of the 3xxx and 5xxx series, Protocol
Errors and Permanent Failures respectively. The errors list is empty if the request
has been received in the relay application.
The transport_data field contains an arbitrary term passed into diameter from the
transport module in question, or the atom undefined if the transport specified no
data. The term is preserved if a message() is returned but must be set explicitly
in a returned packet().
The semantics of each of the possible return values are as follows.
{reply, packet() | message()}:
Send the specified answer message to the peer. In the case of a packet(), the
message to be sent must be set in the msg field and the header field can be set
to a #diameter_header{} to specify values that should be preserved in the
outgoing answer, appropriate values otherwise being set by diameter.
{answer_message, 3000..3999|5000..5999}:
Send an answer message to the peer containing the specified Result-Code.
Equivalent to
{reply, ['answer-message' | Avps]
where Avps sets the Origin-Host, Origin-Realm, the specified Result-Code and
(if the request contained one) Session-Id AVPs, and possibly Failed-AVP as
described below.
Returning a value other than 3xxx or 5xxx will cause the request process in
question to fail, as will returning a 5xxx value if the peer connection in
question has been configured with the RFC 3588 common dictionary
diameter_gen_base_rfc3588. (Since RFC 3588 only allows 3xxx values in an
answer-message.)
When returning 5xxx, Failed-AVP will be populated with the AVP of the first
matching Result-Code/AVP pair in the errors field of the argument packet(), if
found. If this is not appropriate then an answer-message should be constructed
explicitly and returned in a reply tuple instead.
{relay, Opts}:
Relay a request to another peer in the role of a Diameter relay agent. If a
routing loop is detected then the request is answered with 3005
(DIAMETER_LOOP_DETECTED). Otherwise a Route-Record AVP (containing the sending
peer's Origin-Host) is added to the request and pick_peer/4 and subsequent
callbacks take place just as if diameter:call/4 had been called explicitly. The
End-to-End Identifier of the incoming request is preserved in the header of the
relayed request.
The returned Opts should not specify detach. A subsequent handle_answer/4
callback for the relayed request must return its first argument, the packet()
containing the answer message. Note that the extra option can be specified to
supply arguments that can distinguish the relay case from others if so desired.
Any other return value (for example, from a handle_error/4 callback) causes the
request to be answered with 3002 (DIAMETER_UNABLE_TO_DELIVER).
discard:
Discard the request. No answer message is sent to the peer.
{eval, Action, PostF}:
Handle the request as if Action has been returned and then evaluate PostF in
the request process. The return value is ignored.
{eval_packet, Action, PostF}:
Like eval but evaluate PostF on any encoded #diameter_packet{} prior to
transmission, the bin field containing the encoded binary. The return value is
ignored.
{protocol_error, 3000..3999}:
Equivalent to {answer_message, 3000..3999}.
Note:
Requests containing errors may be answered by diameter, without a callback taking
place, depending on the value of the diameter:application_opt() request_errors.