From f3e38ea0653614bcfd3a03846d4cea3df5da3cdf Mon Sep 17 00:00:00 2001
From: Anders Svensson <anders@erlang.org>
Date: Thu, 30 May 2013 18:09:44 +0200
Subject: Respect Host-IP-Address configuration

Addresses returned from a transport module were always used to populate
Host-IP-Address AVP's in an outgoing CER/CEA, which precluded the
sending of a VIP address. Transport addresses are now only used if
Host-IP-Address is unspecified.

In other words, respect any configured Host-IP-Address, regardless of
the physical addresses returned by the transport. To use the physical
addresses, don't configure Host-IP-Address.
---
 lib/diameter/doc/src/diameter_transport.xml | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

(limited to 'lib/diameter/doc')

diff --git a/lib/diameter/doc/src/diameter_transport.xml b/lib/diameter/doc/src/diameter_transport.xml
index 8bccf6521e..9161bd1f48 100644
--- a/lib/diameter/doc/src/diameter_transport.xml
+++ b/lib/diameter/doc/src/diameter_transport.xml
@@ -137,15 +137,14 @@ passed to the former.</p>
 
 <p>
 The start function should use the <c>Host-IP-Address</c> list in
-<c>Svc</c> and/or <c>Config</c> to select an appropriate list of local
-IP addresses, and should return this list if different from the
-<c>Svc</c> addresses.
+<c>Svc</c> and/or <c>Config</c> to select and return an appropriate
+list of local IP addresses.
 In the connecting case, the local address list can instead be
 communicated in a <c>connected</c> message (see &MESSAGES; below)
 following connection establishment.
 In either case, the local address list is used to populate
 <c>Host-IP-Address</c> AVPs in outgoing capabilities exchange
-messages.</p>
+messages if <c>Host-IP-Address</c> is unspecified.</p>
 
 <p>
 A transport process must implement the message interface documented below.
-- 
cgit v1.2.3


From 21e778b998b895034453251d83c3e6aaa72fe395 Mon Sep 17 00:00:00 2001
From: Anders Svensson <anders@erlang.org>
Date: Fri, 31 May 2013 14:46:59 +0200
Subject: Fix setting of Failed-AVP on {answer_message, 5xxx} from
 handle_request

RFC 6733 says that certain 5xxx result codes must be accompanied by
Failed-AVP, and decode populates #diameter_packet.errors with
Result-Code/AVP pairs for errors it detects. However, Failed-AVP was not
set in the outgoing answer if the handle_request callback returned
{answer_message, 5xxx}. It is now set with the AVP from the first pair
with the specified Result-Code, if found.

Note that {answer_message, 5xxx} doesn't handle all cases in which a
5xxx answer is required, only that in which the setting above is
appropriate. If it isn't then handle_request should construct its answer
and return {reply, Ans}.
---
 lib/diameter/doc/src/diameter_app.xml | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 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 d4fb792787..e6c9cc9a90 100644
--- a/lib/diameter/doc/src/diameter_app.xml
+++ b/lib/diameter/doc/src/diameter_app.xml
@@ -565,7 +565,8 @@ Equivalent to</p>
 </pre>
 <p>
 where <c>Avps</c> sets the Origin-Host, Origin-Realm, the specified
-Result-Code and (if the request contained one) Session-Id AVP's.</p>
+Result-Code and (if the request contained one) Session-Id AVP's, and
+possibly Failed-AVP as described below.</p>
 
 <p>
 Returning a value other than 3xxx or 5xxx will cause the request
@@ -573,6 +574,14 @@ 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 <c>diameter_gen_base_rfc3588</c>.
 (Since RFC 3588 only allows 3xxx values in an answer-message.)</p>
+
+<p>
+When returning 5xxx, Failed-AVP will be populated with the AVP of the
+first matching Result-Code/AVP pair in the <c>errors</c> field of the
+argument &packet;, if found.
+If this is not appropriate then an answer-message should be
+constructed explicitly and returned in a <c>reply</c> tuple
+instead.</p>
 </item>
 
 <tag><c>{relay, Opts}</c></tag>
@@ -592,8 +601,7 @@ header of the relayed request.</p>
 The returned <c>Opts</c> should not specify <c>detach</c>.
 A subsequent &handle_answer;
 callback for the relayed request must return its first
-argument, the <c>#diameter_packet{}</c> record containing the answer
-message.
+argument, the &packet; 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
-- 
cgit v1.2.3