From fbb8586af3dd74b52ecdfa74d758f14cb82683fd Mon Sep 17 00:00:00 2001
From: Anders Svensson
Date: Mon, 26 Sep 2011 00:21:08 +0200
Subject: Fix and clarify relay behaviour
Leave it up to a handle_request callback to decide whether or
not to filter the peer from which the incoming request was sent.
Reply with 3002 (DIAMETER_UNABLE_TO_DELIVER) on anything but an
answer from the peer.
---
lib/diameter/doc/src/diameter_app.xml | 40 ++++++++++++++++++-----------------
1 file changed, 21 insertions(+), 19 deletions(-)
(limited to 'lib/diameter/doc')
diff --git a/lib/diameter/doc/src/diameter_app.xml b/lib/diameter/doc/src/diameter_app.xml
index fc359b9d1d..a3d9a8eeac 100644
--- a/lib/diameter/doc/src/diameter_app.xml
+++ b/lib/diameter/doc/src/diameter_app.xml
@@ -467,11 +467,11 @@ callback returned false.
Packet = packet()
SvcName = term()
Peer = peer()
-Action = Reply | {relay, Opts} | discard | {eval, Action, ContF}
+Action = Reply | {relay, Opts} | discard | {eval, Action, PostF}
Reply = {reply, message()}
| {protocol_error, 3000..3999}
Opts = diameter:call_opts()
-ContF = diameter:evaluable()
+PostF = diameter:evaluable()
@@ -559,26 +559,28 @@ will cause the request process in question to fail.
{relay, Opts}
-
-Relay a request to another peer.
-The appropriate Route-Record AVP will be added to the relayed request
-by diameter and pick_peer/4
-and prepare_request/3
-callback will take place just as if pick_peer/4
+and subsequent callbacks take place just as if diameter:call/4 had been called
explicitly.
-However, returning a relay tuple also causes the End-to-End
-Identifier to be preserved in the header of the relayed request as
-required by RFC 3588.
+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 and
-the handle_answer/4
-callback following from a relayed request must return its first
+The returned Opts should not specify detach.
+A subsequent handle_answer/4
+callback for the relayed request must return its first
argument, the diameter_packet record 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,
-although the form of the request message may be sufficient.
+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
@@ -587,18 +589,18 @@ although the form of the request message may be sufficient.
Discard the request.
-{eval, Action, ContF}
+{eval, Action, PostF}
-
Handle the request as if Action has been returned and then
-evaluate ContF in the request process.
+evaluate PostF in the request process.
-Note that diameter will respond to protocol errors in an incoming
-request without invoking handle_request/3.
+Note that protocol errors detected by diameter will result in an
+answer message without handle_request/3 being invoked.
--
cgit v1.2.3