From rlb@ipv.sx Mon Apr 1 10:06:15 2013 Return-Path: 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 51DE211E80D1 for ; Mon, 1 Apr 2013 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=1.879, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 VZdtyNvcLZWE for ; Mon, 1 Apr 2013 10:06:14 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id B0A7C11E80AE for ; Mon, 1 Apr 2013 10:06:14 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id n1so2135873oag.23 for ; Mon, 01 Apr 2013 10:06:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:cc:content-type:x-gm-message-state; bh=ljr1eVpnqMduUt0dcxjI2n/N7cT7MqEMZOPkCe4pN6A=; b=d5CRFEJzrXYV9ExmMGgvcjcMU0wxRq3MrBPFArDRUPTmV11XxF13RdBnA7ozfgt0me h5oMX87l9ipTKmxQJA9OnAzEFMI9kZtDZygWlxsNPhYoQBQWBC6/B4S1AbQIroG31gjw HWw+lemSA6gU200fPnVrrdbYelZMhgO6OzKiMrTyqsP+m14B68wAozMUOHx+8sEPwwSa Rl8CbLVnUQeP95GSMfIjlXDmtZ9FQIdesTDBKrlP/Vcd+n+CdrcpgAi/XfsJj2WxVt74 HwiQNs7uyLGzM7hkTgHuiE5DCCv3I8LVMG69vgD2uUwHStzQE/NqmEUnCnIRLuLCOGyC MO0w== MIME-Version: 1.0 X-Received: by 10.60.3.71 with SMTP id a7mr4195473oea.35.1364835974165; Mon, 01 Apr 2013 10:06:14 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Mon, 1 Apr 2013 10:06:13 -0700 (PDT) X-Originating-IP: [192.1.51.16] Date: Mon, 1 Apr 2013 13:06:13 -0400 Message-ID: From: Richard Barnes To: payload@ietf.org Content-Type: multipart/alternative; boundary=e89a8f839d516b1ef204d94fa35c X-Gm-Message-State: ALoCoQnGJwvwNKdZqRFQng8GQNU2FhELvbT8SNq15Q+diSMd+pEuvTcOKo+ExSeeYXiFTGwYfc1m Cc: draft-ietf-avt-rtp-isac@tools.ietf.org Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:06:15 -0000 --e89a8f839d516b1ef204d94fa35c Content-Type: text/plain; charset=ISO-8859-1 Overall, this document looks in pretty good shape. A couple of comments I would like to get resolved before IETF LC: Section 3.1., "Consult source code for details" If the details are only specified in the source code, then the source needs to be a normative reference. And I would prefer to avoid that :) Better to specify here how the BEI and FL fields are encoded. Alternatively, if the codec really does expect a combined BEI/FL field, you could specify such a field here, opaque to the RTP layer. However, you would at least need to say how the recipient knows where this field starts and stops. Section 3.2., "The length of the encoded data is variable and depends on the signal characteristics and the target bit rate." However, there's nothing in this section that tells a recipient how to determine what this length is. Section 3.3., "... verifying the CRC checksum ..." Please specify which CRC function is to be applied, and how the CRC value field is formatted. Section 3.3., "If this value would exceed 255 at encoding..." It sounds like the LEN field is a single octet unsigned integer. Please state that explicitly. Section 9.2. Informative References. Better path to source code would be "webrtc/ modules/audio_coding/codecs/isac" Thanks, --Richard --e89a8f839d516b1ef204d94fa35c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Overall, this document looks in pretty good shape. =A0A couple of comments = I would like to get resolved before IETF LC:

Section 3.1= ., "Consult source code for det= ails"
If the details are only specified in the source code, then the source = needs to be a normative reference. =A0And I would prefer to avoid that =A0:= ) =A0Better to specify here how the BEI and FL fields are encoded. =A0 Alte= rnatively, if the codec really does expect a combined BEI/FL field, you cou= ld specify such a field here, opaque to the RTP layer. =A0However, you woul= d at least need to say how the recipient knows where this field starts and = stops.

Section 3.2., "The length of the encoded data is variable and depends on=A0<= /span>the signal character= istics and the target bit rate."
However, there's nothing in this section that tells a recipient ho= w to determine what this length is. =A0

Section 3.= 3., "...=A0verifying = the CRC checksum ..."
Please specify which CRC function is to be applied, and how the CRC va= lue field is formatted.

Section 3.3., "If this value would exceed 255 a= t encoding..."
It sounds like the LEN field is a single octet unsigned integer. =A0Pl= ease state that explicitly.=A0

Section 9.2. Inform= ative References.
Better path to source code would be "webrt= c/modules/audio_coding/cod= ecs/isac"

Thanks,
= --Richard
--e89a8f839d516b1ef204d94fa35c-- From ron.even.tlv@gmail.com Mon Apr 1 11:03:49 2013 Return-Path: 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 3B06D21E804A for ; Mon, 1 Apr 2013 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 8AaUMad5i6Dm for ; Mon, 1 Apr 2013 11:03:48 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 208041F0CE0 for ; Mon, 1 Apr 2013 11:03:47 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b15so1159759eek.35 for ; Mon, 01 Apr 2013 11:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=TdI4hn0qtiVTgLjS05frAUdFGHBV3mxsG5UbJhlKMe4=; b=tmYg3jBXvAJqEm3pwlk8avyU06g+lHXP7ItOxnsRXKKY/PzsOOkuBO+ITs1MBxTMKC OahTkjIleI+kvjwxyM5f89qiomvLuURNCL2BC6i4frdSUhk3RXCv7EbXOu1lGsXdQLYq nxOtLfzRGDSjRpXNuGCaoh/oFaeafjuORBSvrq1VDVSB0V25aS2k8Q6gJksSbP7wfJ2b i/mDzVa7NI0r+HBmoX0P2+f0duIKKX3pvJXlDZCSGOlBsOoBI+5Nx2Dl1K5R99s/A6P9 xa8nyveYlDGr4SWV0M8YmktZbnRKB94WnlgF1gIFIlNUMYsHdcxLX/Olu2B7b384MQ+O cJBA== X-Received: by 10.14.3.133 with SMTP id 5mr39686022eeh.43.1364839427216; Mon, 01 Apr 2013 11:03:47 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id r4sm22396655eeo.12.2013.04.01.11.03.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 11:03:46 -0700 (PDT) From: "Roni Even" To: "'Richard Barnes'" , References: In-Reply-To: Date: Mon, 1 Apr 2013 21:03:14 +0300 Message-ID: <062e01ce2f03$33956840$9ac038c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_062F_01CE2F1C.58E38AA0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQNII6D3+HHGXem04NFCDjzvpOKjf5XNvZnw Content-Language: en-us Cc: draft-ietf-avt-rtp-isac@tools.ietf.org Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:03:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_062F_01CE2F1C.58E38AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Richard, As a general comment, for RTP payload specifications we do not require a normative reference to the codec. We only require enough information that will allow an RTP receiver to parse the information and move it to the decoder that can be a black box. This allows us to publish RTP payload specification also for codecs whose specifications are not publically available. Still in this case more information can be supplied. As for the comments the authors should address them Roni Even From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes Sent: 01 April, 2013 8:06 PM To: payload@ietf.org Cc: draft-ietf-avt-rtp-isac@tools.ietf.org Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 Overall, this document looks in pretty good shape. A couple of comments I would like to get resolved before IETF LC: Section 3.1., "Consult source code for details" If the details are only specified in the source code, then the source needs to be a normative reference. And I would prefer to avoid that :) Better to specify here how the BEI and FL fields are encoded. Alternatively, if the codec really does expect a combined BEI/FL field, you could specify such a field here, opaque to the RTP layer. However, you would at least need to say how the recipient knows where this field starts and stops. Section 3.2., "The length of the encoded data is variable and depends on the signal characteristics and the target bit rate." However, there's nothing in this section that tells a recipient how to determine what this length is. Section 3.3., "... verifying the CRC checksum ..." Please specify which CRC function is to be applied, and how the CRC value field is formatted. Section 3.3., "If this value would exceed 255 at encoding..." It sounds like the LEN field is a single octet unsigned integer. Please state that explicitly. Section 9.2. Informative References. Better path to source code would be "webrtc/modules/audio_coding/codecs/isac" Thanks, --Richard ------=_NextPart_000_062F_01CE2F1C.58E38AA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

As a general comment, for RTP payload specifications we do not = require a normative reference to the codec. We only require enough = information that will allow an RTP receiver to parse the information and = move it to the decoder that can be a black box. This allows us to = publish RTP payload specification also for codecs whose specifications = are not publically available.

Still in this case more information can be = supplied.

 

As for the comments the authors should address = them

 

Roni Even

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Richard Barnes
Sent: 01 April, 2013 8:06 = PM
To: payload@ietf.org
Cc: = draft-ietf-avt-rtp-isac@tools.ietf.org
Subject: [payload] AD = Evaluation: draft-ietf-avt-rtp-isac-04

 

Overall, = this document looks in pretty good shape.  A couple of comments I = would like to get resolved before IETF LC:

 

Section 3.1., "Consult source code for = details"

If the = details are only specified in the source code, then the source needs to = be a normative reference.  And I would prefer to avoid that =  :)  Better to specify here how the BEI and FL fields are = encoded.   Alternatively, if the codec really does expect a = combined BEI/FL field, you could specify such a field here, opaque to = the RTP layer.  However, you would at least need to say how the = recipient knows where this field starts and = stops.

 

Section 3.2., "The length of the encoded data is variable = and depends on the signal characteristics and the target bit = rate."

However, there's nothing in this section that tells a = recipient how to determine what this length is. =  

 

Section 3.3., "... verifying the CRC checksum = ..."

Please = specify which CRC function is to be applied, and how the CRC value field = is formatted.

 

Section 3.3., "If this value would exceed 255 at = encoding..."

It sounds like the LEN field is a single octet = unsigned integer.  Please state that = explicitly. 

 

Section 9.2. Informative = References.

Better path to = source code would be "webrtc/modules/audio_coding/codecs/isac"<= o:p>

 

Thanks,

--Richard

------=_NextPart_000_062F_01CE2F1C.58E38AA0-- From coverdale@sympatico.ca Mon Apr 1 11:20:18 2013 Return-Path: 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 B5A4E1F0D1C for ; Mon, 1 Apr 2013 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 nQvCP+V8i-fz for ; Mon, 1 Apr 2013 11:20:15 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by ietfa.amsl.com (Postfix) with ESMTP id 147271F0D1B for ; Mon, 1 Apr 2013 11:20:14 -0700 (PDT) Received: from BLU0-SMTP92 ([65.55.111.72]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Apr 2013 11:20:05 -0700 X-EIP: [O5t0Mngzp868VpaEIBJX4iYCNB2m1gbx] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.36.207]) by BLU0-SMTP92.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Apr 2013 11:20:02 -0700 From: Paul Coverdale To: Date: Mon, 1 Apr 2013 14:20:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CE2EE3.FFB46770" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4r3n/+B1SdXLETRwWJfC71TBmvqwAAA4ewAMmfZhA= Content-Language: en-us X-OriginalArrivalTime: 01 Apr 2013 18:20:03.0276 (UTC) FILETIME=[875E28C0:01CE2F05] X-Mailman-Approved-At: Mon, 01 Apr 2013 11:23:12 -0700 Subject: [payload] FW: Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:20:18 -0000 ------=_NextPart_000_0053_01CE2EE3.FFB46770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I also support this as a new work item the Payload WG. Paul Coverdale From: Michael Ramalho (mramalho) Sent: Thursday, March 28, 2013 2:04 PM To: payload@ietf.org Subject: Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload WG, This email requests that the RTP payload format for ITU-T Rec. G.711.0 be a formal work item for the PAYLOAD WG. The G.711.0 RTP payload draft (draft-ramalho-payload-g7110) has been discussed at past IETFs and is listed as a "related document" for the PAYLOAD working group (see: http://datatracker.ietf.org/wg/payload/). The history/chronology of G.711.0 work in the IETF Payload Working Group follows after my signature for those interested. If adopted, a milestone submit date of December 2013 is suggested. Regards, Michael Ramalho >>Chronology of G.711.0 Work in the IETF PAYLOAD WG<< >> IETF 81 Quebec, Canada, July 24-29, 2011 I presented the G.711.0 "Compression Segments" draft at the PAYLOAD meeting held within the AVTEXT timeslot. This draft was a combination of a "G.711-like" RTP payload specification and text describing how G.711.0 could be used as a lossless compression mechanism for "G.711.0 segments" of an end-to-end G.711 session. In discussion that ensued at that meeting it was decided that this draft should be split into two drafts: Draft 1: "G.711.0 RTP Payload Format" draft (targeted as standards track RFC), and Draft 2: "G.711.0 Use Cases" draft (targeted as informational RFC). Soon after IETF 81 this was accomplished by the following drafts: draft-ramalho-payload-g7110-01.txt (G.711.0 RTP payload format) and draft-ramalho-g7110-segments-00.txt (G.711.0 "use cases"). As the G.711.0 payload draft is nearly identical to the G.711 RTP payload specification, there was little debate on the mailing lists about it outside of the storage mode definition (the G.711 RTP payload specification did not have a storage mode defined). >>IETF 83 Paris, France, March 27, 2012 I presented: draft-ramalho-g7110-segments-00 during the PAYLOAD segment inside of the AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/slides-83-avtext-6.pdf ). I did not present on the G.711.0 payload format draft, as the only issue being debated on the list for this draft was the storage mode - and the storage mode agreements were converging to a solution on the mailing list. I renewed the G.711.0 RTP payload specification with a new version (draft-ramalho-payload-g7110-02.txt) which captured the email discussions on the storage mode issues. I let the use case draft (draft-ramalho-g7110-segments-00) expire due to lack of interest on the mailing list. I believe interest will revive when the payload specification is complete. >>Summary: This email requests the G.711.0 RTP Payload Format be a formal working group item with an associated milestone (December 2013 suggested). ------=_NextPart_000_0053_01CE2EE3.FFB46770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also support this as a new work item the Payload = WG.

 

