diff options
author | Anders Svensson <[email protected]> | 2015-02-16 09:11:50 +0100 |
---|---|---|
committer | Anders Svensson <[email protected]> | 2015-02-17 02:29:19 +0100 |
commit | ebe60da137dafe659d9577e1c6411bcc1ea431af (patch) | |
tree | 6a307424b19e0f4667e4245feabe360cbf3afc79 /Makefile.in | |
parent | 60ddb0dc9e5c1e28aa01548b01310744fd9ede15 (diff) | |
download | otp-ebe60da137dafe659d9577e1c6411bcc1ea431af.tar.gz otp-ebe60da137dafe659d9577e1c6411bcc1ea431af.tar.bz2 otp-ebe60da137dafe659d9577e1c6411bcc1ea431af.zip |
Don't discard component diameter_avp list on Grouped AVP decode error
The AVPs of an incoming Diameter message diameter_codec:decode/2,3 are
decoded into a diameter_packet record in two ways: as a message-specific
record in the 'msg' field and as a deep list of diameter_avp records in
the 'avps' field. The record decode came first; the diameter_avp decode
came later to support the Diameter relay application, but can also be
convenient for non-relay applications. The diameter_avp representation
can be used with outgoing messages, but what exactly is supported for
isn't clearly documented.
In the diameter_avp list representation, it's AVPs of type Grouped that
lead to nesting: instead of a diameter_avp record, a Grouped AVP is
represented by a diameter_avp list whose head is the Grouped AVP itself,
and whose tail is the list of component AVPs.
The diameter_avp decode was broken in the case of decode errors: the
Grouped AVP was represented as a bare diameter_avp, and the component
records were lost. The decode now produces the intended list. Note that
component AVPs that could not be decoded will have 'undefined' in their
data field.
Diffstat (limited to 'Makefile.in')
0 files changed, 0 insertions, 0 deletions