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.