Erlang/OTP 17.5.6.3

The diameter-1.9.2.1 application can be applied independently of other applications on a full OTP 17 installation.

OTP-12871

Application(s):

diameter

Don't report 5005 (DIAMETER_AVP_MISSING) errors unnecessarily.

An AVP whose decode failed was reported as missing, despite having been reported with another error as a consequence of the failure.

OTP-12879

Application(s):

diameter

Related Id(s):

OTP-12475

Fix relay encode of nested, Grouped AVPs.

A fault in OTP-12475 caused encode to fail if the first AVP in a Grouped AVP was itself Grouped.

OTP-12891

Application(s):

diameter

Improve decode performance.

The time required to decode a message increased quadratically with the number of AVPs in the worst case, leading to extremely long execution times.

OTP-12902

Application(s):

diameter

Match acceptable peer addresses case insensitively.

Regular expressions passed in an 'accept' tuple to diameter_tcp or diameter_sctp inappropriately matched case.

OTP-12912

Application(s):

diameter

Improve watchdog and statistics performance.

Inefficient use of timers contributed to poor performance at high load, as did ordering of the table statistics are written to.

OTP-12929

Application(s):

diameter

Fix start order of alternate transports.

A transport configured with diameter:add_transport/2 can be passed multiple transport_module/transport_config tuples in order to specify alternate configuration, modules being attempted in order until one succeeds. This is primarily for the connecting case; for example, to allow a transport to be configured to first attempt connection over SCTP, and then TCP in case SCTP fails. Multiple module tuples can be paired with a single config tuple, but in this case the start order was reversed relative to the order in which the modules were specifed.

OTP-12930

Application(s):

diameter

Fix decode of Grouped AVPs containing errors.

RFC 6733 says this of Failed-AVP in 7.5:

-- In the case where the offending AVP is embedded within a Grouped AVP, the Failed-AVP MAY contain the grouped AVP, which in turn contains the single offending AVP. The same method MAY be employed if the grouped AVP itself is embedded in yet another grouped AVP and so on. In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up to the single offending AVP. This enables the recipient to detect the location of the offending AVP when embedded in a group.

It says this of DIAMETER_INVALID_AVP_LENGTH in 7.1.5:

-- The request contained an AVP with an invalid length. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. In cases where the erroneous AVP length value exceeds the message length or is less than the minimum AVP header length, it is sufficient to include the offending AVP header and a zero filled payload of the minimum required length for the payloads data type. If the AVP is a Grouped AVP, the Grouped AVP header with an empty payload would be sufficient to indicate the offending AVP. In the case where the offending AVP header cannot be fully decoded when the AVP length is less than the minimum AVP header length, it is sufficient to include an offending AVP header that is formulated by padding the incomplete AVP header with zero up to the minimum AVP header length.

The AVPs placed in the errors field of a diameter_packet record are intended to be appropriate for inclusion in a Failed-AVP, but neither of the above paragraphs has been followed in the Grouped case: the entire faulty AVP (non-faulty components and all) has been included. This made it difficult to identify the actual faulty AVP in all but simple cases.

The decode is now adapted to the RFC, and implements the suggested single faulty AVP, nested in as many Grouped containers as required.

Full runtime dependencies of diameter-1.9.2.1: erts-6.0, kernel-3.0, ssl-5.3.4, stdlib-2.0