From julian.spittka@skype.net Mon Jul 4 17:10:48 2011 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 8370411E8072 for ; Mon, 4 Jul 2011 17:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXRxphBeCi+E for ; Mon, 4 Jul 2011 17:10:48 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5B77521F87E5 for ; Mon, 4 Jul 2011 17:10:47 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 7FB857FD; Tue, 5 Jul 2011 02:10:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=reply-to:from :to:cc:subject:date:message-id:mime-version:content-type: content-transfer-encoding; s=mx; bh=RhWbjf29Xpmt9uN4fUr8Rp8FMKo= ; b=f5Olwko8VFP5rlUlERzepBSPi2+x+lvTI9BFvqtKEHvyRtf35F3Z0mBUjrDB UcRoax6LQhKO81Om+rZRmOKqk6EWKQzPJzuzNSFXPPW4upS1VTgSq90RSfhmurIO /jpnIfkk50nYIGFea8SFvpyYQTsWXVq9t2XdSHBkkEpsdFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=reply-to:from:to:cc :subject:date:message-id:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=JWsysGgshDleS00twkOKmw BxzbpP3DZOHlJdam62rJ/vzORni2qk02/7CgOD91uob+lOxC0h7YFMvVHkgPWVx3 AwLblV0L/2mSa0xTaJCA+0AizZv5lJFaHioF4QNlXs44SKtm2U2+pDyqqRxnNZSr uNXLFP7MyvXpMpKAoLDHE= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 7E6167F8; Tue, 5 Jul 2011 02:10:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 63A263506E74; Tue, 5 Jul 2011 02:10:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHyVCg2hslEt; Tue, 5 Jul 2011 02:10:45 +0200 (CEST) Received: from outlook (p50873087.dip.t-dialin.net [80.135.48.135]) by zimbra.skype.net (Postfix) with ESMTPSA id 271033506E36; Tue, 5 Jul 2011 02:10:45 +0200 (CEST) From: "Julian Spittka" To: Date: Tue, 5 Jul 2011 02:10:48 +0200 Organization: Skype Message-ID: <00f601cc3aa7$ff4c9460$fde5bd20$@spittka@skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw6pw9jgR5RV21fTeKHP+yx4tKudAAANRXg Content-Language: en-us Cc: 'Koen Vos' , 'Jean-Marc Valin' Subject: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: julian.spittka@skype.net 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, 05 Jul 2011 00:10:48 -0000 All, Please find a first draft "draft-spittka-payload-rtp-opus-00" for the "RTP Payload Format and File Storage Format for Opus Speech and Audio Codec" uploaded at https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/. Any feedback, questions, or comments are highly welcome. Best Regards, Julian. --- Julian Spittka Skype see & chat: julian_spittka write: julian.spittka@skype.net From ron.even.tlv@gmail.com Tue Jul 5 14:01:25 2011 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 2D5ED21F8829; Tue, 5 Jul 2011 14:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+C7cqPlxrac; Tue, 5 Jul 2011 14:01:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42F7021F8828; Tue, 5 Jul 2011 14:01:24 -0700 (PDT) Received: by wyj26 with SMTP id 26so4982565wyj.31 for ; Tue, 05 Jul 2011 14:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=VugoYNZUmghdisIcJgkUDod56EBVfUebqUrhJqpmSrw=; b=FkqF4DgUz42uiTpPwecTOQXDjxzluSV5N6+Qv/KXz/5JPgoVRAPrMeuW7PPXuTzvc2 KasFNVoIl7vwAGwV8rQpHlSY/OoRczUF04UeOYWcCk5hhPDrXsDstMWATvFelsN5CZN6 rNtAsJLZfzqpN3a+tqsO1E2oBlBXFUWmB0Bnk= Received: by 10.216.62.203 with SMTP id y53mr6416843wec.108.1309899682920; Tue, 05 Jul 2011 14:01:22 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-43-124.red.bezeqint.net [79.176.43.124]) by mx.google.com with ESMTPS id s47sm3876124weq.6.2011.07.05.14.01.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 14:01:21 -0700 (PDT) From: "Roni Even" To: , References: <4e12556d.454a2a0a.70a9.3676SMTPIN_ADDED@mx.google.com> In-Reply-To: <4e12556d.454a2a0a.70a9.3676SMTPIN_ADDED@mx.google.com> Date: Tue, 5 Jul 2011 23:59:00 +0300 Message-ID: <4e137ba1.c5ead80a.0f49.5e49@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw6pw9jgR5RV21fTeKHP+yx4tKudAAAAQjAACvAZVA= Content-Language: en-us X-Mailman-Approved-At: Tue, 05 Jul 2011 21:44:13 -0700 Cc: payload@ietf.org Subject: Re: [payload] [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 05 Jul 2011 21:01:25 -0000 Hi, I noticed the discussion that started on the codec mailing list. Since this work will be handled in the payload WG please send the comments to payload@ietf.org Thanks Roni Even Payload co-chair > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Julian Spittka > Sent: Tuesday, July 05, 2011 3:06 AM > To: codec@ietf.org > Subject: [codec] RTP Payload Format and File Storage Format for Opus > Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 > > All, > > Please find a first draft "draft-spittka-payload-rtp-opus-00" for the > "RTP > Payload Format and File Storage Format for Opus Speech and Audio Codec" > uploaded at > https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/. > > Any feedback, questions, or comments are highly welcome. > > Best Regards, > > Julian. > > --- > Julian Spittka > Skype > > see & chat: julian_spittka > write: julian.spittka@skype.net > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Tue Jul 5 14:17:44 2011 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 EA61C21F89D2; Tue, 5 Jul 2011 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIRNfhoHx4WP; Tue, 5 Jul 2011 14:17:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5DFB21F8989; Tue, 5 Jul 2011 14:17:42 -0700 (PDT) Received: by wwe5 with SMTP id 5so4270398wwe.13 for ; Tue, 05 Jul 2011 14:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=C9kRzzvUQN2ptGAxryZ46mFUj6UQs9bSyppDOm0kqkk=; b=O1INOwDxMw6sVdpJOfYQ0fWuGg/bkJ9xghXVg+hg2bTNzGbqTCifc8qkYF0iSLcYad aUMCInBrqLpuFHCnk1PmefP0vmMYjNFUtD6LMtoYh7hKX+xf3s48B7IwjRMpvEFDndIq 6/IqeB1eV0tA5MkYIFa435kGoPdSxaxkSXxj8= Received: by 10.217.7.3 with SMTP id z3mr6406250wes.68.1309900661536; Tue, 05 Jul 2011 14:17:41 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-43-124.red.bezeqint.net [79.176.43.124]) by mx.google.com with ESMTPS id n21sm3879955wed.19.2011.07.05.14.17.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 14:17:40 -0700 (PDT) From: "Roni Even" To: , References: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> <4E133E21.3050001@fas.harvard.edu> In-Reply-To: <4E133E21.3050001@fas.harvard.edu> Date: Wed, 6 Jul 2011 00:15:21 +0300 Message-ID: <4e137f74.9545d80a.4f62.65af@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw7MjMua76S7kZPQoSi4yd0CWWc9wAJXgQQ Content-Language: en-us X-Mailman-Approved-At: Tue, 05 Jul 2011 21:44:13 -0700 Cc: codec@ietf.org, payload@ietf.org Subject: Re: [payload] [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 05 Jul 2011 21:17:45 -0000 Hi, I find it difficult to address all you comments being in XML patch format. In general the payload specification should provide enough information that will enable the reader to create or parse the RTP payload without understanding the codec payload based on the payload specification. As such it is useful to provide information that will explain the general concepts of the codec and the optional parameters. So I find sections 1 and 3 useful and they should be in the document Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Benjamin M. Schwartz > Sent: Tuesday, July 05, 2011 7:39 PM > To: julian.spittka@skype.net > Cc: codec@ietf.org > Subject: Re: [codec] RTP Payload Format and File Storage Format for > Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 > > On 07/04/2011 08:06 PM, Julian Spittka wrote: > > Any feedback, questions, or comments are highly welcome. > > Thank you for doing this work. I think your proposed RTP and SDP > formats are very nice and a good step for us. > > I have a few comments. > > 1. I think the description of Opus should be removed. There's no need > to duplicate the contents of the Opus RFC. > > 2. I think the payload specification should make (almost) no mention > of Opus frames, modes, etc. These aspects of Opus are entirely > internal to the payload, which is a "black box". As far as the RTP > specification is concerned, Opus consists of (almost-)arbitrary- > duration "packets" and that's it. > > 3. To avoid confusion, I think we should be very careful and clear > about the distinction between audio bandwidth and samplerate, as their > relationship in Opus is far from simple. > > I have implemented these ideas, along with a few minor changes, as a > patch to the draft .xml, attached. Please feel free to discard this > patch; I mean it only as a way to communicate my suggestions more > clearly. > > --Ben From abegen@cisco.com Wed Jul 6 08:35:53 2011 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 F2EB321F8784 for ; Wed, 6 Jul 2011 08:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcl2i-ieAa54 for ; Wed, 6 Jul 2011 08:35:52 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 5133C21F8782 for ; Wed, 6 Jul 2011 08:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=273; q=dns/txt; s=iport; t=1309966552; x=1311176152; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=vT0TED1oz/ENAvxUkraYsxiYqhB5xXqJ1izZiFmjwk0=; b=iQBpf1KMY8K4Ynq73qa8G1aUXC73EFVzo53u7U5Z/TWFcbe9frHkXklO InRq/jtcDyL8C6+0Hy4FOXHZc0uXXVLPmheydwFrCWPtUDalK5wUaD0JG UKU5Agm6ALtyrYACY9NhjhemgMbdNg9HjiAQ8GgMA7wGSJGavC6ct+DAM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAIAAKAFE6rRDoG/2dsb2JhbABTmRmObHesdoEinieGNwSHRo9+i1o X-IronPort-AV: E=Sophos;i="4.65,487,1304294400"; d="scan'208";a="291322028" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-4.cisco.com with ESMTP; 06 Jul 2011 15:35:48 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p66FZl3M003637 for ; Wed, 6 Jul 2011 15:35:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 08:35:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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, 6 Jul 2011 08:35:05 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F692760@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-payload-rtp-klv-01 Thread-Index: Acw78gsfFCNII3eVSFOhZKDVFXst2g== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 06 Jul 2011 15:35:45.0747 (UTC) FILETIME=[5F835A30:01CC3BF2] Subject: [payload] WGLC for draft-ietf-payload-rtp-klv-01 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, 06 Jul 2011 15:35:53 -0000 Hi everyone, This is to announce a 2-week WGLC for the following draft (ends July = 20th): http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ Please review the document and post any questions/concerns you have to = the mailing list. Thanks. -acbegen From fluffy@cisco.com Wed Jul 6 09:43:45 2011 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 691DB21F8894; Wed, 6 Jul 2011 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd6fA1dJgcJj; Wed, 6 Jul 2011 09:43:44 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 9714C21F8895; Wed, 6 Jul 2011 09:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1121; q=dns/txt; s=iport; t=1309970624; x=1311180224; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HnvptrznsMrgGQcbY7JH82Ch6llBjjIZmfQHyXZtwZ0=; b=EM26xsNI2u7EYI5y3OxrogQOYQBQlX6twZGZdcThi1seyiQf6E6yVp9T CjKmYDrR+T3HV5IpS07bQTNc9pGS9h+Z+i4eIUG07CDqn9fIMPlwwP8hi GiL3PicZZV2T1jGlV32dS8S9phd3Oapdxa9gBvTnE0f1rCVMPvQIl5TdH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHePFE6rRDoJ/2dsb2JhbABTqAV3iHqlO54WhjcEh0aKe4R6i2I X-IronPort-AV: E=Sophos;i="4.65,488,1304294400"; d="scan'208";a="362469463" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2011 16:43:44 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p66GhhRr021391; Wed, 6 Jul 2011 16:43:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> Date: Wed, 6 Jul 2011 10:43:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <75A39260-8D02-4F1F-B5F1-3A3BA09D8F43@cisco.com> References: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> To: julian.spittka@skype.net, payload@ietf.org X-Mailer: Apple Mail (2.1084) Cc: codec@ietf.org Subject: Re: [payload] [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 06 Jul 2011 16:43:45 -0000 I would prefer to see the file format separated into a separate draft = for two reason. One, it allows an implementation to say they do RFC XXXX = and have that be clear if the mean the RTP payload or the file format. = Two, I suspect the file format conversation might take longer to = resolve.=20 Cullen PS - this discussion and draft needs to happen in the payloads WG, feel = free to CC the rtcweb@ietf.org mailing list. On Jul 4, 2011, at 6:06 PM, Julian Spittka wrote: > All, >=20 > Please find a first draft "draft-spittka-payload-rtp-opus-00" for the = "RTP > Payload Format and File Storage Format for Opus Speech and Audio = Codec" > uploaded at > https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/.=20 >=20 > Any feedback, questions, or comments are highly welcome. >=20 > Best Regards, >=20 > Julian. >=20 > --- > Julian Spittka > Skype >=20 > see & chat: julian_spittka > write: julian.spittka@skype.net >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From magnus.westerlund@ericsson.com Thu Jul 7 03:53:35 2011 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 D8E4021F87F8; Thu, 7 Jul 2011 03:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RmjoJYNPJPV; Thu, 7 Jul 2011 03:53:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E9D0F21F85C5; Thu, 7 Jul 2011 03:53:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-1f-4e15902df65e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BE.AB.09774.D20951E4; Thu, 7 Jul 2011 12:53:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 7 Jul 2011 12:53:31 +0200 Message-ID: <4E15902A.3010107@ericsson.com> Date: Thu, 7 Jul 2011 12:53:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> <75A39260-8D02-4F1F-B5F1-3A3BA09D8F43@cisco.com> In-Reply-To: <75A39260-8D02-4F1F-B5F1-3A3BA09D8F43@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "codec@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 07 Jul 2011 10:53:36 -0000 On 2011-07-06 18:43, Cullen Jennings wrote: > > I would prefer to see the file format separated into a separate draft for two reason. One, it allows an implementation to say they do RFC XXXX and have that be clear if the mean the RTP payload or the file format. Two, I suspect the file format conversation might take longer to resolve. > > Cullen > > PS - this discussion and draft needs to happen in the payloads WG, feel free to CC the rtcweb@ietf.org mailing list. Cullen, I assume you mean CODEC WG rather than the RTCWEB WG. Cheer 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 fluffy@cisco.com Thu Jul 7 07:29:28 2011 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 E483B11E8071; Thu, 7 Jul 2011 07:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfSUzQJe1GLw; Thu, 7 Jul 2011 07:29:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A92E911E807A; Thu, 7 Jul 2011 07:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=743; q=dns/txt; s=iport; t=1310048966; x=1311258566; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4V+rUKkxwRWJF2WRGT0CuqXUFDcZVa6dy/tbidlW8oM=; b=J/x+6C72WtcSrb+VIuNR6RjjdC7+AVo5ovEqmrHk2qsx0Jhw+z8oXHls Mzx99tV27MgGEzSCtW2X5RZIvJFezClhiv6Is9LzvTxXHwNzj6BRrMTMY OPg0DKxM96RtgiUPjOVsJsdeWnkAk/ZSvXVwiEtntV7HjjJDiCq3OazVW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPnBFU5Io8US/2dsb2JhbABTqBt3iHukaZ12hjgEh0mKfYR9i2M X-IronPort-AV: E=Sophos;i="4.65,493,1304294400"; d="scan'208";a="100149706" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2011 14:29:23 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p67ETI03032206; Thu, 7 Jul 2011 14:29:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E15902A.3010107@ericsson.com> Date: Thu, 7 Jul 2011 08:29:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> <75A39260-8D02-4F1F-B5F1-3A3BA09D8F43@cisco.com> <4E15902A.3010107@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "codec@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 07 Jul 2011 14:29:29 -0000 On Jul 7, 2011, at 4:53 AM, Magnus Westerlund wrote: > On 2011-07-06 18:43, Cullen Jennings wrote: >>=20 >> I would prefer to see the file format separated into a separate draft = for two reason. One, it allows an implementation to say they do RFC XXXX = and have that be clear if the mean the RTP payload or the file format. = Two, I suspect the file format conversation might take longer to = resolve.=20 >>=20 >> Cullen >>=20 >> PS - this discussion and draft needs to happen in the payloads WG, = feel free to CC the rtcweb@ietf.org mailing list. >=20 > Cullen, I assume you mean CODEC WG rather than the RTCWEB WG. yes - thank you. too much RTCweb on my mind and was just typing while on = a call. Always bad to do From bmschwar@fas.harvard.edu Fri Jul 8 21:30:21 2011 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 D373921F8A14; Fri, 8 Jul 2011 21:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEMdd792ExHJ; Fri, 8 Jul 2011 21:30:21 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC1E21F89D8; Fri, 8 Jul 2011 21:30:18 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us18.unix.fas.harvard.edu (Postfix) with ESMTP id 5F6AB4D5E06; Sat, 9 Jul 2011 00:30:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=PHexp4Z0S2Wwybm r7+gLUHhtmvfdG0JjWkn1OduhsLE=; b=qEsKLxddz8fwTmrujtD5ZHgPTcOSBNQ 5gf9SpLQNzfGBjDbiP6KBF5YMaGsWSB24f1atD77MVpIV8NuVAZGBzplvZn6SaUd jcdkxWo4iIQQwqr2L4Dh6l0Phhwbvij1etXNcfR36N/wHGa2IWK1oS+vhxCQPr8N WBp7Y+gQb12o= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=tbxg53AKI UOXCIHrYwbPPXpkbDWlxNU3MrYNKIGvhQ0QC3ORO0wIdUt3iQ6DEh9AIiu+0/D0n UDPNISVZiqphQlLzbfMOQgqnLpe7AFYGJjuDmSoKIaGERkx0ljGmZU6Gi+l5pkL8 5Q6IuXRja3IEfEG/eSH1rs8jhoTmnV+wm0= Received: from [192.168.1.141] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 491F94D5DFD; Sat, 9 Jul 2011 00:30:17 -0400 (EDT) Message-ID: <4E17D958.6060903@fas.harvard.edu> Date: Sat, 09 Jul 2011 00:30:16 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Roni Even References: <00f501cc3aa7$551264c0$ff372e40$@spittka@skype.net> <4E133E21.3050001@fas.harvard.edu> <4e137f74.9545d80a.4f62.65af@mx.google.com> In-Reply-To: <4e137f74.9545d80a.4f62.65af@mx.google.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26B74FE2FCAF403AA9EF9243" Cc: codec@ietf.org, payload@ietf.org Subject: Re: [payload] [codec] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bens@alum.mit.edu 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, 09 Jul 2011 04:30:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26B74FE2FCAF403AA9EF9243 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/05/2011 05:15 PM, Roni Even wrote: > In general the payload specification should provide enough information = that > will enable the reader to create or parse the RTP payload without > understanding the codec payload based on the payload specification. As = such > it is useful to provide information that will explain the general conce= pts > of the codec and the optional parameters. So I find sections 1 and 3 us= eful > and they should be in the document Despite having removed Section 3 in my suggested edit, I agree. The payload document should present relevant information about Opus, such as the available frame sizes and the significance of the low-bitrate redundancy feature. However, it should not discuss non-normative behaviors of the reference coder, or internal details such as subsampling= and coding modes. The most important thing to understand about Opus coding modes is that th= e encoder can, and does, dynamically switch among them on a packet-by-packe= t basis in order to optimize quality. The draft seems to have been written= under the assumption that a stream, once started in a particular mode, ma= y not be able to switch to other modes. This is no longer true, as explained in the latest Opus draft. --Ben --------------enig26B74FE2FCAF403AA9EF9243 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4X2VgACgkQUJT6e6HFtqTSrwCgnuZKzXwev2kNWyQnd4gw82sK pxUAnjSsHHy/ULFSgTvGRCGOK7VS8+S9 =b+En -----END PGP SIGNATURE----- --------------enig26B74FE2FCAF403AA9EF9243-- From Even.roni@huawei.com Mon Jul 11 07:27:30 2011 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 980BE21F8C0A; Mon, 11 Jul 2011 07:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OzMSYGz2Kzt; Mon, 11 Jul 2011 07:27:29 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5D25521F8C05; Mon, 11 Jul 2011 07:27:29 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO600DVXATPMM@szxga05-in.huawei.com>; Mon, 11 Jul 2011 22:27:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO600G24ATOW9@szxga05-in.huawei.com>; Mon, 11 Jul 2011 22:27:25 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO600DLFATFOT@szxml11-in.huawei.com>; Mon, 11 Jul 2011 22:27:24 +0800 (CST) Date: Mon, 11 Jul 2011 17:24:43 +0300 From: Roni Even In-reply-to: <00f601cc3aa7$ff4c9460$fde5bd20$%spittka@skype.net> To: payload@ietf.org, codec@ietf.org Message-id: <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acw6pw9jgR5RV21fTeKHP+yx4tKudAAANRXgAUnhLaA= References: <00f601cc3aa7$ff4c9460$fde5bd20$%spittka@skype.net> Cc: 'Jean-Marc Valin' Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 11 Jul 2011 14:27:30 -0000 Hi, I reviewed the draft and it is a good start. Based on Cullen recommendation I am posting to both codec and payload mailing lists. I did not review the storage format since I understand that it will be removed from this draft and discussed separately. I have some comments 1. In the introduction "thus, making it the codec of choice for various applications using the Internet or similar networks" maybe change to "thus, making it useful for various applications using the Internet or similar networks". The first sentence have a market share declaration. 2. In section 3.2 when you talk about network bandwidth what does it mean. Do you calculate it based on the whole IP packet, the RTP packet or just the opus payload. I assume it is the last one so please define the term network bandwidth. 3. in section 3.2.1 you talk about "average bit rate". How do you measure average bit rate, is it average in 3 minutes, in 1 minute? 4. In section 3.4 "The decision to send "in-band" FEC information is entirely controlled by the encoder ". This is true only if the decoder signaled support for FEC. 5. In section 3.5 "If a decoder can not take advantage of the benefits of a stereo signal this SHOULD be indicated at the time a session is set up. In that case the sending side SHOULD NOT send stereo signals as it leads to an inefficient usage of network bandwidth". I think that the SHOULD NOT need to be MUST NOT. Is there a reason for the sender to ignore the receiver request? 6. In section 4.1 is there a specific reason for stating "The receiving side MUST be prepared to receive duplicates of RTP packets. Only one of those payloads MUST be provided to the Opus decoder for decoding and others MUST be discarded" since this is a standard RTP behavior. The duplicate packets can be reported in RTCP. 7. In section 4.2 "The maximum packet length is limited to the amount of encoded data representing 120 ms of speech or audio data". I think that is should also be limted by the MTU size if you do not want to fragment the RTP packets. 8.In section 6 the whole section talks about what an encoder can do and not about how to find and report congestion I think that maybe instead of "It is RECOMMENDED that congestion control is applied during the transmission of Opus encoded data ." say " that "receivers MUST monitor the packet loss rate to ensure congestion is not caused, following the guidelines in Section 2 of RFC 3551." . 9. In section 7.1 you mention a required parameter "Rate". Is this a parameter that need to be specified in the SDP. You only need to say in the mapping to SDP that The RTP clock rate in "a=rtpmap" MUST be 48000. You example 1 does not have the rate parameter just a=rtpmap:101 opus/48000 10. In section 7.1 maxcodedaudiobandwidth. Is this relay an issue to signal the sampling rate. Isn't it enough to have the maximum bandwidth which will affect the sampling rate according to table 1. 11. In section 7.1 I noticed that ptime, maxptime and minptime signaled by the receiver are just recommendations and not the desired value as in RFC 3264, and the sender can send any size it wishes upto 120. So what is the benfit for the receiver to signal it. I thought that this is a receive capability. 12. In section 71. Why define maxaveragebitrate and not use the SDP b= parameter. 13. In section 7.1 Why need the stereo parameter there is the number of channels in the rtpmap. It should say a=rtpmap:101 opus/48000/2 instead of a=rtpmap:101 opus/48000 and stereo=1. 14.In 7.1 the CBR parameter let the decoder specify if to use CBR or VBR. Yet the CBR does not specify a value making it look a bit like VBR. I think that there should be an option for the receiver to ask for a specific CBR rate. 15.About fec and useinbandfec. I did not see if there an overhead for using fec that should be reflected in the bandwidth considerations. Some nits 1. In the introduction " The codec has a very low algorithmic delay and is is" 2. In 4.1 " according to Table 2 to determine the RTP timestamp" maybe " according to Table 2 to determine the increment in RTP timestamp" Roni Even as individual I would like to have two comment as Payload WG co-chair 1. Person & email address to contact for further information: SILK Support silksupport@skype.net I think IANA will prefer a person and not a general email address 2. The change controller Should be "IETF Payload working group delegated from the IESG.". I think this was a conclusion on previous discussion > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Julian Spittka > Sent: Tuesday, July 05, 2011 3:11 AM > To: payload@ietf.org > Cc: 'Koen Vos'; 'Jean-Marc Valin' > Subject: [payload] RTP Payload Format and File Storage Format for Opus > Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 > > All, > > Please find a first draft "draft-spittka-payload-rtp-opus-00" for the > "RTP > Payload Format and File Storage Format for Opus Speech and Audio Codec" > uploaded at > https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/. > > Any feedback, questions, or comments are highly welcome. > > Best Regards, > > Julian. > > --- > Julian Spittka > Skype > > see & chat: julian_spittka > write: julian.spittka@skype.net > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From bmschwar@fas.harvard.edu Mon Jul 11 07:53:48 2011 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 9958E21F8C85; Mon, 11 Jul 2011 07:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efen8oFhTybO; Mon, 11 Jul 2011 07:53:47 -0700 (PDT) Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu [140.247.35.201]) by ietfa.amsl.com (Postfix) with ESMTP id B187C21F8C83; Mon, 11 Jul 2011 07:53:47 -0700 (PDT) Received: from us25.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us25.unix.fas.harvard.edu (Postfix) with ESMTP id 0D1641D7552; Mon, 11 Jul 2011 10:53:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=j3XDDst7PZWkbIp MFqdQ9XysYK4ua8KJkatJivqFbKo=; b=sD+LkK4Y9KJB8KWKvMIDfxK7xOAqUY9 9Kfbuj20CdM0e8GNAO+5DSE4tmP+p42AI03JGQ2H/UdV63A61XG2Bod70FJy7ymT h+RGU0vzHQEJfSJUBrMk7DGyv1XsAiWTKtInTUTkwjeeDa8jFDOgSzmney41e2Lz IMoPfZoU/zyI= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=iXFAtCM+X o00J/idudyyikSN7dxqPvqy3nOob70X/E2BDkcmlLCFiY6BSqQ9yXVNq7h/yHZct Fv3kUTXMTkZnsavG+bs0oV6v5TqFXVpOZcgK9KKRXGsCeL/T7FqIefcuSlq2bdeS A8dgzA534OlwxffO2S9l+4SHPNE8mX8eiM= Received: from [192.168.1.141] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us25.unix.fas.harvard.edu (Postfix) with ESMTPSA id EF9D21D752F; Mon, 11 Jul 2011 10:53:46 -0400 (EDT) Message-ID: <4E1B0E78.8090005@fas.harvard.edu> Date: Mon, 11 Jul 2011 10:53:44 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Roni Even References: <00f601cc3aa7$ff4c9460$fde5bd20$%spittka@skype.net> <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com> In-Reply-To: <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig865375B2228B1DC3ACBA6B69" Cc: 'Jean-Marc Valin' , codec@ietf.org, payload@ietf.org Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bens@alum.mit.edu 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, 11 Jul 2011 14:53:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig865375B2228B1DC3ACBA6B69 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/11/2011 10:24 AM, Roni Even wrote: > 5. In section 3.5 "If a decoder can not take advantage of the benefits = of a > stereo signal this SHOULD be indicated at the time a session is set u= p. > In that case the sending side SHOULD NOT send stereo signals as it le= ads > to an inefficient usage of network bandwidth". I think that the SHOULD = NOT > need to be MUST NOT. Is there a reason for the sender to ignore the rec= eiver > request? If a stream is being sent to many recipients, most of whom prefer stereo,= then it may be appropriate to send a single stereo stream to all recipients, rather than increase the encoder CPU requirements by encoding= multiple versions of the stream. > 14.In 7.1 the CBR parameter let the decoder specify if to use CBR or VB= R. > Yet the CBR does not specify a value making it look a bit like VBR. I t= hink > that there should be an option for the receiver to ask for a specific C= BR > rate. I think the implication was that in CBR mode, "maxaveragebitrate" also sets a hard ceiling on the size of an individual packet. I agree that this is not a perfect solution. Personally, I would prefer that the receiver indicate both a hard limit and a soft target (or similar). --Ben --------------enig865375B2228B1DC3ACBA6B69 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4bDnkACgkQUJT6e6HFtqS7PwCeI+2lpaBhUFxIqBr2bd6Gyw4N F3IAn1h+xPBFhB7BmMY/eoQZoFOUOsNq =Y+ua -----END PGP SIGNATURE----- --------------enig865375B2228B1DC3ACBA6B69-- From Even.roni@huawei.com Mon Jul 11 11:57:10 2011 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 4E2B421F8A51 for ; Mon, 11 Jul 2011 11:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-2.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MANGLED_WORKNG=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChYw7L8wMvSd for ; Mon, 11 Jul 2011 11:57:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 090FF21F85F9 for ; Mon, 11 Jul 2011 11:56:50 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO600461NAO32@szxga05-in.huawei.com> for payload@ietf.org; Tue, 12 Jul 2011 02:56:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO600JU2NAMY5@szxga05-in.huawei.com> for payload@ietf.org; Tue, 12 Jul 2011 02:56:48 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO600LEINA6NV@szxml12-in.huawei.com>; Tue, 12 Jul 2011 02:56:46 +0800 (CST) Date: Mon, 11 Jul 2011 21:53:58 +0300 From: Roni Even To: ietf-types@iana.org Message-id: <00c201cc3ffb$ec0da480$c428ed80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h2dREk8IVohaJEj+d5EhTA)" Content-language: en-us Thread-index: Acw/++NrLX+2OlvpS3OJHyUSrZ73ag== Cc: draft-ietf-payload-rfc3189bis.all@tools.ietf.org, payload@ietf.org Subject: [payload] Updating the registration of audio and video DV media subtype 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, 11 Jul 2011 18:57:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_h2dREk8IVohaJEj+d5EhTA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, draft-ietf-payload-rfc3189bis-01 has passed Working Group Last Call in the Payload Working Group. Note that it an update to existing RFC3189 registrations http://www.iana.org/assignments/rtp-parameters for DV media subtype. The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1 The information is also available below. I noticed that there is a need to change the change controller from " IETF Audio/Video Transport working group delegated from the IESG" to " IETF Payload working group delegated from the IESG" Other comments on the registration are welcome. Thanks Roni Even Payload co-chair 3.1.1. Media Type Registration for DV Video Type name: video Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV video can be transmitted with RTP as specified in RFCXXXX(This document). Other transport methods are not specified. Security considerations: See Section 4 of RFCXXXX (This document). Interoperability considerations: NONE Public specification: IEC 61834 Standard SMPTE 314M SMPTE 370M RFCXXXX (This document) SMPTE 306M (for backward compatibility). Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: NONE Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@ni.aist.go.jp Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time. Author: Katsushi Kobayashi Change controller: IETF Audio/Video Transport working group delegated from the IESG 3.1.2. Media Type Registration for DV Audio Type name: audio Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV audio can be transmitted with RTP as specified in RFCXXXX(This document). Other transport methods are not specified. Security considerations: See Section 4 of RFCXXXX (This document). Interoperability considerations: NONE Published specification: IEC 61834 Standard SMPTE 314M SMPTE 370M RFCXXXX (This document) SMPTE 306M (for backward compatibility). Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: NONE Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@ni.aist.go.jp Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time. Author: Katsushi Kobayashi Change controller: IETF Audio/Video Transport working group delegated from the IESG --Boundary_(ID_h2dREk8IVohaJEj+d5EhTA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

draft-ietf-payload-rfc3189bis-01 has passed Working Group Last Call in the Payload Working Group.

 

Note that it an update to existing RFC3189 registrations http://www.iana.org/assignments/rtp-parameters for DV media subtype.

 

The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1

nbsp;

The information is also available below.

 

I noticed that there is a need to change the change controller from " IETF Audio/Video Transport working group delegated from the   IESG"  to " IETF Payload  working group delegated from the   IESG"

 

 

Other comments on the registration are welcome.

 

Roni Even

Payload co-chair

 

 

3.1.1.  Media Type Registration for DV Video

  

 

Type name:  video

 

   Subtype name:  DV

 

 

      encode:  type of DV format.  Permissible values for encode are

         SD-VCR/525-60,

         SD-VCR/625-50,

         HD-VCR/1125-60,

         HD-VCR/1250-50,

    ; & DL-VCR/525-60,

         SDL-VCR/625-50,

         314M-25/525-60,

         314M-25/625-50,

         314M-50/525-60,

         314M-50/625-50,

         370M/1080-60i,

  ; & bsp;  370M/1080-50i,

         370M/720-60p,

         370M/720-50p,

         306M/525-60 (for backward compatibility),

         and 306M/625-50 (for backward compatibility).

 

   Optional parameters:

 

      audio:  whether the DV stream includes audio data or not.

         Permissible values for audio are bundled and none.  Defaults to  none.

 

   Encoding considerations:

 

         DV video can be transmitted with RTP as specified in RFCXXXX(This document).  Other transport methods are not specified.

    Security considerations:

 

         See Section 4 of RFCXXXX (This document).

 

   Interoperability considerations:  NONE

 

   Public specification:

 

     &nbs p;  FR style='font-family:"Courier New"'>IEC 61834 Standard

         SMPTE 314M

         SMPTE 370M

         RFCXXXX (This document)

         SMPTE 306M (for backward compatibility).

 

   Applications that use this media type:  Audio and video s treaming o:p>

 

   Additional information:  NONE

 

   Person & email address to contact for further information:

 

         Katsushi Kobayashi

 

         e-mail: ikob@ni.aist.go.jp

 

   Intended usage:  COMMON

 

   Restrictions on usage:  This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550).  Transfer within other framing protocols is not defined at this time.

 

   Author:

 

         Katsushi Kobayashi

