From f719d0fe308f00b85f92c29d7cdf9b0dc20d98a2 Mon Sep 17 00:00:00 2001 From: Erlang/OTP Date: Mon, 7 Apr 2014 19:52:48 +0200 Subject: Update release notes --- lib/diameter/doc/src/notes.xml | 158 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 158 insertions(+) (limited to 'lib/diameter/doc') diff --git a/lib/diameter/doc/src/notes.xml b/lib/diameter/doc/src/notes.xml index e2390df37c..675ffcfd18 100644 --- a/lib/diameter/doc/src/notes.xml +++ b/lib/diameter/doc/src/notes.xml @@ -42,6 +42,164 @@ first.

+
diameter 1.6 + +
Fixed Bugs and Malfunctions + + +

+ Add missing check at dictionary compilation.

+

+ In particular, that an AVP defined as having type Grouped + in an @avp_types section has a corresponding definition + in a @grouped section.

+

+ Own Id: OTP-11561

+ + +

+ Correct documentation on the setting of Origin-State-Id

+

+ It was incorrectly stated that the AVP would be set in an + outgoing DPR/DPA.

+

+ Own Id: OTP-11583

+ + +

+ Change interface for communicating outbound stream id to + diameter_sctp

+

+ The module uses the transport_data field of record + diameter_packet to communicate the stream on which the an + incoming message is received and on which an outgoing + message should be sent, the previous interface being that + both are communicated as a tuple of the form {stream, + Id}. However, since diameter retains the value of an + incoming request's transport_data unless the + corresponding answer message specifies otherwise, the + behaviour in this case is to send an answer on the + outbound stream with the same identifier as the that of + the inbound stream on which the request was received. If + the inbound stream id is greater than or equal to the + number of outbound streams then this is guaranteed to + fail, causing the transport process in question to + terminate. There is no relationship between inbound and + outbound stream identifiers so diameter_sctp's imposition + of one is simply wrong.

+

+ Outbound stream ids are now communicated with a different + tuple: {outstream, Id}, interpreted modulo the number of + outbound streams. Thus, retention of an inbound request's + transport_data has no effect on the selection of an + outbound stream.

+

+ The change in interface is not strictly backwards + compatible because of the new atom for the outbound + stream. However, as there is currently no documented way + of obtaining the available number of outbound streams for + a peer connection, there is no way for a client to have + known the range of ids from which it could reliably have + chosen with the previous interface, so any setting of the + outbound stream has probably been unintentional. Not + explicitly specifying an outbound stream now results in a + round-robin selection.

+

+ Thanks to Sharmila Pillai for reporting the problem.

+

+ *** POTENTIAL INCOMPATIBILITY ***

+

+ Own Id: OTP-11593

+ + +

+ Fix unicode path failure in diameter_make:codec/2.

+

+ A dictionary path containing a unicode codepoint > 255 + caused the function to fail.

+

+ Own Id: OTP-11655

+ + +

+ Fix 'accept' config to diameter_sctp.

+

+ OTP-10893 added support for {accept, Match} tuples to + specify addresses or regexps that should be matched + against peer addresses to decide whether or not a newly + established association should be retained, but this + hasn't been functional in the SCTP case because of + missing support in inet(3).

+

+ The display of both local and peer addresses in + diameter:service_info/2 output has also been corrected.

+

+ Own Id: OTP-11661 Aux Id: OTP-10229

+ + +

+ Be lenient with the M-bit in Grouped AVPs.

+

+ RFC 6733 says this, in 4.4:

+

+

Receivers of a Grouped AVP that does + not have the 'M' (mandatory) bit set and one or more of + the encapsulated AVPs within the group has the 'M' + (mandatory) bit set MAY simply be ignored if the Grouped + AVP itself is unrecognized. The rule applies even if the + encapsulated AVP with its 'M' (mandatory) bit set is + further encapsulated within other sub-groups, i.e., other + Grouped AVPs embedded within the Grouped + AVP.

+

+ The first sentence is mangled but take it to mean this:

+

+

An unrecognized AVP of type Grouped + that does not set the 'M' bit MAY be ignored even if one + of its encapsulated AVPs sets the 'M' + bit.

+

+ This is a bit of a non-statement since if the AVP is + unrecognized then its type is unknown. We therefore don't + know that its data bytes contain encapsulated AVPs, so + can't but ignore any of those that set the M-bit. Doing + anything else when the type *is* known would be + inconsistent.

+

+ OTP-11087 (R16B03) caused the M-bit on any unrecognized + AVP to be regarded as an error, unrecognized being taken + to mean "not explicitly defined as a member of its + container". (That is, an AVP that can't be packed into a + dedicated record field, which is slightly stronger than + "not defined".) This fixed the original intention for + top-level AVPs but broke the required leniency for + Grouped AVPs whose type is known. This leniency is now + restored.

+

+ Note that dictionary files need to be recompiled for the + change to have effect.

+

+ Thanks to Rory McKeown for reporting the problem.

+

+ Own Id: OTP-11675 Aux Id: OTP-11087

+ + +

+ Fix pick_peer case clause failure.

+

+ In the case of {call_mutates_state, true} configuration + on the service in question, any peer selection that + failed to select a peer resulted in a case clause + failure. This was noticed in the case of a peer failover + in which an alternate peer wasn't available.

+

+ Own Id: OTP-11789

+ + +
+ +
+
diameter 1.5
Improvements and New Features -- cgit v1.2.3