From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>,
 "mmusic@ietf.org WG" <mmusic@ietf.org>
Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt
Thread-Index: AQHOVjGFxxHXG70GdU+mqA0iSAmD15kQEDIw
Date: Tue, 21 May 2013 20:15:51 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE224103C0B@xmb-rcd-x02.cisco.com>
References: <20130520161935.17435.91264.idtracker@ietfa.amsl.com>
 <C5E08FE080ACFD4DAE31E4BDBF944EB113508A6A@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB113508A6A@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt
Precedence: list

If the answerer supports RFC3551 it is most likely to support RFC3555 that =
defines the annexb parameter, because RFC3551 has the following:
      Receivers MUST accept comfort noise frames if restriction of their
      use has not been signaled.  The MIME registration for G729 in RFC
      3555 specifies a parameter that MAY be used with MIME or SDP to
      restrict the use of comfort noise frames.

So, the case where the answerer supports RFC3551, but not annexb isn't prob=
ably pragmatic, I think. However, a note could probably be added to the dra=
ft..

Muthu

|-----Original Message-----
|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O=
f Cullen Jennings (fluffy)
|Sent: Tuesday, May 21, 2013 8:13 PM
|To: mmusic@ietf.org WG
|Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt
|
|
|What happens when an endpoint that understands the anexb attribute sends a=
nd offer to an endpoint that
|does not understand or implement the anexb attribute ?
|
|
|
|
|On May 20, 2013, at 10:19 AM, internet-drafts@ietf.org wrote:
|
|>
|> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
|> This draft is a work item of the Multiparty Multimedia Session Control W=
orking Group of the IETF.
|>
|> 	Title           : Offer/Answer Considerations for G.723 Annex A and G.7=
29 Annex B
|> 	Author(s)       : Muthu Arul Mozhi Perumal
|>                          Parthasarathi Ravindran
|> 	Filename        : draft-ietf-mmusic-sdp-g723-g729-01.txt
|> 	Pages           : 8
|> 	Date            : 2013-05-20
|>
|> Abstract:
|>   RFC4856 describes the annexa parameter for G723 and the annexb
|>   parameter for G729, G729D and G729E. However, the specification does
|>   not describe the offerer and answerer behavior when the value of the
|>   annexa or annexb parameter does not match in the SDP offer and
|>   answer.  This document provides the offer/answer considerations for
|>   these parameters and updates RFC4856.
|>
|>
|> The IETF datatracker status page for this draft is:
|> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729
|>
|> There's also a htmlized version available at:
|> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-01
|>
|> A diff from the previous version is available at:
|> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-g723-g729-01
|>
|>
|> Internet-Drafts are also available by anonymous FTP at:
|> ftp://ftp.ietf.org/internet-drafts/
|>
|> _______________________________________________
|> I-D-Announce mailing list
|> I-D-Announce@ietf.org
|> https://www.ietf.org/mailman/listinfo/i-d-announce
|> Internet-Draft directories: http://www.ietf.org/shadow.html
|> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
|
|_______________________________________________
|mmusic mailing list
|mmusic@ietf.org
|https://www.ietf.org/mailman/listinfo/mmusic