< n style='font-family:"Courier New"'> 

   Change controller:

 

         IETF Audio/Video Transport working group delegated from the

         IESG

 

 

3.1.2.  Media Type Registration for DV Audio

  <    Type name:  audio

 

   Subtype name:  DV

 

   Required parameters:

 

      encode:  type of DV format.  Permissible values for encode are

         SD-VCR/525-60,

         HD-VCR/1125-60,

         HD-VCR/1250-50,

         SDL-VCR/525-60,

         SDL-VCR/625-50,

         314M-25/525-60,

         314M-25/625-50,

         314M-50/625-50,

         370M/1080-60i,

         370M/1080-50i,

         370M/720-60p,

         370M/720-50p,

         306M/525-60 (for backward compatibility),

         and 306M/625-50 (for backward compatibility).

 

   Optional parameters:

 

      audio:  whether the DV stream includes audio data or not.

         Permissible values for audio are bundled and none.  Defaults to none.

 

   Encodin g consid n>

 

         DV audio can be transmitted with RTP as specified in RFCXXXX(This document).  Other transport methods are not specified.

 

   Security considerations:

 

         See Section 4 of RFCXXXX (This document).

 

 &nb sp; Inte ns:  NONE

 

   Published specification:

 

         IEC 61834 Standard

         SMPTE 314M

         SMPTE 370M

         RFCXXXX (This document)< /p>

         SMPTE 306M (for backward compatibility).

 

   Applications that use this media type:  Audio and video streaming and conferencing tools.

 

   Additional information:  NONE

 

   Person & email address to contact for further information:

         Katsushi Kobayashi

 

         e-mail: ikob@ni.aist.go.jp

 

   Intended usage:  COMMON

 

   Restrictions on usage:  This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550).  Transfer      within other framing protocol time.

 

 

   Author:

 

         Katsushi Kobayashi

 

   Change controller:

 

         IETF Audio/Video Transport worki ng group /o:p>

         IESG

 

 

