diff options
author | Anders Svensson <[email protected]> | 2017-09-02 16:17:47 +0200 |
---|---|---|
committer | Anders Svensson <[email protected]> | 2017-09-04 15:45:04 +0200 |
commit | 2a25b1f4a45430a2df973f3c632b5aae703d9b81 (patch) | |
tree | ee4599d2cd53bee95e026b521a6029f66de6feed /lib/diameter/doc | |
parent | 382c88e5fdb92c6f97acad2f1c260cc69759b8e5 (diff) | |
download | otp-2a25b1f4a45430a2df973f3c632b5aae703d9b81.tar.gz otp-2a25b1f4a45430a2df973f3c632b5aae703d9b81.tar.bz2 otp-2a25b1f4a45430a2df973f3c632b5aae703d9b81.zip |
Let generic AVPs be encoded/decoded in alternate dictionaries
To support specifications like RFC 7683 DOIC, that only define AVPs, not
applications. AVPs that aren't known to the application dictionary in
question could previously not be decoded. Configuring alternate
dictionaries with the new transport/service option avp_dictionaries
changes this, so that AVPs like DOIC's Grouped OC-OLR can presented in
their fully decoded glory. Encode is also extended, allowing things like
the following to be encoded in an outgoing message:
'AVP' => [{'OC-OLR', #{'OC-Sequence-Number' => 1,
'OC-Report-Type' => 0,
'OC-Reduction-Percentage' => [25]}}]
A diameter_gen_doic_rfc7683 dictionary is installed, but
avp_dictionaries isn't specific to DOIC.
This commit also solves the problem demonstrated a few commits back,
that application AVPs aren't decoded in answers setting the E-bit. Test
coverage will come in a subsequent commit.
Diffstat (limited to 'lib/diameter/doc')
-rw-r--r-- | lib/diameter/doc/src/diameter.xml | 31 |
1 files changed, 31 insertions, 0 deletions
diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml index 0169afb619..6b84b22eb5 100644 --- a/lib/diameter/doc/src/diameter.xml +++ b/lib/diameter/doc/src/diameter.xml @@ -1083,6 +1083,37 @@ implies having to set matching *-Application-Id AVPs in a </item> <tag> +<marker id="avp_dictionaries"/><c>{avp_dictionaries, [module()]}</c></tag> +<item> +<p> +A list of alternate dictionary modules with which to encode/decode +AVPs that are not defined by the dictionary of the application in +question. +At decode, such AVPs are represented as diameter_avp records in the +<c>'AVP'</c> field of a decoded message or Grouped AVP, the first +alternate that succeeds in decoding the AVP setting the record's value +field. +At encode, values in an <c>'AVP'</c> list can be passed as AVP +name/value 2-tuples, and it is an encode error for no alternate to +define the AVP of such a tuple.</p> + +<p> +Defaults to the empty list.</p> + +<note> +<p> +The motivation for alternate dictionaries is RFC 7683, Diameter +Overload Indication Conveyance (DOIC), which defines AVPs to +be piggybacked onto existing application messages rather than defining +an application of its own. +The DOIC dictionary is provided by the diameter application, as module +<c>diameter_gen_doic_rfc7683</c>, but alternate dictionaries can be +used to encode/decode any set of AVPs not known to an application +dictionary.</p> +</note> +</item> + +<tag> <marker id="capabilities"/><c>{capabilities, [&capability;]}</c></tag> <item> <p> |