+// RFC 6733:
+//
+// 7.5. Failed-AVP AVP
+//
+// The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
+// debugging information in cases where a request is rejected or not
+// fully processed due to erroneous information in a specific AVP. The
+// value of the Result-Code AVP will provide information on the reason
+// for the Failed-AVP AVP. A Diameter answer message SHOULD contain an
+// instance of the Failed-AVP AVP that corresponds to the error
+// indicated by the Result-Code AVP. For practical purposes, this
+// Failed-AVP would typically refer to the first AVP processing error
+// that a Diameter node encounters.
+
+ // Although the Failed-AVP definition has cardinality 1* and Failed-AVP itself is defined in
+ // most of the command codes as *[Failed-AVP], i think this is not a deliberate ambiguity.
+ // Probably the RFC wants to give freedom to the application layer, but it is recommended to
+ // have only one child (wrong avp) inside a unique message Failed-AVP to ease the Result-Code
+ // correspondence. Anyway, this behaviour could be easily opened commenting condition block (*).
+ Avp *theFailedAvp = getAvp(helpers::base::AVPID__Failed_AVP, 1, anna::Exception::Mode::Ignore);
+ if (theFailedAvp) {
+ LOGDEBUG(anna::Logger::debug("Failed-AVP has already been added. RFC 6733 Section 7.5 recommends to store only the first error found", ANNA_FILE_LOCATION));
+ return;
+ }
+
+ // Section 7.5 RFC 6733: A Diameter message SHOULD contain one Failed-AVP AVP
+ theFailedAvp = addAvp(helpers::base::AVPID__Failed_AVP);
+ Avp *leaf = theFailedAvp;
+
+ LOGDEBUG(
+ std::string msg = "Adding to Failed-AVP, the wrong avp ";
+ msg += wrongName ? wrongName : (anna::diameter::functions::avpIdAsPairString(wrong));
+ msg += " found inside ";
+ msg += parent.asString();
+
+ anna::Logger::debug(msg, ANNA_FILE_LOCATION);
+ );
+
+ std::vector<AvpId>::const_iterator it;
+ for(it = parent.AvpsId.begin(); it != parent.AvpsId.end(); it++)
+ leaf = leaf->addAvp(*it);
+
+ leaf->addAvp(wrong);