[AVTCORE] Offer/answer interpretation of annexa/annexb parameter in RFC 4856

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

RFC 4856 describes the annexa parameter for G723 and the annexb
parameter for G729, G729D and G729E as follows:
 
    indicates that voice activity detection, is used or preferred.  
    Permissible values are "yes" and "no" (without the quotes); 
    "yes" is implied if this parameter is omitted.
 
However, it doesn't have any normative statement for the case where the
value of this parameter doesn't match in the SDP offer and answer. If
the offer has G729 with annexb=yes and the answer has G729 with
annexb=no, common sense seems to suggest that:
1) The offerer and answerer should proceed as if G729 is negotiated with
annexb=no. 
2) The parameter can be turned off by the answerer, but cannot be turned
on (if the offerer had turned it off).
 
However, because RFC 4856 doesn't state it clearly, various
implementations seem to have interpreted it in their own ways, including
choosing a different codec to failing the call, if the parameter doesn't
match in the offer/answer, as in:
http://sipforum.org/pipermail/discussion/2008-January/004026.html
 
RFC 3264 has the following about fmtp parameters, which indicate the
Annex B (or  Annex A) capability in offer/answer:
 
   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the answer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.
 
Ideally, RFC 4856 should have specified proper interpretation when the
Annex B (or Annex A) capability specified in the fmtp parameter doesn't
match in the offer/answer.
 
What would be the best way to fix this? By submitting a new draft
clarifying the recommended behavior (BCP) or by submitting an errata
against RFC 4856 and waiting for its next revision?
 
thanks,
Muthu