Paul = Coverdale

From:= = Michael Ramalho (mramalho)
Sent: Thursday, March 28, 2013 = 2:04 PM
To: payload@ietf.org
Subject: = Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work = item

 

Ali Begen, = Roni Even (PAYLOAD WG Chairs) and Payload WG,

 

This email = requests that the RTP payload format for ITU-T Rec. G.711.0 be a formal = work item for the PAYLOAD WG.

 

The G.711.0 = RTP payload draft (draft-ramalho-payload-g7110) has been discussed at = past IETFs and is listed as a “related document” for the = PAYLOAD working group (see: http://datatracker.ietf.= org/wg/payload/).

 

The = history/chronology of G.711.0 work in the IETF Payload Working Group = follows after my signature for those interested.

 

If adopted, = a milestone submit date of December 2013 is suggested.

 

Regards,

 

Michael = Ramalho

 

>>Chronology of G.711.0 Work in the IETF PAYLOAD = WG<<

 

>> IETF 81 Quebec, Canada, July 24-29, = 2011

 

I presented the G.711.0 “Compression = Segments” draft at the PAYLOAD meeting held within the AVTEXT = timeslot. This draft was a combination of a “G.711-like” RTP = payload specification and text describing how G.711.0 could be used as a = lossless compression mechanism for “G.711.0 segments” of an = end-to-end G.711 session.

 

In = discussion that ensued at that meeting it was decided that this draft = should be split into two drafts:

 

Draft 1: = “G.711.0 RTP Payload Format” draft (targeted as standards = track RFC), and

Draft 2: = “G.711.0 Use Cases” draft (targeted as informational = RFC).

 

Soon after IETF 81 this was accomplished by the = following drafts: draft-ramalho-payload-g7110-01.txt (G.711.0 RTP = payload format) and draft-ramalho-g7110-segments-00.txt (G.711.0 = “use cases”).

 

As the = G.711.0 payload draft is nearly identical to the G.711 RTP payload = specification, there was little debate on the mailing lists about it = outside of the storage mode definition (the G.711 RTP payload = specification did not have a storage mode defined).

 

>>IETF = 83 Paris, France, March 27, 2012

 

I presented: = draft-ramalho-g7110-segments-00 during the PAYLOAD segment inside of the = AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/slides-83-avtext-6.pdf = ).

 

I did not present on the G.711.0 payload format draft, = as the only issue being debated on the list for this draft was the = storage mode – and the storage mode agreements were converging to = a solution on the mailing list.

 

I renewed = the G.711.0 RTP payload specification with a new version = (draft-ramalho-payload-g7110-02.txt) which captured the email = discussions on the storage mode issues.

 

I let the = use case draft (draft-ramalho-g7110-segments-00) expire due to lack of = interest on the mailing list. I believe interest will revive when the = payload specification is complete.

 

>>Summary: This email requests the G.711.0 RTP = Payload Format be a formal working group item with an associated = milestone (December 2013 suggested).

