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

From: [email-masked]
Date: Mon, 20 May 2013 09:19:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Offer/Answer Considerations for G.723 Annex A and G.729 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=draft-ietf-mmusic-sdp-g723-g729-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 21 May 2013 14:43:00 +0000

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 ?

On May 20, 2013, at 10:19 AM, [email-masked] wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 21 May 2013 23:17:48 +0530

Cullen,

As per Sec 2.1.9 RFC 4856, "annexb=no" has to be sent by Answerer in case
the answerer does not support G729 AnnexB. The exact RFC snippet is as
follows:  

        "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."

Please let me know whether you wish to explicitly mention in the draft that
Answerer *MUST* send "annexb=no".

Thanks
Partha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings (fluffy)
> Sent: Tuesday, May 21, 2013 8:13 PM
> To: [email-masked] 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 and offer to an endpoint that does not understand or implement
> the anexb attribute ?
> 
> 
> 
> 
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 21 May 2013 20:15:51 +0000

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 probably pragmatic, I think. However, a note could probably be added to the draft..

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
|Sent: Tuesday, May 21, 2013 8:13 PM
|To: [email-masked] 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 and offer to an endpoint that
|does not understand or implement the anexb attribute ?
|
|
|
|
|On May 20, 2013, at 10:19 AM, [email-masked] wrote:
|
|>
|> A New Internet-Draft is available from the on-line Internet-Drafts directories.
|> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
|>
|> 	Title           : Offer/Answer Considerations for G.723 Annex A and G.729 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=draft-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
|> [email-masked]
|> 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
[email-masked]
|https://www.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 May 2013 22:04:07 -0400 (EDT)

> > From: Cullen Jennings (fluffy)
> > 
> > What happens when an endpoint that understands the [annexb] attribute
> > sends [an] offer to an endpoint that does not understand or implement
> > the [annexb] attribute ?

> From: "Parthasarathi R" <[email-masked]>
> 

No, if the offerer sends "annexb=yes" and the answerer *does not
understand it*, that is, does not support this I-D, the answer will
not contain an annexb parameter.  You should make sure the draft
describes how the *offerer* detects this situation and ensures that
the operation of the codec is done as well as possible.

Dale

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 23 May 2013 23:46:41 +0530

Dale,

The current scope of this draft is to add the offer/answer (O/A)
consideration to RFC 4856 as it is missing in RFC 4856. The draft provides
clarification like "annexb=no" is in the offer whether annexb=yes is allowed
by the answerer or not.

Your proposal breaks RFC 4856 default value for annexb as the missing annexb
parameter in SDP implies that Annexb is supported as per 4856. The reason
for the default annexb value as "Yes" instead of "no" is as follows:

RFC3551 snippet related to G729 AnnexB:

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.

Thanks
Partha

> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Thursday, May 23, 2013 7:34 AM
> To: Parthasarathi R
> Cc: [email-masked]; [email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 May 2013 18:07:49 -0400 (EDT)

> 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)" <[email-masked]>
> 

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

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 24 May 2013 04:20:18 +0000

|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".

Thank you for the clarifying text. We'll include it in the next revision of the draft.

Muthu

|-----Original Message-----
|From: Dale R. Worley [mailto:[email-masked]]
|Sent: Friday, May 24, 2013 3:38 AM
|To: Parthasarathi R
|Cc: Cullen Jennings (fluffy); [email-masked]; Muthu Arul Mozhi Perumal (mperumal)
|Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-01.txt
|
|> From: "Parthasarathi R" <[email-masked]>
|>
|> 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)" <[email-masked]>
|>
|> 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

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 26 May 2013 16:28:16 +0530

Dale,

Thanks for the closure.

Cullen & all,

Hope the below proposed text is fine with you. The text will be added in the
next revision for both g729 annnexb & g723 annexa in case there is no
objection for an week. 

BTW, it is the only one update pending in this draft and there is no other
open item.

Thanks
Partha

> From: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
> Sent: Friday, May 24, 2013 9:50 AM
> To: Dale R. Worley; Parthasarathi R
> Cc: Cullen Jennings (fluffy); [email-masked]
> Subject: RE: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-
> 01.txt
>

---

From: Ari Keränen <[email-masked]>
Date: Mon, 27 May 2013 01:42:20 +0300

Hi,

There seems to be one (recurring) typo in the examples:

4.1.  Offer with G279 annexb=yes and answer with G279 annexb=no

            [Offer with G279 annexb=yes]

s/G279/G729/g
(same in the sections 4.2 & 4.3)

Also, the following sentence in section 3 seems a bit hard to parse:

    Based on the above, it is best to not use comfort noise frames if the
    SDP offer or answer indicates no support for it.

Maybe rather say "[...] offer or answer indicates that comfort noise is 
not supported", if that's what you mean.

Cheers,
Ari

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 27 May 2013 21:49:41 +0530

Ari,

Thank for your comments. We'll incorporate all the comments in the next
revision.

Thanks
Partha

> Behalf Of Ari Keränen
> Sent: Monday, May 27, 2013 4:12 AM
> To: [email-masked]
> Cc: mmusic