Offer/Answer Considerations for G723 Annex A and G729 Annex B
Extracted elements (15)
The offer/answer semantics for annexa and annexb were underspecified, causing implementations to interpret mismatched parameter values differently — some proceeding with the offerer's value, others with the answerer's — resulting in codec negotiation failures. This document resolves the ambiguity by mandating that if either side indicates no support for Annex A/B, it MUST NOT be used.
When the offer has G723 with annexa=no or G729 with annexb=no, the answer is not mandated to also carry the no value because existing implementations commonly omit the annexa/annexb parameter in the answer; the offerer and answerer still proceed as if the codec is negotiated with the no value.
Existing implementations of G723 and G729 commonly omit the annexa or annexb parameter in the SDP answer even when the offer explicitly set it to 'no'. Compliant implementations must therefore treat an absent parameter in the answer as annexb=yes, while still honoring an explicit no in the offer.
If the SDP offer or answer indicates that comfort noise is not supported, comfort noise frames MUST NOT be used.
When the offer has G723 with annexa=no, after offer/answer completion both sides MUST proceed as if G723 is negotiated with annexa=no, regardless of the answer's annexa value (or its absence).
When the offer has G723 with annexa=yes and the answer has G723 with annexa=no, both offerer and answerer MUST proceed as if G723 is negotiated with annexa=no.
When the offer has G723 with no annexa parameter and the answer has G723 with annexa=yes, the offerer and answerer MUST proceed as if G723 is negotiated with annexa=yes.
When the offer has G729 with annexb=no, after offer/answer completion both sides MUST proceed as if G729 is negotiated with annexb=no, regardless of what the answer contains.
When the offer has G729 with annexb=yes and the answer has G729 with annexb=no, both offerer and answerer MUST proceed as if G729 is negotiated with annexb=no.
When the offer has G729 with no annexb parameter and the answer has G729 with annexb=yes, the offerer and answerer MUST proceed as if G729 is negotiated with annexb=yes.
When the offer or answer has G723 and the annexa parameter is absent, this MUST be treated as if annexa=yes, because all G723 implementations understand the annexa attribute and 'yes' is the implied default per RFC 4856.
When the offer or answer has G729 (including G729D or G729E) and the annexb parameter is absent, this MUST be treated as if annexb=yes, because all G729 implementations understand the annexb attribute and 'yes' is the implied default per RFC 4856.
The annexa parameter for G723 indicates whether Annex A (voice activity detection) is used or preferred; permissible values are 'yes' and 'no', with 'yes' implied if the parameter is omitted. It is carried as an fmtp attribute in SDP.
The annexb parameter for G729, G729D, and G729E indicates whether Annex B (voice activity detection/comfort noise) is used or preferred; permissible values are 'yes' and 'no', with 'yes' implied if the parameter is omitted. It is carried as an fmtp attribute in SDP.
For deployments using Voice Activity Detection (Annex A or Annex B) with SRTP, implementations MUST follow the guidelines in RFC 6562 ('Guidelines for the Use of Variable Bit Rate Audio with Secure RTP') to avoid leaking information through varying packet sizes.