------=_NextPart_000_0053_01CE2EE3.FFB46770-- From abegen@cisco.com Mon Apr 1 11:29:56 2013 Return-Path: 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 CA8FF21E8099 for ; Mon, 1 Apr 2013 11:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QhNGCTaXj+0I for ; Mon, 1 Apr 2013 11:29:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8B521E804A for ; Mon, 1 Apr 2013 11:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15185; q=dns/txt; s=iport; t=1364840995; x=1366050595; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=RnWg5H9yjd2b2Bov+Z4BFSHeQZabG88zaSnilvi97ew=; b=mOOPFi/+6aUy77CDrajbGd56UcdnEnu3fwhULB8f62FtTI16/KHxLV6A 4kGJuk+qzQx4P0/K+kGhBVWlvZAJUxIuNzfVlq4gNeA4yQGgUIwaG4HCJ gUfNdUnNwJk1aU0jW6zvEYzKeT/tlfo1FgYetHjWm8xDn33+PpkcYnOPV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoGAG++WVGtJXG+/2dsb2JhbABDgkMjVYMgqkCJMYg9DW8WdIIfAQEBAgEBIwo5CB0BCBEDAQILHQMCBDAUCQgBAQQBEggBEodzBgELrkGSD4kXhE0LFnsgBhKCLTJhA5gKj2yBVYE2gWsIFx4 X-IronPort-AV: E=Sophos;i="4.87,387,1363132800"; d="scan'208,217";a="193520531" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 01 Apr 2013 18:29:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r31ITnR8008707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Apr 2013 18:29:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 1 Apr 2013 13:29:49 -0500 From: "Ali C. Begen (abegen)" To: "Michael Ramalho (mramalho)" , "payload@ietf.org" Thread-Topic: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item Thread-Index: Ac4r3n/+B1SdXLETRwWJfC71TBmvqwDa3DYA Date: Mon, 1 Apr 2013 18:28:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.99.18] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940CF7FD3Exmbalnx01ciscoc_" MIME-Version: 1.0 Subject: Re: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:29:56 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940CF7FD3Exmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBhbHJlYWR5IHNlZW4gcXVpdGUgYSBudW1iZXIgb2Ygc3VwcG9ydGluZyBlbWFpbHMg Zm9yIHRoaXMgZHJhZnQuIFBsZWFzZSBzcGVhayB1cCB0aWxsIHRoaXMgRnJpZGF5IGlmIHlvdSBo YXZlIGFueSBvYmplY3Rpb25zIGZvciBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQotYWNiZWdl biwgY28tY2hhaXINCg0KDQpGcm9tOiAiTWljaGFlbCBSYW1hbGhvIChtcmFtYWxobykiIDxtcmFt YWxob0BjaXNjby5jb208bWFpbHRvOm1yYW1hbGhvQGNpc2NvLmNvbT4+DQpEYXRlOiBUaHVyc2Rh eSwgTWFyY2ggMjgsIDIwMTMgOTowNCBQTQ0KVG86ICJwYXlsb2FkQGlldGYub3JnPG1haWx0bzpw YXlsb2FkQGlldGYub3JnPiIgPHBheWxvYWRAaWV0Zi5vcmc8bWFpbHRvOnBheWxvYWRAaWV0Zi5v cmc+Pg0KU3ViamVjdDogW3BheWxvYWRdIFJlcXVlc3QgZm9yIEcuNzExIFJUUCBQYXlsb2FkIEZv cm1hdCB0byBiZSBhZG9wdGVkIGFzIGEgUEFZTE9BRCB3b3JrIGl0ZW0NCg0KQWxpIEJlZ2VuLCBS b25pIEV2ZW4gKFBBWUxPQUQgV0cgQ2hhaXJzKSBhbmQgUGF5bG9hZCBXRywNCg0KVGhpcyBlbWFp bCByZXF1ZXN0cyB0aGF0IHRoZSBSVFAgcGF5bG9hZCBmb3JtYXQgZm9yIElUVS1UIFJlYy4gRy43 MTEuMCBiZSBhIGZvcm1hbCB3b3JrIGl0ZW0gZm9yIHRoZSBQQVlMT0FEIFdHLg0KDQpUaGUgRy43 MTEuMCBSVFAgcGF5bG9hZCBkcmFmdCAoZHJhZnQtcmFtYWxoby1wYXlsb2FkLWc3MTEwKSBoYXMg YmVlbiBkaXNjdXNzZWQgYXQgcGFzdCBJRVRGcyBhbmQgaXMgbGlzdGVkIGFzIGEg4oCccmVsYXRl ZCBkb2N1bWVudOKAnSBmb3IgdGhlIFBBWUxPQUQgd29ya2luZyBncm91cCAoc2VlOiBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvcGF5bG9hZC8pLg0KDQpUaGUgaGlzdG9yeS9jaHJvbm9s b2d5IG9mIEcuNzExLjAgd29yayBpbiB0aGUgSUVURiBQYXlsb2FkIFdvcmtpbmcgR3JvdXAgZm9s bG93cyBhZnRlciBteSBzaWduYXR1cmUgZm9yIHRob3NlIGludGVyZXN0ZWQuDQoNCklmIGFkb3B0 ZWQsIGEgbWlsZXN0b25lIHN1Ym1pdCBkYXRlIG9mIERlY2VtYmVyIDIwMTMgaXMgc3VnZ2VzdGVk Lg0KDQpSZWdhcmRzLA0KDQpNaWNoYWVsIFJhbWFsaG8NCg0KPj5DaHJvbm9sb2d5IG9mIEcuNzEx LjAgV29yayBpbiB0aGUgSUVURiBQQVlMT0FEIFdHPDwNCg0KPj4gSUVURiA4MSBRdWViZWMsIENh bmFkYSwgSnVseSAyNC0yOSwgMjAxMQ0KDQpJIHByZXNlbnRlZCB0aGUgRy43MTEuMCDigJxDb21w cmVzc2lvbiBTZWdtZW50c+KAnSBkcmFmdCBhdCB0aGUgUEFZTE9BRCBtZWV0aW5nIGhlbGQgd2l0 aGluIHRoZSBBVlRFWFQgdGltZXNsb3QuIFRoaXMgZHJhZnQgd2FzIGEgY29tYmluYXRpb24gb2Yg YSDigJxHLjcxMS1saWtl4oCdIFJUUCBwYXlsb2FkIHNwZWNpZmljYXRpb24gYW5kIHRleHQgZGVz Y3JpYmluZyBob3cgRy43MTEuMCBjb3VsZCBiZSB1c2VkIGFzIGEgbG9zc2xlc3MgY29tcHJlc3Np b24gbWVjaGFuaXNtIGZvciDigJxHLjcxMS4wIHNlZ21lbnRz4oCdIG9mIGFuIGVuZC10by1lbmQg Ry43MTEgc2Vzc2lvbi4NCg0KSW4gZGlzY3Vzc2lvbiB0aGF0IGVuc3VlZCBhdCB0aGF0IG1lZXRp bmcgaXQgd2FzIGRlY2lkZWQgdGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBiZSBzcGxpdCBpbnRvIHR3 byBkcmFmdHM6DQoNCkRyYWZ0IDE6IOKAnEcuNzExLjAgUlRQIFBheWxvYWQgRm9ybWF04oCdIGRy YWZ0ICh0YXJnZXRlZCBhcyBzdGFuZGFyZHMgdHJhY2sgUkZDKSwgYW5kDQpEcmFmdCAyOiDigJxH LjcxMS4wIFVzZSBDYXNlc+KAnSBkcmFmdCAodGFyZ2V0ZWQgYXMgaW5mb3JtYXRpb25hbCBSRkMp Lg0KDQpTb29uIGFmdGVyIElFVEYgODEgdGhpcyB3YXMgYWNjb21wbGlzaGVkIGJ5IHRoZSBmb2xs b3dpbmcgZHJhZnRzOiBkcmFmdC1yYW1hbGhvLXBheWxvYWQtZzcxMTAtMDEudHh0IChHLjcxMS4w IFJUUCBwYXlsb2FkIGZvcm1hdCkgYW5kIGRyYWZ0LXJhbWFsaG8tZzcxMTAtc2VnbWVudHMtMDAu dHh0IChHLjcxMS4wIOKAnHVzZSBjYXNlc+KAnSkuDQoNCkFzIHRoZSBHLjcxMS4wIHBheWxvYWQg ZHJhZnQgaXMgbmVhcmx5IGlkZW50aWNhbCB0byB0aGUgRy43MTEgUlRQIHBheWxvYWQgc3BlY2lm aWNhdGlvbiwgdGhlcmUgd2FzIGxpdHRsZSBkZWJhdGUgb24gdGhlIG1haWxpbmcgbGlzdHMgYWJv dXQgaXQgb3V0c2lkZSBvZiB0aGUgc3RvcmFnZSBtb2RlIGRlZmluaXRpb24gKHRoZSBHLjcxMSBS VFAgcGF5bG9hZCBzcGVjaWZpY2F0aW9uIGRpZCBub3QgaGF2ZSBhIHN0b3JhZ2UgbW9kZSBkZWZp bmVkKS4NCg0KPj5JRVRGIDgzIFBhcmlzLCBGcmFuY2UsIE1hcmNoIDI3LCAyMDEyDQoNCkkgcHJl c2VudGVkOiBkcmFmdC1yYW1hbGhvLWc3MTEwLXNlZ21lbnRzLTAwIGR1cmluZyB0aGUgUEFZTE9B RCBzZWdtZW50IGluc2lkZSBvZiB0aGUgQVZURVhUIG1lZXRpbmcgc2xvdCAoaHR0cDovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xpZGVzLTgzLWF2dGV4dC02LnBkZiApLg0K DQpJIGRpZCBub3QgcHJlc2VudCBvbiB0aGUgRy43MTEuMCBwYXlsb2FkIGZvcm1hdCBkcmFmdCwg YXMgdGhlIG9ubHkgaXNzdWUgYmVpbmcgZGViYXRlZCBvbiB0aGUgbGlzdCBmb3IgdGhpcyBkcmFm dCB3YXMgdGhlIHN0b3JhZ2UgbW9kZSDigJMgYW5kIHRoZSBzdG9yYWdlIG1vZGUgYWdyZWVtZW50 cyB3ZXJlIGNvbnZlcmdpbmcgdG8gYSBzb2x1dGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpJ IHJlbmV3ZWQgdGhlIEcuNzExLjAgUlRQIHBheWxvYWQgc3BlY2lmaWNhdGlvbiB3aXRoIGEgbmV3 IHZlcnNpb24gKGRyYWZ0LXJhbWFsaG8tcGF5bG9hZC1nNzExMC0wMi50eHQpIHdoaWNoIGNhcHR1 cmVkIHRoZSBlbWFpbCBkaXNjdXNzaW9ucyBvbiB0aGUgc3RvcmFnZSBtb2RlIGlzc3Vlcy4NCg0K SSBsZXQgdGhlIHVzZSBjYXNlIGRyYWZ0IChkcmFmdC1yYW1hbGhvLWc3MTEwLXNlZ21lbnRzLTAw KSBleHBpcmUgZHVlIHRvIGxhY2sgb2YgaW50ZXJlc3Qgb24gdGhlIG1haWxpbmcgbGlzdC4gSSBi ZWxpZXZlIGludGVyZXN0IHdpbGwgcmV2aXZlIHdoZW4gdGhlIHBheWxvYWQgc3BlY2lmaWNhdGlv biBpcyBjb21wbGV0ZS4NCg0KPj5TdW1tYXJ5OiBUaGlzIGVtYWlsIHJlcXVlc3RzIHRoZSBHLjcx MS4wIFJUUCBQYXlsb2FkIEZvcm1hdCBiZSBhIGZvcm1hbCB3b3JraW5nIGdyb3VwIGl0ZW0gd2l0 aCBhbiBhc3NvY2lhdGVkIG1pbGVzdG9uZSAoRGVjZW1iZXIgMjAxMyBzdWdnZXN0ZWQpLg0KDQoN Cg== --_000_C15918F2FCDA0243A7C919DA7C4BE9940CF7FD3Exmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PldlIGhhdmUg YWxyZWFkeSBzZWVuIHF1aXRlIGEgbnVtYmVyIG9mIHN1cHBvcnRpbmcgZW1haWxzIGZvciB0aGlz IGRyYWZ0LiBQbGVhc2Ugc3BlYWsgdXAgdGlsbCB0aGlzIEZyaWRheSBpZiB5b3UgaGF2ZSBhbnkg b2JqZWN0aW9ucyBmb3IgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pi1hY2JlZ2VuLCBjby1jaGFpcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246 bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVG VDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQ QURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7TWljaGFlbCBSYW1hbGhvIChtcmFtYWxo bykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcmFtYWxob0BjaXNjby5jb20iPm1yYW1hbGhv QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRh dGU6IDwvc3Bhbj5UaHVyc2RheSwgTWFyY2ggMjgsIDIwMTMgOTowNCBQTTxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpw YXlsb2FkQGlldGYub3JnIj5wYXlsb2FkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBheWxvYWRAaWV0Zi5vcmciPnBheWxvYWRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W3BheWxvYWRdIFJl cXVlc3QgZm9yIEcuNzExIFJUUCBQYXlsb2FkIEZvcm1hdCB0byBiZSBhZG9wdGVkIGFzIGEgUEFZ TE9BRCB3b3JrIGl0ZW08YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1M RUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4N CjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29m dCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFsaSBCZWdlbiwgUm9uaSBFdmVuIChQQVlMT0FEIFdHIENoYWlycykg YW5kIFBheWxvYWQgV0csPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZW1haWwgcmVxdWVz dHMgdGhhdCB0aGUgUlRQIHBheWxvYWQgZm9ybWF0IGZvciBJVFUtVCBSZWMuIEcuNzExLjAgYmUg YSBmb3JtYWwgd29yayBpdGVtIGZvciB0aGUgUEFZTE9BRCBXRy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIEcuNzExLjAgUlRQIHBheWxvYWQgZHJhZnQgKGRyYWZ0LXJhbWFsaG8tcGF5bG9h ZC1nNzExMCkgaGFzIGJlZW4gZGlzY3Vzc2VkIGF0IHBhc3QgSUVURnMgYW5kIGlzIGxpc3RlZCBh cyBhIOKAnHJlbGF0ZWQgZG9jdW1lbnTigJ0gZm9yIHRoZSBQQVlMT0FEIHdvcmtpbmcgZ3JvdXAg KHNlZToNCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9wYXlsb2FkLyI+ aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3BheWxvYWQvPC9hPikuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBoaXN0b3J5L2Nocm9ub2xvZ3kgb2YgRy43MTEuMCB3b3JrIGluIHRo ZSBJRVRGIFBheWxvYWQgV29ya2luZyBHcm91cCBmb2xsb3dzIGFmdGVyIG15IHNpZ25hdHVyZSBm b3IgdGhvc2UgaW50ZXJlc3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgYWRvcHRlZCwg YSBtaWxlc3RvbmUgc3VibWl0IGRhdGUgb2YgRGVjZW1iZXIgMjAxMyBpcyBzdWdnZXN0ZWQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1p Y2hhZWwgUmFtYWxobzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0O0Nocm9ub2xvZ3kg b2YgRy43MTEuMCBXb3JrIGluIHRoZSBJRVRGIFBBWUxPQUQgV0cmbHQ7Jmx0OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBJRVRGIDgxIFF1ZWJlYywgQ2FuYWRhLCBKdWx5IDI0LTI5 LCAyMDExPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcHJlc2VudGVkIHRoZSBHLjcxMS4wIOKA nENvbXByZXNzaW9uIFNlZ21lbnRz4oCdIGRyYWZ0IGF0IHRoZSBQQVlMT0FEIG1lZXRpbmcgaGVs ZCB3aXRoaW4gdGhlIEFWVEVYVCB0aW1lc2xvdC4gVGhpcyBkcmFmdCB3YXMgYSBjb21iaW5hdGlv biBvZiBhIOKAnEcuNzExLWxpa2XigJ0gUlRQIHBheWxvYWQgc3BlY2lmaWNhdGlvbiBhbmQgdGV4 dCBkZXNjcmliaW5nIGhvdyBHLjcxMS4wIGNvdWxkIGJlIHVzZWQgYXMgYSBsb3NzbGVzcw0KIGNv bXByZXNzaW9uIG1lY2hhbmlzbSBmb3Ig4oCcRy43MTEuMCBzZWdtZW50c+KAnSBvZiBhbiBlbmQt dG8tZW5kIEcuNzExIHNlc3Npb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGRpc2N1c3Np b24gdGhhdCBlbnN1ZWQgYXQgdGhhdCBtZWV0aW5nIGl0IHdhcyBkZWNpZGVkIHRoYXQgdGhpcyBk cmFmdCBzaG91bGQgYmUgc3BsaXQgaW50byB0d28gZHJhZnRzOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EcmFmdCAxOiDigJxHLjcxMS4wIFJUUCBQYXlsb2FkIEZvcm1hdOKAnSBkcmFmdCAodGFy Z2V0ZWQgYXMgc3RhbmRhcmRzIHRyYWNrIFJGQyksIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RHJhZnQgMjog4oCcRy43MTEuMCBVc2UgQ2FzZXPigJ0gZHJhZnQgKHRh cmdldGVkIGFzIGluZm9ybWF0aW9uYWwgUkZDKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29v biBhZnRlciBJRVRGIDgxIHRoaXMgd2FzIGFjY29tcGxpc2hlZCBieSB0aGUgZm9sbG93aW5nIGRy YWZ0czogZHJhZnQtcmFtYWxoby1wYXlsb2FkLWc3MTEwLTAxLnR4dCAoRy43MTEuMCBSVFAgcGF5 bG9hZCBmb3JtYXQpIGFuZCBkcmFmdC1yYW1hbGhvLWc3MTEwLXNlZ21lbnRzLTAwLnR4dCAoRy43 MTEuMCDigJx1c2UgY2FzZXPigJ0pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB0aGUgRy43 MTEuMCBwYXlsb2FkIGRyYWZ0IGlzIG5lYXJseSBpZGVudGljYWwgdG8gdGhlIEcuNzExIFJUUCBw YXlsb2FkIHNwZWNpZmljYXRpb24sIHRoZXJlIHdhcyBsaXR0bGUgZGViYXRlIG9uIHRoZSBtYWls aW5nIGxpc3RzIGFib3V0IGl0IG91dHNpZGUgb2YgdGhlIHN0b3JhZ2UgbW9kZSBkZWZpbml0aW9u ICh0aGUgRy43MTEgUlRQIHBheWxvYWQgc3BlY2lmaWNhdGlvbiBkaWQgbm90IGhhdmUgYSBzdG9y YWdlDQogbW9kZSBkZWZpbmVkKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDtJRVRG IDgzIFBhcmlzLCBGcmFuY2UsIE1hcmNoIDI3LCAyMDEyPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgcHJlc2VudGVkOiBkcmFmdC1yYW1hbGhvLWc3MTEwLXNlZ21lbnRzLTAwIGR1cmluZyB0aGUg UEFZTE9BRCBzZWdtZW50IGluc2lkZSBvZiB0aGUgQVZURVhUIG1lZXRpbmcgc2xvdCAoPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xpZGVzLTgzLWF2 dGV4dC02LnBkZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xp ZGVzLTgzLWF2dGV4dC02LnBkZjwvYT4NCiApLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRp ZCBub3QgcHJlc2VudCBvbiB0aGUgRy43MTEuMCBwYXlsb2FkIGZvcm1hdCBkcmFmdCwgYXMgdGhl IG9ubHkgaXNzdWUgYmVpbmcgZGViYXRlZCBvbiB0aGUgbGlzdCBmb3IgdGhpcyBkcmFmdCB3YXMg dGhlIHN0b3JhZ2UgbW9kZSDigJMgYW5kIHRoZSBzdG9yYWdlIG1vZGUgYWdyZWVtZW50cyB3ZXJl IGNvbnZlcmdpbmcgdG8gYSBzb2x1dGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHJlbmV3ZWQgdGhlIEcuNzExLjAgUlRQIHBheWxvYWQgc3BlY2lmaWNh dGlvbiB3aXRoIGEgbmV3IHZlcnNpb24gKGRyYWZ0LXJhbWFsaG8tcGF5bG9hZC1nNzExMC0wMi50 eHQpIHdoaWNoIGNhcHR1cmVkIHRoZSBlbWFpbCBkaXNjdXNzaW9ucyBvbiB0aGUgc3RvcmFnZSBt b2RlIGlzc3Vlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBsZXQgdGhlIHVzZSBjYXNlIGRy YWZ0IChkcmFmdC1yYW1hbGhvLWc3MTEwLXNlZ21lbnRzLTAwKSBleHBpcmUgZHVlIHRvIGxhY2sg b2YgaW50ZXJlc3Qgb24gdGhlIG1haWxpbmcgbGlzdC4gSSBiZWxpZXZlIGludGVyZXN0IHdpbGwg cmV2aXZlIHdoZW4gdGhlIHBheWxvYWQgc3BlY2lmaWNhdGlvbiBpcyBjb21wbGV0ZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDtTdW1tYXJ5OiBUaGlzIGVtYWlsIHJlcXVlc3RzIHRo ZSBHLjcxMS4wIFJUUCBQYXlsb2FkIEZvcm1hdCBiZSBhIGZvcm1hbCB3b3JraW5nIGdyb3VwIGl0 ZW0gd2l0aCBhbiBhc3NvY2lhdGVkIG1pbGVzdG9uZSAoRGVjZW1iZXIgMjAxMyBzdWdnZXN0ZWQp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C15918F2FCDA0243A7C919DA7C4BE9940CF7FD3Exmbalnx01ciscoc_-- From rlb@ipv.sx Mon Apr 1 11:46:41 2013 Return-Path: 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 6E17511E80E2 for ; Mon, 1 Apr 2013 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 tTekoqgBRWWg for ; Mon, 1 Apr 2013 11:46:39 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5D7611E80E0 for ; Mon, 1 Apr 2013 11:46:37 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so2284748oag.32 for ; Mon, 01 Apr 2013 11:46:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EMJCfbvopgvAizVgKln5li55JmjUc05kaxGNmlHJhHE=; b=DMo3RrQ8bizEU8nRvqWLJN2uVsXLqkhAJVMgrsVwRXZR9TAlhx17onekgNEgqiNu+c akfcEjJ5Fviw8mdU2L31dzITIoyeK/yCTEusxrRkAb/1xjlp5+l0A9PP7uWHp7mD7lLU SF2SnWaP0RvWjzCsyIZyDwyXTLLbk5nWBjtxftY8nuG6ZUynBT/AEGWpasZ4gYnlk2OZ z7aqSOEaB9alKNjjJt0C1E60F5QqNNbF1Sk4kWfnC7esmPzxLxg9w8QQF/Z1m5Yy6LGg Ea4LzGxxTsn5ECH8qvlZ1jDUQ9qw/eBaJ8bSPKr9NPseIJvnoC9WIe+nA9wc/Pr15oRx JBvw== MIME-Version: 1.0 X-Received: by 10.60.14.104 with SMTP id o8mr4378259oec.127.1364841995549; Mon, 01 Apr 2013 11:46:35 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Mon, 1 Apr 2013 11:46:35 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <062e01ce2f03$33956840$9ac038c0$@gmail.com> References: <062e01ce2f03$33956840$9ac038c0$@gmail.com> Date: Mon, 1 Apr 2013 14:46:35 -0400 Message-ID: From: Richard Barnes To: Roni Even Content-Type: multipart/alternative; boundary=e89a8fb1ef1651d27a04d9510af2 X-Gm-Message-State: ALoCoQlGHnMpe9B6FnmqYp8dLwZVUDS5H5PdQn1id/VoFGWYVPmDgZASh88BU9SYesCCPQOPlVdP Cc: draft-ietf-avt-rtp-isac@tools.ietf.org, payload@ietf.org Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:46:41 -0000 --e89a8fb1ef1651d27a04d9510af2 Content-Type: text/plain; charset=ISO-8859-1 Sure. I didn't mean to imply that we need a reference to the codec, in fact the opposite. I was looking for this document to tell me how to parse out the fields I would feed into the black box of the codec. They describe the fields, but it seems to me that they need more detail in order for people to know how to parse them out of the payload. --Richard On Mon, Apr 1, 2013 at 2:03 PM, Roni Even wrote: > Hi Richard,**** > > As a general comment, for RTP payload specifications we do not require a > normative reference to the codec. We only require enough information that > will allow an RTP receiver to parse the information and move it to the > decoder that can be a black box. This allows us to publish RTP payload > specification also for codecs whose specifications are not publically > available.**** > > Still in this case more information can be supplied.**** > > ** ** > > As for the comments the authors should address them**** > > ** ** > > Roni Even**** > > ** ** > > *From:* payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On > Behalf Of *Richard Barnes > *Sent:* 01 April, 2013 8:06 PM > *To:* payload@ietf.org > *Cc:* draft-ietf-avt-rtp-isac@tools.ietf.org > *Subject:* [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04**** > > ** ** > > Overall, this document looks in pretty good shape. A couple of comments I > would like to get resolved before IETF LC:**** > > ** ** > > Section 3.1., "Consult source code for details"**** > > If the details are only specified in the source code, then the source > needs to be a normative reference. And I would prefer to avoid that :) > Better to specify here how the BEI and FL fields are encoded. > Alternatively, if the codec really does expect a combined BEI/FL field, you > could specify such a field here, opaque to the RTP layer. However, you > would at least need to say how the recipient knows where this field starts > and stops.**** > > ** ** > > Section 3.2., "The length of the encoded data is variable and depends > on the signal characteristics and the target bit rate."**** > > However, there's nothing in this section that tells a recipient how to > determine what this length is. **** > > ** ** > > Section 3.3., "... verifying the CRC checksum ..."**** > > Please specify which CRC function is to be applied, and how the CRC value > field is formatted.**** > > ** ** > > Section 3.3., "If this value would exceed 255 at encoding..."**** > > It sounds like the LEN field is a single octet unsigned integer. Please > state that explicitly. **** > > ** ** > > Section 9.2. Informative References.**** > > Better path to source code would be "webrtc/ > modules/audio_coding/codecs/isac"**** > > ** ** > > Thanks,**** > > --Richard**** > --e89a8fb1ef1651d27a04d9510af2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sure. I didn't mean to imply that we need a reference to the codec, in = fact the opposite. =A0I was looking for this document to tell me how to par= se out the fields I would feed into the black box of the codec. =A0They des= cribe the fields, but it seems to me that they need more detail in order fo= r people to know how to parse them out of the payload.

