Age | Commit message (Collapse) | Author |
|
In the same vein as commit 00584303, to avoid logging traffic-related
happenings.
Not that the value in diameter.hrl is just documentation: the value is
set explicitly when diameter:start_service/2 creates diameter_app
records.
|
|
A Diameter Header Command Code is 24 bits, not 8, and an Application-ID
is 32 bits, not 24.
Thanks to Austin Aigbe for pointing it out.
|
|
RFC 3588 allowed only 3xxx result codes in an answer-message (that is,
an answer that sets the E-bit) while RFC 6733 also allows 5xxx result
codes. Setting request_errors = answer tells diameter to answer 5xxx
errors itself. Returning {answer_message, integer()} from a
handle_request callback allows both 3xxx and 5xxx result codes to be
set. {protocol_error, integer()} is retained for 3xxx result codes.
|
|
Configuring the value 'callback' all errors detected in incoming
requests to result in a handle_request callback. The default value
'answer_3xxx' is the previous behaviour in which diameter answers
protocol errors without a callback.
|
|
Instead, use whatever dictionary a transport has configured as
supporting application id 0. This is to support the updated RFC 6733
dictionaries (which bring with them updated records) and also to be able
to transparently support any changed semantics (eg. 5xxx in
answer-message).
|
|
|
|
To make for easier adding of future options. The record is only passed
into transport modules so the only compatibility issue is with these.
(No issue for diameter_{tcp,sctp} and unlikely but theoretically
possible for any other implementations, which probably don't exist at
this point.)
|
|
The module was originally just intended as a minimal callback
implementation that could be used as a template. Being able to order
just a subset of callbacks (with reasonable defaults) makes for
simpler code in many cases however so ready support for this can be
useful.
|
|
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|