aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/src/diameter_app.xml
diff options
context:
space:
mode:
Diffstat (limited to 'lib/diameter/doc/src/diameter_app.xml')
-rw-r--r--lib/diameter/doc/src/diameter_app.xml273
1 files changed, 112 insertions, 161 deletions
diff --git a/lib/diameter/doc/src/diameter_app.xml b/lib/diameter/doc/src/diameter_app.xml
index b6870f7c28..304c69ebda 100644
--- a/lib/diameter/doc/src/diameter_app.xml
+++ b/lib/diameter/doc/src/diameter_app.xml
@@ -1,5 +1,10 @@
<?xml version="1.0" encoding="latin1" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
+<!DOCTYPE erlref SYSTEM "erlref.dtd" [
+ <!ENTITY % also SYSTEM "seealso.ent" >
+ <!ENTITY % here SYSTEM "seehere.ent" >
+ %also;
+ %here;
+]>
<erlref>
<header>
@@ -41,15 +46,13 @@ Callback module of a Diameter application.</modulesummary>
<description>
<p>
-A diameter service as started by <seealso
-marker="diameter#start_service">diameter:start_service/2</seealso>
+A diameter service as started by &mod_start_service;
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
-<seealso marker="diameter_dict">diameter_dict(4)</seealso>
-while the callback module is documented here.
+&man_dict; while the callback module is documented here.
The callback module implements the Diameter application-specific
functionality of a service.</p>
@@ -60,26 +63,24 @@ The functions themselves are of three distinct flavours:</p>
<list>
<item>
<p>
-<seealso marker="#peer_up">peer_up/3</seealso> and
-<seealso marker="#peer_down">peer_down/3</seealso> signal the
+&peer_up; and &peer_down; signal the
attainment or loss of connectivity with a Diameter peer.</p>
</item>
<item>
<p>
-<seealso marker="#pick_peer">pick_peer/4</seealso>,
-<seealso marker="#prepare_request">prepare_request/3</seealso>,
-<seealso marker="#prepare_retransmit">prepare_retransmit/3</seealso>,
-<seealso marker="#handle_answer">handle_answer/4</seealso>
-and <seealso marker="#handle_error">handle_error/4</seealso> are (or may
-be) called as a consequence of a call to <seealso
-marker="diameter#call">diameter:call/4</seealso> to send an outgoing
+&pick_peer;,
+&prepare_request;,
+&prepare_retransmit;,
+&handle_answer;
+and &handle_error; are (or may be) called as a consequence of a call
+to &mod_call; to send an outgoing
Diameter request message.</p>
</item>
<item>
<p>
-<seealso marker="#handle_request">handle_request/3</seealso>
+&handle_request;
is called in response to an incoming Diameter request message.</p>
</item>
@@ -92,10 +93,9 @@ is called in response to an incoming Diameter request message.</p>
The arities given 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 <seealso
-marker="diameter#start_service">diameter:start_service/2</seealso>
+the callback module itself when calling &mod_start_service;
and, for the call-specific callbacks, any extra arguments passed to
-<seealso marker="diameter#call">diameter:call/4</seealso>.</p>
+&mod_call;.</p>
</note>
<!-- ===================================================================== -->
@@ -128,7 +128,7 @@ mandatory values as the bare value.</p>
<item>
<p>
The representation of a Diameter message as passed to
-<seealso marker="diameter#call">diameter:call/4</seealso>.
+&mod_call;.
The record representation is as outlined in
<seealso
marker="diameter_dict#MESSAGE_RECORDS">diameter_dict(4)</seealso>:
@@ -145,7 +145,7 @@ whose head is a <c>#diameter_header{}</c> record and whose tail is a list
of <c>#diameter_avp{}</c> records.
This representation is used by diameter itself when relaying requests
as directed by the return value of a
-<seealso marker="#handle_request">handle_request/3</seealso>
+&handle_request;
callback.
It differs from the other other two in that it bypasses the checks for
messages that do not agree with their definitions in the dictionary in
@@ -174,9 +174,7 @@ A term identifying a transport connection with a Diameter peer.</p>
<marker id="peer"/>
-<tag><c>peer() =
- {<seealso marker="#peer_ref">peer_ref()</seealso>,
- <seealso marker="#capabilities">capabilities()</seealso>}</c></tag>
+<tag><c>peer() = {&peer_ref;, &capabilities;}</c></tag>
<item>
<p>
A tuple representing a Diameter peer connection.</p>
@@ -188,13 +186,9 @@ A tuple representing a Diameter peer connection.</p>
<item>
<p>
The state maintained by the application callback functions
-<seealso marker="#peer_up">peer_up/3</seealso>,
-<seealso marker="#peer_down">peer_down/3</seealso> and (optionally)
-<seealso marker="#pick_peer">pick_peer/4</seealso>.
+&peer_up;, &peer_down; and (optionally) &pick_peer;.
The initial state is configured in the call to
-<seealso
-marker="diameter#start_service">diameter:start_service/2</seealso>
-that configures the application on a service.
+&mod_start_service; 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
@@ -215,9 +209,9 @@ process.</p>
<name>Mod:peer_up(SvcName, Peer, State) -> NewState</name>
<fsummary>Invoked when a transport connection has been established</fsummary>
<type>
-<v>SvcName = <seealso marker="diameter#service_name">diameter:service_name()</seealso></v>
-<v>Peer = <seealso marker="#peer">peer()</seealso></v>
-<v>State = NewState = <seealso marker="#state">state()</seealso></v>
+<v>SvcName = &mod_service_name;</v>
+<v>Peer = &peer;</v>
+<v>State = NewState = &state;</v>
</type>
<desc>
<p>
@@ -238,14 +232,10 @@ new peer_ref().</p>
<note>
<p>
There is no requirement that a callback return before incoming
-requests are received: <seealso
-marker="#handle_request">handle_request/3</seealso> callbacks must be
-handled independently of <seealso
-marker="#peer_up">peer_up/3</seealso> and <seealso
-marker="#peer_down">peer_down/3</seealso>.</p>
+requests are received: &handle_request; callbacks must be
+handled independently of &peer_up; and &peer_down;.</p>
</note>
-<marker id="peer_down"/>
</desc>
</func>
@@ -253,21 +243,18 @@ marker="#peer_down">peer_down/3</seealso>.</p>
<name>Mod:peer_down(SvcName, Peer, State) -> NewState</name>
<fsummary>Invoked when a transport connection has been lost.</fsummary>
<type>
-<v>SvcName = <seealso marker="diameter#service_name">diameter:service_name()</seealso></v>
-<v>Peer = <seealso marker="#peer">peer()</seealso></v>
-<v>State = NewState = <seealso marker="#state">state()</seealso></v>
+<v>SvcName = &mod_service_name;</v>
+<v>Peer = &peer;</v>
+<v>State = NewState = &state;</v>
</type>
<desc>
<p>
Invoked to signal that a peer connection is no longer available
-following a previous call to <seealso
-marker="#peer_up">peer_up/3</seealso>.
+following a previous call to &peer_up;.
In particular, that the RFC 3539 watchdog state machine for the
connection has left state <c>OKAY</c> and the peer will no longer be a
-candidate in <seealso marker="#pick_peer">pick_peer()</seealso>
-callbacks.</p>
+candidate in &pick_peer; callbacks.</p>
-<marker id="pick_peer"/>
</desc>
</func>
@@ -276,16 +263,15 @@ callbacks.</p>
-> Selection | false</name>
<fsummary>Select a target peer for an outgoing request.</fsummary>
<type>
-<v>Candidates = [<seealso marker="#peer">peer()</seealso>]</v>
-<v>SvcName = <seealso marker="diameter#service_name">diameter:service_name()</seealso></v>
-<v>State = NewState = <seealso marker="#state">state()</seealso></v>
+<v>Candidates = [&peer;]</v>
+<v>SvcName = &mod_service_name;</v>
+<v>State = NewState = &state;</v>
<v>Selection = {ok, Peer} | {Peer, NewState}</v>
-<v>Peer = <seealso marker="#peer">peer()</seealso> | false</v>
+<v>Peer = &peer; | false</v>
</type>
<desc>
<p>
-Invoked as a consequence of a call to <seealso
-marker="diameter#call">diameter:call/4</seealso> to select a destination
+Invoked as a consequence of a call to &mod_call; to select a destination
peer for an outgoing request.
The return value indicates the selected peer.</p>
@@ -293,39 +279,34 @@ The return value indicates the selected peer.</p>
The candidate list contains only those peers that have advertised
support for the Diameter application in question during capabilities
exchange, that have not be excluded by a <c>filter</c> option in
-the call to <seealso marker="diameter#call">diameter:call/4</seealso>
+the call to &mod_call;
and whose watchdog state machine is in the <c>OKAY</c> 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 <c>{filter, {all, [host, realm]}}</c>
-option to <seealso marker="diameter#call">diameter:call/4</seealso>)
+option to &mod_call;)
will be placed at the head of the list.</p>
<p>
A callback that returns a peer() will be followed by a
-<seealso marker="#prepare_request">prepare_request/3</seealso>
+&prepare_request;
callback and, if the latter indicates that the request should be sent,
-by either <seealso marker="#handle_answer">handle_answer/4</seealso>
-or <seealso marker="#handle_error">handle_error/4</seealso> depending
+by either &handle_answer;
+or &handle_error; depending
on whether or not an answer message is received from the peer.
-If the transport becomes unavailable after <seealso
-marker="#prepare_request">prepare_request/3</seealso> then a new <seealso
-marker="#pick_peer">pick_peer/4</seealso> callback may take place to
-failover to an alternate peer, after which <seealso
-marker="#prepare_retransmit">prepare_retransmit/3</seealso> takes the
-place of <seealso
-marker="#prepare_request">prepare_request/3</seealso> in resending the
+If the transport becomes unavailable after &prepare_request; then a
+new &pick_peer; callback may take place to
+failover to an alternate peer, after which &prepare_retransmit; takes the
+place of &prepare_request; in resending the
request.
-There is no guarantee that a <seealso
-marker="#pick_peer">pick_peer/4</seealso> callback to select
+There is no guarantee that a &pick_peer; 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.</p>
<p>
Returning <c>false</c> or <c>{false, NewState}</c> causes <c>{error,
-no_connection}</c> to be returned from <seealso
-marker="diameter#call">diameter:call/4</seealso>.</p>
+no_connection}</c> to be returned from &mod_call;.</p>
<p>
The return values <c>false</c> and <c>{false, State}</c> (that is,
@@ -335,16 +316,14 @@ The return values <c>false</c> and <c>{false, State}</c> (that is,
<note>
<p>
The return value <c>{Peer, NewState}</c> is only allowed if
-the Diameter application in question was configured with the <seealso
-marker="diameter#application_opt">diameter:application_opt()</seealso>
-<c>{call_mutates_state, true}</c>.
+the Diameter application in question was configured with the
+&mod_application_opt; <c>{call_mutates_state, true}</c>.
Otherwise, the <c>State</c> argument is always
the intial value as configured on the application, not any subsequent
-value returned by a <seealso marker="#peer_up">peer_up/3</seealso>
-or <seealso marker="#peer_down">peer_down/3</seealso> callback.</p>
+value returned by a &peer_up;
+or &peer_down; callback.</p>
</note>
-<marker id="prepare_request"/>
</desc>
</func>
@@ -353,15 +332,13 @@ or <seealso marker="#peer_down">peer_down/3</seealso> callback.</p>
<name>Mod:prepare_request(Packet, SvcName, Peer) -> Action</name>
<fsummary>Return a request for encoding and transport.</fsummary>
<type>
-<v>Packet = <seealso marker="#packet">packet()</seealso></v>
-<v>SvcName = <seealso marker="diameter#service_name">diameter:service_name()</seealso></v>
-<v>Peer = <seealso marker="#peer">peer()</seealso></v>
+<v>Packet = &packet;</v>
+<v>SvcName = &mod_service_name;</v>
+<v>Peer = &peer;</v>
<v>Action = Send | Discard | {eval_packet, Action, PostF}</v>
-<v>Send = {send, <seealso marker="#packet">packet()</seealso>
- | <seealso marker="#message">message()</seealso>}</v>
+<v>Send = {send, &packet; | &message;}</v>
<v>Discard = {discard, Reason} | discard</v>
-<v>PostF =
- <seealso marker="diameter#evaluable">diameter:evaluable()</seealso>}</v>
+<v>PostF = &mod_evaluable;}</v>
</type>
<desc>
<p>
@@ -371,16 +348,15 @@ to modify the outgoing request.
Many implementations may simply want to return <c>{send, Packet}</c></p>
<p>
-A returned <seealso marker="#packet">packet()</seealso> should set the
+A returned &packet; should set the
request to be encoded in its
<c>msg</c> field and can set the <c>transport_data</c> field in order
to pass information to the transport process.
-Extra arguments passed to <seealso
-marker="diameter#call">diameter:call/4</seealso> can be used to
+Extra arguments passed to &mod_call; can be used to
communicate transport (or any other) data to the callback.</p>
<p>
-A returned <seealso marker="#packet">packet()</seealso> can set
+A returned &packet; can set
the <c>header</c> field to a
<c>#diameter_header{}</c> to specify values that should
be preserved in the outgoing request, values otherwise being those in
@@ -396,13 +372,11 @@ The return value is ignored.</p>
<p>
Returning <c>{discard, Reason}</c> causes the request to be aborted
-and the <seealso
-marker="diameter#call">diameter:call/4</seealso> for which the
+and the &mod_call; for which the
callback has taken place to return <c>{error, Reason}</c>.
Returning <c>discard</c> is equivalent to returning <c>{discard,
discarded}</c>.</p>
-<marker id="prepare_retransmit"/>
</desc>
</func>
@@ -410,35 +384,29 @@ discarded}</c>.</p>
<name>Mod:prepare_retransmit(Packet, SvcName, Peer) -> Action</name>
<fsummary>Return a request for encoding and retransmission.</fsummary>
<type>
-<v>Packet = <seealso marker="#packet">packet()</seealso></v>
-<v>SvcName = <seealso marker="diameter#service_name">diameter:service_name()</seealso></v>
-<v>Peer = <seealso marker="#peer">peer()</seealso></v>
+<v>Packet = &packet;</v>
+<v>SvcName = &mod_service_name;</v>
+<v>Peer = &peer;</v>
<v>Action = Send | Discard | {eval_packet, Action, PostF}</v>
-<v>Send = {send, <seealso marker="#packet">packet()</seealso>
- | <seealso marker="#message">message()</seealso>}</v>
+<v>Send = {send, &packet; | &message;}</v>
<v>Discard = {discard, Reason} | discard</v>
-<v>PostF =
- <seealso marker="diameter#evaluable">diameter:evaluable()</seealso>}</v>
+<v>PostF = &mod_evaluable;}</v>
</type>
<desc>
<p>
Invoked to return a request for encoding and retransmission.
-Has the same role as <seealso
-marker="#prepare_request">prepare_request/3</seealso> in the case that
+Has the same role as &prepare_request; in the case that
a peer connection is lost an an alternate peer selected but the
-argument <seealso marker="#packet">packet()</seealso> is as returned
-by the initial <seealso
-marker="#prepare_request">prepare_request/3</seealso>.</p>
+argument &packet; is as returned
+by the initial &prepare_request;.</p>
<p>
Returning <c>{discard, Reason}</c> causes the request to be aborted
-and a <seealso
-marker="#handle_error">handle_error/4</seealso> callback to
+and a &handle_error; callback to
take place with <c>Reason</c> as initial argument.
Returning <c>discard</c> is equivalent to returning <c>{discard,
discarded}</c>.</p>
-<marker id="handle_answer"/>
</desc>
</func>
@@ -446,52 +414,43 @@ discarded}</c>.</p>
<name>Mod:handle_answer(Packet, Request, SvcName, Peer) -> Result</name>
<fsummary>Receive an answer message from a peer.</fsummary>
<type>
-<v>Packet = <seealso marker="#packet">packet()</seealso></v>
-<v>Request = <seealso marker="#message">message()</seealso></v>
-<v>SvcName = <seealso marker="diameter#service_name">diameter:service_name()</seealso></v>
-<v>Peer = <seealso marker="#peer">peer()</seealso></v>
+<v>Packet = &packet;</v>
+<v>Request = &message;</v>
+<v>SvcName = &mod_service_name;</v>
+<v>Peer = &peer;</v>
<v>Result = term()</v>
</type>
<desc>
<p>
Invoked when an answer message is received from a peer.
-The return value is returned from <seealso
-marker="diameter#call">diameter:call/4</seealso> unless the
+The return value is returned from &mod_call; unless the
<c>detach</c> option was specified.</p>
<p>
The decoded answer record and undecoded binary are in the <c>msg</c>
and <c>bin</c> fields of the argument
-<seealso marker="#packet">packet()</seealso> respectively.
+&packet; respectively.
<c>Request</c> is the outgoing request message as was returned from
-<seealso marker="#prepare_request">prepare_request/3</seealso> or
-<seealso
- marker="#prepare_retransmit">prepare_retransmit/3</seealso>.</p>
+&prepare_request; or &prepare_retransmit;.</p>
<p>
-For any given call to <seealso
-marker="diameter#call">diameter:call/4</seealso> there is at most one
-<seealso marker="#handle_answer">handle_answer/4</seealso> callback: any
+For any given call to &mod_call; there is at most one
+&handle_answer; callback: any
duplicate answer (due to retransmission or otherwise) is discarded.
-Similarly, only one of <seealso
-marker="#handle_answer">handle_answer/4</seealso> or
-<seealso marker="#handle_error">handle_error/4</seealso> is
-called.</p>
+Similarly, only one of &handle_answer; or
+&handle_error; is called.</p>
<p>
By default, an incoming answer message that cannot be successfully
decoded causes the request process to fail, causing
-<seealso marker="diameter#call">diameter:call/4</seealso>
+&mod_call;
to return <c>{error, failure}</c> unless the <c>detach</c> option was
specified.
-In particular, there is no <seealso
-marker="#handle_error">handle_error/4</seealso> callback in this
+In particular, there is no &handle_error; callback in this
case.
-The <seealso
-marker="diameter#application_opt">diameter:application_opt()</seealso>
+The &mod_application_opt;
<c>answer_errors</c> can be set to change this behaviour.</p>
-<marker id="handle_error"/>
</desc>
</func>
@@ -500,29 +459,26 @@ marker="diameter#application_opt">diameter:application_opt()</seealso>
<fsummary>Return an error from a outgoing request.</fsummary>
<type>
<v>Reason = timeout | failover | term()</v>
-<v>Request = <seealso marker="#message">message()</seealso></v>
-<v>SvcName = <seealso marker="diameter#service_name">diameter:service_name()</seealso></v>
-<v>Peer = <seealso marker="#peer">peer()</seealso></v>
+<v>Request = &message;</v>
+<v>SvcName = &mod_service_name;</v>
+<v>Peer = &peer;</v>
<v>Result = term()</v>
</type>
<desc>
<p>
Invoked when an error occurs before an answer message is received
in response to an outgoing request.
-The return value is returned from <seealso
-marker="diameter#call">diameter:call/4</seealso> unless the
+The return value is returned from &mod_call; unless the
<c>detach</c> option was specified.</p>
<p>
Reason <c>timeout</c> indicates that an answer message has not been
-received within the time specified with the corresponding <seealso
-marker="diameter#call_opt">diameter:call_opt()</seealso>.
+received within the time specified with the corresponding &mod_call_opt;.
Reason <c>failover</c> 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.</p>
-<marker id="handle_request"/>
</desc>
</func>
@@ -530,25 +486,23 @@ not selected.</p>
<name>Mod:handle_request(Packet, SvcName, Peer) -> Action</name>
<fsummary>Receive an incoming request.</fsummary>
<type>
-<v>Packet = <seealso marker="#packet">packet()</seealso></v>
+<v>Packet = &packet;</v>
<v>SvcName = term()</v>
-<v>Peer = <seealso marker="#peer">peer()</seealso></v>
+<v>Peer = &peer;</v>
<v>Action = Reply
| {relay, [Opt]}
| discard
| {eval|eval_packet, Action, PostF}</v>
-<v>Reply = {reply, <seealso marker="#packet">packet()</seealso>
- | <seealso marker="#message">message()</seealso>}
+<v>Reply = {reply, &packet; | &message;}
| {protocol_error, 3000..3999}</v>
-<v>Opt = <seealso marker="diameter#call_opt">diameter:call_opt()</seealso></v>
-<v>PostF = <seealso marker="diameter#evaluable">diameter:evaluable()</seealso></v>
+<v>Opt = &mod_call_opt;</v>
+<v>PostF = &mod_evaluable;</v>
</type>
<desc>
<p>
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 <seealso
-marker="diameter#start_service">diameter:start_service/2</seealso>)
+callback module as configured with &mod_start_service;)
is determined by the Application Identifier in the header of the
incoming request message, the selected module being the one
whose corresponding <seealso
@@ -557,16 +511,16 @@ itself as defining either the application in question or the Relay
application.</p>
<p>
-The argument <seealso marker="#packet">packet()</seealso> has the following signature.</p>
+The argument &packet; has the following signature.</p>
-<code>
+<pre>
#diameter_packet{header = #diameter_header{},
avps = [#diameter_avp{}],
msg = record() | undefined,
- errors = [<seealso marker="diameter_dict#DATA_TYPES">Unsigned32()</seealso> | {<seealso marker="diameter_dict#DATA_TYPES">Unsigned32()</seealso>, #diameter_avp{}}],
+ errors = [&dict_Unsigned32; | {&dict_Unsigned32;, #diameter_avp{}}],
bin = binary(),
transport_data = term()}
-</code>
+</pre>
<p>
The <c>msg</c> field will be <c>undefined</c> in case the request has
@@ -580,8 +534,8 @@ The <c>errors</c> field specifies any Result-Code's identifying errors
that were encountered in decoding the request.
In this case diameter will set both Result-Code and
Failed-AVP AVP's in a returned
-answer <seealso marker="#message">message()</seealso> before sending it to the peer:
-the returned <seealso marker="#message">message()</seealso> need only set any other required AVP's.
+answer &message; before sending it to the peer:
+the returned &message; need only set any other required AVP's.
Note that the errors detected by diameter are all of the 5xxx series
(Permanent Failures).
The <c>errors</c> list is empty if the request has been received in
@@ -591,21 +545,19 @@ the relay application.</p>
The <c>transport_data</c> field contains an arbitrary term passed into
diameter from the transport module in question, or the atom
<c>undefined</c> if the transport specified no data.
-The term is preserved if a <seealso
-marker="#packet">message()</seealso> is returned but must be set
-explicitly in a returned <seealso marker="#packet">packet()</seealso>.</p>
+The term is preserved if a &message; is returned but must be set
+explicitly in a returned &packet;.</p>
<p>
The semantics of each of the possible return values are as follows.</p>
<taglist>
-<tag><c>{reply, <seealso marker="#packet">packet()</seealso>
- | <seealso marker="#message">message()</seealso>}</c></tag>
+<tag><c>{reply, &packet; | &message;}</c></tag>
<item>
<p>
Send the specified answer message to the peer.
-In the case of a <seealso marker="#packet">packet()</seealso>, the
+In the case of a &packet;, the
message to be sent must be set in the
<c>msg</c> field and the <c>header</c> field can be set to a
<c>#diameter_header{}</c> to specify values that should be
@@ -619,9 +571,9 @@ being set by diameter.</p>
Send an answer message to the peer containing the specified
protocol error.
Equivalent to</p>
-<code>
+<pre>
{reply, ['answer-message' | Avps]
-</code>
+</pre>
<p>
where <c>Avps</c> sets the Origin-Host, Origin-Realm, the specified
Result-Code and (if the request sent one) Session-Id AVP's.</p>
@@ -640,23 +592,22 @@ 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 <seealso marker="#pick_peer">pick_peer/4</seealso>
-and subsequent callbacks take place just as if <seealso
-marker="diameter#call">diameter:call/4</seealso> had been called
+added to the request and &pick_peer;
+and subsequent callbacks take place just as if &mod_call; had been called
explicitly.
The End-to-End Identifier of the incoming request is preserved in the
header of the relayed request.</p>
<p>
The returned <c>Opts</c> should not specify <c>detach</c>.
-A subsequent <seealso marker="#handle_answer">handle_answer/4</seealso>
+A subsequent &handle_answer;
callback for the relayed request must return its first
argument, the <c>#diameter_packet{}</c> record containing the answer
message.
Note that the <c>extra</c> 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
-<seealso marker="#handle_error">handle_error/4</seealso> callback)
+&handle_error; callback)
causes the request to be answered with 3002 (DIAMETER_UNABLE_TO_DELIVER).</p>
</item>