--Richard


On Mo= n, Apr 1, 2013 at 2:03 PM, Roni Even <ron.even.tlv@gmail.com><= /span> wrote:

Hi Richard,

As a general comment, for= RTP payload specifications we do not require a normative reference to the = codec. We only require enough information that will allow an RTP receiver t= o parse the information and move it to the decoder that can be a black box.= This allows us to publish RTP payload specification also for codecs whose = specifications are not publically available.

Still in this case more i= nformation can be supplied.

= =A0

As for the comments the a= uthors should address them

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=A0

Roni Even

=A0

From: payload-bounces@ietf= .org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: 01 April, 2013 8:06 PM
To: payload@ietf.org
Cc: draft-ietf= -avt-rtp-isac@tools.ietf.org
Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04<= u>

=A0

Overall, this document looks in pretty good= shape. =A0A couple of comments I would like to get resolved before IETF LC= :

=A0

Section 3.1., "Consult source code for details"=

If the details are only specified= in the source code, then the source needs to be a normative reference. =A0= And I would prefer to avoid that =A0:) =A0Better to specify here how the BE= I and FL fields are encoded. =A0 Alternatively, if the codec really does ex= pect a combined BEI/FL field, you could specify such a field here, opaque t= o the RTP layer. =A0However, you would at least need to say how the recipie= nt knows where this field starts and stops.

=A0

Section 3.2., "The len= gth of the encoded data is variable and depends on=A0the signal characteris= tics and the target bit rate."

However, there's nothing in this sect= ion that tells a recipient how to determine what this length is. =A0=

=A0

Section 3.3., "...=A0verifying the CR= C checksum ..."

Please specify which CRC function is to be applied, and how the CRC val= ue field is formatted.

=A0

Section 3.3., "If this= value would exceed 255 at encoding..."

=

It sounds like the LEN field is a single octet unsig= ned integer. =A0Please state that explicitly.=A0

=A0

Section 9.2. Informative References.

Better path to source code would be "= ;webrtc/modules/audio_coding/codecs/isac&q= uot;

=A0

Thanks,<= /span>

--Richard

<= /div>

--e89a8fb1ef1651d27a04d9510af2-- From ron.even.tlv@gmail.com Mon Apr 1 14:45:22 2013 Return-Path: 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 B25301F0D1D for ; Mon, 1 Apr 2013 14:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-2.135, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] 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 jVPmt8NAN5jj for ; Mon, 1 Apr 2013 14:45:21 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BEC9D1F0D1B for ; Mon, 1 Apr 2013 14:45:20 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id q15so1181699ead.27 for ; Mon, 01 Apr 2013 14:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=uSWcSXjEEn7tleY8TdlwqajttQSXQNCoA5+C9TpcXbI=; b=I99b6EneUOn8tuw0OFOhP/IUAIIoldO/2M2Z8ObttZqoGy7506w9sbmJz2eFutWckS NuATRJKsKpTVOn2RhCz4f4EVYcAPXclgq0u2BUURkam4koRxUZn+P/gwbO6oLN2eHAEA LMjEkhHjT4e3MsPePHe6wAg/nC7rFjxZvwhQ9r+SOBX3BCyshKsr2PxSdXcEAXq5jS7J 69+Ik/pq/TRjfnsroUZsrtAAFfq/kfXC5jiNtOXyCC2rbim/iYHmZidGNkAKih/LCNLN EBRnALQUXwJjy9oGrQfpRb2ARSi1NAcn4pWtbyWTgYWBPFb8h3EawOeBaTM2l69uhWfm qNtw== X-Received: by 10.14.179.201 with SMTP id h49mr41711586eem.26.1364852719786; Mon, 01 Apr 2013 14:45:19 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id d47sm23453147eem.9.2013.04.01.14.45.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 14:45:18 -0700 (PDT) From: "Roni Even" To: "'Richard Barnes'" References: <062e01ce2f03$33956840$9ac038c0$@gmail.com> In-Reply-To: Date: Tue, 2 Apr 2013 00:44:43 +0300 Message-ID: <065f01ce2f22$26c76b80$74564280$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0660_01CE2F3B.4C15B4F0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQNII6D3+HHGXem04NFCDjzvpOKjfwGUKUuuAdYX/3eVsqqIMA== Content-Language: en-us Cc: draft-ietf-avt-rtp-isac@tools.ietf.org, payload@ietf.org Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:45:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0660_01CE2F3B.4C15B4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Richard, These fields are not part of the RTP header but part of the iSAC payload header and I agree that it will be better to clarify them. Roni From: Richard Barnes [mailto:rlb@ipv.sx] Sent: 01 April, 2013 9:47 PM To: Roni Even Cc: payload@ietf.org; draft-ietf-avt-rtp-isac@tools.ietf.org Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 Sure. I didn't mean to imply that we need a reference to the codec, in fact the opposite. I was looking for this document to tell me how to parse out the fields I would feed into the black box of the codec. They describe the fields, but it seems to me that they need more detail in order for people to know how to parse them out of the payload. --Richard On Mon, Apr 1, 2013 at 2:03 PM, Roni Even wrote: Hi Richard, As a general comment, for RTP payload specifications we do not require a normative reference to the codec. We only require enough information that will allow an RTP receiver to parse the information and move it to the decoder that can be a black box. This allows us to publish RTP payload specification also for codecs whose specifications are not publically available. Still in this case more information can be supplied. As for the comments the authors should address them Roni Even From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes Sent: 01 April, 2013 8:06 PM To: payload@ietf.org Cc: draft-ietf-avt-rtp-isac@tools.ietf.org Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 Overall, this document looks in pretty good shape. A couple of comments I would like to get resolved before IETF LC: Section 3.1., "Consult source code for details" If the details are only specified in the source code, then the source needs to be a normative reference. And I would prefer to avoid that :) Better to specify here how the BEI and FL fields are encoded. Alternatively, if the codec really does expect a combined BEI/FL field, you could specify such a field here, opaque to the RTP layer. However, you would at least need to say how the recipient knows where this field starts and stops. Section 3.2., "The length of the encoded data is variable and depends on the signal characteristics and the target bit rate." However, there's nothing in this section that tells a recipient how to determine what this length is. Section 3.3., "... verifying the CRC checksum ..." Please specify which CRC function is to be applied, and how the CRC value field is formatted. Section 3.3., "If this value would exceed 255 at encoding..." It sounds like the LEN field is a single octet unsigned integer. Please state that explicitly. Section 9.2. Informative References. Better path to source code would be "webrtc/modules/audio_coding/codecs/isac" Thanks, --Richard ------=_NextPart_000_0660_01CE2F3B.4C15B4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

These fields are not part of the RTP header but part of the iSAC = payload header and I agree that it will be better to clarify = them.

Roni

 

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: 01 April, 2013 9:47 = PM
To: Roni Even
Cc: payload@ietf.org; = draft-ietf-avt-rtp-isac@tools.ietf.org
Subject: Re: [payload] = AD Evaluation: draft-ietf-avt-rtp-isac-04

 

Sure. I = didn't mean to imply that we need a reference to the codec, in fact the = opposite.  I was looking for this document to tell me how to parse = out the fields I would feed into the black box of the codec.  They = describe the fields, but it seems to me that they need more detail in = order for people to know how to parse them out of the = payload.

 

--Richard

 

On Mon, Apr 1, 2013 at 2:03 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Richard,

As a general comment, for RTP payload specifications we do not = require a normative reference to the codec. We only require enough = information that will allow an RTP receiver to parse the information and = move it to the decoder that can be a black box. This allows us to = publish RTP payload specification also for codecs whose specifications = are not publically available.

Still in this case more information can be = supplied.

 

As for the comments the authors should address = them

 

Roni Even

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of = Richard Barnes
Sent: 01 April, 2013 8:06 PM
To: = payload@ietf.org
Cc: draft-ietf-avt-rtp-isac@tools.ietf.org
Subjec= t: [payload] AD Evaluation: = draft-ietf-avt-rtp-isac-04

 <= /o:p>

Overall, = this document looks in pretty good shape.  A couple of comments I = would like to get resolved before IETF LC:

 <= /o:p>

Section = 3.1., "Consult source code for = details"

If the = details are only specified in the source code, then the source needs to = be a normative reference.  And I would prefer to avoid that =  :)  Better to specify here how the BEI and FL fields are = encoded.   Alternatively, if the codec really does expect a = combined BEI/FL field, you could specify such a field here, opaque to = the RTP layer.  However, you would at least need to say how the = recipient knows where this field starts and = stops.

 <= /o:p>

Section = 3.2., "The length of the encoded = data is variable and depends on the signal characteristics and the = target bit rate."

However, = there's nothing in this section that tells a recipient how to determine = what this length is.  

 <= /o:p>

Section = 3.3., "... verifying the CRC = checksum ..."

Please = specify which CRC function is to be applied, and how the CRC value field = is formatted.

 <= /o:p>

Section = 3.3., "If this value would exceed = 255 at encoding..."

It sounds = like the LEN field is a single octet unsigned integer.  Please = state that explicitly. 

 <= /o:p>

Section = 9.2. Informative References.

Better path = to source code would be "webrtc/modules/audio_coding/codecs/isac"<= o:p>

 <= /o:p>

Thanks,

--Richard

 

