2011 Ericsson AB. All Rights Reserved. The contents of this file are subject to the Erlang Public License, Version 1.1, (the "License"); you may not use this file except in compliance with the License. You should have received a copy of the Erlang Public License along with this software. If not, it can be retrieved online at http://www.erlang.org/. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. Release Notes notes.xml

Releases are listed in reverse chronological order, most recent first.

Diameter 0.10
Fixed Bugs and Malfunctions

Handle #sctp_paddr_change and #sctp_pdapi_event from gen_sctp.

The events are enabled by default but diameter_sctp neither disabled nor dealt with them. Reception of such an event caused a transport process to crash.

Own Id: OTP-9538

Fix header folding bug.

A prepare_request callback from diameter can return a diameter_header record in order to set values in the header of an outgoing request. A fault in diameter_lib:fold_tuple/3 caused the subsequent encode of the outgoing request to fail.

Own Id: OTP-9577

Fix bugs in sending of answer-message replies.

3001 (DIAMETER_COMMAND_UNSUPPORTED) was not sent since the decode placed the AVP list in the wrong field of the diameter_packet, causing the subsequent encode to fail. Session-Id was also set improperly, causing encode to fail even in this case.

Own Id: OTP-9578

Fix improper use of error_logger:info_report/2.

Function doesn't take a format string and arguments as it was called. Instead use error_logger:info_report/1 and use the same report format as used for warning and error reports.

Own Id: OTP-9579

Fix and clarify semantics of peer filters.

An eval filter returning a non-true value caused the call process to fail and the doc was vague on how an exception was treated. Clarify that the non-tuple host/realm filters assume messages of a certain form.

Own Id: OTP-9580

Fix and clarify relay behaviour.

Implicit filtering of the sending peer in relaying a request could cause loop detection to be preempted in a manner not specified by RFC3588. Reply with 3002 (DIAMETER_UNABLE_TO_DELIVER) on anything but an answer to a relayed request.

Own Id: OTP-9583
Improvements and New Features

@id required in dictionary files only when @messages is specified.

@id defines an application identifier and this is used only when sending or receiving messages. A dictionary can define only AVP's however, to be included by other dictionaries using @inherits, in which case it makes no sense to require @id.

Note that message definitions are not inherited with @inherits, only AVP's

Own Id: OTP-9467

Allow @enum when AVP is defined in an inherited dictionary.

3GPP standards (for one) extend the values allowed for RFC 3588 AVP's of type Enumerated. Previously, extending an AVP was only possible by completely redefining the AVP.

Own Id: OTP-9469

Migrate testsuites to pure common test and add both suites and testcases.

Own Id: OTP-9553

Requests of arbitrary form.

diameter:call/4 can be passed anything, as long as the subsequent prepare_request callback returns a term that can be encoded.

Own Id: OTP-9581
diameter 0.9

Initial release of the diameter application.

Known issues or limitations:

Some agent-related functionality is not entirely complete. In particular, support for proxy agents, that advertise specific Diameter applications but otherwise relay messages in much the same way as relay agents (for which a handle_request/3 callback can return a relay tuple), will be completed in an upcoming release. There may also be more explicit support for redirect agents, although redirect behaviour can be implemented with the current functionality.

There is some asymmetry in the treatment of messages sent as diameter_header/avp records and those sent in the "normal" fashion, and not all of this is documented. This is related to the previous point since this form of sending a message was introduced specifically to handle relay agent behaviour using the same callback interface as for client/server behaviour.

The User's Guide is currently quite thin. The introductory chapter followed by the examples (in the application examples subdirectory) may be sufficient for those having some familiarity with the Diameter protocol but the intention is to provide more introductory text. The reference documentation is quite complete, although some points could likely be expanded upon.

The function diameter:service_info/2 can be used to retrieve information about a started service (statistics, information about connected peers, etc) but this is not yet documented and both the input and output may change in the next release.

See Standards Compliance for standards-related issues.