Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g729-03
"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Fri, 05 July 2013 05:24 UTC
Return-Path: <mperumal@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E484C21F9BD0 for <mmusic@ietfa.amsl.com>; Thu, 4 Jul 2013 22:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level:
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uuAQQQYNZwH for <mmusic@ietfa.amsl.com>; Thu, 4 Jul 2013 22:24:43 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCA121F8BCE for <mmusic@ietf.org>; Thu, 4 Jul 2013 22:24:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9601; q=dns/txt; s=iport; t=1373001883; x=1374211483; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0SvOr4FbepQUmIjtE+9n+5mvAQNrw8oWYKQoOwYZ4oI=; b=l7ySWKAucD+QfdWUkZGsymOTjFZA3d0QpCXaFTbeLHpsTylA07di/5d9 S5vFEsqvA/k5xDaAyv9BJ5uFvaREwgvyVnZh/dRjnvCMN3AzxJx407YbV yekc6fvy/UdgMwQhv/cCs4+fWbeWidzhAi8f8zkQu5CZLx3sAdN79J1WQ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0FABtX1lGtJXG+/2dsb2JhbABagwkyQwbAOX8WdIIjAQEBBIEFBgEIEQQBAQsdORQJCQEEARIIAYgGBwWqUI49jikQgQEGLQcEgn5pA4hrmwGFIoMRgXE3
X-IronPort-AV: E=Sophos;i="4.87,1000,1363132800"; d="scan'208";a="231246929"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2013 05:24:40 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r655Od46010836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 05:24:39 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 00:24:39 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "aurelien.sollaud@orange.com" <aurelien.sollaud@orange.com>, Parthasarathi R <partha@parthasarathi.co.in>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: comments on draft-ietf-mmusic-sdp-g723-g729-03
Thread-Index: Ac55Nkbs04s/rq3fQliC5Ns4xH13+gAAQt0wAAIOmyA=
Date: Fri, 05 Jul 2013 05:24:39 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE224180B1A@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.163.211.93]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g729-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 05:24:49 -0000
Fixed the subject to make it easier to search.. Muthu |-----Original Message----- |From: Muthu Arul Mozhi Perumal (mperumal) |Sent: Friday, July 05, 2013 10:42 AM |To: 'aurelien.sollaud@orange.com'; Parthasarathi R; mmusic@ietf.org |Subject: RE: RE:` | |Hi Aurelien, | |Partha and I had a discussion. Please see inline for [Muthu]: | ||-----Original Message----- ||From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] ||Sent: Thursday, July 04, 2013 3:44 PM ||To: Parthasarathi R; mmusic@ietf.org; Muthu Arul Mozhi Perumal (mperumal) ||Subject: RE:` || ||Hello || ||My answers inline ||(I removed the agreed parts) || ||Aurelien || ||-----Message d'origine----- ||De : Parthasarathi R [mailto:partha@parthasarathi.co.in] ||Envoyé : mercredi 3 juillet 2013 19:29 ||À : SOLLAUD Aurelien OLNC/OLN; mmusic@ietf.org; mperumal@cisco.com Objet : RE: comments on draft- |ietf- ||mmusic-sdp-g723-g729-03 || ||Hi Aurelien, || ||Sorry for the delay response. Thanks for the review comments. || ||Please read inline. || ||Thanks ||Partha || ||> -----Original Message----- ||> From: aurelien.sollaud@orange.com [mailto:aurelien.sollaud@orange.com] ||> Sent: Thursday, June 27, 2013 1:52 PM ||> To: mmusic@ietf.org; mperumal@cisco.com; partha@parthasarathi.co.in ||> Subject: comments on draft-ietf-mmusic-sdp-g723-g729-03 ||> || || (snip) ||> ||> ||> ** Section 3.1 ||> ||> 2) ||> After the first paragraph, I suggest to insert the new paragraph below: ||> ||> ---NEW ||> The Annex A of the codec concerns both sending and receiving, so both ||> sides of a bi-directional session MUST have the same setting. If one ||> party indicates that it does not support Annex A, Annex A must be ||> deactivated both ways. ||> ----- ||> That defines the general rationale of the following paragraphs. ||> ||<Partha> I agree with that it is the objective of this O/A requirement but how this statement ||qualifies for normative statement is not clear. From the offerer perspective, there is no control on ||same setting in both sides. In case you look at the combine requirements of this draft, this object |is ||met. ||</Partha> || ||[Aurelien] OK. I agree you can turn "MUST" into "must". I think this new paragraph helps anyway. | |[Muthu] Agree it helps. However, the text could be reworded to make it crisper: | | The objective of the below statements is to make sure that if the offerer | or answerer indicates it does not support Annex A, Annex A is not used. | |Does it sound good? | || || ||> ||> 3) ||> ----- ||> When the offer has G723 with annexa=no then the answer MUST NOT have ||> annexa=yes for G723. Thus the annexa parameter can be turned off by ||> the answerer, but cannot be turned on. ||> ----- ||> I don't think this new requirement is needed. ||> Anyway implementation that will not implement this RFC-to-be will not ||> comply with it. ||> ||<Partha> As per based G723 RFC, it is expected for all the implementation to support annexa. This ||issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current/msg11165.html </Partha> || ||[Aurelien] Yes I agree all implementations support annexa. What I called the RFC-to-be is the |document ||draft-ietf-mmusic-sdp-g723-g729. My comment was that previous implementations will not comply with ||this "MUST NOT". A warning should be written on this. The receiver of the SDP should be tolerant and ||ready to receive SDP not compliant with this new requirement, without breaking. ||I the offer has annexa=no and the answer (of an old implementation) has annexa=yes, Annex A must not ||be used. ||It is the same kind of thing you describe later about the case where the offer has annexa=no and the ||answer has no annexa at all. Annex A must not be used. | |[Muthu] Agree. I think both this paragraph and the later paragraph (that describes the case where the |offer has annexa=no and the answer has no annexa at all) can be combined together: | | When the offer has G723 with annexa=no, after the offer/answer | completion the offerer and answerer MUST proceed as if G723 is | negotiated with annexa=no. | | When the offer has G723 with annexa=no, the reason for not mandating | that the answer MUST have annexa=no for G723 is that there are there | implementations that omit the annexa parameter in answer and expect | the least common denominator to be used. | |Does it sound good? | || || || (snip) ||> ||> ** Section 3.2 ||> ||> 5) ||> After the first two paragraphs, I suggest to insert the new paragraph ||> below: ||> ||> ---NEW ||> The Annex B of the codec concerns both sending and receiving, so both ||> sides of a bi-directional session MUST have the same setting. If one ||> party indicates that it does not support Annex B, Annex B must be ||> deactivated both ways. ||> ----- ||> That defines the general rationale of the following paragraphs. ||> || ||<Partha> Same as comment 2 reply. I agree with that it is the objective of this O/A requirement but ||how this statement qualifies for normative statement is not clear. From the offerer perspective, |there ||is no control on same setting in both sides. In case you look at the combine requirements of this ||draft, this object is met. </Partha> || ||[Aurelien] same as comment 2, you can keep it informative and turn the "MUST" into "must". | |[Muthu] Same as above: | | The objective of the below statements is to make sure that if the offerer | or answerer indicates it does not support Annex B, Annex B is not used. | |Does it sound good? | || || ||> ||> 6) ||> ----- ||> When the offer or answer has G729 and the annexb parameter is ||> absent, ||> it MUST be considered as if the offer or answer has G729 with ||> annexb=yes. ||> ----- ||> This paragraph is redundant with what is said before. ||> Remove it. ||> ||> || ||<Partha> As per based G729 RFC, it is expected for all the implementation to support annexb. This ||issue is discussed in http://www.ietf.org/mail-archive/web/mmusic/current/msg11165.html </Partha> || ||[Aurelien] You did not understand me. I said to remove the paragraph because it is an exact |repetition ||of text. I quote the whole text: || ||---- || When the offer or answer has G729 and the annexb parameter is absent, || the offerer or answerer knows that it has implied the default || "annexb=yes". This is because the annexb attribute is part of the || original registration of audio/G729 [RFC4856]. All implementations || that support G729 understand the annexb attribute. Hence, this case || MUST be considered as if the offer or answer has G729 with || annexb=yes. || || When the offer or answer has G729 and the annexb parameter is absent, || it MUST be considered as if the offer or answer has G729 with || annexb=yes. ||---- || ||As you can see, the second paragraph says the exact same thing as the first one. | |[Muthu] Agree, the second paragraph is redundant. | || || ||> 7) ||> ----- ||> When the offer has G729 with annexb=no then the answer MUST NOT have ||> annexb=yes for G729. Thus the annexb parameter can be turned off by ||> the answerer, but cannot be turned on. ||> ----- ||> I don't think this new requirement is needed. ||> For the same reason as for G723 ||> ||<Partha> Same reply as comment 3. As per based G729 RFC, it is expected for all the implementation to ||support annexb. This issue is discussed in http://www.ietf.org/mail- ||archive/web/mmusic/current/msg11165.html </Partha> || ||[Aurelien] Same as comment 3, I suggest adding a warning on previous implementation that may not ||comply with this new requirement. | |[Muthu] Same as above: | | When the offer has G729 with annexb=no, after the offer/answer | completion the offerer and answerer MUST proceed as if G729 is | negotiated with annexb=no. | | When the offer has G729 with annexb=no, the reason for not mandating | that the answer MUST have annexb=no for G729 is that there are there | implementations that omit the annexb parameter in answer and expect | the least common denominator to be used. | |Does it sound good? | |Thanks for your inputs, | |Muthu | || || (snip) || ||_____________________________________________________________________________________________________ |_ ||___________________ || ||Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ||ne doivent donc ||pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, ||veuillez le signaler ||a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant ||susceptibles d'alteration, ||Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. || ||This message and its attachments may contain confidential or privileged information that may be ||protected by law; ||they should not be distributed, used or copied without authorisation. ||If you have received this email in error, please notify the sender and delete this message and its ||attachments. ||As emails may be altered, Orange is not liable for messages that have been modified, changed or ||falsified. ||Thank you.
- [MMUSIC] comments on draft-ietf-mmusic-sdp-g723-g… aurelien.sollaud
- Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g7… Parthasarathi R
- Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g7… aurelien.sollaud
- Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g7… Muthu Arul Mozhi Perumal (mperumal)
- Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-g7… aurelien.sollaud