------=_NextPart_000_0660_01CE2F3B.4C15B4F0-- From magnus.westerlund@ericsson.com Wed Apr 3 07:55:29 2013 Return-Path: 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 7D61121F8E6A; Wed, 3 Apr 2013 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 uK80SsQbXLeP; Wed, 3 Apr 2013 07:55:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A83FA21F8E58; Wed, 3 Apr 2013 07:55:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-74-515c42de5781 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E8.E6.32353.ED24C515; Wed, 3 Apr 2013 16:55:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Apr 2013 16:55:26 +0200 Message-ID: <515C42DD.1030902@ericsson.com> Date: Wed, 3 Apr 2013 16:55:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: avt@ietf.org, "payload@ietf.org" References: <20130219074201.79BD0B1E002@rfc-editor.org> In-Reply-To: <20130219074201.79BD0B1E002@rfc-editor.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+Jvre49p5hAg8srdS1e9qxkt3j1+gqr xdPGs4wWly6eZbKY2mdrcemfisWF9b9YHNg9Wp/tZfX4eusgk8fOWXfZPVqOvGX1WLLkJ5PH 5I2zWALYorhsUlJzMstSi/TtErgyZp6dy15wUabizlypBsYe8S5GTg4JAROJU3tusELYYhIX 7q1n62Lk4hASOMUocXblFihnGaNEz/Xb7CBVvALaEvt7zjF1MXJwsAioSNycFggSZhOwkLj5 o5ENxBYVCJb4+eoMC0S5oMTJmU/AbBEBc4lfR5czgsxkFtjMKHHreDNYg7CAo8TjIw8ZQWwh oKL5736BXcQJNPRDxxI2iOskJba8aAe7gVlAT2LK1RZGCFteonnrbGaIXm2JhqYO1gmMQrOQ 7J6FpGUWkpYFjMyrGNlzEzNz0svNNzECI+Dglt8GOxg33Rc7xCjNwaIkzhvueiFASCA9sSQ1 OzW1ILUovqg0J7X4ECMTBycwDDdJR3POzWQJ6s0+F1D1f3f4PNN9ddyK4qvWVC/exnT20Ic2 nwK9/4GykybPeBYSWbF01YvDGhPNy+Q78sx797A9PsvOP1NiPpPXpNigM+6O3u/seYJl1itd mrT3Mn9iX14ok27aI7l/Rc9OK8aeCH3yMIQ3YP5mLT2GA7V3J5+beYFJquxrihJLcUaioRZz UXEiAF3dw71OAgAA Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, tom.taylor.stds@gmail.com Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:55:29 -0000 AVTCORE and Payload WG, There appear to exist an interoperability issue around the the need to use the same timestamp rate for the DTMF and the audio. Thus, I think we should serioulsy consider to approve this erratum. And if the text is not correct, propose a better text. I personally believe the proposal is significantly clearer than the old text and also reflect what must have been intended. This issues a 2-week last call on input on this erratum. After the 17th of April I will issue a final recommendation on this erratum. For previous discussion that resulted in this updated erratum proposal see this AVTCORE mailing list discussion: http://www.ietf.org/mail-archive/web/avt/current/msg15669.html Cheers Magnus Westerlund AVTCORE WG chair On 2013-02-19 08:42, RFC Errata System wrote: > > The following errata report has been submitted for RFC4733, > "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 > > -------------------------------------- > Type: Technical > Reported by: Xavier Marjou > > Section: 2.1 > > Original Text > ------------- > Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. > > Corrected Text > -------------- > Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel. > > Notes > ----- > RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451). > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4733 (draft-ietf-avt-rfc2833bis-15) > -------------------------------------- > Title : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals > Publication Date : December 2006 > Author(s) : H. Schulzrinne, T. Taylor > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From petithug@acm.org Wed Apr 3 11:23:43 2013 Return-Path: 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 15E7A21F8A68; Wed, 3 Apr 2013 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 jBFoIi9v5XVV; Wed, 3 Apr 2013 11:23:42 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 205E021F89E1; Wed, 3 Apr 2013 11:23:42 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f] (unknown [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1DDBA202D8; Wed, 3 Apr 2013 20:23:40 +0200 (CEST) Message-ID: <515C73AA.8080007@acm.org> Date: Wed, 03 Apr 2013 11:23:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Magnus Westerlund References: <20130219074201.79BD0B1E002@rfc-editor.org> <515C42DD.1030902@ericsson.com> In-Reply-To: <515C42DD.1030902@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, avt@ietf.org, "payload@ietf.org" , tom.taylor.stds@gmail.com Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:23:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2013 07:55 AM, Magnus Westerlund wrote: > AVTCORE and Payload WG, > > There appear to exist an interoperability issue around the the need to use > the same timestamp rate for the DTMF and the audio. Thus, I think we should > serioulsy consider to approve this erratum. And if the text is not correct, > propose a better text. > > I personally believe the proposal is significantly clearer than the old > text and also reflect what must have been intended. > > This issues a 2-week last call on input on this erratum. After the 17th of > April I will issue a final recommendation on this erratum. > I support this text. BTW I would like to applaud the way this erratum was handled. i.e. discussed and refined first in the WG, as it should be[1]. Thanks. [1] http://www.rfc-editor.org/pipermail/rfc-interest/2012-August/004839.html > > For previous discussion that resulted in this updated erratum proposal see > this AVTCORE mailing list discussion: > http://www.ietf.org/mail-archive/web/avt/current/msg15669.html > > Cheers > > Magnus Westerlund AVTCORE WG chair > > On 2013-02-19 08:42, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC4733, "RTP Payload >> for DTMF Digits, Telephony Tones, and Telephony Signals". >> >> -------------------------------------- You may review the report below >> and at: http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 >> >> -------------------------------------- Type: Technical Reported by: >> Xavier Marjou >> >> Section: 2.1 >> >> Original Text ------------- Named telephone events are carried as part of >> the audio stream and MUST use the same sequence number and timestamp base >> as the regular audio channel to simplify the generation of audio >> waveforms at a gateway. >> >> Corrected Text -------------- Named telephone events are carried as part >> of the audio stream and if they use the same SSRC (therefore the same >> timing and sequence number space), they MUST use the same timestamp clock >> rate as the regular audio channel. >> >> Notes ----- RFC4733 was written in a way to avoid the multiple clock-rate >> problem by mandating the use of the same SSRC for DTMF and audio. However >> it's not explicitly written, which brings an ambiguity. It was commented >> that RFC4733 needs to be updated. (c.f. >> http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). >> This errata obsoletes the previous proposed errata (ID: 3451). >> >> Instructions: ------------- This errata is currently posted as >> "Reported". If necessary, please use "Reply All" to discuss whether it >> should be verified or rejected. When a decision is reached, the verifying >> party (IESG) can log in to change the status and edit the report, if >> necessary. >> >> -------------------------------------- RFC4733 >> (draft-ietf-avt-rfc2833bis-15) -------------------------------------- >> Title : RTP Payload for DTMF Digits, Telephony Tones, and >> Telephony Signals Publication Date : December 2006 Author(s) >> : H. Schulzrinne, T. Taylor Category : PROPOSED STANDARD >> Source : Audio/Video Transport Area : >> Real-time Applications and Infrastructure Stream : IETF >> Verifying Party : IESG - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRXHOnAAoJECnERZXWan7E0TkQANzx6Ls7FTHJYIz4ijt3MPlM 0lZnq6tOgdaDGS4K9ol4Bp1Qf8EbB+tdzFTTOTpUWSO1Xx+ZmdLsdZIlxPcyFs36 Ylh9gxo9E/tVEiYQwrP7j/qsrIXMC5TQgMeQ7wqEVsRjo//jmo+1oE9O72QA2NL/ JJzZFkXdxpHIgkot6ILMVNMZ5IGAOKqqafKkSjLDnidmkma8CqnJal7SjaqsoYmO Kxabvbf+Rrh5iZnZa38eOYPKJc9FyxmjknbxPLrS+uM6Z8VZ5ogIOS0x1FUKXrMq /HYYV4TNbduUlh571lwYA+u85be/jRsLxl2XDWEIBHrtzp+DWo8DkZgg/7kOE/js XtU00+1qeu/Z3HljkjohkLyPBxqTu8L1PdVsN8N5LEdO4sqprGZD5aKf25LZOGF2 rhU0o/xCSFTW6W8hkycS+wtoIzTH7g2bTmajOW2/gfRU+VYosBaDeOqZIvWp9qzj Db6JRQlQ01rSFtvajL+LB/x1ykkaHmcuK8RHuPqemddTZH/wMGBCYKH86ErzI7AV BE7xArnNGBSGV6KEIXszyyaiJMAHmT8pliwr3/hga9LDqcfBwZS/flJRPWpEXhD/ 9YVbqnTBX3om2YyCJnxRhOvuj4S3kTsZxdmALvSnwpks+tsGtf7u9gIcGQfN8pKP kEZZP2g13bMxSkhWcbeZ =MkAX -----END PGP SIGNATURE----- From internet-drafts@ietf.org Fri Apr 12 06:33:37 2013 Return-Path: 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 6C65021F8BE2; Fri, 12 Apr 2013 06:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 3fZXBVRpyCDT; Fri, 12 Apr 2013 06:33:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDA321F89DB; Fri, 12 Apr 2013 06:33:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130412133336.27848.48350.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 06:33:36 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:33:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-03.txt Pages : 51 Date : 2013-04-12 Abstract: This document contains information on how to best write an RTP payload format. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions that can be used when writing an RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Fri Apr 12 06:37:22 2013 Return-Path: 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 82E8621F8BE2 for ; Fri, 12 Apr 2013 06:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 pn95JDNNr0j6 for ; Fri, 12 Apr 2013 06:37:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4255621F8B13 for ; Fri, 12 Apr 2013 06:37:21 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-71-51680e102e3e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C1.09.03253.01E08615; Fri, 12 Apr 2013 15:37:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Apr 2013 15:37:19 +0200 Message-ID: <51680E0E.3070002@ericsson.com> Date: Fri, 12 Apr 2013 15:37:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: payload@ietf.org References: <20130412133336.27848.48350.idtracker@ietfa.amsl.com> In-Reply-To: <20130412133336.27848.48350.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvra4AX0agwctdMhaXLp5lcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqlrs1gLNolULN90kqmBcYlAFyMnh4SAiUT/i/esELaYxIV7 69m6GLk4hAROMUp8e3gMLCEksJxR4uZtcRCbV0Bb4s302WwgNouAqsSWy7PAatgELCRu/mgE i4sKBEv8fHWGBaJeUOLkzCdgtoiAiMSiu5PBbGEBN4mjP9YxQsx3lJiwegKYzSngJNHZ844R 4iBJiS0v2tlBbGYBPYkpV1sYIWx5ieats5kherUlGpo6WCcwCs5Csm4WkpZZSFoWMDKvYmTP TczMSS8338QIDL+DW34b7GDcdF/sEKM0B4uSOG+464UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYyr117s1J+qn3f0z3YbjZ+lCr7brYI/P2P/Yf+4o9GnPyh27ZLlPzt5bRhmcRVyX8j0 XBIvdu77yrgVkQ9N+823ej/fZr1kcewhu/mLFlrcmckecrXHrHsv34M306zifhye+ut8n0jb l4KKAoeriSrdTl+uMrZ4BTbN9zpVxX5nGsedE3cc2bSVWIozEg21mIuKEwEF7zTXDQIAAA== Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:37:22 -0000 WG, Sorry for being tardy in updating this document. I have finally done a rewrite of the text on security consideration, especially the template text. I now intended to request review of this from the sec-dir and SEC ADs if they think this works. I have also done a complete review and taken care of any detected published documents, concluded WG and other things that has changed since last years submission. If the security considerations are okay I do think this document is ready for publications. I would really appreciate if some could take the time to review it and see if they agree that it is ready for WG last call. Cheers Magnus Westerlund On 2013-04-12 15:33, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. > > Title : How to Write an RTP Payload Format > Author(s) : Magnus Westerlund > Filename : draft-ietf-payload-rtp-howto-03.txt > Pages : 51 > Date : 2013-04-12 > > Abstract: > This document contains information on how to best write an RTP > payload format. It provides reading tips, design practices, and > practical tips on how to produce an RTP payload format specification > quickly and with good results. A template is also included with > instructions that can be used when writing an RTP payload format. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Apr 12 06:49:23 2013 Return-Path: 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 2E22821F89DB; Fri, 12 Apr 2013 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.024 X-Spam-Level: X-Spam-Status: No, score=-106.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 EoDSEJWopr09; Fri, 12 Apr 2013 06:49:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEBB21F896B; Fri, 12 Apr 2013 06:49:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-8b-516810df7783 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.1C.10459.FD018615; Fri, 12 Apr 2013 15:49:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Apr 2013 15:49:19 +0200 Message-ID: <516810DE.3020806@ericsson.com> Date: Fri, 12 Apr 2013 15:49:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "secdir@ietf.org" , sec-ads@tools.ietf.org X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLJMWRmVeSWpSXmKPExsUyM+Jvre4DgYxAg6/LuSwuXTzLZLF88WR2 iw8LH7I4MHssWfKTyePL5c9sAUxRXDYpqTmZZalF+nYJXBn72oULWqwq/jz5xdzAuEK3i5GT Q0LAROL3qp9MELaYxIV769m6GLk4hAROMUoce3yVEcJZzijx4uUPdpAqXgFtid7fC1hBbBYB VYmXJ2cyg9hsAhYSN380soHYogLBEj9fnWGBqBeUODnzCZgtImAvMXFtM9g2ZgFNiUOfH4PV Cwu4Slx6eZQZ4gpJiS0v2tkhavQkplxtYYSw5SWat84GqxECuqGhqYN1AqPALCQrZiFpmYWk ZQEj8ypG9tzEzJz0csNNjMAgPLjlt+4OxlPnRA4xSnOwKInzhrleCBASSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAmNuZeM16vlJp0EaT7DUsn1837Vnr399g7uR7/43O42WzutMnTUhru5nX vOLPt7hpzs8VT5mqRM+sm2zFkPfKusf16tLVu9Yy+rjfaUv0uJx/2vl18G05X+9zKwSfKpgt 4DnRs3zL8UbZ5X+evWdbceVHlAtj92zRnq88z6Z+fZrlVvm9aOeh80osxRmJhlrMRcWJAFLp WtQQAgAA Cc: "payload@ietf.org" Subject: [payload] Security consideration template text for RTP payload formats X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 13:49:23 -0000 Secdir and Sec ADs, I have just updated the draft on Howto write RTP payload formats: https://datatracker.ietf.org/wg/payload/ I would like to request review from both some Secdir persons and at least one of the ADs regarding the security aspects of this document. The reasons are that this document contains both recommendations on what to think about when writing Security Consideration sections and template text. As this is a document that has existed a long time we have determined that the template text will be commonly used by authors of RTP payload formats. Thus I want to ensure that we have at least now have agreement on this text, especially in light of the discussion around https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ and that we don't want secdir reviewers raising issues with this template text when you see it in the last call reviews in future years. The relevant security sections from the Howto draft are the following: 7.2. Security Considerations All Internet drafts require a Security Considerations section. The security considerations section in an RTP payload format needs to concentrate on the security properties this particular format has. Some payload formats have very few specific issues or properties and can fully fall back on the security considerations for RTP in general and those of the profile being used. Because those documents are always applicable, a reference to these is normally placed first in the security considerations section. There is suggested text in the template below. The security issues of confidentiality, integrity protection and source authentication are common issue for all payload formats. These should be solved by mechanisms external to the payload and do not need any special consideration in the payload format except for an reminder on these issues. Reasons for this division is further documented in "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory]. For a survey of available mechanisms to meet these goals, please review "Options for Securing RTP Sessions" [I-D.ietf-avtcore-rtp-security-options]. Suitable stock text to inform people about this is included in the template. Potential security issues with an RTP payload format and the media encoding that needs to be considered are: 1. That the decoding of the payload format or its media shows substantial non-uniformity, either in output or in complexity to perform the decoding operation. For example a generic non- destructive compression algorithm may provide an output of almost an infinite size for a very limited input, thus consuming memory or storage space out of proportion with what the receiving application expected. Such inputs can cause some sort of disruption, i.e. a denial of service attack on the receiver side by preventing that host from producing any goodput. Certain decoding operations may also vary in the amount of processing needed to perform those operations depending on the input. This may also be a security risk if it is possible to raise processing load significantly above nominal simply by designing a malicious input sequence. If such potential attacks exist, this must be made clear in the security considerations section to make implementers aware of the need to take precautions against such behavior. 2. The inclusion of active content in the media format or its transport. "Active content" means scripts etc. that allow an attacker to perform potentially arbitrary operations on the receiver. Most active contents has limited possibility to access the system or perform operations outside a protected sandbox. RFC 4855 [RFC4855] has a requirement that it be noted in the media types registration if the payload format contains active content or not. If the payload format has active content it is strongly recommended that references to any security model applicable for such content are provided. A boilerplate text for "no active content" is included in the template. This must be changed if the format actually carries active content. 3. Some media formats allow for the carrying of "user data", or types of data which are not known at the time of the specification of the payload format. Such data may be a security risk and should be mentioned. 4. Audio or Speech codecs supporting variable bit-rate based on audio/speech input or having discontinuous transmission support must consider the issues discussed in Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [RFC6562]. Suitable stock text for the security considerations section is provided in the template in the appendix. However, authors do need to actively consider any security issues from the start. Failure to address these issues may block approval and publication. ---- Next Section ---- A.13. Security Considerations [See Section 7.2] RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload formats responsibility to discuss or mandate what solutions are used to meet the basic security goals like confiedenitality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. The rest of the this security consideration discusses the security impacting properties of the payload format itself. This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content. [The previous paragraph may need editing due to the format breaking either of the statements. Fill in here any further potential security threats created by the payload format itself.] Thanks Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rlb@ipv.sx Tue Apr 16 15:21:09 2013 Return-Path: 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 69F2421F979C for ; Tue, 16 Apr 2013 15:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] 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 13bjQm-oWMgU for ; Tue, 16 Apr 2013 15:21:08 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id C5B4D21F9794 for ; Tue, 16 Apr 2013 15:21:08 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ef5so372045obb.36 for ; Tue, 16 Apr 2013 15:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=vubON9Yp44BnowIxlNdrY/OASMn78Oqe132d9eDdVuk=; b=bU+6gIW9pBb6yEp/gXLHshb2dTNZCckid95QD3Z9hUz/9VFWXCj3fdzAZzO9juJiLd wxyjIEVvQ7uJ0ut+YAkqSkLcWZt3aREK4ZmNkcvE2XEOJiMZrl199l1WuBWclZJVVyQi rkNIZCrEfDfm2ALmI2Z3qvZgr8IzZGVIe7bLOX3FST/omxOZnyGLzufEwA3ad4WBirAf EANXnqAQnHXESpwMS7VowkDvBnQ76aNaTBoRzUBAvs/BULFctTwqMn3RISPoePVZxFOE YTx7rUUunDyqS/hKsi0cJtrqn+cXRwa5uOs6nIEslt2hGzaUK+KH2QUSJYX13dGR1ISB +yOA== MIME-Version: 1.0 X-Received: by 10.182.52.102 with SMTP id s6mr1502328obo.87.1366150868237; Tue, 16 Apr 2013 15:21:08 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Tue, 16 Apr 2013 15:21:08 -0700 (PDT) X-Originating-IP: [108.18.40.68] Date: Tue, 16 Apr 2013 18:21:08 -0400 Message-ID: From: Richard Barnes To: payload@ietf.org Content-Type: multipart/alternative; boundary=14dae93996073611bf04da81c9a0 X-Gm-Message-State: ALoCoQlg9IBWhKiJx8hpnLCQcU3E9EhtRV5jPt8PbmqvA1KlabUsdJdmKyXGB+ZvibJxNgRRbiNv Subject: [payload] AD review of draft-ietf-payload-vp8-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 22:21:09 -0000 --14dae93996073611bf04da81c9a0 Content-Type: text/plain; charset=ISO-8859-1 I reviewed this draft and have a couple of questions before IETF LC: Major: >From the current text, it seems like the frame reconstruction algorithm is mostly clear: 1. Collect all packets with a given PictureID 2. Order packets by PartID 3. Go through packets in order, updating PartID as you go through each packet. 4. If you get to the end of a packet with an incomplete partition, and the PartID of the next packet is different from the current PartID (indicating a lost packet), then discard the incomplete partition and: 4.1. If S=1, start a new partition at the beginning of the new packet 4.2. If S=0, skip to the next partition boundary in the new packet and start a new partition starting there Is this understanding correct? In any case, it would really help interoperability if you could write this algorithm down explicitly in the document, probably around Section 4.4. Note that this assumes that the bitstream format has partition markers. Minor: The document refers several times to the "golden" and "altref" frames. However, I don't see it defined anywhere how these frames are set. Is this in the bit stream definition? Section 4.2. says that the PartID MUST NOT be larger than 8. But the field is 4 bits long. Is this correct? In Section 4.2., there are 8- and 16-bit versions of the PictureID. The definition says that when the maximum ID is reached, the ID rolls over. MUST the length remain the same? In the congestion control section, please add a note that the discarding of non-reference frames cannot be done if the stream is encrypted (because the non-reference marker is encrypted). --14dae93996073611bf04da81c9a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I reviewed this draft and have a couple of questions before IETF LC:
Major:

