Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

"Fang, Zheng" <zfang@qualcomm.com> Tue, 04 October 2011 23:38 UTC

Return-Path: <zfang@qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A621F8B53 for <payload@ietfa.amsl.com>; Tue, 4 Oct 2011 16:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.998
X-Spam-Level:
X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 RGfZPEeuprCu for <payload@ietfa.amsl.com>; Tue, 4 Oct 2011 16:38:11 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7853F21F8B50 for <payload@ietf.org>; Tue, 4 Oct 2011 16:38:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=zfang@qualcomm.com; q=dns/txt; s=qcdkim; t=1317771678; x=1349307678; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Fang,=20Zheng"=20<zfang@qualcomm.com>|To:=20Ron i=20Even=20<Even.roni@huawei.com>,=20"payload@ietf.org" =20<payload@ietf.org>|CC:=20"Fang,=20Zheng"=20<zfang@qual comm.com>|Subject:=20RE:=20[payload]=20WGLC=20on=20draft- ietf-avt-rtp-evrc-nw-03|Thread-Topic:=20[payload]=20WGLC =20on=20draft-ietf-avt-rtp-evrc-nw-03|Thread-Index:=20Acx dnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4AAILpqQAAPxDrg |Date:=20Tue,=204=20Oct=202011=2023:39:50=20+0000 |Message-ID:=20<E23CE350F3C94C4A834B4E7069CA5679161C8C@na sanexd01a.na.qualcomm.com>|References:=20<008801cc5d9c$dd 1eb400$975c1c00$%roni@huawei.com>=0D=0A=20<02b501cc663f$a 40278e0$ec076aa0$%roni@huawei.com>=0D=0A=20<E23CE350F3C94 C4A834B4E7069CA567915FD1D@nasanexd01a.na.qualcomm.com>=0D =0A=20<037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com> |In-Reply-To:=20<037101cc82ae$043c8fe0$0cb5afa0$%roni@hua wei.com>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |x-originating-ip:=20[172.30.39.5]|Content-Type:=20multip art/alternative=3B=0D=0A=09boundary=3D"_000_E23CE350F3C94 C4A834B4E7069CA5679161C8Cnasanexd01anaqual_" |MIME-Version:=201.0; bh=XJpFC7BS7GtjbRZLr+Ov+jT/3O4kUMbNxeBpMfxjtBI=; b=EX8zI9z/BX+WQMUBQdq8UIUhXHbkkqkbN+BOYRJ/7A4zTVwVSV1LFysD HUjhu3iWThc1m1bkvRf8jyobdkPWPC4wT0D0+uOzU9yW3uHgw2BMBOgxq YVkB5i6loRNa8cSMOBWJqR6yq8Gx/ZVVLVt6DAd05p5kYIAZU9bLnKdT8 4=;
X-IronPort-AV: E=McAfee;i="5400,1158,6489"; a="124818200"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 04 Oct 2011 16:41:17 -0700
X-IronPort-AV: E=Sophos; i="4.68,485,1312182000"; d="scan'208,217"; a="155920811"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 04 Oct 2011 16:41:17 -0700
Received: from NASANEXHC12.na.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 4 Oct 2011 16:39:52 -0700
Received: from NASANEXD01A.na.qualcomm.com ([fe80::88b1:1c81:4562:8797]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.01.0339.001; Tue, 4 Oct 2011 16:39:51 -0700
From: "Fang, Zheng" <zfang@qualcomm.com>
To: Roni Even <Even.roni@huawei.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03
Thread-Index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4AAILpqQAAPxDrg
Date: Tue, 4 Oct 2011 23:39:50 +0000
Message-ID: <E23CE350F3C94C4A834B4E7069CA5679161C8C@nasanexd01a.na.qualcomm.com>
References: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> <02b501cc663f$a40278e0$ec076aa0$%roni@huawei.com> <E23CE350F3C94C4A834B4E7069CA567915FD1D@nasanexd01a.na.qualcomm.com> <037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com>
In-Reply-To: <037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.30.39.5]
Content-Type: multipart/alternative; boundary="_000_E23CE350F3C94C4A834B4E7069CA5679161C8Cnasanexd01anaqual_"
MIME-Version: 1.0
Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 23:38:15 -0000

