Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt

[[e-mail] (Dale R. Worley)]

> From: "Parthasarathi R" <[e-mail]>
> 
> If the answerer supports RFC3551, then the answerer has to support RFC3555
> for annexb parameter. Annexb value default value is "Yes" in RFC 3555 as per
> RFC 3551. RFC 4856 obsoletes RFC 3555 without changing "annexb" related
> requirement. Please let me know any reason that you wish to change AnnexB
> parameter default value now.

Sorry, my mistake, I didn't realize that "annexb" is not an extension
of audio/g729, it's defined in the base specification:

RFC 4856 section 2.1.9

   Registration of Media Type audio/G729

   Type name: audio
   Subtype name: G729
   Optional parameters:
	[...]
        annexb: indicates that Annex B, voice activity detection, is
        used or preferred.  Permissible values are "yes" and "no"
        (without the quotes); "yes" is implied if this parameter is
        omitted.

So the answer to Cullen's query is:

> From: "Cullen Jennings (fluffy)" <[e-mail]>
> 
> What happens when an endpoint that understands the anexb attribute
> sends and offer to an endpoint that does not understand or implement
> the anexb attribute ?

Since the annexb attribute is part of the (original) registration of
audio/g729, any endpoint that implements that media type understands
the annexb attribute.  If the answer does not include the annexb
attribute, the answerer knows that it has implied the default
"annexb=yes".

Dale