From the current text, it seem= s like the frame reconstruction algorithm is mostly clear:
1. Col= lect all packets with a given PictureID
2. Order packets by PartID
3. Go through packets in order, u= pdating PartID as you go through each packet. =A0
4. If you get t= o the end of a packet with an incomplete partition, and the PartID of the n= ext packet is different from the current PartID (indicating a lost packet),= then discard the incomplete partition and:
4.1. If S=3D1, start a new partition at the beginning of the new packe= t
4.2. If S=3D0, skip to the next partition boundary in the new p= acket and start a new partition starting there
Is this understand= ing correct? =A0In any case, it would really help interoperability if you c= ould write this algorithm down explicitly in the document, probably around = Section 4.4. =A0Note that this assumes that the bitstream format has partit= ion markers.


Minor:=A0

The d= ocument refers several times to the "golden" and "altref&quo= t; frames. =A0However, I don't see it defined anywhere how these frames= are set. =A0Is this in the bit stream definition?

Section 4.2. says that the PartID MUST NOT be larger th= an 8. =A0But the field is 4 bits long. =A0Is this correct?

In Section 4.2., there are 8- and 16-bit versions of the PictureID= . =A0The definition says that when the maximum ID is reached, the ID rolls = over. =A0MUST the length remain the same?

In the congestion control section, = please add a note that the discarding of non-reference frames cannot be don= e if the stream is encrypted (because the non-reference marker is encrypted= ). --14dae93996073611bf04da81c9a0-- From magnus.westerlund@ericsson.com Thu Apr 18 00:50:23 2013 Return-Path: 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 76BDD21F89DB; Thu, 18 Apr 2013 00:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.024 X-Spam-Level: X-Spam-Status: No, score=-106.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 FXyQhxkRdTSe; Thu, 18 Apr 2013 00:50:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4021F89B2; Thu, 18 Apr 2013 00:50:11 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-b5-516fa5b217a3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D5.8F.10459.2B5AF615; Thu, 18 Apr 2013 09:50:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Apr 2013 09:50:10 +0200 Message-ID: <516FA5AA.5080900@ericsson.com> Date: Thu, 18 Apr 2013 09:50:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gonzalo Camarillo References: <20130219074201.79BD0B1E002@rfc-editor.org> <515C42DD.1030902@ericsson.com> In-Reply-To: <515C42DD.1030902@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvre6mpfmBBndaVSxe9qxkt3j1+gqr xaWLZ5ksLv1Tsbiw/heLA6vH11sHmTx2zrrL7tFy5C2rx5IlP5kCWKK4bFJSczLLUov07RK4 Mma8cSs4IV/RdaOfqYFxg2QXIyeHhICJxNU1rYwQtpjEhXvr2boYuTiEBE4xSvydN58FwlnO KHG+uYsFpIpXQFtizeYdQFUcHCwCqhJ3b0uDhNkELCRu/mgEC4sKBEtsbY2BqBaUODnzCVin iICZxPt/q5hARjILdDNKnP56lQkkISzgLbF18wewI4QEwiXuNB1hA7E5BXQkVrfvY4U4TlJi y4t2dhCbWUBPYsrVFkYIW16ieetsZohebYmGpg7WCYxCs5DsnoWkZRaSlgWMzKsY2XMTM3PS yw03MQID++CW37o7GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o5iRQPGEnStOWJoH7PAtfhFa+fxaR2b1uScte+ek7/U5HeuovsSPyTJhJfuNyLnPu+4UnOib p3H/uJbgtMfiBipXJ5xwnbJq1jKNJNmn4hvOJf7ZdEXNwmKGysVq/q+H+0T/vw6zn8fxdoVS liK3WKvSz0dlM+/pLWJWLfN+0tli88ni69bCbiWW4oxEQy3mouJEAAX9cSI6AgAA Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, avt@ietf.org, "payload@ietf.org" , tom.taylor.stds@gmail.com Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 07:50:23 -0000 AD, I recommend that you verify this errata as there has been no objection during this last call period and the text was developed in the context of the AVTCORE WG. Cheers Magnus Westerlund as WG chair of AVTCORE WG On 2013-04-03 16:55, Magnus Westerlund wrote: > AVTCORE and Payload WG, > > There appear to exist an interoperability issue around the the need to > use the same timestamp rate for the DTMF and the audio. Thus, I think we > should serioulsy consider to approve this erratum. And if the text is > not correct, propose a better text. > > I personally believe the proposal is significantly clearer than the old > text and also reflect what must have been intended. > > This issues a 2-week last call on input on this erratum. After the 17th > of April I will issue a final recommendation on this erratum. > > > For previous discussion that resulted in this updated erratum proposal > see this AVTCORE mailing list discussion: > http://www.ietf.org/mail-archive/web/avt/current/msg15669.html > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > On 2013-02-19 08:42, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC4733, >> "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 >> >> -------------------------------------- >> Type: Technical >> Reported by: Xavier Marjou >> >> Section: 2.1 >> >> Original Text >> ------------- >> Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. >> >> Corrected Text >> -------------- >> Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel. >> >> Notes >> ----- >> RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451). >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4733 (draft-ietf-avt-rfc2833bis-15) >> -------------------------------------- >> Title : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals >> Publication Date : December 2006 >> Author(s) : H. Schulzrinne, T. Taylor >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gonzalo.camarillo@ericsson.com Thu Apr 18 01:09:45 2013 Return-Path: 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 291D021F8E94; Thu, 18 Apr 2013 01:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.069 X-Spam-Level: X-Spam-Status: No, score=-106.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 q7JDoyIhjfia; Thu, 18 Apr 2013 01:09:44 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6221F8935; Thu, 18 Apr 2013 01:09:43 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-38-516faa463c9a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 75.FF.19728.64AAF615; Thu, 18 Apr 2013 10:09:42 +0200 (CEST) Received: from [131.160.126.169] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Apr 2013 10:09:43 +0200 Message-ID: <516FAA45.2010005@ericsson.com> Date: Thu, 18 Apr 2013 11:09:41 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Magnus Westerlund References: <20130219074201.79BD0B1E002@rfc-editor.org> <515C42DD.1030902@ericsson.com> <516FA5AA.5080900@ericsson.com> In-Reply-To: <516FA5AA.5080900@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvra7bqvxAg6vHrC1e9qxkt3j1+gqr xaWLZ5ksLv1Tsbiw/heLA6vH11sHmTx2zrrL7tFy5C2rx5IlP5kCWKK4bFJSczLLUov07RK4 Mg5M28RUsE+24vamPYwNjBfFuxg5OSQETCSWPpjLDmGLSVy4t56ti5GLQ0jgFKPEq+W7GCGc tYwSU86uYgKp4hXQlnjz/g6YzSKgKvFi91E2EJtNwEJiy637LCC2qECUxL+3uxkh6gUlTs58 AhYXETCTeDhhP9gGZoFuRonTX6+CDRIW8JbYuvkDWIOQQLnE/3O/WUFsTgEdiX0v+6DOk5RY NK0TbBCzgJ7ElKstjBC2vMT2t3OYIXq1JZY/a2GZwCg0C8nuWUhaZiFpWcDIvIqRPTcxMye9 3GgTIzC8D275rbqD8c45kUOM0hwsSuK84a4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw zkiZ987MbcYUgeDb3/Xfdmn+DfisoTBv+rtrG+zmtvK+7fhc/2An69Xy/XOOyq/jC1E9GCYf +bftfaNoUo37tpy3EpcnRx/PNp8979Sd6QfqA4z2/uDh/MB7fCXbywUJsvl6+ofMPA7s4Yh1 1P3/bbbO1LJXklIqrfutE3+/OWxms+TZj9t3NZVYijMSDbWYi4oTAYcM+uI9AgAA Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, avt@ietf.org, "payload@ietf.org" , tom.taylor.stds@gmail.com Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:09:45 -0000 Hi, I have just verified it. Thanks, Gonzalo On 18/04/2013 10:50 AM, Magnus Westerlund wrote: > AD, > > I recommend that you verify this errata as there has been no objection > during this last call period and the text was developed in the context > of the AVTCORE WG. > > Cheers > > Magnus Westerlund > as WG chair of AVTCORE WG > > > On 2013-04-03 16:55, Magnus Westerlund wrote: >> AVTCORE and Payload WG, >> >> There appear to exist an interoperability issue around the the need to >> use the same timestamp rate for the DTMF and the audio. Thus, I think we >> should serioulsy consider to approve this erratum. And if the text is >> not correct, propose a better text. >> >> I personally believe the proposal is significantly clearer than the old >> text and also reflect what must have been intended. >> >> This issues a 2-week last call on input on this erratum. After the 17th >> of April I will issue a final recommendation on this erratum. >> >> >> For previous discussion that resulted in this updated erratum proposal >> see this AVTCORE mailing list discussion: >> http://www.ietf.org/mail-archive/web/avt/current/msg15669.html >> >> Cheers >> >> Magnus Westerlund >> AVTCORE WG chair >> >> On 2013-02-19 08:42, RFC Errata System wrote: >>> >>> The following errata report has been submitted for RFC4733, >>> "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Xavier Marjou >>> >>> Section: 2.1 >>> >>> Original Text >>> ------------- >>> Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. >>> >>> Corrected Text >>> -------------- >>> Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel. >>> >>> Notes >>> ----- >>> RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451). >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4733 (draft-ietf-avt-rfc2833bis-15) >>> -------------------------------------- >>> Title : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals >>> Publication Date : December 2006 >>> Author(s) : H. Schulzrinne, T. Taylor >>> Category : PROPOSED STANDARD >>> Source : Audio/Video Transport >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >> >> > > From ron.even.tlv@gmail.com Fri Apr 19 00:41:53 2013 Return-Path: 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 8743421F8A1B for ; Fri, 19 Apr 2013 00:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 L2Dn9xLRGO6O for ; Fri, 19 Apr 2013 00:41:52 -0700 (PDT) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id ED36E21F9367 for ; Fri, 19 Apr 2013 00:41:48 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id d17so929884eek.26 for ; Fri, 19 Apr 2013 00:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=bL1jqm0RCHr3duZL2vj7Zdz8c6ne8hlgd0STfSyCYlk=; b=kutY0Y8y6YUYhL9N6oHlojPkhLq9SqzhXN9CHOrTuojnjti3iE+tniaeUtAy3rzXxk vESodxhIp6+jcxez96F4tEsb5R2zl7BgMunp9CBorxZwq7xzs+/JXWkNUKsjpYXH3e6t nY53mQ7xdp9so/gdSiRHuGFYlV2j9i5id+5FksdKKsAgWrTB34R9N8SZb+Ln97q5nCJM R2B93GHwPqQZbMJBiMnaCjygJo85SmozekH9yXG7s2/epG8OpD9cAaJ9naaQzT0fLuMu aU0uTJ/mjXESkPu9bBk2wQcGqmDANfZnfnhzGVp6+mdXGV2VeL5tXLsNde9q/Uq4R01v P8oA== X-Received: by 10.15.95.74 with SMTP id bc50mr14182301eeb.36.1366357308140; Fri, 19 Apr 2013 00:41:48 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id 8sm20933047eeg.15.2013.04.19.00.41.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 19 Apr 2013 00:41:47 -0700 (PDT) From: "Roni Even" To: Date: Fri, 19 Apr 2013 10:41:12 +0300 Message-ID: <006901ce3cd1$46596c20$d30c4460$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01CE3CEA.6BA76770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac48zT0MjAv8KR0ASOKqxoogCAoRIA== Content-Language: en-us Cc: "Wang, Ye-Kui" , "'Botzko, Stephen'" , 'Tom Kristensen' Subject: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 07:41:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006A_01CE3CEA.6BA76770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, An errata report was filed on RFC6184 http://www.rfc-editor.org/errata_search.php?eid=3318 it is given bellow. I would like to get some feedback about this errata, is it correct? "Section 8.1 says: On page 46 start from line 7: "When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb ^^^^^ MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), ^^^^^ 16)" It should say: When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb ^^^^^ MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), ^^^^^ 16) " My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata is correct. Roni Even ------=_NextPart_000_006A_01CE3CEA.6BA76770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