--Boundary_(ID_h2dREk8IVohaJEj+d5EhTA)-- From randell-ietf@jesup.org Mon Jul 11 13:24:18 2011 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 72B5E11E81F2 for ; Mon, 11 Jul 2011 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ze9+KibUUsL for ; Mon, 11 Jul 2011 13:24:17 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 796D411E818F for ; Mon, 11 Jul 2011 13:24:17 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QgN1c-0001CA-Kq for payload@ietf.org; Mon, 11 Jul 2011 15:24:16 -0500 Message-ID: <4E1B5BCD.7050708@jesup.org> Date: Mon, 11 Jul 2011 16:23:41 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: payload@ietf.org References: <00f601cc3aa7$ff4c9460$fde5bd20$%spittka@skype.net> <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com> In-Reply-To: <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 11 Jul 2011 20:24:18 -0000 On 7/11/2011 10:24 AM, Roni Even wrote: > 11. In section 7.1 I noticed that ptime, maxptime and minptime signaled by > the receiver are just recommendations and not the desired value as in RFC > 3264, and the sender can send any size it wishes upto 120. So what is the > benfit for the receiver to signal it. I thought that this is a receive > capability. ptime is I think desired but not required. maxptime and minptime should be hard receiver limits. Per Colin on AVT on 30 Mar 2006, ptime is a "hint", but the encoder can vary up to maxptime (and I assume down to minptime). (I didn't bother researching further). -- Randell Jesup randell-ietf@jesup.org From stephen.botzko@gmail.com Mon Jul 11 13:57:05 2011 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 8B8B721F8776 for ; Mon, 11 Jul 2011 13:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91jvlqMHl6WX for ; Mon, 11 Jul 2011 13:57:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A905821F8772 for ; Mon, 11 Jul 2011 13:57:04 -0700 (PDT) Received: by vws12 with SMTP id 12so4472062vws.31 for ; Mon, 11 Jul 2011 13:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NQZnDxofrMKDTfX7QOJ4XP14FaXPfOz6bYiA7YtqGMg=; b=v+N0bynO48V4RCsOV/A0oT9xthZ6/12MHnyi2dOAX99H69qriAuhinWi0TWhZR3vW3 nQZk5ROqXDCdhzgAxrROlle1Ju8HzGSriQRZ+4K2tUGNjuPZopmT/mEjz6HOXpcrkPhn wDXTSb3GwiidEslJL+wgiy660saH+VPk3yXUY= MIME-Version: 1.0 Received: by 10.52.109.228 with SMTP id hv4mr6005355vdb.42.1310417824158; Mon, 11 Jul 2011 13:57:04 -0700 (PDT) Received: by 10.52.116.34 with HTTP; Mon, 11 Jul 2011 13:57:03 -0700 (PDT) In-Reply-To: <4E1B5BCD.7050708@jesup.org> References: <00f601cc3aa7$ff4c9460$fde5bd20$%spittka@skype.net> <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com> <4E1B5BCD.7050708@jesup.org> Date: Mon, 11 Jul 2011 16:57:03 -0400 Message-ID: From: Stephen Botzko To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec5486088ea92f304a7d16c11 Cc: payload@ietf.org Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 11 Jul 2011 20:57:05 -0000 --bcaec5486088ea92f304a7d16c11 Content-Type: text/plain; charset=ISO-8859-1 ptime is described in both RFC3264 and RFC4566, which is a bit confusing. But the normative text for ptime is in RFC3264, I think that should be referenced in 7.1. (maxptime and minptime only appear in RFC4566). ptime, maxptime, and minptime are media attributes, so they apply to all codecs on the m= line. This is not that clear in this text, as it seems to mandate specific values for this OPUS. For instance: >>> maxptime Possible values are 3, 5, 10, 20, 40, and 60 or an arbitrary multiple of Opus frame sizes rounded up to the next full integer value up to a maximum value of 120 as defined in Section 4 and Section 5 of this document. If no value is specified, 120 is assumed as default. >>> The signaled maxptime certainly might exceed 120 ms, since the offerer might be quite willing to receive some other codec on the m-line at that interval. Regards, Stephen Botzko On Mon, Jul 11, 2011 at 4:23 PM, Randell Jesup wrote: > On 7/11/2011 10:24 AM, Roni Even wrote: > >> 11. In section 7.1 I noticed that ptime, maxptime and minptime signaled by >> the receiver are just recommendations and not the desired value as in RFC >> 3264, and the sender can send any size it wishes upto 120. So what is the >> benfit for the receiver to signal it. I thought that this is a receive >> capability. >> > > ptime is I think desired but not required. maxptime and minptime should be > hard receiver limits. > Per Colin on AVT on 30 Mar 2006, ptime is a "hint", but the encoder can > vary up to maxptime (and I > assume down to minptime). (I didn't bother researching further). > > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/**listinfo/payload > --bcaec5486088ea92f304a7d16c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ptime is described in both RFC3264 and RFC4566, which is a bit=20 confusing.=A0 But the normative text for ptime is in RFC3264, I think that should be referenced in 7.1. (maxptime and minptime only appear in RFC4566= ).

ptime, maxptime, and minptime are media attributes, so they apply to all codecs on the m=3D line.=A0 This is not that clear in this text, as it=20 seems to mandate specific values for this OPUS.=A0 For instance:

>>> maxptime
Po=
ssible values are 3, 5,
      10, 20, 40, and 60 or an arbitrary multiple of Opus frame sizes
      rounded up to the next full integer value up to a maximum value of
      120 as defined in Section 4 and Section 5 of this document.  If no
      value is specified, 120 is assumed as default.
>>>=
The signaled maxptime certainly might exceed 120 ms, since the offerer migh= t be quite willing to receive some other codec on the m-line at that interv= al.

Regards,
Stephen Botzko

On Mon, Jul 11, 2011 at 4:23 PM, Randell Jesup <randell-ietf@jesup.org> w= rote:
On 7/11/2011 10:24 AM, Roni Even wrote:
11. In section 7.1 I noticed that ptime, maxptime and minptime signaled by<= br> the receiver are just recommendations and not the desired value as in RFC 3264, and the sender can send any size it wishes upto 120. So what is the benfit for the receiver to signal it. I thought that this is a receive
capability.

ptime is I think desired but not required. =A0maxptime and minptime should = be hard receiver limits.
Per Colin on AVT on 30 Mar 2006, ptime is a "hint", but the encod= er can vary up to maxptime (and I
assume down to minptime). =A0(I didn't bother researching further).
=
--
Randell Jesup
randell-ietf@je= sup.org


_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload

--bcaec5486088ea92f304a7d16c11-- From internet-drafts@ietf.org Mon Jul 11 14:24:16 2011 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 9014E11E828F; Mon, 11 Jul 2011 14:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2SmzHtEAZ3s; Mon, 11 Jul 2011 14:24:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CD411E828E; Mon, 11 Jul 2011 14:24:16 -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: 3.55 Message-ID: <20110711212416.3471.75996.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 14:24:16 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-01.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: Mon, 11 Jul 2011 21:24:16 -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 Workin= g Group of the IETF. Title : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-01.txt Pages : 57 Date : 2011-07-11 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-howto-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-howto-01.txt From magnus.westerlund@ericsson.com Mon Jul 11 14:27:56 2011 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 4D3B721F8BCE for ; Mon, 11 Jul 2011 14:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvts2PgI-UGH for ; Mon, 11 Jul 2011 14:27:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51F21F8C16 for ; Mon, 11 Jul 2011 14:26:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-68-4e1b6a9ad9e4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B3.58.20773.A9A6B1E4; Mon, 11 Jul 2011 23:26:50 +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.137.0; Mon, 11 Jul 2011 23:26:49 +0200 Message-ID: <4E1B6A98.9010101@ericsson.com> Date: Mon, 11 Jul 2011 23:26:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "payload@ietf.org" X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [payload] Issues in RTP Payload HOWTO (draft-ietf-payload-rtp-howto-01) 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, 11 Jul 2011 21:27:56 -0000 Hi, In the process of updating the I-D to draft-ietf-payload-rtp-howto-01 I found some issues that I think should be discusses by the WG. These issues have not be changed yet from prior version of the draft. 1. Section 4.1.3 in the I-D discuss the WG draft names of the RTP payload formats. It recommends a form that is draft-ietf-wg-rtp--. Which made more sense in the old AVT when there was more need to separate payload formats from other drafts. In the payload WG I think we can remove the recommendation for "-rtp-" in the file name. Any one against? 2. Section 7.4 and the IANA template indicates that RTP payload format Media types shall be registered also in the RTP Payload Format media types found on page: http://www.iana.org/assignments/rtp-parameters My question to the WG. Should we continue to do this? The registry is not needed for collision prevention. Its sole purpose is as a quick way of finding all the RTP payload format media types. If we think the later is good enough then the WG chairs needs to work to update that registry to be correct and complete as it currently are missing some format. They also need to ensure that this bit of procedure really is followed in all the payload formats going forward. The alternative I see it to declare the registry as discontinued and add a note that it will not any longer be maintained and that people have to look in the main registry. 3. The draft has an open issue that says: Should any procedure for the future when the Payload WG is closed be described? I think we should remove this open issue and continue without specifying that procedure. The reason is that we can't really predict the situation when there no longer are a WG that is chartered for RTP payload formats development. Several possible reasons for that can occur, and based on the situation the procedures to handle that needs to be developed at that time. Any one having a different view? Cheers 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 Mon Jul 11 14:33:07 2011 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 9DB2111E8165 for ; Mon, 11 Jul 2011 14:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JllRqYzHMkrJ for ; Mon, 11 Jul 2011 14:33:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1040521F8EB9 for ; Mon, 11 Jul 2011 14:32:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-15-4e1b6c051f37 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FE.78.20773.50C6B1E4; Mon, 11 Jul 2011 23:32:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 11 Jul 2011 23:32:52 +0200 Message-ID: <4E1B6C02.5010803@ericsson.com> Date: Mon, 11 Jul 2011 23:32:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "payload@ietf.org" References: <20110711212416.3471.75996.idtracker@ietfa.amsl.com> In-Reply-To: <20110711212416.3471.75996.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-01.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: Mon, 11 Jul 2011 21:33:07 -0000 Hi, This updates main change is a media scalability section that has been contributed by Thomas Schierl, then banged up a bit by me. The rest is an editing pass and an attempt to resolve some open issues. See other email for issues requiring discussion. Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-01 I would very much appreciate some feedback so we can conclude this I-D and request publication of it. Cheers Magnus On 2011-07-11 23:24, 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-01.txt > Pages : 57 > Date : 2011-07-11 > > 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. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-howto-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-howto-01.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- 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 randell-ietf@jesup.org Mon Jul 11 14:58:14 2011 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 10B1111E828C for ; Mon, 11 Jul 2011 14:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPIxkomZakSd for ; Mon, 11 Jul 2011 14:58:13 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id B10F011E82E1 for ; Mon, 11 Jul 2011 14:58:08 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QgOUS-0001or-BA for payload@ietf.org; Mon, 11 Jul 2011 16:58:08 -0500 Message-ID: <4E1B71CD.1020905@jesup.org> Date: Mon, 11 Jul 2011 17:57:33 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: payload@ietf.org References: <00f601cc3aa7$ff4c9460$fde5bd20$%spittka@skype.net> <008901cc3fd6$4d18e490$e74aadb0$%roni@huawei.com> <4E1B5BCD.7050708@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 11 Jul 2011 21:58:14 -0000 On 7/11/2011 4:57 PM, Stephen Botzko wrote: > ptime is described in both RFC3264 and RFC4566, which is a bit > confusing. But the normative text for ptime is in RFC3264, I think > that should be referenced in 7.1. (maxptime and minptime only appear > in RFC4566). > > ptime, maxptime, and minptime are media attributes, so they apply to > all codecs on the m= line. This is not that clear in this text, as it > seems to mandate specific values for this OPUS. For instance: > > >>> maxptime > Possible values are 3, 5, > 10, 20, 40, and 60 or an arbitrary multiple of Opus frame sizes > rounded up to the next full integer value up to a maximum value of > 120 as defined in Section 4 and Section 5 of this document. If no > value is specified, 120 is assumed as default. > >>> > The signaled maxptime certainly might exceed 120 ms, since the offerer > might be quite willing to receive some other codec on the m-line at > that interval. Right. You could define a fmtp parameter of maxptime (or equivalent) that give the maximum for that codec/payload. iLBC uses fmtp to negotiate between 20 and 30ms frame sizes, though that's not exactly the same as the ptime issues here. ptime and maxptime are a bit problematic due to the global nature (and that's part of why ptime is a hint). Also, they can be any arbitrary value (due to the shared nature), not just multiples of your codec's frame size. -- Randell Jesup randell-ietf@jesup.org From koen.vos@skype.net Mon Jul 11 15:00:39 2011 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 99D0E11E82E0 for ; Mon, 11 Jul 2011 15:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JgXxmkoCRXC for ; Mon, 11 Jul 2011 15:00:39 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF011E826E for ; Mon, 11 Jul 2011 15:00:38 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 1D52B16E2; Tue, 12 Jul 2011 00:00:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=JZi2rk3ZaOqJlCRBpCs65ohgXTI= ; b=tu/HWDZJ8TShdxVNiVCk1/C0kACzRUoklwbXKROWN4VLJa5y6npyQH7i6Zz0 KWULMg8fNnAGeLq7DvWp5GcoNKgr25mZWdboLV8WhCRWikPjT/fttBifg4+ZCOED aOOW4bkVyLNCqgwBu+WgKo01YEKWesayRh//SXMWc/fE79c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=BTGg1duYjQ9wt/6+XHvpvB mXRRyJrisMRSYkRwZeGx78JWdmVQxLb6qsDgOGEdaaUyc2xIakGqbrNGoWuO8IpV CdnYzebb+dhuPMm3VTHQ7oM5IxtOtvbc6DHR3pitA1cl3AnZnxuThoxG4wv+8Fxn 23HEDgMc35QLbFTbpEyQM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1BE337F6; Tue, 12 Jul 2011 00:00:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id ECB3C3507E56; Tue, 12 Jul 2011 00:00:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i9-04dV5x4C; Tue, 12 Jul 2011 00:00:37 +0200 (CEST) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 3CE9635075DF; Tue, 12 Jul 2011 00:00:37 +0200 (CEST) Date: Tue, 12 Jul 2011 00:00:37 +0200 (CEST) From: Koen Vos To: Randell Jesup Message-ID: <1906705067.3121553.1310421637147.JavaMail.root@lu2-zimbra> In-Reply-To: <4E1B5BCD.7050708@jesup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.181.192.115] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686) Cc: payload@ietf.org Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 11 Jul 2011 22:00:39 -0000 Randell Jesup wrote: > ptime is I think desired but not required. maxptime and minptime should > be hard receiver limits. The goal has always been that every Opus decoder is able to decode any valid Opus bitstream. Advantages are: - In a multi-party call you can send the same bitstream to all end points. If maxptime and minptime were hard limits, then two end points may not have any overlap in their ranges of allowed ptime, making it impossible to share bitstreams. - Less reliance on parameter negotiation. Keep in mind that bitstreams may be saved to file and played out later. Note that the cost in storage requirements of maxptime being a soft limit is modest: payloads are stored in compressed format, and payloads with ptime > 20 ms can always be decoded in chunks of 20 ms (or less). If Opus' use of minptime and maxptime differs from what is generally accepted, then perhaps we should use different names for these parameters? Roni Even wrote: > So what is the benfit for the receiver to signal it. See section 7.2.1: performance (e.g. quality) may be better for some ptime values than for others. best, koen. ----- Original Message ----- From: "Randell Jesup" To: payload@ietf.org Sent: Monday, July 11, 2011 1:23:41 PM Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 On 7/11/2011 10:24 AM, Roni Even wrote: > 11. In section 7.1 I noticed that ptime, maxptime and minptime signaled by > the receiver are just recommendations and not the desired value as in RFC > 3264, and the sender can send any size it wishes upto 120. So what is the > benfit for the receiver to signal it. I thought that this is a receive > capability. ptime is I think desired but not required. maxptime and minptime should be hard receiver limits. Per Colin on AVT on 30 Mar 2006, ptime is a "hint", but the encoder can vary up to maxptime (and I assume down to minptime). (I didn't bother researching further). -- Randell Jesup randell-ietf@jesup.org _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From internet-drafts@ietf.org Mon Jul 11 15:26:47 2011 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 3FA4D11E833D; Mon, 11 Jul 2011 15:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vl5UUuZEkV4; Mon, 11 Jul 2011 15:26:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF2511E8332; Mon, 11 Jul 2011 15:26:46 -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: 3.55 Message-ID: <20110711222646.29752.16188.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 15:26:46 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-01.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: Mon, 11 Jul 2011 22:26:47 -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 Workin= g Group of the IETF. Title : RTP Payload Format for VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-01.txt Pages : 27 Date : 2011-07-11 This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-vp8-01.txt From abegen@cisco.com Mon Jul 11 15:39:44 2011 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 5382911E834B for ; Mon, 11 Jul 2011 15:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-qlb6A27X+M for ; Mon, 11 Jul 2011 15:39:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DCB0F11E8084 for ; Mon, 11 Jul 2011 15:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3330; q=dns/txt; s=iport; t=1310423983; x=1311633583; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=q2EfLCFMILUfggH9QjBC1vEWPx/aVwT8p6WgfgSqXOs=; b=YhEKcN3vXzqWe5tohcHibq3A1jpOcpJCTxPC5dQzYChOAqbHmPZ5+u0O +KAh0ovCvAC2KKb7q2/rx1lQS64voMfC0NnvQQsyeuSnIRpc512z0kXbj 7PZkHBXoOpuTQ6LV4h5i6YeqEuDyrnKyOhwXfvz+7ytB8RGHmx1krqNeB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAC97G06rRDoJ/2dsb2JhbABTl22POXeIeqI5nhkChVlfBIdPkA6LYA X-IronPort-AV: E=Sophos;i="4.65,517,1304294400"; d="scan'208";a="1898422" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2011 22:39:42 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6BMdgJb030917; Mon, 11 Jul 2011 22:39:42 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 15:39:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 15:39:35 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F69331A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E1B6A98.9010101@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] Issues in RTP Payload HOWTO(draft-ietf-payload-rtp-howto-01) Thread-Index: AcxAEZ1wcREmv8qnTmqpdZ87+AwsfAACXMeA References: <4E1B6A98.9010101@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 11 Jul 2011 22:39:41.0836 (UTC) FILETIME=[6CAB44C0:01CC401B] Subject: Re: [payload] Issues in RTP Payload HOWTO(draft-ietf-payload-rtp-howto-01) 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, 11 Jul 2011 22:39:46 -0000 > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Magnus Westerlund > Sent: Monday, July 11, 2011 2:27 PM > To: payload@ietf.org > Subject: [payload] Issues in RTP Payload = HOWTO(draft-ietf-payload-rtp-howto-01) >=20 > Hi, >=20 > In the process of updating the I-D to draft-ietf-payload-rtp-howto-01 = I > found some issues that I think should be discusses by the WG. >=20 > These issues have not be changed yet from prior version of the draft. >=20 > 1. Section 4.1.3 in the I-D discuss the WG draft names of the RTP > payload formats. It recommends a form that is > draft-ietf-wg-rtp--. Which made more sense = in > the old AVT when there was more need to separate payload formats from > other drafts. In the payload WG I think we can remove the = recommendation > for "-rtp-" in the file name. Any one against? I guess we can drop it as "wg" will be payload already. =20 > 2. Section 7.4 and the IANA template indicates that RTP payload format > Media types shall be registered also in the RTP Payload Format media > types found on page: http://www.iana.org/assignments/rtp-parameters > My question to the WG. Should we continue to do this? Why should not we continue? =20 > The registry is not needed for collision prevention. Its sole purpose = is > as a quick way of finding all the RTP payload format media types. I personally find it useful. =20 > If we think the later is good enough then the WG chairs needs to work = to > update that registry to be correct and complete as it currently are > missing some format. They also need to ensure that this bit of = procedure > really is followed in all the payload formats going forward. The > alternative I see it to declare the registry as discontinued and add a > note that it will not any longer be maintained and that people have to > look in the main registry. Which registry are you referring to? =20 > 3. The draft has an open issue that says: > Should any procedure for the future when the Payload WG is closed be > described? >=20 > I think we should remove this open issue and continue without = specifying > that procedure. The reason is that we can't really predict the = situation > when there no longer are a WG that is chartered for RTP payload = formats > development. Several possible reasons for that can occur, and based on > the situation the procedures to handle that needs to be developed at > that time. Any one having a different view? Agreed. If payload shuts down, then I guess RAI will take care of it. =20 -acbegen (individual) > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From csp@csperkins.org Tue Jul 12 07:56:29 2011 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 3A9F921F8E1E for ; Tue, 12 Jul 2011 07:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM72wjnwO6QR for ; Tue, 12 Jul 2011 07:56:28 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8204921F8D6A for ; Tue, 12 Jul 2011 07:56:28 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QgeNv-0000OL-Xg; Tue, 12 Jul 2011 14:56:27 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <00f601cc3aa7$ff4c9460$fde5bd20$@spittka@skype.net> Date: Tue, 12 Jul 2011 15:56:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00f601cc3aa7$ff4c9460$fde5bd20$@spittka@skype.net> To: julian.spittka@skype.net X-Mailer: Apple Mail (2.1084) Cc: 'Jean-Marc Valin' , payload@ietf.org Subject: Re: [payload] RTP Payload Format and File Storage Format for Opus Speech and Audio Codec - draft-spittka-payload-rtp-opus-00 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, 12 Jul 2011 14:56:29 -0000 On 5 Jul 2011, at 01:10, Julian Spittka wrote: > Please find a first draft "draft-spittka-payload-rtp-opus-00" for the = "RTP Payload Format and File Storage Format for Opus Speech and Audio = Codec" uploaded at = https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/.=20 >=20 > Any feedback, questions, or comments are highly welcome. A few quick comments: - The codec supports a VBR mode, so it would be useful to reference the = discussion in draft-ietf-avtcore-srtp-vbr-audio in the Security = Considerations - Section 4.1 states that the Marker bit in the RTP header is not used. = Any reason why the standard audio usage of setting the M bit to one on = the first packet on a talk-spurt isn't appropriate?=20 - The media type registration defines a "stereo" parameter. Rather than = define something codec-specific, can't this use the encoding parameter = in the SDP "a=3Drtpmap:" line, line other stereo codecs? Cheers, Colin --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Wed Jul 13 01:26:51 2011 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 A0E2F21F88A6 for ; Wed, 13 Jul 2011 01:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNNHGfBIUe8J for ; Wed, 13 Jul 2011 01:26:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6616321F8879 for ; Wed, 13 Jul 2011 01:26:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b5-4e1d56c6c878 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 61.99.09774.6C65D1E4; Wed, 13 Jul 2011 10:26:46 +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.137.0; Wed, 13 Jul 2011 10:26:45 +0200 Message-ID: <4E1D56BF.50702@ericsson.com> Date: Wed, 13 Jul 2011 10:26:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4E1B6A98.9010101@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F69331A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F69331A@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "payload@ietf.org" Subject: Re: [payload] Issues in RTP Payload HOWTO(draft-ietf-payload-rtp-howto-01) 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, 13 Jul 2011 08:26:51 -0000 On 2011-07-12 00:39, Ali C. Begen (abegen) wrote: > >> 2. Section 7.4 and the IANA template indicates that RTP payload format >> Media types shall be registered also in the RTP Payload Format media >> types found on page: http://www.iana.org/assignments/rtp-parameters >> My question to the WG. Should we continue to do this? > > Why should not we continue? The main reason is to ensure that this registration actually happens. There is formats missing from it. > >> The registry is not needed for collision prevention. Its sole purpose is >> as a quick way of finding all the RTP payload format media types. > > I personally find it useful. Yes, I also find it a useful concept. But as it is incomplete I can't rely on it. > >> If we think the later is good enough then the WG chairs needs to work to >> update that registry to be correct and complete as it currently are >> missing some format. They also need to ensure that this bit of procedure >> really is followed in all the payload formats going forward. The >> alternative I see it to declare the registry as discontinued and add a >> note that it will not any longer be maintained and that people have to >> look in the main registry. > > Which registry are you referring to? "RTP Payload Format media types" found on page: http://www.iana.org/assignments/rtp-parameter Someone needs to ensure that this registry actually contains all the RTP payload types. Secondly, which definitely will be the WG chairs job, is to ensure that the IANA sections do request that any future registrations actually do this. If we look at the current set of PAYLOAD WG documents the status of this registration request is as follows when it comes to request of IANA to actually add or modify the "RTP Payload Format media types" draft-ietf-avt-rtp-evrc-nw-03: Don't request registration draft-ietf-avt-rtp-ipmr-15.txt: Don't request registration draft-ietf-payload-rfc3016bis-01.txt: Doesn't update the registration draft-ietf-payload-rfc3189bis-01: Doesn't update the registration draft-ietf-payload-rtp-g718-00: Don't request registration draft-ietf-payload-rtp-klv-01: Requests Registration!!! draft-ietf-payload-rtp-mvc-00: Don't request registration draft-ietf-payload-rtp-sbc-00: Don't request registration draft-ietf-payload-vp8-01: Don't request registration In other words, only one out of nine drafts actually ensures that their drafts get added to this registry. That is why I raised this question, if we should continue to use it or declare it dead. Cheers 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 Wed Jul 13 04:42:30 2011 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 BA1CB21F8A62 for ; Wed, 13 Jul 2011 04:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvjs3P4vcmIt for ; Wed, 13 Jul 2011 04:42:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B54AD21F891D for ; Wed, 13 Jul 2011 04:42:26 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ca-4e1d84a1cc5a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A2.49.20773.1A48D1E4; Wed, 13 Jul 2011 13:42:25 +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.137.0; Wed, 13 Jul 2011 13:42:25 +0200 Message-ID: <4E1D849F.7030704@ericsson.com> Date: Wed, 13 Jul 2011 13:42:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: payload@ietf.org References: <4E1B6A98.9010101@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F69331A@xmb-sjc-215.amer.cisco.com> <4E1D56BF.50702@ericsson.com> In-Reply-To: <4E1D56BF.50702@ericsson.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [payload] Issues in RTP Payload HOWTO(draft-ietf-payload-rtp-howto-01) 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, 13 Jul 2011 11:42:30 -0000 To clarify as I have received one email pointing out that draft x do update this registry despite what I wrote. But, that is misunderstanding. There are two regestries. The Media Types registry: http://www.iana.org/assignments/media-types/index.html This is the registry that ensure that there are no colliding media types etc. The registry I am discussing is the "RTP Payload Format media types" http://www.iana.org/assignments/rtp-parameters This is a courtesy registry to track which of the media types that exist in the previous registry that are defined for RTP usage. I hope that helps setting what I want discussed. Cheers Magnus On 2011-07-13 10:26, Magnus Westerlund wrote: > On 2011-07-12 00:39, Ali C. Begen (abegen) wrote: >> >>> 2. Section 7.4 and the IANA template indicates that RTP payload format >>> Media types shall be registered also in the RTP Payload Format media >>> types found on page: http://www.iana.org/assignments/rtp-parameters >>> My question to the WG. Should we continue to do this? >> >> Why should not we continue? > > The main reason is to ensure that this registration actually happens. > There is formats missing from it. > >> >>> The registry is not needed for collision prevention. Its sole purpose is >>> as a quick way of finding all the RTP payload format media types. >> >> I personally find it useful. > > Yes, I also find it a useful concept. But as it is incomplete I can't > rely on it. > >> >>> If we think the later is good enough then the WG chairs needs to work to >>> update that registry to be correct and complete as it currently are >>> missing some format. They also need to ensure that this bit of procedure >>> really is followed in all the payload formats going forward. The >>> alternative I see it to declare the registry as discontinued and add a >>> note that it will not any longer be maintained and that people have to >>> look in the main registry. >> >> Which registry are you referring to? > > "RTP Payload Format media types" found on page: > http://www.iana.org/assignments/rtp-parameter > > Someone needs to ensure that this registry actually contains all the RTP > payload types. > > Secondly, which definitely will be the WG chairs job, is to ensure that > the IANA sections do request that any future registrations actually do > this. > > If we look at the current set of PAYLOAD WG documents the status of this > registration request is as follows when it comes to request of IANA to > actually add or modify the "RTP Payload Format media types" > > draft-ietf-avt-rtp-evrc-nw-03: Don't request registration > draft-ietf-avt-rtp-ipmr-15.txt: Don't request registration > draft-ietf-payload-rfc3016bis-01.txt: Doesn't update the registration > draft-ietf-payload-rfc3189bis-01: Doesn't update the registration > draft-ietf-payload-rtp-g718-00: Don't request registration > draft-ietf-payload-rtp-klv-01: Requests Registration!!! > draft-ietf-payload-rtp-mvc-00: Don't request registration > draft-ietf-payload-rtp-sbc-00: Don't request registration > draft-ietf-payload-vp8-01: Don't request registration > > In other words, only one out of nine drafts actually ensures that their > drafts get added to this registry. > > That is why I raised this question, if we should continue to use it or > declare it dead. > > Cheers > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > 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 dpetrie@sipez.com Mon Jul 18 17:52:05 2011 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 EC62221F86C4 for ; Mon, 18 Jul 2011 17:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKG3EiCgE1Zs for ; Mon, 18 Jul 2011 17:52:05 -0700 (PDT) Received: from nm30.bullet.mail.ne1.yahoo.com (nm30.bullet.mail.ne1.yahoo.com [98.138.90.93]) by ietfa.amsl.com (Postfix) with SMTP id 5356C21F86C2 for ; Mon, 18 Jul 2011 17:52:05 -0700 (PDT) Received: from [98.138.90.49] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 00:52:01 -0000 Received: from [98.138.89.250] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 00:52:01 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 00:52:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 944745.11636.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 24821 invoked by uid 60001); 19 Jul 2011 00:52:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311036721; bh=H3TwT2vGVwOJVWmuSOMTE+t9uc/xqPAVuztofqOU7I0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=XlQRFvUf8TTAhEEhcV6sHqE2orogldEIWdZvv9y1BCA7TXlmojChGsS3bpGq4Zi0RXlVuCaze8sTzFYCYLtMTyy4+MwmvHBHo/S4/3imOHLFUPlIHC4FZDszlXHfqF0ObDLIrsyiAoukiBtvfzWNJjXO1C7t9pRIyUl2gFFdeYQ= X-YMail-OSG: NkEQR6UVM1lkIN4fJf_XbQ1zuTsDx6W6Scj39xFDsjI6IfY wBa7a9MQeQcy60xukMqA9RAdrvT0KY0wXGlYl_dTFfEfTGxma.EDW3aoM3ue VDHJYv8hAQciULSXj3CI52He1UI6BoqhTn.h_lc.9qnj4OI.ynIBTRnYTHtS RDb2gKXnzPh1AeTHVh_FuiQ0xhoejCAP9yqSxOVgRvP3ynQG3myi_5PASiiy XTCkqxMF4o.gAhJEAkgInlTqEdvH_rb4EO8gYsXq.KVMlJSNuDA568tuktl6 DswLNaPLiEWXPdD2KD9eqt0Le_dtNy1IqeyprXmUSoCEG_egBbXbB9zUwcog w7BnTiUSWMVneZHDGfJvy9ZPkXfTavCdf6KLbkL2DQNKIOQ-- Received: from [24.61.83.127] by web120006.mail.ne1.yahoo.com via HTTP; Mon, 18 Jul 2011 17:52:01 PDT X-RocketYMMF: dgpetrie X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311036721.925.YahooMailClassic@web120006.mail.ne1.yahoo.com> Date: Mon, 18 Jul 2011 17:52:01 -0700 (PDT) From: Daniel Petrie To: payload@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [payload] AAC_LC mime type and RTP/SDP binding X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dpetrie@sipez.com 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, 19 Jul 2011 00:52:06 -0000 Hi: Sorry for the broadcast on this. I am looking for the RFC for RTP streaming of audio/AAC_LC. Normally I can pretty easily find the codec profile with RTP and SDP binding for a mime type. However I am having difficulty finding the RFC or draft for this. Iana has no registration for the audio/AAC_LC MIME type, yet I know of several vendors who are advertising this MIME type in their SDP. I have scanned through RFC 3016 & 3640, but less I am being dense, these do not define it either. I would appreciate a pointer. Cheers, Dan From frans.de.bont@philips.com Tue Jul 19 00:11:19 2011 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 B6B3C21F8589 for ; Tue, 19 Jul 2011 00:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3NI49Jc0NKj for ; Tue, 19 Jul 2011 00:11:18 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 32A0121F8538 for ; Tue, 19 Jul 2011 00:11:15 -0700 (PDT) Received: from mail46-ch1-R.bigfish.com (216.32.181.173) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Tue, 19 Jul 2011 07:11:15 +0000 Received: from mail46-ch1 (localhost.localdomain [127.0.0.1]) by mail46-ch1-R.bigfish.com (Postfix) with ESMTP id F13C0201FF; Tue, 19 Jul 2011 07:11:14 +0000 (UTC) X-SpamScore: -44 X-BigFish: VPS-44(zz217bL15d6O9251J542M1432Nzz1202hzz1033IL8275dhz31h2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received-SPF: softfail (mail46-ch1: transitioning domain of philips.com does not designate 168.87.56.20 as permitted sender) client-ip=168.87.56.20; envelope-from=frans.de.bont@philips.com; helo=smtpx.philips.com ; .philips.com ; Received: from mail46-ch1 (localhost.localdomain [127.0.0.1]) by mail46-ch1 (MessageSwitch) id 1311059474820500_26507; Tue, 19 Jul 2011 07:11:14 +0000 (UTC) Received: from CH1EHSMHS034.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail46-ch1.bigfish.com (Postfix) with ESMTP id C00F1FB004E; Tue, 19 Jul 2011 07:11:14 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 19 Jul 2011 07:11:14 +0000 Received: from NLHILEXH02.connect1.local (172.16.153.92) by connect1.philips.com (172.16.156.153) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 19 Jul 2011 09:10:35 +0200 Received: from NLCLUEXM01.connect1.local ([172.16.153.50]) by NLHILEXH02.connect1.local ([172.16.153.92]) with mapi; Tue, 19 Jul 2011 09:08:40 +0200 From: "Bont, Frans de" To: "dpetrie@sipez.com" , "payload@ietf.org" Date: Tue, 19 Jul 2011 09:10:31 +0200 Thread-Topic: [payload] AAC_LC mime type and RTP/SDP binding Thread-Index: AcxFrdZPzJ2PgD5rR3qXYd9lWeTTXAALzDFA Message-ID: <19FE62CE8D62CF4B96C845DC556B8813A3043951F0@NLCLUEXM01.connect1.local> References: <1311036721.925.YahooMailClassic@web120006.mail.ne1.yahoo.com> In-Reply-To: <1311036721.925.YahooMailClassic@web120006.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [payload] AAC_LC mime type and RTP/SDP binding 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, 19 Jul 2011 07:11:19 -0000 Hi Dan, RFC 3016 & 3640 define two different payload formats for MPEG-4 AAC LC. RFC 3016 defines the MIME subtype audio/MP4A-LATM, and support all MPEG-4 A= udio coders, so also MPEG-4 AAC LC. The payload format is based on MPEG-4 L= ATM (Low-overhead MPEG-4 Audio Transport Multiplex), a format which is also= used by DVB services using MPEG-2 TS. An example of deployment of RFC 3016 is the 3GPP Transparent end-to-end Pac= ket-switched Streaming Service (PSS) (3GPP TS 26.234). RFC 3640 defines the MIME subtype mpeg4-generic, which has defined audio mo= des for MPEG-4 AAC and MPEG-4 CELP. The AAC modes are AAC-lbr and AAC-hbr a= nd the payload carries elementary AAC frames. RFC 3640 is referenced in ETS= I TS 102 005 (DVB services delivered directly over IP protocols) and the AT= SC Mobile DTV Standard (ATSC A/153 Part 8). I am not aware of a audio/AAC_LC MIME type. Best regards, Frans > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Daniel Petrie > Sent: Tuesday 19 July 2011 2:52 > To: payload@ietf.org > Subject: [payload] AAC_LC mime type and RTP/SDP binding > > Hi: > Sorry for the broadcast on this. > > I am looking for the RFC for RTP streaming of audio/AAC_LC. > > Normally I can pretty easily find the codec profile with RTP and SDP > binding for a mime type. However I am having difficulty finding the > RFC or draft for this. Iana has no registration for the audio/AAC_LC > MIME type, yet I know of several vendors who are advertising this MIME > type in their SDP. I have scanned through RFC 3016 & 3640, but less I > am being dense, these do not define it either. > > I would appreciate a pointer. > > Cheers, > Dan > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From dpetrie@sipez.com Tue Jul 19 01:04:48 2011 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 C165421F8698 for ; Tue, 19 Jul 2011 01:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLIKFqrhpWVg for ; Tue, 19 Jul 2011 01:04:47 -0700 (PDT) Received: from nm12.bullet.mail.ne1.yahoo.com (nm12.bullet.mail.ne1.yahoo.com [98.138.90.75]) by ietfa.amsl.com (Postfix) with SMTP id CFC8B21F8678 for ; Tue, 19 Jul 2011 01:04:47 -0700 (PDT) Received: from [98.138.90.51] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 08:04:44 -0000 Received: from [98.138.88.234] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 08:04:44 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 08:04:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 725084.64221.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 89264 invoked by uid 60001); 19 Jul 2011 08:04:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311062684; bh=mt8u3m+KGaTGMhPkTzGGOvjawPaPBm1eeGg7deBJ+PA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0CyhQ4Xwe/Lp5UsYaNRRSIkzUdlZxg5wbRLfBXpYY6jv+Gjb7VPwYJFmld6d3NkaFdX2LxjHvZz1PkheHygNvV1Lxv1nIF7wneNKaKPL1kz96GI7Y3mhhoB2WOERdNFgKe71lSGk0VUTwrGNqUxWqxfuzK2YYOhCH+QSWUewE7w= X-YMail-OSG: db6LdhAVM1mlx0_lYS8afFbKoQHHmjGvBnMmnANGBhGaIzB BiZUq2Edhqi1F55jGxMbfCKFKlsv1zTsoh5ILto9YzBBJV3H2wG4HfXoiXeS A7KMKkt9w82gERGyGMcry5mFc3V9x.3mu2f2V6JMj9upVOvcbvZtbS.uMptH syT0EDhZ0yKnTdTt9MNuMrEc_WhmVNxRLXEr02oTd9X6aDiP8sfdTPIP8aMb 2CgHXZRNFiuWa0KL1S_Jdea21KWD234InjkVgPcvhwbDpI5RXMjQDilOBqiX bpm3a_7SwI72o5Sj8qITuiN2G12CfrqQ.wuWrXZid4_aopDtFqYpTfiuCdiJ Z5geJzDyuR2s.8pxJr3I5AUNE_crsjZsKkz13MW42sZFPjPyq37SWCkwgTC4 QCki4TDLlxx_6NAw- Received: from [24.61.83.127] by web120002.mail.ne1.yahoo.com via HTTP; Tue, 19 Jul 2011 01:04:44 PDT X-RocketYMMF: dgpetrie X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311062684.78842.YahooMailClassic@web120002.mail.ne1.yahoo.com> Date: Tue, 19 Jul 2011 01:04:44 -0700 (PDT) From: Daniel Petrie To: "payload@ietf.org" , Frans deBont In-Reply-To: <19FE62CE8D62CF4B96C845DC556B8813A3043951F0@NLCLUEXM01.connect1.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [payload] AAC_LC mime type and RTP/SDP binding X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dpetrie@sipez.com 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, 19 Jul 2011 08:04:48 -0000 Hi Frans:=0AThank you for the response and references to AAC LC. I am defi= nitely seeing mime type audio/AAC_LC from several vendors. See the followi= ng rtpmap from the SDP:=0A=0Aa=3Drtpmap:116 AAC_LC/32000=0A=0ACan anyone pr= ovide a pointer to a spec. which defines what AAC profile and parameters ar= e implied by this?=0A=0ACheers,=0ADan=0A=0A--- On Tue, 7/19/11, Bont, Frans= de wrote:=0A=0A> From: Bont, Frans de =0A> Subject: RE: [payload] AAC_LC mime type and RTP/SDP= binding=0A> To: "dpetrie@sipez.com" , "payload@ietf.org= " =0A> Date: Tuesday, July 19, 2011, 3:10 AM=0A> Hi Dan,= =0A> =0A> RFC 3016 & 3640 define two different payload formats=0A> for MPEG= -4 AAC LC.=0A> =0A> RFC 3016 defines the MIME subtype audio/MP4A-LATM, and= =0A> support all MPEG-4 Audio coders, so also MPEG-4 AAC LC. The=0A> payloa= d format is based on MPEG-4 LATM (Low-overhead MPEG-4=0A> Audio Transport M= ultiplex), a format which is also used by=0A> DVB services using MPEG-2 TS.= =0A> An example of deployment of RFC 3016 is the 3GPP=0A> Transparent end-t= o-end Packet-switched Streaming Service=0A> (PSS) (3GPP TS 26.234).=0A> =0A= > RFC 3640 defines the MIME subtype mpeg4-generic, which has=0A> defined au= dio modes for MPEG-4 AAC and MPEG-4 CELP. The AAC=0A> modes are AAC-lbr and= AAC-hbr and the payload carries=0A> elementary AAC frames. RFC 3640 is ref= erenced in ETSI TS 102=0A> 005 (DVB services delivered directly over IP pro= tocols) and=0A> the ATSC Mobile DTV Standard (ATSC A/153 Part 8).=0A> =0A> = I am not aware of a audio/AAC_LC MIME type.=0A> =0A> Best regards,=0A> Fran= s=0A> =0A> > -----Original Message-----=0A> > From: payload-bounces@ietf.or= g=0A> [mailto:payload-bounces@ietf.org]=0A> On=0A> > Behalf Of Daniel Petri= e=0A> > Sent: Tuesday 19 July 2011 2:52=0A> > To: payload@ietf.org=0A> > Su= bject: [payload] AAC_LC mime type and RTP/SDP=0A> binding=0A> >=0A> > Hi:= =0A> > Sorry for the broadcast on this.=0A> >=0A> > I am looking for the RF= C for RTP streaming of=0A> audio/AAC_LC.=0A> >=0A> > Normally I can pretty = easily find the codec profile=0A> with RTP and SDP=0A> > binding for a mime= type.=A0 However I am having=0A> difficulty finding the=0A> > RFC or draft= for this.=A0 Iana has no registration=0A> for the audio/AAC_LC=0A> > MIME = type, yet I know of several vendors who are=0A> advertising this MIME=0A> >= type in their SDP.=A0 I have scanned through RFC=0A> 3016 & 3640, but less= I=0A> > am being dense, these do not define it either.=0A> >=0A> > I would= appreciate a pointer.=0A> >=0A> > Cheers,=0A> > Dan=0A> >=0A> > __________= _____________________________________=0A> > payload mailing list=0A> > payl= oad@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/payload=0A> =0A> T= he information contained in this message may be=0A> confidential and legall= y protected under applicable law. The=0A> message is intended solely for th= e addressee(s). If you are=0A> not the intended recipient, you are hereby n= otified that any=0A> use, forwarding, dissemination, or reproduction of thi= s=0A> message is strictly prohibited and may be unlawful. If you=0A> are no= t the intended recipient, please contact the sender by=0A> return e-mail an= d destroy all copies of the original=0A> message.=0A> =0A> From kaz.mishima@gmail.com Wed Jul 20 01:03:04 2011 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 0363421F8754 for ; Wed, 20 Jul 2011 01:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_74=0.6, MANGLED_WORKNG=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLirbKHaDgfv for ; Wed, 20 Jul 2011 01:03:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D89721F8752 for ; Wed, 20 Jul 2011 01:02:56 -0700 (PDT) Received: by gyd5 with SMTP id 5so2436110gyd.31 for ; Wed, 20 Jul 2011 01:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K781W2+lzlqSc2xqOh9VeW4+xAnkRzceHqKk4vh8GDk=; b=lWNk3P9Dc3+/aVDWp7tJj0Xxv/p4cSUJ9/+w3bhi8GRze+vcyq+GzFbad2R3uBHE0g Oc5p9W5sCdILWb2Qa4LCx50Zb87TiagphJv3GMqb+YC/MBTj2081moqy5PWHZmfoYrQX NEhcIt00RVvfqJ0tJcamq1q9t5BeBE8LqE1HE= MIME-Version: 1.0 Received: by 10.236.155.34 with SMTP id i22mr11466903yhk.245.1311148976341; Wed, 20 Jul 2011 01:02:56 -0700 (PDT) Sender: kaz.mishima@gmail.com Received: by 10.147.32.17 with HTTP; Wed, 20 Jul 2011 01:02:56 -0700 (PDT) In-Reply-To: <00c201cc3ffb$ec0da480$c428ed80$%roni@huawei.com> References: <00c201cc3ffb$ec0da480$c428ed80$%roni@huawei.com> Date: Wed, 20 Jul 2011 17:02:56 +0900 X-Google-Sender-Auth: -e2uftvnZq8iaXILQcT-_kyKPLc Message-ID: From: Kazuhiro Mishima To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-payload-rfc3189bis.all@tools.ietf.org, ietf-types@iana.org, payload@ietf.org Subject: Re: [payload] Updating the registration of audio and video DV media subtype 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, 20 Jul 2011 08:03:04 -0000 Hi Thanks for your comments. I'll update our draft with working group's comments. Best regards, Kazuhiro 2011/7/12 Roni Even : > Hi, > > > > draft-ietf-payload-rfc3189bis-01 has passed Working Group Last Call in th= e > Payload Working Group. > > > > Note that it an update to existing RFC3189 registrations > http://www.iana.org/assignments/rtp-parameters for DV media subtype. > > > > The new registrations are in Section 3.1 of the document. > http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1 > > nbsp; > > The information is also available below. > > > > I noticed that there is a need to change the change controller from " IET= F > Audio/Video Transport working group delegated from the=A0=A0 IESG" =A0to = " IETF > Payload =A0working group delegated from the=A0=A0 IESG" > > > > > > Other comments on the registration are welcome. > > > > Roni Even > > Payload co-chair > > > > > > 3.1.1.=A0 Media Type Registration for DV Video > > > > > > Type name:=A0 video > > > > =A0=A0 Subtype name:=A0 DV > > > > > > =A0=A0=A0=A0=A0 encode:=A0 type of DV format.=A0 Permissible values for e= ncode are > > =A0=A0=A0=A0=A0=A0=A0=A0 SD-VCR/525-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 SD-VCR/625-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 HD-VCR/1125-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 HD-VCR/1250-50, > > =A0=A0  ;=A0& DL-VCR/525-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 SDL-VCR/625-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 314M-25/525-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 314M-25/625-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 314M-50/525-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 314M-50/625-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 370M/1080-60i, > >   ;=A0& bsp;=A0 370M/1080-50i, > > =A0=A0=A0=A0=A0=A0=A0=A0 370M/720-60p, > > =A0=A0=A0=A0=A0=A0=A0=A0 370M/720-50p, > > =A0=A0=A0=A0=A0=A0=A0=A0 306M/525-60 (for backward compatibility), > > =A0=A0=A0=A0=A0=A0=A0=A0 and 306M/625-50 (for backward compatibility). > > > > =A0=A0 Optional parameters: > > > > =A0=A0=A0=A0=A0 audio:=A0 whether the DV stream includes audio data or no= t. > > =A0=A0=A0=A0=A0=A0=A0=A0 Permissible values for audio are bundled and non= e.=A0 Defaults to > none. > > > > =A0=A0 Encoding considerations: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 DV video can be transmitted with RTP as specifie= d in RFCXXXX(This > document).=A0 Other transport methods are not specified. > > =A0=A0=A0 Security considerations: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 See Section 4 of RFCXXXX (This document). > > > > =A0=A0 Interoperability considerations:=A0 NONE > > > > =A0=A0 Public specification: > > > > =A0=A0=A0=A0=A0&nbs p;=A0 FR style=3D'font-family:"Courier New"'>IEC 6183= 4 Standard > > =A0=A0=A0=A0=A0=A0=A0=A0 SMPTE 314M > > =A0=A0=A0=A0=A0=A0=A0=A0 SMPTE 370M > > =A0=A0=A0=A0=A0=A0=A0=A0 RFCXXXX (This document) > > =A0=A0=A0=A0=A0=A0=A0=A0 SMPTE 306M (for backward compatibility). > > > > =A0=A0 Applications that use this media type:=A0 Audio and video s treami= ng o:p> > > > > =A0=A0 Additional information:=A0 NONE > > > > =A0=A0 Person & email address to contact for further information: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 Katsushi Kobayashi > > > > =A0=A0=A0=A0=A0=A0=A0=A0 e-mail: ikob@ni.aist.go.jp > > > > =A0=A0 Intended usage:=A0 COMMON > > > > =A0=A0 Restrictions on usage:=A0 This media type depends on RTP framing, = and hence > is only defined for transfer via RTP (RFC 3550).=A0 Transfer within other > framing protocols is not defined at this time. > > > > =A0=A0 Author: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 Katsushi Kobayashi > > < n style=3D'font-family:"Courier New"'> > > =A0=A0 Change controller: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 IETF Audio/Video Transport working group delegat= ed from the > > =A0=A0=A0=A0=A0=A0=A0=A0 IESG > > > > > > 3.1.2.=A0 Media Type Registration for DV Audio > > =A0 < =A0=A0 Type name:=A0 audio > > > > =A0=A0 Subtype name:=A0 DV > > > > =A0=A0 Required parameters: > > > > =A0=A0=A0=A0=A0 encode:=A0 type of DV format.=A0 Permissible values for e= ncode are > > =A0=A0=A0=A0=A0=A0=A0=A0 SD-VCR/525-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 HD-VCR/1125-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 HD-VCR/1250-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 SDL-VCR/525-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 SDL-VCR/625-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 314M-25/525-60, > > =A0=A0=A0=A0=A0=A0=A0=A0 314M-25/625-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 314M-50/625-50, > > =A0=A0=A0=A0=A0=A0=A0=A0 370M/1080-60i, > > =A0=A0=A0=A0=A0=A0=A0=A0 370M/1080-50i, > > =A0=A0=A0=A0=A0=A0=A0=A0 370M/720-60p, > > =A0=A0=A0=A0=A0=A0=A0=A0 370M/720-50p, > > =A0=A0=A0=A0=A0=A0=A0=A0 306M/525-60 (for backward compatibility), > > =A0=A0=A0=A0=A0=A0=A0=A0 and 306M/625-50 (for backward compatibility). > > > > =A0=A0 Optional parameters: > > > > =A0=A0=A0=A0=A0 audio:=A0 whether the DV stream includes audio data or no= t. > > =A0=A0=A0=A0=A0=A0=A0=A0 Permissible values for audio are bundled and non= e.=A0 Defaults to > none. > > > > =A0=A0 Encodin g consid n> > > > > =A0=A0=A0=A0=A0=A0=A0=A0 DV audio can be transmitted with RTP as specifie= d in RFCXXXX(This > document).=A0 Other transport methods are not specified. > > > > =A0=A0 Security considerations: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 See Section 4 of RFCXXXX (This document). > > > > =A0&nb sp; Inte ns:=A0 NONE > > > > =A0=A0 Published specification: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 IEC 61834 Standard > > =A0=A0=A0=A0 =A0=A0=A0=A0SMPTE 314M > > =A0=A0=A0=A0=A0=A0=A0=A0 SMPTE 370M > > =A0=A0=A0=A0=A0=A0=A0=A0 RFCXXXX (This document)< /p> > > =A0=A0=A0=A0=A0=A0=A0=A0 SMPTE 306M (for backward compatibility). > > > > =A0=A0 Applications that use this media type:=A0 Audio and video streamin= g and > conferencing tools. > > > > =A0=A0 Additional information:=A0 NONE > > > > =A0=A0 Person & email address to contact for further information: > > =A0=A0=A0=A0=A0=A0=A0=A0 Katsushi Kobayashi > > > > =A0=A0=A0=A0=A0=A0=A0=A0 e-mail: ikob@ni.aist.go.jp > > > > =A0=A0 Intended usage:=A0 COMMON > > > > =A0=A0 Restrictions on usage:=A0 This media type depends on RTP framing, = and hence > is only defined for transfer via RTP (RFC 3550).=A0 Transfer=A0=A0=A0=A0= =A0 within other > framing protocol time. > > > > > > =A0=A0 Author: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 Katsushi Kobayashi > > > > =A0=A0 Change controller: > > > > =A0=A0=A0=A0=A0=A0=A0=A0 IETF Audio/Video Transport worki ng group /o:p> > > =A0=A0=A0=A0=A0=A0=A0=A0 IESG > > > > From Even.roni@huawei.com Thu Jul 21 06:23:52 2011 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 0704821F8B11; Thu, 21 Jul 2011 06:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.8 X-Spam-Level: X-Spam-Status: No, score=-104.8 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZfz1HNSXXcz; Thu, 21 Jul 2011 06:23:51 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E821F87A4; Thu, 21 Jul 2011 06:23:49 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO003L5QJMQY@szxga03-in.huawei.com>; Thu, 21 Jul 2011 21:23:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO00FFNQJM70@szxga03-in.huawei.com>; Thu, 21 Jul 2011 21:23:46 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-130.red.bezeqint.net [79.183.21.130]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOO006D9QJEPT@szxml12-in.huawei.com>; Thu, 21 Jul 2011 21:23:46 +0800 (CST) Date: Thu, 21 Jul 2011 16:21:01 +0300 From: Roni Even To: avt@ietf.org, rtcweb@ietf.org Message-id: <023701cc47a9$0da14660$28e3d320$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw)" Content-language: en-us Thread-index: AcxHqQgDSDakdIHASt6N7yX/APEFyQ== Cc: rtcweb-chairs@tools.ietf.org, payload@ietf.org, payload-chairs@tools.ietf.org Subject: [payload] Updated AVTcore agenda - new slot for multiplexing RTP for broweser based RTC 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, 21 Jul 2011 13:23:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw) Content-type: multipart/alternative; boundary="Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw)" --Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, We apologize for the last minute change. The topic of "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time Communications (RTC)" proposed in draft-rosenberg-rtcweb-rtpmux-00 caused a long discussion in RTCweb mailing list and the feeling is that it should be also discussed in AVTcore. Magnus has started a thread on the AVTcore list. In order to have a time slot we moved the payload WG status presentation to the AVText slot which will be on Wednesday afternoon. We had to remove the mprtp presentation based on low discussion on the mailing list. We may have one slide on mprtp during the chair status Please review the above draft, I recommend also to look at http://tools.ietf.org/html/draft-perkins-rtcweb-rtp-usage-02 Thanks Roni Even --Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

We apologize = for the last minute change. 

The topic =
of "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for =
Browser based Real-Time Communications (RTC)" proposed in =
  draft-rosenberg-rtcweb-rtpmux-00 caused a long discussion in =
RTCweb mailing list and the feeling is that it should be also discussed =
in AVTcore.  Magnus has started a thread on the AVTcore =
list.
In order =
to have a time slot we moved the payload WG status presentation to the =
AVText slot which will be on Wednesday afternoon. =

We had to =
remove the mprtp presentation based on low discussion on the mailing =
list. We may have one slide on mprtp during the chair =
status
 =

Please =
review the above draft, I recommend also to look at htt=
p://tools.ietf.org/html/draft-perkins-rtcweb-rtp-usage-02 =

 =

Thanks=

Roni =
Even

 

 

= --Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw)-- --Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw) Content-type: text/plain; name=a1107.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1107.txt Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Wednesday, 27 July 2011 at 9:00-11:30 (208 AB) ---------------------------------------------- 09:00 AVTCore Status Update (Chairs, 20) 09:20 Encryption of Header Extensions in SRTP (Lennox, 15) draft-ietf-avtcore-srtp-encrypted-header-ext-00 09:35 RTCP Extension for Feedback Suppression Indication (Qin Wu, 15) draft-ietf-avtcore-feedback-supression-rtp-05 09:50 Monitoring Architecture for RTP (Qin Wu, 15) draft-ietf-avtcore-monarch-03 10:05 RTP Multiple Stream Sessions and Simulcast(Magnus Westerlund , 30) draft-westerlund-avtcore-multistream-and-simulcast-00 10:35 Delayed Duplication Attribute and Duplication Grouping in SDP(Begen, 15) draft-begen-mmusic-temporal-interleaving-02 draft-begen-mmusic-redundancy-grouping-01 10:50 Retransmission for SSM Sessions (Begen, 10) draft-vancaenegem-avtcore-retransmission-for-ssm-00 11:00 Multiplexing of RTP trafic for Browser based RTC (Rosenberg, 30) draft-rosenberg-rtcweb-rtpmux-00 11:30 End --Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw) Content-type: text/html; name=a1107.html Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1107.html Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni Even

Wednesday, 27 July 2011 at 9:00-11:30 (208 AB)

09:00 AVTCore Status UpdateChairs
09:20 Encryption of Header Extensions in SRTPLennox
draft-ietf-avtcore-srtp-encrypted-header-ext-00
09:35 RTCP Extension for Feedback Suppression IndicationQin Wu
draft-ietf-avtcore-feedback-supression-rtp-05
09:50 Monitoring Architecture for RTPQin Wu
draft-ietf-avtcore-monarch-03
10:05 RTP Multiple Stream Sessions and SimulcastMagnus Westerlund
draft-westerlund-avtcore-multistream-and-simulcast-00
10:35 Delayed Duplication Attribute and Duplication Grouping in SDPBegen
draft-begen-mmusic-temporal-interleaving-02
draft-begen-mmusic-redundancy-grouping-01
10:50 Retransmission for SSM SessionsBegen
draft-vancaenegem-avtcore-retransmission-for-ssm-00
11:00 Multiplexing of RTP trafic for Browser based RTCRosenberg
draft-rosenberg-rtcweb-rtpmux-00
11:30 End
--Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw)-- From mina.s67@gmail.com Thu Jul 21 06:30:09 2011 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 EF6F721F8B19 for ; Thu, 21 Jul 2011 06:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNSvNcyVB7V9 for ; Thu, 21 Jul 2011 06:30:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6988721F8B12 for ; Thu, 21 Jul 2011 06:30:08 -0700 (PDT) Received: by gyd5 with SMTP id 5so701183gyd.31 for ; Thu, 21 Jul 2011 06:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=+v0lm8AUD/Jca8iBqqETRqCJiGriZ6fqlmDMLPPKDYc=; b=i0ejc6H48SKGzkc50R5LdjjTzXAOE1UKlpxt6bYWr79eZfEfxaT02ca0KjS8PB7xzi 1E9+9EerPSxiwQMtVRqb+UzzO9xrgpCrclsXjyaOSY69Y8he75Doh0LMCwsY3belIWZG xbEg70MnH0y7tV+pPka8MAiARqaCGistvh64Q= MIME-Version: 1.0 Received: by 10.91.127.5 with SMTP id e5mr674498agn.104.1311255007869; Thu, 21 Jul 2011 06:30:07 -0700 (PDT) Received: by 10.90.90.15 with HTTP; Thu, 21 Jul 2011 06:30:07 -0700 (PDT) Date: Thu, 21 Jul 2011 18:00:07 +0430 Message-ID: From: Mina Salehi To: payload@ietf.org Content-Type: multipart/alternative; boundary=001485f87eb4f43a3204a8945854 X-Mailman-Approved-At: Thu, 21 Jul 2011 08:05:22 -0700 Subject: [payload] Far End Camera Control in SIP 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, 21 Jul 2011 13:30:09 -0000 --001485f87eb4f43a3204a8945854 Content-Type: text/plain; charset=ISO-8859-1 I must implement FECC over SIP as a part of my work project. I need more details about RFC 4573. would you please introduce me some reference about it? PLZ help me. thanks very much. --001485f87eb4f43a3204a8945854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I must implement FECC over SIP as a part of my work=20 project.
I need more details about=A0 RFC 4573.
would you please=20 introduce me some reference about it?
PLZ help me.
thanks very much. --001485f87eb4f43a3204a8945854-- From Even.roni@huawei.com Thu Jul 21 08:21:13 2011 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 6E3DC21F86AB for ; Thu, 21 Jul 2011 08:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.715 X-Spam-Level: X-Spam-Status: No, score=-103.715 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95nmgizmpHtX for ; Thu, 21 Jul 2011 08:21:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A5E9C21F8500 for ; Thu, 21 Jul 2011 08:21:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO00H94VZ30T@szxga05-in.huawei.com> for payload@ietf.org; Thu, 21 Jul 2011 23:21:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO0066YVZ3J7@szxga05-in.huawei.com> for payload@ietf.org; Thu, 21 Jul 2011 23:21:03 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-130.red.bezeqint.net [79.183.21.130]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOO00HQAVYSJJ@szxml12-in.huawei.com>; Thu, 21 Jul 2011 23:21:03 +0800 (CST) Date: Thu, 21 Jul 2011 18:18:14 +0300 From: Roni Even In-reply-to: To: 'Mina Salehi' Message-id: <028401cc47b9$6ea17a60$4be46f20$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mkZqgi5E0znng9/pZ5hECQ)" Content-language: en-us Thread-index: AcxHrApSp8zg6MvTSYGoHat9Ow6y6AADN69A References: Cc: payload@ietf.org Subject: Re: [payload] Far End Camera Control in SIP 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, 21 Jul 2011 15:21:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_mkZqgi5E0znng9/pZ5hECQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, You should look at H.281 http://www.itu.int/rec/T-REC-H.281-199411-I and H.224 http://www.itu.int/rec/T-REC-H.224-200501-I with the fix in http://www.itu.int/rec/T-REC-H.224-200708-I!Cor1 H.224 is the encapsulation and H.281 is FECC ITU-T recommendations are available free of charge Roni Even From: Mina Salehi [mailto:mina.s67@gmail.com] Sent: Thursday, July 21, 2011 4:42 PM To: Even.roni@huawei.com Subject: Far End Camera Control in SIP Mr Roni, I must implement FECC over SIP as a part of my work project. I need more details about RFC 4573. would you please introduce me some reference about it? PLZ help me. thanks very much. --Boundary_(ID_mkZqgi5E0znng9/pZ5hECQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

You should look at H.281 http://www.itu.int/r= ec/T-REC-H.281-199411-I

and H.224 http://www.itu.int/r= ec/T-REC-H.224-200501-I  with the fix in http://www.itu.= int/rec/T-REC-H.224-200708-I!Cor1

 

H.224 is the encapsulation and H.281 is FECC

 

ITU-T recommendations are available free of = charge

Roni Even

 

From:= = Mina Salehi [mailto:mina.s67@gmail.com]
Sent: Thursday, July = 21, 2011 4:42 PM
To: Even.roni@huawei.com
Subject: = Far End Camera Control in SIP

 

Mr = Roni,
I must implement FECC over SIP as a part of my work = project.
I need more details about  RFC 4573.
would you = please introduce me some reference about it?
PLZ help me.
thanks = very much.

= --Boundary_(ID_mkZqgi5E0znng9/pZ5hECQ)-- From hoene@uni-tuebingen.de Mon Jul 25 09:10:47 2011 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 5AF7E21F910C; Mon, 25 Jul 2011 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twunP5j6-KAW; Mon, 25 Jul 2011 09:10:45 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCEF21F86CA; Mon, 25 Jul 2011 07:24:07 -0700 (PDT) Received: from hoeneT60 (dhcp-55ec.meeting.ietf.org [130.129.85.236]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p6PENubs011725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2011 16:24:03 +0200 From: "Christian Hoene" To: , Date: Mon, 25 Jul 2011 10:23:55 -0400 Organization: =?iso-8859-1?Q?Universit=E4t_T=FCbingen?= Message-ID: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxK1nknHdPOabTNQlSivuuWTQaFUg== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx05) Subject: [payload] Frames to Packets in draft-ietf-codec-opus-07? 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, 25 Jul 2011 16:10:47 -0000 Hello, I was wondering why the draft-ietf-codec-opus-07 draft has feature to concatenate multiple codec frames to packets. At the same time, draft-spittka-payload-rtp-opus-00 does not support to place multiple = codec entities in on RTP packet. As a consequence, the maximal size of an Opus packet is limited to = 120ms. Especially, on low rate links this might be too low. Also, on links with = a high packet overhead (such as IPsec or IEEE 802.11b WLAN), this limits = seems to be too. I would suggest to either 1) Remove the concatenation from draft-ietf-codec-opus-07 and add it to draft-spittka-payload-rtp-opus-00. Or 2) Add a second concatenation feature to the payload spec. With best regards, Christian -------------------------------------------------------------------------= --- ----- Dr.-Ing. Christian Hoene, University of T=FCbingen, Computer Science, = Chair of Communication Networks, Research Group Interactive Communication Systems (ICS) Sand 13, 72076 T=FCbingen, Germany, Tel +49 7071 2970532, www.net.uni-tuebingen.de From hoene@uni-tuebingen.de Mon Jul 25 09:11:18 2011 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 DDE4511E8095; Mon, 25 Jul 2011 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax-gL2GO6hbo; Mon, 25 Jul 2011 09:11:17 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF721F8C28; Mon, 25 Jul 2011 07:33:36 -0700 (PDT) Received: from hoeneT60 (dhcp-55ec.meeting.ietf.org [130.129.85.236]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p6PEXSwA013188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jul 2011 16:33:34 +0200 From: "Christian Hoene" To: , Date: Mon, 25 Jul 2011 10:33:27 -0400 Organization: =?iso-8859-1?Q?Universit=E4t_T=FCbingen?= Message-ID: <00ee01cc4ad7$d593a970$80bafc50$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxK187dPiFd+64rRSeM3WhDMXDZQQ== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx05) Subject: [payload] Padding in draft-ietf-codec-opus-07? 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, 25 Jul 2011 16:11:18 -0000 Hello, I am wondering about a padding feature in draft-ietf-codec-opus-07. It allows you to extend the frame size by filling it up with zeros. I just spoke with the Tim, Jean-Marc and Gregory about this feature. As = far as I understood, this feature is required at transcoding gateways to = enforce a stream of packets having a constant size (while using UDP). Otherwise, attackers could potentially follow the conversation by observing packet sizes.=20 To my understanding, padding is a feature that can be easily skipped = from the codec specification. It violates the layering principle and is = intended only for a very specific use cases. On the other side, constant sized = frames can be easily supported by keeping the codec parameters fixed. With best regards, Christian Hoene -------------------------------------------------------------------------= --- ----- Dr.-Ing. Christian Hoene, University of T=FCbingen, Computer Science, = Chair of Communication Networks, Research Group Interactive Communication Systems (ICS) Sand 13, 72076 T=FCbingen, Germany, Tel +49 7071 2970532, www.net.uni-tuebingen.de From stephen.botzko@gmail.com Mon Jul 25 10:24:53 2011 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 3F74A21F8BC1; Mon, 25 Jul 2011 10:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dpifBAA-6wd; Mon, 25 Jul 2011 10:24:52 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 59FEB21F8BB6; Mon, 25 Jul 2011 10:24:49 -0700 (PDT) Received: by pzk6 with SMTP id 6so8404488pzk.26 for ; Mon, 25 Jul 2011 10:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:subject:message-id:from:to:mime-version:content-type :content-transfer-encoding; bh=SLRR4lgIytC/gesyQ6H1OeW4139SJdwqYjATvJLFFCc=; b=LKtgfM2cxFjwjrEsGZHaztDbtVIEyBe6lD5eGu73/jC8FOxQDk2TxeGVOl80zCnPSL ZhHKe1SXRXTZiVYnjXCDoLNJmyt23AaIFTPd7XDKWVxRBKiNMfcxu0QOO1Xnz9mbkAgw iD8y7gCt3DzkwOiMRdUDfqBM+blVdhE1TGJfw= Received: by 10.68.66.170 with SMTP id g10mr8340090pbt.490.1311614688837; Mon, 25 Jul 2011 10:24:48 -0700 (PDT) Received: from localhost (dhcp-15e4.meeting.ietf.org [130.129.21.228]) by mx.google.com with ESMTPS id k8sm4711769pbk.15.2011.07.25.10.24.46 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 10:24:47 -0700 (PDT) Date: Mon, 25 Jul 2011 13:24:46 -0400 Message-ID: From: Stephen Botzko To: hoene@uni-tuebingen.de, payload@ietf.org, codec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [payload] Padding in draft-ietf-codec-opus-07? 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, 25 Jul 2011 17:24:53 -0000 SSB0aGluayBSVFAgcGFkZGluZyBzaG91bGQgYmUgc3VmZmljaWVudC4KClJlZ2FyZHMsClN0ZXBo ZW4KClNlbnQgZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIERldmljZQoKQ2hyaXN0aWFuIEhvZW5l IDxob2VuZUB1bmktdHVlYmluZ2VuLmRlPiB3cm90ZToKCj5IZWxsbywKPgo+SSBhbSB3b25kZXJp bmcgYWJvdXQgYSBwYWRkaW5nIGZlYXR1cmUgaW4gZHJhZnQtaWV0Zi1jb2RlYy1vcHVzLTA3LiBJ dAo+YWxsb3dzIHlvdSB0byBleHRlbmQgdGhlIGZyYW1lIHNpemUgYnkgZmlsbGluZyBpdCB1cCB3 aXRoIHplcm9zLgo+Cj4gSSBqdXN0IHNwb2tlIHdpdGggdGhlIFRpbSwgSmVhbi1NYXJjIGFuZCBH cmVnb3J5IGFib3V0IHRoaXMgZmVhdHVyZS4gQXMgZmFyCj5hcyBJIHVuZGVyc3Rvb2QsIHRoaXMg ZmVhdHVyZSBpcyByZXF1aXJlZCBhdCB0cmFuc2NvZGluZyBnYXRld2F5cyB0byBlbmZvcmNlCj5h IHN0cmVhbSBvZiBwYWNrZXRzIGhhdmluZyBhIGNvbnN0YW50IHNpemUgKHdoaWxlIHVzaW5nIFVE UCkuIE90aGVyd2lzZSwKPmF0dGFja2VycyBjb3VsZCBwb3RlbnRpYWxseSBmb2xsb3cgdGhlIGNv bnZlcnNhdGlvbiBieSBvYnNlcnZpbmcgcGFja2V0Cj5zaXplcy4gCj4KPlRvIG15IHVuZGVyc3Rh bmRpbmcsIHBhZGRpbmcgaXMgYSBmZWF0dXJlIHRoYXQgY2FuIGJlIGVhc2lseSBza2lwcGVkIGZy b20KPnRoZSBjb2RlYyBzcGVjaWZpY2F0aW9uLiBJdCB2aW9sYXRlcyB0aGUgbGF5ZXJpbmcgcHJp bmNpcGxlIGFuZCBpcyBpbnRlbmRlZAo+b25seSBmb3IgYSB2ZXJ5IHNwZWNpZmljIHVzZSBjYXNl cy4gT24gdGhlIG90aGVyIHNpZGUsIGNvbnN0YW50IHNpemVkIGZyYW1lcwo+Y2FuIGJlIGVhc2ls eSBzdXBwb3J0ZWQgYnkga2VlcGluZyB0aGUgY29kZWMgcGFyYW1ldGVycyBmaXhlZC4KPgo+V2l0 aCBiZXN0IHJlZ2FyZHMsCj4KPiBDaHJpc3RpYW4gSG9lbmUKPgo+Cj4KPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KPi0tLS0tCj5Eci4tSW5nLiBDaHJpc3RpYW4gSG9lbmUsIFVuaXZlcnNpdHkgb2YgVMO8 YmluZ2VuLCBDb21wdXRlciBTY2llbmNlLCBDaGFpciBvZgo+Q29tbXVuaWNhdGlvbiBOZXR3b3Jr cywgUmVzZWFyY2ggR3JvdXAgSW50ZXJhY3RpdmUgQ29tbXVuaWNhdGlvbiBTeXN0ZW1zCj4oSUNT KQo+U2FuZCAxMywgNzIwNzYgVMO8YmluZ2VuLCBHZXJtYW55LCBUZWwgKzQ5IDcwNzEgMjk3MDUz MiwKPnd3dy5uZXQudW5pLXR1ZWJpbmdlbi5kZQo+Cj4KPgo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPnBheWxvYWQgbWFpbGluZyBsaXN0Cj5wYXlsb2Fk QGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BheWxvYWQK From mramalho@cisco.com Mon Jul 25 10:56:06 2011 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 4DF9621F8BD1; Mon, 25 Jul 2011 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2kNDa-7KuZz; Mon, 25 Jul 2011 10:56:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7C21F8B7F; Mon, 25 Jul 2011 10:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=11450; q=dns/txt; s=iport; t=1311616564; x=1312826164; h=mime-version:subject:date:message-id:from:to; bh=KZSx7MZ33bJTSHZ6lKB11Ze4gKXC8yVXH/znNZwYheM=; b=LeAHbrdTlLn9wWHSS8OErmN087hnjsUFYiHu7DDydDaWrNo1u8nMmgzI HWnZlkrjglDQQavu7OMkC4uaRuPIE1Q5z90vYIhC8bEatAm/JNi0M9eBc pFeoCSrMsrzgLACrqbGzwRSzDuq5W0Nyw7g2sRS5O6y3dN7OFfAmIsRlc c=; X-Files: image001.gif : 837 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADmtLU6tJV2c/2dsb2JhbAA2AQEDBQ8BDAoIAQI6JAQBJgEBAwYPFAEHAQUNBAEHAgkkFwEFARUBCgIbgjakfHeqZZ4ZAoM7giNfBIdVg0GCYYoJi24 X-IronPort-AV: E=Sophos;i="4.67,263,1309737600"; d="gif'147?scan'147,208,217,147";a="6206983" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2011 17:56:04 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6PHu4oU018874; Mon, 25 Jul 2011 17:56:04 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 12:56:03 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: DTNW EO41 FxPH GjGs J5WL Os6u Py1x SVRg U+DP YY6y ZG4x Z7yI dQYM dWo+ eDA3 fimX; 3; YQB2AHQAQABpAGUAdABmAC4AbwByAGcAOwBhAHYAdABlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQB5AGwAbwBhAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8AD51F7B-5C7F-4DC9-8806-E319DC357319}; bQByAGEAbQBhAGwAaABvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 25 Jul 2011 17:55:56 GMT; ZAByAGEAZgB0AC0AcgBhAG0AYQBsAGgAbwAtAHAAYQB5AGwAbwBhAGQALQBnADcAMQAxADAALQAwADAAIAB0AG8AIABiAGUAIABkAGkAcwBjAHUAcwBzAGUAZAAgAGkAbgAgAEEAVgBUAEUAWABUAA== MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC4AF4.1E89FDC9" x-cr-puzzleid: {8AD51F7B-5C7F-4DC9-8806-E319DC357319} Content-class: urn:content-classes:message Date: Mon, 25 Jul 2011 12:55:56 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A00444F743@XMB-RCD-209.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ramalho-payload-g7110-00 to be discussed in AVTEXT Thread-Index: AcxK9Bp9BfwrLmXySG2KIyD5u4pbDw== From: "Michael Ramalho (mramalho)" To: "IETF AVTCore WG" , , X-OriginalArrivalTime: 25 Jul 2011 17:56:03.0342 (UTC) FILETIME=[1EA3AAE0:01CC4AF4] Subject: [payload] draft-ramalho-payload-g7110-00 to be discussed in AVTEXT 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, 25 Jul 2011 17:56:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4AF4.1E89FDC9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC4AF4.1E89FDC9" ------_=_NextPart_002_01CC4AF4.1E89FDC9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Apologies for cross posting AVT lists - reason below] =20 All, =20 I will be discussing issues contained in draft-ramalho-payload g7110-00 at the AVT extensions timeslot on Wednesday afternoon. =20 This draft is a payload WG draft, but there isn't a payload meeting at IETF 81. And this draft was previously scheduled to be discussed the AVT core timeslot prior to its being moved to AVTEXT (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me to say a few words prior to the discussion this week. =20 G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. When negotiated end-to-end it is negotiated "as if it were a codec". =20 However, being lossless and stateless, G.711.0 can be applied anywhere within an end-to-end G.711 negotiated session. When applied in this manner, it suffers no voice quality degradation relative to G.711 (duh, its lossless). =20 Most of the open issues in the draft relate to the use of G.711.0 within the context of an and-to-end G.711 negotiated session. =20 I look forward to comments generated from the discussion of this draft for those cases. =20 Regards, =20 Michael Ramalho =20 =20 Michael Ramalho Technical Leader Product Development mramalho@cisco.com =20 Phone: +1 919 476 2038 Mobile: +1 941 544 2844 Cisco Systems, Inc. 4564 Tuscana Drive Sarasota, FL 34241-4201 United States http://ramalho.webhop.info Skype: mramalho_mar42 =20 =20 =09 =09 =20 =20 ------_=_NextPart_002_01CC4AF4.1E89FDC9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Apologies for cross posting AVT lists – = reason below]

 

All,

 

I will be discussing issues contained in = draft-ramalho-payload g7110-00 at the AVT extensions timeslot on Wednesday = afternoon.

 

This draft is a payload WG draft, but there = isn’t a payload meeting at IETF 81. And this draft was previously scheduled to = be discussed  the AVT core timeslot prior to its being moved to AVTEXT = (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me = to say a few words prior to the discussion this week.

 

G.711.0 is a stateless and lossless compression of = G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. = When negotiated end-to-end it is negotiated “as if it were a = codec”.

 

However, being lossless and stateless, G.711.0 can = be applied anywhere within an end-to-end G.711 negotiated session. When = applied in this manner, it suffers no voice quality degradation relative to G.711 = (duh, its lossless).

 

Most of the open issues in the draft relate to the = use of G.711.0 within the context of an and-to-end G.711 negotiated = session.

 

I look forward to comments generated from the = discussion of this draft for those cases.

 

Regards,

 

Michael Ramalho

 

3D"http://www.cisco.com/swa/i/logo.gif"

= Michael Ramalho
Technical Leader
Product Development
mramalho@cisco.com
Phone: +1 919 476 2038
Mobile: +1 941 544 2844

= Cisco Systems, Inc.
4564 Tuscana Drive
Sarasota, FL 34241-4201
United States
http://ramalho.webhop.info
Skype: mramalho_mar42

 

 

 

 

------_=_NextPart_002_01CC4AF4.1E89FDC9-- ------_=_NextPart_001_01CC4AF4.1E89FDC9 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CC4AF4.1E89FDC9-- From bmschwar@fas.harvard.edu Mon Jul 25 10:56:58 2011 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 25ECD21F8BA4; Mon, 25 Jul 2011 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj2fEQ9vdno9; Mon, 25 Jul 2011 10:56:57 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (us26.unix.fas.harvard.edu [140.247.35.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5184821F8B7F; Mon, 25 Jul 2011 10:56:57 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us26.unix.fas.harvard.edu (Postfix) with ESMTP id A54F21F71CF; Mon, 25 Jul 2011 13:56:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=CI3neouXH273ES+ jpDwFnPi9pPqX3A8wMh99A+0+VuQ=; b=qLIzdVOggFTqYg7c+hwEyWB4Iu0tBHn pXTjH8dpCjY2mm0dOT/9+QsgGKqkoVzxR1MxIaZLsRyzmPAgsNR0ZuFqgjx6cGyl 52VtosIivqJLFkNfLEqixQb558PozO7g4htxnlH7nmCpeDnGtdkc8PExpN8v+orR cmR220O2gIOc= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=I5061MSsD 5F/inLiZfucXmD0Vt4mr7oBWPwxnZRD6xQFGFDuFeJDRGivfQfs4TRJTYrf0XGmU xNLRKY/kwoJzXJTwiYAsSlrQGaOoTJT03daZUjlmvi5mu7p3fRGt1bRrCsa4zxK8 f+UDz78GAhVQkbz8JIge+tupETWXFxsBjg= Received: from [172.23.141.135] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us26.unix.fas.harvard.edu (Postfix) with ESMTPSA id 9C5831F71CD; Mon, 25 Jul 2011 13:56:56 -0400 (EDT) Message-ID: <4E2DAE67.6090008@fas.harvard.edu> Date: Mon, 25 Jul 2011 13:56:55 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Christian Hoene References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> In-Reply-To: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE092448E8E6DC7BDA0A387E8" Cc: codec@ietf.org, payload@ietf.org Subject: Re: [payload] Frames to Packets in draft-ietf-codec-opus-07? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bens@alum.mit.edu 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, 25 Jul 2011 17:56:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE092448E8E6DC7BDA0A387E8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/25/2011 10:23 AM, Christian Hoene wrote: > I was wondering why the draft-ietf-codec-opus-07 draft has feature to > concatenate multiple codec frames to packets. At the same time, > draft-spittka-payload-rtp-opus-00 does not support to place multiple co= dec > entities in on RTP packet. I think we are in agreement that for many packet transports, a single frame per packet (max duration of 20~ms for general audio, minimum of 2.5ms or 400 pps) would be inappropriate, and so a concatenation scheme i= s required. The question is then: where should the concatenation scheme be= specified? The motivation for specifying concatenation inside the codec is to promot= e interoperability and adoption by reducing the total amount of engineering= work required to implement Opus. This happens in two ways: 1. Avoiding duplicative software work Given the structure of existing networked audio software, I expect that software using Opus will typically rely on a pre-existing Opus library, and there will be only a small number of widely used Opus implementations= =2E However, there will likely be many implementations of the Opus-RTP specification, due to engineering integration requirements. As such, we can reduce implementation effort by minimizing the complexity of the RTP specification. 2. Avoiding duplicative specification work Opus will be distributed over many transports other than RTP, and a concatenation scheme may be desirable in each case. Specifying concatenation inside the codec avoids the need to specify a new concatenation scheme for every transport. Having a single concatenation scheme should therefore accelerate adoption, minimize confusion when moving packets between transports, and minimize the amount of software required to make Opus work. Personally, I've found H.264 to be an example of how specifying framing outside the codec can create problems. H.264's packet/framing schemes (th= e "network abstraction layer", "access units", bytestream alignment, etc.) are specified outside the codec, so that they must be handled by the stream processing layer. Correctly distinguishing and converting between= the various possibilities is so confusing that, until the latest release last month, gstreamer's H.264 parser could not correctly depayload H.264 from the popular AVCHD format. --------------enigE092448E8E6DC7BDA0A387E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4trmgACgkQUJT6e6HFtqSbHwCeLoK+gkAlQNyXsC7dg/fYP9wJ q8UAnjq7aKLm9cb+G5mW0Zkm09kXUaHM =1E00 -----END PGP SIGNATURE----- --------------enigE092448E8E6DC7BDA0A387E8-- From prvs=180d87961=tterribe@xiph.org Mon Jul 25 15:55:54 2011 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 58A5811E80E3; Mon, 25 Jul 2011 15:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA8SzDC+UygV; Mon, 25 Jul 2011 15:55:53 -0700 (PDT) Received: from mxip0i.isis.unc.edu (mxip0i.isis.unc.edu [152.2.0.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5F29311E80D7; Mon, 25 Jul 2011 15:55:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAO7zLU6sGgRa/2dsb2JhbAA0AQEEAT5GAQUMDCEiDwkDAgECAQJRFQEOAqZegWyIfMEohj8Eh1eLG4R4D4t5 X-IronPort-AV: E=Sophos;i="4.67,265,1309752000"; d="scan'208";a="186040031" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip0o.isis.unc.edu with ESMTP; 25 Jul 2011 18:55:52 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 207.253.240.61 Received: from [172.16.61.51] ([207.253.240.61]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p6PMtpBb007954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jul 2011 18:55:52 -0400 (EDT) Message-ID: <4E2DF477.8050608@xiph.org> Date: Mon, 25 Jul 2011 15:55:51 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> In-Reply-To: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Jul 2011 18:59:01 -0700 Cc: codec@ietf.org, payload@ietf.org Subject: Re: [payload] [codec] Frames to Packets in draft-ietf-codec-opus-07? 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, 25 Jul 2011 22:55:54 -0000 > 1) Remove the concatenation from draft-ietf-codec-opus-07 and add it to > draft-spittka-payload-rtp-opus-00. We have to this point bent over backwards to keep the bitstream from changing since we declared a (soft) freeze in February, because people specifically asked for this in order to begin testing. While the working group can still agree to change it if a _serious_ issue arises with the format, I personally do not think this qualifies. From abegen@cisco.com Mon Jul 25 21:34:59 2011 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 CDC3511E807F for ; Mon, 25 Jul 2011 21:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.277 X-Spam-Level: X-Spam-Status: No, score=-4.277 tagged_above=-999 required=5 tests=[AWL=-1.678, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAOgWR+GUpQJ for ; Mon, 25 Jul 2011 21:34:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 11C7011E8072 for ; Mon, 25 Jul 2011 21:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=928; q=dns/txt; s=iport; t=1311654899; x=1312864499; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=jIknvkSDyKEusqJCPpWZNj2v6IiEIaZtk7SU95uvPOM=; b=mifzXIVOdP0CbT1/N+FXUCStbKAqUsO12vnw/9ELbABK6S/Ry3RemKF6 4CUS28HzyZdaJzjjZGL7SWjYbDcavAU4uJHdznnCt2Hj8pRqE++XkzPU7 G9Cxr6Vgpel0t8t9ywCZk0qCDaMD+qpyAyIqDG4ozFP4Bj/kUkIFKh5xn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0BAB5DLk6rRDoG/2dsb2JhbAA0AQEBAQMBAQERASFEFwcBCREEAQELBiMBBxMYIw4JAQUXDBuXXESPFHeJAKEvgSOeXoVhXwSHV5Ari3A X-IronPort-AV: E=Sophos;i="4.67,266,1309737600"; d="scan'208";a="6354011" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 04:34:57 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6Q4YviU024128 for ; Tue, 26 Jul 2011 04:34:57 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 21:34:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 21:34:47 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F8BD5F6@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-payload-rtp-klv-01 Thread-Index: Acw78gsfFCNII3eVSFOhZKDVFXst2gPWygmg From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 26 Jul 2011 04:34:57.0348 (UTC) FILETIME=[5F7CC840:01CC4B4D] Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-klv-01 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, 26 Jul 2011 04:34:59 -0000 The WGLC has ended a few days ago but I have not seen any comments on = the list. This is a short draft. We would appreciate to get some = comments on the list so that we can proceed with publication. Thanks. > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Ali C. Begen (abegen) > Sent: Wednesday, July 06, 2011 11:35 AM > To: payload@ietf.org > Subject: [payload] WGLC for draft-ietf-payload-rtp-klv-01 >=20 > Hi everyone, >=20 > This is to announce a 2-week WGLC for the following draft (ends July = 20th): > http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ >=20 > Please review the document and post any questions/concerns you have to = the mailing list. >=20 > Thanks. > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From HKaplan@acmepacket.com Tue Jul 26 07:11:54 2011 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 1125E21F8CB2; Tue, 26 Jul 2011 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id molQ6hVkKhx4; Tue, 26 Jul 2011 07:11:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AE39121F8BF2; Tue, 26 Jul 2011 07:11:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 10:11:51 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jul 2011 10:11:51 -0400 From: Hadriel Kaplan To: "draft-ramalho-payload-g7110@tools.ietf.org" Date: Tue, 26 Jul 2011 10:11:49 -0400 Thread-Topic: draft-ramalho-payload-g7110-00 to be discussed in AVTEXT Thread-Index: AcxLnfa5ON9/+YDUQsu+wdrgliSsAg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFR Cc: "avtext@ietf.org" , "payload@ietf.org" Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed in AVTEXT 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, 26 Jul 2011 14:11:54 -0000 [sorry for cross-posting, but this draft is going to be presented in avtext= ] Hi, I read this draft and I have a couple comments, as follows: 1) Have any IPR disclosures been submitted to the IETF for this? I ask bec= ause I believe there are several submitted to ITU for this codec. 2) The stuff in section 6 on "In the Middle" is really controversial, and a= rguably a very bad idea. =20 For one, just to be able to do this requires sniffing SDP which is only pos= sible if it's in cleartext, and if the sniffer can reassemble fragments or = stream segments, and if the sniffer is guaranteed to be in the path for all= SDP exchanges between the parties for ever. And to be able to really do i= t you have to *modify* the SDP which is a whole different ballgame. =20 And then there's the way in which the draft describes doing it, by insertin= g an fmtp attribute line of the new payload type, which is wrong in my opin= ion - it should either replace the payload type in the m-line and add the o= riginal 711a/u-law info as a new attribute, or better yet add the new paylo= ad type as another option in the m-line and wait for an SDP answer to choos= e (for protocols that have an offer/answer model). Otherwise the middlebox= has to know another middlebox is in the call path a priori. And then there's the problem of SRTP: if SRTP prevents the middlebox from d= oing the compression, the middlebox needs to know when SRTP is going to be = used by inspecting SDP, which isn't as straightforward as looking for "SAVP= " in the m-line... e.g. the endpoints could be using RFC 5939. =20 In summary: I would remove this idea/section from the draft. Publishing a = draft defining the payload format and media type for G.711.0 is fairly stra= ight-forward and non-controversial (I think), but going beyond that to "sup= port" this man-in-the-middle thing is going to cause you heartburn and dela= y getting the basic stuff published as an RFC. Just my 2 cents. -hadriel On Jul 25, 2011, at 12:55 PM, Michael Ramalho wrote: > This draft is a payload WG draft, but there isn=92t a payload meeting at = IETF 81. And this draft was previously scheduled to be discussed the AVT c= ore timeslot prior to its being moved to AVTEXT (thus the reason for the cr= oss post to all AVT groups). Roni and Ali encouraged me to say a few words = prior to the discussion this week. >=20 > G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payload= s. Thus it is a compression algorithm tailored for G.711. When negotiated e= nd-to-end it is negotiated =93as if it were a codec=94. >=20 > However, being lossless and stateless, G.711.0 can be applied anywhere wi= thin an end-to-end G.711 negotiated session. When applied in this manner, i= t suffers no voice quality degradation relative to G.711 (duh, its lossless= ). >=20 > Most of the open issues in the draft relate to the use of G.711.0 within = the context of an and-to-end G.711 negotiated session. >=20 > I look forward to comments generated from the discussion of this draft fo= r those cases. >=20 From mramalho@cisco.com Tue Jul 26 10:02:03 2011 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 268E81F0C36; Tue, 26 Jul 2011 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KuMOGVTxGJD; Tue, 26 Jul 2011 10:02:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB31F0C35; Tue, 26 Jul 2011 10:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=6156; q=dns/txt; s=iport; t=1311699722; x=1312909322; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MBQ7FyXq8UIIXOTbLBj38/GOqZYvQgVyw8NO+cmHlyA=; b=cLvIXOnUzNpW1OiHgs7LduWMaj37dlmwNYONpsrEj7l+ahheExRQfa8/ m2pkVuEQLXb4xa9k5RJqxk/6jma9MYkfnXNW/yb0Gkubg34fmUOH9HveP /uiUwfSXhGWrUunF8llwQ8TAEmBpaMc6pe8yOqD3/ROZP4VAajcJSQ5LL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAANXxLk6tJXG9/2dsb2JhbAArCwEBAQECAQEBAREBIQo6CwUHBQIBCQ4DBAEBCwYjAQYBExgjDggBAQUBFgwSCZdUj1p3iHwEowqeY4VhXwSHV5Ari24 X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6558096" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2011 17:02:01 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QH21JZ001856; Tue, 26 Jul 2011 17:02:01 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 12:02:01 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 12:01:52 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxLnfa5ON9/+YDUQsu+wdrgliSsAgAFt/Iw References: From: "Michael Ramalho (mramalho)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 26 Jul 2011 17:02:01.0157 (UTC) FILETIME=[BC8F3F50:01CC4BB5] Cc: avtext@ietf.org, payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT 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, 26 Jul 2011 17:02:03 -0000 Hadriel, Thank you for asking your question. Re: "Have any IPR disclosures been submitted to the IETF for this?" For the G.711.0 IETF payload draft, no. In the ITU-T there are four IPR disclosures for G.711.0 - one for each of the collaborating companies. However, Cisco had hoped for a disclosures to be filed at either the IETF or the ITU-T by IETF 81 by all four collaborating companies explicitly stating that G.711.0 for "consumer software terminals" (e.g., softclients) be royalty-free. We hope such a statement will be released in the near future. RE: "For one, just to be able to do this requires sniffing SDP " Not true. Virtually every implementation using G.711 I have found in practice uses the STATIC payload type of 0 or 8 for G.711. Thus every RTP packet with PT =3D [ 0 | 8 ] can only have a G.711 = payload inside of it. When G.711.0 is negotiated end to end, it will have its own media line. The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in either uncompressed (real G.711 with PT =3D [0 | 8]) or compressed (with PT =3D Q) form as equivalents. Part of the reason for the "hint in the G.711 SDP" is because SBCs will likely strip the G.711.0 m line from the SDP because it doesn't know about G.711.0 and only let the m line for G.711 to pass ... it might just let an unrecognized G.711 attribute through. I would like to get opinions for the group and appreciate your question. Re: SRTP Yep, the raw G.711 needs to be in the clear for the compression to work. Note that the PT is in the clear with SRTP (because the RTP header is in the clear) ... and thus SRTP should be able to encrypt G.711.0 without issues. Re: "Cut out the "In the Middle" section". That is a possibility. However I can say that we have explicit customer requests that IF such a compression is likely to be used by "in the middle entities" (i.e., service providers or administrative domains within a service provider), that we provide guidance on how to accomplish that compression so that everyone does it the same way. I also agree that keeping it in the draft will cause heartburn relative to its absence ;-). But I've got customers to please. And I have thick skin ;-). Re: "Middleboxes are a pain" Yes they are; but the are also a fact of life. I have a longer talk in which I enumerate the issues related to SBCs ... but that talk is inappropriate for the IETF slot (at least that is what I have been told). Thanks again, Michael Ramalho -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, July 26, 2011 10:12 AM To: draft-ramalho-payload-g7110@tools.ietf.org Cc: avtext@ietf.org; payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT [sorry for cross-posting, but this draft is going to be presented in avtext] Hi, I read this draft and I have a couple comments, as follows: 1) Have any IPR disclosures been submitted to the IETF for this? I ask because I believe there are several submitted to ITU for this codec. 2) The stuff in section 6 on "In the Middle" is really controversial, and arguably a very bad idea. =20 For one, just to be able to do this requires sniffing SDP which is only possible if it's in cleartext, and if the sniffer can reassemble fragments or stream segments, and if the sniffer is guaranteed to be in the path for all SDP exchanges between the parties for ever. And to be able to really do it you have to *modify* the SDP which is a whole different ballgame. =20 And then there's the way in which the draft describes doing it, by inserting an fmtp attribute line of the new payload type, which is wrong in my opinion - it should either replace the payload type in the m-line and add the original 711a/u-law info as a new attribute, or better yet add the new payload type as another option in the m-line and wait for an SDP answer to choose (for protocols that have an offer/answer model). Otherwise the middlebox has to know another middlebox is in the call path a priori. And then there's the problem of SRTP: if SRTP prevents the middlebox from doing the compression, the middlebox needs to know when SRTP is going to be used by inspecting SDP, which isn't as straightforward as looking for "SAVP" in the m-line... e.g. the endpoints could be using RFC 5939. =20 In summary: I would remove this idea/section from the draft. Publishing a draft defining the payload format and media type for G.711.0 is fairly straight-forward and non-controversial (I think), but going beyond that to "support" this man-in-the-middle thing is going to cause you heartburn and delay getting the basic stuff published as an RFC. Just my 2 cents. -hadriel On Jul 25, 2011, at 12:55 PM, Michael Ramalho wrote: > This draft is a payload WG draft, but there isn't a payload meeting at IETF 81. And this draft was previously scheduled to be discussed the AVT core timeslot prior to its being moved to AVTEXT (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me to say a few words prior to the discussion this week. >=20 > G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. When negotiated end-to-end it is negotiated "as if it were a codec". >=20 > However, being lossless and stateless, G.711.0 can be applied anywhere within an end-to-end G.711 negotiated session. When applied in this manner, it suffers no voice quality degradation relative to G.711 (duh, its lossless). >=20 > Most of the open issues in the draft relate to the use of G.711.0 within the context of an and-to-end G.711 negotiated session. >=20 > I look forward to comments generated from the discussion of this draft for those cases. >=20 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From HKaplan@acmepacket.com Tue Jul 26 10:51:17 2011 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 31ABE21F8A95; Tue, 26 Jul 2011 10:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpOkLJ1kPaZ9; Tue, 26 Jul 2011 10:51:16 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id DB0EF21F8A67; Tue, 26 Jul 2011 10:51:15 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 26 Jul 2011 13:51:14 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jul 2011 13:51:14 -0400 From: Hadriel Kaplan To: "Michael Ramalho (mramalho)" Date: Tue, 26 Jul 2011 13:51:13 -0400 Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxLvJwjeXPLpU4bTWeQAtZHOf9AMw== Message-ID: References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "avtext@ietf.org" , "payload@ietf.org" , "draft-ramalho-payload-g7110@tools.ietf.org" Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT 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, 26 Jul 2011 17:51:17 -0000 On Jul 26, 2011, at 1:01 PM, Michael Ramalho (mramalho) wrote: > RE: "For one, just to be able to do this requires sniffing SDP " >=20 > Not true. Virtually every implementation using G.711 I have found in > practice uses the STATIC payload type of 0 or 8 for G.711. >=20 > Thus every RTP packet with PT =3D [ 0 | 8 ] can only have a G.711 payload > inside of it. Sorry I should have been explicit. It needs to sniff to detect the PT of t= he G.711.0 payload. I.e., for the example diagram figure 4 in the draft, d= evice E needs to sniff the SDP offer to determine what the "Q" value is, an= d device C needs to do the same for the SDP answer for the reverse media st= ream. >=20 > When G.711.0 is negotiated end to end, it will have its own media line. Ummm... I'm confused. The example in the draft is: m=3Daudio RTP/AVP 0 a=3Drtpmap: 0 PCMU a=3Dfmtp:0 G7110 =3D Q <<< the G.711 SDP hint Are you saying that it's really this?: m=3Daudio 49120 RTP/AVP 0 a=3Drtpmap:0 PCMU a=3Dfmtp:0 G7110 =3D Q m=3Daudio 49120 RTP/AVP 99 a=3Drtpmap:99 G7110/8000 a=3Dptime:20 a=3Dfmtp:98 complaw=3Dmu > The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but > rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in > either uncompressed (real G.711 with PT =3D [0 | 8]) or compressed (with > PT =3D Q) form as equivalents. But they're NOT equivalent. For all intents and purposes G.711.0 is a diff= erent codec from G.711, afaict. That it can be implemented as a bump-in-th= e-wire without full DSPs matters not. The most logical thing for a middleb= ox to do would be to handle it exactly like it handles middlebox-provided t= ranscoding/transrating cases today, with normal SDP modifications/behavior,= no? (and by that I mean act as a first-class participant in SDP, by insert= ing/adding codecs into the same m-line, and handling offer/answer appropria= tely) -hadriel From kpfleming@digium.com Tue Jul 26 11:01:44 2011 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 57D4411E8122 for ; Tue, 26 Jul 2011 11:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxdaE7y6cvX6 for ; Tue, 26 Jul 2011 11:01:43 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 883CA11E810E for ; Tue, 26 Jul 2011 11:01:43 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Qllwt-0005OW-7o for payload@ietf.org; Tue, 26 Jul 2011 13:01:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 3BB1FD82A3 for ; Tue, 26 Jul 2011 13:01:43 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbpoW3p1Lsrh for ; Tue, 26 Jul 2011 13:01:42 -0500 (CDT) Received: from [130.129.16.72] (unknown [130.129.16.72]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id B0F05D8024 for ; Tue, 26 Jul 2011 13:01:42 -0500 (CDT) Message-ID: <4E2F0103.7020108@digium.com> Date: Tue, 26 Jul 2011 14:01:39 -0400 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: payload@ietf.org References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT 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, 26 Jul 2011 18:01:44 -0000 On 07/26/2011 01:51 PM, Hadriel Kaplan wrote: >> The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but >> rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in >> either uncompressed (real G.711 with PT = [0 | 8]) or compressed (with >> PT = Q) form as equivalents. > > But they're NOT equivalent. For all intents and purposes G.711.0 is a different codec from G.711, afaict. That it can be implemented as a bump-in-the-wire without full DSPs matters not. The most logical thing for a middlebox to do would be to handle it exactly like it handles middlebox-provided transcoding/transrating cases today, with normal SDP modifications/behavior, no? (and by that I mean act as a first-class participant in SDP, by inserting/adding codecs into the same m-line, and handling offer/answer appropriately) I tend to agree with Hadriel's opinion here; this really isn't much different from a pair of middleboxes in the path of a G.711 call choosing to transcode the audio stream to/from G.729 in order to save bandwidth (except that does require DSP-type processing, but that shouldn't affect how the transformation is signaled). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From mramalho@cisco.com Tue Jul 26 13:32:22 2011 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 6C18721F881C; Tue, 26 Jul 2011 13:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPAckP0h6+MZ; Tue, 26 Jul 2011 13:32:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9441421F87C7; Tue, 26 Jul 2011 13:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=4759; q=dns/txt; s=iport; t=1311712341; x=1312921941; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RW6rrr7zAq0vcj+dfzI+dQGphYj98qc9NkhU6EzYo5E=; b=EVBDvX0dmZQIoJsJ4ftmiytgRA9/3XX0fExp+7ABjbDOsmYplgeYmP9S mG78iD5JCs+I9yebyefhY+Q+DUyUuHMgW5vY67xRrKCJJWfgRAdKqaGBq JMtJGwEUvu2pDEz2xAGGJpBW02bXK8ZzL4AdlO5wuemJL5SsldMlCEQao g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAAsjL06tJXG9/2dsb2JhbAA1AQEBAQIBFAEhCkUFBwUCAQkOAwQBAQsGDhUBBgETOw4IAQEFFwwbl06PXHeIfKM3nlWDNoIrXwSHV5Ari24 X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6636156" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jul 2011 20:32:21 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKWKwX017186; Tue, 26 Jul 2011 20:32:21 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 15:32:20 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 15:32:19 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxLvJwjeXPLpU4bTWeQAtZHOf9AMwAEX9Zg References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> From: "Michael Ramalho (mramalho)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 26 Jul 2011 20:32:20.0171 (UTC) FILETIME=[1E13F9B0:01CC4BD3] Cc: avtext@ietf.org, payload@ietf.org, draft-ramalho-payload-g7110@tools.ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT 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, 26 Jul 2011 20:32:22 -0000 Hadriel, Thanks for the volley. Comments in-line below (w/ MAR:). Michael -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Tuesday, July 26, 2011 1:51 PM To: Michael Ramalho (mramalho) Cc: draft-ramalho-payload-g7110@tools.ietf.org; avtext@ietf.org; payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT On Jul 26, 2011, at 1:01 PM, Michael Ramalho (mramalho) wrote: > RE: "For one, just to be able to do this requires sniffing SDP " >=20 > Not true. Virtually every implementation using G.711 I have found in > practice uses the STATIC payload type of 0 or 8 for G.711. >=20 > Thus every RTP packet with PT =3D [ 0 | 8 ] can only have a G.711 payload > inside of it. Sorry I should have been explicit. It needs to sniff to detect the PT of the G.711.0 payload. I.e., for the example diagram figure 4 in the draft, device E needs to sniff the SDP offer to determine what the "Q" value is, and device C needs to do the same for the SDP answer for the reverse media stream. MAR: Thanks for the clarification. Yes, you have got it right (one exception shortly). SBCs normally "sniff SDP", so that might not be an issue for them. But in the case where there are multiple SBCs in the end-to-end path, one or more of them may strip out the G.711.0 m line (as you have it below) before a given SBC sees the end-to-end SDP. MAR: As an aside, some network providers may "configure PT =3D Q" in = their networks to make things easier (at the downside of not allowing their applications to use PT =3D Q), although that would not be recommended = (in the IETF or in general). MAR: Lastly, the compression can be applied in specific topologies - when there are no middleboxes that deny flows based on RTP PT changes - by tunnel endpoints that know how to compress/decompress G.711/G.711.0. This tunneling is unspecified magic in the draft. It can also be used in many of the same topologies where multi-hop header compression is employed. >=20 > When G.711.0 is negotiated end to end, it will have its own media line. Ummm... I'm confused. The example in the draft is: m=3Daudio RTP/AVP 0 a=3Drtpmap: 0 PCMU a=3Dfmtp:0 G7110 =3D Q <<< the G.711 SDP hint Are you saying that it's really this?: m=3Daudio 49120 RTP/AVP 0 a=3Drtpmap:0 PCMU a=3Dfmtp:0 G7110 =3D Q m=3Daudio 49120 RTP/AVP 99 a=3Drtpmap:99 G7110/8000 a=3Dptime:20 a=3Dfmtp:98 complaw=3Dmu MAR: Precisely ... one m-line for G.711 (in your case mu-law) and one m-line for G.711.0 (complaw=3Dmu, PT =3D 99). The "hint" is in the G.711 m-line (and the draft says so ... but you example makes it more clear .. thanks). MAR: I want to know if anyone "objects" to a new fmtp parameter "G7110/8000". Worse case, if an SBC doesn't like that parameter, it could strip it with no harm to setting up a G.711 flow. > The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but > rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in > either uncompressed (real G.711 with PT =3D [0 | 8]) or compressed = (with > PT =3D Q) form as equivalents. But they're NOT equivalent. For all intents and purposes G.711.0 is a different codec from G.711, afaict. MAR: OK .. we are even now .. I should have been more explicit here ;-). MAR: While I believe the best "in the middle" use cases are when SBCs are involved in the (lossless) transcode ... there are SOME LIMITED cases in which SPs desire to switch from G.711 to G.711.0 though such boxes without the transcode and without signaling (so-called "in-media methods"). Such SPs account for the bandwidth savings relative to G.711 in their traffic engineering. Like I said earlier, I have a longer talk on the subject and would be happy to discuss further. Perhaps I should have asked for a slot in the behave WG for these issues? That it can be implemented as a bump-in-the-wire without full DSPs matters not. The most logical thing for a middlebox to do would be to handle it exactly like it handles middlebox-provided transcoding/transrating cases today, with normal SDP modifications/behavior, no? (and by that I mean act as a first-class participant in SDP, by inserting/adding codecs into the same m-line, and handling offer/answer appropriately) MAR: See my last comment; there may be exceptions for specific customers and topologies. Indeed, the reason for the "hint" is precisely to inform devices such as SBCs that the switch from PT=3D0 to PT=3D99 (your = example) could occur naturally, so please don't kill the flow. MAR: Thanks again for your commentary, I appreciate it. -hadriel From mramalho@cisco.com Tue Jul 26 15:43:51 2011 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 9E50611E80D1 for ; Tue, 26 Jul 2011 15:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4LqWVM2Z1Ct for ; Tue, 26 Jul 2011 15:43:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8CA11E80BD for ; Tue, 26 Jul 2011 15:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=3048; q=dns/txt; s=iport; t=1311720230; x=1312929830; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=XRaHqNxRfqX9elP/eKLum188Ndih5HFmuasmnDQxVeg=; b=ZOmHlfNFQnhHak6gAbj9NoFQuvpaBfoimqqKe1pfTCLJszthfFYitc5f mxMztGZO+XVqm3obBEt3zqfAsNsCvvBjj78yiR4GzCB5tB4KozanyGkjX p0qYzR3OeB6ov6U2l4ttfN/r0ECYz/zhgxYrkJojtEyEzd42FDUtBtJoY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAIRCL06tJXHB/2dsb2JhbAA1AQEBAQIBAQEBEQEhChMnFwUCAQkRBAEBCwYjAQYBExgjDggBAQUBFgwbl06PXHeIfASjJ55XhWFfBIdXkCuLbg X-IronPort-AV: E=Sophos;i="4.67,272,1309737600"; d="scan'208";a="6684265" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 22:43:50 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6QMhnS9032624; Tue, 26 Jul 2011 22:43:50 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 17:43:49 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 17:43:48 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> In-Reply-To: <4E2F0103.7020108@digium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT Thread-Index: AcxLvh0jbzBYK5EjRkylJx6OIo0MMAAJtc3Q References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <4E2F0103.7020108@digium.com> From: "Michael Ramalho (mramalho)" To: "Kevin P. Fleming" , X-OriginalArrivalTime: 26 Jul 2011 22:43:49.0875 (UTC) FILETIME=[7CB54430:01CC4BE5] Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT 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, 26 Jul 2011 22:43:51 -0000 Kevin, Re: "this really isn't much different from a pair of middleboxes in the path of a G.711 call choosing to transcode the audio stream to/from G.729 in order to save bandwidth " I respectfully disagree. While a transcode from G.711 to G.729 "saves bandwidth" ... it also DEGRADES VOICE QUALITY. Thus adjacent signaling elements and/or endpoints and/or service providers SHOULD be informed that a transcode that degraded voice quality occurred. A natural way to inform the "other parties" is via signaling. A transcode from G.711 to G711.0 "saves bandwidth" (for zero-mean acoustic signals) ... but it does NOT degrade voice quality. Indeed, after the decompression the IDENTICAL G.711 PAYLOAD is reproduced. Thus adjacent signaling elements and/or endpoints and/or service providers NEED NOT be informed that it even occurred! So while I would heartily agree that lossy transcodes be signaled to the endpoints, I disagree that they need to be informed of a transformation which is truly invisible to the endpoints. Do we signal to the endpoints that RTP header compression occurred somewhere on the end-to-end path? I don't think so. Michael Ramalho -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Kevin P. Fleming Sent: Tuesday, July 26, 2011 2:02 PM To: payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT On 07/26/2011 01:51 PM, Hadriel Kaplan wrote: >> The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but >> rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in >> either uncompressed (real G.711 with PT =3D [0 | 8]) or compressed (with >> PT =3D Q) form as equivalents. > > But they're NOT equivalent. For all intents and purposes G.711.0 is a different codec from G.711, afaict. That it can be implemented as a bump-in-the-wire without full DSPs matters not. The most logical thing for a middlebox to do would be to handle it exactly like it handles middlebox-provided transcoding/transrating cases today, with normal SDP modifications/behavior, no? (and by that I mean act as a first-class participant in SDP, by inserting/adding codecs into the same m-line, and handling offer/answer appropriately) I tend to agree with Hadriel's opinion here; this really isn't much=20 different from a pair of middleboxes in the path of a G.711 call=20 choosing to transcode the audio stream to/from G.729 in order to save=20 bandwidth (except that does require DSP-type processing, but that=20 shouldn't affect how the transformation is signaled). --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From HKaplan@acmepacket.com Tue Jul 26 22:42:24 2011 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 4504311E8076; Tue, 26 Jul 2011 22:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUkeiI2sEHnD; Tue, 26 Jul 2011 22:42:23 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC811E8072; Tue, 26 Jul 2011 22:42:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 27 Jul 2011 01:42:19 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 01:42:17 -0400 From: Hadriel Kaplan To: "Michael Ramalho (mramalho)" Date: Wed, 27 Jul 2011 01:42:16 -0400 Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxMH/HOYigxaGnNRSO18vl/0yq1kw== Message-ID: <23FA88EE-A4E7-4A57-93BA-8B91501050F6@acmepacket.com> References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "avtext@ietf.org" , "payload@ietf.org" , "draft-ramalho-payload-g7110@tools.ietf.org" Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT 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, 27 Jul 2011 05:42:24 -0000 On Jul 26, 2011, at 4:32 PM, Michael Ramalho (mramalho) wrote: > MAR: Thanks for the clarification. Yes, you have got it right (one > exception shortly). SBCs normally "sniff SDP", so that might not be an > issue for them. But in the case where there are multiple SBCs in the > end-to-end path, one or more of them may strip out the G.711.0 m line > (as you have it below) before a given SBC sees the end-to-end SDP. I think the odds of an SBC stripping out something would be far less if thi= s weren't encoded as two m-lines for the same media type (audio). I.e., just do normal SDP like this: m=3Daudio 49120 RTP/AVP 0 99 a=3Dptime:20 a=3Drtpmap:99 G7110/8000 a=3Dfmtp:99 complaw=3Dmu > MAR: As an aside, some network providers may "configure PT =3D Q" in thei= r > networks to make things easier (at the downside of not allowing their > applications to use PT =3D Q), although that would not be recommended (in > the IETF or in general). But even if you fixed a PT for G.711.0, wouldn't you still need to sniff th= e SDP to learn the IP/port of the media? Or are you just going to guess th= at if the packet looks like RTP it is RTP?=20 > MAR: Lastly, the compression can be applied in specific topologies - > when there are no middleboxes that deny flows based on RTP PT changes - > by tunnel endpoints that know how to compress/decompress G.711/G.711.0. > This tunneling is unspecified magic in the draft. It can also be used in > many of the same topologies where multi-hop header compression is > employed. I don't understand what you mean, or why that matters. All I have to go by= is the diagram in the draft: ********************** * * |------------| |--------------------| * |---------------| * | A: | | B: | * | C: G.711.0 | * | SENDING |--->| ZERO OR MORE |---->| Compression | * | G.711 | | ROUTING AND/OR | * | PT=3D[0|8] | * | ENDPOINT | | SWITCHING HOPS | * | CHANGED TO | * | | | AND/OR MIDDLEBOXES | * | PT =3D Q | * |____________| |____________________| * |_______________| * * | * * | * ********* * | * * | * * V * * |--------------------| * * | D: | * G.711.0 * | ZERO OR MORE | * COMPRESSION * | ROUTING AND/OR | * SEGMENT * | SWITCHING HOPS | * (payload * | AND/OR MIDDLEBOXES | * only) * |____________________| * * | * * | * *********** | * * | * * V * |------------| |--------------------| * |---------------| * | G: | | F: | * | E: G.711.0 | * | RECEIVING |<---| ZERO OR MORE |<----| DECOMPRESSION | * | G.711 | | ROUTING AND/OR | * | PT =3D Q | * | ENDPOINT | | SWITCHING HOPS | * | CHANGED BACK | * | | | AND/OR MIDDLEBOXES | * | TO PT=3D[0|8] | * |____________| |____________________| * |_______________| * * * ********************** Are you saying that there's a GRE or MPLS tunnel between C and E, and that = C knows a priori (without SIP/SDP) that RTP it sends goes through E, and th= at C knows a priori that E is capable of G.711.0 decompression to 711a/u-la= w? -hadriel From HKaplan@acmepacket.com Tue Jul 26 22:49:21 2011 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 7625221F8680; Tue, 26 Jul 2011 22:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDs8bT7galCI; Tue, 26 Jul 2011 22:49:21 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4D21F85EE; Tue, 26 Jul 2011 22:49:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 27 Jul 2011 01:49:21 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 01:49:19 -0400 From: Hadriel Kaplan To: "Michael Ramalho (mramalho)" Date: Wed, 27 Jul 2011 01:49:18 -0400 Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxMIO1YGtl69Y2bTSOCOvRr/V940A== Message-ID: <90B879AD-0009-4ED4-870F-815197BA06BD@acmepacket.com> References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "avtext@ietf.org" , "payload@ietf.org" , "draft-ramalho-payload-g7110@tools.ietf.org" Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT 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, 27 Jul 2011 05:49:21 -0000 On Jul 26, 2011, at 4:32 PM, Michael Ramalho (mramalho) wrote: > Like I said earlier, I have a longer talk > on the subject and would be happy to discuss further. Perhaps I should > have asked for a slot in the behave WG for these issues? Yes a presentation discussion will help, but I don't think BEHAVE would be = the right WG. IMHO, most of this draft belongs in PAYLOAD, but all of section 6 belongs s= omewhere else, maybe MMUSIC. Just my 2 cents though. -hadriel From kpfleming@digium.com Wed Jul 27 06:29:25 2011 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 C94A421F8658 for ; Wed, 27 Jul 2011 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1VoA2MK-Sqz for ; Wed, 27 Jul 2011 06:29:24 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8421F85B2 for ; Wed, 27 Jul 2011 06:29:24 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Qm4At-0008Mi-Nq for payload@ietf.org; Wed, 27 Jul 2011 08:29:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id B212BD82AC for ; Wed, 27 Jul 2011 08:29:23 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEvXesgIh7mc for ; Wed, 27 Jul 2011 08:29:23 -0500 (CDT) Received: from [130.129.16.72] (dhcp-1048.meeting.ietf.org [130.129.16.72]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 4A8D2D82A5 for ; Wed, 27 Jul 2011 08:29:23 -0500 (CDT) Message-ID: <4E3012B2.7070701@digium.com> Date: Wed, 27 Jul 2011 09:29:22 -0400 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 CC: payload@ietf.org References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <4E2F0103.7020108@digium.com> <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT 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, 27 Jul 2011 13:29:25 -0000 On 07/26/2011 06:43 PM, Michael Ramalho (mramalho) wrote: > Kevin, > > Re: "this really isn't much different from a pair of middleboxes in the > path of a G.711 call choosing to transcode the audio stream to/from > G.729 in order to save bandwidth " > > I respectfully disagree. > > While a transcode from G.711 to G.729 "saves bandwidth" ... it also > DEGRADES VOICE QUALITY. Thus adjacent signaling elements and/or > endpoints and/or service providers SHOULD be informed that a transcode > that degraded voice quality occurred. A natural way to inform the "other > parties" is via signaling. > > A transcode from G.711 to G711.0 "saves bandwidth" (for zero-mean > acoustic signals) ... but it does NOT degrade voice quality. Indeed, > after the decompression the IDENTICAL G.711 PAYLOAD is reproduced. Thus > adjacent signaling elements and/or endpoints and/or service providers > NEED NOT be informed that it even occurred! > > So while I would heartily agree that lossy transcodes be signaled to the > endpoints, I disagree that they need to be informed of a transformation > which is truly invisible to the endpoints. Fair enough. I probably shouldn't have tried to read the draft yesterday in the middle of an IETF WG meeting. Mea culpa. > Do we signal to the endpoints that RTP header compression occurred > somewhere on the end-to-end path? I don't think so. No, but there is still signaling between the middleboxes that decide to compress/uncompress RTP headers along the path, and the endpoints don't even have to be aware that this is a possibility. Granted, this draft also allows for such 'endpoint ignorance' if the middleboxes use some signaling mechanism (defined elsewhere), but it just feels a bit strange to me to have endpoints use a mechanism to indicate to some elements that might be in the path how an optional behavior should be employed. Is it at all realistic to get a static RTP payload number assigned for G.711.0? If that was done, then such middleboxes wouldn't need any help from the endpoints to select a payload number to use for the transformed media. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From stephen.botzko@gmail.com Wed Jul 27 06:35:30 2011 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 9A7B411E807A for ; Wed, 27 Jul 2011 06:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpAeeYGtzWU5 for ; Wed, 27 Jul 2011 06:35:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6944B21F847D for ; Wed, 27 Jul 2011 06:35:24 -0700 (PDT) Received: by vws12 with SMTP id 12so1432072vws.31 for ; Wed, 27 Jul 2011 06:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YlkCLR3s5iPUe4w0cUoko7zbCOK8PvEf0W45KKBgWfs=; b=rkZYeVT4hzr6xRPWSqg6Tvzk6S21BuSmC4qllLWgPuovDY+nqY93d5JyfH8r/DR0lb G1A8SiSoAaa9EFlMOAhNjPX41XVp6sk6EqSef5mDrKEv4lbezH0HBhZXS/CI10OlQsVY bTmFd99kLRVZtSusBd234pq+YK1D7DGO1qLpM= MIME-Version: 1.0 Received: by 10.52.69.39 with SMTP id b7mr57509vdu.264.1311773723854; Wed, 27 Jul 2011 06:35:23 -0700 (PDT) Received: by 10.52.185.71 with HTTP; Wed, 27 Jul 2011 06:35:23 -0700 (PDT) In-Reply-To: <4E3012B2.7070701@digium.com> References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <4E2F0103.7020108@digium.com> <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> <4E3012B2.7070701@digium.com> Date: Wed, 27 Jul 2011 09:35:23 -0400 Message-ID: From: Stephen Botzko To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=90e6ba475d4fd607da04a90d1e3e Cc: payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT 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, 27 Jul 2011 13:35:30 -0000 --90e6ba475d4fd607da04a90d1e3e Content-Type: text/plain; charset=ISO-8859-1 static payload types are a scarce resource, I wouldn't assign one to this (even if it were practical), as this is a very specialized use case for a rather specialized codec. Stephen Botzko On Wed, Jul 27, 2011 at 9:29 AM, Kevin P. Fleming wrote: > On 07/26/2011 06:43 PM, Michael Ramalho (mramalho) wrote: > >> Kevin, >> >> Re: "this really isn't much different from a pair of middleboxes in the >> path of a G.711 call choosing to transcode the audio stream to/from >> G.729 in order to save bandwidth " >> >> I respectfully disagree. >> >> While a transcode from G.711 to G.729 "saves bandwidth" ... it also >> DEGRADES VOICE QUALITY. Thus adjacent signaling elements and/or >> endpoints and/or service providers SHOULD be informed that a transcode >> that degraded voice quality occurred. A natural way to inform the "other >> parties" is via signaling. >> >> A transcode from G.711 to G711.0 "saves bandwidth" (for zero-mean >> acoustic signals) ... but it does NOT degrade voice quality. Indeed, >> after the decompression the IDENTICAL G.711 PAYLOAD is reproduced. Thus >> adjacent signaling elements and/or endpoints and/or service providers >> NEED NOT be informed that it even occurred! >> >> So while I would heartily agree that lossy transcodes be signaled to the >> endpoints, I disagree that they need to be informed of a transformation >> which is truly invisible to the endpoints. >> > > Fair enough. I probably shouldn't have tried to read the draft yesterday in > the middle of an IETF WG meeting. Mea culpa. > > > Do we signal to the endpoints that RTP header compression occurred >> somewhere on the end-to-end path? I don't think so. >> > > No, but there is still signaling between the middleboxes that decide to > compress/uncompress RTP headers along the path, and the endpoints don't even > have to be aware that this is a possibility. Granted, this draft also allows > for such 'endpoint ignorance' if the middleboxes use some signaling > mechanism (defined elsewhere), but it just feels a bit strange to me to have > endpoints use a mechanism to indicate to some elements that might be in the > path how an optional behavior should be employed. > > Is it at all realistic to get a static RTP payload number assigned for > G.711.0? If that was done, then such middleboxes wouldn't need any help from > the endpoints to select a payload number to use for the transformed media. > > > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > ______________________________**_________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/**listinfo/payload > --90e6ba475d4fd607da04a90d1e3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable static payload types are a scarce resource, I wouldn't assign one to th= is (even if it were practical), as this is a very specialized use case for = a rather specialized codec.

Stephen Botzko

On Wed, Jul 27, 2011 at 9:29 AM, Kevin P. Fleming <kpfleming@digium.com> wr= ote:
On 07/26/2011 06:43 PM, Michael Ramalho (mramalho) wrote:=
Kevin,

Re: "this really isn't much =A0different from a pair of middleboxe= s in the
path of a G.711 call choosing to transcode the audio stream to/from
G.729 in order to save bandwidth "

I respectfully disagree.

While a transcode from G.711 to G.729 "saves bandwidth" ... it al= so
DEGRADES VOICE QUALITY. Thus adjacent signaling elements and/or
endpoints and/or service providers SHOULD be informed that a transcode
that degraded voice quality occurred. A natural way to inform the "oth= er
parties" is via signaling.

A transcode from G.711 to G711.0 "saves bandwidth" (for zero-mean=
acoustic signals) ... but it does NOT degrade voice quality. Indeed,
after the decompression the IDENTICAL G.711 PAYLOAD is reproduced. Thus
adjacent signaling elements and/or endpoints and/or service providers
NEED NOT be informed that it even occurred!

So while I would heartily agree that lossy transcodes be signaled to the endpoints, I disagree that they need to be informed of a transformation
which is truly invisible to the endpoints.

Fair enough. I probably shouldn't have tried to read the draft yesterda= y in the middle of an IETF WG meeting. Mea culpa.


Do we signal to the endpoints that RTP header compression occurred
somewhere on the end-to-end path? I don't think so.

No, but there is still signaling between the middleboxes that decide to com= press/uncompress RTP headers along the path, and the endpoints don't ev= en have to be aware that this is a possibility. Granted, this draft also al= lows for such 'endpoint ignorance' if the middleboxes use some sign= aling mechanism (defined elsewhere), but it just feels a bit strange to me = to have endpoints use a mechanism to indicate to some elements that might b= e in the path how an optional behavior should be employed.

Is it at all realistic to get a static RTP payload number assigned for G.71= 1.0? If that was done, then such middleboxes wouldn't need any help fro= m the endpoints to select a payload number to use for the transformed media= .



--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@d= igium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.dig= ium.com & www= .asterisk.org
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload

--90e6ba475d4fd607da04a90d1e3e-- From HKaplan@acmepacket.com Wed Jul 27 06:56:35 2011 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 CEC4521F8610 for ; Wed, 27 Jul 2011 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um2Avxu5HSEB for ; Wed, 27 Jul 2011 06:56:35 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4316321F850B for ; Wed, 27 Jul 2011 06:56:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 27 Jul 2011 09:53:33 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 09:56:34 -0400 From: Hadriel Kaplan To: "Michael Ramalho (mramalho)" Date: Wed, 27 Jul 2011 09:56:35 -0400 Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT Thread-Index: AcxMZP63uQDIihw7RVux0r04YFfXOA== Message-ID: References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <4E2F0103.7020108@digium.com> <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "payload@ietf.org" Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT 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, 27 Jul 2011 13:56:35 -0000 On Jul 26, 2011, at 6:43 PM, Michael Ramalho (mramalho) wrote: > While a transcode from G.711 to G.729 "saves bandwidth" ... it also > DEGRADES VOICE QUALITY. It doesn't matter whether a particular codec or payload transform is lossle= ss or not, from the perspective of SDP and RTP. SRTP encrypt/decrypt and a= uthentication is also completely "lossless". You could, in theory, do SRTP= between two middleboxes. All you'd need is a way to exchange keys between= the two middleboxes, just like for G.711.0 you need a way to exchange payl= oad types and companding. Obviously SBCs and other middleboxes can and do = SRTP termination/origination, but we would never have done it the way this = draft is describing to do G.711.0. I must be missing something about your = use-case that makes it different. > Do we signal to the endpoints that RTP header compression occurred > somewhere on the end-to-end path? I don't think so. >=20 ROHC for RTP only works in extremely constrained deployment scenarios, and = as far as I'm aware can only be done either by the devices generating the R= TP so they know what IP/UDP combo stream is RTP before-hand, or by channeli= zation/separation and signaling for a context. And as far as I know it has= signaling in ROHC itself - it's not just blindly starting to compress with= out knowing the far-end is capable of decompressing and what modes.=20 -hadriel From mperumal@cisco.com Wed Jul 27 08:51:22 2011 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 2C05711E80F3 for ; Wed, 27 Jul 2011 08:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvubl+a48TS1 for ; Wed, 27 Jul 2011 08:51:21 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC2A011E80F5 for ; Wed, 27 Jul 2011 08:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=36446; q=dns/txt; s=iport; t=1311781874; x=1312991474; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=aTzyX63/gMW2EIP2BuH5d46x+OOOymmWN/uw9aMHt1I=; b=IGifR6M1ZfEXlQAt9u9KJ5YI2G2UHZy5IbZER/FR7WKIbuotfjmmoJWM FRi0W3/UksTdNHLhGMLVLxL55OxrqjP/hMcRRSqQIailc6ySIp9wwwWJ8 +FRj1NjxpsRVt8Gv7A3p8lWbBGHOEASf6wcrNH443JHVN16k7jOKCNV1B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAKEyME5Io8UT/2dsb2JhbAA1AQEBAQMBAQERAQwSAx0nCxECAQkRBAEBCwYcAQYBBgETFwEjDggBAQUBCwoBDBuCNpUfj0h3iQCjYp5rhWFfBIdVkDCLWg X-IronPort-AV: E=Sophos;i="4.67,276,1309737600"; d="scan'208,217";a="44987318" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 27 Jul 2011 15:51:09 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6RFp82M012941; Wed, 27 Jul 2011 15:51:08 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 21:21:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C75.0011BA57" Date: Wed, 27 Jul 2011 21:21:06 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206096D43@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT Thread-Index: AcxMYji6IrSqQIaHTMSpVkLMjpYregAEoWIA References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com><4E2F0103.7020108@digium.com><999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com><4E3012B2.7070701@digium.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Stephen Botzko" , "Kevin P. Fleming" X-OriginalArrivalTime: 27 Jul 2011 15:51:08.0661 (UTC) FILETIME=[00499A50:01CC4C75] Cc: payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT 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, 27 Jul 2011 15:51:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C75.0011BA57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is literally impossible to assign one, because RFC 3551 establishes a policy that no more static payload type values would be assigned for RTP/AVP: =20 This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in this document. Establishing this policy avoids the problem of trying to create a set of criteria for accepting static assignments and encourages the implementation and deployment of the dynamic payload type mechanisms. =20 The final set of static payload type assignments is provided in Tables 4 and 5. =20 Muthu =20 From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, July 27, 2011 7:05 PM To: Kevin P. Fleming Cc: payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT =20 static payload types are a scarce resource, I wouldn't assign one to this (even if it were practical), as this is a very specialized use case for a rather specialized codec. Stephen Botzko On Wed, Jul 27, 2011 at 9:29 AM, Kevin P. Fleming wrote: On 07/26/2011 06:43 PM, Michael Ramalho (mramalho) wrote: Kevin, Re: "this really isn't much different from a pair of middleboxes in the path of a G.711 call choosing to transcode the audio stream to/from G.729 in order to save bandwidth " I respectfully disagree. While a transcode from G.711 to G.729 "saves bandwidth" ... it also DEGRADES VOICE QUALITY. Thus adjacent signaling elements and/or endpoints and/or service providers SHOULD be informed that a transcode that degraded voice quality occurred. A natural way to inform the "other parties" is via signaling. A transcode from G.711 to G711.0 "saves bandwidth" (for zero-mean acoustic signals) ... but it does NOT degrade voice quality. Indeed, after the decompression the IDENTICAL G.711 PAYLOAD is reproduced. Thus adjacent signaling elements and/or endpoints and/or service providers NEED NOT be informed that it even occurred! So while I would heartily agree that lossy transcodes be signaled to the endpoints, I disagree that they need to be informed of a transformation which is truly invisible to the endpoints. =20 Fair enough. I probably shouldn't have tried to read the draft yesterday in the middle of an IETF WG meeting. Mea culpa. =20 Do we signal to the endpoints that RTP header compression occurred somewhere on the end-to-end path? I don't think so. =20 No, but there is still signaling between the middleboxes that decide to compress/uncompress RTP headers along the path, and the endpoints don't even have to be aware that this is a possibility. Granted, this draft also allows for such 'endpoint ignorance' if the middleboxes use some signaling mechanism (defined elsewhere), but it just feels a bit strange to me to have endpoints use a mechanism to indicate to some elements that might be in the path how an optional behavior should be employed. Is it at all realistic to get a static RTP payload number assigned for G.711.0? If that was done, then such middleboxes wouldn't need any help from the endpoints to select a payload number to use for the transformed media. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload =20 ------_=_NextPart_001_01CC4C75.0011BA57 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is literally impossible to assign one, because RFC 3551 establishes a policy that no more static payload type values would be assigned for = RTP/AVP:

 

<snip>

   This specification = establishes the policy that no additional static

   payload types will be = assigned beyond the ones defined in this

   document.  Establishing this policy avoids the problem of trying = to

   create a set of criteria = for accepting static assignments and

   encourages the = implementation and deployment of the dynamic payload

   type = mechanisms.

 

   The final set of static = payload type assignments is provided in

   Tables 4 and = 5.

</snip>

 

Muthu

 

From: payload-bounces@ietf.org = [mailto:payload-bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, July 27, 2011 7:05 PM
To: Kevin P. Fleming
Cc: payload@ietf.org
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT

 

static payload types = are a scarce resource, I wouldn't assign one to this (even if it were = practical), as this is a very specialized use case for a rather specialized codec.

Stephen Botzko

On Wed, Jul 27, 2011 at 9:29 AM, Kevin P. Fleming = <kpfleming@digium.com> = wrote:

On 07/26/2011 06:43 PM, Michael Ramalho (mramalho) = wrote:

Kevin,

Re: "this really isn't much  different from a pair of = middleboxes in the
path of a G.711 call choosing to transcode the audio stream to/from
G.729 in order to save bandwidth "

I respectfully disagree.

While a transcode from G.711 to G.729 "saves bandwidth" ... it = also
DEGRADES VOICE QUALITY. Thus adjacent signaling elements and/or
endpoints and/or service providers SHOULD be informed that a = transcode
that degraded voice quality occurred. A natural way to inform the = "other
parties" is via signaling.

A transcode from G.711 to G711.0 "saves bandwidth" (for = zero-mean
acoustic signals) ... but it does NOT degrade voice quality. Indeed,
after the decompression the IDENTICAL G.711 PAYLOAD is reproduced. = Thus
adjacent signaling elements and/or endpoints and/or service = providers
NEED NOT be informed that it even occurred!

So while I would heartily agree that lossy transcodes be signaled to = the
endpoints, I disagree that they need to be informed of a = transformation
which is truly invisible to the endpoints.

 

Fair enough. I probably shouldn't have tried to = read the draft yesterday in the middle of an IETF WG meeting. Mea = culpa.

 

Do we signal to the endpoints that RTP header = compression occurred
somewhere on the end-to-end path? I don't think so.

 

No, but there is still signaling between the = middleboxes that decide to compress/uncompress RTP headers along the path, and the endpoints don't even have to be aware that this is a possibility. = Granted, this draft also allows for such 'endpoint ignorance' if the middleboxes use = some signaling mechanism (defined elsewhere), but it just feels a bit strange = to me to have endpoints use a mechanism to indicate to some elements that = might be in the path how an optional behavior should be employed.

Is it at all realistic to get a static RTP payload number assigned for = G.711.0? If that was done, then such middleboxes wouldn't need any help from the endpoints to select a payload number to use for the transformed = media.




--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload<= /o:p>

 

------_=_NextPart_001_01CC4C75.0011BA57-- From mramalho@cisco.com Wed Jul 27 10:36:13 2011 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 2458121F8A4B; Wed, 27 Jul 2011 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fw9MOZ+8QYj; Wed, 27 Jul 2011 10:36:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50CA621F8A30; Wed, 27 Jul 2011 10:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=5819; q=dns/txt; s=iport; t=1311788172; x=1312997772; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gkcgh0RX3GcfxB0yPyqp8PBwbGv9tl1T7Sl9ax+FjKU=; b=OoszJHsOxKZdlcMHvGFwRrntnn7KsjIPIa57s5Wxqa2rM3c3d5WuaLC4 IzjugesWwcZUexHhC5UMgQN6GrsD0+LcvDEKneoUHAoKGrkOa0ZE0obfv Md3xOyZ+bKcHNIjp8cdIzx6Cna//NO/0/B6wxxbUod95RVZk43UnIGp3Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAACBMME6tJXG8/2dsb2JhbAA1AQEBAQIBFAEYCQpFBQcFAgEJDgMEAQELBiMBBgETOw4IAQEFFwwbl1mPSHeIfKNWnm2FYV8Eh1eQLotw X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208";a="7078934" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2011 17:36:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RHa5Zk010784; Wed, 27 Jul 2011 17:36:05 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 12:36:04 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 12:36:03 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E33C1@XMB-RCD-209.cisco.com> In-Reply-To: <23FA88EE-A4E7-4A57-93BA-8B91501050F6@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT Thread-Index: AcxMH/HOYigxaGnNRSO18vl/0yq1kwAYoP3w References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com> <23FA88EE-A4E7-4A57-93BA-8B91501050F6@acmepacket.com> From: "Michael Ramalho (mramalho)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 27 Jul 2011 17:36:04.0291 (UTC) FILETIME=[A8C68130:01CC4C83] Cc: avtext@ietf.org, payload@ietf.org, draft-ramalho-payload-g7110@tools.ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT 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, 27 Jul 2011 17:36:13 -0000 Hadriel, Re: Put G.711.0 on one m-line. If others believe, as you do, that having G.711.0 on it's own m-line is actually worse (in the sense of the probability of it being stripped out) than having in on the same m-line as G.711 ... I am OK with that. Do others have an opinion? I am inclined to go with your recommendation if no one objects. Re: "Are you saying that there's a GRE or MPLS tunnel between C and E, and that C knows a priori (without SIP/SDP) that RTP it sends goes through E, and that C knows a priori that E is capable of G.711.0 decompression to 711a/u-law?" A tunnel of some sort ... including WAAS-like tunnels in enterprise use cases. The question of how the end tunnels (Box C and E) "find themselves" is purposely left outside the scope of the draft. What I am hoping for is that we can specify some principals for how you compress/decompress so that the flow to the "G.711.0 unaware" endpoints don't know it occurred. Better text is always welcome. Thanks again, Michael -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Wednesday, July 27, 2011 1:42 AM To: Michael Ramalho (mramalho) Cc: draft-ramalho-payload-g7110@tools.ietf.org; avtext@ietf.org; payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT On Jul 26, 2011, at 4:32 PM, Michael Ramalho (mramalho) wrote: > MAR: Thanks for the clarification. Yes, you have got it right (one > exception shortly). SBCs normally "sniff SDP", so that might not be an > issue for them. But in the case where there are multiple SBCs in the > end-to-end path, one or more of them may strip out the G.711.0 m line > (as you have it below) before a given SBC sees the end-to-end SDP. I think the odds of an SBC stripping out something would be far less if this weren't encoded as two m-lines for the same media type (audio). I.e., just do normal SDP like this: m=3Daudio 49120 RTP/AVP 0 99 a=3Dptime:20 a=3Drtpmap:99 G7110/8000 a=3Dfmtp:99 complaw=3Dmu > MAR: As an aside, some network providers may "configure PT =3D Q" in their > networks to make things easier (at the downside of not allowing their > applications to use PT =3D Q), although that would not be recommended (in > the IETF or in general). But even if you fixed a PT for G.711.0, wouldn't you still need to sniff the SDP to learn the IP/port of the media? Or are you just going to guess that if the packet looks like RTP it is RTP?=20 > MAR: Lastly, the compression can be applied in specific topologies - > when there are no middleboxes that deny flows based on RTP PT changes - > by tunnel endpoints that know how to compress/decompress G.711/G.711.0. > This tunneling is unspecified magic in the draft. It can also be used in > many of the same topologies where multi-hop header compression is > employed. I don't understand what you mean, or why that matters. All I have to go by is the diagram in the draft: ********************** * * |------------| |--------------------| * |---------------| * | A: | | B: | * | C: G.711.0 | * | SENDING |--->| ZERO OR MORE |---->| Compression | * | G.711 | | ROUTING AND/OR | * | PT=3D[0|8] | * | ENDPOINT | | SWITCHING HOPS | * | CHANGED TO | * | | | AND/OR MIDDLEBOXES | * | PT =3D Q | * |____________| |____________________| * |_______________| * * | * * | * ********* * | * * | * * V * * |--------------------| * * | D: | * G.711.0 * | ZERO OR MORE | * COMPRESSION * | ROUTING AND/OR | * SEGMENT * | SWITCHING HOPS | * (payload * | AND/OR MIDDLEBOXES | * only) * |____________________| * * | * * | * *********** | * * | * * V * |------------| |--------------------| * |---------------| * | G: | | F: | * | E: G.711.0 | * | RECEIVING |<---| ZERO OR MORE |<----| DECOMPRESSION | * | G.711 | | ROUTING AND/OR | * | PT =3D Q | * | ENDPOINT | | SWITCHING HOPS | * | CHANGED BACK | * | | | AND/OR MIDDLEBOXES | * | TO PT=3D[0|8] | * |____________| |____________________| * |_______________| * * * ********************** Are you saying that there's a GRE or MPLS tunnel between C and E, and that C knows a priori (without SIP/SDP) that RTP it sends goes through E, and that C knows a priori that E is capable of G.711.0 decompression to 711a/u-law? -hadriel From mramalho@cisco.com Wed Jul 27 11:36:30 2011 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 D29E021F8B34 for ; Wed, 27 Jul 2011 11:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX90XdouEXiG for ; Wed, 27 Jul 2011 11:36:30 -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 1D42C21F8B01 for ; Wed, 27 Jul 2011 11:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=3374; q=dns/txt; s=iport; t=1311791790; x=1313001390; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1h7vFz6WwbfMFMClO8pAO4nKNNUwBrO+sGOx0krWq+o=; b=Y5i6MUXH9Tmd8wNZy1L489E6R/IIRE8uHI+tz8H6lxz0LN5tq6oI7rCJ cMTbWB26bxVJJqMWNvg4RTiLIO5Z+Wp/KoY6vtEvsd3BBtWixSRQRmPAP qro8a+sZTQmlnOr2Ehtz0znGSrgTAkfxq67pqo4THthBAtIiu1UZ8blka E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAEVaME6tJXG+/2dsb2JhbAA1AQEBAQIBFAEhCkUFBwUCAQkOAwQBAQsGIwEGARM7DggBAQUXDBuXW49Id4h8oz6ea4VhXwSHV5Aui3A X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208";a="7096181" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jul 2011 18:36:29 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIaTFS024246; Wed, 27 Jul 2011 18:36:29 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 13:36:29 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 13:36:28 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0044E3439@XMB-RCD-209.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT Thread-Index: AcxMZP63uQDIihw7RVux0r04YFfXOAAJF+5g References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <4E2F0103.7020108@digium.com> <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> From: "Michael Ramalho (mramalho)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 27 Jul 2011 18:36:29.0572 (UTC) FILETIME=[199C7C40:01CC4C8C] Cc: payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT 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, 27 Jul 2011 18:36:30 -0000 Hadriel, In-line below. Michael -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Wednesday, July 27, 2011 9:57 AM To: Michael Ramalho (mramalho) Cc: Kevin P. Fleming; payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT On Jul 26, 2011, at 6:43 PM, Michael Ramalho (mramalho) wrote: > While a transcode from G.711 to G.729 "saves bandwidth" ... it also > DEGRADES VOICE QUALITY. It doesn't matter whether a particular codec or payload transform is lossless or not, from the perspective of SDP and RTP. SRTP encrypt/decrypt and authentication is also completely "lossless". You could, in theory, do SRTP between two middleboxes. MAR: Not even in theory .. but also in practice! MAR: SRTP was designed (as I understand it) from day one to encrypt between "session endpoints". MAR: Insofar as the UAs facing each other in two consenting SBCs are SIP dialog endpoints (i.e., "in the middle" of a longer end-to-end "call") ... they can do SRTP between them! MAR: I guess I don't get the "in theory" part. All you'd need is a way to exchange keys between the two middleboxes, just like for G.711.0 you need a way to exchange payload types and companding. MAR: The companding for the "G.711.0 compression segment" (as defined in the draft) is assumed to be the companding used in the true user endpoints ... which can be determined from the incoming PT (0 or 8). MAR: The communication/negotiation/exchange between the "G.711.0 tunnel endpoints" is purposely unspecified in the draft. Indeed, how the G.711.0 compression/decompression endpoints "find themselves" is also purposely unspecified in the draft. MAR: In the absence of middleboxes and NAT/PAT and in certain topologies ... there are a variety of simple "in-media" methods by which compression/decompression endpoints can find themselves. There are many "gotchas" for those use cases ... but again ... these cases are purposely unspecified in the draft. Unfortunately, I was not allotted enough time to go through those cases in the avtext meeting today. MAR: My comment about various forms of header compression was to point out, via example, that SBCs do not always know what is going on "within" the flows that traverse them (I could put a friendly comment that SBCs being "control freaks" ... but I'll refrain ;-) ). Obviously SBCs and other middleboxes can and do SRTP termination/origination, but we would never have done it the way this draft is describing to do G.711.0. I must be missing something about your use-case that makes it different. MAR: I wouldn't use per-flow encryption in your example either ... but that is a different story. > Do we signal to the endpoints that RTP header compression occurred > somewhere on the end-to-end path? I don't think so. >=20 ROHC for RTP only works in extremely constrained deployment scenarios, and as far as I'm aware can only be done either by the devices generating the RTP so they know what IP/UDP combo stream is RTP before-hand, or by channelization/separation and signaling for a context. And as far as I know it has signaling in ROHC itself - it's not just blindly starting to compress without knowing the far-end is capable of decompressing and what modes.=20 -hadriel From jonathan@vidyo.com Wed Jul 27 12:11:17 2011 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 AF53321F8862; Wed, 27 Jul 2011 12:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03mTuBnRC5ra; Wed, 27 Jul 2011 12:11:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id F095421F8779; Wed, 27 Jul 2011 12:10:41 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5D3AB8BE73E; Wed, 27 Jul 2011 15:10:41 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id DCEB08BE54B; Wed, 27 Jul 2011 15:10:35 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Wed, 27 Jul 2011 15:10:26 -0400 From: Jonathan Lennox To: "codec@ietf.org" , "payload@ietf.org" Date: Wed, 27 Jul 2011 15:10:34 -0400 Thread-Topic: [payload] Frames to Packets in draft-ietf-codec-opus-07? Thread-Index: AcxMkNzxKrhe3c1/SY+h3AcPKT1kOQ== Message-ID: <5AC4E10B-A3D0-4438-8F69-F7F282D3843B@vidyo.com> References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> <4E2DAE67.6090008@fas.harvard.edu> In-Reply-To: <4E2DAE67.6090008@fas.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] Frames to Packets in draft-ietf-codec-opus-07? 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, 27 Jul 2011 19:11:18 -0000 On Jul 25, 2011, at 1:56 PM, Benjamin M. Schwartz wrote: > On 07/25/2011 10:23 AM, Christian Hoene wrote: >> I was wondering why the draft-ietf-codec-opus-07 draft has feature to >> concatenate multiple codec frames to packets. At the same time, >> draft-spittka-payload-rtp-opus-00 does not support to place multiple cod= ec >> entities in on RTP packet. >=20 > I think we are in agreement that for many packet transports, a single > frame per packet (max duration of 20~ms for general audio, minimum of > 2.5ms or 400 pps) would be inappropriate, and so a concatenation scheme i= s > required. The question is then: where should the concatenation scheme be > specified? Does the Opus framing allow packets to be split and/or aggregated by a midd= lebox along frame boundaries, without requiring transcoding? (The use case= for splitting is to forward traffic to a box with a lower maxptime than th= e stream you're receiving, and the use case for aggregation is to reduce th= e RTP header overhead at the cost of some additional delay.) I tried to read the Opus spec to answer my question, and I think I came up = with the answer, but I wanted to confirm this with the Opus experts. Based on my reading of the Opus spec, it looks like splitting should be pos= sible, relatively trivially. Aggregation, however, is only possible if the= packets to be aggregated have the same value for the Opus TOC byte. I get the impression that the TOC byte is expected to change only relativel= y infrequently in most encoding modes, in which case this would be fine -- = there may be transient packets which couldn't be aggregated, resulting in o= ccasional "short" packets, but most packets could be aggregated. However, = if an encoder might change its TOC frequently, this could be more problemat= ic. If the (Payload) WG is okay with this limitation (and the limitation of a m= aximum of 120 ms packets), I think the internal-framing-only is okay; if no= t, we might need external framing as well. (I appreciate that you don't wan= t to change the Opus bitstream proper, at this point.) -- Jonathan Lennox jonathan@vidyo.com From bmschwar@fas.harvard.edu Wed Jul 27 12:21:08 2011 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 E8FB821F8BB1; Wed, 27 Jul 2011 12:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufQBNGmp-CIU; Wed, 27 Jul 2011 12:21:08 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3609A21F8BB4; Wed, 27 Jul 2011 12:21:08 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us18.unix.fas.harvard.edu (Postfix) with ESMTP id 6F2F14D5E5B; Wed, 27 Jul 2011 15:21:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=o5m8AaVwZHWkcLF osnnIOC6QROi33hIxdkW2mqiYsNA=; b=smLHgS46p2YyDGxathyoNRzbweimiax 79sisqo6yToHoL8lME62DBulSkaQ510tMMcgP2K2C40CfUtiYpLZIcawFqLJ8bGE vb/UKRIKAK86JMSaSMYJ95mMCSdcpbnIf/23SEtDcwd+2qre6MUnrPkef8F+HLIj XM9lKc27+KWY= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=JOgYjhtG3 mRpSabQ1Pi5OWMiZeh9yg6XdjpoyRwbgdLH4aaWv4qBJO38EjosJVWwj367IQb4F yETrrX/Z3tzMkEFimb+0xk3v3nmMN8CoDRke/MW81woCplDLG/ONcPm25g/5Kb4K 77I5pvU1IdvHeDdDeTQHsz6mq514lDAOd8= Received: from [172.23.141.135] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 675FB4D5E54; Wed, 27 Jul 2011 15:21:05 -0400 (EDT) Message-ID: <4E30651E.7090305@fas.harvard.edu> Date: Wed, 27 Jul 2011 15:21:02 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jonathan Lennox References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> <4E2DAE67.6090008@fas.harvard.edu> <5AC4E10B-A3D0-4438-8F69-F7F282D3843B@vidyo.com> In-Reply-To: <5AC4E10B-A3D0-4438-8F69-F7F282D3843B@vidyo.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6B7A58D6D542A520C5D890BD" Cc: "codec@ietf.org" , "payload@ietf.org" Subject: Re: [payload] Frames to Packets in draft-ietf-codec-opus-07? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bens@alum.mit.edu 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, 27 Jul 2011 19:21:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B7A58D6D542A520C5D890BD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/27/2011 03:10 PM, Jonathan Lennox wrote: > Based on my reading of the Opus spec, it looks like splitting should be= possible, relatively trivially. Aggregation, however, is only possible = if the packets to be aggregated have the same value for the Opus TOC byte= =2E That is a correct reading of the Opus spec as of Opus-02 and later. Prio= r to Opus-02, the spec also described a packet mode that could contain frames of different types, allowing arbitrary aggregation. I believe it was removed because the authors expected that it would be rarely used, an= d removing it allowed them to improve the efficiency of more common cases. --Ben --------------enig6B7A58D6D542A520C5D890BD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4wZR4ACgkQUJT6e6HFtqRGjQCeLkUCztmSz9Mk5PAlOSnIHQG9 pSUAmwRq2RBsdI+ZU+v33E++bwbPi4QY =/uzT -----END PGP SIGNATURE----- --------------enig6B7A58D6D542A520C5D890BD-- From HKaplan@acmepacket.com Wed Jul 27 12:53:01 2011 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 90D8711E8120 for ; Wed, 27 Jul 2011 12:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XHsfDhOETQM for ; Wed, 27 Jul 2011 12:53:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6483911E813F for ; Wed, 27 Jul 2011 12:53:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Jul 2011 15:52:56 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 15:52:56 -0400 From: Hadriel Kaplan To: "Michael Ramalho (mramalho)" Date: Wed, 27 Jul 2011 15:52:54 -0400 Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT Thread-Index: AcxMlsb5uEnb5ioIRXSGynMapV7m8A== Message-ID: References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <4E2F0103.7020108@digium.com> <999109E6BC528947A871CDEB5EB908A0044E30DA@XMB-RCD-209.cisco.com> <999109E6BC528947A871CDEB5EB908A0044E3439@XMB-RCD-209.cisco.com> In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E3439@XMB-RCD-209.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "payload@ietf.org" Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT 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, 27 Jul 2011 19:53:01 -0000 On Jul 27, 2011, at 2:36 PM, Michael Ramalho (mramalho) wrote: > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 >=20 > It doesn't matter whether a particular codec or payload transform is > lossless or not, from the perspective of SDP and RTP. SRTP > encrypt/decrypt and authentication is also completely "lossless". You > could, in theory, do SRTP between two middleboxes. >=20 > MAR: Not even in theory .. but also in practice! Yes, exactly - they do it in *practice*, but SBCs don't do it by "not telli= ng the endpoints" or hiding stuff, because the SBCs *are* the endpoints fro= m the perspective of SDP and IP/UDP/RTP. The "real" endpoints (namely your= phones) don't know SRTP happened in the middle, and they don't know transc= oding G.711<->G.729 happened either, etc., but the phones not the real endp= oints from the perspective of IP, UDP, RTP, nor SDP - only from a human per= spective. -hadriel From Even.roni@huawei.com Thu Jul 28 15:49:03 2011 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 190B311E80B5 for ; Thu, 28 Jul 2011 15:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqZqrsdzNQp7 for ; Thu, 28 Jul 2011 15:49:02 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D585611E80A1 for ; Thu, 28 Jul 2011 15:49:01 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200DV1FDPNJ@szxga04-in.huawei.com> for payload@ietf.org; Fri, 29 Jul 2011 06:49:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200MLCFDPSM@szxga04-in.huawei.com> for payload@ietf.org; Fri, 29 Jul 2011 06:49:01 +0800 (CST) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP2001EUFDL8H@szxml12-in.huawei.com>; Fri, 29 Jul 2011 06:49:00 +0800 (CST) Date: Fri, 29 Jul 2011 01:46:15 +0300 From: Roni Even To: payload@ietf.org Message-id: <019401cc4d78$2b46b450$81d41cf0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_V3nUg3xYFU8YZbFiQtwBGQ)" Content-language: en-us Thread-index: AcxNeCa9zoBAGke+Q0CF78Lx4vR/0w== Subject: [payload] adding a new milestone to the charter 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, 28 Jul 2011 22:49:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_V3nUg3xYFU8YZbFiQtwBGQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, As was stated in the payload WG status presentation the WG chairs intend to ask for a new milestone to the charter Submit RTP Payload Format for IETF OPUS codec for Proposed Standard. If there are no objection we will also accept draft-spittka-payload-rtp-opus as the initial document to address this new work item Thanks Roni Even --Boundary_(ID_V3nUg3xYFU8YZbFiQtwBGQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

As was =
stated in the payload WG status presentation the WG chairs intend to ask =
for  a new milestone to the charter Submit RTP Payload Format for =
IETF OPUS codec for Proposed Standard. =

 =

If there =
are no objection we will also accept draft-spittka-payload-rtp-opus as =
the initial document to address this new work =
item
 =

Thanks=

Roni =
Even

 

 

= --Boundary_(ID_V3nUg3xYFU8YZbFiQtwBGQ)-- From prvs=1839367b2=tterribe@xiph.org Thu Jul 28 16:53:26 2011 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 CA73D11E8104; Thu, 28 Jul 2011 16:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxeVFJmkM--z; Thu, 28 Jul 2011 16:53:25 -0700 (PDT) Received: from mxip2i.isis.unc.edu (mxip2i.isis.unc.edu [152.2.2.193]) by ietfa.amsl.com (Postfix) with ESMTP id 54AC311E809C; Thu, 28 Jul 2011 16:53:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAMj1MU6sGgRa/2dsb2JhbAA1AQEEAT5GBgwMISIPCQMCAQIBAlEIDQ8CqEyIfMJ2hkEEh1qLIIR3D4t9 X-IronPort-AV: E=Sophos;i="4.65,614,1304308800"; d="scan'208";a="129454708" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip2o.isis.unc.edu with ESMTP; 28 Jul 2011 19:53:23 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 130.129.18.147 Received: from [130.129.18.147] (dhcp-1293.meeting.ietf.org [130.129.18.147]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p6SNrMKh022724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jul 2011 19:53:23 -0400 (EDT) Message-ID: <4E31F672.1070208@xiph.org> Date: Thu, 28 Jul 2011 16:53:22 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 To: codec@ietf.org, payload@ietf.org References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> <3343CB02-8D8B-4723-A8D2-ED3E65FF68A8@matthew.at> In-Reply-To: <3343CB02-8D8B-4723-A8D2-ED3E65FF68A8@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] [codec] Frames to Packets in draft-ietf-codec-opus-07? 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, 28 Jul 2011 23:53:26 -0000 > Would it be possible to add an appendix or create an additional document > that describes how a middlebox could detect mode changes and avoid > concatenating in these cases? This is basically as simple as examining the first byte of the packet. But if you have some example text I'd be happy to make an appendix for it (and possibly other related issues). From giles@thaumas.net Tue Jul 26 11:01:50 2011 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 CE37911E8135; Tue, 26 Jul 2011 11:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhMcz4qiBspi; Tue, 26 Jul 2011 11:01:50 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C14711E8132; Tue, 26 Jul 2011 11:01:50 -0700 (PDT) Received: by vws12 with SMTP id 12so646389vws.31 for ; Tue, 26 Jul 2011 11:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.105.136 with SMTP id t8mr1639225vco.128.1311703309600; Tue, 26 Jul 2011 11:01:49 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Tue, 26 Jul 2011 11:01:49 -0700 (PDT) X-Originating-IP: [66.119.183.150] In-Reply-To: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> Date: Tue, 26 Jul 2011 11:01:49 -0700 Message-ID: From: Ralph Giles To: Christian Hoene Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 29 Jul 2011 05:29:41 -0700 Cc: codec@ietf.org, payload@ietf.org Subject: Re: [payload] [codec] Frames to Packets in draft-ietf-codec-opus-07? 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, 26 Jul 2011 18:01:50 -0000 2011/7/25 Christian Hoene : > I was wondering why the draft-ietf-codec-opus-07 draft has feature to > concatenate multiple codec frames to packets. At the same time, > draft-spittka-payload-rtp-opus-00 does not support to place multiple codec > entities in on RTP packet. I believe the codec authors have described some of their reasoning for the internal framing. However, it sounds like your concern is the presence of framing at the codec level, rather than at the RTP payload level. There is precedent for this in previous specifications. http://tools.ietf.org/html/rfc3551#section-4.4 "Guidelines for Frame-Based Audio Encodings" says: "Frame-based encodings encode a fixed-length block of audio into another block of compressed data, typically also of fixed length. For frame-based encodings, the sender MAY choose to combine several such frames into a single RTP packet. The receiver can tell the number of frames contained in an RTP packet, if all the frames have the same length, by dividing the RTP payload length by the audio frame size which is defined as part of the encoding. This does not work when carrying frames of different sizes unless the frame sizes are relatively prime. If not, the frames MUST indicate their size. [...] All frame-oriented audio codecs SHOULD be able to encode and decode several consecutive frames within a single packet. [...]" Opus can use variable length encoded frames, so the clause that _frames_ must indicate their size, so that the codec can "decode several consecutive frames within a single packet" applies. The referent here is frames and codecs, not the payload format, so I don't think we're breaking new ground here by having some framing at the codec level. I would also point out that the opus codec draft is nearly finished. Continuing to specify framing there, rather than adding complication to the newer RTP draft, is the quicker path to standardization of both levels. FWIW, -r From matthew@matthew.at Thu Jul 28 16:39:26 2011 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 17ABE11E80A2; Thu, 28 Jul 2011 16:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4nqNqxHd3S2; Thu, 28 Jul 2011 16:39:25 -0700 (PDT) Received: from eeph.com (eeph.com [192.135.198.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEAF11E808B; Thu, 28 Jul 2011 16:39:19 -0700 (PDT) Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by eeph.com (Postfix) with ESMTP id 6A5B7C98023; Thu, 28 Jul 2011 16:39:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matthew Kaufman In-Reply-To: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> Date: Thu, 28 Jul 2011 19:39:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3343CB02-8D8B-4723-A8D2-ED3E65FF68A8@matthew.at> References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> To: Christian Hoene X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Fri, 29 Jul 2011 05:29:41 -0700 Cc: codec@ietf.org, payload@ietf.org Subject: Re: [payload] [codec] Frames to Packets in draft-ietf-codec-opus-07? 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, 28 Jul 2011 23:39:26 -0000 In response to comments at the mic at today's meeting: Would it be possible to add an appendix or create an additional document = that describes how a middlebox could detect mode changes and avoid = concatenating in these cases? Matthew Kaufman From jmvalin@jmvalin.ca Sun Jul 31 18:27:15 2011 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 2F0AF5E8005; Sun, 31 Jul 2011 18:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp+SWPPEQ87t; Sun, 31 Jul 2011 18:27:14 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfa.amsl.com (Postfix) with ESMTP id A283E5E8003; Sun, 31 Jul 2011 18:27:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.14] ([184.160.206.46]) by vl-mr-mrz22.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LP800CZ76P47J50@vl-mr-mrz22.ip.videotron.ca>; Sun, 31 Jul 2011 21:27:05 -0400 (EDT) Message-id: <4E3600D7.1040603@jmvalin.ca> Date: Sun, 31 Jul 2011 21:26:47 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 To: Jonathan Lennox References: <00ec01cc4ad6$8125b2d0$83711870$@uni-tuebingen.de> <4E2DAE67.6090008@fas.harvard.edu> <5AC4E10B-A3D0-4438-8F69-F7F282D3843B@vidyo.com> In-reply-to: <5AC4E10B-A3D0-4438-8F69-F7F282D3843B@vidyo.com> X-Enigmail-Version: 1.2 X-Mailman-Approved-At: Sun, 31 Jul 2011 19:44:33 -0700 Cc: "codec@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [codec] Frames to Packets in draft-ietf-codec-opus-07? 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 Aug 2011 01:27:15 -0000 Hi Jonathan, (sorry, just received your post now) On 11-07-27 03:10 PM, Jonathan Lennox wrote: > Based on my reading of the Opus spec, it looks like splitting should > be possible, relatively trivially. Aggregation, however, is only > possible if the packets to be aggregated have the same value for the > Opus TOC byte. Correct. > I get the impression that the TOC byte is expected to change only > relatively infrequently in most encoding modes, in which case this > would be fine -- there may be transient packets which couldn't be > aggregated, resulting in occasional "short" packets, but most packets > could be aggregated. However, if an encoder might change its TOC > frequently, this could be more problematic. I don't really see the TOC byte changing frequently. I would expect that for many/most uses, the TOC would never change during an RTP session. For other uses, I'd be surprised to see it changed more than once every 5-10 minutes. The only potentially problematic case (when it comes to aggregation) would be contents that has music and speech that alternates frequently. > If the (Payload) WG is okay with this limitation (and the limitation > of a maximum of 120 ms packets), I think the internal-framing-only is > okay; if not, we might need external framing as well. (I appreciate > that you don't want to change the Opus bitstream proper, at this > point.) I don't see these limitations as being a problem, but if they really are (in practice, not in some theoretical scenario), then I'd rather change this in the bit-stream than have RTP implementations mess it up on a regular basis (and having non-RTP implementations do it differently). Cheers, Jean-Marc