diff options
Diffstat (limited to 'lib/diameter/doc')
| -rw-r--r-- | lib/diameter/doc/src/notes.xml | 202 |
1 files changed, 202 insertions, 0 deletions
diff --git a/lib/diameter/doc/src/notes.xml b/lib/diameter/doc/src/notes.xml index 60478606ad..d1ad00de5c 100644 --- a/lib/diameter/doc/src/notes.xml +++ b/lib/diameter/doc/src/notes.xml @@ -43,6 +43,208 @@ first.</p> <!-- ===================================================================== --> +<section><title>diameter 2.1</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Fix handling of Proxy-Info in answer messages setting the + E-bit.</p> + <p> + RFC 6733 requires that Proxy-Info AVPs in an incoming + request be echoed in an outgoing answer. This was not + done in answers formulated by diameter; for example, as a + result of a handle_request callback having returned an + 'answer-message' or protocol_error tuple.</p> + <p> + Own Id: OTP-9869</p> + </item> + <item> + <p> + React to nodeup/nodedown when sharing peer connections.</p> + <p> + Service configuration share_peers and use_shared_peers + did not respond to the coming and going of remote nodes.</p> + <p> + Own Id: OTP-14011</p> + </item> + <item> + <p> + Fix inappropriate message callbacks.</p> + <p> + An incoming CER or DPR was regarded as discarded, + resulting in a corresponding message callback (if + configured) in diameter_tcp/sctp.</p> + <p> + Own Id: OTP-14486</p> + </item> + <item> + <p> + Fix handling of 5009 errors (DIAMETER_AVP_OCCURS_TOO_MANY + TIMES).</p> + <p> + RFC 6733 says that the first AVP that exceeds the bound + should be reported, but the suggestions in the errors + field of a diameter_packet record counted AVPs from the + rear of the message, not the front. Additionally, + diameter 2.0 in OTP 20.0 broke the counting by accepting + one more AVP than the message grammar in question + allowed.</p> + <p> + Own Id: OTP-14512</p> + </item> + <item> + <p> + Match case insensitively in diameter_tcp/sctp accept + tuple.</p> + <p> + Matching of remote addresses when accepting connections + in a listening transport was case-sensitive, causing the + semantics to change as a consequence of (kernel) + OTP-13006.</p> + <p> + Own Id: OTP-14535 Aux Id: OTP-13006 </p> + </item> + <item> + <p> + Fix backwards incompatibility of remote send when sharing + transports.</p> + <p> + The sending of requests over a transport connection on a + remote node running an older version of diameter was + broken by diameter 2.0 in OTP 20.0.</p> + <p> + Own Id: OTP-14552</p> + </item> + <item> + <p> + Fix diameter_packet.avps decode of Grouped AVP errors in + Failed-AVP.</p> + <p> + Decode didn't produce a list of diameter_avp records, so + information about faulty component AVPs was lost.</p> + <p> + Own Id: OTP-14607</p> + </item> + </list> + </section> + + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Let unordered delivery be configured in diameter_sctp.</p> + <p> + With option {unordered, boolean() | pos_integer()}, with + false the default, and N equivalent to OS =< N, where + OS is the number of outbound streams negotiated on the + association in question. If configured, unordered sending + commences upon reception of a second message, outgoing + messages being sent on stream 0 before this.</p> + <p> + The default false is for backwards compatibility, but + false or 1 should be set to follow RFC 6733's + recommendation on the use of unordered sending to avoid + head-of-line blocking. There is typically no meaningful + order to preserve, since the order in which outgoing + messages are received by a transport process isn't known + to the sender.</p> + <p> + Own Id: OTP-10889</p> + </item> + <item> + <p> + Complete/simplify Standards Compliance in User's Guide.</p> + <p> + Own Id: OTP-10927</p> + </item> + <item> + <p> + Add service option decode_format.</p> + <p> + To allow incoming messages to be decoded into maps or + lists instead of records. Messages can be presented in + any of the formats for encode.</p> + <p> + Decode performance has also been improved.</p> + <p> + Own Id: OTP-14511 Aux Id: OTP-14343 </p> + </item> + <item> + <p> + Add service option traffic_counters.</p> + <p> + To let message-related counters be disabled, which can be + a performance improvement in some usecases.</p> + <p> + Own Id: OTP-14521</p> + </item> + <item> + <p> + Allow loopback/any as local addresses in + diameter_tcp/sctp.</p> + <p> + The atoms were implied by documentation, but not handled + in code.</p> + <p> + Own Id: OTP-14544</p> + </item> + <item> + <p> + Add transport option strict_capx.</p> + <p> + To allow the RFC 6733 requirement that a transport + connection be closed if a message is received before + capabilities exchange to be relaxed.</p> + <p> + Own Id: OTP-14546</p> + </item> + <item> + <p> + Be consistent with service/transport configuration.</p> + <p> + For options for which it's meaningful, defaults values + for transport options can now be configured on a service. + This was previously the case only for an arbitrary subset + of options.</p> + <p> + Own Id: OTP-14555</p> + </item> + <item> + <p> + Add service/transport option avp_dictionaries.</p> + <p> + To provide better support for AVPs that are not defined + in the application dictionary: configuring additional + dictionaries in an avp_dictionaries tuple allows their + AVPs to be encoded/decoded in much the same fashion as + application AVPs.</p> + <p> + The motivation is RFC 7683 Diameter Overload, Indicator + Conveyance (DOIC), that defines AVPs intended to be + piggybacked onto arbitrary messages. A DOIC dictionary + has been included in the installation, in module + diameter_gen_doic_rfc7683.</p> + <p> + Own Id: OTP-14588</p> + </item> + <item> + <p> + Decode application AVPs in answers setting the E-bit.</p> + <p> + AVPs defined in the application of the message being sent + were previously not decoded, only those in the common + application that defines the answer-message grammar.</p> + <p> + Own Id: OTP-14596</p> + </item> + </list> + </section> + +</section> + <section><title>diameter 2.0</title> <section><title>Improvements and New Features</title> |