An errata = report was filed on RFC6184 http://ww= w.rfc-editor.org/errata_search.php?eid=3D3318  it is given = bellow.

I would like to get some = feedback about this errata, is it correct?

“Secti= on 8.1 says:

On page 46 start from line 7: =

"When max-dpb is signaled, the = receiver MUST be able to decode

NAL unit streams that conform to the = signaled highest level,

with the exception that the MaxDpbMbs value = in Table A-1 of [1]

for the signaled highest level is replaced = with the value of

max-dpb * 3 / 8. Consequently, a receiver = that signals max-dpb

       &n= bsp;  ^^^^^

MUST be capable of storing the following = number of decoded

frames, complementary field pairs, and = non-paired fields in its

decoded picture buffer:

Min(max-dpb * 3 / 8 / ( = PicWidthInMbs * FrameHeightInMbs),

       &n= bsp;      ^^^^^

16)"

It should = say:

When max-dpb is signaled, the receiver MUST = be able to decode

NAL unit streams that conform to the = signaled highest level,

with the exception that the MaxDpbMbs value = in Table A-1 of [1]

for the signaled highest level is replaced = with the value of

max-dpb * 8 / 3. Consequently, a receiver = that signals max-dpb

       &n= bsp;  ^^^^^

MUST be capable of storing the following = number of decoded

frames, complementary field pairs, and = non-paired fields in its

decoded picture buffer:

Min(max-dpb * 8 / 3 / ( = PicWidthInMbs * FrameHeightInMbs),

       &n= bsp;      ^^^^^

16)

“

 

 

 

My personal view is that  since = MaxDpbMbs=3D max-dpb * 8 / 3 the errata is correct.

 

 

Roni = Even

 

 

 

 

------=_NextPart_000_006A_01CE3CEA.6BA76770-- From mzanaty@cisco.com Fri Apr 19 09:35:04 2013 Return-Path: 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 0E5A021F8C10 for ; Fri, 19 Apr 2013 09:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.444 X-Spam-Level: X-Spam-Status: No, score=-8.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, 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 uw7gxpKUK02n for ; Fri, 19 Apr 2013 09:35:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0455B21F8633 for ; Fri, 19 Apr 2013 09:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12709; q=dns/txt; s=iport; t=1366389302; x=1367598902; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=V6woHN82GYQfIzFADsP+u3HuVo/Attn6Fpyt/gnhcl4=; b=eXx1Ja3Vm0UgwvzWW2drsoYuE30agvTV/4eMYD49EuKHYVx+k/AHrYpB 9A6a6uYtuo2AlE00FEx6JkONciEPtB24989VJ8QFgP2abvDf6VLr8h2EV qbiPHUv7EInD3R/pilI+aqk6AXaT33fTVxIjY11+I+HX3BzVwmGFO1xli c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAIJxcVGtJXG+/2dsb2JhbAA2GoJCRDbAZoEGFnSCHwEBAQQtTBACAQgOAwQBAQsdByERFAkIAQEEAQ0FCId6Aw8ML7MrDYlQjFKCIiYLBgGCZmEDlS2NXIUcgwx6gS4 X-IronPort-AV: E=Sophos;i="4.87,510,1363132800"; d="scan'208,217";a="197804317" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 19 Apr 2013 16:35:01 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3JGZ1rD005549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 16:35:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 11:35:01 -0500 From: "Mo Zanaty (mzanaty)" To: Roni Even , "payload@ietf.org" Thread-Topic: Errata report on RFC6184 - H.264 payload Thread-Index: Ac48zT0MjAv8KR0ASOKqxoogCAoRIAAR8V4g Date: Fri, 19 Apr 2013 16:35:00 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> In-Reply-To: <006901ce3cd1$46596c20$d30c4460$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.247.209] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F6DA449xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "Wang, Ye-Kui" , "'Botzko, Stephen'" , "Tom Kristensen \(tomkrist\)" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 16:35:04 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D90F6DA449xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The errata looks correct. For further clarity, it may also help to add pare= nthesis around (max-dpb*8/3). NEW: When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 8/3. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) Mo From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Friday, April 19, 2013 3:41 AM To: payload@ietf.org Cc: 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom Kristensen (t= omkrist) Subject: Errata report on RFC6184 - H.264 payload Hi, An errata report was filed on RFC6184 http://www.rfc-editor.org/errata_sear= ch.php?eid=3D3318 it is given bellow. I would like to get some feedback about this errata, is it correct? "Section 8.1 says: On page 46 start from line 7: "When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb ^^^^^ MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), ^^^^^ 16)" It should say: When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb ^^^^^ MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), ^^^^^ 16) " My personal view is that since MaxDpbMbs=3D max-dpb * 8 / 3 the errata is = correct. Roni Even --_000_3879D71E758A7E4AA99A35DD8D41D3D90F6DA449xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The errata looks correct. For further clarity, it ma= y also help to add parenthesis

around (max-dpb*8/3).

 

NEW:

When max-dpb is signale= d, the receiver MUST be able to decode

NAL unit streams that c= onform to the signaled highest level,

with the exception that= the MaxDpbMbs value in Table A-1 of [1]

for the signaled highes= t level is replaced with the value of

max-dpb * 8/3. Consequently, a recei= ver that signals max-dpb

MUST be capable of stor= ing the following number of decoded

frames, complementary f= ield pairs, and non-paired fields in its

decoded picture buffer:=

Min((max-dpb * 8/3) / (PicWidthInMbs= * FrameHeightInMbs),16)

 

Mo

 

 

From: Roni Eve= n [mailto:ron.even.tlv@gmail.com]
Sent: Friday, April 19, 2013 3:41 AM
To: payload@ietf.org
Cc: 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom Kriste= nsen (tomkrist)
Subject: Errata report on RFC6184 - H.264 payload<= /p>

 

Hi,

An errata report was filed on RFC6184 http://www.rfc-editor.org/errata_search.php?eid=3D3318  it is give= n bellow.

I would like to get some feedback about this errata,= is it correct?

“Section 8.1 says:

On page 46 start from l= ine 7:

"When max-dpb is s= ignaled, the receiver MUST be able to decode

NAL unit streams that c= onform to the signaled highest level,

with the exception that= the MaxDpbMbs value in Table A-1 of [1]

for the signaled highes= t level is replaced with the value of

max-dpb * 3 / 8. Conseq= uently, a receiver that signals max-dpb

    = ;      ^^^^^

MUST be capable of stor= ing the following number of decoded

frames, complementary f= ield pairs, and non-paired fields in its

decoded picture buffer:=

Min(max-dpb * 3 / 8 / (= PicWidthInMbs * FrameHeightInMbs),

    = ;          ^^^^^

16)"

It should say:

When max-dpb is signale= d, the receiver MUST be able to decode

NAL unit streams that c= onform to the signaled highest level,

with the exception that= the MaxDpbMbs value in Table A-1 of [1]

for the signaled highes= t level is replaced with the value of

max-dpb * 8 / 3. Conseq= uently, a receiver that signals max-dpb

    = ;      ^^^^^

MUST be capable of stor= ing the following number of decoded

frames, complementary f= ield pairs, and non-paired fields in its

decoded picture buffer:=

Min(max-dpb * 8 / 3 / (= PicWidthInMbs * FrameHeightInMbs),

    = ;          ^^^^^

16)

“

 

 

 

My personal view is tha= t  since MaxDpbMbs=3D max-dpb * 8 / 3 the errata is correct.

 

 