Roni,

Thanks for the follow-up comments.

I will modify the change controller to be the Payload working group.

For the last question, regarding declarative use of SDP parameters (copied in below):

1.      In section 13 how is "mode-set-recv" used in declarative SDP since it is a decoder capability and not an encoder one.
             [Zheng] In some two-way conversation scenarios, the traffics can be asymmetric, i.e, incoming and outgoing streams use different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply follows.
             [roni] Declarative is a one way announcement like in SAP for streaming media, so there is no encoder at the other side.

I propose to add the following text to Section 13 "Declarative SDP Considerations":
o  The usage of unidirectional receive only parameters, such as 'mode-set-recv', should be excluded in any declarations, since these parameters are meaningless in one-way streaming applications.
Any comments would be appreciated.
Thanks,
Zheng

From: Roni Even [mailto:Even.roni@huawei.com]
Sent: Tuesday, October 04, 2011 8:55 AM
To: Fang, Zheng; payload@ietf.org
Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananthapadmanabhan (Ananth)
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

Hi Zheng,
See inline
Roni

From: Fang, Zheng [mailto:zfang@qualcomm.com]
Sent: Tuesday, October 04, 2011 2:44 AM
To: Roni Even; payload@ietf.org
Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananthapadmanabhan (Ananth); Fang, Zheng
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

Hi Roni,

Thank you for your comments and suggestions. I updated the draft based on your suggestions. Please find attached the modified text and diff.

I am not sure how to address some of the comments. My answers to those questions are in line. I would appreciate it if you could further comment on it.

I will submit a new version once I resolve all the comments.

Thanks!
Zheng

From: Roni Even [mailto:Even.roni@huawei.com]
Sent: Monday, August 29, 2011 4:35 AM
To: payload@ietf.org
Cc: Fang, Zheng
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

Hi,
I reviewed the draft and have some comments.


2.       It looks to me that this draft updates RFC3558 similar to RFC 4788 and RFC 5188.  It should be referenced in the header and in the text
[Zheng] Although the payload definition of EVRCNW is similar to EVRCWB (RFC 5188), EVRCB (RFC 4788) and EVRC (RFC 3558), the current draft only defines the payload format for EVRCNW only. This is different than that of RFC 5188, which not only defines a new MIME type (EVRC-WB) but also update an existing MIME type (EVRC-B in RFC 4788).

[roni] OK

3.       In section 6 first paragraph why not reference 3788 where ToC is defined.
[Zheng] Reference is added.


4.       In second 9 in the registration template you have sendmode deprecated. This is strange since this registration is a new registration so there is nothing to deprecate . If you want to state that this optional parameter that is used in other EVRC modes is not used, please do it in another section and not in the registration section.
[Zheng] The sendmode descriptions are removed from the registration templates. Instead a comment on it is added in Section 10 "SDP mode attributes for EVRC-NW".


5.       In section 9 in the published specification you mention RFC3558 without a reference. I think that this document need also to be specified since it defines the RTP header and the usage.
[Zheng] References are added.


6.       In section 9 in the author field add your email address
[Zheng] Done.


7.      In section 9  change controller should be " IETF Audio/Video Transport working group delegated from the IESG."
[Zheng] I am a little confused. The changed controller was indeed the same as you mentioned. Can you please point it out in case I miss anything?
[roni} my mistake should be "IETF Payload working group delegated from the IESG"


8.      In section 13 how is "mode-set-recv" used in declarative SDP since it is a decoder capability and not an encoder one.
[Zheng] In some two-way conversation scenarios, the traffics can be asymmetric, i.e, incoming and outgoing streams use different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply follows.
[roni] Declarative is a one way announcement like in SAP for streaming media, so there is no encoder at the other side.

Thanks
Roni Even


From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even
Sent: Thursday, August 18, 2011 2:49 PM
To: payload@ietf.org
Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

Hi,

I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-nw-03<http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-03> , RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec  (EVRC-NW)

The WGLC will end on September 9, 2011
Please review the draft and send comments to the list.


Roni Even
Payload co-chair