Roni Even

 

 

 

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D90F6DA449xmbrcdx14ciscoc_-- From hhhansen@MAYAH.com Tue Apr 23 15:01:29 2013 Return-Path: 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 AE3C421F9352; Tue, 23 Apr 2013 15:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35] 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 b6lufI4TvCzQ; Tue, 23 Apr 2013 15:01:29 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2596421F96B1; Tue, 23 Apr 2013 15:01:28 -0700 (PDT) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1UUlHD-0003qi-Lo; Wed, 24 Apr 2013 00:01:27 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Apr 2013 00:01:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C38F40A@mayah-sbs.mayah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt Thread-Index: Ac4gDnCa3Fo7/g6xRW2P9VT6PrKdAQgXDU0g From: "Hans-Heinrich Hansen" To: , X-Df-Sender: MzI2MjQx Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 22:01:29 -0000 MAYAH and other companies have already implemented the following = optional media type parameters defined in previous apt-X = drafts/discussions: 1. A media type attribute embedded-sync=3Doff/on that applies to both = variants of apt-X=20 2. Media type attributes embedded-aux-left=3Doff/on and = embedded-aux-right=3Doff/on that apply to the Standard apt-X variant = only. 3. A Media type attributes embedded-aux=3Doff/on that applies to the = Enhanced apt-X variant only. Is it possible that the new draft will also contain these parameters as = an option for mono and stereo connections? The new optional parameters embedded-autosync-channels and = embedded-aux-channels could be defined for multi channel audio (more = than 2 channels). From mzanaty@cisco.com Thu Apr 25 11:57:49 2013 Return-Path: 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 0183D21F9671; Thu, 25 Apr 2013 11:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 H47H+Q5t9hUy; Thu, 25 Apr 2013 11:57:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0984521F8411; Thu, 25 Apr 2013 11:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2628; q=dns/txt; s=iport; t=1366916268; x=1368125868; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lH8OVXyc9gZ8+6CgKDUB+oAEjpSEmgJ2Kvx+/RESnqk=; b=IZ2b/i25HunEJajkF4IQSoB9sHEQMQ3DDHRxRnBmn2YrzvQ5MpaOpUp7 n4J/dtuDLcdcoBVPuW78zDwIpnOLX165rCGxndHTSmbzlMRucSg+d6XWb 5I2xvPTVZynCV1rz3ECVCsh2Gp5tud60/LlFhKGBlLXzqSJAITKOtbEMY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAA98eVGtJV2b/2dsb2JhbABRgwY2vi+BBBZ0gh8BAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCAGICwy+Po19gQc4BoJnYQOoPoMOgWo+ X-IronPort-AV: E=Sophos;i="4.87,552,1363132800"; d="scan'208";a="200150634" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 25 Apr 2013 18:57:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3PIvlAR031810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 18:57:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.181]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 13:57:46 -0500 From: "Mo Zanaty (mzanaty)" To: "Dale R. Worley" , "mmusic@ietf.org" , "payload@ietf.org" , "Ali C. Begen (abegen)" Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Thread-Index: AQHOQdoLz3rs6rgYyUO2pptDF+kp/pjnRTkw Date: Thu, 25 Apr 2013 18:57:46 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> In-Reply-To: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.88.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 18:57:49 -0000 I agree with the IANA update below for clarity. But practically speaking, P= AYLOAD will never assign another static payload, so we are effectively limi= ted to the dynamic range for all modern codecs unless PAYLOAD decides to re= allocate 35-63 from static to dynamic. I could only see that happening if p= roducts really need to support >32 codecs. (True codecs, not demux IDs for = different streams in bundles.) Mo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Dale R. Worley Sent: Thursday, April 25, 2013 1:26 PM To: mmusic@ietf.org Subject: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? I was looking at the IANA registry "RTP Payload types (PT) for standard audio and video encodings" (http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-para= meters-1) to see what the allowed dynamic payload types are, and what PTs are reserved to avoid confusion with RTCP. The unassigned range is: 35-71 Unassigned 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Unassigned 96-127 dynamic [RFC3551] Unfortunately, this doesn't reflect RFC 5761 ("Multiplexing RTP Data and Control Packets on a Single Port"), which gives these instructions in section 4: Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first. Since the entire range 64 to 95 is now reserved, the table should read: 35-63 Unassigned 64-71 Reserved for RTCP conflict avoidance [RFC5761] 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Reserved for RTCP conflict avoidance [RFC5761] 96-127 dynamic [RFC3551] IMHO, it would be helpful to get this table up to date with regard to the RFCs, even though it is marked "Closed". Do people agree with me on this? (And how do we go about it? I assume that the AD can route it to IANA.) (This also limits us to 61 PTs, which is another matter.) Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From adam@nostrum.com Thu Apr 25 12:29:40 2013 Return-Path: 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 D6EDD21F850E; Thu, 25 Apr 2013 12:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 BxN63Fn1bmap; Thu, 25 Apr 2013 12:29:40 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3052F21F84F5; Thu, 25 Apr 2013 12:29:40 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3PJTT13005817 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 14:29:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51798419.7070103@nostrum.com> Date: Thu, 25 Apr 2013 14:29:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------060404010905000303020204" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 25 Apr 2013 12:32:20 -0700 Cc: "Dale R. Worley" , "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 19:29:41 -0000 This is a multi-part message in MIME format. --------------060404010905000303020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/25/13 13:57, Mo Zanaty (mzanaty) wrote: > I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic. I think RFC 3551, section 3 is still the governing text on how RTP/AVP (and its related profiles) allocates payload types: > "This profile reserves payload type numbers in the range 96-127 > exclusively for dynamic assignment. Applications SHOULD first use > values in this range for dynamic payload types. Those applications > which need to define more than 32 dynamic payload types MAY bind > codes below 96, in which case it is RECOMMENDED that unassigned > payload type numbers be used first. However, the statically assigned > payload types are default bindings and MAY be dynamically bound to > new encodings if needed." (With particular emphasis on the final quoted sentence) So, _practically_ speaking, the proposed registry update does make a big difference: it clarifies that 64-71 and 77-95 are off limits. Also, _practically_ speaking, there's room to talk about 32 + 64 = 96 distinct codecs, since even the statically assigned payload types can be rebound. If you work with teams that are under the mistaken impression that you cannot dynamically re-bind the first 64 RTP payload types, I would beg you to disabuse them of that notion. /a --------------060404010905000303020204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 4/25/13 13:57, Mo Zanaty (mzanaty) wrote:
I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic.

I think RFC 3551, section 3 is still the governing text on how RTP/AVP (and its related profiles) allocates payload types:

>  "This profile reserves payload type numbers in the range 96-127
>   exclusively for dynamic assignment.  Applications SHOULD first use
>   values in this range for dynamic payload types.  Those applications
>   which need to define more than 32 dynamic payload types MAY bind
>   codes below 96, in which case it is RECOMMENDED that unassigned
>   payload type numbers be used first.  However, the statically assigned
>   payload types are default bindings and MAY be dynamically bound to
>   new encodings if needed."

(With particular emphasis on the final quoted sentence)

So, _practically_ speaking, the proposed registry update does make a big difference: it clarifies that 64-71 and 77-95 are off limits. Also, _practically_ speaking, there's room to talk about 32 + 64 = 96 distinct codecs, since even the statically assigned payload types can be rebound.

If you work with teams that are under the mistaken impression that you cannot dynamically re-bind the first 64 RTP payload types, I would beg you to disabuse them of that notion.

/a
--------------060404010905000303020204-- From magnus.westerlund@ericsson.com Thu Apr 25 23:50:38 2013 Return-Path: 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 9CD6E21F9743; Thu, 25 Apr 2013 23:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 QK2M1woNImUR; Thu, 25 Apr 2013 23:50:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DEFA321F856D; Thu, 25 Apr 2013 23:50:35 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-3c-517a23bab713 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 46.CC.19728.AB32A715; Fri, 26 Apr 2013 08:50:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 26 Apr 2013 08:50:34 +0200 Message-ID: <517A23B4.3060801@ericsson.com> Date: Fri, 26 Apr 2013 08:50:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adam Roach References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> In-Reply-To: <51798419.7070103@nostrum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvre4u5apAg5Vr1S32/F3EbjF1+WMW ixcP5jBZXLp4lsmBxWPK742sHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXRv/hJpaCbumK j49msjYw3hDtYuTkkBAwkbj+9zEbhC0mceHeeiCbi0NI4BSjxIWtJ5ghnOWMEheXTwGr4hXQ lri+9RQjiM0ioCqx/PlDZhCbTcBC4uaPRqAaDg5RgWCJra0xEOWCEidnPmEBsUUEFCXaDt8E K2cWqJO4cGM6O0i5sICvxOavchCr5jNK7Fx5DWw8J9Cq5zsfQB0nKbHlRTs7RK+exJSrLYwQ trxE89bZYDOFgOobmjpYJzAKzUKyehaSlllIWhYwMq9iZM9NzMxJLzfaxAgM5INbfqvuYLxz TuQQozQHi5I47wypykAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNsO1lyuli1MzzC/sXL2 0oi4X7dWFOdc4ep7FLHvePOfBcUcrxQ6wv5pTn1s+K7ubs1klu3RfNn/26sFd92q4hPh0M78 WxwxU+BI9wSd7t8d1kvrp+RO5jK6Ovfzxqm2HH9z7rQKTP6yp4Jvw261K5zVvj2FRYeuLpJd ev7i5oy+uWmcGx6FnlFiKc5INNRiLipOBAAk/f62MgIAAA== Cc: "payload@ietf.org" , "mmusic@ietf.org" Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 06:50:38 -0000 Hi, And to add to that. These limitations are only present given that you actually are using RTP and RTCP multiplexing. You can regain the whole 128 numbers by having RTP and RTCP separated. This quote from RFC 5761: Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first. I think is clear that you have 96 values for use. The MUST NOT is really to ensure that you will not have issues. Assuming tighter signalling control could have allowed dynamic blocking of the space, but that was deemed to complex and error prone. Regarding the IANA, Mo you have correctly identified the registry as closed and Adam pointed to the relevant text. Is this level of indirection so problematic that this registry needs a Note to the effect? Cheers Magnus On 2013-04-25 21:29, Adam Roach wrote: > On 4/25/13 13:57, Mo Zanaty (mzanaty) wrote: >> I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic. > > I think RFC 3551, section 3 is still the governing text on how RTP/AVP > (and its related profiles) allocates payload types: > >> "This profile reserves payload type numbers in the range 96-127 >> exclusively for dynamic assignment. Applications SHOULD first use >> values in this range for dynamic payload types. Those applications >> which need to define more than 32 dynamic payload types MAY bind >> codes below 96, in which case it is RECOMMENDED that unassigned >> payload type numbers be used first. However, the statically assigned >> payload types are default bindings and MAY be dynamically bound to >> new encodings if needed." > > (With particular emphasis on the final quoted sentence) > > So, _practically_ speaking, the proposed registry update does make a big > difference: it clarifies that 64-71 and 77-95 are off limits. Also, > _practically_ speaking, there's room to talk about 32 + 64 = 96 distinct > codecs, since even the statically assigned payload types can be rebound. > > If you work with teams that are under the mistaken impression that you > cannot dynamically re-bind the first 64 RTP payload types, I would beg > you to disabuse them of that notion. > > /a > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From worley@shell01.TheWorld.com Fri Apr 26 11:22:05 2013 Return-Path: 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 E454F21F9A1D for ; Fri, 26 Apr 2013 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 vv1DkAJrqavn for ; Fri, 26 Apr 2013 11:22:05 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id E622521F9A17 for ; Fri, 26 Apr 2013 11:22:04 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r3QIKrRq003265; Fri, 26 Apr 2013 14:20:55 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3QIKq4I3494740; Fri, 26 Apr 2013 14:20:52 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3QIKq913501941; Fri, 26 Apr 2013 14:20:52 -0400 (EDT) Date: Fri, 26 Apr 2013 14:20:52 -0400 (EDT) Message-Id: <201304261820.r3QIKq913501941@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Magnus Westerlund In-reply-to: <517A23B4.3060801@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> X-Mailman-Approved-At: Fri, 26 Apr 2013 13:48:00 -0700 Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 18:22:06 -0000 > From: Magnus Westerlund > > Regarding the IANA, Mo you have correctly identified the registry as > closed and Adam pointed to the relevant text. Is this level of > indirection so problematic that this registry needs a Note to the effect? (cleaning up my proposal) I use the IANA registries as the reference for how the various number spaces are managed. The current final rows of the Payload Types table read: 35-71 Unassigned 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Unassigned 96-127 dynamic [RFC3551] I find these to be problematic in several ways: 1) RFC 5761 is not mentioned at all, despite that it provides important modifications of the governing text in RFC 3551. This is a practical problem: Note that Adam quoted the text in RFC 3551, not the text in RFC 5761, and the 3551 text is now incorrect. 2) The range that is reserved for RTCP avoidance is not specified correctly. It's true that the rest of the RTCP avoidance range is marked "Unassigned", but in the context of RFC 3551, that suggests that they can be used as a secondary dynamic assignment area. 3) The range 35-71 should be marked more clearly as the secondary dynamic assignment area. Because of this, I suggest the following changes to this registry: 1) The "Reference" section should be changed from "[RFC3551]" to "[RFC5761][RFC3551]". 2) The final rows should be changed to 35-63 Unassigned/secondary dynamic area [RFC5761] 64-71 Reserved for RTCP conflict avoidance [RFC5761] 72-76 Reserved for RTCP conflict avoidance [RFC3551] 77-95 Reserved for RTCP conflict avoidance [RFC5761] 96-127 Dynamic [RFC3551] Dale From johnsonhammond1@hushmail.com Sat Apr 27 14:56:55 2013 Return-Path: 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 0933C21F983B for ; Sat, 27 Apr 2013 14:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] 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 cZCRIBZlEvdj for ; Sat, 27 Apr 2013 14:56:54 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id EE64621F983A for ; Sat, 27 Apr 2013 14:56:53 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 1207B31056 for ; Sat, 27 Apr 2013 17:30:41 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:30:40 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id D07BFE6736; Sat, 27 Apr 2013 17:30:40 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:30:40 -0400 To: payload@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173040.D07BFE6736@smtp.hushmail.com> Subject: [payload] Biggest Fake Conference in Computer Science X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:56:55 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.