From mailman-bounces@ietf.org Fri Oct 1 09:20:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27624 for ; Fri, 1 Oct 2004 09:20:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNSs-00075d-2d for avt-archive@ietf.org; Fri, 01 Oct 2004 09:28:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDK4Q-0002Ta-Or for avt-archive@ietf.org; Fri, 01 Oct 2004 05:51:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: avt-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:19:53 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for avt-archive@ietf.org: List Password // URL ---- -------- avt@ietf.org afvueh https://www1.ietf.org/mailman/options/avt/avt-archive%40ietf.org From avt-bounces@ietf.org Fri Oct 1 16:23:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13091 for ; Fri, 1 Oct 2004 16:23:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDU56-0003sM-0u for avt-archive@ietf.org; Fri, 01 Oct 2004 16:32:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTlc-00066t-E1; Fri, 01 Oct 2004 16:12:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTPo-0001nr-Nq; Fri, 01 Oct 2004 15:50:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11010; Fri, 1 Oct 2004 15:50:03 -0400 (EDT) Message-Id: <200410011950.PAA11010@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 01 Oct 2004 15:50:03 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vmr-wb-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol (RTP) Payload and File Storage Formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec Author(s) : S. Ahmadi Filename : draft-ietf-avt-rtp-vmr-wb-04.txt Pages : 33 Date : 2004-10-1 This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of VMR-WB speech data in storage mode applications such as email. A MIME type registration is included, for VMR-WB, specifying use of both the RTP payload and the storage formats VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this draft to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vmr-wb-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-vmr-wb-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-vmr-wb-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-1153454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-vmr-wb-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-vmr-wb-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-1153454.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 1 16:43:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14682 for ; Fri, 1 Oct 2004 16:43:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDUNw-0005OO-DE for avt-archive@ietf.org; Fri, 01 Oct 2004 16:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTlk-0006G3-Jd; Fri, 01 Oct 2004 16:12:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTPv-0001so-IO; Fri, 01 Oct 2004 15:50:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11017; Fri, 1 Oct 2004 15:50:10 -0400 (EDT) Message-Id: <200410011950.PAA11017@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 01 Oct 2004 15:50:09 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-amrwbplus-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol (RTP) Payload Format for Extended AMR Wideband (AMR-WB+) Audio Codec Author(s) : J. Sjoberg, et al. Filename : draft-ietf-avt-rtp-amrwbplus-02.txt Pages : 31 Date : 2004-10-1 This document specifies a real-time transport protocol (RTP) payload format to be used for Extended AMR Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB codec providing additional modes designed to give higher quality of music and speech than the original modes. A MIME type registration is included for AMR-WB+. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amrwbplus-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-amrwbplus-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-amrwbplus-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-1153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amrwbplus-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amrwbplus-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-1153513.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Sat Oct 2 04:26:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03508 for ; Sat, 2 Oct 2004 04:26:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDfMT-0004WK-Io for avt-archive@ietf.org; Sat, 02 Oct 2004 04:35:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDf10-00030L-RI; Sat, 02 Oct 2004 04:13:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDObE-0007hQ-NW for avt@megatron.ietf.org; Fri, 01 Oct 2004 10:41:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05819 for ; Fri, 1 Oct 2004 10:41:30 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOjh-0000CA-Li for avt@ietf.org; Fri, 01 Oct 2004 10:50:18 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91EfUfM014887 for ; Fri, 1 Oct 2004 16:41:30 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 16:41:30 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 16:41:28 +0200 Message-ID: <299151A395F20F4BA29A6CC22C1F3A6F011C08E7@esealmw111> From: =?iso-8859-1?Q?Per_Fr=F6jdh_=28KI/EAB=29?= To: "'mankin@psg.com'" , "'randy@qualcomm.com'" , "'avt@ietf.org'" , 3GPP_TSG_SA_WG4@LIST.ETSI.ORG Date: Fri, 1 Oct 2004 16:41:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 Oct 2004 14:41:30.0204 (UTC) FILETIME=[BD2629C0:01C4A7C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 02 Oct 2004 04:13:12 -0400 Cc: "Magnus Westerlund \(KI/EAB\)" , "'hgarudad@QUALCOMM.COM'" , "'Dave Singer'" Subject: [AVT] Comments on the codecs parameter for bucket media types (file for mats) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Dear all, We at Ericsson have reviewed the Internet Draft =B4The Codecs Parameter = for "Bucket" Media Types=B4 http://www.ietf.org/internet-drafts/draft-gellens-mime-bucket-00.txt and identified some issues. The ID addresses the need to specify codecs contained in a "bucket" = file by adding a parameter to its MIME type (which by itself gives no = details on which codecs the file contains). However, the information = conveyed in the proposed codec parameter is currently limited and gives = the (false) impression that it would provide a client enough details to = decide whether it can render the content of the corresponding file. Our major concerns are the following: 1) Scope of the ID The ID states generally that it targets bucket media types, but the = design is only explicit for file formats that are based on the ISO Base = Media File Format (including the MP4, 3GP and 3G2 file formats). The = values of the codec parameters only mention such code points (as = registered by the MP4 registration authority) and it is not clear how = this would apply to any other file formats or bucket media types. One option to resolve the issue would be to explicitly state that the = ID is only intended for file formats in the "ISO family". However, some = work would still be needed to serve this purpose (see below).=20 A better alternative would be to address bucket media types in general, = but then remove ISO specific details and make a general framework that = can be used for all files (bucket media types). Such a framework could = specify the general syntax of the codecs parameter. Each media type = that would use the parameter would then define the semantics (list = entries) that are applicable to that particular media type.=20 2) Incomplete differentiation of codecs The codecs parameter takes MP4 code points (sample entry character = codes) as its main values to identify codecs. The main problem with = this is that it does not provide a sufficent description of the codec: =20 a) For codecs that use the MP4 file format entries (mp4v and mp4a) the = proposal includes an MPEG-4 systems object type indication to further = specify the codec. However, it is still not clear how to distinguish = AAC-LC from AAC-LTP (both used by 3GPP) as this information is carried = by the Audio object type in the decoder specific information (and not = by the MPEG-4 systems object type). Similar problems may arise for = ACCplus or Enhanced AACplus(?).=20 b) For codecs that are not signalled using MPEG-4 systems object type = there are also problems. 3GPP uses both H.263 Profile 0 (Baseline) and = H.263 Profile 3, but these codecs cannot be distinguished by the MP4 = code point (s263). A quick solution may be to define extended list = entries, e.g., s263.P0 and s263.P3, but considerable care must then be = taken to cover all cases and codecs that may be interesting. Keeping = track of such entries would also be outside the scope of the MP4 = registration authority. Instead of using the MP4 code points (and define extensions that would = cover the information not carried by them) it would be straightforward = to define the relevant entries for a given bucket media type. The owner = of the media type would then naturally serve as the "registration = authority" for its entries. 3GPP can keep a list of the relevant = entries for 3GP files and 3GPP2 one for 3G2 files. Also profiles and = levels can be included in the list of such entries. 3) Codecs information not enough One "risk" of introducing the codecs parameter is that it may be = perceived as the only description of the file. The ID states that it = "adds a parameter to allow unambiguous specification of the codecs = required to render the content in a media element". However, even if = the codec information is made more detailed, it is still possible that = some codecs may be required whereas some may be optionally used. This = and other aspects of a file in the ISO family is currently carried by = the file type box of a file. By only singling out codecs, we don't = think you get an adequate descripton of the file. The file type box of an ISO file includes a major brand ("best use") = and compatible brands. It may tell you that a file is "best" played by = a 3GPP release-5 terminal, although it is compatible with release-4 = terminals. This may be the case if the content creator included timed = text (introduced in release 5), but does not require terminals to = display the text. Hence, if a file contains a codec, it's not always = required that the receiving terminal supports it. If the codecs parameter is introduced, in one form or another, it = should be made clear that it only gives partial information of the = requirements of an end device. One option to make the description more = complete for an ISO file would be to "lift" the file type information = into a second MIME parameter for brand and compatible brands, although = this would imply some level of redundancy. In summary, a) the details specified for files in the ISO family (MP4, 3GP, 3G2, = etc) are not enough for differentiating codecs; b) we propose to have a general syntax for the bucket parameter defined = in IETF, but keep the details to each organisation defining a file = format that would use this parameter. Best regards, Per Fr=F6jdh, editor of the 3GPP file format (3GPP TS 26.244) ---------------------------------------------------------------- Per Fr=F6jdh, Ph.D. Tel +46 8 4048188 Ericsson Research, Multimedia Technologies Mob +46 730312413 =20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:08:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22723 for ; Mon, 4 Oct 2004 00:08:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKDE-0007Dm-1R for avt-archive@ietf.org; Mon, 04 Oct 2004 00:12:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJt2-0001Up-VO; Sun, 03 Oct 2004 23:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJmZ-0006Kt-Sf for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15439 for ; Sun, 3 Oct 2004 23:44:59 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEEWW-0003t0-3r for avt@ietf.org; Sun, 03 Oct 2004 18:08:08 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60683 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CEEMn-0002Jd-SI; Sun, 03 Oct 2004 22:58:06 +0100 In-Reply-To: <01LFLB1HN9SU00005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt Date: Sun, 3 Oct 2004 22:58:02 +0100 To: ned.freed@mrochek.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: IETF MIME Types Review List , John C Klensin , IETF AVT WG , Allison Mankin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit On 3 Oct 2004, at 18:22, ned.freed@mrochek.com wrote: >> On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: >> >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: >> ... >> >> > This admits the possibility of two conformant pieces of software >> >> > failing to interoperate, and that's not good. >> >> > >> >> >> > Now, nothing says you cannot use a naming convention of some >> sort >> >> >> to link the >> >> >> > two types in some way. But IMO they really need to be two >> >> different >> >> >> types. >> >> > >> >> >> In which case we have two different and separate namespaces, >> >> trying to >> >> >> share the same registry. This, IMHO, doesn't make sense. >> >> > >> >> > No, what we have is a single registry for specific formats and a >> >> way to >> >> > link formats that are in some way related. >> > >> >> But that link is the media type name, with the domain of >> applicability >> >> to prevent interoperability problems. This is done in RFCs 3267 and >> >> 3558, for example, and doesn't appear to have caused problems. >> > >> > Two examples where problems haven't yet arisen in a specific domain >> > doesn't mean much. There are hundreds of media types and who knows >> how >> > many domains of applicability, and the rules have to work for all of >> > them. > >> You seem to be arguing that the media types namespace cannot be shared >> between different domains of applicability unless those domains have >> the exact same framing and parameters. > > Nope. I'm arguing that a media type name needs to uniquely identify a > specific cononical format. Various encoding details, including some > aspects of framing, can of course be domain-specific. It is also > possible for an entire media type to have a single domain of > applicability, but in such cases it is still wrong to use the same > name for something different in another domain. yes, of course. >> I don't see this as realistic, >> since the entire reasoning behind specifying domains of applicability >> for media types is to allow for different framing and parameters. > > I do not regard fundamental differences in what goes in the content > as a framing detail. Again, the metric needs to be based on > interoperability. > > Look, this discussion has become pointless. I find your proposal to > use the same media type name to identify different formats in > different domains to be completely unacceptable, so much so that I > will not be party to any draft that incorporates this concept. THAT IS NOT MY PROPOSAL! What I have been arguing for is to allow the framing and framing specific parameters to vary for different domains of applicability, yet have received nothing but push back on this. Go read RFC 3267; only the framing differs. > Additionally, I see zero support being offered for this notion from > anyone else. I therefore regard the matter as closed. > > Ned > > -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:08:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22898 for ; Mon, 4 Oct 2004 00:08:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEK9M-0006qn-Rh for avt-archive@ietf.org; Mon, 04 Oct 2004 00:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJst-0001Nq-IH; Sun, 03 Oct 2004 23:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJls-000636-PY for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:44:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14865 for ; Sun, 3 Oct 2004 23:44:16 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEFIl-0007dK-LP for avt@ietf.org; Sun, 03 Oct 2004 18:58:03 -0400 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LFJ37H15XC00005R@mauve.mrochek.com> for avt@ietf.org; Sun, 03 Oct 2004 15:48:38 -0700 (PDT) Date: Sun, 03 Oct 2004 15:40:58 -0700 (PDT) Subject: Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-reply-to: "Your message dated Sun, 03 Oct 2004 22:58:02 +0100" <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> To: "Colin Perkins" Message-id: <01LFLM83HHTG00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7BIT Cc: John C Klensin , IETF MIME Types Review List , ned.freed@mrochek.com, IETF AVT WG , Allison Mankin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7BIT > > > I don't see this as realistic, > > > since the entire reasoning behind specifying domains of applicability > > > for media types is to allow for different framing and parameters. > > I do not regard fundamental differences in what goes in the content > > as a framing detail. Again, the metric needs to be based on > > interoperability. > > Look, this discussion has become pointless. I find your proposal to > > use the same media type name to identify different formats in > > different domains to be completely unacceptable, so much so that I > > will not be party to any draft that incorporates this concept. > THAT IS NOT MY PROPOSAL! On the contrary, that's exactly your proposal. Quoting your own original message on this thread: I'm a little concerned about the strength of this rule. I agree when the parameter space is separate, but I can certainly envisage cases when the parameter space and data format for two different domains have a very high degree of overlap, and where it makes sense for them to use the same media type. For example, there are several audio codecs where the RTP payload format can be summarised as "put frames into RTP packets in order" and the file format is "put frames into the file in order, following an initial magic number". In both cases there are common parameters: sampling rate, frame duration, and number of channels. However the RTP payload format needs an additional parameter: maximum frame duration (RTP packets have a size limit due to the path MTU, but the file format supports any frame size). I'm not sure it makes sense to require these to use different media types, since they're clearly the same format applied to different domains, yet the above rule would seem to require it. I have stated repeatedly that I regard data with and without some sort of header as constituting different formats that require different media types. > What I have been arguing for is to allow the > framing and framing specific parameters to vary for different domains > of applicability, yet have received nothing but push back on this. Go > read RFC 3267; only the framing differs. File header/magic number != framing in my book. And this will be my last message on this topic. Ned _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:08:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23054 for ; Mon, 4 Oct 2004 00:08:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEK4M-0006kE-2E for avt-archive@ietf.org; Mon, 04 Oct 2004 00:03:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJsi-0001Gl-Hc; Sun, 03 Oct 2004 23:51:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJlD-0005dY-28 for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:43:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14305 for ; Sun, 3 Oct 2004 23:43:32 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEGK3-0001MK-2D for avt@ietf.org; Sun, 03 Oct 2004 20:03:23 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61563 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CEGAY-0005j7-Vk; Mon, 04 Oct 2004 00:53:35 +0100 In-Reply-To: <01LFLM83HHTG00005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt Date: Mon, 4 Oct 2004 00:53:31 +0100 To: ned.freed@mrochek.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: IETF MIME Types Review List , John C Klensin , IETF AVT WG , Allison Mankin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit On 3 Oct 2004, at 23:40, ned.freed@mrochek.com wrote: >> > > I don't see this as realistic, >> > > since the entire reasoning behind specifying domains of >> applicability >> > > for media types is to allow for different framing and parameters. > >> > I do not regard fundamental differences in what goes in the content >> > as a framing detail. Again, the metric needs to be based on >> > interoperability. > >> > Look, this discussion has become pointless. I find your proposal to >> > use the same media type name to identify different formats in >> > different domains to be completely unacceptable, so much so that I >> > will not be party to any draft that incorporates this concept. > >> THAT IS NOT MY PROPOSAL! > > On the contrary, that's exactly your proposal. Quoting your own > original > message on this thread: > > I'm a little concerned about the strength of this rule. I agree when > the parameter space is separate, but I can certainly envisage cases > when the parameter space and data format for two different domains > have a very high degree of overlap, and where it makes sense for them > to use the same media type. > > For example, there are several audio codecs where the RTP payload > format can be summarised as "put frames into RTP packets in order" and > the file format is "put frames into the file in order, following an > initial magic number". In both cases there are common parameters: > sampling rate, frame duration, and number of channels. However the RTP > payload format needs an additional parameter: maximum frame duration > (RTP packets have a size limit due to the path MTU, but the file > format supports any frame size). I'm not sure it makes sense to > require these to use different media types, since they're clearly the > same format applied to different domains, yet the above rule would > seem to require it. > > I have stated repeatedly that I regard data with and without some sort > of header as constituting different formats that require different > media types. And as I have repeatedly argued, this prevents use of the media type registry for different domains of applicability, since those domains will have different headers due to the framing. >> What I have been arguing for is to allow the >> framing and framing specific parameters to vary for different domains >> of applicability, yet have received nothing but push back on this. Go >> read RFC 3267; only the framing differs. > > File header/magic number != framing in my book. So, what do you mean by framing? In the examples I'm quoting, the media data format is bitwise identical in both cases. The difference is that it's framed in a file (and hence has a file header) rather than a series of RTP packets (and hence has an RTP header); once you strip the framing there is no difference in format. > And this will be my last message on this topic. Which doesn't resolve the conflict between draft-freed-media-types-reg -01.txt and existing practice. Much as you may dislike it, there are two proposed standards (RFC 3267 and 3558) which register formats in the way I describe. The change you propose is problematic for a significant user community, which has previously registered these types in good faith, according to IETF procedures. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:32:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01932 for ; Mon, 4 Oct 2004 00:32:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKS8-00061q-RI for avt-archive@ietf.org; Mon, 04 Oct 2004 00:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEK5S-0007Cj-6o; Mon, 04 Oct 2004 00:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJtM-0001tU-J4 for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:52:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20767 for ; Sun, 3 Oct 2004 23:52:00 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE7eb-00039I-SJ for avt@ietf.org; Sun, 03 Oct 2004 10:48:02 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62941 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE7Ux-0000e3-5W; Sun, 03 Oct 2004 15:38:03 +0100 In-Reply-To: <4154102D.6040804@motorola.com> References: <0B08EA1BF5F6304992CDC985EE02209E02342B61@sdebe002.americas.nokia.com> <751B9B52-03EA-11D9-A048-000A957FC5F2@csperkins.org> <366D9364-0D38-11D9-A100-000A957FC5F2@csperkins.org> <4154102D.6040804@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] RE: : sampling rate Date: Sun, 3 Oct 2004 15:37:59 +0100 To: Qiaobing Xie X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Randell Jesup , magnus.westerlund@ericsson.com, avt@ietf.org, sassan.ahmadi@nokia.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Qiaobing, On 24 Sep 2004, at 13:16, Qiaobing Xie wrote: > Colin Perkins wrote: > > >>> Not that such things exist currently, but playing devil's advocate, >>> one could create a codec that takes a variable-sampling-rate input >>> depending on current conditions. (Similar to video codecs that vary >>> the >>> frame rate, resolution, and/or bitrate within a stream.) >> Sure, one could. I don't think it would be a good idea though: the >> convention that the sampling rate equals the timestamp rate is very >> helpful when building multi-format systems. > > The practical need in 3GPP2 (and possibly other systems) to feed mixed > sampling rate input (depending on conditions in the call flow) to > vmr-wb codec in a single session has already been explained in this > discussion. I think it is quite equivalent to the scenario depicted by > Randell. With respect, the only argument I've heard is that you want to save having to store both 8kHz and 16kHz sampled clips in a system. That is not a compelling reason to break the RTP timing model. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:35:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26553 for ; Mon, 4 Oct 2004 00:13:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKNC-0004FC-P7 for avt-archive@ietf.org; Mon, 04 Oct 2004 00:22:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJuC-0002vH-KM; Sun, 03 Oct 2004 23:52:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJri-0000Vo-2H for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19541 for ; Sun, 3 Oct 2004 23:50:19 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE96i-00016w-88 for avt@ietf.org; Sun, 03 Oct 2004 12:21:08 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60098 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE8x3-0003DC-4R; Sun, 03 Oct 2004 17:11:09 +0100 In-Reply-To: <01LFATFLKFG600005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt Date: Sun, 3 Oct 2004 16:41:59 +0100 To: ned.freed@mrochek.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: IETF MIME Types Review List , John C Klensin , IETF AVT WG , Allison Mankin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: ... >> > This admits the possibility of two conformant pieces of software >> > failing to interoperate, and that's not good. >> > >> >> > Now, nothing says you cannot use a naming convention of some sort >> >> to link the >> >> > two types in some way. But IMO they really need to be two >> different >> >> types. >> > >> >> In which case we have two different and separate namespaces, >> trying to >> >> share the same registry. This, IMHO, doesn't make sense. >> > >> > No, what we have is a single registry for specific formats and a >> way to >> > link formats that are in some way related. > >> But that link is the media type name, with the domain of applicability >> to prevent interoperability problems. This is done in RFCs 3267 and >> 3558, for example, and doesn't appear to have caused problems. > > Two examples where problems haven't yet arisen in a specific domain > doesn't mean much. There are hundreds of media types and who knows how > many domains of applicability, and the rules have to work for all of > them. You seem to be arguing that the media types namespace cannot be shared between different domains of applicability unless those domains have the exact same framing and parameters. I don't see this as realistic, since the entire reasoning behind specifying domains of applicability for media types is to allow for different framing and parameters. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:35:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26540 for ; Mon, 4 Oct 2004 00:13:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKNB-0004Ed-QN for avt-archive@ietf.org; Mon, 04 Oct 2004 00:22:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJto-0002SD-EI; Sun, 03 Oct 2004 23:52:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJqH-0008Bg-49 for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:48:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18423 for ; Sun, 3 Oct 2004 23:48:48 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEAJX-0007Fa-CT for avt@ietf.org; Sun, 03 Oct 2004 13:38:27 -0400 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LFJ37H15XC00005R@mauve.mrochek.com> for avt@ietf.org; Sun, 03 Oct 2004 10:28:45 -0700 (PDT) Date: Sun, 03 Oct 2004 10:22:19 -0700 (PDT) Subject: Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-reply-to: "Your message dated Sun, 03 Oct 2004 16:41:59 +0100" To: "Colin Perkins" Message-id: <01LFLB1HN9SU00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7BIT Cc: John C Klensin , IETF MIME Types Review List , ned.freed@mrochek.com, IETF AVT WG , Allison Mankin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7BIT > On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: > >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: > ... > >> > This admits the possibility of two conformant pieces of software > >> > failing to interoperate, and that's not good. > >> > > >> >> > Now, nothing says you cannot use a naming convention of some sort > >> >> to link the > >> >> > two types in some way. But IMO they really need to be two > >> different > >> >> types. > >> > > >> >> In which case we have two different and separate namespaces, > >> trying to > >> >> share the same registry. This, IMHO, doesn't make sense. > >> > > >> > No, what we have is a single registry for specific formats and a > >> way to > >> > link formats that are in some way related. > > > >> But that link is the media type name, with the domain of applicability > >> to prevent interoperability problems. This is done in RFCs 3267 and > >> 3558, for example, and doesn't appear to have caused problems. > > > > Two examples where problems haven't yet arisen in a specific domain > > doesn't mean much. There are hundreds of media types and who knows how > > many domains of applicability, and the rules have to work for all of > > them. > You seem to be arguing that the media types namespace cannot be shared > between different domains of applicability unless those domains have > the exact same framing and parameters. Nope. I'm arguing that a media type name needs to uniquely identify a specific cononical format. Various encoding details, including some aspects of framing, can of course be domain-specific. It is also possible for an entire media type to have a single domain of applicability, but in such cases it is still wrong to use the same name for something different in another domain. > I don't see this as realistic, > since the entire reasoning behind specifying domains of applicability > for media types is to allow for different framing and parameters. I do not regard fundamental differences in what goes in the content as a framing detail. Again, the metric needs to be based on interoperability. Look, this discussion has become pointless. I find your proposal to use the same media type name to identify different formats in different domains to be completely unacceptable, so much so that I will not be party to any draft that incorporates this concept. Additionally, I see zero support being offered for this notion from anyone else. I therefore regard the matter as closed. Ned _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:38:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03510 for ; Mon, 4 Oct 2004 00:38:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKlL-0007E1-03 for avt-archive@ietf.org; Mon, 04 Oct 2004 00:47:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKNt-00050a-0B; Mon, 04 Oct 2004 00:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKEG-0005Y2-KF for avt@megatron.ietf.org; Mon, 04 Oct 2004 00:13:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26583 for ; Mon, 4 Oct 2004 00:13:36 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE28z-00021q-HC for avt@ietf.org; Sun, 03 Oct 2004 04:55:01 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60204 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE1zY-0001M7-Lm; Sun, 03 Oct 2004 09:45:16 +0100 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <86966C42-1518-11D9-92C0-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Sun, 3 Oct 2004 09:45:06 +0100 To: avt@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund Subject: [AVT] Internet Draft deadlines for IETF 61 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit The deadlines for internet-draft submissions for the 61st IETF meeting in Washington DC are as follows: 11 October Pre-approval deadline for new working group drafts 18 October Submission deadline for new working group drafts 25 October Submission deadline for other drafts The deadline is at 9:00am US Eastern time on the date specified. Note the initial pre-approval deadline: if you are intending to submit a new working group draft (i.e. name of the form draft-ietf-avt-...-00.txt) you MUST contact the chairs to seek approval, in sufficient time that we can read the draft and send approval before 11th October. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 00:42:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26741 for ; Mon, 4 Oct 2004 00:13:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKNR-0004MX-St for avt-archive@ietf.org; Mon, 04 Oct 2004 00:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJuE-0002xp-W5; Sun, 03 Oct 2004 23:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJrj-0000Vw-6r for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:50:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19537 for ; Sun, 3 Oct 2004 23:50:19 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE96i-00016z-TC for avt@ietf.org; Sun, 03 Oct 2004 12:21:09 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60098 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE8x2-0003DC-BM; Sun, 03 Oct 2004 17:11:08 +0100 In-Reply-To: References: <0B08EA1BF5F6304992CDC985EE02209E02A74365@sdebe002.americas.nokia.com> <1225B53B-03EB-11D9-A048-000A957FC5F2@csperkins.org> <41433EE5.3030604@motorola.com> <4145B1B6.4090000@ericsson.com> <6654897A-0D36-11D9-A100-000A957FC5F2@csperkins.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5D35BB06-154F-11D9-B636-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] RE: : sampling rate Date: Sun, 3 Oct 2004 16:17:39 +0100 To: Randell Jesup X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund , sassan.ahmadi@nokia.com, avt@ietf.org, Qiaobing Xie X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit On 24 Sep 2004, at 20:15, Randell Jesup wrote: > Colin Perkins writes: >> On 13 Sep 2004, at 16:41, Magnus Westerlund wrote: >>> I think we have two issues: >>> >>> A. Is there any benefit to indicate or request that the sampling >>> frequency used at the sender. >> >> Yes. This is why RTP has the "rate" parameter, and uses the sampling >> rate as the RTP timestamp rate. > > My apologies, but I don't see how that answers the question as > to what the benefit is. How does the receiver make use of this > information? Why is this better for the receiver? If the codec can have different rates for source material and output material, it's clearly advantageous to signal that. More information is clearly better, as I hope is obvious. For RTP audio, the convention is to use the sampling rate at the input to drive the timestamp. The benefit is that it gives a consistent RTP timing model, with well defined semantics independent of the codec. This makes it simpler to design senders that operate with a range of codecs, and to design receivers that perform sample-accurate synchronisation (since the timestamp always increases by exactly 1 per audio sample in the input, meaning receivers can do synchronisation independent of the codec). > I can see some advantage in having the RTP rate parameter be > the > normal _output_ sample rate from the codec (which may be uncorrelated > to > the input rate!) in that you could use that to implement an audio codec > with non-fixed frame sizes. I agree that might be useful. However, it doesn't fit with the semantics assigned to the RTP timestamp. >>> B. Is it necessary to use the sampling frequency as RTP timestamp >>> rate. >> >> It's highly desirable. > > Again, asserting this without a reason doesn't convince me. To make a consistent definition of the RTP timestamp. >>> Colin, if one looks at issue B. Is it really needed to use the RTP >>> timestamp frequency equal to the sampling rate used? I would say NO >>> to >>> that question. >> >> Yes, it is necessary to use an RTP timestamp equal to the sampling >> rate. > > Again, no reasons given. Again, to avoid breaking standard RTP timing model. >>> My reasoning is the following. >>> >>> - Many audio input is sampled from a source at a higher rate then the >>> encoder may handle. Thus a resampling and pre-processing stage is >>> employed based on the encoders input frequency rather then producing >>> that >>> rate initially from the hardware. Some of the reason is that the >>> pre-processing may actually yield better results than what the >>> hardware >>> at given input rate can gain. Another reason may be that one like to >>> avoid switching the hardware between rate if changing the encoding. >>> >>> - The frame based decoders does not need to know the encoders input >>> rate. The encoder may anyway resample this into other rates for >>> internal >>> processing and band limited signals. I would claim that VMR-WB, >>> AMR-WB+ >>> and AAC are all example of codecs that perform this kind of tricks. >>> On >>> the receiver side they produce a output signal that has any sampling >>> frequency the receiver finds most useful. Either causing clipping of >>> the >>> higher frequencies, but more commonly to a higher clock rate, despite >>> that no more information is provided simply for ease of use. >>> >>> - The frame based codecs do only need a RTP timestamp that allows the >>> receiver to correctly reconstruct the time line when the encoding is >>> done >>> with the most audio bandwidth. In the VMR-WB case this is 16kHz. >>> AMR-WB+ >>> is even more strange, as we have selected an RTP timestamp rate that >>> results in that all internal sampling frequencies will result in >>> integer >>> timestamp ticks. Thus actually allowing one to correctly calculate >>> frame >>> alignment when the internal sampling frequency changes. That the >>> frequency also is possible to recalculate into several common >>> sampling >>> frequencies with few partial sample alignments was also considered. >>> >>> Thus I would use this to argue that indicating the actual sampling >>> frequency is not necessarily as long as the receiver is capable of >>> correctly reconstruct the media stream with its timing information in >>> full resolution. >> >> True, but it greatly simplifies the system if all codecs use the >> sampling rate as the RTP clock rate. You can make things work if each >> codec uses a different rate, but it's desirable that RTP is >> consistent where possible. Why is this codec so special that it needs >> to break this rule? > > Again, I simply don't see how things are simplified by having > the RTP timestamp rate be the sender-side sample rate. If the > timestamp rate is 2x or 4x the input rate, or if it's the lowest > common multiple (if you know what I mean) of a range of sample rates > the encoder might use, how does that hurt the receiver? See above. > In fact, if it _is_ possible for the encoder to use multiple rates > (like VMR-WB), isn't it a lot easier on both sides if we can just us > 16KHz for RTP and avoid having the play games if we want to switch > input rates dynamically? Setting the timestamp at the sender end is > trivial. > > Also, sticking with a strict timestamp rate == sample rate > dictate means that various classes of codecs won't fit well, will be > harder to write and/or use with RTP, or won't be developed because the > transports for them would be painful. I agree. This is a limitation of the way RTP has evolved, using the input sampling rate for the audio timestamp. Unfortunately changing the meaning of the RTP timestamp will break things, so we're stuck with the current model. > Or, perhaps worse for the participant of this group, such codecs will > push the use of alternative mechanisms such as IAX2 or other possible > alternatives. I could simplify my life CONSIDERABLY by ignoring RTP > and using a single multiplexed stream, with lower overhead due to > piggybacked nacks and acks, and much less hassle blowing multiple > holes through firewall/NATS. But for the sake of standards and > compatibility I've gone through the pain of getting dealing with all > the issues surrounding RTP, feedback, RTP-through-NATs, etc, and have > probably hewn (much) closer to the specs than most, I suspect. > > Don't put up roadblocks where there isn't a reason to. In this > case, there is a good argument _for this codec_ to use a fixed 16K > timestamp rate. However, doing so would fragment the consistent RTP timing model. I agree that using a 16kHz clock for this codec solves a short term implementation issue; however it makes RTP implementations that support multiple codec more complex in the long term, and fragments the standard. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 01:20:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01947 for ; Mon, 4 Oct 2004 00:32:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKRe-0005zD-TO for avt-archive@ietf.org; Mon, 04 Oct 2004 00:27:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEK5M-0007Bi-1n; Mon, 04 Oct 2004 00:04:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJtH-0001n1-O0 for avt@megatron.ietf.org; Sun, 03 Oct 2004 23:52:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20712 for ; Sun, 3 Oct 2004 23:51:55 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE7hg-0004w7-78 for avt@ietf.org; Sun, 03 Oct 2004 10:51:12 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62969 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE7Y1-0000ip-Vc; Sun, 03 Oct 2004 15:41:14 +0100 In-Reply-To: <41540C5C.6000307@ericsson.com> References: <0B08EA1BF5F6304992CDC985EE02209E02A74365@sdebe002.americas.nokia.com> <1225B53B-03EB-11D9-A048-000A957FC5F2@csperkins.org> <41433EE5.3030604@motorola.com> <4145B1B6.4090000@ericsson.com> <6654897A-0D36-11D9-A100-000A957FC5F2@csperkins.org> <41540AAA.7010102@motorola.com> <41540C5C.6000307@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <441BF4B4-154A-11D9-B636-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] RE: : sampling rate Date: Sun, 3 Oct 2004 15:41:09 +0100 To: Magnus Westerlund X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: sassan.ahmadi@nokia.com, avt@ietf.org, Qiaobing Xie X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On 24 Sep 2004, at 13:00, Magnus Westerlund wrote: > Qiaobing Xie wrote: >> I'd think that the saving (in terms of reduction to the system design >> and signaling complexity) by avoiding performing RTP timestamp rate >> switches (as Magnus pointed out above) far overweighs the ability of >> using the sampling rate to drive the media clock. > > Also, nothing in the case of VMR-WB prevents it from driving the media > clock. The larger issue is that VMR-WB has built in resampling > functions, and the fully information carrying sampling rate needed is > 16kHz, not 8. However resampling before the codec, or resampling in > the codec does not make any difference from the handling, only > somewhat in regards to quality, due to encoder optimization. This is why RTP uses the timestamp rate to indicate the sampling rate of the input, and why using a fixed 16kHz rate would be a mistake. > As the native out-put is 16kHz using a 8kHz RTP clock prevents a > receiver from driving its media clock with the appropriate rate. If a > receiver is using 8kHz output, then it easier to scale down the rate, > then to scale it up for the normal receiver behavior. > > Thus I see the least problem of driving the media clock when we only > uses a 16kHz clock, rather then a clock that reflects the encoders > front-end. If the codec needs another parameter to indicate the preferred output rate, I don't see that as a problem. However, the RTP timestamp rate should match the sampling rate of the input. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 05:56:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18616 for ; Mon, 4 Oct 2004 05:56:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPiy-0000iZ-LU for avt-archive@ietf.org; Mon, 04 Oct 2004 06:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPYR-0003WB-ME; Mon, 04 Oct 2004 05:54:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPLd-00029Y-Lx for avt@megatron.ietf.org; Mon, 04 Oct 2004 05:41:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17237 for ; Mon, 4 Oct 2004 05:41:34 -0400 (EDT) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPUg-0006U5-V6 for avt@ietf.org; Mon, 04 Oct 2004 05:50:59 -0400 Received: from [68.217.3.72] (port=1323 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CEPLc-0004FY-52; Mon, 04 Oct 2004 05:41:36 -0400 From: "Alan Clark" To: "Colin Perkins" , Subject: RE: [AVT] Internet Draft deadlines for IETF 61 Date: Mon, 4 Oct 2004 05:41:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <86966C42-1518-11D9-92C0-000A957FC5F2@csperkins.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Colin I haven't seen the rtcpxr-00 draft emerge from IETF as yet .. are there delays or is it possible it may be lost? Regards Alan -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of Colin Perkins Sent: Sunday, October 03, 2004 4:45 AM To: avt@ietf.org Cc: Magnus Westerlund Subject: [AVT] Internet Draft deadlines for IETF 61 The deadlines for internet-draft submissions for the 61st IETF meeting in Washington DC are as follows: 11 October Pre-approval deadline for new working group drafts 18 October Submission deadline for new working group drafts 25 October Submission deadline for other drafts The deadline is at 9:00am US Eastern time on the date specified. Note the initial pre-approval deadline: if you are intending to submit a new working group draft (i.e. name of the form draft-ietf-avt-...-00.txt) you MUST contact the chairs to seek approval, in sufficient time that we can read the draft and send approval before 11th October. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 07:04:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23539 for ; Mon, 4 Oct 2004 07:04:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQmj-00036i-6i for avt-archive@ietf.org; Mon, 04 Oct 2004 07:13:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQc5-0000vG-GH; Mon, 04 Oct 2004 07:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQQj-0007au-Ba for avt@megatron.ietf.org; Mon, 04 Oct 2004 06:50:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22409 for ; Mon, 4 Oct 2004 06:50:54 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQZn-0000lF-9m for avt@ietf.org; Mon, 04 Oct 2004 07:00:19 -0400 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:57962) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CEQQC-00081N-4E; Mon, 04 Oct 2004 11:50:24 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2F21DB26-15F3-11D9-B636-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Internet Draft deadlines for IETF 61 Date: Mon, 4 Oct 2004 11:50:19 +0100 To: "Alan Clark" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund , avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit I guess it's been lost. Can you resubmit? Colin On 4 Oct 2004, at 10:41, Alan Clark wrote: > Colin > > I haven't seen the rtcpxr-00 draft emerge from IETF as yet .. are there > delays or is it possible it may be lost? > > Regards > > Alan > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of > Colin Perkins > Sent: Sunday, October 03, 2004 4:45 AM > To: avt@ietf.org > Cc: Magnus Westerlund > Subject: [AVT] Internet Draft deadlines for IETF 61 > > > The deadlines for internet-draft submissions for the 61st IETF meeting > in Washington DC are as follows: > > 11 October Pre-approval deadline for new working group drafts > 18 October Submission deadline for new working group drafts > 25 October Submission deadline for other drafts > > The deadline is at 9:00am US Eastern time on the date specified. > > Note the initial pre-approval deadline: if you are intending to submit > a new working group draft (i.e. name of the form > draft-ietf-avt-...-00.txt) you MUST contact the chairs to seek > approval, in sufficient time that we can read the draft and send > approval before 11th October. > > -- > Colin Perkins > http://csperkins.org/ > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 14:17:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00282 for ; Mon, 4 Oct 2004 14:17:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXYG-0004hT-Ep for avt-archive@ietf.org; Mon, 04 Oct 2004 14:27:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXNP-0000dm-3i; Mon, 04 Oct 2004 14:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXGw-0007fZ-PO for avt@megatron.ietf.org; Mon, 04 Oct 2004 14:09:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29446 for ; Mon, 4 Oct 2004 14:09:17 -0400 (EDT) From: sassan.ahmadi@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXQ3-000317-Op for avt@ietf.org; Mon, 04 Oct 2004 14:18:45 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94I97a13446; Mon, 4 Oct 2004 21:09:07 +0300 (EET DST) X-Scanned: Mon, 4 Oct 2004 21:08:58 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i94I8wsh026430; Mon, 4 Oct 2004 21:08:58 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00aS8JKm; Mon, 04 Oct 2004 21:08:56 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94I8lS16787; Mon, 4 Oct 2004 21:08:47 +0300 (EET DST) Received: from sdebe002.NOE.Nokia.com ([172.19.201.138]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 13:08:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2004 11:08:38 -0700 Message-ID: <0B08EA1BF5F6304992CDC985EE02209E02A7437B@sdebe002.americas.nokia.com> Thread-Topic: [AVT] RE: : sampling rate Thread-Index: AcSpyYv3zQG44iCcSni7uLr/xYEriQAbbA2g X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 04 Oct 2004 18:08:44.0092 (UTC) FILETIME=[2F9027C0:01C4AA3D] X-Spam-Score: 1.6 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: [AVT] VMR-WB RTP Payload and Storage Formats X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Dear Colin, I am getting frustrated with the situation regarding the VMR-WB I-D. When this I-D was about to be accepted for the WGLC, a comment on the = relationship between the sampling rate and RTP clock rate has put this = I-D in an ambiguous status. In the one hand, based on the distinctive capability of VMR-WB, there = are people who want to use a fixed RTP clock rate of 16000 Hz to enable = processing/injection of the 8000 Hz sampled media. Note that 8000 and = 16000 Hz sampled media have identical VMR-WB output frames. I believe = there is technically nothing wrong and revision -04 of the I-D = appropriately addresses this concern. On the other hand, you persist on your opinion that RTP clock rate must = be identical to the input media sampling rate regardless of the codec = capabilities. The following excerpt from Section 4.1 of RFC 3551 (line 434) "... The RTP clock rate used for generating the RTP timestamp is independent of the number of channels and the encoding; it usually equals the number of sampling periods per second. For N-channel encodings, each sampling period (say, 1/8,000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.) ..." indicates that (there is no normative language here) the RTP clock rate = "usually" equals the input media sampling rate and that it is = independent of the encoding. Also the following excerpt from Section 6.4.4 of RFC 3550 (line 2391) "... Since that timestamp is independent of the clock rate for the data encoding, it is possible to implement encoding- and profile-independent quality monitors. ..." Therefore, you have no technical ground to assert that RTP clock rate = MUST be equal to input media sampling frequency. Please think of VMR-WB as a dual-rate system where both 8000 and 16000 = Hz sampled media are supported and that decoding can proceed without = knowing the input media sampling frequency. Please remember that initially I resisted this idea; however, after = considering all aspects of the requested change, I came to realize that = it is technically sound. I do want a resolution for this matter. This is definitely jeopardizing = and delaying the deployment of VMR-WB codec and its prospective = applications. Please do not expect that the other parties to back off = from their position. We must resolve this issue. Your understanding and consideration are appreciated in advance. Regards -Sassan Ahmadi _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 15:18:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05575 for ; Mon, 4 Oct 2004 15:18:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEYV8-0007fS-Mm for avt-archive@ietf.org; Mon, 04 Oct 2004 15:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEY9Z-0004nn-6S; Mon, 04 Oct 2004 15:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEY59-0000hI-Ud for avt@megatron.ietf.org; Mon, 04 Oct 2004 15:01:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03215 for ; Mon, 4 Oct 2004 15:01:09 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEYEH-00049I-MY for avt@ietf.org; Mon, 04 Oct 2004 15:10:38 -0400 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:59609) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CEY4c-0003Yi-PC; Mon, 04 Oct 2004 20:00:38 +0100 In-Reply-To: <0B08EA1BF5F6304992CDC985EE02209E02A7437B@sdebe002.americas.nokia.com> References: <0B08EA1BF5F6304992CDC985EE02209E02A7437B@sdebe002.americas.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Mon, 4 Oct 2004 20:00:33 +0100 To: X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: [AVT] Re: VMR-WB RTP Payload and Storage Formats X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Sassan, I am likewise getting frustrated with the situation. However, I don't believe the arguments in favour of making the VMR-WB payload format inconsistent with other speech payload formats are compelling. The codec is not particularly special in its behaviour, and the argument that one wishes to inject 8 kHz sampled tones rather than injecting tones at native rate (i.e. you wish to save a few bytes of storage in the tone generation box) does not justify the inconsistency. I regard a consistent and stable timing model across payload formats to be fundamental to the utility of RTP. You are trying to disrupt that for a trivial cost saving in a particular application. That is not an appropriate trade-off. Colin On 4 Oct 2004, at 19:08, wrote: > Dear Colin, > > I am getting frustrated with the situation regarding the VMR-WB I-D. > > When this I-D was about to be accepted for the WGLC, a comment on the > relationship between the sampling rate and RTP clock rate has put this > I-D in an ambiguous status. > > In the one hand, based on the distinctive capability of VMR-WB, there > are people who want to use a fixed RTP clock rate of 16000 Hz to > enable processing/injection of the 8000 Hz sampled media. Note that > 8000 and 16000 Hz sampled media have identical VMR-WB output frames. I > believe there is technically nothing wrong and revision -04 of the I-D > appropriately addresses this concern. > > On the other hand, you persist on your opinion that RTP clock rate > must be identical to the input media sampling rate regardless of the > codec capabilities. > > The following excerpt from Section 4.1 of RFC 3551 (line 434) > > "... > The RTP clock rate used for generating the RTP timestamp is > independent of the number of channels and the encoding; it usually > equals the number of sampling periods per second. For N-channel > encodings, each sampling period (say, 1/8,000 of a second) generates > N samples. (This terminology is standard, but somewhat confusing, > as > the total number of samples generated per second is then the > sampling > rate times the channel count.) > ..." > > indicates that (there is no normative language here) the RTP clock > rate "usually" equals the input media sampling rate and that it is > independent of the encoding. > > Also the following excerpt from Section 6.4.4 of RFC 3550 (line 2391) > > "... > Since that timestamp is > independent of the clock rate for the data encoding, it is possible > to implement encoding- and profile-independent quality monitors. > ..." > > Therefore, you have no technical ground to assert that RTP clock rate > MUST be equal to input media sampling frequency. > > Please think of VMR-WB as a dual-rate system where both 8000 and 16000 > Hz sampled media are supported and that decoding can proceed without > knowing the input media sampling frequency. > > Please remember that initially I resisted this idea; however, after > considering all aspects of the requested change, I came to realize > that it is technically sound. > > I do want a resolution for this matter. This is definitely > jeopardizing and delaying the deployment of VMR-WB codec and its > prospective applications. Please do not expect that the other parties > to back off from their position. We must resolve this issue. > > Your understanding and consideration are appreciated in advance. > > Regards > > -Sassan Ahmadi _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 4 15:56:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09635 for ; Mon, 4 Oct 2004 15:56:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEZ6D-0004mo-Ld for avt-archive@ietf.org; Mon, 04 Oct 2004 16:06:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYiw-0006K6-Op; Mon, 04 Oct 2004 15:42:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYdy-0003YX-JU for avt@megatron.ietf.org; Mon, 04 Oct 2004 15:37:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07590 for ; Mon, 4 Oct 2004 15:37:08 -0400 (EDT) Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=mail.tvol.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEYn4-0001oX-9x for avt@ietf.org; Mon, 04 Oct 2004 15:46:38 -0400 Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NPY70PKV; Mon, 4 Oct 2004 15:36:01 -0400 To: sassan.ahmadi@nokia.com Subject: Re: [AVT] VMR-WB RTP Payload and Storage Formats References: <0B08EA1BF5F6304992CDC985EE02209E02A7437B@sdebe002.americas.nokia.com> From: Randell Jesup Date: 04 Oct 2004 15:38:31 -0400 In-Reply-To: <0B08EA1BF5F6304992CDC985EE02209E02A7437B@sdebe002.americas.nokia.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: magnus.westerlund@ericsson.com, csp@csperkins.org, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 sassan.ahmadi@nokia.com writes: >In the one hand, based on the distinctive capability of VMR-WB, there are >people who want to use a fixed RTP clock rate of 16000 Hz to enable >processing/injection of the 8000 Hz sampled media. Note that 8000 and >16000 Hz sampled media have identical VMR-WB output frames. I believe >there is technically nothing wrong and revision -04 of the I-D >appropriately addresses this concern. This is a very relevant point - the decoder doesn't need to know the input sample rate, and certainly doesn't need to know it from the timestamp. >On the other hand, you persist on your opinion that RTP clock rate must be >identical to the input media sampling rate regardless of the codec >capabilities. > >The following excerpt from Section 4.1 of RFC 3551 (line 434) > >"... > The RTP clock rate used for generating the RTP timestamp is > independent of the number of channels and the encoding; it usually > equals the number of sampling periods per second. For N-channel > encodings, each sampling period (say, 1/8,000 of a second) generates > N samples. (This terminology is standard, but somewhat confusing, as > the total number of samples generated per second is then the sampling > rate times the channel count.) >..." > >indicates that (there is no normative language here) the RTP clock rate >"usually" equals the input media sampling rate and that it is independent >of the encoding. As Colin has indicated, this is the traditional usage. However, I (personally) see no reason for this other that tradition, and Colin's response to me didn't include any significant reason other than tradition (I'll respond to that shortly in detail). >Also the following excerpt from Section 6.4.4 of RFC 3550 (line 2391) > >"... > Since that timestamp is > independent of the clock rate for the data encoding, it is possible > to implement encoding- and profile-independent quality monitors. >..." > >Therefore, you have no technical ground to assert that RTP clock rate MUST >be equal to input media sampling frequency. In fact, in Colin's defense, I don't think Colin asserted it "MUST" be equal to the sampling frequency, but instead he asserted (very strongly) that it should be; that he saw no reason to break the tradition. I (and apparently others such as Sassan) do. >Please think of VMR-WB as a dual-rate system where both 8000 and 16000 Hz >sampled media are supported and that decoding can proceed without knowing >the input media sampling frequency. And, if you do need to know the sampling frequency to decode, it should either be part of the encoding or part of the SDP/etc that creates the stream - and not the timestamp frequency portion of the SDP. As I see it, there are two primary uses of the RTP timestamp and it's frequency: 1) Playback timing Knowing when a frame was sampled (the time the first sample of the frame was) is important for playback, especially if the codec can omit samples for some reason without otherwise indicating it. You can infer lost packets from sequence numbers as well, but there isn't a guaranteed sequence number -> time equation for many codecs. Note that the time of the first sample of the frame can be in any units of sufficient resolution. It's handy if it's an integer multiple of the actual sampling rate (1->N times), but even that might not be important given a high enough rate, and for certain non-audio codecs that's already the norm (video). 2) Stream synchronization Combined with RTCP with NTP times to synchronize streams. Again, the same issues are above for playback; in this case higher multiples of the sampling rate might have an advantage in some cases. For example, when trying to synchronize multiple audio streams for a mix for music, using a higher timestamp rate when possible may allow tighter synchronization and less chance of introducing phasing issues. If you're synchronizing an 250Hz-samples LFE stream to video at 60fps, or much worse to multi-channel audio at 44KHz, you don't want the timestamps in the LFE stream to be 250Hz - that might allow the LFE channel to be as much as 2ms out-of-phase with the channels carrying the higher frequencies. Now this might not matter a huge deal - but you certainly aren't _gaining_ anything by restricting the LFE timestamps to 250Hz. It may become worse when you're trying to merge multiple streams with 250Hz-samples audio coming from different sources; the phase issues may become quite apparent. It's like my old video character-generation example - even with a display that can handle at most 350 "lines" of analog video across, using a circa-1400 pixel source to generate the analog produces better output because you can control edge _positions_ more finely, even if you can't make a sharper edge transition or (same thing) go from one color/brightness to another any quicker. It's an easy thing to forget about when you're used to working in the digital domain. I thought I had a third, but I think it's covered by those. Note that for video, current codecs generally use a 90 KHz timestamp rate. This is definitely not the actual sample rate of most/any inputs. That's circa 3000 ticks per 30Hz video frame, way under even QCIF sample rates (if you're thinking video pixels). This 90Khz rate works for video because it has _enough_ accuracy for the purpose. Codec/etc writers have to assume there isn't a perfect 1:1 correlation of timestamp to time-of-first-sample. Given that RTP is not designed for easy switching of timestamp rates on a single stream, using a single fixed "high enough" timestamp rate for a codec with multiple input rates makes a ton of sense to me. It definitely simplifies intermediate pieces and simplifies receivers as well - given the apparent complexity of dealing with multiple on-the-fly timestamp rates. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 5 01:12:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03223 for ; Tue, 5 Oct 2004 01:12:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEhmN-0000O2-Mz for avt-archive@ietf.org; Tue, 05 Oct 2004 01:22:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEhXc-0005dj-En; Tue, 05 Oct 2004 01:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEhPN-00043o-8F for avt@megatron.ietf.org; Tue, 05 Oct 2004 00:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02496 for ; Tue, 5 Oct 2004 00:58:37 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEhYa-0006BM-LD for avt@ietf.org; Tue, 05 Oct 2004 01:08:13 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i954xBlY005286 for ; Mon, 4 Oct 2004 21:59:11 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i954wFot006939 for ; Mon, 4 Oct 2004 23:58:16 -0500 Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 23:58:31 -0500 Message-ID: From: Scribano Gino-QA1087 To: "'Colin Perkins'" Subject: RE: [AVT] Re: VMR-WB RTP Payload and Storage Formats Date: Mon, 4 Oct 2004 23:58:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: magnus.westerlund@ericsson.com, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Colin, It seems that the 'sampling rate' issue has now crossed over to the Storage Format thread. In any case, it's been a while since my initial comments regarding application impacts of restricting the RTP timestamp to be equivalent to the source media sampling rate. So, I would like to reiterate that the impact of this restriction extends well beyond saving a few bytes of storage in a tone generation box. As I stated previously, this restriction is also problematic for mixing and/or switching diverse media sources in streaming and conversational applications. Consider a conference bridging application, where at least one party is a land-line circuit (which requires 8 KHz sampling) and at least one other party is a wideband VMR-WB terminal (which may employ 16 KHz sampling). Conference bridging for these media streams requires switching and/or mixing the input streams into like output streams. According to your restricted method, use of the VMR-WB sample rate adaptation function for this application requires end-to-end session renegotiation (eg, an SDP offer-answer cycle for each leg) in order to achieve a common sampling rate, and hence timestamp interval, for all RTP terminations involved in the conference bridge. Additional latencies and synchronization complexities associated with end-to-end renegotiation of the sampling rate for all RTP terminations should not be required to establish and maintain the bridge in such applications. Regards, Gino -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Colin Perkins Sent: Monday, October 04, 2004 2:01 PM To: sassan.ahmadi@nokia.com Cc: magnus.westerlund@ericsson.com; avt@ietf.org Subject: [AVT] Re: VMR-WB RTP Payload and Storage Formats Sassan, I am likewise getting frustrated with the situation. However, I don't believe the arguments in favour of making the VMR-WB payload format inconsistent with other speech payload formats are compelling. The codec is not particularly special in its behaviour, and the argument that one wishes to inject 8 kHz sampled tones rather than injecting tones at native rate (i.e. you wish to save a few bytes of storage in the tone generation box) does not justify the inconsistency. I regard a consistent and stable timing model across payload formats to be fundamental to the utility of RTP. You are trying to disrupt that for a trivial cost saving in a particular application. That is not an appropriate trade-off. Colin On 4 Oct 2004, at 19:08, wrote: > Dear Colin, > > I am getting frustrated with the situation regarding the VMR-WB I-D. > > When this I-D was about to be accepted for the WGLC, a comment on the > relationship between the sampling rate and RTP clock rate has put this > I-D in an ambiguous status. > > In the one hand, based on the distinctive capability of VMR-WB, there > are people who want to use a fixed RTP clock rate of 16000 Hz to > enable processing/injection of the 8000 Hz sampled media. Note that > 8000 and 16000 Hz sampled media have identical VMR-WB output frames. I > believe there is technically nothing wrong and revision -04 of the I-D > appropriately addresses this concern. > > On the other hand, you persist on your opinion that RTP clock rate > must be identical to the input media sampling rate regardless of the > codec capabilities. > > The following excerpt from Section 4.1 of RFC 3551 (line 434) > > "... > The RTP clock rate used for generating the RTP timestamp is > independent of the number of channels and the encoding; it usually > equals the number of sampling periods per second. For N-channel > encodings, each sampling period (say, 1/8,000 of a second) generates > N samples. (This terminology is standard, but somewhat confusing, > as > the total number of samples generated per second is then the > sampling > rate times the channel count.) > ..." > > indicates that (there is no normative language here) the RTP clock > rate "usually" equals the input media sampling rate and that it is > independent of the encoding. > > Also the following excerpt from Section 6.4.4 of RFC 3550 (line 2391) > > "... > Since that timestamp is > independent of the clock rate for the data encoding, it is possible > to implement encoding- and profile-independent quality monitors. > ..." > > Therefore, you have no technical ground to assert that RTP clock rate > MUST be equal to input media sampling frequency. > > Please think of VMR-WB as a dual-rate system where both 8000 and 16000 > Hz sampled media are supported and that decoding can proceed without > knowing the input media sampling frequency. > > Please remember that initially I resisted this idea; however, after > considering all aspects of the requested change, I came to realize > that it is technically sound. > > I do want a resolution for this matter. This is definitely > jeopardizing and delaying the deployment of VMR-WB codec and its > prospective applications. Please do not expect that the other parties > to back off from their position. We must resolve this issue. > > Your understanding and consideration are appreciated in advance. > > Regards > > -Sassan Ahmadi _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 5 04:47:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03775 for ; Tue, 5 Oct 2004 04:47:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEl8Y-0003mE-IO for avt-archive@ietf.org; Tue, 05 Oct 2004 04:57:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEkww-0000gv-8N; Tue, 05 Oct 2004 04:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEkqn-0008Kf-E3 for avt@megatron.ietf.org; Tue, 05 Oct 2004 04:39:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03342 for ; Tue, 5 Oct 2004 04:39:11 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEkzz-0001XG-KI for avt@ietf.org; Tue, 05 Oct 2004 04:48:47 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60044 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CEkqB-0003VW-8v; Tue, 05 Oct 2004 09:38:35 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Re: VMR-WB RTP Payload and Storage Formats Date: Tue, 5 Oct 2004 09:38:30 +0100 To: Scribano Gino-QA1087 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: magnus.westerlund@ericsson.com, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Gino, Thanks - this is a much more compelling explanation of the problem. The issue with switching between sampling rates in an RTP session is a well known problem with the way audio payload formats have been defined in the RTP/AVP profile. If you want to work to solve that in the general case, I would support that work. However, introducing workarounds for specific codec - making it inconsistent with the others in the profile - doesn't seem like a good idea to me. On 5 Oct 2004, at 05:58, Scribano Gino-QA1087 wrote: > It seems that the 'sampling rate' issue has now crossed over to the > Storage Format thread. In any case, it's been a while since my initial > comments regarding application impacts of restricting the RTP > timestamp to be equivalent to the source media sampling rate. So, I > would like to reiterate that the impact of this restriction extends > well beyond saving a few bytes of storage in a tone generation box. As > I stated previously, this restriction is also problematic for mixing > and/or switching diverse media sources in streaming and conversational > applications. > > Consider a conference bridging application, where at least one party > is a land-line circuit (which requires 8 KHz sampling) and at least > one other party is a wideband VMR-WB terminal (which may employ 16 KHz > sampling). Conference bridging for these media streams requires > switching and/or mixing the input streams into like output streams. > According to your restricted method, use of the VMR-WB sample rate > adaptation function for this application requires end-to-end session > renegotiation (eg, an SDP offer-answer cycle for each leg) in order to > achieve a common sampling rate, and hence timestamp interval, for all > RTP terminations involved in the conference bridge. I would have thought the conference bridge could act as an RTP translator, and resample as appropriate for some participants? > Additional latencies and synchronization complexities associated with > end-to-end renegotiation of the sampling rate for all RTP terminations > should not be required to establish and maintain the bridge in such > applications. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 6 10:52:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03868 for ; Wed, 6 Oct 2004 10:52:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFDIl-0007uj-Bg for avt-archive@ietf.org; Wed, 06 Oct 2004 11:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFD28-0001XQ-Ns; Wed, 06 Oct 2004 10:44:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBOu-0001NP-KL for avt@megatron.ietf.org; Wed, 06 Oct 2004 09:00:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20960 for ; Wed, 6 Oct 2004 09:00:10 -0400 (EDT) Received: from mailgate.uni-paderborn.de ([131.234.22.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBYO-000098-Nk for avt@ietf.org; Wed, 06 Oct 2004 09:10:01 -0400 Received: from feuerdorn.cs.upb.de ([131.234.64.26]) by mailgate.uni-paderborn.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1CFBOm-00034s-Bs for avt@ietf.org; Wed, 06 Oct 2004 15:00:04 +0200 Received: from fhkarl by feuerdorn.cs.upb.de with local (Exim 4.34) id 1CFBOn-0005zV-Tw for avt@ietf.org; Wed, 06 Oct 2004 15:00:05 +0200 To: avt@ietf.org Message-Id: From: Holger Karl Date: Wed, 06 Oct 2004 15:00:05 +0200 X-UNI-PB_FAK-EIM-MailScanner-Information: Please see http://imap.uni-paderborn.de for details X-UNI-PB_FAK-EIM-MailScanner: Found to be clean X-UNI-PB_FAK-EIM-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.011, required 4, LINES_OF_YELLING 0.01) X-MailScanner-From: fhkarl@feuerdorn.cs.upb.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f X-Mailman-Approved-At: Wed, 06 Oct 2004 10:44:47 -0400 Subject: [AVT] Call for Papers: WiOpt '05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Dear Colleagues, Please note that the deadline for WiOpt'05 has been EXTENDED UNTIL October 10! The web site http://www.wiopt.org has full details. Our apologies for duplicate copies of this call. Best regards Holger Karl (on behalf of the Wiopt'05 organizers) ----------------------------------------------- The 3rd International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks (WiOpt'05) Riva del Garda, Trentino, Italy, April 3-7, 2005 http://www.wiopt.org SCOPE OF THE SYMPOSIUM ---------------------- The complexity of mobile, ad hoc, and wireless networks requires thoroughly founded models capturing their essential characteristics and new optimization techniques building upon such models. Insights into both the theoretical aspects of these problems as well as practical methods and tools are necessary. This symposium, building upon the two successful WiOpt workshops, intends to bring together researchers and practitioners working on optimization issues from different perspectives, including performance analysis, mobile networking, wireless communication, and optimization theory. Contributions to this conference should show new modeling and optimization techniques suitable for mobile/wireless networks or innovative applications of these techniques to improve network operation. Topics of interest include, but are not limited to: * Modeling techniques and tools for mobile/wireless networks * Performance characterisation & optimisation of mobile/wireless networks and systems * Mobile network optimisation: Applications, algorithms, and tools * Protocol design for optimal mobile network utilisation * Models and optimization approaches for energy efficiency, QoS, bandwidth economy and other aspects of mobile/wireless networks * Models and optimization techniques for non-standard network paradigms like sensor, vehicular, body area networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad-hoc networks Papers should be submitted as extended abstracts of up to 8 pages (see webpage for details). Selected papers from WiOpt 2005 will appear in a special issue of ACM/Kluwer Monet. ADJUNCT WORKSHOPS ----------------- Several one-day workshops will accompany the main WiOpt Symposium on April 3rd and 7th (see webpage for details): * WINMEE 2005: Measurement in Wireless Networks Chairs: L. Krishnamurthy (Intel), D. Papagiannaki (Intel Research Cambridge) * RAWNET 2005: Resource Allocation in Wireless Networks, Chairs: A. Proutiere (France Telecom R&D), S. Borst (Bell Labs.-CWI) * SPASWIN 2005: Stochastic Geometry for Wireless Networks, Chairs: F. Baccelli (INRIA-ENS), B. Blaszczyszyn (INRIA-ENS) * NETCOD 2005: Network Coding and Information Theory, Chairs: R. W. Yeung (The Chinese U. of Hong Kong), P. Chou (Microsoft Research) SPONSORHSIP ----------- WiOpt05 is sponsored by INRIA, Create-Net, ICST, eNext NoE, Intel, and Siemens mobile; it is technically co-sponsored by the IEEE Information Theory Society; it is organized in cooperation with ACM and IFIP WG 6.3. IMPORTANT DATES --------------- Submission deadline: Oct. 10, 2004 (midnight EST) Notification of acceptance: Dec. 5, 2004 Camera-ready copy: Jan. 5, 2005 Papers should be submitted in pdf or ps format through the EDAS system (http://edas.info). For more details, please visit http://www.wiopt.org General Chair ------------- E. Altman, INRIA Vice General Chair ------------------ H. Karl, U. of Paderbon Program Co-Chairs ----------------- R. R. Mazumdar, Purdue U. I. Stavrakakis, U. of Athens Steering Committee Chair ------------------------ I. Chlamtac, Create-Net Program Committee ----------------- E. Altman, INRIA V. Anantharam, UC Berkeley K. Avrachenkov, INRIA T. Basar, U. of Illinois A. Campbell, Columbia U. X. Cao, Hong Kong U. of Science and Technology A. Chockalingam, Indian Institute of Science M. Conti, CNR-ITT J. Crowcroft, U. of Cambridge P. Dube, IBM Research A. Ephremides, U. of Maryland S. Giordano, SUSPI A. Jukan, NSF CISE Networking Research H. Karl, U. of Paderborn P. Key, Microsoft Research J-W. Lee, Princeton U. R. Malhame, Ecole Poly-technique de Montreal P. Marbach, U. of Toronto D. Mcauley, Intel Research Cambridge A. Misra, IBM Research Q. Ni, National U. of Ireland Y. Onozato, Guma University A. Orda, Technion A. Panagakis, U. of Athens R. Rao, UC San Diego A. Richa, Arizona State U. P. Rodriguez, Microsoft Research C. Rosenberg, Purdue U. V. Syrotiuk, Aritona State U. T. Turletti, INRIA J. Wieselthier, Naval Research Laboratory M. Zukerman, U. of Melbourne Workshops Chair --------------- C. Barakat, INRIA Local Arrangements Chair ------------------------ G. Boata, U. of Trento Publicity Chair --------------- T. Turletti, INRIA Publications Chair ------------------ E. Deriche, INRIA _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 6 15:34:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26727 for ; Wed, 6 Oct 2004 15:34:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFHhq-0000To-OD for avt-archive@ietf.org; Wed, 06 Oct 2004 15:44:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHWt-0000L6-K2; Wed, 06 Oct 2004 15:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHW5-0008Mp-4q; Wed, 06 Oct 2004 15:32:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26495; Wed, 6 Oct 2004 15:31:58 -0400 (EDT) Message-Id: <200410061931.PAA26495@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 06 Oct 2004 15:31:58 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc3119bis-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : A More Loss-Tolerant RTP Payload Format for MP3 Audio Author(s) : R. Finlayson Filename : draft-ietf-avt-rfc3119bis-03.txt Pages : 0 Date : 2004-10-6 This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. (This document updates RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3119bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc3119bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc3119bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-6151735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc3119bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc3119bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-6151735.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Oct 6 17:17:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15838 for ; Wed, 6 Oct 2004 17:17:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFJJx-0002SL-L8 for avt-archive@ietf.org; Wed, 06 Oct 2004 17:27:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFItT-0006PN-5S; Wed, 06 Oct 2004 17:00:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFIYK-0002hD-Lg for avt@megatron.ietf.org; Wed, 06 Oct 2004 16:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08642 for ; Wed, 6 Oct 2004 16:38:22 -0400 (EDT) Received: from ns.live.com ([66.80.62.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFIht-00076A-GZ for avt@ietf.org; Wed, 06 Oct 2004 16:48:17 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.11/8.12.11) with ESMTP id i96KcIAC074541 for ; Wed, 6 Oct 2004 13:38:18 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.11/8.12.9/Submit) id i96KcIDD074540; Wed, 6 Oct 2004 13:38:18 -0700 (PDT) (envelope-from rsf) Message-Id: <6.1.2.0.1.20041006133327.02d75450@localhost> X-Sender: rsf@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 06 Oct 2004 13:38:15 -0700 To: avt@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [AVT] Updated Internet Drafts for "audio/mpa-robust" Draft Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 FYI, I have made available two updated Internet Drafts related to the "audio/mpa-robust" RTP payload format: draft-ietf-avt-rfc3119bis-03.txt draft-finlayson-avt-mpa-robust-interoperability-01.txt These versions were updated to use the proper new IETF 'boilerplate'; there were no other changes. Can this now be progressed to Draft Standard? Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 6 21:44:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09763 for ; Wed, 6 Oct 2004 21:44:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFNUY-0003TD-Db for avt-archive@ietf.org; Wed, 06 Oct 2004 21:54:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFNCe-0002FK-BL; Wed, 06 Oct 2004 21:36:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFN5D-0000nJ-IV for avt@megatron.ietf.org; Wed, 06 Oct 2004 21:28:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08273 for ; Wed, 6 Oct 2004 21:28:37 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFNEo-0002JK-Sr for avt@ietf.org; Wed, 06 Oct 2004 21:38:35 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i971TfIK007789; Wed, 6 Oct 2004 18:29:41 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i971KU1h028301; Wed, 6 Oct 2004 20:20:30 -0500 Message-ID: <41649C30.9050409@motorola.com> Date: Wed, 06 Oct 2004 20:30:24 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] RE: : sampling rate References: <0B08EA1BF5F6304992CDC985EE02209E02342B61@sdebe002.americas.nokia.com> <751B9B52-03EA-11D9-A048-000A957FC5F2@csperkins.org> <366D9364-0D38-11D9-A100-000A957FC5F2@csperkins.org> <4154102D.6040804@motorola.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Randell Jesup , magnus.westerlund@ericsson.com, avt@ietf.org, sassan.ahmadi@nokia.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi, Colin, >> The practical need in 3GPP2 (and possibly other systems) to feed mixed >> sampling rate input (depending on conditions in the call flow) to >> vmr-wb codec in a single session has already been explained in this >> discussion. I think it is quite equivalent to the scenario depicted by >> Randell. > > With respect, the only argument I've heard is that you want to save > having to store both 8kHz and 16kHz sampled clips in a system. That is > not a compelling reason to break the RTP timing model. No, that's not what I am concerned. Storage costs little nowadays. Other costs can be far more significant. For example, if one has to do a system-wide update of pre-existing announcement clips in order to use vmr-wb/rtp, it would become a substantial deployment cost of vmr-wb. Moreover, to maintain 2 sets of clips is surely going to add complexity to the system design as well as add to engineering and maintenance costs. So, I don't see storing both 8kHz and 16kHz sampled clips in a system as the best solution. regards, -Qiaobing > > Colin > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 6 21:57:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10322 for ; Wed, 6 Oct 2004 21:57:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFNgU-0004CS-6U for avt-archive@ietf.org; Wed, 06 Oct 2004 22:07:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFNVb-00075d-Lm; Wed, 06 Oct 2004 21:55:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFNSK-0006O8-Gf for avt@megatron.ietf.org; Wed, 06 Oct 2004 21:52:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10058 for ; Wed, 6 Oct 2004 21:52:30 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFNbv-0003s3-9c for avt@ietf.org; Wed, 06 Oct 2004 22:02:28 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id i971sfdj007559; Wed, 6 Oct 2004 18:54:41 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i971iO1h023594; Wed, 6 Oct 2004 20:44:25 -0500 Message-ID: <4164A1CB.1070302@motorola.com> Date: Wed, 06 Oct 2004 20:54:19 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] RE: : sampling rate References: <0B08EA1BF5F6304992CDC985EE02209E02A74365@sdebe002.americas.nokia.com> <1225B53B-03EB-11D9-A048-000A957FC5F2@csperkins.org> <41433EE5.3030604@motorola.com> <4145B1B6.4090000@ericsson.com> <6654897A-0D36-11D9-A100-000A957FC5F2@csperkins.org> <5D35BB06-154F-11D9-B636-000A957FC5F2@csperkins.org> In-Reply-To: <5D35BB06-154F-11D9-B636-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Randell Jesup , Magnus Westerlund , avt@ietf.org, sassan.ahmadi@nokia.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Colin Perkins wrote: >> In fact, if it _is_ possible for the encoder to use multiple rates >> (like VMR-WB), isn't it a lot easier on both sides if we can just us >> 16KHz for RTP and avoid having the play games if we want to switch >> input rates dynamically? Setting the timestamp at the sender end is >> trivial. >> >> Also, sticking with a strict timestamp rate == sample rate >> dictate means that various classes of codecs won't fit well, will be >> harder to write and/or use with RTP, or won't be developed because the >> transports for them would be painful. > > I agree. This is a limitation of the way RTP has evolved, using the > input sampling rate for the audio timestamp. Unfortunately changing the > meaning of the RTP timestamp will break things, so we're stuck with the > current model. I'd think that RTP will have to keep evolving and adapting in order to survive and be relevant. Otherwise, its ability to support newer codecs like vmr-wb (which happens to be the future of voice communications) will diminish. That would be bad for this community, IMO. regards, -Qiaobing _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 6 22:23:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11901 for ; Wed, 6 Oct 2004 22:23:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFO5o-0005oH-68 for avt-archive@ietf.org; Wed, 06 Oct 2004 22:33:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFNuu-0003f6-Hk; Wed, 06 Oct 2004 22:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFNrF-000385-8P for avt@megatron.ietf.org; Wed, 06 Oct 2004 22:18:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11547 for ; Wed, 6 Oct 2004 22:18:14 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFO0p-0005Ry-OJ for avt@ietf.org; Wed, 06 Oct 2004 22:28:13 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate2) with ESMTP id i972Io3O000991; Wed, 6 Oct 2004 19:18:50 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i972A91h020178; Wed, 6 Oct 2004 21:10:09 -0500 Message-ID: <4164A7D3.1030707@motorola.com> Date: Wed, 06 Oct 2004 21:20:03 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins Subject: Re: [AVT] Re: VMR-WB RTP Payload and Storage Formats References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: magnus.westerlund@ericsson.com, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Colin, Colin Perkins wrote: > I would have thought the conference bridge could act as an RTP > translator, and resample as appropriate for some participants? Use this as an example - here we have the advanced codec vmr-wb saying "you no longer need to worry about resampling at the bridge. Just send me the frames and I can handle them at either rates (8k or 16k)." But RTP payload says: "No, you cann't do that, even I know you are capable of it. You still have to stick with the tradition and pay the cost of signaling the rate change and building the resampling function into the bridge." I think this as a failure of taking full advantage of the codec capability. regards, -Qiaobing _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 7 00:45:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22394 for ; Thu, 7 Oct 2004 00:45:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFQJM-0005ku-BW for avt-archive@ietf.org; Thu, 07 Oct 2004 00:55:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFQ4l-0005t7-SK; Thu, 07 Oct 2004 00:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFQ3U-0005hC-8P for avt@megatron.ietf.org; Thu, 07 Oct 2004 00:39:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22136 for ; Thu, 7 Oct 2004 00:39:00 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFQD6-0005Ok-IL for avt@ietf.org; Thu, 07 Oct 2004 00:49:01 -0400 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i974d1a3003166 for ; Wed, 6 Oct 2004 21:39:01 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I5700D696919N@gateway2.EECS.Berkeley.EDU> for avt@ietf.org; Wed, 06 Oct 2004 21:39:01 -0700 (PDT) Date: Wed, 06 Oct 2004 21:39:00 -0700 From: lazzaro To: avt@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7BIT Subject: [AVT] Updated RTP MIDI I-Ds X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Hi everyone, Just finished the DC updates to RTP MIDI and sent them off to Internet-Drafts -- you can download them from: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt These updates address the issues raised by Dominique Fober, the MIDI expert who graciously offered to review the documents for the IETF -- he caught many issues, whose fixes I describe in the change log of the two I-Ds. Thanks again, Dominique! So, what's left to do for these I-Ds? [1] The MMA may have a final set of comments, I'll know for certain soon. And of course, the line is still open for comments from others too. [2] We may be approaching the point where a MIME review is in order ... Otherwise, I'd say I see no obstacles to Last Call. I'll be updating sfront soon (de-facto reference implementation) to conform to the few normative changes in the I-Ds, just to be sure these changes are implementable (they seem innocuous in this regard ...). --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 7 16:00:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17682 for ; Thu, 7 Oct 2004 16:00:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFeaw-0006fc-97 for avt-archive@ietf.org; Thu, 07 Oct 2004 16:10:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFeJ6-00074R-GP; Thu, 07 Oct 2004 15:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFe1q-0007xC-8n; Thu, 07 Oct 2004 15:34:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15741; Thu, 7 Oct 2004 15:34:16 -0400 (EDT) Message-Id: <200410071934.PAA15741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 07 Oct 2004 15:34:15 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-format-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-rtp-midi-format-06.txt Pages : 152 Date : 2004-10-7 This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-midi-format-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-midi-format-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-7155248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-midi-format-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-midi-format-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-7155248.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 8 15:05:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24275 for ; Fri, 8 Oct 2004 15:05:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG0D3-0006Nm-Sc for avt-archive@ietf.org; Fri, 08 Oct 2004 15:15:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzus-0003DH-IR; Fri, 08 Oct 2004 14:56:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzqR-0001cD-Dm; Fri, 08 Oct 2004 14:51:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22241; Fri, 8 Oct 2004 14:52:00 -0400 (EDT) Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG00Q-0005vL-4p; Fri, 08 Oct 2004 15:02:19 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <4H4TKGYB>; Fri, 8 Oct 2004 20:51:13 +0200 Message-ID: <8F669A5302C2264DBF6B856B4CBA68A0FEA3A3@accord-mail.israel.polycom.com> From: "Even, Roni" To: rajeewsingh@tataelxsi.co.in, sip@ietf.org Date: Fri, 8 Oct 2004 20:51:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4AD67.C78362EF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92788d1b003e07b99aff407d30cf4598 Cc: avt@ietf.org Subject: [AVT] RE: [Sip] Far End Camera Control in SIP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08aa56e70047071f9a3037af5750d40e This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C4AD67.C78362EF Content-Type: text/plain Hi I just submitted a personal draft to the AVT about FECC. We try to see which working group item it should be Roni Even -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rajeew Kumar Singh Sent: Wednesday, October 06, 2004 2:11 PM To: sip@ietf.org Subject: [Sip] Far End Camera Control in SIP Hi, Can anybody provide some info on Far End Camera Control in SIP. Regards Rajeew _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_000_01C4AD67.C78362EF Content-Type: text/plain; name="draft-even-avt-h224-00.txt" Content-Disposition: attachment; filename="draft-even-avt-h224-00.txt" Content-Transfer-Encoding: quoted-printable AVT R. = Even Internet-Draft = Polycom Expires: March 2, 2005 September = 2004 Far End Camera Control Payload Type draft-even-avt-h224-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document defines the syntax and the semantics of SDP parameters needed to support far end camera control protocol. In conversional video applications far end camera control protocol is used by participants to control the remote camera. The common used protocol is ITU H.281 over H.224. Even Expires March 2, 2005 [Page = 1] =0C Internet-Draft FECC September = 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Far-end camera control protocol . . . . . . . . . . . . . . . = 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 6 4.1 Registration of MIME media type application/h224 . . . . . = 6 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . = 7 5.1 Usage with the SDP Offer Answer Model . . . . . . . . . . = 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . = 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . = 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 9 Intellectual Property and Copyright Statements . . . . . . . . = 10 Even Expires March 2, 2005 [Page = 2] =0C Internet-Draft FECC September = 2004 1. Introduction The ITU-T recommendation H.281 [ITU.281] specifies a protocol for = far end camera control. This protocol is carried in H.320 systems using H.224 [ITU.H224] H.323 annex Q specifies how to carry H.281/H.224 frames using RTP packets. The document will define the SDP[RFC2327]parameters needed to = support the above far end camera control protocol in systems that use SDP Even Expires March 2, 2005 [Page = 3] =0C Internet-Draft FECC September = 2004 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119[RFC2119] and indicate requirement levels for compliant RTP implementations. Even Expires March 2, 2005 [Page = 4] =0C Internet-Draft FECC September = 2004 3. Far-end camera control protocol This protocol is based on ITU-T H.281 running over ITU-T H.224 in an RTP/UDP channel. H.323 annex Q specifies how to build the RTP packets from the H.224 packets. Using far end camera control protocol in point to point calls and multipoint calls is described in H.281 and H.323 annex Q Even Expires March 2, 2005 [Page = 5] =0C Internet-Draft FECC September = 2004 4. IANA Considerations This section describes the MIME types and names associated with this payload format. The section registers the MIME types, as per RFC2048[RFC2048] 4.1 Registration of MIME media type application/h224 MIME media type name: application MIME subtype name: H224 Required parameters: None Optional parameters: None Encoding considerations: This type is only defined for transfer via RTP [RFC3550] Security considerations: See Section 6 Interoperability considerations: Terminals that will like to send = far end camera control command should use this MIME type, receivers who can not support the protocol will reject the channel. Published specification: RFC yyy Applications which use this media type: Video conferencing applications. Additional information: none Person and email address to contact for further information : Roni Even: roni.even@polycom.co.il Intended usage: COMMON Author/Change controller: Roni Even Even Expires March 2, 2005 [Page = 6] =0C Internet-Draft FECC September = 2004 5. SDP Parameters The MIME media type application/h224 string is mapped to fields in the Session Description Protocol (SDP) as follows: o The media name in the "m=3D" line of SDP MUST be application. The transport SHOULD be RTP and the payload type is dynamic. o The encoding name in the "a=3Drtpmap" line of SDP MUST be h224 = (the MIME subtype). o The clock rate in the "a=3Drtpmap" line MUST be 0. The recommended maximum bandwidth for this protocol is 6.4 kbit/sec. 5.1 Usage with the SDP Offer Answer Model When offering FECC using SDP in an Offer/Answer model[RFC3264] the following considerations are necessary. H.281 Far end camera control communication are uni-directional. H.224 is bi-directional and can be used to learn the capabilities of the remote video end point e.g how many cameras it has. The offer answer exchange will be dependent on the functionality of both side. The offerer will offer a sendonly channel if its camera can not be remotely controlled and if the offerer does not intend to use H.224 to learn the capabilities of the remote video endpoints. In all other cases, when the offerer camera can be remotely controlled and/or it intends to use H.224 capabilities negotiation, the offerer will offer a sendrecv channel. The answerer behavior will be as follows: If it receives an offer with sendonly it will answer with a recvonly if it supports far end camera control, otherwise it will ignore reject the offer. If it receives an offer with sendrecv and its camera can be remotely controlled it will answer with a sendrecv option. If its camera cannot be remotely control it will reject the offer but may later = try to remotely control the offerer's camera using this procedure. Even Expires March 2, 2005 [Page = 7] =0C Internet-Draft FECC September = 2004 6. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550]. This implies that confidentiality of the media streams is achieved by encryption. A potential denial-of-service threat exists. The attacker can = inject pathological datagrams into the stream which may cause the receiver to move the camera randomly. The usage of authentication of at = least the RTP packet is RECOMMENDED As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. 7 Normative References [ITU.281] International Telecommunications Union, "A far end camera control protocol for videoconferences using H.224", ITU-T Recommendation H.281, November 1994. [ITU.H224] International Telecommunications Union, "A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels.", ITU-T Recommendation H.224, February 2000. [ITU.H323] International Telecommunications Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", ITU-T Recommendation H.323, July 2003. [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June Even Expires March 2, 2005 [Page = 8] =0C Internet-Draft FECC September = 2004 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Author's Address Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel EMail: roni.even@polycom.co.il Even Expires March 2, 2005 [Page = 9] =0C Internet-Draft FECC September = 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed = to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. = Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use = of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository = at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on = an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Even Expires March 2, 2005 [Page = 10] =0C ------_=_NextPart_000_01C4AD67.C78362EF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_000_01C4AD67.C78362EF-- From avt-bounces@ietf.org Fri Oct 8 15:43:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29434 for ; Fri, 8 Oct 2004 15:43:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG0og-0007MS-LF for avt-archive@ietf.org; Fri, 08 Oct 2004 15:54:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0V5-0005XZ-1Z; Fri, 08 Oct 2004 15:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0Tr-0004i2-4q; Fri, 08 Oct 2004 15:32:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28066; Fri, 8 Oct 2004 15:32:41 -0400 (EDT) Message-Id: <200410081932.PAA28066@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Oct 2004 15:32:41 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-guidelines-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An Implementation Guide for RTP MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-rtp-midi-guidelines-06.txt Pages : 42 Date : 2004-10-8 This memo offers non-normative implementation guidance for the RTP MIDI payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-guidelines-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-midi-guidelines-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-midi-guidelines-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-8155947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-midi-guidelines-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-midi-guidelines-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8155947.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 8 15:53:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00717 for ; Fri, 8 Oct 2004 15:53:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG0xb-0007sC-GQ for avt-archive@ietf.org; Fri, 08 Oct 2004 16:03:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0V7-0005ZN-Qn; Fri, 08 Oct 2004 15:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0U2-0004uO-8e; Fri, 08 Oct 2004 15:32:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28078; Fri, 8 Oct 2004 15:32:52 -0400 (EDT) Message-Id: <200410081932.PAA28078@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Oct 2004 15:32:52 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for 3GPP Timed Text Author(s) : J. Rey, Y. Matsui Filename : draft-ietf-avt-rtp-3gpp-timed-text-07.txt Pages : 43 Date : 2004-10-8 This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined decorated text media format with defined storage in a 3GP file. Timed Text can be synchronised with audio/video contents. As of today, 3GP files containing timed text contents can only be downloaded via HTTP. There is no available mechanism for streaming 3GPP timed text contents neither out of 3GP files nor directly from live content. In the following sections the problems of streaming timed text are addressed and a payload format for streaming 3GPP timed text over RTP is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-3gpp-timed-text-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-8155952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-3gpp-timed-text-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8155952.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Sat Oct 9 05:29:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28565 for ; Sat, 9 Oct 2004 05:29:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGDhR-0001sx-Uj for avt-archive@ietf.org; Sat, 09 Oct 2004 05:39:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGDTs-0004TZ-2a; Sat, 09 Oct 2004 05:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaWm-0006Oe-PC; Thu, 07 Oct 2004 11:51:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28475; Thu, 7 Oct 2004 11:49:54 -0400 (EDT) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFagS-00053P-LI; Thu, 07 Oct 2004 12:00:01 -0400 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i97Fm2Ae026387; Thu, 7 Oct 2004 17:48:03 +0200 Received: from sophia.inria.fr (vesubie.inria.fr [138.96.112.27]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i97FkvJC025557; Thu, 7 Oct 2004 17:46:58 +0200 Message-ID: <416564F1.202423D9@sophia.inria.fr> Date: Thu, 07 Oct 2004 17:46:57 +0200 From: Sara Alouf X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.22 i686) X-Accept-Language: en, fr, pt MIME-Version: 1.0 To: 100765.3267@compuserve.com, aaa-wg@merit.edu, activeNets_Wire@ittc.ukans.edu, ahmadi@engn.uwindsor.ca, ahmed@ece.concordia.ca, aidarous@bnr.ca, all@inf.ethz.ch, all_ifi@ifi.unizh.ch, amlist@takilab.k.dendai.ac.jp, announce@tcos.org, announcements.chi@acm.com, announcements.chi@xerox.com, arc-tcp@sophia.inria.fr, arl@arl.wustl.edu, arl@arl1.wustl.edu.cnri.reston.va.us, atm-list@csc.com, atm@bbn.com, avt@ietf.org, badri@cs.rutgers.edu, bd3@imag.fr, bhumip@gte.com, bobchap@ibm.net.cnri.reston.va.us, bran@silcom.com, braudyb@aol.com, brigitte.plateau@imag.fr, bumblis@mcc.com, c.desmond@ieee.org, c_F_Wetzel@att.com, cabernet-events@newcastle.ac.uk, ccrc@dworkin.ccrc.wustl.edu, cellular@comnets.rwth-aachen.de, cens@cens.ucla.edu, cfp@mmlab.snu.ac.kr, christos@ece.miami.edu, chuanyi@ecse.rpi.edu, cip@bbn.com, clytle@sed.stel.com.cnri.reston.va.us, cnom@maestro.bellcore.com.cnri.reston.va.us, comm-theory@ieee.org, commsoft@cc.bellcore.com.cnri.reston.va.us, commsoft@ieee.org, comsoc.bog@tab.ieee.org, comswtc@comsoc.org, comswtc@gmu.edu, comswtc@ieee.org, conf@colmar.uha.fr.cnri.reston.va.us, confctrl@isi.edu, conferencesa@comsoc.org, confs-conferences@comsoc.org, confs-conferencesa@comsoc.org, cost237-transport@comp.lancs.ac.uk, cost257@informatik.uni-wuerzburg.de, cost263@fokus.gmd.de, cost264@lip6.fr, craig@bbn.com, ctc-members@tinac.com, dares-announcement@enst-bretagne.fr, dbworld@cs.wisc.edu, diffserv@ietf.org, disman@dorothy.bmc.com, dist-obj@distributedcoalition.org, dnac_2002@yahoo.fr, dnzuckerman@att.com, domain3@BXL.DG13.cec.eu.int.cnri.reston.va.us, dotti@fokus.gmd.de, ecoop-info@ecoop.org, end2end-interest@isi.edu, end2end-interest@postel.org, enternet-ec@bbn.com, enternet@bbn.com, erbi@eurecom.fr, euro-ngi@infres.enst.fr, f-troup@codex.cis.upenn.edu, fad@prism.uvsq.fr, faouzi.daoud@prism.uvsq.fr, fokus-user@fokus.gmd.de, g-troup@dworkin.ccrc.wustl.edu, g.weisman@ieee.org, g3g@pacbell.net, ga@terena.nl, gi-fb3@fokus.gmd.de, giga@tele.pitt.edu, gigabitkits@arl.wustl.edu, globecom@signet.com.sg.cnri.reston.va.us, gsmp@ietf.org, gu-net@gunet.gr, guthery@austin.sar.slb.com.cnri.reston.va.us, hegering@lrz-muenchen.de, hipparch@sophia.inria.fr, icad-request@santafe.edu, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu.cnri.reston.va.us, ieeetcpc@listserv.utoronto.ca, ifip-6-1-distr@run.montefiore.ulg.ac.be, ifip-tc6@informatik.rwth-aachen.de, info-confs@comsoc.org, infocom2003-org@cs.umass.edu, int-serv@isi.edu, ipgroup@sprintlabs.com, iplpdn@cnri.reston.va.us, ippm@advanced.org, irtf-rr@puck.nether.net, iscc2000@infres.enst.fr, issll@mercury.lcs.mit.edu, itc@comsoc.org, itc@i-teletraffic.org, itc@ieee.org, iwqos@comsoc.org, jandre@imtn.tpd.dsccc.com, jerry@ece.concordia.ca, jknecht@att.com, jne@glasgow-caledonian.ac.uk, jussara@dcc.ufmg.br, just4net@aol.com, jwkhong@postech.ac.kr, kUVS-L@listserv.uni-heidelberg.de, kgold@firstconf.com, kjl@bellcore.com.cnri.reston.va.us, kom-meeting@KOM.th-darmstadt.de.cnri.reston.va.us, kseo@bbn.com, kuvs-elg@fokus.gmd.de, kuvs@tm.uka.de, labetoul@eurecom.fr, lanworks@delphi.com, lewis@ctron.com.cnri.reston.va.us, liste_cfip@info.uqam.ca, lists-mbone-eu-op-out@postman.ripe.net, lmassoul@microsoft.com, mOBICOM@acm.org, manet@ietf.org, mbone-eu-op@ripe.net, mboned@network-services.uoregon.edu, members@ngni.org, mmb@ira.uka.de, mobile-ip@sunroof.eng.sun.com, mobile-ip@tadpole.com, mohan@ccmail.inet.com.cnri.reston.va.us, mouftah@eleceng.ee.queensu.ca, mpls@uu.net, multicomm@cc.bellcore.com.cnri.reston.va.us, multicomm@comsoc.org, multicomm@research.panasonic.com, murase@nwk.cl.nec.co.jp, mustafa@ece.concordia.ca, naceur.Malouch@lip6.fr, nanog@merit.edu, nemo@nal.motlabs.com.cnri.reston.va.us, netnomics@eco.utexas.edu, netnomics@listserver.tue.nl, netos@cl.cam.ac.uk, news-announce-conferences@uunet.uu.net, nichains@BXL.DG13.cec.eu.int.cnri.reston.va.us, nkc@bellcore.com.cnri.reston.va.us, odp@dstc.edu.au, oliveira@eurecom.fr, orctrans@loria.fr, paulcov@bnr.ca, perform@tay1.dec.com.cnri.reston.va.us, performance@haven.epm.ornl.gov.cnri.reston.va.us, peterkey@microsoft.com, Philippe.Mussi@sophia.inria.fr, pilc@grc.nasa.gov, podc@research.telcordia.com, pogran@bbn.com, policy@ietf.org, prabhu@ee.uta.edu, pradeep@dstc.uts.edu.au, rHDM@lip6.fr, rdantu@tddcae99.fnts.com.cnri.reston.va.us, rem-conf@es.net, request-datacom@comsoc.org, reres@laas.fr, rlfike@aol.com, rm@openmash.org, rm@openmash.org, rmonmib@ietf.org, rmt@lbl.gov, ron.Horn.0090874@nt.com, rsvp@isi.edu, rubino@irisa.fr, saracco@cselt.stet.it, sbw@ccrl.nj.nec.com, scott_linke@aus.hp.com, seamoby@ietf.org, serge.Fdida@lip6.fr, sidou@eurecom.fr, sigmedia@bellcore.com.cnri.reston.va.us, sigmetrics@haven.epm.ornl.gov.cnri.reston.va.us, sip@ietf.org, Saverio.Mascolo@sophia.inria.fr, smds@cnri.reston.va.us, sming@ops.ietf.org, snmpv3@lists.tislabs.com, spects02@comp.leeds.ac.uk, ssefaculty@alakhawayn.ma, staples@bnr.ca, stds-802-jt11-15@ieee.org, stds-802-wpan@ieee.org, t.stevenson@ieee.org, tCPC.Mail@rome.ece.cornell.edu, tccc@comsoc.org, tccc@cs.umass.edu, tccc@ieee.org, tcgn@ieee.org, tcgn@majordomo.ieee.org, tci-announce@computer.org, tcp-impl@lerc.nasa.gov, tcplw@cray.com, tcpp-announce@eece.unm.edu, tcpsat@lerc.nasa.gov, te-wg@ops.ietf.org, tf-mm@i4serv.informatik.rwth-a.cnri.reston.va.us, tik@tik.ee.ethz.ch, tsuzuki@ccsd.ho.nec.co.jp, uist.chi@xerox.com, vik@ihades.ih.att.com, vpim@lists.neystadt.org, webrepl@cs.utk.edu, westphal@lrg.ufsc.br, wiss-mitarb@ee.ethz.ch, wlai@att.com, wolfson@ouri.cs.uic.edu, wz@prosun.first.gmd.de, xrjo@atc.boeing.com, xtp-relay@cs.concordia.ca, yemini@cs.columbia.edu, yoshida@netwk.ntt-at.co.jp, yoshida@rosso.mss.netwk.ntt-at.co.jp, zeroconf@merit.edu Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-new at sophia.inria.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sophia.inria.fr id i97Fm2Ae026387 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 09 Oct 2004 04:21:05 -0400 Subject: [AVT] CFP Performance 2005 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable ** Apologies for multiple copies of this message ** *************** CALL FOR PAPERS *************** PERFORMANCE 2005 The 24th IFIP WG 7.3 International Symposium on Computer=20 Performance Modeling, Measurement and Evaluation October 3-7, 2005 Juan-les-Pins, France http://www-sop.inria.fr/maestro/performance2005/ Sponsored by IFIP WG 7.3, the Computer Performance Foundation=20 and INRIA The PERFORMANCE 2005 conference solicits papers on the=20 development and application of state-of-the-art analytic,=20 simulation, and measurement-based performance evaluation=20 techniques. Topics of interest include, but are not=20 limited to: * Performance-oriented design and evaluation of: communication networks, mobile and wireless systems, Internet servers and E-commerce systems, Web services, Web architectures, peer-to-peer systems, grid computing, computer architectures, database systems, operating systems, software systems, distributed systems,=20 multimedia systems, file and I/O systems, memory systems, real-time systems, and fault-tolerant systems. * Techniques and algorithms: analytic modeling, performance optimization, queueing analysis, stochastic scheduling, model verification and validation, power analysis, hybrid models, experimental design, system or network measurement and monitoring, workload characterization, simulation,=20 and statistical analysis. ** SUBMISSION GUIDELINES ** PAPERS: Papers should not exceed 20 double-spaced pages=20 including figures, tables and references. A limited number=20 of submitted papers will be accepted for a poster session.=20 Submissions must be made electronically as Postscript or=20 Adobe PDF files through the Conference Web site=20 (http://www-sop.inria.fr/maestro/performance2005/). In case of problems, please send papers by email to=20 papers.perf2005@sophia.inria.fr Papers will be selected on the basis of their originality,=20 technical standards, relevance and clarity.=20 Full papers will be published in a special issue of the Journal=20 Performance Evaluation (Elsevier) available at the conference. TUTORIAL SESSIONS: Tutorial proposals, not exceeding 3 pages,=20 have to include title, abstract, duration (1H30 or 3H),=20 intended audience, assumed background of attendees, name,=20 affiliation and a biographical sketch of the instructors.=20 Proposals should be sent to the tutorials co-chairs (tutorials.perf2005@sophia.inria.fr). HOT/CONTROVERSIAL TOPIC SESSIONS: Proposals are solicited for=20 a hot topic session, in which a group of speakers will present=20 and discuss their recent results in an area. Send proposals to=20 the program co-chairs, identifying the organizer of the session,=20 the session title, three to five speakers, the titles of their=20 talks, and a short abstract of each talk. ** IMPORTANT DATES ** FEBRUARY 22, 2005 Title, abstract and author affiliation due. MARCH 1, 2005 Submission of papers, hot topic proposals and tutorial proposals.=20 JUNE 1, 2005 Notification of acceptance. JULY 1, 2005 Camera ready copy due. For Further Information: info.perf2005@sophia.inria.fr http://www-sop.inria.fr/maestro/performance2005/ ** ORGANIZING COMMITTEE ** GENERAL CHAIR:=20 Philippe Nain, INRIA, France=20 PROGRAM COMMITTEE CO-CHAIRS:=20 Cheng-Shang Chang, National Tsing Hua U., Taiwan=20 Daniel A. Menasce, George Mason U., USA TUTORIALS CO-CHAIRS:=20 Eitan Altman, INRIA, France Zhen Liu, IBM T. J.Watson Reseach Center, USA LOCAL ARRANGEMENTS CO-CHAIRS:=20 Konstantin Avrachenkov, INRIA, France Ephie Deriche, INRIA, France =20 FINANCE CHAIR: Dany Sergeant, INRIA, France PUBLICITY CHAIR: Sara Alouf, INRIA, France PROCEEDINGS CHAIR:=20 Rudesindo N=FA=F1ez Queija, CWI, The Netherlands ** PROGRAM COMMITTEE ** Almeida, Virgilio UFMG, Brazil Baccelli, Francois ENS, France Bonald, Thomas France Telecom, France Borst, Sem CWI, the Netherlands Calzarossa, Mariacarla U. Pavia, Italy de Souza e Silva, Edmundo UFRJ, Brazil Duffield, Nick AT&T Research, USA Eager, Derek U. Saskatchewan, Canada Gelenbe, Erol Imperial College, UK=20 Golubchik, Leana USC, USA Harchol-Balter, Mor Carnegie Mellon U., USA Haring, Guenter U. Wien, Austria Harrisson, Pete Imperial College, UK Haverkort, Boudewijn U. Twente, the Netherlands Herzog, Ulrich Friedrich Alexander U., Germany Hou, Jennifer U. Illinois Urbana Champaign, USA Hsu,Yarsun National Tsing Hua U., Taiwan Iazeolla, Giuzeppe U. Roma "Tor Vergata", Italy Jean-Marie, Alain U. Montpellier & INRIA, France Kumar, Anurag IISc, India Kurose, Jim U. Massachusetts, USA Le Boudec, Jean-Yves EPFL, Switzerland Lee, Duan-Shin National Tsing Hua U., Taiwan Liebeherr, Jorg U. Virginia, USA Lindemann, Christophe U. Dortmund, Germany Lui, John Chinese U. of Hong Kong, China Marsan, Marco A. Politecnico di Torino, Italy Mazumdar, Ravi U. Waterloo, Canada Merchant, Arif HP Labs, USA Misra, Vishal Columbia U., USA Mitra, Debasis Bell Laboratories, USA Muntz, Richard R. UCLA, USA Nicol, David U. Illinois Urbana-Champaign, USA Perros, Harry North Carolina State U., USA Sanders, William U. Illinois Urbana-Champaign, USA Serazzi, Giuseppe Politecnico di Milano, Italy Setia, Sanjeev George Mason University, USA Smirni, Evgenia College of William and Mary, USA Squillante, Mark IBM Research, USA Stewart, William North Carolina State U., USA Thomasian, Alexander NJIT, USA Trivedi, Kishor Duke U., USA Tucci, Salvatore U. Roma "Tor Vergata", Italy Vernon, Mary U. Wisconsin-Madison, USA Verscheure, Olivier IBM Research, USA Williamson, Carey U. Saskatchewan, Canada Woodside, C. Murray Carleton U., Canada Xia, Cathy IBM Research, USA Yao, David Columbia U., USA Zhang, Zhi-Li U. Minnesota, USA --------------- Sara Alouf Publicity chair _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 11 06:13:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20174 for ; Mon, 11 Oct 2004 06:13:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxM4-0004AM-OZ for avt-archive@ietf.org; Mon, 11 Oct 2004 06:24:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGx8z-0003Tu-Kf; Mon, 11 Oct 2004 06:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGx84-0003Az-4B for avt@megatron.ietf.org; Mon, 11 Oct 2004 06:10:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20056 for ; Mon, 11 Oct 2004 06:10:05 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxIZ-00046u-RA for avt@ietf.org; Mon, 11 Oct 2004 06:21:00 -0400 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:51083) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CGx7O-0006Zp-5z; Mon, 11 Oct 2004 11:09:26 +0100 In-Reply-To: <86966C42-1518-11D9-92C0-000A957FC5F2@csperkins.org> References: <86966C42-1518-11D9-92C0-000A957FC5F2@csperkins.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Internet Draft deadlines for IETF 61 Date: Mon, 11 Oct 2004 11:09:23 +0100 To: avt@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Reminder: the internet-draft submission deadline for -00 drafts is one week from today. Colin On 3 Oct 2004, at 09:45, Colin Perkins wrote: > The deadlines for internet-draft submissions for the 61st IETF meeting > in Washington DC are as follows: > > 11 October Pre-approval deadline for new working group drafts > 18 October Submission deadline for new working group drafts > 25 October Submission deadline for other drafts > > The deadline is at 9:00am US Eastern time on the date specified. > > Note the initial pre-approval deadline: if you are intending to submit > a new working group draft (i.e. name of the form > draft-ietf-avt-...-00.txt) you MUST contact the chairs to seek > approval, in sufficient time that we can read the draft and send > approval before 11th October. > > -- > Colin Perkins > http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 11 14:45:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02598 for ; Mon, 11 Oct 2004 14:45:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH5Lg-0006Ch-6O for avt-archive@ietf.org; Mon, 11 Oct 2004 14:56:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH58f-00071S-O7; Mon, 11 Oct 2004 14:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4xN-0003zg-I5 for avt@megatron.ietf.org; Mon, 11 Oct 2004 14:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00998 for ; Mon, 11 Oct 2004 14:31:35 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH57n-0005kb-NX for avt@ietf.org; Mon, 11 Oct 2004 14:42:34 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63181 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CH4wh-0002tB-E4 for avt@ietf.org; Mon, 11 Oct 2004 19:30:55 +0100 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: avt@ietf.org From: Colin Perkins Date: Mon, 11 Oct 2004 19:30:51 +0100 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [AVT] Checking of boilerplate for Internet-Drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Folks, A reminder that the secretariat is now checking that all new internet draft submissions have the correct boilerplate. If your draft doesn't conform to the guidelines at http://www.ietf.org/ietf/1id-guidelines.txt it will be rejected. You are STRONGLY URGED to use the idnits tool to check your draft before submitting it. See http://ietf.levkowetz.com/tools/idnits/ Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 11 17:21:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29757 for ; Mon, 11 Oct 2004 17:21:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7mP-0005Ko-C5 for avt-archive@ietf.org; Mon, 11 Oct 2004 17:32:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH7Ki-0002zJ-E1; Mon, 11 Oct 2004 17:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH6NT-0007nz-M7 for avt@megatron.ietf.org; Mon, 11 Oct 2004 16:02:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11666 for ; Mon, 11 Oct 2004 16:02:37 -0400 (EDT) Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=mail.tvol.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH6Y4-0008Ep-AC for avt@ietf.org; Mon, 11 Oct 2004 16:13:36 -0400 Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NPY708RR; Mon, 11 Oct 2004 16:01:36 -0400 To: Colin Perkins Subject: Re: [AVT] RE: : sampling rate References: <0B08EA1BF5F6304992CDC985EE02209E02A74365@sdebe002.americas.nokia.com> <1225B53B-03EB-11D9-A048-000A957FC5F2@csperkins.org> <41433EE5.3030604@motorola.com> <4145B1B6.4090000@ericsson.com> <6654897A-0D36-11D9-A100-000A957FC5F2@csperkins.org> <5D35BB06-154F-11D9-B636-000A957FC5F2@csperkins.org> From: Randell Jesup Date: 11 Oct 2004 16:04:41 -0400 In-Reply-To: <5D35BB06-154F-11D9-B636-000A957FC5F2@csperkins.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: Magnus Westerlund , sassan.ahmadi@nokia.com, avt@ietf.org, Qiaobing Xie X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 My apologies for the delayed response; I accidentally deleted my 1/2-written response a few days ago. Colin Perkins writes: >>> Yes. This is why RTP has the "rate" parameter, and uses the sampling >>> rate as the RTP timestamp rate. >> >> My apologies, but I don't see how that answers the question as to >> what the benefit is. How does the receiver make use of this information? >> Why is this better for the receiver? > >If the codec can have different rates for source material and output >material, it's clearly advantageous to signal that. More information is >clearly better, as I hope is obvious. Sure - but that doesn't answer the question, which is how timestamp-rate == input-sample-rate benefits the receiver. >For RTP audio, the convention is to use the sampling rate at the input to >drive the timestamp. The benefit is that it gives a consistent RTP timing >model, with well defined semantics independent of the codec. This makes it >simpler to design senders that operate with a range of codecs, and to >design receivers that perform sample-accurate synchronisation (since the >timestamp always increases by exactly 1 per audio sample in the input, >meaning receivers can do synchronisation independent of the codec). Ok, here there are some claims. Let me list them: 1) "consistent RTP timing model, with well defined semantics independent of the codec" My apologies again, but that still seems to be hand-waving. What semantics are you speaking of, and how does this do something useful? 2) "simpler to design senders that operate with a range of codecs" In all cases, the codec must tell the "sender" (RTP sender API) how many input samples a frame of RTP data corresponds to (directly or indirectly). You could design things such that higher-level code (that feeds input data to the codec) "knows" the codec's frame size - but you really don't gain by doing so, and you remove a bunch of possibilities in codec design. Also, doing so rather inappropriately mixes codec-specific knowledge into higher-level code - the higher level code would have to learn about silence suppression, etc, etc. Also the codec might want higher-sample-rate input in some cases to do it's own filtering before encoding. And there are variable-framesize codecs, adaptive bandwidth codecs that might adapt input sample rates depending on guesses about the input, etc, etc. Certainly keeping timestamp-rate == input-sample-rate isn't necessary if the RTP send API includes a (possibly optional) parameter for the number of RTP timestamp units the block corresponds to. And for all sorts of reasons it makes sense to have that, at least as an option. 3) [simpler to] "design receivers that perform sample-accurate synchronisation" Sample-accurate synchronization: a) if sticking by the RTP/RTCP model to the letter it isn't guaranteed to be possible, and a receiver can't assume it can do it. RTCP will give you "this RTP timestamp == this NTP timestamp" for each stream independently, generally at wide intervals. There is no guarantee even for streams from a single source that the sample times are synchronized - in fact in multimedia synchronization typically they aren't (video is a fixed 90000Hz timestamp rate, and video frames are usually sampled from an external clock, or if from an internal clock not the same one used to drive the audio D->A. Even two audio streams may (and in fact in many cases will) be based on different hardware clocks. So no receiver can (in a spec-compliant way) assume it can do sample- accurate synchronization of streams from the same source, even if they're both audio. b) Since the timestamp-rates we're talking about are typically fixed in the RTP spec for the codec, one can assume that they will be chosen to make sense - typically to correspond to a useful rate for the codec data or a multiple of it (or a lowest-common-multiple if it's a multirate codec). So from that end, sample accuracy shouldn't come into it. c) receivers don't get to process input data. They get to process output data from the codec. synchronization is typically done on output samples from the codec. So you _can_ make an argument that the timestamp rate should correspond to the codec output sample rate, or for multirate codecs the lowest-common-multiple (though I would expect that multirate codecs would output at their highest rate regardless of the intermediate rate, but there may be some reasons not to - in which case the codec will have to provide data on the output rate for each block of output). >> I can see some advantage in having the RTP rate parameter be the >> normal _output_ sample rate from the codec (which may be uncorrelated to >> the input rate!) in that you could use that to implement an audio codec >> with non-fixed frame sizes. > >I agree that might be useful. However, it doesn't fit with the semantics >assigned to the RTP timestamp. I'd say it doesn't fit the original "fixed hardware A->D/D->A"/G711/etc mindset/convention. But I don't see how sticking to that mindset/convention gets us anything, and as people have shown, it definitely costs us something. >>>> B. Is it necessary to use the sampling frequency as RTP timestamp rate. >>> >>> It's highly desirable. >> >> Again, asserting this without a reason doesn't convince me. > >To make a consistent definition of the RTP timestamp. a) consistency is only useful if it provides you with an advantage. b) how is this consistent with other uses of RTP timestamps, such as video? They're even further afield. >>>> Colin, if one looks at issue B. Is it really needed to use the RTP >>>> timestamp frequency equal to the sampling rate used? I would say NO to >>>> that question. >>> >>> Yes, it is necessary to use an RTP timestamp equal to the sampling rate. >> >> Again, no reasons given. > >Again, to avoid breaking standard RTP timing model. Again, what does this "break" other than a convention that so far as I can see exists merely by happenstance and with no particular reason behind it? >>>> My reasoning is the following. >>>> >>>> - Many audio input is sampled from a source at a higher rate then the >>>> encoder may handle. Thus a resampling and pre-processing stage is >>>> employed based on the encoders input frequency rather then producing >>>> that >>>> rate initially from the hardware. Some of the reason is that the >>>> pre-processing may actually yield better results than what the hardware >>>> at given input rate can gain. Another reason may be that one like to >>>> avoid switching the hardware between rate if changing the encoding. >>>> >>>> - The frame based decoders does not need to know the encoders input >>>> rate. The encoder may anyway resample this into other rates for internal >>>> processing and band limited signals. I would claim that VMR-WB, AMR-WB+ >>>> and AAC are all example of codecs that perform this kind of tricks. On >>>> the receiver side they produce a output signal that has any sampling >>>> frequency the receiver finds most useful. Either causing clipping of the >>>> higher frequencies, but more commonly to a higher clock rate, despite >>>> that no more information is provided simply for ease of use. >>>> >>>> - The frame based codecs do only need a RTP timestamp that allows the >>>> receiver to correctly reconstruct the time line when the encoding is >>>> done >>>> with the most audio bandwidth. In the VMR-WB case this is 16kHz. AMR-WB+ >>>> is even more strange, as we have selected an RTP timestamp rate that >>>> results in that all internal sampling frequencies will result in integer >>>> timestamp ticks. Thus actually allowing one to correctly calculate frame >>>> alignment when the internal sampling frequency changes. That the >>>> frequency also is possible to recalculate into several common sampling >>>> frequencies with few partial sample alignments was also considered. >>>> >>>> Thus I would use this to argue that indicating the actual sampling >>>> frequency is not necessarily as long as the receiver is capable of >>>> correctly reconstruct the media stream with its timing information in >>>> full resolution. >>> >>> True, but it greatly simplifies the system if all codecs use the >>> sampling rate as the RTP clock rate. You can make things work if each >>> codec uses a different rate, but it's desirable that RTP is consistent >>> where possible. Why is this codec so special that it needs to break this >>> rule? >> >> Again, I simply don't see how things are simplified by having the >> RTP timestamp rate be the sender-side sample rate. If the timestamp rate >> is 2x or 4x the input rate, or if it's the lowest common multiple (if you >> know what I mean) of a range of sample rates the encoder might use, how >> does that hurt the receiver? > >See above. The above didn't answer it. The closest thing to an answer were the points 1-3 above that I pulled out of your response, and I so far as I can see they don't answer the question I pose. >> In fact, if it _is_ possible for the encoder to use multiple rates (like >> VMR-WB), isn't it a lot easier on both sides if we can just us 16KHz for >> RTP and avoid having the play games if we want to switch input rates >> dynamically? Setting the timestamp at the sender end is trivial. >> >> Also, sticking with a strict timestamp rate == sample rate >> dictate means that various classes of codecs won't fit well, will be >> harder to write and/or use with RTP, or won't be developed because the >> transports for them would be painful. > >I agree. This is a limitation of the way RTP has evolved, using the input >sampling rate for the audio timestamp. Unfortunately changing the meaning >of the RTP timestamp will break things, so we're stuck with the current >model. So, breaking that down, you agree that sticking with the convention limits the application of RTP, but you're worried about "break[ing] things". So if you can be convinced that the convention is not a requirement and that defining new codecs that don't follow that convention won't break anything, then I take it you'd be in favor? >> Or, perhaps worse for the participant of this group, such codecs will >> push the use of alternative mechanisms such as IAX2 or other possible >> alternatives. I could simplify my life CONSIDERABLY by ignoring RTP and >> using a single multiplexed stream, with lower overhead due to piggybacked >> nacks and acks, and much less hassle blowing multiple holes through >> firewall/NATS. But for the sake of standards and compatibility I've gone >> through the pain of getting dealing with all the issues surrounding RTP, >> feedback, RTP-through-NATs, etc, and have probably hewn (much) closer to >> the specs than most, I suspect. >> >> Don't put up roadblocks where there isn't a reason to. In this >> case, there is a good argument _for this codec_ to use a fixed 16K >> timestamp rate. > >However, doing so would fragment the consistent RTP timing model. I agree >that using a 16kHz clock for this codec solves a short term implementation >issue; however it makes RTP implementations that support multiple codec >more complex in the long term, and fragments the standard. To be horribly repetitious: please show how this will make multiple codec implementation noticably more complex, or how it will "fragment" the standard and what the practical fallout would be. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 12 15:49:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25120 for ; Tue, 12 Oct 2004 15:49:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHSot-0005za-B8 for avt-archive@ietf.org; Tue, 12 Oct 2004 16:00:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSXx-0005VG-A5; Tue, 12 Oct 2004 15:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSSL-0002ya-NV; Tue, 12 Oct 2004 15:37:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23429; Tue, 12 Oct 2004 15:37:08 -0400 (EDT) Message-Id: <200410121937.PAA23429@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 12 Oct 2004 15:37:08 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-xr-mib-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Proposed RTP Control Protocol Extended Reports (RTCP XR) VoIP Metrics Management Information Base Author(s) : A. Clark, A. Pendleton Filename : draft-ietf-avt-rtcp-xr-mib-00.txt Pages : 17 Date : 2004-10-12 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Control Protocol Extended Reports (RTCP XR) VoIP Metrics (RFC3611). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-xr-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-xr-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-12160252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-xr-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-xr-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-12160252.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Oct 12 17:46:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17960 for ; Tue, 12 Oct 2004 17:46:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUeo-0004PO-At for avt-archive@ietf.org; Tue, 12 Oct 2004 17:58:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHU25-0003Fy-A6; Tue, 12 Oct 2004 17:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOqn-0005So-ID; Tue, 12 Oct 2004 11:48:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02471; Tue, 12 Oct 2004 11:46:00 -0400 (EDT) Received: from foxtrot.nab.org ([209.116.240.194] helo=nab.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHP1N-00087F-4V; Tue, 12 Oct 2004 11:57:08 -0400 Received: from ([199.29.3.1]) by maildc2.nab.org with ESMTP id 4028857.2383141; Tue, 12 Oct 2004 11:45:09 -0400 Received: by mail.NAB.ORG with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Oct 2004 11:45:09 -0400 Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF108EDC59B@mail.NAB.ORG> From: "Allison, Art" To: "'Sara Alouf'" , 100765.3267@compuserve.com, aaa-wg@merit.edu, activeNets_Wire@ittc.ukans.edu, ahmadi@engn.uwindsor.ca, ahmed@ece.concordia.ca, aidarous@bnr.ca, all@inf.ethz.ch, all_ifi@ifi.unizh.ch, amlist@takilab.k.dendai.ac.jp, announce@tcos.org, announcements.chi@acm.com, announcements.chi@xerox.com, arc-tcp@sophia.inria.fr, arl@arl.wustl.edu, arl@arl1.wustl.edu.cnri.reston.va.us, atm-list@csc.com, atm@bbn.com, avt@ietf.org, badri@cs.rutgers.edu, bd3@imag.fr, bhumip@gte.com, bobchap@ibm.net.cnri.reston.va.us, bran@silcom.com, braudyb@aol.com, brigitte.plateau@imag.fr, bumblis@mcc.com, c.desmond@ieee.org, c_F_Wetzel@att.com, cabernet-events@newcastle.ac.uk, ccrc@dworkin.ccrc.wustl.edu, cellular@comnets.rwth-aachen.de, cens@cens.ucla.edu, cfp@mmlab.snu.ac.kr, christos@ece.miami.edu, chuanyi@ecse.rpi.edu, cip@bbn.com, clytle@sed.stel.com.cnri.reston.va.us, cnom@maestro.bellcore.com.cnri.reston.va.us, comm-theory@ieee.org, commsoft@cc.bellcore.com.cnri.reston.va.us, commsoft@ieee.org, comsoc.bog@tab.ieee.org, comswtc@comsoc.org, comswtc@gmu.edu, comswtc@ieee.org, conf@colmar.uha.fr.cnri.reston.va.us, confctrl@isi.edu, conferencesa@comsoc.org, confs-conferences@comsoc.org, confs-conferencesa@comsoc.org, cost237-transport@comp.lancs.ac.uk, cost257@informatik.uni-wuerzburg.de, cost263@fokus.gmd.de, cost264@lip6.fr, craig@bbn.com, ctc-members@tinac.com, dares-announcement@enst-bretagne.fr, dbworld@cs.wisc.edu, diffserv@ietf.org, disman@dorothy.bmc.com, dist-obj@distributedcoalition.org, dnac_2002@yahoo.fr, dnzuckerman@att.com, domain3@BXL.DG13.cec.eu.int.cnri.reston.va.us, dotti@fokus.gmd.de, ecoop-info@ecoop.org, end2end-interest@isi.edu, end2end-interest@postel.org, enternet-ec@bbn.com, enternet@bbn.com, erbi@eurecom.fr, euro-ngi@infres.enst.fr, f-troup@codex.cis.upenn.edu, fad@prism.uvsq.fr, faouzi.daoud@prism.uvsq.fr, fokus-user@fokus.gmd.de, g-troup@dworkin.ccrc.wustl.edu, g.weisman@ieee.org, g3g@pacbell.net, ga@terena.nl, gi-fb3@fokus.gmd.de, giga@tele.pitt.edu, gigabitkits@arl.wustl.edu, globecom@signet.com.sg.cnri.reston.va.us, gsmp@ietf.org, gu-net@gunet.gr, guthery@austin.sar.slb.com.cnri.reston.va.us, hegering@lrz-muenchen.de, hipparch@sophia.inria.fr, icad-request@santafe.edu, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu.cnri.reston.va.us, ieeetcpc@listserv.utoronto.ca, ifip-6-1-distr@run.montefiore.ulg.ac.be, ifip-tc6@informatik.rwth-aachen.de, info-confs@comsoc.org, infocom2003-org@cs.umass.edu, int-serv@isi.edu, ipgroup@sprintlabs.com, iplpdn@cnri.reston.va.us, ippm@advanced.org, irtf-rr@puck.nether.net, iscc2000@infres.enst.fr, issll@mercury.lcs.mit.edu, itc@comsoc.org, itc@i-teletraffic.org, itc@ieee.org, iwqos@comsoc.org, jandre@imtn.tpd.dsccc.com, jerry@ece.concordia.ca, jknecht@att.com, jne@glasgow-caledonian.ac.uk, jussara@dcc.ufmg.br, just4net@aol.com, jwkhong@postech.ac.kr, kUVS-L@listserv.uni-heidelberg.de, kgold@firstconf.com, kjl@bellcore.com.cnri.reston.va.us, kom-meeting@KOM.th-darmstadt.de.cnri.reston.va.us, kseo@bbn.com, kuvs-elg@fokus.gmd.de, kuvs@tm.uka.de, labetoul@eurecom.fr, lanworks@delphi.com, lewis@ctron.com.cnri.reston.va.us, liste_cfip@info.uqam.ca, lists-mbone-eu-op-out@postman.ripe.net, lmassoul@microsoft.com, mOBICOM@acm.org, manet@ietf.org, mbone-eu-op@ripe.net, mboned@network-services.uoregon.edu, members@ngni.org, mmb@ira.uka.de, mobile-ip@sunroof.eng.sun.com, mobile-ip@tadpole.com, mohan@ccmail.inet.com.cnri.reston.va.us, mouftah@eleceng.ee.queensu.ca, mpls@uu.net, multicomm@cc.bellcore.com.cnri.reston.va.us, multicomm@comsoc.org, multicomm@research.panasonic.com, murase@nwk.cl.nec.co.jp, mustafa@ece.concordia.ca, naceur.Malouch@lip6.fr, nanog@merit.edu, nemo@nal.motlabs.com.cnri.reston.va.us, netnomics@eco.utexas.edu, netnomics@listserver.tue.nl, netos@cl.cam.ac.uk, news-announce-conferences@uunet.uu.net, nichains@BXL.DG13.cec.eu.int.cnri.reston.va.us, nkc@bellcore.com.cnri.reston.va.us, odp@dstc.edu.au, oliveira@eurecom.fr, orctrans@loria.fr, paulcov@bnr.ca, perform@tay1.dec.com.cnri.reston.va.us, performance@haven.epm.ornl.gov.cnri.reston.va.us, peterkey@microsoft.com, Philippe.Mussi@sophia.inria.fr, pilc@grc.nasa.gov, podc@research.telcordia.com, pogran@bbn.com, policy@ietf.org, prabhu@ee.uta.edu, pradeep@dstc.uts.edu.au, rHDM@lip6.fr, rdantu@tddcae99.fnts.com.cnri.reston.va.us, rem-conf@es.net, request-datacom@comsoc.org, reres@laas.fr, rlfike@aol.com, rm@openmash.org, rm@openmash.org, rmonmib@ietf.org, rmt@lbl.gov, ron.Horn.0090874@nt.com, rsvp@isi.edu, rubino@irisa.fr, saracco@cselt.stet.it, sbw@ccrl.nj.nec.com, scott_linke@aus.hp.com, seamoby@ietf.org, serge.Fdida@lip6.fr, sidou@eurecom.fr, sigmedia@bellcore.com.cnri.reston.va.us, sigmetrics@haven.epm.ornl.gov.cnri.reston.va.us, sip@ietf.org, Saverio.Mascolo@sophia.inria.fr, smds@cnri.reston.va.us, sming@ops.ietf.org, snmpv3@lists.tislabs.com, spects02@comp.leeds.ac.uk, ssefaculty@alakhawayn.ma, staples@bnr.ca, stds-802-jt11-15@ieee.org, stds-802-wpan@ieee.org, t.stevenson@ieee.org, tCPC.Mail@rome.ece.cornell.edu, tccc@comsoc.org, tccc@cs.umass.edu, tccc@ieee.org, tcgn@ieee.org, tcgn@majordomo.ieee.org, tci-announce@computer.org, tcp-impl@lerc.nasa.gov, tcplw@cray.com, tcpp-announce@eece.unm.edu, tcpsat@lerc.nasa.gov, te-wg@ops.ietf.org, tf-mm@i4serv.informatik.rwth-a.cnri.reston.va.us, tik@tik.ee.ethz.ch, tsuzuki@ccsd.ho.nec.co.jp, uist.chi@xerox.com, vik@ihades.ih.att.com, vpim@lists.neystadt.org, webrepl@cs.utk.edu, westphal@lrg.ufsc.br, wiss-mitarb@ee.ethz.ch, wlai@att.com, wolfson@ouri.cs.uic.edu, wz@prosun.first.gmd.de, xrjo@atc.boeing.com, xtp-relay@cs.concordia.ca, yemini@cs.columbia.edu, yoshida@netwk.ntt-at.co.jp, yoshida@rosso.mss.netwk.ntt-at.co.jp, zeroconf@merit.edu Date: Tue, 12 Oct 2004 11:45:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Oct 2004 17:18:07 -0400 Subject: [AVT] Call For Proposals NAB 2005 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable NAB2005 will host the 59th NAB Broadcast Engineering Conference on = April 16-21 at the Las Vegas Convention Center in Las Vegas, Nevada. The conference addresses the most recent developments in broadcast = technology and focuses on the opportunities and challenges that face broadcast engineering professionals around the world. Each year hundreds of broadcast professionals from around the world = attend the conference. They include practicing broadcast engineers and technicians, engineering consultants, contract engineers, broadcast equipment manufacturers, distributors, R&D engineers plus anyone specifically interested in the latest broadcast technologies. =20 The NAB Broadcast Engineering Conference is a highly technical = conference where presenters deliver technical papers ranging over a variety of = topics relevant to the broadcast and allied industries. Presentations are = limited to thirty minutes in length, including five or ten minutes for = questions from the audience. The conference rooms are equipped with audio visual equipment that will accommodate standard computer presentations. = Presenters must bring their own computers. We invite you to submit a proposal to present a technical paper at our conference by accessing = http://www.nabshow.com/forms/beccallforpapers.asp. Proposals should be clearly written and be no more than 200 words in = length. Your proposal should explain precisely what conference attendees can be expected to learn from your paper. Papers promoting company products = or services will not be accepted. However, papers explaining the = underlying technologies used in broadcast products or services will be acceptable. The deadline for submitting your proposal is October 15, 2004. The selection process will begin at that time. You can expect to be = notified if your paper proposal has been accepted by November 19, 2004. After = receiving your acceptance, you will have until January 31, 2005 to submit your completed paper to us. Your paper will be published in the NAB = Broadcast Engineering Conference Proceedings and you will receive a complimentary copy. We will consider all topics related to broadcast engineering, such as: Television Engineering =B7 Data Broadcasting Technologies and Applications =B7 Distributed Transmission =B7 Television Transmission Systems and Maintenance =B7 8VSB Enhancements =B7 Systems Integration =B7 Storage and Networking =B7 Broadband Technologies =B7 Automation Systems =B7 Camera Technology =B7 Film Transfer =B7 Archival Technologies =B7 Set-top Box Technology =B7 Test and Measurement Techniques =B7 Media Asset Management =B7 Television Receiver Developments =B7 Optimizing RF Coverage =B7 Design and Building Studio and Transmission Facilities =B7 Security and Emergency Preparedness =B7 Broadcast Technical Standards =B7 Remote Broadcasting =B7 Remote Systems Control =B7 Centralcasting =B7 Interference Concerns =B7 Digital Television Developments Around the World Radio Engineering =B7 Digital Radio Developments Around the World =B7 In Band On Channel DAB Implementation =B7 Test and Measurement Techniques =B7 Automation Systems =B7 Centralcasting =B7 New Receiver Technologies =B7 Data Broadcasting Technologies and Applications =B7 Security and Emergency Preparedness =B7 New Transmitter Technologies =B7 Optimizing RF Coverage =B7 AM Directional Antenna Systems =B7 Broadband Technologies =B7 Interference Concerns =B7 Audio Coding Advancements -- We are also soliciting speakers for other conferences.=20 See http://www.nabshow.com/technologypapers.asp, =20 Thank you for your bandwidth.=20 Art ::{)> Arthur W. Allison Director, Science & Technology National Association of Broadcasters 202 429 5418 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 14 04:45:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19525 for ; Thu, 14 Oct 2004 04:45:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI1QE-0004Zg-Qs for avt-archive@ietf.org; Thu, 14 Oct 2004 04:57:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI19G-0001eT-Kk; Thu, 14 Oct 2004 04:39:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI001-0004yk-In for avt@megatron.ietf.org; Thu, 14 Oct 2004 03:26:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15204 for ; Thu, 14 Oct 2004 03:26:07 -0400 (EDT) From: Andre.Adrian@dfs.de Received: from [195.27.201.52] (helo=mail1.dfs.de) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CI0B4-0003EK-OP for avt@ietf.org; Thu, 14 Oct 2004 03:37:38 -0400 To: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 14 Oct 2004 09:25:31 +0200 X-MIMETrack: Serialize by Router on OHVLNM06/SRV/DFS(Release 5.0.10 |March 22, 2002) at 14.10.2004 09:26:04 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 0af64a5d6771d0a11c20b73fee87759a Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 14 Oct 2004 04:39:43 -0400 Subject: [AVT] Acoustic Echo cancellation memo X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e0ce87e8a8080dd27b518f94257398f8 Content-Transfer-Encoding: quoted-printable Dear Members of Audio/Video Transport group, as attachment you find a memo about "Acoustic Echo Cancellation". This = memo was created while developing a Voice-over-IP Prototype for intercom communication between air traffic controllers by the german air traffic= control agency DFS. Mr. Colin Perkins wrote me: >We're grateful that you considered the IETF AVT working group as a >venue for this work. Unfortunately, we don't have sufficient expertis= e >to effectively review it, and so cannot accept it as an AVT work item.= >If you have a paper on this subject, you're welcome to post a pointer >to the AVT mailing list to encourage uptake, though. >I'm not sure what an appropriate venue for publication might be, >although the ITU-T has done related work in the past. >Regards, >Colin As you can read in the memo, the algorithm and the implementation are royalty free and should not be monopolized as intellectual property by = DFS or by others. The software is currently implemented in kphone - a SIP softphone runni= ng on Linux. You can find the memo and the Kphone source file patches on http://home.arcor.de/andreadrian/ With best regards, Andre Adrian Senior engineer email work: email home: snail-mail: DFS Flughafen Frankfurt Gebaeude 501 60549 Frankfurt Germany Tel: (++49) 69 69766 176 FAX: (++49) 69 69766 175 #######################################################################= ########### Attachment: Draft Andre Adrian= Document: draft-avt-aec-01.txt DFS Deutsche Flugsicherung= Category: Experimental october 11th, 2004 Expires: ? Voice over Internet Acoustic Echo Cancellation Status of this Memo This document specifies an Acoustic Echo Cancellation implementation = for hands-free Voice over Internet telephony and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) DFS Deutsche Flugsicherung (2004). All Rights Reserved.= You are allowed to use this source code in any open source or closed source software you want. You are allowed to use the algorithms for a hardwa= re solution. You are allowed to modify the source code. You are not allowed to remove the name of the author from this memo o= r from the source code files. You are not allowed to monopolize the source c= ode or the algorithms behind the source code as your intellectual property. This source code is free of royalty and comes with no warranty. Abstract This document specifies an acoustic echo cancellation (AEC) for voice= over IP. Because of the large latency in VoIP communication (tenths to hunderts of milliseconds), AEC is necessary. The presented implementation is b= ased on the well-known Normalized Least Means Square (NLMS) and Geigel Double= talk detector (DTD) algorithms. To improve performance, a pre-whitening fi= lter is used. The presented algorithm is therefore of NLMS-pw family. The NLMS-pw family is known to give good echo cancellation for modera= te processing resources. This algorithm is of complexity O(3*L) with L number of taps in the NLMS filter. Table of Contents 1. INTRODUCTION 2. AEC PRINCIPLES 3. AEC algorithms 3.1. Infinite Impulse Response (IIR) Highpass Filter 3.2. Geigel Double Talk Detector 3.3. Normalized Least Means Square - Pre-Whitening Filter 4. References A. The C++ Source Code A.1 aec.h A.2 aec.cxx A.3 aec_test.cxx 1. INTRODUCTION A hands-free telephone or full-duplex intercom system has a feedback = or echo problem because the output from the loudspeaker feeds into the microphone. Several methods can be used to reduce or eliminate the problem: 1.) Reduce the overall amplification. If the system amplification is = less then 1 a feedback dies away. This solution leads to poor volume. 2.) Use Acoustic Echo Suppression. Echo Suppression is realized with speech activated switches. Suppression reduces the full-duplex telephone to half- duplex. The switches can even "switch away" beginnings of words. 3.) Use Acoustic Echo Cancellation. This is realized with an adaptive= or learning filter. First the filter learns from given microphone and speaker signals the acoustics. After learning, the filter can calculate an estimated microphone signal from the loudspeaker signal. This estimated mic sig= nal is subtracted from the real mic signal. The difference signal no longer contains the loudspeaker signal - the feedback loop is broken. The Least Means Square algorithm from Widrow and Hoff is known since 1960. Unfortunately the LMS is a slow learner. The learning speed or convergence rate is controlled by a constant value. This value in the LMS can onl= y be optimized for loud signals or for weak signals. Optimizing for loud signals produces slow convergence with weak signals. Optimizing for weak sign= als gives divergence with loud signals. Divergence can be defined as "the= filter does not reduce the echo but does increase the echo" and is very ugly= . The Normalized LMS has a constant convergence rate for loud and weak signals, the convergence rate controlling parameter is derived from t= he signal energy. For white noise signal, where all frequencies have the same energy, t= he NLMS performs good. But the human speech has more energy in low frequencies then in high frequencies. Therefore, a NLMS gives good echo cancellat= ion for low frequencies and poor echo cancellation for high frequencies. A pre-whitening filter in front of the echo cancellation filter transforms human speech into something more "white noise" like - the energy of h= igh frequency signals is similar to the energy of low frequency signals. The presented algorithm uses the most simple pre-whitening filter possible, a first order or one pole highpass filter with transfer frequency equ= al to half of the sample frequency (4kHz for the narrowband sample frequenc= y of 8kHz). Because the pre-whitening filter is fixed, the complexity of this NLM= S-pw filter is still the same as for the NLMS filter. One important point should be remembered: The AEC in your telephony device helps your telephony partner to hear no echo. Therefore AEC is an altruistic algorithm. 2. AEC PRINCIPLES The core of the acoustic echo cancellation is described in the introduction. Next to the NLMS-pw three more blocks are used: 1.) A highpass filter for the microphone signal. Telephone users are = used to a frequency range between 300Hz and 3400Hz. Narrowband VoIP can gi= ve 0Hz to 4000Hz. After hearing a VoIP signal with frequencies below 300Hz testers complained about the bad quality. With a 300Hz cut-off filter sound i= s limited as in telephone. The highpass filter in use is a 6th order infinite impulse response (= IIR) filter. IIR filter was used because of its simplicity and low process= ing demand. 2.) A double talk detector. The AEC filter should only learn if the signal from the microphone is determined from the loudspeaker signal only. I= f the local or near-end user is talking, the filter can no longer learn successful. Detection of user talking is done by comparing the volume= levels of loudspeaker and microphone. This implementation uses the well-known Geigel DTD. 3.) An Acoustic Echo Suppressor (AES) or Non Linear Processor (NLP). = If the Double talk detector (DTD) detects "no talking", the microphone signa= l gets attenuated by 6dB. This is done to suppress echo artefacts. AEC block diagram. Sin is the microphone signal, Rout and Rin is the loudspeaker signal. Sout is the echo-cancelled microphone signal: +--+ + +---+ Sin -->---|HP|--+------->(+)----+-->|NLP|--->-- Sout +--+ | /|\ | +---+ | -| | \|/ | | +---+ +----+ | |DTD|---->|NLMS|<-+ +---+ +----+ /|\ /|\ | | | | Rout -<---------+---------+-----------------<-- Rin Figure 1.) AEC block diagram 3. AEC algorithms This chapter gives the mathematical background to the source code. Th= is document will not give derivations of the algorithms or proofs. See references for more information. 3.1. Infinite Impulse Response (IIR) Highpass Filter IIR lowpass filters are also known as "exponential smoothing". The traditional form of exponential smoothing is: y[n+1] =3D (1-alpha) * y[n] + alpha * x[n+1] with x[n+1] is the actual measurement value, y[n] is the previous smoothed or lowpass-filtered value, y[n+1] is the actual smoothed value, alpha is the smoothing constant or slowly changeing variable, determi= ning the transfer frequency. After a little algebra the exponential smoothing formula looks this: y[n+1] +=3D alpha*(x[n+1] - y[n]) To move from lowpass to highpass we use the following assumption: highpass =3D signal - lowpass In this formula "highpass", "signal" and "lowpass" are rather abstrac= t things. The implementation uses the following formulas: lowpassf[i+1] +=3D AlphaHp*(highpassf[i] - lowpassf[i+1]) highpassf[i+1] =3D highpassf[i] - lowpassf[i+1] with highpassf[i] is the "highpassed" value from the previous filter stage, highpassf[i+1] is the "highpassed" value of this filter stage, lowpassf[i+1] is the "lowpassed" value of this filter stage, AlphaHp is a constant that determines the transfer frequency. Attention: The index i refers to filter stage and should not be confu= sed with the index n above which refers to time. The above two formulas give an attenuation of 3dB below the transfer frequency. To get steeper filters, we use 12 stages. The signal to be "highpassed" is feed in as highpassf[0]. The result is in highpassf[12]. Because the filter attenuates the signal above transfe= r frequency, a amplification constant of 1.45 or 3.2dB is used. The value for AlphaHp for a 300Hz highpass filter was found empirical= ly. Only one AlphaHp constant for all stages of the 6th order filter is a= nice feature of this approach. 3.2. Geigel Double Talk Detector Talk detection can be done with a threshold for the microphone signal= only. This approach is very sensitive to the threshold level. A more robust= approach is to compare microphone level with loudspeaker level. The threshold in this solution will be a relative one. Because we deal wi= th echo, it is not sufficient to compare only the actual levels, but we = have to consider previous levels, too. The Geigel DTD brings these ideas in one simple formula: The last L levels (index 0 for now and index L-1 for L samples ago) from loudspeaker si= gnal are compared to the actual microphone signal. To avoid problems with phase, the absolute values are used. Double talk is declared if: |d| >=3D c * max(|x[0]|, |x[1]|, .., |x[L-1]|) with |d| is the absolute level of actual microphone signal, c is a threshold value (typical value 0.5 for -6dB or 0.71 for -3dB),= |x[0]| is the absolute level of actual loudspeaker signel, |x[L-1]| is the absolute level of loudspeaker signal L samples ago. See references 3, 7, 9. 3.3. Normalized Least Means Square - Pre-Whitening Filter The NLMS-pw, NLMS and LMS are of the gradient descent-based algorithm= s family. The good features of gradient-descent based algorithms are simplicity and robustness. First we look at the "echo cancelling" formula, the convolution. This= formula is used to subtract the (from the loudspeaker signal) estimat= ed microphone signal from the real microphone signal. e =3D d - X' * W with e is the linear error signal or echo-cancelled microphone signal= , d is the desired signal or the microphone signal with echo, X' is the transpose of the loudspeaker signals vector, W is the adaptive weights vector. With a matching vector W the echo cancellation can be perfect. Unfortunately, learning the vector W has limitations. The loudspeaker= is not the only audio source at filter learning. Ambient sounds and noises, system internal amplifier and converter noises and non-linearities of= loudspeaker and microphone have a negative impact on learning. Due to the LMS simplicity, all elements of W are updated with the sam= e "mikro * e" term. This simple approach makes the LMS robust and only demanding moderate processing resources, but this "one term fits all"= approach prevents "perfect" learning, too. The LMS algorithm has the update formula: W[n+1] =3D W[n] + 2*mikro*e*X[n] with W[n+1] is the new adaptive weights vector, W[n] is the previous adaptive weights vector, mikro is the step size constant or variable, e is the error signal X[n] is the loudspeaker signals vector. The constant scalar mikro becomes a variable in NLMS. This variable i= s calculated from the loudspeaker signals vector with: 1 mikro =3D ------ X' * X with X' is the transpose of the loudspeaker signals vector, X is the loudspeaker signals vector. Note: The vector dot product is a scalar. It is the sum of the element-wise multiplication of both vectors. The constant value 2 in the LMS formula changes into a stability "tuneing" constant. For stable adaptation this constant should be between 0 and= 2, this NLMS-pw uses a value of 0.5. The NLMS-pw uses for the weights vector update and the calculation of= mikro highpass-filtered values of e and X. The filtered values are used bec= ause the NLMS converges best with white noise signals, and human voice is = not white noise. The fixed highpass filter approach used in this NLMS-pw = does not increase the overall complexity. With ef =3D highpass(e) Xf =3D highpass(X) we get our NLMS-pw weights vector update formulas: 0.5 mikro =3D -------- Xf' * Xf W[n+1] =3D W[n] + mikro*ef*Xf[n] with ef is the highpass-filtered value of e, Xf is the highpass-filtered value of X, and the other values are as above. Both filters are 1. order FIR with a transfer frequency of 4000Hz. For other pre-whitening algorithms see references 6, 8, 9. For non-LM= S echo cancellation algorithms see references 6 and 9. 4. References [1] B. Widrow, M. E. Hoff Jr., "Adaptive switching circuits", Western= Electric Show and Convention Record, Part 4, pages 96-104, Aug. 1= 960 [2] B. Widrow, et al, "Stationary and Nonstationary Learning Characteristics of the LMS Adaptive Filter", Proc. of the IEEE, v= ol. 64 No. 8, pp. 1151-1162, Aug. 1976 [3] D.L. Duttweiler, "A twelve-channel digital echo canceller", IEEE Trans. Commun., Vol. 26, pp. 647-653, May 1978 [4] B. Widrow, S.D. Stearns, Adaptive Signal Processing, Prentice-Hal= l, 1985 [5] D. Messerschmitt, D. Hedberg, C. Cole, A. Haoui, P. Winship, "Dig= ital Voice Echo Canceller with a TMS32020", Application report SPRA129= , Texas Instruments, 1989 [6] R. Storn, "Echo Cancellation Techniques for Multimedia Applicatio= ns - a Survey", TR-96-046, International Computer Science Institute,= Berkeley, Nov. 1996 [7] J. Nikolic, "Implementing a Line Echo Canceller using the block update and NLMS algorithms on the TMS320C54x DSP", Application report SPRA188, Texas Instruments, Apr. 1997 [8] M. G. Siqueira, "Adaptive Filtering Algorithms in Acoustic Echo Cancellation and Feedback Reduction", Ph.D. thesis, University of= California, Los Angeles, 1998 [9] T. Gaensler, S. L. Gay, M. M. Sondhi, J. Benesty, "Double-Talk ro= bust fast converging algorithms for network echo cancellation", IEEE trans. on speech and audio processing, vol. 8, No. 6, Nov. 2000 [10] M. Hutson, "Acoustic Echo Cancellation using Digital Signal Processing", Bachelor of Engineering (Honours) thesis, The School= of Information Technology and Electrical Engineering, The University= of Queensland, Nov 2003 [11] A. Adrian, "Audio Echo Cancellation", Free Software/Open Source Telephony Summit 2004, German Unix User Group, Geilenkirchen, Germany, Jan. 16-20, 2004 Appendix A. The C++ Source Code /*************************************************************** A.1 aec.h ***************************************************************/ #ifndef _AEC_H /* include only once */ /* aec.h * Acoustic Echo Cancellation NLMS-pw algorithm * Author: Andre Adrian, DFS Deutsche Flugsicherung * * * Version 1.1 */ /* dB Values */ const float M0dB =3D 1.0f; const float M3dB =3D 0.71f; const float M6dB =3D 0.50f; /* dB values for 16bit PCM */ const float M10dB_PCM =3D 10362.0f; const float M20dB_PCM =3D 3277.0f; const float M25dB_PCM =3D 1843.0f; const float M30dB_PCM =3D 1026.0f; const float M35dB_PCM =3D 583.0f; const float M40dB_PCM =3D 328.0f; const float M45dB_PCM =3D 184.0f; const float M50dB_PCM =3D 104.0f; const float M55dB_PCM =3D 58.0f; const float M60dB_PCM =3D 33.0f; const float MAXPCM =3D 32767.0f; /* Design constants (Change to fine tune the algorithms */ /* For Normalized Least Means Square - Pre-whitening */ #define NLMS_LEN (240*8) /* maximum NLMS filter length in = taps */ const float PreWhiteAlphaTF =3D (4000.0f/8000.0f); /* FIR controls Tr= ansfer Frequency */ /* for Geigel Double Talk Detector */ const float GeigelThreshold =3D M3dB; const int Thold =3D 30*8; /* DTD hangover in = taps */ const float UpdateThreshold =3D M30dB_PCM; /* for Non Linear Processor */ const float NLPAttenuation =3D M0dB; /* Below this line there are no more design constants */ /* Exponential Smoothing or IIR Infinite Impulse Response Filter */ class IIR_HP { float lowpassf; float alphaTF; /* controls Transfer Frequency */ public: IIR_HP() { lowpassf =3D 0.0f; alphaTF =3D 0.0f; } void init(float alphaTF_) { alphaTF =3D alphaTF_; } float highpass(float in) { /* Highpass =3D Signal - Lowpass. Lowpass =3D Exponential Smoothing= */ lowpassf +=3D alphaTF*(in - lowpassf); return in - lowpassf; } }; #define POL 6 /* -6dB attenuation per octave per Pol */= class IIR_HP6 { float lowpassf[2*POL+1]; float highpassf[2*POL+1]; public: IIR_HP6(); float highpass(float in) { const float AlphaHp6 =3D 0.075; /* controls Transfer Frequency */ const float Gain6 =3D 1.45f; /* gain to undo filter attenuation = */ highpassf[0] =3D in; int i; for (i =3D 0; i < 2*POL; ++i) { /* Highpass =3D Signal - Lowpass. Lowpass =3D Exponential Smoothi= ng */ lowpassf[i+1] +=3D AlphaHp6*(highpassf[i] - lowpassf[i+1]); highpassf[i+1] =3D highpassf[i] - lowpassf[i+1]; } return Gain6*highpassf[2*POL]; } }; /* Recursive single pole FIR Finite Impulse response filter */ class FIR1 { float a0, a1, b1; float last_in, last_out; public: FIR1(); void init(float preWhiteTransferAlpha); float highpass(float in) { float out =3D a0 * in + a1 * last_in + b1 * last_out; last_in =3D in; last_out =3D out; return out; } }; #define NLMS_EXT (10*8) // Extention in taps to reduce mem copies #define DTD_LEN 16 // block size in taps to optimize DTD calculation class AEC { // Time domain Filters IIR_HP6 hp0; // 300Hz cut-off Highpass IIR_HP hp1; // DC-level remove Highpass) FIR1 Fx, Fe; // pre-whitening Highpass for x, e // Geigel DTD (Double Talk Detector) float max_max_x; // max(|x[0]|, .. |x[L-1]|) int hangover; float max_x[NLMS_LEN/DTD_LEN]; // optimize: less calculations for ma= x() int dtdCnt; int dtdNdx; // NLMS-pw float x[NLMS_LEN+NLMS_EXT]; // tap delayed loudspeaker signal= float xf[NLMS_LEN+NLMS_EXT]; // pre-whitening tap delayed signal float w[NLMS_LEN]; // tap weights int j; // optimize: less memory co= pies int lastupdate; // optimize: iterative dotp(x,x) double dotp_xf_xf; // double to avoid loss of precision public: AEC(); /* Geigel Double-Talk Detector * * in d: microphone sample (PCM as floating point value) * in x: loudspeaker sample (PCM as floating point value) * return: 0 for no talking, 1 for talking */ int dtd(float d, float x); /* Normalized Least Mean Square Algorithm pre-whitening (NLMS-pw) * The LMS algorithm was developed by Bernard Widrow * book: Widrow/Stearns, Adaptive Signal Processing, Prentice-Hall, 198= 5 * * in mic: microphone sample (PCM as floating point value) * in spk: loudspeaker sample (PCM as floating point value) * in update: 0 for convolve only, 1 for convolve and update * return: echo cancelled microphone sample */ float nlms_pw(float mic, float spk, int update); /* Acoustic Echo Cancellation and Suppression of one sample * in d: microphone signal with echo * in x: loudspeaker signal * return: echo cancelled microphone signal */ int AEC::doAEC(int d, int x); }; #define _AEC_H #endif /*************************************************************** A.2 aec.cxx ***************************************************************/ /* aec.cxx * Acoustic Echo Cancellation NLMS-pw algorithm * Author: Andre Adrian, DFS Deutsche Flugsicherung * * * Version 1.1 */ #include #include #include #include #include "aec.h" IIR_HP6::IIR_HP6() { memset(this, 0, sizeof(IIR_HP6)); } /* Vector Dot Product */ float dotp(float a[], float b[]) { float sum0 =3D 0.0, sum1 =3D 0.0; int j; for (j =3D 0; j < NLMS_LEN; j+=3D 2) { // optimize: partial loop unrolling sum0 +=3D a[j] * b[j]; sum1 +=3D a[j+1] * b[j+1]; } return sum0+sum1; } /* * Algorithm: Recursive single pole FIR high-pass filter * * Reference: The Scientist and Engineer's Guide to Digital Processing */ FIR1::FIR1() { } void FIR1::init(float preWhiteTransferAlpha) { float x =3D exp(-2.0 * M_PI * preWhiteTransferAlpha); a0 =3D (1.0f + x) / 2.0f; a1 =3D -(1.0f + x) / 2.0f; b1 =3D x; last_in =3D 0.0f; last_out =3D 0.0f; } AEC::AEC() { hp1.init(0.01f); /* 10Hz */ Fx.init(PreWhiteAlphaTF); Fe.init(PreWhiteAlphaTF); max_max_x =3D 0.0f; hangover =3D 0; memset(max_x, 0, sizeof(max_x)); dtdCnt =3D dtdNdx =3D 0; memset(x, 0, sizeof(x)); memset(xf, 0, sizeof(xf)); memset(w, 0, sizeof(w)); j =3D NLMS_EXT; lastupdate =3D 0; dotp_xf_xf =3D 0.0f; } float AEC::nlms_pw(float mic, float spk, int update) { float d =3D mic; // desired signal x[j] =3D spk; xf[j] =3D Fx.highpass(spk); // pre-whitening of x // calculate error value (mic signal - estimated mic signal from spk signal) float e =3D d - dotp(w, x + j); float ef =3D Fe.highpass(e); // pre-whitening of e if (update) { if (lastupdate) { // optimize: iterative dotp(xf, xf) dotp_xf_xf +=3D (xf[j]*xf[j] - xf[j+NLMS_LEN-1]*xf[j+NLMS_LEN-1])= ; } else { dotp_xf_xf =3D dotp(xf+j, xf+j); } // calculate variable step size float mikro_ef =3D 0.5f * ef / dotp_xf_xf; // update tap weights (filter learning) int i; for (i =3D 0; i < NLMS_LEN; i +=3D 2) { // optimize: partial loop unrolling w[i] +=3D mikro_ef*xf[i+j]; w[i+1] +=3D mikro_ef*xf[i+j+1]; } } lastupdate =3D update; if (--j < 0) { // optimize: decrease number of memory copies j =3D NLMS_EXT; memmove(x+j+1, x, (NLMS_LEN-1)*sizeof(float)); memmove(xf+j+1, xf, (NLMS_LEN-1)*sizeof(float)); } return e; } int AEC::dtd(float d, float x) { // optimized implementation of max(|x[0]|, |x[1]|, .., |x[L-1]|): // calculate max of block (DTD_LEN values) x =3D fabsf(x); if (x > max_x[dtdNdx]) { max_x[dtdNdx] =3D x; if (x > max_max_x) { max_max_x =3D x; } } if (++dtdCnt >=3D DTD_LEN) { dtdCnt =3D 0; // calculate max of max max_max_x =3D 0.0f; for (int i =3D 0; i < NLMS_LEN/DTD_LEN; ++i) { if (max_x[i] > max_max_x) { max_max_x =3D max_x[i]; } } // rotate Ndx if (++dtdNdx >=3D NLMS_LEN/DTD_LEN) dtdNdx =3D 0; max_x[dtdNdx] =3D 0.0f; } // The Geigel DTD algorithm with Hangover timer Thold if (fabsf(d) >=3D GeigelThreshold * max_max_x) { hangover =3D Thold; } if (hangover) --hangover; if (max_max_x < UpdateThreshold) { // avoid update with silence or noise return 1; } else { return (hangover > 0); } } int AEC::doAEC(int d, int x) { float s0 =3D (float)d; float s1 =3D (float)x; // Mic Highpass Filter - telephone users are used to 300Hz cut-off s0 =3D hp0.highpass(s0); // Spk Highpass Filter - to remove DC s1 =3D hp1.highpass(s1); // Double Talk Detector int update =3D !dtd(s0, s1); // Acoustic Echo Cancellation s0 =3D nlms_pw(s0, s1, update); // Acoustic Echo Suppression if (update) { // Non Linear Processor (NLP): attenuate low volumes s0 *=3D NLPAttenuation; } // Saturation if (s0 > MAXPCM) { return (int)MAXPCM; } else if (s0 < -MAXPCM) { return (int)-MAXPCM; } else { return (int)roundf(s0); } } /*************************************************************** A.3 aec_test.cxx ***************************************************************/ /* aec_test.cxx * Test stub for Acoustic Echo Cancellation NLMS-pw algorithm * Author: Andre Adrian, DFS Deutsche Flugsicherung * * * Version 1.1 */ #include #include #include #include #include "aec.h" #define TAPS (80*8) typedef signed short MONO; typedef struct { signed short l; signed short r; } STEREO; /* Read a raw audio file (8KHz sample frequency, 16bit PCM, stereo) * from stdin, echo cancel it and write it to stdout */ int main(int argc, char *argv[]) { STEREO inbuf[TAPS], outbuf[TAPS]; fprintf(stderr, "usage: aec_test out.raw\n"); AEC aec; int taps; while (taps =3D fread(inbuf, sizeof(STEREO), TAPS, stdin)) { int i; for (i =3D 0; i < taps; ++i) { int s0 =3D inbuf[i].l; /* left channel microphone */ int s1 =3D inbuf[i].r; /* right channel speaker */ /* and do NLMS*/ s0 =3D aec.doAEC(s0, s1); /* copy back */ outbuf[i].l =3D 0; /* left channel silence */ outbuf[i].r =3D (MONO)(s0); /* right channel echo cancelled mic= */ } fwrite(outbuf, sizeof(STEREO), taps, stdout); } fflush(NULL); return 0; } /*************************************************************** A.4 Compile source code ***************************************************************/ On a Linux system with GNU C++ compiler enter: g++ aec_test.cxx aec.cxx -o aec_test -lm /*************************************************************** A.5 Test source code ***************************************************************/ The microphone and loudspeaker signals have to be synchronized on a sample-to-sample basis to make acoustic echo cancellation working. An AC97 conformal on-board soundcard in a Personal Computer can be set in a special stereo mode: The left channnel records microphone signal and the right channel reports loudspeaker signal. To set-up a Linux PC with ALSA sound system, microphone connected to Mic in and loudspeaker connected to right Line out enter: amixer -q set 'Master',0 50% unmute amixer -q set 'PCM',0 80% unmute amixer -q set 'Line',0 0% mute amixer -q set 'CD',0 0% mute amixer -q set 'Mic',0 0% mute amixer -q set 'Video',0 0% mute amixer -q set 'Phone',0 0% mute amixer -q set 'PC Speaker',0 0% mute amixer -q set 'Aux',0 0% mute amixer -q set 'Capture',0 50%,0% amixer -q set 'Mic Boost (+20dB)',0 1 amixer -q cset iface=3DMIXER,name=3D'Capture Source' 0,5 amixer -q cset iface=3DMIXER,name=3D'Capture Switch' 1 To test the acoustic echo cancellation we simulate a real telephone conversation in 5 steps: (1) record far-end speaker, (2) perform acoustic echo cancellation (this should change nothing) (3) playback far-end speaker and at the same time record near-end spe= aker (4) perform acoustic echo cancellation (5) playback near-end speaker (far-end speech should be cancelled) To record 10 seconds of speech into the file b.raw enter: arecord -D plug:hw:0 -c 2 -t raw -f S16_LE -r 8000 -d 10 >b.raw To perform AEC at the far-end enter: ./aec_test b1.raw To playback file b1.raw and simultaneously record b2.raw enter both commands in one go: aplay -D plug:hw:0 -c 2 -t raw -f S16_LE -r 8000 b1.raw & arecord -D plug:hw:0 -c 2 -t raw -f S16_LE -r 8000 -d 10 >b2.raw To perform AEC at the near-end enter: ./aec_test b3.raw To playback the echo-cancelled near-end enter: aplay -D plug:hw:0 -c 2 -t raw -f S16_LE -r 8000 b3.raw DFS Deutsche Flugsicherung GmbH TWR-S=FCd, Geb=E4ude 501 Frankfurt - Flughafen D - 60549 Frankfurt Tel.: +49-(0)69-69766-101 Fax: +49-(0)69-69766-105 Home Page: http://www.dfs.de -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP 6.5.8 mQGiBECbVgwRBAD09k4R2DiCObeUeO+FZCBJ8OkjzEIQ3niUMHSwlQmX5prKCJQe NjEGvsS4Ex6qdYQ/awmXkNtOpsF0mN3aBoKUyRDF6KkkfsTNYQQ6WyK5RHu2Q4wQ G93DL+Ryhgs2oNH3Ou4FbEiYATJCl14fpxd08D0DCsmL0ZfeaZlZeBCUzwCg/8sY qJ2uSj5JgHWEp170menK6CUEAIlI3gXegKbBY1PFSpzNpjVGQJg9bQR4B6tqdASP nLfsQR+1BIIz0WFgiIickqPSRbGYP7slpw9onE43su3HVg2sBMI25Q5kK6WujPUG n72PDy8yogXCcYS807FcqMqKTqYjiRQxbcQn3gJaoTau0/HJTHF9jES89SyIDXdm CjphA/9FZ0tmotILaxyL53X8G01lf28NhykkGzbBTiIAsgTcvCx6b1GxBwUb/WlL KmWG3kjwSsZxtPzrUPN3Z83pavfCQI4E9tNI4mVgX9gtklKoVtJPglu2jPrJ+umZ UO78anBrsTnPzOJ954+uziMe3imsFAC8T2gAmgsAvZgZP98gBLQYREZTIEdtYkgg PHB1YmtleUBkZnMuZGU+iQBOBBARAgAOBQJAm1YMBAsDAQICGQEACgkQN3h5OLny dHrchQCgmuRvdqRthFARXOQatgKCc+5pWs4AoPkSU2XeYbNq4AVmv0BJOpRgOsCJ uQMNBECbVosQDADMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X/faY98h8ebByHTh1 +/bBc8SDESYrQ2DD4+jWCv2hKCYLrqmus2UPogBTAaB81qujEh76DyrOH3SET8rz F/OkQOnX0ne2Qi0CNsEmy2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8MvZCV7cI fwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ +AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm /xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1F HQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzh sSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZ Jrqrol7DVelMMm8AAgIL/2zbjaNlPL+13ZFiJwAGg0yj4zciLkp141Pwvn2OtY+B JZxnIfcPKINj2f5QiW4weqV9OMJ5EgZcx8aRxkk5uJsJv3S1JFUUNaSwCl0xynpr Spw5QsoCAQAhzmOlqj1tvCJW3bm3iniiud6UzGjbdpvU9oeiSOGMFYVpfGCHC5fb 4TnnsLcrmARXh3COKle27X7TGOROUWyxqKWdHvBsMEjO2ERF2A+nMEYz4dd8kezd Iiw9hjftJtp9GpCJ5CWq4jcyQ5Bb+D0IUqI0FdH9Mfe8ytMnDRwDPH1r9FaCNkaH Q+8Aqp20QbSHe03CaT8UbYziNCNdzCFt4QjDqAfDsTKEHGeBzKfBprsKbox6CURk IikAiUX0YE1P3bxH2ovP5bxEormlPfFN870QYNZYmo03hX41H6LnOaI4YaHzfiXG Plrm/mtkDryXoqA57f09vcQcAmS6Qa50qyqheGK49lSM9MndqXGWrmddtccE3qUJ /U1UAxqX11l80Yz8Wk+brokARgQYEQIABgUCQJtWiwAKCRA3eHk4ufJ0enLHAJ9R 3Z0uPt+U+qSJU/63IpU/y+Ho3QCgg571CpdVdsohBeaF21f4uckz3nU=3D =3Dh1ys -----END PGP PUBLIC KEY BLOCK----- = _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 14 18:12:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12821 for ; Thu, 14 Oct 2004 18:12:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIE18-0007S1-Ed for avt-archive@ietf.org; Thu, 14 Oct 2004 18:24:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDm4-0003PM-NL; Thu, 14 Oct 2004 18:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDaB-0006ga-6I for avt@megatron.ietf.org; Thu, 14 Oct 2004 17:56:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11068 for ; Thu, 14 Oct 2004 17:56:20 -0400 (EDT) Received: from mail.8x8.com ([192.84.19.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDlM-000787-Sz for avt@ietf.org; Thu, 14 Oct 2004 18:08:00 -0400 Received: from [127.0.0.1] (mail [192.84.19.130]) by mail.8x8.com (Postfix) with ESMTP id EAD0F1E1A2; Thu, 14 Oct 2004 14:55:46 -0700 (PDT) Message-ID: <416EF5E2.7030104@8x8.com> Date: Thu, 14 Oct 2004 14:55:46 -0700 From: Jim Kleck User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Subject: [AVT] bandwidth feedback in draft-ietf-avt-rtcp-feedback-11.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Hi all, We have a SIP video conferencing application which operates over broadband. Typically our videophone is on a local network behind a router connected to a DSL or cable modem. When another device on the local network asynchronously starts using bandwidth, e.g. by doing an FTP, we experience either increasing latency as transmitted packets are buffered along the path and/or we experience dropped packets. Both of these conditions are detectable by using RTCP Sender Reports and Receiver Reports, but the question is: how far should our application reduce its transmit bandwidth? RTCP reports indicate number of lost packets or increasing latency, but due to the varying transmit bandwidth of the video (i.e. small bandwidth during periods of little motion, larger bandwidth during periods of large motion), this does not easily translate into how far to reduce the transmit bandwidth. The far end's receiver does, however, have the means to easily calculate both the sender's transmit bandwidth for a particular period (by comparing the two most recently received RTCP Sender Reports) and the actual received bandwidth for that comparable period (by comparing the time and the received byte count at the reception of those two RTCP Sender Reports). Note that the receive bandwidth alone is not sufficient because of the varying video bandwidth. So given these transmit and receive bandwidths, the difference is the amount by which the sender has overfilled the pipe. This difference is not exact because RTP/RTCP packets can get out of sequence, so the difference is only meaningful if it exceeds some threshold. Now all that is needed is a way for the receiver to communicate this difference back to the sender. This could certainly be done using an Application Layer Feedback Message but it is the receiver's RTP layer which processes the RTCP Sender Reports and Receiver Reports and which can calculate the bandwidth difference. This puts the feedback more in the Transport Layer area. However, the sender (i.e. the endpoint that receives the feedback) must pass the information up to the application, so maybe it belongs in the Application Layer area after all. But this kind of feedback seems of general use to me, possibly useful for many types of payload. It should thus be standardized and not left up the the applications nor put into the Payload Specific area. So, I propose a new transport layer feedback message with a single FCI field containing an unsigned 32 bit value. This FCI field would contain the bandwidth difference detected by the receiver. Upon receiving this feedback, the sender can then reduce its maximum transmit bandwidth by the difference. Thank you for your time, Jim Kleck 8x8, Inc _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 15 04:19:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04268 for ; Fri, 15 Oct 2004 04:19:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CINUL-0000cu-F5 for avt-archive@ietf.org; Fri, 15 Oct 2004 04:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CINGw-00052I-QT; Fri, 15 Oct 2004 04:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CINEU-0004dO-Gd for avt@megatron.ietf.org; Fri, 15 Oct 2004 04:14:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04071 for ; Fri, 15 Oct 2004 04:14:36 -0400 (EDT) Received: from [203.196.161.92] (helo=redpinesignals.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CINPm-0000Yo-Bm for avt@ietf.org; Fri, 15 Oct 2004 04:26:21 -0400 Received: from redpinesignals.com ([192.168.1.34]) by redpinesignals.com (8.11.6+Sun/8.11.6) with ESMTP id i9F5sJZ02979; Fri, 15 Oct 2004 13:54:20 +0800 (CST) Message-ID: <416F891E.7050600@redpinesignals.com> Date: Fri, 15 Oct 2004 13:53:58 +0530 From: P Lavin Organization: www.redpinesignals.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner References: <001f01c48040$637571c0$9c40fea9@Gbino> <20040812120443.S63026@ash.packetdesign.com> Content-Type: multipart/mixed; boundary="------------010502090607040003010200" X-Spam-Score: 0.3 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: avt@ietf.org Subject: [AVT] RTP SEND-RECV / Problem with linux 8.0 Sound. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lavin.p@redpinesignals.com List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd This is a multi-part message in MIME format. --------------010502090607040003010200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Steve, I've developed an RTP Stack. Now i'm doing the testing for the same. The stack is being tested on Linux 8.0, afterwords this will be ported to some RTOS... I've tested my stack with one SEND-Only session on one machine & RECV- Only session on other machine. It worked fine !!! I was able to communi- cate with the other endpoint using my stack(But a small delay was there). Now i'm testing SendRecv session (ie sending and receiving in single (or multiple) thread)(I'll be reading/writing to /dev/dsp inside a loop) The sequence of operations on single thread is given below, while(1) { //read from /dev/dsp. //Send this to n/w using RTP //recv data from RTP Stack. //Write this data to /dev/dsp } The problem lies here... In this progam i'm reciving the data frm remote session correctly...and i'm writing that data after receiving ... but after each write the my audio has a delay in palying the next packet... wt i'm trying to say is the data from the remote machine seems to be non-contineous. Where as when i tried with send-only & recv-only the real-time playback was contineous... I've opened the audio device using one of the files provided by vovida. I'm attatching that file. Sampling rate 44100Hz, 16Bits. Please help me with this issue... Thanks in Advance, Regards, P Lavin --------------010502090607040003010200 Content-Type: text/plain; name="soundOss.c" Content-Disposition: inline; filename="soundOss.c" Content-Transfer-Encoding: 7bit /* ==================================================================== * The Vovida Software License, Version 1.0 * * Copyright (c) 2000 Vovida Networks, Inc. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. The names "VOCAL", "Vovida Open Communication Application Library", * and "Vovida Open Communication Application Library (VOCAL)" must * not be used to endorse or promote products derived from this * software without prior written permission. For written * permission, please contact vocal@vovida.org. * * 4. Products derived from this software may not be called "VOCAL", nor * may "VOCAL" appear in their name, without prior written * permission of Vovida Networks, Inc. * * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND * NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA * NETWORKS, INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT DAMAGES * IN EXCESS OF $1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH * DAMAGE. * * ==================================================================== * * This software consists of voluntary contributions made by Vovida * Networks, Inc. and many individuals on behalf of Vovida Networks, * Inc. For more information on Vovida Networks, Inc., please see * . * */ //static const char* const phoneJack_cxx_Version = // "$Id: soundcardTest.cxx,v 1.1 2001/03/09 01:40:55 kimle Exp $"; #include #include #include #include #include //#include "RtpSession.hxx" //#include "cpLog.h" #define NETWORK_RTP_RATE 160 static int deviceFD; //RtpSession* audioStack; //RtpPacket* outRtpPkt; //RtpPacket* inRtpPkt; //RtpPayloadType apiCodec; static int apiRate; audio_buf_info info; void *iPtr,*oPtr; int openAudioHardware( const char* pname ,int samplingRate) { //cerr <<"Opening audio hardware\n"; int audioFD,min_size,blk_size=1024,cond,i,p; int ioctlParam; // open audio device if( ( audioFD = open( pname, O_RDWR, 0 ) ) == -1 ) { perror("Open failed:"); return -1; } #if 0 ioctl(audioFD,SNDCTL_DSP_GETBLKSIZE,&min_size); if(min_size > blk_size) { cond=1; p=min_size/blk_size; while(cond) { i=ioctl(audioFD,SNDCTL_DSP_SUBDIVIDE,&p); if((i==0)||(p==1)) cond=0; else p=p/2; } } ioctl(audioFD,SNDCTL_DSP_GETBLKSIZE,&min_size); printf("SNDCTL_DSP_GETBLKSIZE(size)=%d\n",min_size); #endif // query audio formats ioctlParam = 16; if( ioctl( audioFD, SNDCTL_DSP_SAMPLESIZE, &ioctlParam ) == -1 ) { perror("SNDCTL_DSP_SAMPLESIZE"); return -1; } ioctlParam = -1; if( ioctl( audioFD, SNDCTL_DSP_GETFMTS, &ioctlParam ) == -1 ) { perror("SNDCTL_DSP_GETFMTS"); return -1; } // choose codec if( ioctlParam & AFMT_MU_LAW ) { //cpLog(LOG_DEBUG,"Setting sound card to ulaw"); ioctlParam = AFMT_MU_LAW; //apiCodec = rtpPayloadPCMU; //apiRate = 160; } else if( ioctlParam & AFMT_S16_LE ) { //cpLog(LOG_DEBUG,"Setting sound card to linear16"); ioctlParam = AFMT_S16_LE; //apiCodec = rtpPayloadL16_mono; //apiRate = 320; } else { //cpLog(LOG_ERR,"Sound card doesn't support any known encodings"); printf("Sound card supports the following (Mask:%d:)\n", ioctlParam); if( ioctlParam & AFMT_MU_LAW ) printf(" AFMT_MU_LAW\n"); if( ioctlParam & AFMT_A_LAW ) printf(" AFMT_A_LAW\n"); if( ioctlParam & AFMT_IMA_ADPCM ) printf(" AFMT_IMA_ADPCM\n"); if( ioctlParam & AFMT_U8 ) printf(" AFMT_U8\n"); if( ioctlParam & AFMT_S16_LE ) printf(" AFMT_S16_LE\n"); if( ioctlParam & AFMT_S16_BE ) printf(" AFMT_S16_BE\n"); if( ioctlParam & AFMT_S8 ) printf(" AFMT_S8\n"); if( ioctlParam & AFMT_U16_LE ) printf(" AFMT_U16_LE\n"); if( ioctlParam & AFMT_U16_BE ) printf(" AFMT_U16_BE\n"); if( ioctlParam & AFMT_MPEG ) printf(" AFMT_MPEG\n"); return -1; } //Setting Duplex if( ioctl( audioFD, SNDCTL_DSP_SETDUPLEX,0 ) == -1 ) { perror("SNDCTL_DSP_SETDUPLEX"); return -1; } // setting audio device parameters int ioctlParamSave = ioctlParam; if( ioctl( audioFD, SNDCTL_DSP_SETFMT, &ioctlParam ) == -1 ) { perror("SNDCTL_DSP_SETFMT"); return -1; } if( ioctlParam != ioctlParamSave ) { perror("Failed to set DSP Format, sound card returned format"); return -1; } ioctlParam = 1; if( ioctl( audioFD, SNDCTL_DSP_CHANNELS, &ioctlParam ) == -1 ) { perror("SNDCTL_DSP_CHANNELS"); return -1; } if( ioctlParam != 1) { perror("Failed to set channels"); return -1; } ioctlParam = samplingRate; if( ioctl( audioFD, SNDCTL_DSP_SPEED, &ioctlParam ) == -1 ) { perror("SNDCTL_DSP_SPEED"); return -1; } if( ioctlParam != samplingRate ) { perror("Failed to set sample rate"); return -1; } #if 0 ioctl(audioFD,SNDCTL_DSP_GETISPACE,&info); printf("ISpace\nNo of Fragments:%d,\nTotal fragments allocated for buffering:%d,\nFragment size:%d,\nTotal Available Bytes %d \n\n",info.fragments,info.fragstotal,info.fragsize,info.bytes); ioctl(audioFD,SNDCTL_DSP_GETOSPACE,&info); printf("OSpace\nNo of Fragments:%d,\nTotal fragments allocated for buffering:%d,\nFragment size:%d,\nTotal Available Bytes %d \n\n",info.fragments,info.fragstotal,info.fragsize,info.bytes); //ioctl(audioFD,SNDCTL_DSP_GETOPTR,oPtr); //ioctl(audioFD,SNDCTL_DSP_GETOPTR,iPtr); #endif return audioFD; } int closeAudioHardware( int audioFD ) { //cerr <<"Closing audio hardware\n"; if( ioctl( audioFD, SNDCTL_DSP_RESET, 0 ) == -1 ) { perror("SNDCTL_DSP_RESET"); } close( audioFD ); return 1; } --------------010502090607040003010200 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --------------010502090607040003010200-- From avt-bounces@ietf.org Tue Oct 19 02:14:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17625 for ; Tue, 19 Oct 2004 02:14:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJnSC-0004ml-5T for avt-archive@ietf.org; Tue, 19 Oct 2004 02:26:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJmhH-00082Q-3P; Tue, 19 Oct 2004 01:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJmRB-0004kP-1w for avt@megatron.ietf.org; Tue, 19 Oct 2004 01:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03597 for ; Tue, 19 Oct 2004 01:21:27 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJmdD-0003fr-NE for avt@ietf.org; Tue, 19 Oct 2004 01:34:01 -0400 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9J5LM3H010328 for ; Tue, 19 Oct 2004 00:21:24 -0500 (CDT) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2657.72) id <4Y5CKYQ7>; Tue, 19 Oct 2004 13:21:21 +0800 Message-ID: <31C0F08B0D18D511ACC800508BAE7B470BD4E052@CI0026EXCH001U> From: "Fan, Chen (Chen)" To: lavin.p@redpinesignals.com, Stephen Casner Subject: RE: [AVT] RTP SEND-RECV / Problem with linux 8.0 Sound. Date: Tue, 19 Oct 2004 13:21:21 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Lavin, Maybe you should try to use separate threads to handle send and receive. regards Chen -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of P Lavin Sent: Friday, October 15, 2004 4:24 PM To: Stephen Casner Cc: avt@ietf.org Subject: [AVT] RTP SEND-RECV / Problem with linux 8.0 Sound. Hi Steve, I've developed an RTP Stack. Now i'm doing the testing for the same. The stack is being tested on Linux 8.0, afterwords this will be ported to some RTOS... I've tested my stack with one SEND-Only session on one machine & RECV- Only session on other machine. It worked fine !!! I was able to communi- cate with the other endpoint using my stack(But a small delay was there). Now i'm testing SendRecv session (ie sending and receiving in single (or multiple) thread)(I'll be reading/writing to /dev/dsp inside a loop) The sequence of operations on single thread is given below, while(1) { //read from /dev/dsp. //Send this to n/w using RTP //recv data from RTP Stack. //Write this data to /dev/dsp } The problem lies here... In this progam i'm reciving the data frm remote session correctly...and i'm writing that data after receiving ... but after each write the my audio has a delay in palying the next packet... wt i'm trying to say is the data from the remote machine seems to be non-contineous. Where as when i tried with send-only & recv-only the real-time playback was contineous... I've opened the audio device using one of the files provided by vovida. I'm attatching that file. Sampling rate 44100Hz, 16Bits. Please help me with this issue... Thanks in Advance, Regards, P Lavin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 19 03:24:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25657 for ; Tue, 19 Oct 2004 03:24:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJoXj-0005xd-Cq for avt-archive@ietf.org; Tue, 19 Oct 2004 03:36:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJnov-0000zb-2j; Tue, 19 Oct 2004 02:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJnVA-0006SB-6r for avt@megatron.ietf.org; Tue, 19 Oct 2004 02:29:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22974 for ; Tue, 19 Oct 2004 02:29:37 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJngx-00053Y-I0 for avt@ietf.org; Tue, 19 Oct 2004 02:42:12 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9J6TKRU003709 for ; Tue, 19 Oct 2004 08:29:20 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 08:29:20 +0200 Received: from [147.214.34.59] (E-98B00806F3E64.ki.sw.ericsson.se [147.214.34.59]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V19NNHJ3; Tue, 19 Oct 2004 08:29:13 +0200 Message-ID: <4174B439.9030705@ericsson.com> Date: Tue, 19 Oct 2004 08:29:13 +0200 X-Sybari-Trust: 53d83a8c bfd556f1 986d9f48 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2004 06:29:20.0853 (UTC) FILETIME=[F7B84850:01C4B5A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Colin Perkins Subject: [AVT] AVT agenda time in Washington X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hi, Anyone desiring any agenda time during the AVT WG session as the 61th IETF meeting in Washington D.C. needs to submit a request for that time. All requests needs to be sent to the chairs before 24.00 CET on Monday the 25th of October. The request shall be sent to BOTH chairs. In the request include the following information: A. Presentation Title: B. Name of presenter: C. Draft Reference(s): D. Requested amount of time in minutes: Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 19 08:40:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18758 for ; Tue, 19 Oct 2004 08:40:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJtU2-0003cH-6L for avt-archive@ietf.org; Tue, 19 Oct 2004 08:52:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJski-0006XO-D3; Tue, 19 Oct 2004 08:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsPm-000357-2K; Tue, 19 Oct 2004 07:44:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13661; Tue, 19 Oct 2004 07:44:28 -0400 (EDT) Message-Id: <200410191144.HAA13661@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Oct 2004 07:44:28 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vmr-wb-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol (RTP) Payload Formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec Author(s) : S. Ahmadi Filename : draft-ietf-avt-rtp-vmr-wb-05.txt Pages : 29 Date : 2004-10-18 This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A MIME type registration is included for VMR-WB RTP payload formats. VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this draft to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vmr-wb-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-vmr-wb-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-vmr-wb-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-18172657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-vmr-wb-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-vmr-wb-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18172657.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Oct 19 08:46:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19081 for ; Tue, 19 Oct 2004 08:46:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJtZe-0003iK-JR for avt-archive@ietf.org; Tue, 19 Oct 2004 08:58:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJskk-0006Y1-V4; Tue, 19 Oct 2004 08:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsPq-00036X-Gx; Tue, 19 Oct 2004 07:44:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13680; Tue, 19 Oct 2004 07:44:33 -0400 (EDT) Message-Id: <200410191144.HAA13680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Oct 2004 07:44:33 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-vmr-wb-file-format-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Storage File Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec Author(s) : S. Ahmadi Filename : draft-ietf-avt-vmr-wb-file-format-00.txt Pages : 0 Date : 2004-10-18 This document specifies a file format for the storage of variable-rate multimode wideband (VMR-WB) speech codec. A MIME type registration is included for VMR-WB files. VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this draft to facilitate retrieval of VMR-WB stored data (generated in the interoperable mode) by AMR-WB decoder. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-vmr-wb-file-format-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-vmr-wb-file-format-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-vmr-wb-file-format-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-18172706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-vmr-wb-file-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-vmr-wb-file-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18172706.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Oct 20 11:55:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17039 for ; Wed, 20 Oct 2004 11:55:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJ0T-0003eA-D8 for avt-archive@ietf.org; Wed, 20 Oct 2004 12:08:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIA6-0000HA-FM; Wed, 20 Oct 2004 11:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHP8-0005Le-Il; Wed, 20 Oct 2004 10:25:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07762; Wed, 20 Oct 2004 10:25:28 -0400 (EDT) Message-Id: <200410201425.KAA07762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:25:27 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-amr-bis-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs Author(s) : J. Sjoberg, et al. Filename : draft-ietf-avt-rtp-amr-bis-00.txt Pages : 49 Date : 2004-10-19 This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-amr-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-amr-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104652.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Oct 20 11:59:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17347 for ; Wed, 20 Oct 2004 11:59:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJ4w-0003kO-JE for avt-archive@ietf.org; Wed, 20 Oct 2004 12:12:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIA9-0000HS-Rk; Wed, 20 Oct 2004 11:14:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHPJ-0005OY-0R; Wed, 20 Oct 2004 10:25:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07811; Wed, 20 Oct 2004 10:25:38 -0400 (EDT) Message-Id: <200410201425.KAA07811@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:25:38 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-variable-rate-audio-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Timestamp Frequency for Variable Rate Audio Codecs Author(s) : S. Wenger, C. Perkins Filename : draft-ietf-avt-variable-rate-audio-00.txt Pages : 6 Date : 2004-10-19 This memo discusses the problems of audio codecs with variable external sampling rates. Historically, for audio codecs, the RTP timestamp frequency was chosen to match the sampling rate of the audio codec. However, this choice is nowadays more difficult to justify, because of the advent of audio codecs (and, even more important, practical use cases) that support multiple sample rates and the switch between the sample rates during the lifetime of an RTP session. This Internet draft addresses the problem by suggesting that RTP Payload RFCs for such codecs to utilize a single, high, unified RTP timestamp frequency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-variable-rate-audio-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-variable-rate-audio-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-variable-rate-audio-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-variable-rate-audio-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-variable-rate-audio-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104657.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 21 08:51:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20276 for ; Thu, 21 Oct 2004 08:51:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcbi-0000oF-M9 for avt-archive@ietf.org; Thu, 21 Oct 2004 09:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbNj-0004gM-Lu; Thu, 21 Oct 2004 07:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKY4T-0005P4-Ki for avt@megatron.ietf.org; Thu, 21 Oct 2004 04:13:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20493 for ; Thu, 21 Oct 2004 04:13:10 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKYGx-0000wQ-9w for avt@ietf.org; Thu, 21 Oct 2004 04:26:12 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9L8D9RU008933 for ; Thu, 21 Oct 2004 10:13:09 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 10:13:09 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJRR10QD; Thu, 21 Oct 2004 10:13:09 +0200 Message-ID: <41776F95.5060206@ericsson.com> Date: Thu, 21 Oct 2004 10:13:09 +0200 X-Sybari-Trust: e48c2108 8cefd49f 00b34519 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: avt@ietf.org References: <200410201425.KAA07762@ietf.org> In-Reply-To: <200410201425.KAA07762@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2004 08:13:09.0673 (UTC) FILETIME=[CD364990:01C4B745] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Subject: [AVT] Re: I-D ACTION:draft-ietf-avt-rtp-amr-bis-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Hi, This draft is the start of updating the AMR and AMR-WB RTP payload to draft standard (RFC3267). Their is a detailed change section in the end of the draft which gives the different corrections applied, they are not that many. The major new thing is the Offer/Answer section which is an proposal for discussion. This version may not fully address all the comments that was raised in the earlier discussion, so please review it and give comments on it. Cheers Magnus 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 Working Group of > the IETF. > > Title : Real-Time Transport Protocol (RTP) Payload > Format and File > Storage Format for the Adaptive Multi-Rate > (AMR) and > Adaptive Multi-Rate Wideband (AMR-WB) Audio > Codecs > Author(s) : J. Sjoberg, et al. > Filename : draft-ietf-avt-rtp-amr-bis-00.txt > Pages : 49 > Date : 2004-10-19 > > This document specifies a real-time transport protocol (RTP) payload > format to be used for Adaptive Multi-Rate (AMR) and Adaptive > Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload > format is designed to be able to interoperate with existing AMR and > AMR-WB transport formats on non-IP networks. In addition, a file > format is specified for transport of AMR and AMR-WB speech data in > storage mode applications such as email. Two separate MIME type > registrations are included, one for AMR and one for AMR-WB, > specifying use of both the RTP payload format and the storage > format. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-bis-00.txt > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 21 12:50:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22189 for ; Thu, 21 Oct 2004 12:50:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgLM-00082v-Cy for avt-archive@ietf.org; Thu, 21 Oct 2004 13:03:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKg3r-0008Vq-Ke; Thu, 21 Oct 2004 12:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfo5-0001eD-C1 for avt@megatron.ietf.org; Thu, 21 Oct 2004 12:28:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19869 for ; Thu, 21 Oct 2004 12:28:50 -0400 (EDT) Received: from mail.8x8.com ([192.84.19.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKg0j-0007SX-IA for avt@ietf.org; Thu, 21 Oct 2004 12:41:58 -0400 Received: from [127.0.0.1] (mail [192.84.19.130]) by mail.8x8.com (Postfix) with ESMTP id 75B521E1AF; Thu, 21 Oct 2004 09:28:20 -0700 (PDT) Message-ID: <4177E3A4.8070303@8x8.com> Date: Thu, 21 Oct 2004 09:28:20 -0700 From: Jim Kleck User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Subject: [AVT] bandwidth feedback in draft-ietf-avt-rtcp-feedback-11.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: burmeister@panasonic.de, stewe@stewe.org, jo@tzi.org, rey@panasonic.de, sato652@oki.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit (resent to CC the draft authoers) Hi all, We have a SIP video conferencing application which operates over broadband. Typically our videophone is on a local network behind a router connected to a DSL or cable modem. When another device on the local network asynchronously starts using bandwidth, e.g. by doing an FTP, we experience either increasing latency as transmitted packets are buffered along the path and/or we experience dropped packets. Both of these conditions are detectable by using RTCP Sender Reports and Receiver Reports, but the question is: how far should our application reduce its transmit bandwidth? RTCP reports indicate number of lost packets or increasing latency, but due to the varying transmit bandwidth of the video (i.e. small bandwidth during periods of little motion, larger bandwidth during periods of large motion), this does not easily translate into how far to reduce the transmit bandwidth. The far end's receiver does, however, have the means to easily calculate both the sender's transmit bandwidth for a particular period (by comparing the two most recently received RTCP Sender Reports) and the actual received bandwidth for that comparable period (by comparing the time and the received byte count at the reception of those two RTCP Sender Reports). Note that the receive bandwidth alone is not sufficient because of the varying video bandwidth. So given these transmit and receive bandwidths, the difference is the amount by which the sender has overfilled the pipe. This difference is not exact because RTP/RTCP packets can get out of sequence, so the difference is only meaningful if it exceeds some threshold. Now all that is needed is a way for the receiver to communicate this difference back to the sender. This could certainly be done using an Application Layer Feedback Message but it is the receiver's RTP layer which processes the RTCP Sender Reports and Receiver Reports and which can calculate the bandwidth difference. This puts the feedback more in the Transport Layer area. However, the sender (i.e. the endpoint that receives the feedback) must pass the information up to the application, so maybe it belongs in the Application Layer area after all. But this kind of feedback seems of general use to me, possibly useful for many types of payload. It should thus be standardized and not left up the the applications nor put into the Payload Specific area. So, I propose a new transport layer feedback message with a single FCI field containing an unsigned 32 bit value. This FCI field would contain the bandwidth difference detected by the receiver. Upon receiving this feedback, the sender can then reduce its maximum transmit bandwidth by the difference. Thank you for your time, Jim Kleck 8x8, Inc _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 21 16:08:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15060 for ; Thu, 21 Oct 2004 16:08:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjQt-0005IH-Cj for avt-archive@ietf.org; Thu, 21 Oct 2004 16:21:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiu0-0000wO-Mh; Thu, 21 Oct 2004 15:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKigB-0006P1-IK; Thu, 21 Oct 2004 15:32:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10825; Thu, 21 Oct 2004 15:32:53 -0400 (EDT) Message-Id: <200410211932.PAA10825@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 15:32:53 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for ATRAC Family Author(s) : M. Romaine, et al. Filename : draft-ietf-avt-rtp-atrac-family-01.txt Pages : 22 Date : 2004-10-21 This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Codec (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document includes support for data fragmentation and elementary redundancy measures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-atrac-family-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-atrac-family-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-21154023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-atrac-family-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-atrac-family-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154023.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 21 21:05:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19232 for ; Thu, 21 Oct 2004 21:05:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKo53-0008DJ-8E for avt-archive@ietf.org; Thu, 21 Oct 2004 21:18:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlIu-0000js-EG; Thu, 21 Oct 2004 18:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjjb-0000eF-Df for avt@megatron.ietf.org; Thu, 21 Oct 2004 16:40:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22062 for ; Thu, 21 Oct 2004 16:40:28 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjwG-0007Xr-Uq for avt@ietf.org; Thu, 21 Oct 2004 16:53:38 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9LKdqj02382; Thu, 21 Oct 2004 16:39:52 -0400 (EDT) Received: from [47.9.16.95] (abrw002v.ca.nortel.com [47.9.16.95]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNPNLVC; Thu, 21 Oct 2004 16:39:52 -0400 Message-ID: <41781E97.9080706@nortelnetworks.com> Date: Thu, 21 Oct 2004 16:39:51 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kevin A. Noll" Subject: Re: [AVT] RFC2833 and 2833bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: schulzrinne@cs.columbia.edu, scott.petrack@edial.com, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Your recommendation is reasonable. I've added the text to the latest version of the draft (which I expect to submit tonight). Kevin A. Noll wrote: > Please forgive me if this has been a topic of discussion already, > but I have not been able to find any references to it... > > I am interested in understanding the correct handling of lost > packets in the context of RFC 2833 and draft-ietf-avt-rfc2833bis-04. > > I have not found any clear explanation for what a receiver should > do in the event that: > > 1. The "marker" at the beginning of an event is lost? > > Should the receiver: > a. ignore the entire event > b. assume that the marker was lost and playout the event per > the event messages that are received (i.e. non-marker and the > "end"). > > I would think that (b) would be the better choice. > > 2. Only the "end" flag is received? (This is only a variation on > item (1) above. > > > --kan-- > -- > Kevin A. Noll, KD4WOZ > CCIE 10948, CCDP > Perfect Order, Inc. > Kevin.Noll@perfectorder.com > 717-796-1936 > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 21 21:07:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19424 for ; Thu, 21 Oct 2004 21:07:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKo6m-0008GD-8y for avt-archive@ietf.org; Thu, 21 Oct 2004 21:20:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlIz-0000tT-Qs; Thu, 21 Oct 2004 18:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjlC-0001Gh-Bi for avt@megatron.ietf.org; Thu, 21 Oct 2004 16:42:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22377 for ; Thu, 21 Oct 2004 16:42:07 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjxs-0007ez-Rn for avt@ietf.org; Thu, 21 Oct 2004 16:55:17 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id i9LKj4Br027926 for ; Thu, 21 Oct 2004 13:45:04 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i9LKY6tD005047; Thu, 21 Oct 2004 15:34:07 -0500 Message-ID: <41781E80.6080400@motorola.com> Date: Thu, 21 Oct 2004 15:39:28 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-variable-rate-audio-00.txt References: <200410201425.KAA07811@ietf.org> In-Reply-To: <200410201425.KAA07811@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Hi, Stephan/Colin, I like this solution and the draft summaries the issue/benefits very well. ... > * Is it a good idea to require ALL future I-Ds on audio (not only > the variable clock frequency ones) to use the uRTR? > * Or only those that do not fit the uRTR (fit == subset of prime > factors)? ... Or, we can make uRTR a standard _option_ to all payloads - e.g., whenever rate param is set to 192kHz (or whatever value we end up with), it would mean that uRTR is in use, if rate is set to any other value, it implies that the actual sampling rate is in use. regards, -Qiaobing 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 Working Group of the IETF. > > Title : RTP Timestamp Frequency for Variable Rate Audio Codecs > Author(s) : S. Wenger, C. Perkins > Filename : draft-ietf-avt-variable-rate-audio-00.txt > Pages : 6 > Date : 2004-10-19 > > This memo discusses the problems of audio codecs with variable > external sampling rates. Historically, for audio codecs, the RTP > timestamp frequency was chosen to match the sampling rate of the > audio codec. However, this choice is nowadays more difficult to > justify, because of the advent of audio codecs (and, even more > important, practical use cases) that support multiple sample rates > and the switch between the sample rates during the lifetime of an > RTP session. This Internet draft addresses the problem by > suggesting that RTP Payload RFCs for such codecs to utilize a > single, high, unified RTP timestamp frequency. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-variable-rate-audio-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-avt-variable-rate-audio-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-avt-variable-rate-audio-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 21 21:35:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25704 for ; Thu, 21 Oct 2004 21:35:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoXW-0001O1-0i for avt-archive@ietf.org; Thu, 21 Oct 2004 21:48:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKnor-0003iA-FO; Thu, 21 Oct 2004 21:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlDp-0003z9-Fo; Thu, 21 Oct 2004 18:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12914; Thu, 21 Oct 2004 18:15:46 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKlQW-0005Ds-9e; Thu, 21 Oct 2004 18:28:56 -0400 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i9LMFd1U003946; Thu, 21 Oct 2004 15:15:39 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I5Y00ILWDPAI0@gateway2.EECS.Berkeley.EDU>; Thu, 21 Oct 2004 14:15:11 -0700 (PDT) Date: Thu, 21 Oct 2004 15:15:38 -0700 From: lazzaro In-reply-to: <4177691F.9090800@ericsson.com> To: Magnus Westerlund Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <75B73F9E-22BF-11D9-A6E7-00039372C384@eecs.berkeley.edu> <4177691F.9090800@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7BIT Cc: avt@ietf.org, mmusic@ietf.org Subject: [AVT] Re: [MMUSIC] maxptime X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7BIT On Oct 21, 2004, at 12:45 AM, Magnus Westerlund wrote: > Hi John, Hi Magnus! There are a few separable issues here, let's take them one by one ... CC'd to AVT since these issues cross boundaries ... > I think the usage of maxptime=0 may be a bit problematic. A > interpretation is that no audio can be included in the packet, as no > audio duration is allowed. > > I see that you have made another interpretation in the MIDI draft > (draft-ietf-avt-rtp-midi-format-06): > > "0 ms is a reasonable media time value for MIDI packets. In a packet > with a 0 ms media time, all commands execute at the instant coded by > the > packet timestamp. Prohibitions in [13] against 0 ms ptime values are > not relevant for MIDI streams, and may be ignored." > > An RTP timestamp tick is strictly not an instant, it has a duration > equal to 1/(RTP timestamp rate). > However these is my interpretation. Here's the underlying motivation for the choice I made. Imagine playing the piano. Play three notes simultaneously. In MIDI, this corresponds to three separate NoteOn commands. In RTP MIDI, each has a timestamp, expressed in RTP timestamp units. It's really important to the sonic integrity of the piece to code that the notes happen simultaneously -- even one RTP tick matters. The reason is, phase effects as the waveforms beat against each other change the timbre. Hand drummers on the list (conga, etc) can attest to this -- the art of creating certain timbres on those types of percussion instruments is based on fine timing of strokes on the drum with the two hands. Standard MIDI Files do in fact code true simultaneity, which is why they can be used in studio work. Musicians go crazy shifting around MIDI notes by tiny amounts inside the DAW to get this sort of stuff right, and SMFs preserve that hard work on export. Pull back from the nanosecond level to the few-millisecond level, and we move from timbre distortion to timing sloppiness. MIDI as transmitted on a MIDI 1.0 DIN cable suffers from this: at 300 microseconds/command, playing full chords with both hands creates timing slews you can hear. Part of the motivation to move off of MIDI DIN cable technology is to make instrument controllers that don't suffer this timing problem. You might ask -- why can't just put all simultaneous notes in the same packet, and use something other than RTP timestamps to denote intra-packet timing? To understand the answer, you need to understand that a core use of RTP MIDI is on "media LANs" -- a stage or studio situation that may consist of two nodes -- piano controller and laptop -- connected by an Ethernet cable as the Layer 2 for RTP MIDI. These folks want absolute lowest latency -- so, they don't want their piano controller to wait around after the first MIDI command to see if a second command that is "simultaneous" is happening soon. Instead, they want the piano to take each command, put it in its own RTP packet, and send it off. So, they want the ability to send two RTP packets in a row, each coding one MIDI command, each with the same RTP timestamp. To do this, they need the RTP timestamp semantics that say an RTP MIDI packet can have 0 ms media time. Some instrument makers use Ethernet today. They use their own UDP solutions (some use OSC on top of UDP) and have their own code. They want to add support for RTP MIDI, but RTP MIDI needs to work with their model, which is as I describe it above. I would also not be surprised if the recovery journal semantics failed if we moved to your RTP timestamp interpretation, although I'd have to think about to say for certain. Other things might break too. This is a 4-year-old project now, and the timestamp model is a fundamental assumption that underlies RTP MIDI in subtle ways. So, that's the reply to issue #1. Issue #2: > Is really your intention of using maxptime=0 that for each timestamp > tick there is a command(s), a new packet should be sent? I can > understand using ptime=0 to recommend that you do this behaviour but > using maxptime to enforce the behaviour? Yes. Once again, we're talking about apps in the "media network" world, a laptop and piano keyboard with a point-to-point 2-node Ethernet as the Layer 2 for RTP MIDI. The maxptime=0 parameter says: all packets must either code no MIDI commands, or code one or more MIDI commands with the same timestamp -- and thus, the media time for all packets must be 0 ms. This accommodates receivers (such as, currently, sfront!) that do not implement a receiver buffer of any sort. Instead, sfront grabs a packet, and executes all MIDI commands in the packet simultaneously. It relies on the constant nominal latency of the point-to-point Layer 2, and the constant nominal latency of the keyboard sender, for timing accuracy -- not RTP timestamps, which are ignored. Thus, these receivers can't handle a packet that has a non-zero media time -- all they know is "now". If one is designing receivers exclusively for use on media LANs as live performance instruments (in other words -- a musical instrument synthesizers intended to only be played locally), this "no buffer" model makes perfect sense -- it's how soft synths that are driven by MIDI 1.0 cables work today. Eventually, it would be better if these synths incorporated small configurable buffers to compensate for sub-ms jitter, but the conceptual hurdle to do so would be too great for many synth authors to do. In practice, OS APIs will probably implement those buffers if/when they choose to support RTP MIDI as a media LAN MIDI source. So, we need a way for those soft synths to negotiation (via Offer/Answer) to say "I can only handle 0 ms packets, do not send me any other kind". As an aside, RTP MIDI works fairly well Berkeley/Stanford/Berkeley using the no-buffer sfront -- it doesn't get down to the "hand percussion jitter" I mention above, but with a few coding heuristics it produces a playable instrument when I do loop-back (keyboard in Berkeley, RTP MIDI to Stanford and back, which sfront then turns into audio). Chris Chafe sees jitter under the audio sample rate on his DAT-quality long-distance streaming sessions on occassion! Issue #3 > Especially any that is primarily to handle Offer/Answer, where a > normative > MUST be larger than 0 is present. I think you should consider the > impact on interoperability. Well, the easiest thing to do is invent my own SDP parameter as an RTP MIDI replacement for maxptime -- this skirts the compatibility issue. But as I explained above, I think we have a legitimate need for the negotiating functionality. And I think the most elegant thing to do is for maxptime to bend its definition to include 0 ms, just for RTP MIDI, which is why I did it that way ... a compromise would be to put interoperability warning language into the RTP MIDI I-D, but keep the normative text as is. > So lets try to sort this out by answering some questions: > > - How big is the need to be able to specify ptime=0 and maxptime=0, > and what is the effect is the smallest one can use is ptime=1? Hopefully this is answered above. > - Do any implementers of generic SDP parsers have any problems with > ptime or maxptime equals 0? > > - Why does RFC 3264 have a normative MUST against using ptime=0? > > - Any further considerations? These questions seem aimed at others on the list ... however, I should note that I didn't take the route I did on maxptime lightly -- after several years of consensus building with the music technology community, the approach to RTP timing I outline above is the best way I can see to solve their problems. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 21 23:56:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09119 for ; Thu, 21 Oct 2004 23:56:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKqkQ-0004hK-Fy for avt-archive@ietf.org; Fri, 22 Oct 2004 00:09:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqSl-00075m-1K; Thu, 21 Oct 2004 23:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKqJE-00010O-9S for avt@megatron.ietf.org; Thu, 21 Oct 2004 23:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08084 for ; Thu, 21 Oct 2004 23:41:40 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKqVx-0004JL-64 for avt@ietf.org; Thu, 21 Oct 2004 23:54:53 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9M3f9v05616 for ; Thu, 21 Oct 2004 23:41:09 -0400 (EDT) Received: from [47.9.16.95] (abrw002v.ca.nortel.com [47.9.16.95]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SPNPNMRJ; Thu, 21 Oct 2004 23:41:09 -0400 Message-ID: <41788154.7090908@nortelnetworks.com> Date: Thu, 21 Oct 2004 23:41:08 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [AVT] draft-ietf-avt-rfc2833bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit I have just submitted the latest update to RFC2833bis. I'll be glad to mail an advance copy to anyone who wants one. The list of changes from the previous version is given below. The draft now includes a paragraph by paragraph analysis of the changes from RFC 2833, including an assessment of the normative impact of each change. All I can say is that there have been a lot of normative changes. I will be pointing at some that are non-backwards compatible when I describe outstanding issues. I hope the analysis is useful to those of you who are interested parties. Changes In The -05 Version - Added a complete accounting for the changes from RFC 2833. - Added a backward compatibility provision in 2.5.1.1. - Deleted second paragraph of 2.5.2.2 because it also appears in section 5.2. - Added text to 2.5.2.2 regarding missed initial event report based on suggestions by Kevin Noll - Deleted redundant text in the middle of the third paragraph of section 3.1. - Added a note to the "980 or 1180 Hz" outcome for V.18 in section 3.2.6 indicating that the distinction between 110 and 300 bit/s V.21 is very difficult, based on discussions with Gunnar Hellstrom. - Added the Metering Pulse event to Table 10 and new section 3.5.7 to document it, as requested by Adrian Soncodi. - Transposed Table 14 to fix the assignment of R2 backward register signals to frequencies. The error was pointed out by Oren Peleg, Moshe Samoha, and Yaakov Stein. - Corrected the statement before Table 7 (V.18 event codepoints) to indicate that all V.18 codepoints are new since RFC 2833. - Editorial fixes (mostly correction of cross-references). Fixed duplicate section number for 2.5.2.3. - Updated boilerplate to meet current requirements. - Added the current editor (me) as an author and the people mentioned above as contributors. -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 22 05:03:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13996 for ; Fri, 22 Oct 2004 05:03:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKvXR-0001Ul-Hn for avt-archive@ietf.org; Fri, 22 Oct 2004 05:16:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvID-0002Tq-S7; Fri, 22 Oct 2004 05:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhoq-0006Iy-Np for avt@megatron.ietf.org; Thu, 21 Oct 2004 14:37:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04179 for ; Thu, 21 Oct 2004 14:37:46 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKi1V-0002s7-Bk for avt@IETF.ORG; Thu, 21 Oct 2004 14:50:54 -0400 Received: from [129.46.74.110] ([129.46.74.110]) by warlock.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id i9LIb3sc007542; Thu, 21 Oct 2004 11:37:06 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <299151A395F20F4BA29A6CC22C1F3A6F011C08E7@esealmw111> References: <299151A395F20F4BA29A6CC22C1F3A6F011C08E7@esealmw111> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora for safety: Date: Thu, 21 Oct 2004 11:33:57 -0700 To: Per =?iso-8859-1?Q?Fr=F6jdh?= (KI/EAB) , "'mankin@psg.com'" , "'randy@qualcomm.com'" , "'avt@ietf.org'" , 3GPP_TSG_SA_WG4@list.etsi.org From: Randall Gellens Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1113738670==_============" X-Random-Sig-Tag: 1.0b27 X-Spam-Score: 1.0 (+) X-Scan-Signature: 8353da2fde044920180672209f5bf8a0 X-Mailman-Approved-At: Fri, 22 Oct 2004 05:00:59 -0400 Cc: "Magnus Westerlund \(KI/EAB\)" , "'hgarudad@QUALCOMM.COM'" , "'Dave Singer'" Subject: [AVT] Re: Comments on the codecs parameter for bucket media types (file for mats) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 0c3d807a9e67fb2ae2b97f891ffd2e4e --============_-1113738670==_============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 4:41 PM +0200 10/1/04, Per Fr=F6jdh (KI/EAB) wrote: > Dear all, > > We at Ericsson have reviewed the Internet Draft=20 > =B4The Codecs Parameter for "Bucket" Media Types=B4 > http://www.ietf.org/internet-drafts/draft-gellens-mime-bucket-00.txt > and identified some issues. Thank you for the detailed review and discussion.=20 Please see below for in-line responses. > > The ID addresses the need to specify codecs=20 > contained in a "bucket" file by adding a=20 > parameter to its MIME type (which by itself=20 > gives no details on which codecs the file=20 > contains). However, the information conveyed in=20 > the proposed codec parameter is currently=20 > limited and gives the (false) impression that=20 > it would provide a client enough details to=20 > decide whether it can render the content of the=20 > corresponding file. > > Our major concerns are the following: > > 1) Scope of the ID > > The ID states generally that it targets bucket=20 > media types, but the design is only explicit=20 > for file formats that are based on the ISO Base=20 > Media File Format (including the MP4, 3GP and=20 > 3G2 file formats). The values of the codec=20 > parameters only mention such code points (as=20 > registered by the MP4 registration authority)=20 > and it is not clear how this would apply to any=20 > other file formats or bucket media types. > > One option to resolve the issue would be to=20 > explicitly state that the ID is only intended=20 > for file formats in the "ISO family". However,=20 > some work would still be needed to serve this=20 > purpose (see below). > > A better alternative would be to address bucket=20 > media types in general, but then remove ISO=20 > specific details and make a general framework=20 > that can be used for all files (bucket media=20 > types). Such a framework could specify the=20 > general syntax of the codecs parameter. Each=20 > media type that would use the parameter would=20 > then define the semantics (list entries) that=20 > are applicable to that particular media type. This is the approach taken in the most recent=20 revision of this document, a draft of which I am=20 attaching. Please see especially Section 3 ("The=20 Codecs Parameter") for the updated text and ABNF. > > > 2) Incomplete differentiation of codecs > > The codecs parameter takes MP4 code points=20 > (sample entry character codes) as its main=20 > values to identify codecs. The main problem=20 > with this is that it does not provide a=20 > sufficent description of the codec: > > a) For codecs that use the MP4 file format=20 > entries (mp4v and mp4a) the proposal includes=20 > an MPEG-4 systems object type indication to=20 > further specify the codec. However, it is still=20 > not clear how to distinguish AAC-LC from=20 > AAC-LTP (both used by 3GPP) as this information=20 > is carried by the Audio object type in the=20 > decoder specific information (and not by the=20 > MPEG-4 systems object type). Similar problems=20 > may arise for ACCplus or Enhanced AACplus(?). > > b) For codecs that are not signalled using=20 > MPEG-4 systems object type there are also=20 > problems. 3GPP uses both H.263 Profile 0=20 > (Baseline) and H.263 Profile 3, but these=20 > codecs cannot be distinguished by the MP4 code=20 > point (s263). A quick solution may be to define=20 > extended list entries, e.g., s263.P0 and=20 > s263.P3, but considerable care must then be=20 > taken to cover all cases and codecs that may be=20 > interesting. Keeping track of such entries=20 > would also be outside the scope of the MP4=20 > registration authority. If we go this route, I would think that the=20 extended entries would be the responsibility of=20 the owner of the MIME type. An initial list of=20 such could be included in the document for types=20 in its initial scope. > > Instead of using the MP4 code points (and=20 > define extensions that would cover the=20 > information not carried by them) it would be=20 > straightforward to define the relevant entries=20 > for a given bucket media type. The owner of the=20 > media type would then naturally serve as the=20 > "registration authority" for its entries. 3GPP=20 > can keep a list of the relevant entries for 3GP=20 > files and 3GPP2 one for 3G2 files. Also=20 > profiles and levels can be included in the list=20 > of such entries. This could also be a workable solution, but we=20 would need to be careful to list all needed=20 entries. Do any of the others on the=20 distribution list have comments on these=20 approaches? > > > 3) Codecs information not enough > > One "risk" of introducing the codecs parameter=20 > is that it may be perceived as the only=20 > description of the file. Certainly that is not the intent. The goal is to=20 allow Internet-connected hosts which may receive,=20 relay, or process files containing "bucket" MIME=20 types to determine if all required codecs are=20 present in the target resource without needing to=20 parse the media itself. The draft does attempt=20 to make this clear, but of course suggestions for=20 improved working are always welcome. > The ID states that it "adds a parameter to=20 > allow unambiguous specification of the codecs=20 > required to render the content in a media=20 > element". However, even if the codec=20 > information is made more detailed, it is still=20 > possible that some codecs may be required=20 > whereas some may be optionally used. This and=20 > other aspects of a file in the ISO family is=20 > currently carried by the file type box of a=20 > file. By only singling out codecs, we don't=20 > think you get an adequate descripton of the=20 > file. > > The file type box of an ISO file includes a=20 > major brand ("best use") and compatible brands.=20 > It may tell you that a file is "best" played by=20 > a 3GPP release-5 terminal, although it is=20 > compatible with release-4 terminals. This may=20 > be the case if the content creator included=20 > timed text (introduced in release 5), but does=20 > not require terminals to display the text.=20 > Hence, if a file contains a codec, it's not=20 > always required that the receiving terminal=20 > supports it. The intent here is to be able to specify the=20 codecs that are required. In the example you=20 cite, I'd be inclined to leave it up to the=20 originator of the media to determine if a=20 particular codec should be listed or not, that=20 is, to determine how essential a given codec is. > If the codecs parameter is introduced, in one=20 > form or another, it should be made clear that=20 > it only gives partial information of the=20 > requirements of an end device. One option to=20 > make the description more complete for an ISO=20 > file would be to "lift" the file type=20 > information into a second MIME parameter for=20 > brand and compatible brands, although this=20 > would imply some level of redundancy. If this would be helpful to the underlying goal=20 I'd be happy to assist in such efforts. > > > In summary, > > a) the details specified for files in the ISO=20 > family (MP4, 3GP, 3G2, etc) are not enough for=20 > differentiating codecs; > b) we propose to have a general syntax for the=20 > bucket parameter defined in IETF, but keep the=20 > details to each organisation defining a file=20 > format that would use this parameter. > > Best regards, > > Per Fr=F6jdh, editor of the 3GPP file format (3GPP TS 26.244) > > ---------------------------------------------------------------- > Per Fr=F6jdh, Ph.D. Tel +46 8 4048188 > Ericsson Research, Multimedia Technologies Mob +46 730312413 > > > > > -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Democracy is a form of government that substitutes election by the incompetent many for appointment by the corrupt few. --G. B. Shaw --============_-1113738670==_============ Content-Id: Content-Type: application/octet-stream; name="draft-gellens-mime-bucket-01a.txt" Content-Disposition: attachment; filename="draft-gellens-mime-bucket-01a.txt" Content-Transfer-Encoding: base64 CgpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUi4gR2VsbGVucwpEb2N1bWVudDogZHJhZnQtZ2VsbGVucy1taW1l LWJ1Y2tldC0wMS50eHQgICAgICAgICAgICAgICAgICAgICBRdWFsY29tbQpFeHBpcmVz OiBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE9jdG9iZXIgMjAwNAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAoKICAgICAgICAgICAgIFRoZSBDb2RlY3MgUGFy YW1ldGVyIGZvciAiQnVja2V0IiBNZWRpYSBUeXBlcwogICAgClN0YXR1cyBvZiB0aGlz IE1lbW8KICAgIAogICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBJ IGNlcnRpZnkgdGhhdCBhbnkgYXBwbGljYWJsZQogICAgcGF0ZW50IG9yIG90aGVyIElQ UiBjbGFpbXMgb2Ygd2hpY2ggSSBhbSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xvc2VkCiAg ICBhbmQgYW55IG9mIHdoaWNoIEkgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2Vk LCBpbiBhY2NvcmRhbmNlCiAgICB3aXRoIFJGQyAzNjY4IChCQ1AgNzkpLgogICAgCiAg ICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIEkgYWNjZXB0IHRoZSBw cm92aXNpb25zIG9mCiAgICBTZWN0aW9uIDMgb2YgUkZDIDM2NjcgKEJDUCA3OCkuCiAg ICAKICAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhl IEludGVybmV0IEVuZ2luZWVyaW5nCiAgICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0CiAgICBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC0KICAgIERyYWZ0cy4KICAgIAogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgKICAgIG1vbnRocyBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzCiAgICBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8g dXNlIEludGVybmV0LURyYWZ0cyBhcwogICAgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKICAgIAog ICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vz c2VkIGF0CiAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50 eHQgVGhlIGxpc3Qgb2YKICAgIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rvcmll cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93 Lmh0bWwuCiAgICAKICAgIApDb3B5cmlnaHQgTm90aWNlCiAgICAKICAgIENvcHlyaWdo dCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLiAgQWxsIFJpZ2h0cyBSZXNl cnZlZC4KICAgIAogICAgCkFic3RyYWN0CiAgICAKICAgIFNldmVyYWwgTUlNRSB0eXBl L3N1YnR5cGUgY29tYmluYXRpb25zIGV4aXN0IHdoaWNoIGNhbiBjb250YWluCiAgICBk aWZmZXJlbnQgbWVkaWEgZm9ybWF0cy4gIEEgcmVjZWl2aW5nIGFnZW50IHRodXMgbmVl ZHMgdG8gZXhhbWluZQogICAgdGhlIGRldGFpbHMgb2Ygc3VjaCBtZWRpYSBjb250ZW50 IHRvIGRldGVybWluZSBpZiB0aGUgc3BlY2lmaWMKICAgIGVsZW1lbnRzIGNhbiBiZSBy ZW5kZXJlZCBnaXZlbiBhbiBhdmFpbGFibGUgc2V0IG9mIGNvZGVjcy4KICAgIEVzcGVj aWFsbHkgd2hlbiB0aGUgZW5kIHN5c3RlbSBoYXMgbGltaXRlZCByZXNvdXJjZXMsIG9y IHRoZQogICAgY29ubmVjdGlvbiB0byB0aGUgZW5kIHN5c3RlbSBoYXMgbGltaXRlZCBi YW5kd2lkdGgsIGl0IHdvdWxkIGJlCiAgICBoZWxwZnVsIHRvIGtub3cgZnJvbSB0aGUg Q29udGVudC1UeXBlIGFsb25lIGlmIHRoZSBjb250ZW50IGNhbiBiZQogICAgcmVuZGVy ZWQuCiAgICAKCgoKR2VsbGVucyAgICAgICAgICAgICAgICAgICBbUGFnZSAxXSAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDIwMDUKDApJbnRlcm5ldCBEcmFmdCAg ICAgICAgICAgICBUaGUgQ29kZWNzIFBhcmFtZXRlciAgICAgICAgICAgICBPY3RvYmVy IDIwMDQKCgogICAgVGhpcyBkb2N1bWVudCBhZGRzIGEgbmV3IHBhcmFtZXRlciwgImNv ZGVjcyIsIHRvIHZhcmlvdXMKICAgIHR5cGUvc3VidHlwZSBjb21iaW5hdGlvbnMgdG8g YWxsb3cgZm9yIHVuYW1iaWd1b3VzIHNwZWNpZmljYXRpb24gb2YKICAgIHRoZSBjb2Rl Y3MgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgbWVkaWEgZm9ybWF0cyBjb250YWluZWQg d2l0aGluLgogICAgCiAgICBCeSBsYWJlbGxpbmcgY29udGVudCB3aXRoIHRoZSBzcGVj aWZpYyBjb2RlY3MgcmVxdWlyZWQgdG8gcmVuZGVyIHRoZQogICAgY29udGFpbmVkIG1l ZGlhLCByZWNlaXZpbmcgc3lzdGVtcyBjYW4gZGV0ZXJtaW5lIGlmIHRoZSBjb2RlY3Mg YXJlCiAgICBzdXBwb3J0ZWQgYnkgdGhlIGVuZCBzeXN0ZW0sIGFuZCBpZiBub3QsIGNh biB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbgogICAgKHN1Y2ggYXMgcmVqZWN0aW5nIHRo ZSBjb250ZW50LCBzZW5kaW5nIG5vdGlmaWNhdGlvbiBvZiB0aGUKICAgIHNpdHVhdGlv biwgdHJhbnNjb2RpbmcgdGhlIGNvbnRlbnQgdG8gYSBzdXBwb3J0ZWQgdHlwZSwgZmV0 Y2hpbmcgYW5kCiAgICBpbnN0YWxsaW5nIHRoZSByZXF1aXJlZCBjb2RlY3MsIGV0Yy4p CiAgICAKICAgIAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpH ZWxsZW5zICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgQXByaWwgMjAwNQoMCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIFRo ZSBDb2RlY3MgUGFyYW1ldGVyICAgICAgICAgICAgIE9jdG9iZXIgMjAwNAoKClRhYmxl IG9mIENvbnRlbnRzCiAgICAKICAgICAxLiAgQ29udmVudGlvbnMgVXNlZCBpbiB0aGlz IERvY3VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMi4gIElu dHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgMwogICAgIDMuICBUaGUgQ29kZWNzIFBhcmFtZXRlciAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICA0LiAgRXhhbXBsZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA3CiAgICAgNS4gIEFkZGl0aW9uYWwgTWVkaWEgRmVhdHVyZSBEZXRhaWxzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDYuICBJQU5BIENvbnNpZGVyYXRp b25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAg ICA3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA3CiAgICAgOC4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgIDkuICBO b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDgKICAgIDEwLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAxMS4gIEF1dGhvcidz IEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQogICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgICAgIEZ1bGwgQ29weXJpZ2h0IFN0 YXRlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAg ICAgICBEaXNjbGFpbWVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMAogICAgCiAgICAKMS4gIENvbnZlbnRpb25zIFVzZWQg aW4gdGhpcyBEb2N1bWVudAogICAgCiAgICBUaGUga2V5IHdvcmRzICJSRVFVSVJFRCIs ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQKICAgIE5PVCIsIGFu ZCAiTUFZIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBk ZXNjcmliZWQKICAgIGluICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlIFJlcXVpcmVtZW50IExldmVscyIKICAgIFtLRVlXT1JEU10uCiAgICAKICAgIAoy LiAgSW50cm9kdWN0aW9uCiAgICAKICAgIE9uZSBvZiB0aGUgb3JpZ2luYWwgbW90aXZh dGlvbnMgZm9yIE1JTUUgaXMgdGhlIGFiaWxpdHkgdG8gaWRlbnRpZnkKICAgIHRoZSBz cGVjaWZpYyBtZWRpYSB0eXBlIG9mIGEgbWVzc2FnZSBwYXJ0LiAgSG93ZXZlciwgZHVl IHRvIHZhcmlvdXMKICAgIGZhY3RvcnMsIGl0IGlzIG5vdCBhbHdheXMgcG9zc2libGUg ZnJvbSBsb29raW5nIGF0IHRoZSBNSU1FIHR5cGUgYW5kCiAgICBzdWJ0eXBlIHRvIGtu b3cgd2hpY2ggc3BlY2lmaWMgbWVkaWEgZm9ybWF0cyBhcmUgY29udGFpbmVkIGluIHRo ZQogICAgYm9keSBwYXJ0LCBvciB3aGljaCBjb2RlY3MgYXJlIHJlcXVpcmVkIGluIG9y ZGVyIHRvIGRpc3BsYXkgdGhlCiAgICBjb250ZW50LgogICAgCiAgICBUaGVyZSBhcmUg c2V2ZXJhbCBtZWRpYSB0eXBlL3N1YnR5cGVzIChlaXRoZXIgY3VycmVudGx5IHJlZ2lz dGVyZWQKICAgIG9yIGRlcGxveWVkIHdpdGggcmVnaXN0cmF0aW9uIHBlbmRpbmcpIHdo aWNoIG1heSBjb250YWluIGNvZGVjcwogICAgY2hvc2VuIGZyb20gYSBzZXQuICBJdCBp cyBjdXJyZW50bHkgbmVjZXNzYXJ5IHRvIGV4YW1pbmUgZWFjaCBtZWRpYQogICAgZWxl bWVudCBpbiBvcmRlciB0byBkZXRlcm1pbmUgdGhlIGNvZGVjcyByZXF1aXJlZCB0byBy ZW5kZXIgdGhlCiAgICBjb250ZW50LiAgRm9yIGV4YW1wbGUsIHZpZGVvLzNncHAgbWF5 IGNvbnRhaW4gYW55IG9mIHRoZSB2aWRlbwogICAgZm9ybWF0cyBILjI2MywgSC4yNjMr LCBILjI2NCwgTVBFRy00IFNQTDAsIGFuZC9vciBhbnkgb2YgdGhlIGF1ZGlvCiAgICBm b3JtYXRzIEFNUiwgQU1SLVdCLCBvciBBQUMsIGFzIHNwZWNpZmllZCBpbiBbM0dQUC1G b3JtYXRzXS4KICAgIAoKCgoKCgoKCkdlbGxlbnMgICAgICAgICAgICAgICAgICAgW1Bh Z2UgM10gICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMDA1CgwKSW50ZXJu ZXQgRHJhZnQgICAgICAgICAgICAgVGhlIENvZGVjcyBQYXJhbWV0ZXIgICAgICAgICAg ICAgT2N0b2JlciAyMDA0CgoKICAgIEluIHNvbWUgY2FzZXMsIHRoZSBzcGVjaWZpYyBj b2RlY3MgY2FuIGJlIGRldGVybWluZWQgYnkgZXhhbWluaW5nCiAgICB0aGUgaGVhZGVy IGluZm9ybWF0aW9uIG9mIHRoZSBtZWRpYSBjb250ZW50LiAgV2hpbGUgdGhpcyBpc24n dCBhcwogICAgYmFkIGFzIGV4YW1pbmluZyB0aGUgZW50aXJlIGNvbnRlbnQsIGl0IHN0 aWxsIHJlcXVpcmVzIHNwZWNpYWxpemVkCiAgICBrbm93bGVkZ2Ugb2YgZWFjaCBmb3Jt YXQgYW5kIGlzIHJlc291cmNlIGNvbnN1bXB0aXZlLgogICAgCiAgICBUaGlzIGFtYmln dWl0eSBjYW4gYmUgYSBwcm9ibGVtIGZvciB2YXJpb3VzIGNsaWVudHMgYW5kIHNlcnZl cnMuICBJdAogICAgcHJlc2VudHMgYSBzaWduaWZpY2FudCBidXJkZW4gdG8gTXVsdGlt ZWRpYSBNZXNzYWdpbmcgKE1NUykgc2VydmVycywKICAgIHdoaWNoIG11c3QgZXhhbWlu ZSB0aGUgbWVkaWEgc2VudCBpbiBlYWNoIG1lc3NhZ2UgaW4gb3JkZXIgdG8KICAgIGRl dGVybWluZSB3aGljaCBjb2RlY3MgYXJlIHJlcXVpcmVkIHRvIHJlbmRlciB0aGUgY29u dGVudC4gIE9ubHkKICAgIHRoZW4gY2FuIGl0IGRldGVybWluZSBpZiB0aGUgY29udGVu dCByZXF1aXJlcyB0cmFuc2NvZGluZyBvcgogICAgc3BlY2lhbGl6ZWQgaGFuZGxpbmcg cHJpb3IgdG8gYmVpbmcgdHJhbnNtaXR0ZWQgdG8gdGhlIGhhbmRzZXQuCiAgICAKICAg IEFkZGl0aW9uYWxseSwgaXQgcHJlc2VudHMgYSBjaGFsbGVuZ2UgdG8gc21hcnQgY2xp ZW50cyBvbiBkZXZpY2VzCiAgICB3aXRoIGNvbnN0cmFpbmVkIG1lbW9yeSwgcHJvY2Vz c2luZyBwb3dlciwgb3IgdHJhbnNtaXNzaW9uIGJhbmR3aWR0aAogICAgKHN1Y2ggYXMg Y2VsbHVsYXIgdGVsZXBob25lcyBhbmQgUERBcykuICBTdWNoIGNsaWVudHMgb2Z0ZW4g bmVlZCB0bwogICAgZGV0ZXJtaW5lIGluIGFkdmFuY2UgaWYgdGhleSBhcmUgY3VycmVu dGx5IGNhcGFibGUgb2YgcmVuZGVyaW5nIHRoZQogICAgY29udGVudCBjb250YWluZWQg aW4gYW4gTU1TIG9yIGVtYWlsIG1lc3NhZ2UuCiAgICAKICAgIFNwZWNpZmljYWxseSwK ICAgIAogICAgbyAgICBhdWRpby8zZ3BwIGNhbiBjb250YWluIEFNUiBvciBBQUMgY29u dGVudHMgYXMgc3BlY2lmaWVkIGluCiAgICBbM0dQUC1Gb3JtYXRzXS4KICAgIG8gICBh dWRpby8zZ3BwMiBjYW4gY29udGFpbiBBTVIsIEFBQywgMTNLIChhcyBwZXIgWzEza10p LCBFVlJDLCBvcgogICAgICAgIFNNViwgYXMgc3BlY2lmaWVkIGluIFszR1BQMi1Gb3Jt YXRzXSAodmlkZW8vM2dwcDIgTUlNRQogICAgICAgIHJlZ2lzdHJhdGlvbiBwZW5kaW5n KS4KICAgIG8gICB2aWRlby8zZ3BwIGNhbiBjb250YWluIEguMjYzLCBILjI2MyssIEgu MjY0LCBNUEVHLTQgU1BMMCwgYW5kL29yCiAgICAgICAgQU1SLCBBTVItV0IsIG9yIEFB QywgYXMgc3BlY2lmaWVkIGluIFszR1BQLUZvcm1hdHNdLgogICAgbyAgIHZpZGVvLzNn cHAyIGNhbiBjb250YWluIEguMjYzLCBILjI2MyssIEguMjY0LCBNUEVHLTQgU1BMMCwK ICAgICAgICBhbmQvb3IgQU1SLCBBQUMsIDEzSyAoYXMgcGVyIFsxM2tdKSwgRVZSQywg b3IgU01WLCBhcyBzcGVjaWZpZWQKICAgICAgICBpbiBbM0dQUDItRm9ybWF0c10gKHZp ZGVvLzNncHAyIE1JTUUgcmVnaXN0cmF0aW9uIHBlbmRpbmcpLgogICAgICAgIAogICAg Tm90ZSB0aGF0IHRoZXJlIGFyZSBhZGRpdGlvbmFsIG1lZGlhIHR5cGVzIHdoaWNoIGFy ZSBhbWJpZ3VvdXMsIGJ1dAogICAgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQsIGluY2x1ZGluZzoKICAgIG8gICB2aWRlby9tcDRWLUVTIGFuZCB2aWRl by9tcGVnNC1nZW5lcmljIHdoaWNoIGNhbiBjb250YWluIGFueXRoaW5nCiAgICAgICAg YWxsb3dlZCBieSB0aGUgTVBFRy00IHNwZWNpZmljYXRpb24sIG9yIGFueSBhdWRpbyBj b2RlYwogICAgICAgIHJlZ2lzdGVyZWQgd2l0aCB0aGUgTVA0IHJlZ2lzdHJhdGlvbiBh dXRob3JpdHkgW01QNC1SZWddLgogICAgbyAgIHZpZGVvL3F1aWNrdGltZSB3aGljaCBj YW4gY29udGFpbiBhbnl0aGluZyBmb3Igd2hpY2ggdGhlcmUgaXMgYQogICAgICAgIFF1 aWNrVGltZSBjb2RlYyBjb21wb25lbnQ7IHNpbmNlIFF1aWNrVGltZSBpcyBleHRlbnNp YmxlLCB0aGlzCiAgICAgICAgaXMgbm90IGxpbWl0ZWQgdG8gdGhlIGNvZGVjcyB0aGF0 IGFyZSBvciBoYXZlIGJlZW4gc2hpcHBlZCBieQogICAgICAgIEFwcGxlIENvbXB1dGVy LgogICAgICAgIAogICAgV2l0aCBlYWNoICJidWNrZXQiIHR5cGUsIGEgcmVjZWl2aW5n IGFnZW50IG9ubHkga25vd3MgdGhhdCBpdCBoYXMgYQogICAgY29udGFpbmVyIGZvcm1h dC4gIEl0IGRvZXNuJ3QgZXZlbiBrbm93IHdoZXRoZXIgY29udGVudCBsYWJlbGxlZAog ICAgdmlkZW8vM0dQUCBvciB2aWRlby8zR1BQMiBjb250YWlucyB2aWRlbzsgaXQgbWln aHQgYmUgYXVkaW8gb25seSwKICAgIGF1ZGlvIGFuZCB2aWRlbywgb3IgdmlkZW8gb25s eS4KICAgIAoKCgoKCkdlbGxlbnMgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMDA1CgwKSW50ZXJuZXQgRHJhZnQg ICAgICAgICAgICAgVGhlIENvZGVjcyBQYXJhbWV0ZXIgICAgICAgICAgICAgT2N0b2Jl ciAyMDA0CgoKICAgIEEgc29sdXRpb24gd2hpY2ggcGVybWl0cyBhIHJlY2VpdmluZyBh Z2VudCB0byBkZXRlcm1pbmUgdGhlIHNwZWNpZmljCiAgICBjb2RlY3MgcmVxdWlyZWQg dG8gcmVuZGVyIG1lZGlhIGNvbnRlbnQgd291bGQgaGVscCBwcm92aWRlIGVmZmljaWVu dAogICAgYW5kIHNjYWxhYmxlIHNlcnZlcnMsIGVzcGVjaWFsbHkgZm9yIE11bHRpbWVk aWEgTWVzc2FnaW5nIChNTVMpLCBhbmQKICAgIGFpZCB0aGUgZ3Jvd3RoIG9mIG11bHRp bWVkaWEgc2VydmljZXMgaW4gd2lyZWxlc3MgbmV0d29ya3MuCiAgICAKICAgIAozLiAg VGhlIENvZGVjcyBQYXJhbWV0ZXIKICAgIAogICAgVGhpcyBkb2N1bWVudCBhZGRzIGEg cGFyYW1ldGVyIHRvIGFsbG93IHVuYW1iaWd1b3VzIHNwZWNpZmljYXRpb24gb2YKICAg IHRoZSBjb2RlY3MgcmVxdWlyZWQgdG8gcmVuZGVyIHRoZSBjb250ZW50IGluIGEgbWVk aWEgZWxlbWVudC4gIFRoaXMKICAgIHBhcmFtZXRlciBpcyBvcHRpb25hbCBpbiBhbGwg Y3VycmVudCB0eXBlcyB0byB3aGljaCBpdCBpcyBhZGRlZC4KICAgIEZ1dHVyZSB0eXBl cyB3aGljaCBjb250YWluIGFtYmlndWl0eSBhcmUgc3Ryb25nbHkgZW5jb3VyYWdlZCB0 bwogICAgaW5jbHVkZSB0aGlzIHBhcmFtZXRlciwgYXMgbWFuZGF0b3J5IGlmIHBvc3Np YmxlLCBhcyBvcHRpb25hbAogICAgb3RoZXJ3aXNlLgogICAgCiAgICBNZWRpYSB0eXBl czoKICAgICAgICBhdWRpby8zZ3BwLAogICAgICAgIGF1ZGlvLzNncHAyKiwKICAgICAg ICB2aWRlby8zZ3BwLAogICAgICAgIHZpZGVvLzNncHAyKiwKICAgICAgICAKICAgICAg ICAqcmVnaXN0cmF0aW9uIHBlbmRpbmcKICAgIAogICAgUGFyYW1ldGVyIG5hbWU6CiAg ICAgICAgQ29kZWNzCiAgICAKICAgIFBhcmFtZXRlciB2YWx1ZToKICAgICAgICBBIHNp bmdsZSB2YWx1ZSwgb3IgYSBjb21tYS1zZXBhcmF0ZWQgbGlzdCBvZiB2YWx1ZXMgKHdo aWNoIG11c3QKICAgICAgICBiZSBlbmNsb3NlZCBpbiBxdW90ZXMgdG8gY29tcGx5IHdp dGggTUlNRSBydWxlcykgd2hpY2gKICAgICAgICBpZGVudGlmaWVzIHRoZSBjb2RlYyhz KSByZXF1aXJlZCB0byByZW5kZXIgdGhlIGNvbnRlbnQgaW4gdGhlCiAgICAgICAgYm9k eSBwYXJ0LgogICAgICAgIAogICAgICAgIEVhY2ggdmFsdWUgY29uc2lzdHMgb2Ygb25l IG9yIG1vcmUgZG90LXNlcGFyYXRlZCBlbGVtZW50cy4gIFRoZQogICAgICAgIG5hbWUg c3BhY2UgZm9yIHRoZSBmaXJzdCBlbGVtZW50IGlzIGRldGVybWluZWQgYnkgdGhlIE1J TUUgdHlwZS4KICAgICAgICBUaGUgbmFtZSBzcGFjZSBmb3IgZWFjaCBzdWJzZXF1ZW50 IGVsZW1lbnQgaXMgZGV0ZXJtaW5lZCBieSB0aGUKICAgICAgICBwcmVjZWRpbmcgZWxl bWVudC4KICAgICAgICAKICAgICAgICBFeGFtcGxlcyBvZiBHZW5lcmljIFN5bnRheDoK ICAgICAgICAgICAgYS5iYi5jLmQKICAgICAgICAgICAgImEuYmIsIGMuZGQiCiAgICAg ICAgCiAgICAgICAgSW5pdGlhbCBuYW1lIHNwYWNlOiAgVGhpcyBkb2N1bWVudCBvbmx5 IGRlZmluZXMgdmFsdWVzIGZvciBmaWxlcwogICAgICAgIGluIHRoZSBJU08gRmlsZSBG b3JtYXQgZmFtaWx5LiAgT3RoZXIgZmlsZSBmb3JtYXRzIG1heSBhbHNvCiAgICAgICAg ZGVmaW5lIGNvZGVjIG5hbWluZy4KICAgICAgICAKCgoKCgoKR2VsbGVucyAgICAgICAg ICAgICAgICAgICBbUGFnZSA1XSAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmls IDIwMDUKDApJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBUaGUgQ29kZWNzIFBhcmFt ZXRlciAgICAgICAgICAgICBPY3RvYmVyIDIwMDQKCgogICAgICAgIEZvciB0aGUgSVNP IEZpbGUgZm9ybWF0LCB0aGUgZmlyc3QgZWxlbWVudCBpcyBhIHNhbXBsZQogICAgICAg IGRlc2NyaXB0aW9uIGVudHJ5IGZvdXItY2hhcmFjdGVyIGNvZGUgYXMgcmVnaXN0ZXJl ZCBieSB0aGUgTVA0CiAgICAgICAgUmVnaXN0cmF0aW9uIEF1dGhvcml0eSBbTVA0LVJl Z10uICBUaGUgdmFsdWVzIGFyZQogICAgICAgIGNhc2Utc2Vuc2l0aXZlLiAgRm9yIHRo ZSBuYW1lICdtcDRhJywgaW5kaWNhdGluZyBzb21lIGtpbmQgb2YKICAgICAgICBNUEVH LTQgYXVkaW8sIHRoZSBzZWNvbmQgZWxlbWVudCBpcyB0aGUgaGV4YWRlY2ltYWwKICAg ICAgICByZXByZXNlbnRhdGlvbiBvZiB0aGUgTVA0IFJlZ2lzdHJhdGlvbiBBdXRob3Jp dHkKICAgICAgICBPYmplY3RUeXBlSW5kaWNhdGlvbiAoT1RJKSBbTVA0LVJlZ10gKGUu Zy4sIHRoZSBlbGVtZW50ICIweDIwIikuCiAgICAgICAgCiAgICAKICAgIFN5bnRheDoK ICAgIAogICAgY29kZWNzICAgICAgPSAiQ29kZWNzIiAqU1AgIj0iICpTUCB2YWx1ZQoK ICAgIHZhbHVlICAgICAgID0gaWQgLyBEUVVPVEUgKlNQIGlkICooKlNQICIsIiAqU1Ag aWQpICpTUCBEUVVPVEUKCiAgICBpZCAgICAgICAgICA9IGlkLUlTTyAvIGlkLWdlbgoK ICAgIGlkLWdlbiAgICAgID0gZWxlbWVudCAqKCAiLiIgZWxlbWVudCApCgogICAgaWQt SVNPICAgICAgPSBjcGlkIFsgIi4iIG90aSBdCiAgICAgCiAgICBjcGlkICAgICAgICA9 IDQgKGlkY2hhciAvIGlkY2hhci1zcGVjKQoKICAgIG90aSAgICAgICAgID0gIjB4IiAy SEVYRElHCgogICAgZWxlbWVudCAgICAgPSAxKihpZGNoYXIgLyBpZGNoYXItc3BlYykK CiAgICBpZGNoYXIgICAgICA9IDxhbnkgKFVTLUFTQ0lJKSBDSEFSIGV4Y2VwdCBTUEFD RSwgQ1RMcywKICAgICAgICAgICAgICAgICAgIiQiLCBvciB0c3BlY2lhbHM+CgogICAg aWRjaGFyLXNwZWMgPSAiJCIgMkRJR0lUCgogICAgdHNwZWNpYWxzICAgPSAgIigiIC8g IikiIC8gIjwiIC8gIj4iIC8gIkAiIC8KICAgICAgICAgICAgICAgICAgICIsIiAvICI7 IiAvICI6IiAvICJcIiAvIDwiPgogICAgICAgICAgICAgICAgICAgIi8iIC8gIlsiIC8g Il0iIC8gIj8iIC8gIj0iCiAgICAKICAgIE5vdGUgdGhhdCBpbiBzb21lIGNhc2VzLCB0 aGUgZm91ci1jaGFyYWN0ZXIgSUQgcmVnaXN0ZXJlZCBpbgogICAgW01QNC1SZWddIG1h eSBzdGlsbCBiZSBhbWJpZ3VvdXMsIGV2ZW4gd2hlbiB1c2luZyB0aGUgT1RJLiAgRm9y CiAgICBleGFtcGxlLCBhbGwgbXBlZy00IGF1ZGlvIGNvZGVjcyBhcmUgdW5kZXIgJ21w NGEnLCBpbmNsdWRpbmcgSFZYQywKICAgIENFTFAsIEdBICh3aGljaCBjYW4gYmUgQUFD LCB0d2luVlEsIG9yIEJTQUMpLCBTQSwgVFRTSSwgSElMTiAoc2VlCiAgICBNUDRBKS4g IEhvd2V2ZXIsIHNpbmNlIGF1ZGlvLzNncHAyLCB2aWRlby8zZ3BwMiwgYXVkaW8vM2dw cCwgYW5kCiAgICB2aWRlby8zZ3BwIHJlc3RyaWN0IHRoZSBhbGxvd2FibGUgSVNPIGNv ZGUgcG9pbnRzLCB0aGVyZSBpcyBubwogICAgYW1iaWd1aXR5IGluIHRoZXNlIGZvdXIg Y2FzZXMuCiAgICAKCgoKCgoKCkdlbGxlbnMgICAgICAgICAgICAgICAgICAgW1BhZ2Ug Nl0gICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMDA1CgwKSW50ZXJuZXQg RHJhZnQgICAgICAgICAgICAgVGhlIENvZGVjcyBQYXJhbWV0ZXIgICAgICAgICAgICAg T2N0b2JlciAyMDA0CgoKICAgIFdoZW4gdGhlIENvZGVjcyBwYXJhbWV0ZXIgaXMgdXNl ZCwgaXQgTVVTVCBjb250YWluIGFsbCBjb2RlY3MKICAgIHJlcXVpcmVkIHRvIHJlbmRl ciBhbGwgY29udGVudCBwcmVzZW50IGluIHRoZSBib2R5IHBhcnQuICBUaGUgQ29kZWNz CiAgICBwYXJhbWV0ZXIgTVVTVCBOT1QgY29udGFpbiBhbnkgY29kZWNzIHdoaWNoIGFy ZSBub3QgcHJlc2VudCBpbiB0aGUKICAgIGJvZHkgcGFydC4KICAgIAogICAgCjQuICBF eGFtcGxlcwogICAgCiAgICBDb250ZW50LVR5cGU6ICBWaWRlby8zR1BQMjsgQ29kZWNz PSJzZXZjLCBzMjYzIgogICAgICAgIChFVlJDIGF1ZGlvIHBsdXMgSC4yNjMgdmlkZW8p CiAgICBDb250ZW50LVR5cGU6ICBBdWRpby8zZ3A7IENvZGVjcz1zYW1yCiAgICAgICAg KEFNUiBhdWRpbykKICAgIENvbnRlbnQtVHlwZTogdmlkZW8vM2dwcDsgQ29kZWNzPSJz MjYzLCBzYW1yIgogICAgICAgIChILjI2MyB2aWRlbyBwbHVzIEFNUiBhdWRpbykKICAg IENvbnRlbnQtVHlwZTogYXVkaW8vM2dwcDI7IENvZGVjcz1tcDRhLjB4RTEKICAgICAg ICAoMTNrIGF1ZGlvKQogICAgQ29udGVudC1UeXBlOiB2aWRlby8zZ3BwMjsgQ29kZWNz PSJtcDR2LjB4MjAsIG1wNGEuMHhFMSIKICAgICAgICAoVmlzdWFsIElTTy9JRUMgMTQ0 OTYtMiBbTVA0Vl0gcGx1cyAxM0sgdm9pY2UpCiAgICAgICAgCiAgICAgICAgTm90ZTog MHgyMCBPVEkgdmFsdWUgc2F5cyAiSW5jbHVkZXMgYXNzb2NpYXRlZCBBbWVuZG1lbnQo cykgYW5kCiAgICAgICAgQ29ycmlnZW5kdW0oYSkuICBUaGUgYWN0dWFsIG9iamVjdCB0 eXBlcyBhcmUgZGVmaW5lZCBpbiBJU08vSUVDCiAgICAgICAgMTQ0OTYtMiBhbmQgYXJl IGNvbnZleWVkIGluIHRoZSBEZWNvZGVyU3BlY2lmaWNJbmZvIGFzIHNwZWNpZmllZAog ICAgICAgIGluIElTTy9JRUMgMTQ0OTYtMiwgQW5uZXggSy4iCiAgICAgICAgCiAgICAg ICAgCiAgICA1LiAgQWRkaXRpb25hbCBNZWRpYSBGZWF0dXJlIERldGFpbHMKICAgICAg ICAKICAgICAgICBGb3IgdGhlIHNhbWUgcmVhc29ucyB0aGF0IHRoZSBDb2RlY3MgcGFy YW1ldGVyIGlzIHVzZWZ1bCwgaXQgaXMKICAgICAgICBzb21ldGltZXMgaGVscGZ1bCB0 byBwcm92aWRlIGFkZGl0aW9uYWwgZGV0YWlscyBmb3IgYSBtZWRpYQogICAgICAgIGVs ZW1lbnQgKGUuZy4sIHRoZSBudW1iZXIgb2YgWCBhbmQgWSBwaXhlbHMsIHRoZSBjb2xv ciBkZXB0aCwKICAgICAgICBldGMuKS4gIFRoZXNlIGRldGFpbHMgYXJlIHNvbWV0aW1l cyBjYWxsZWQgIm1lZGlhIGZlYXR1cmVzIiBhbmQKICAgICAgICBzb21ldGltZXMgIm1l ZGlhIGNoYXJhY3RlcmlzdGljcyIuCiAgICAgICAgCiAgICAgICAgV2hlbiBzdWNoIGFk ZGl0aW9uYWwgZmVhdHVyZXMgYXJlIGluY2x1ZGVkLCB0aGUKICAgICAgICBbQ29udGVu dC1GZWF0dXJlc10gaGVhZGVyIHByb3ZpZGVzIGEgaGFuZHkgd2F5IHRvIGRvIHNvLgog ICAgICAgIAogICAgICAgIAogICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMKICAgICAg ICAKICAgICAgICBUaGUgaGFyZC13b3JraW5nIElBTkEgc3RhZmYgaXMga2luZGx5IHJl cXVlc3RlZCB0byBhZGQgIkNvZGVjcyIKICAgICAgICBhcyBhbiBvcHRpb25hbCBwYXJh bWV0ZXIgdG8gdGhlIG1lZGlhIHR5cGVzIGxpc3RlZCBpbiBTZWN0aW9uCiAgICAgICAg Mywgd2l0aCBhIHJlZmVyZW5jZSB0byB0aGlzIGRvY3VtZW50CiAgICAgICAgCiAgICAg ICAgCgoKCgoKCgpHZWxsZW5zICAgICAgICAgICAgICAgICAgIFtQYWdlIDddICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjAwNQoMCkludGVybmV0IERyYWZ0ICAg ICAgICAgICAgIFRoZSBDb2RlY3MgUGFyYW1ldGVyICAgICAgICAgICAgIE9jdG9iZXIg MjAwNAoKCiAgICA3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKICAgICAgICAKICAg ICAgICBUaGUgY29kZWNzIHBhcmFtZXRlciBpdHNlbGYgZG9lcyBub3QgYWx0ZXIgdGhl IHNlY3VyaXR5CiAgICAgICAgY29uc2lkZXJhdGlvbnMgb2YgYW55IG9mIHRoZSBtZWRp YSB0eXBlcyBmb3Igd2hpY2ggaXQgaXMKICAgICAgICBhdmFpbGFibGUuICBFYWNoIGF1 ZGlvIGFuZCB2aWRlbyBtZWRpYSB0eXBlIGhhcyBpdHMgb3duIHNldCBvZgogICAgICAg IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdoaWNoIGNvbnRpbnVlIHRvIGFwcGx5LCBy ZWdhcmRsZXNzIG9mCiAgICAgICAgdGhlIHVzZSBvZiB0aGUgY29kZWNzIHBhcmFtZXRl ci4KICAgICAgICAKICAgICAgICBBbiBpbmNvcnJlY3QgY29kZWNzIHBhcmFtZXRlciBt aWdodCBjYXVzZSBtZWRpYSBjb250ZW50IHRvIGJlCiAgICAgICAgcmVjZWl2ZWQgYnkg YSBkZXZpY2Ugd2hpY2ggaXMgbm90IGNhcGFibGUgb2YgcmVuZGVyaW5nIGl0LCBvcgog ICAgICAgIG1pZ2h0IGNhdXNlIG1lZGlhIGNvbnRlbnQgdG8gbm90IGJlIHNlbnQgdG8g YSBkZXZpY2Ugd2hpY2ggaXMKICAgICAgICBjYXBhYmxlIG9mIHJlY2VpdmluZyBpdC4g IEFuIGluY29ycmVjdCBjb2RlY3MgcGFyYW1ldGVyIGlzCiAgICAgICAgdGhlcmVmb3Jl IGNhcGFibGUgb2Ygc29tZSB0eXBlcyBvZiBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tz LgogICAgICAgIEhvd2V2ZXIsIHRoaXMgaXMgbW9zdCBsaWtlbHkgdG8gYXJpc2UgYnkg YWNjaWRlbnQsIGFzIGFuCiAgICAgICAgYXR0YWNrZXIgY2FwYWJsZSBvZiBhbHRlcmlu ZyBtZWRpYSBkYXRhIGluIHRyYW5zaXQgY291bGQgY2F1c2UKICAgICAgICBtb3JlIGhh cm0gYnkgYWx0ZXJpbmcgdGhlIG1lZGlhIGZvcm1hdCBpdHNlbGYsIG9yIGV2ZW4gdGhl CiAgICAgICAgY29udGVudCB0eXBlIGhlYWRlciwgcmF0aGVyIHRoYW4ganVzdCB0aGUg Y29kZWNzIHBhcmFtZXRlciBvZgogICAgICAgIHRoZSBjb250ZW50IHR5cGUgaGVhZGVy LgogICAgICAgIAogICAgICAgIAogICAgOC4gIEFja25vd2xlZGdlbWVudHMKICAgICAg ICAKICAgICAgICBEYXZpZCBTaW5nZXIgYW5kIEhhcmluYXRoIEdhcnVkYWRyaSBwcm92 aWRlZCBzaWduaWZpY2FudCBoZWxwLAogICAgICAgIHdoaWNoIGlzIHZlcnkgbXVjaCBh cHByZWNpYXRlZC4KICAgICAgICAKICAgICAgICAKICAgIDkuICBOb3JtYXRpdmUgUmVm ZXJlbmNlcwogICAgICAgIAogICAgICAgIFtBQk5GXSBDcm9ja2VyLCBPdmVyZWxsLCAi QXVnbWVudGVkIEJORiBmb3IgU3ludGF4CiAgICAgICAgU3BlY2lmaWNhdGlvbnM6ICBB Qk5GIiwgUkZDIDIyMzQsIEludGVybmV0IE1haWwgQ29uc29ydGl1bSwKICAgICAgICBE ZW1vbiBJbnRlcm5ldCBMdGQuLCBOb3ZlbWJlciAxOTk3LgogICAgICAgIAogICAgICAg IFtDb250ZW50LUZlYXR1cmVzXSBLbGluZSwgRy4sICJJbmRpY2F0aW5nIE1lZGlhIEZl YXR1cmVzIGZvcgogICAgICAgIE1JTUUgQ29udGVudCIsIFJGQyAyOTEyLCBTZXB0ZW1i ZXIgMjAwMC4KICAgICAgICAKICAgICAgICBbTUlNRS1UeXBlc10gRnJlZWQsIE4uIGFu ZCBOLiBCb3JlbnN0ZWluLCAiTXVsdGlwdXJwb3NlIEludGVybmV0CiAgICAgICAgTWFp bCBFeHRlbnNpb25zIChNSU1FKSBQYXJ0IFR3bzogIE1lZGlhIFR5cGVzIiwgUkZDIDIw NDYsCiAgICAgICAgTm92ZW1iZXIgMTk5Ni4KICAgICAgICAKICAgICAgICBbTWVkaWEt RmVhdHVyZXNdIEhvbHRtYW4sIEsuLCBBLiBNdXR6IGFuZCBULiBIYXJkaWUsICJNZWRp YQogICAgICAgIEZlYXR1cmUgVGFnIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUiLCBSRkMg MjUwNiwgQkNQIDMxLCBNYXJjaAogICAgICAgIDE5OTkuCiAgICAgICAgCgoKCgoKCgoK R2VsbGVucyAgICAgICAgICAgICAgICAgICBbUGFnZSA4XSAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEFwcmlsIDIwMDUKDApJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBU aGUgQ29kZWNzIFBhcmFtZXRlciAgICAgICAgICAgICBPY3RvYmVyIDIwMDQKCgogICAg ICAgIFtNUDQtcmVnXSBNUDRSRUcsIFRoZSBNUEVHLTQgUmVnaXN0cmF0aW9uIEF1dGhv cml0eSwKICAgICAgICA8dXJsOi8vd3d3Lm1wNHJhLm9yZz4KICAgICAgICAKICAgICAg ICAKICAgIDEwLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwogICAgICAgIAogICAgICAg IFsxM2tdIEdlbGxlbnMsIFIgYW5kIEguIEdhcnVkYWRyaSwgIlRoZSBRQ1AgRmlsZSBG b3JtYXQgYW5kCiAgICAgICAgTWVkaWEgVHlwZXMgZm9yIFNwZWVjaCBEYXRhIiwgUkZD IDM2MjUsIFNlcHRlbWJlciAyMDAzLgogICAgICAgIAogICAgICAgIFtBTVJdIFNqb2Jl cmcsIEouLCBNLiBXZXN0ZXJsdW5kLCBBLiBMYWthbmllbWksIFEuIFhpZSwKICAgICAg ICAiUmVhbC1UaW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBQYXlsb2FkIEZvcm1h dCBhbmQgRmlsZQogICAgICAgIFN0b3JhZ2UgRm9ybWF0IGZvciB0aGUgQWRhcHRpdmUg TXVsdGktUmF0ZSAoQU1SKSBhbmQgQWRhcHRpdmUKICAgICAgICBNdWx0aS1SYXRlIFdp ZGViYW5kIChBTVItV0IpIEF1ZGlvIENvZGVjcyIsIFJGQyAzMjY3LCBKdW5lIDIwMDIu CiAgICAgICAgCiAgICAgICAgWzNHUFAtQ29kZWNzXSBUUyAyNi4yMzQsIFRoaXJkIEdl bmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdAogICAgICAgICgzR1BQKSwgIlRyYW5z cGFyZW50IGVuZC10by1lbmQgc3RyZWFtaW5nIHNlcnZpY2U7IFByb3RvY29scyBhbmQK ICAgICAgICBjb2RlY3MiLCBVUkw6CiAgICAgICAgPGh0dHA6Ly93d3cuM2dwcC5vcmcv ZnRwL1NwZWNzL2h0bWwtaW5mby8yNjIzNC5odG0+CiAgICAgICAgCiAgICAgICAgWzNH UFAtRm9ybWF0c10gVFMgMjYuMjQ0LCBUaGlyZCBHZW5lcmF0aW9uIFBhcnRuZXJzaGlw IFByb2plY3QKICAgICAgICAoM0dQUCksICJUcmFuc3BhcmVudCBlbmQtdG8tZW5kIHN0 cmVhbWluZyBzZXJ2aWNlOyAzR1BQIGZpbGUKICAgICAgICBmb3JtYXQgKDNHUCkiLCBV Ukw6CiAgICAgICAgPGh0dHA6Ly93d3cuM2dwcC5vcmcvZnRwL1NwZWNzL2h0bWwtaW5m by8yNjI0NC5odG0+CiAgICAgICAgCiAgICAgICAgWzNHUFAyLUZvcm1hdHNdIFRoaXJk IEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdCAyLCAiM0dQUDIKICAgICAgICBG aWxlIEZvcm1hdHMgZm9yIE11bHRpbWVkaWEgU2VydmljZSIsIFVSTDoKICAgICAgICA8 aHR0cDovL3d3dy4zZ3BwMi5vcmcvUHVibGljX2h0bWwvc3BlY3MvQy5TMDA1MC0wX3Yx LjBfMTIxNTAzLnBkZj4KICAgICAgICAKICAgICAgICBbTVA0QV0gSVNPL0lFQyAxNDQ5 Ni0zOjIwMDEsICJJbmZvcm1hdGlvbiBUZWNobm9sb2d5LS1Db2Rpbmcgb2YKICAgICAg ICBBdWRpby9WaXN1YWwgT2JqZWN0LS1QYXJ0IDM6ICBBdWRpbyIuCiAgICAgICAgCiAg ICAgICAgW01QNFZdIElTTy9JRUMgMTQ0OTYtMjoyMDAxLCAiSW5mb3JtYXRpb24gVGVj aG5vbG9neS0tQ29kaW5nIG9mCiAgICAgICAgQXVkaW8vVmlzdWFsIE9iamVjdC0tUGFy dCAyOiAgVmlkZW8iLgogICAgICAgIAogICAgICAgIAogICAgMTEuICBBdXRob3IncyBB ZGRyZXNzCiAgICAgICAgCiAgICBSYW5kYWxsIEdlbGxlbnMgIAogICAgUVVBTENPTU0g SW5jb3Jwb3JhdGVkICAgICAgICAgICAgICAKICAgIDU3NzUgTW9yZWhvdXNlIERyaXZl CiAgICBTYW4gRGllZ28sIENBICA5MjEyMQogICAgVVNBCiAgICByYW5keUBxdWFsY29t bS5jb20KICAgICAgICAKICAgICAgICAKCgoKCgoKR2VsbGVucyAgICAgICAgICAgICAg ICAgICBbUGFnZSA5XSAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDIwMDUK DApJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBUaGUgQ29kZWNzIFBhcmFtZXRlciAg ICAgICAgICAgICBPY3RvYmVyIDIwMDQKCgogICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5 IFN0YXRlbWVudAogICAgICAgIAogICAgICAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0 aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YKICAgICAgICBhbnkg aW50ZWxsZWN0dWFsIHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJl IGNsYWltZWQKICAgICAgICB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBv ciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kKICAgICAgICBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlCiAgICAgICAg dW5kZXIgc3VjaCByaWdodHMgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsg bmVpdGhlciBkb2VzCiAgICAgICAgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIG1hZGUg YW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaAogICAgICAgIHJpZ2h0cy4gIElu Zm9ybWF0aW9uIG9uIHRoZSBJRVRGJ3MgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8K ICAgICAgICByaWdodHMgaW4gc3RhbmRhcmRzLXRyYWNrIGFuZCBzdGFuZGFyZHMtcmVs YXRlZCBkb2N1bWVudGF0aW9uCiAgICAgICAgY2FuIGJlIGZvdW5kIGluIEJDUC0xMS4g IENvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUKICAgICAgICBhdmFpbGFibGUg Zm9yIHB1YmxpY2F0aW9uIGFuZCBhbnkgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBi ZQogICAgICAgIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIGF0dGVt cHQgbWFkZSB0byBvYnRhaW4gYQogICAgICAgIGdlbmVyYWwgbGljZW5zZSBvciBwZXJt aXNzaW9uIGZvciB0aGUgdXNlIG9mIHN1Y2ggcHJvcHJpZXRhcnkKICAgICAgICByaWdo dHMgYnkgaW1wbGVtZW50b3JzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBj YW4gYmUKICAgICAgICBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIFNlY3JldGFyaWF0Lgog ICAgICAgIAogICAgICAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFy dHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbgogICAgICAgIGFueSBjb3B5cmlnaHRz LCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyCiAgICAgICAg cHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQg bWF5IGJlCiAgICAgICAgcmVxdWlyZWQgdG8gcHJhY3RpY2UgdGhpcyBzdGFuZGFyZC4g IFBsZWFzZSBhZGRyZXNzIHRoZQogICAgICAgIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRG IEV4ZWN1dGl2ZSBEaXJlY3Rvci4KICAgICAgICAKICAgICAgICAKICAgIEZ1bGwgQ29w eXJpZ2h0IFN0YXRlbWVudAogICAgICAgIAogICAgICAgIENvcHlyaWdodCAoQykgVGhl IEludGVybmV0IFNvY2lldHkgKDIwMDQpLgogICAgICAgIAogICAgICAgIFRoaXMgZG9j dW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQKICAgICAg ICByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBz ZXQgZm9ydGgKICAgICAgICB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRo ZWlyIHJpZ2h0cy4KICAgICAgICAKICAgICAgICAKICAgIERpc2NsYWltZXIKICAgICAg ICAKICAgICAgICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQKICAgICAgICBvbiBhbiAiQVMgSVMiIGJhc2lz IGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFCiAgICAg ICAgUkVQUkVTRU5UUyBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRF Uk5FVCBTT0NJRVRZIEFORAogICAgICAgIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBU QVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLAogICAgICAgIEVYUFJFU1Mg T1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFO VFkKICAgICAgICBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OIEhFUkVJTiBX SUxMIE5PVCBJTkZSSU5HRSBBTlkKICAgICAgICBSSUdIVFMgT1IgQU5ZIElNUExJRUQg V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUwogICAgICAgIEZP UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4KICAgICAgICAKICAgICAgICAKCgoKCgoKR2Vs bGVucyAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0gICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBcHJpbCAyMDA1Cg== --============_-1113738670==_============ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --============_-1113738670==_============-- From avt-bounces@ietf.org Fri Oct 22 09:07:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00861 for ; Fri, 22 Oct 2004 09:07:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzL7-0005mq-S8 for avt-archive@ietf.org; Fri, 22 Oct 2004 09:20:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKz3Q-0008LH-0B; Fri, 22 Oct 2004 09:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyxW-0005kB-QZ; Fri, 22 Oct 2004 08:55:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29981; Fri, 22 Oct 2004 08:55:52 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzA9-0005Yh-Fr; Fri, 22 Oct 2004 09:09:08 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9MCtefM001501; Fri, 22 Oct 2004 14:55:40 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 14:55:39 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJPCBGYH; Fri, 22 Oct 2004 14:55:39 +0200 Message-ID: <4179034A.2060904@ericsson.com> Date: Fri, 22 Oct 2004 14:55:38 +0200 X-Sybari-Trust: b10e9499 bfd556f1 394cce6e 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: lazzaro References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2004 12:55:39.0970 (UTC) FILETIME=[6ECA1A20:01C4B836] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, mmusic@ietf.org Subject: [AVT] Re: [MMUSIC] maxptime X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: 7bit Hi John, Please see below. I also have to point out that I haven't read your drafts during the last year or so. I have only looked at certain specific things in them. lazzaro wrote: > > On Oct 21, 2004, at 12:45 AM, Magnus Westerlund wrote: > > Hi John, > > Hi Magnus! > > There are a few separable issues here, let's take > them one by one ... CC'd to AVT since these issues cross > boundaries ... > > > I think the usage of maxptime=0 may be a bit problematic. A > > interpretation is that no audio can be included in the packet, as no > > audio duration is allowed. > > > > I see that you have made another interpretation in the MIDI draft > > (draft-ietf-avt-rtp-midi-format-06): > > > > "0 ms is a reasonable media time value for MIDI packets. In a packet > > with a 0 ms media time, all commands execute at the instant coded by > > the > > packet timestamp. Prohibitions in [13] against 0 ms ptime values are > > not relevant for MIDI streams, and may be ignored." > > > > An RTP timestamp tick is strictly not an instant, it has a duration > > equal to 1/(RTP timestamp rate). > > However these is my interpretation. > I probably should clarify myself as I have received comments that it seems like I am reinterpreting the timestamp model. The only point I was trying to make is that in a digital domain, compared to the analog an instant is not strictly a precise moment without any duration. Due to the analog to digital conversion the smallest point in time we can express is a single sample (RTP TS tick). That sample represent some duration, equal to 1/(sampling frequency), thus it is not truly instantaneous. To connect to John's example below, about the keyboardist. Even if he strikes the keys simultaneously on a timescale of 1/10000 part of second it is most likely not true when you go to a timescale of 1/10^9 of a second. I will return to this later down. > Here's the underlying motivation for the choice I made. > > Imagine playing the piano. > > Play three notes simultaneously. In MIDI, this corresponds > to three separate NoteOn commands. In RTP MIDI, each > has a timestamp, expressed in RTP timestamp units. > > It's really important to the sonic integrity of the piece to code that > the notes happen simultaneously -- even one RTP tick matters. > The reason is, phase effects as the waveforms beat against each > other change the timbre. Hand drummers on the list (conga, etc) > can attest to this -- the art of creating certain timbres on those > types of percussion instruments is based on fine timing of strokes > on the drum with the two hands. Standard MIDI Files do in fact code > true simultaneity, which is why they can be used in studio work. > Musicians go crazy shifting around MIDI notes by tiny amounts inside > the DAW to get this sort of stuff right, and SMFs preserve that hard > work > on export. > > Pull back from the nanosecond level to the few-millisecond > level, and we move from timbre distortion to timing sloppiness. > MIDI as transmitted on a MIDI 1.0 DIN cable suffers from this: > at 300 microseconds/command, playing full chords with both > hands creates timing slews you can hear. Part of the motivation > to move off of MIDI DIN cable technology is to make instrument > controllers that don't suffer this timing problem. I think I understand this, however the RTP timestamp rate as I understand it for MIDI would be equal to the sample rate for the audio produced? That would mean that it is reasonable to expect that we are working with a sample frequency of for example 48kHz. Or do you needed even higher resolution? > > You might ask -- why can't just put all simultaneous notes > in the same packet, and use something other than RTP timestamps > to denote intra-packet timing? No, I am not questioning this timing model at all. It seems appropriate for RTP based on your description. However one needs to be aware what it means. A MIDI command can't be correctly synchronized with a finer scale then one RTP TS tick. Thus the precision is depending on the timestamp rate. > > To understand the answer, you need to understand that a core > use of RTP MIDI is on "media LANs" -- a stage or studio situation > that may consist of two nodes -- piano controller and laptop -- > connected by an Ethernet cable as the Layer 2 for RTP MIDI. > These folks want absolute lowest latency -- so, they don't want > their piano controller to wait around after the first MIDI command > to see if a second command that is "simultaneous" is happening soon. > Instead, they want the piano to take each command, put it in its own RTP > packet, and send it off. So, they want the ability to send two RTP > packets > in a row, each coding one MIDI command, each with the same > RTP timestamp. To do this, they need the RTP timestamp semantics > that say an RTP MIDI packet can have 0 ms media time. First, I can understand that due to the desire to keep the latency to a minimal even a short buffering is not desirable, however RTP payloads are normal gathered using some type of buffering, either at the encoding step, due to the need to gather sufficient amount of samples to perform the encoding, or at the packetization step to aggregate together sufficient amount of data to get the right efficiency in the transmission. Thus MIDI commands are a bit special. Secondly I don't think we are talking media time really here. The command does not truly have a duration as you say. They takes affect the instant (on a specific sample) indicated by the RTP timestamp. The problem is really about indicating packetization strategies. > > Some instrument makers use Ethernet today. They use their own UDP > solutions (some use OSC on top of UDP) and have their own code. They > want to add support for RTP MIDI, but RTP MIDI needs to work with their > model, which is as I describe it above. > > I would also not be surprised if the recovery journal semantics > failed if we moved to your RTP timestamp interpretation, although > I'd have to think about to say for certain. Other things might break > too. This is a 4-year-old project now, and the timestamp model is > a fundamental assumption that underlies RTP MIDI in subtle ways. > I am not redefining anything. I think we simply have misunderstood each other. > So, that's the reply to issue #1. > > Issue #2: > > > Is really your intention of using maxptime=0 that for each timestamp > > tick there is a command(s), a new packet should be sent? I can > > understand using ptime=0 to recommend that you do this behaviour but > > using maxptime to enforce the behaviour? > > Yes. Once again, we're talking about apps in the "media network" > world, a laptop and piano keyboard with a point-to-point 2-node > Ethernet as the Layer 2 for RTP MIDI. The maxptime=0 parameter > says: all packets must either code no MIDI commands, or code one > or more MIDI commands with the same timestamp -- and thus, the > media time for all packets must be 0 ms. > > This accommodates receivers (such as, currently, sfront!) that do not > implement a receiver buffer of any sort. Instead, sfront grabs a > packet, > and executes all MIDI commands in the packet simultaneously. > It relies on the constant nominal latency of the point-to-point Layer 2, > and the constant nominal latency of the keyboard sender, for timing > accuracy -- not RTP timestamps, which are ignored. Then it is not really RTP you are using. You are ignoring the functionality the timestamp provides to place the different packets correctly on a timescale to combat any transport jitter. As it seems the local stage applications are relying on a consistent transport behavior. > > Thus, these receivers can't handle a packet that has a non-zero media > time -- all they know is "now". > Then they are not RTP aware, a RTP receiver needs to have knowledge about how time flows. > If one is designing receivers exclusively for use on media LANs > as live performance instruments (in other words -- a musical > instrument synthesizers intended to only be played locally), this > "no buffer" model makes perfect sense -- it's how soft synths that > are driven by MIDI 1.0 cables work today. Eventually, it would be > better if these synths incorporated small configurable buffers to > compensate for sub-ms jitter, but the conceptual hurdle to do so > would be too great for many synth authors to do. In practice, > OS APIs will probably implement those buffers if/when they choose > to support RTP MIDI as a media LAN MIDI source. > > So, we need a way for those soft synths to negotiation (via > Offer/Answer) > to say "I can only handle 0 ms packets, do not send me any other > kind". The problem is really to indicate the desired behavior. Which is not really what ptime and maxptime is about. They give the recommend and maximal amount of media duration for a packet. > > Issue #3 > > > Especially any that is primarily to handle Offer/Answer, where a > > normative > > MUST be larger than 0 is present. I think you should consider the > > impact on interoperability. > > Well, the easiest thing to do is invent my own SDP parameter as an > RTP MIDI replacement for maxptime -- this skirts the compatibility > issue. But as I explained above, I think we have a legitimate need > for the negotiating functionality. And I think the most elegant thing > to do is for maxptime to bend its definition to include 0 ms, just for > RTP MIDI, which is why I did it that way ... a compromise would be > to put interoperability warning language into the RTP MIDI I-D, but > keep the normative text as is. The basic problem is that you are using ptime and maxptime way beyond what was ever intended by the authors of these parameters. I am certain of this when it comes to maxptime, as I am the one that defined that one with some help. Therefore I think one needs to look at the different use cases for RTP midi. I think there are several. 1. Local play, where most of RTP's timing model seems to be ignored, as it can't be excepted to buffer in either end of the chain. 2. Transmitting a live session to another point, but in which cases it is acceptable to introduce some small delay. This is done over a network that do not have the jitter behavior necessary to ignore the timestamp. Which means a receiver must follow the timestamp to give the right inter command time spacing. 3. Streaming of midi content. In 1, I think you need something new to indicate the intended behavior of minimal transmission delay and local live play. However I do hope that a sender at least correctly timestamp the RTP packets sent. Thus the RTP receiver can in the future start using the timing model correctly. In 2, I think the usage of ptime and maxptime could be reasonable to instruct a sender to gather 10, 50 or 100 samples or 1, 5, 20 ms of commands into each packet. However if you like to have finer resolution than 1 ms then it is necessary to have a new parameter. In 3, theses parameters are not used at all. The amount of commands in the packets are pre determined for best performance at the receiver. In conclusion I would suggest that you use another MIME parameter than ptime and maxptime to indicate the desired behavior. I also think that the format drafts needs to be more explicit on considerations for the RTP timestamp. What rates are suitable, what are the impact on playback timing. There seems to be a bit on this in the guidelines, but I haven't had time to read it fully. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 22 12:33:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18650 for ; Fri, 22 Oct 2004 12:33:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2YV-0001jL-Vo for avt-archive@ietf.org; Fri, 22 Oct 2004 12:46:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2JZ-0003ud-4A; Fri, 22 Oct 2004 12:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2Iv-0003L5-FR for avt@megatron.ietf.org; Fri, 22 Oct 2004 12:30:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18372 for ; Fri, 22 Oct 2004 12:30:09 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2Vj-0001fa-Ou for avt@ietf.org; Fri, 22 Oct 2004 12:43:28 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9MGU9R2020249 for ; Fri, 22 Oct 2004 18:30:09 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 18:30:08 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJQD778V; Fri, 22 Oct 2004 18:30:08 +0200 Message-ID: <41793590.6020904@ericsson.com> Date: Fri, 22 Oct 2004 18:30:08 +0200 X-Sybari-Trust: 95598e6d 963c3fd6 cda1744d 00000979 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: ned.freed@mrochek.com Subject: Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> In-Reply-To: <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2004 16:30:08.0974 (UTC) FILETIME=[655046E0:01C4B854] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: IETF MIME Types Review List , John C Klensin , IETF AVT WG , Allison Mankin X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Hi Ned, We need to resolve this. And I do not consider it resolved as long as it is not sufficient motivated and way of handling the already approved specifications is indicated. I can understand the need for caution if registering different parameters for different applicability. How does one clarify what is acceptable, and what is not? Thus please answer Colin's questions below in attempt to define some borders. Is your point that if you need a different piece of software to correctly handle the data, then it is another type. Like the fact that you need to have a handler of RTP timestamp that sorts frame correctly for AMR RTP payload format, while the file format only needs to be able to read the frames in sequence to get the order? Secondly how does we handle the already registered types? They are almost impossible to change due to the deployed base of at least some of the types. The file format for AMR is deployed in a couple of millions mobile phones that support MMS. Do we only leave them in as anomalies in the system? Cheers Magnus Colin Perkins wrote: >> >> File header/magic number != framing in my book. > > > So, what do you mean by framing? In the examples I'm quoting, the media > data format is bitwise identical in both cases. The difference is that > it's framed in a file (and hence has a file header) rather than a series > of RTP packets (and hence has an RTP header); once you strip the framing > there is no difference in format. > >> And this will be my last message on this topic. > > > Which doesn't resolve the conflict between draft-freed-media-types-reg > -01.txt and existing practice. Much as you may dislike it, there are two > proposed standards (RFC 3267 and 3558) which register formats in the way > I describe. The change you propose is problematic for a significant user > community, which has previously registered these types in good faith, > according to IETF procedures. > > Colin > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 22 16:18:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07331 for ; Fri, 22 Oct 2004 16:18:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL64Y-00067z-Di for avt-archive@ietf.org; Fri, 22 Oct 2004 16:31:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5ha-0006Y7-4f; Fri, 22 Oct 2004 16:07:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5bk-0002s5-7J; Fri, 22 Oct 2004 16:01:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05267; Fri, 22 Oct 2004 16:01:48 -0400 (EDT) Message-Id: <200410222001.QAA05267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 22 Oct 2004 16:01:48 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2833bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-avt-rfc2833bis-05.txt Pages : 91 Date : 2004-10-22 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. This memo preserves the content standardized by RFC 2833, but clarifies its use through reorganization of the text, addition of tutorial content, and addition of normative text describing the detailed application of the content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2833bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc2833bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-22161718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc2833bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc2833bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22161718.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Fri Oct 22 18:17:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01814 for ; Fri, 22 Oct 2004 18:17:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7vc-0005XB-Hm for avt-archive@ietf.org; Fri, 22 Oct 2004 18:30:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6uJ-0006Lj-Fm; Fri, 22 Oct 2004 17:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6Ba-0001mp-U2 for avt@megatron.ietf.org; Fri, 22 Oct 2004 16:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11060 for ; Fri, 22 Oct 2004 16:38:50 -0400 (EDT) Received: from mout00.kundenservices.net ([81.169.163.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6OQ-0007JT-R9 for avt@ietf.org; Fri, 22 Oct 2004 16:52:11 -0400 Received: from smtp02.kundenservices.net ([81.169.163.72]) by mout00.kundenservices.net with esmtp (Exim 4.41) id 1CL6BQ-00024h-1D; Fri, 22 Oct 2004 22:38:44 +0200 Received: from stewe.org ([81.169.171.175] helo=hobel) by smtp02.kundenservices.net with asmtp (Exim 4.40) id 1CL6BP-00085g-Bq; Fri, 22 Oct 2004 22:38:43 +0200 From: "Stephan Wenger" To: "'Jim Kleck'" , Subject: RE: [AVT] bandwidth feedback in draft-ietf-avt-rtcp-feedback-11.txt Date: Fri, 22 Oct 2004 23:38:33 +0300 Message-ID: <000001c4b877$19eedcc0$5401a8c0@hobel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <4177E3A4.8070303@8x8.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: burmeister@panasonic.de, jo@tzi.org, rey@panasonic.de, sato652@oki.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Dear Jim, RTP is considered an application layer protocol, not a transport layer protocol. RTCP feedback message are application layer feedback. =20 Schemes like yours have been proposed before. Their problem is that = they do not work. =20 The standard solution for your problem (without additional signaling support) would be to mimic TCP congestion control mechanisms. Google = for "TCP Westwood", and you will find a dozen papers or so. Standard RCTP receiver reports are perfectly fine for this purpose. However, even if = you were using a high enough report frequency, you could not avoid losses, because only the losses would tell you to reduce your bandwidth. TCP = will always claim as much bandwidth as it can get, and only stop asking for = it when it senses excessive losses. In the 3GPP environment, the AVP (and AVPF) can be augmented with a = "jitter buffer fullness" indication, which reports the status of the receiver (jitter) buffer -- which, in turn, could be used to calculate your = target bandwidth, doing a bit of straightforward math. This may work over the point-to-point wireless link to the mobile terminal, assuming an overprovisioned core network. It will not work on a LAN, or a = best-effort WAN. =20 With respect to your proposal: As long as your LAN has (statistically) a lower bandwidth then the typical TCP sender's sending capability, your = media transport will be messed up from time to time, no matter what. Unless = you use exotic stuff such as negotiated quality (Intserv, Diffserv) or DCCP. Writing this after 22 hours of no-sleep, Stephan -----Original Message----- From: Jim Kleck [mailto:jimk@8x8.com]=20 Sent: Thursday, October 21, 2004 7:28 PM To: avt@ietf.org Cc: jo@tzi.org; stewe@stewe.org; sato652@oki.com; = burmeister@panasonic.de; rey@panasonic.de Subject: [AVT] bandwidth feedback in draft-ietf-avt-rtcp-feedback-11.txt (resent to CC the draft authoers) Hi all, We have a SIP video conferencing application which operates over broadband. Typically our videophone is on a local network behind a router connected to a DSL or cable modem. When another device on the local network asynchronously starts using bandwidth, e.g. by doing an FTP, we experience either increasing latency as transmitted packets are buffered along the path and/or we experience dropped packets. Both of these conditions are detectable by using RTCP Sender Reports and Receiver Reports, but the question is: how far should our application reduce its transmit bandwidth? RTCP reports indicate number of lost packets or increasing latency, but due to the varying transmit bandwidth of the video (i.e. small bandwidth during periods of little motion, larger bandwidth during periods of large motion), this does not easily translate into how far to reduce the transmit bandwidth. The far end's receiver does, however, have the means to easily calculate both the sender's transmit bandwidth for a particular period (by comparing the two most recently received RTCP Sender Reports) and the actual received bandwidth for that comparable period (by comparing the time and the received byte count at the reception of those two RTCP Sender Reports). Note that the receive bandwidth alone is not sufficient because of the varying video bandwidth. So given these transmit and receive bandwidths, the difference is the amount by which the sender has overfilled the pipe. This difference is not exact because RTP/RTCP packets can get out of sequence, so the difference is only meaningful if it exceeds some threshold. Now all that is needed is a way for the receiver to communicate this difference back to the sender. This could certainly be done using an Application Layer Feedback Message but it is the receiver's RTP layer which processes the RTCP Sender Reports and Receiver Reports and which can calculate the bandwidth difference. This puts the feedback more in the Transport Layer area. However, the sender (i.e. the endpoint that receives the feedback) must pass the information up to the application, so maybe it belongs in the Application Layer area after all. But this kind of feedback seems of general use to me, possibly useful for many types of payload. It should thus be standardized and not left up the the applications nor put into the Payload Specific area. So, I propose a new transport layer feedback message with a single FCI field containing an unsigned 32 bit value. This FCI field would contain the bandwidth difference detected by the receiver. Upon receiving this feedback, the sender can then reduce its maximum transmit bandwidth by the difference. Thank you for your time, Jim Kleck 8x8, Inc _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 22 18:19:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02157 for ; Fri, 22 Oct 2004 18:19:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7xQ-0005bP-7F for avt-archive@ietf.org; Fri, 22 Oct 2004 18:32:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6v9-0007bv-SG; Fri, 22 Oct 2004 17:25:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6JT-0006FI-Q9 for avt@megatron.ietf.org; Fri, 22 Oct 2004 16:47:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12697 for ; Fri, 22 Oct 2004 16:46:59 -0400 (EDT) Received: from mout00.kundenservices.net ([81.169.163.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6WK-0007ts-6M for avt@ietf.org; Fri, 22 Oct 2004 17:00:20 -0400 Received: from smtp02.kundenservices.net ([81.169.163.72]) by mout00.kundenservices.net with esmtp (Exim 4.41) id 1CL6JN-0002hX-IY; Fri, 22 Oct 2004 22:46:57 +0200 Received: from stewe.org ([81.169.171.175] helo=hobel) by smtp02.kundenservices.net with asmtp (Exim 4.40) id 1CL6JM-0008Dc-Vf; Fri, 22 Oct 2004 22:46:57 +0200 From: "Stephan Wenger" To: "'Qiaobing Xie'" , Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-variable-rate-audio-00.txt Date: Fri, 22 Oct 2004 23:46:47 +0300 Message-ID: <000d01c4b878$401c9da0$5401a8c0@hobel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <41781E80.6080400@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Hi Qiaobing Xie, -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qiaobing Xie > I like this solution and the draft summaries the issue/benefits very = well. Thanks for the flowers :-) >... >> * Is it a good idea to require ALL future I-Ds on audio (not only >> the variable clock frequency ones) to use the uRTR? >> * Or only those that do not fit the uRTR (fit =3D=3D subset of = prime >> factors)? >... > > Or, we can make uRTR a standard _option_ to all payloads - e.g., = whenever > rate param is set to 192kHz (or whatever value we end up with), it = would=20 > mean that uRTR is in use, if rate is set to any other value, it = implies > that the actual sampling rate is in use. I don't like optional mechanisms very much -- they are not good for interoperability, and increase the implementation burden. Also, what would you do as a receiver if you get a-law with 192 kHz = signaled sample rate -- use 8 kHz (which would be the common use of a-law) or 192 = kHz (which would be a perfectly legal use case as well)? Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 22 18:32:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04263 for ; Fri, 22 Oct 2004 18:32:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8Ac-00069G-Ud for avt-archive@ietf.org; Fri, 22 Oct 2004 18:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7hh-0005hA-Uo; Fri, 22 Oct 2004 18:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6my-0002Ai-Uc; Fri, 22 Oct 2004 17:17:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19015; Fri, 22 Oct 2004 17:17:28 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6zo-0001ZG-Ez; Fri, 22 Oct 2004 17:30:49 -0400 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i9MLHNa9028145; Fri, 22 Oct 2004 14:17:23 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I6000I6S5O2Y8@gateway2.EECS.Berkeley.EDU>; Fri, 22 Oct 2004 13:16:51 -0700 (PDT) Date: Fri, 22 Oct 2004 14:17:06 -0700 From: lazzaro In-reply-to: <4179034A.2060904@ericsson.com> To: Magnus Westerlund Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4179034A.2060904@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7BIT Cc: avt@ietf.org, mmusic@ietf.org Subject: [AVT] Re: [MMUSIC] maxptime X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7BIT On Oct 22, 2004, at 5:55 AM, Magnus Westerlund wrote: > I think I understand this, however the RTP timestamp rate > as I understand it for MIDI would be equal to the sample rate for the > audio produced? Yes -- for best results, the MIDI timestamp resolution should equal the audio sampling rate (44.1, 48, 96, or 192 KHz). > However I do hope that a sender at least correctly timestamp the RTP > packets sent. > Thus the RTP receiver can in the future start using the timing model > correctly. Sender time stamping is a MUST. > In conclusion I would suggest that you use another MIME parameter than > ptime and maxptime to indicate the desired behavior. OK, I'll redo this part of the I-D, and create new MIME parameters to partially convey what the I-D previously coded using ptime and maxptime. Unless a miracle happens, I won't make the Monday deadline with a new I-D pair ... so it will have to wait post-D.C. But I really hope we can make it to Last Call for the two I-Ds by the holidays ... > I also think that the format drafts needs to be more explicit on > considerations for the RTP timestamp. What rates are suitable, what > are the impact on playback timing. There seems to be a bit on this in > the guidelines, but I haven't had time to read it fully. See C.6.3 in the normative I-D. Part of Appendix C.6, the "SDP Interoperability Section", it might be easier to read all of C.6. Also, in the guide I-D, Section 4 discusses sender timing, Section 6 discusses receiver timing. > No, I am not questioning this timing model at all. It seems appropriate > for RTP based on your description. Great -- thinking it over last night, I'm pretty sure that if I was forced to define the media time for a packet with a single MIDI command whose command timestamp equals the RTP timestamp to be 1 RTP timestamp tick long (and not 0 ticks as it is now), the recovery journal would break. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 22 19:02:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10191 for ; Fri, 22 Oct 2004 19:02:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8d9-000877-5b for avt-archive@ietf.org; Fri, 22 Oct 2004 19:15:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7r0-0008F9-40; Fri, 22 Oct 2004 18:25:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7Rd-00025P-5V for avt@megatron.ietf.org; Fri, 22 Oct 2004 17:59:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26968 for ; Fri, 22 Oct 2004 17:59:28 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7eS-0004AQ-RL for avt@ietf.org; Fri, 22 Oct 2004 18:12:50 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i9MM0uYB027222; Fri, 22 Oct 2004 15:00:56 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i9MLpOUE025477; Fri, 22 Oct 2004 16:51:24 -0500 Message-ID: <41798337.6010407@motorola.com> Date: Fri, 22 Oct 2004 17:01:27 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan Wenger Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-variable-rate-audio-00.txt References: <000d01c4b878$401c9da0$5401a8c0@hobel> In-Reply-To: <000d01c4b878$401c9da0$5401a8c0@hobel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi, Stephan, Stephan Wenger wrote: ... >>Or, we can make uRTR a standard _option_ to all payloads - e.g., whenever >>rate param is set to 192kHz (or whatever value we end up with), it would >>mean that uRTR is in use, if rate is set to any other value, it implies >>that the actual sampling rate is in use. > > I don't like optional mechanisms very much -- they are not good for > interoperability, and increase the implementation burden. Of cause, you don't have to call it "optional" ;-) > Also, what would you do as a receiver if you get a-law with 192 kHz signaled > sample rate -- use 8 kHz (which would be the common use of a-law) or 192 kHz > (which would be a perfectly legal use case as well)? Well, I am thinking that individual payload formats will be allowed to decide whether or not to support uRTR when they are defined. For instance, if the payload format is being defined for a-law, the RFC could say "uRTR is not supported" since it would not add any value to it. In such a case, signaling 192 kHz to the receiver would be an error. On the other hand, when a codec considers variable rate operation an integral part of its capability (e.g., vmr-wb, amr-wb+), the corresponding payload specs could then explicitly say "uRTR SHOULD be supported." regards, -Qiaobing > > Stephan > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 25 04:05:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28960 for ; Mon, 25 Oct 2004 04:05:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM04N-0008TS-4s for avt-archive@ietf.org; Mon, 25 Oct 2004 04:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzoz-0001OY-70; Mon, 25 Oct 2004 04:03:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLAZM-0006tj-Bu for avt@megatron.ietf.org; Fri, 22 Oct 2004 21:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20236 for ; Fri, 22 Oct 2004 21:19:43 -0400 (EDT) Message-Id: <200410230119.VAA20236@ietf.org> Received: from [202.108.255.195] (helo=tom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLAmF-0002TY-VB for avt@ietf.org; Fri, 22 Oct 2004 21:33:06 -0400 Received: from buaa-fangweiwei (unknown [211.71.7.162]) by bjapp21 (Coremail) with SMTP id MKvxRpSxeUE9AAei.1 for ; Sat, 23 Oct 2004 09:19:21 +0800 (CST) X-Originating-IP: [211.71.7.162] Date: Sat, 23 Oct 2004 09:19:06 +0800 From: "Fangweiwei" To: "avt" X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 X-Spam-Score: 1.5 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 25 Oct 2004 04:03:11 -0400 Subject: [AVT] questions about jitter X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0702704375==" Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 --===============0702704375== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 YXZ0o6xoaaOhDQoNCglBcyBJIGtub3csIEppdHRlciBpcyBzdGFuZGFyZCBkZXZpYXRpb24gb2Yg aW50ZXItcGFja2V0IHRpbWUgLGJ1dCBBcyBpbiB0aGUgUkZDMzM1MDoNCiANCiAgICAgIGZKaXR0 ZXIgKz0gKDEuMC8xNi4wKSAqICgoZG91YmxlKWQgLSBmSml0dGVyKTsNCiAgIA0KICAgIEkgZG9u J3Qga25vdyB3aHkgUkZDIDM1NTAgY29tcHV0ZXMgaXQgYXMgdGhhdC4NCg0KICAgIE5vdyBJIGRv IHNvbWUgd29yayBhcyBOZXR3b3JrIEVtdWxhdGlvbi4gQW5kIHdoZW4gSSBjaGFuZ2VkIHRoZSB2 aXJ0dWFsIG5ldHdvcmssIGZyb20gZ29vZCB0byBiYWQgKGVnLnBhY2tldCBsb3NzKSwgSSBjYWxj dWxhdGUgdGhlIHBhY2tldCBqaXR0ZXIgdXNpbmcgc3RhbmRhcmQgZGV2aWF0aW9uIGZvbXVsYS5h bmQgSXQgcmVmbGVjdHMgdGhhdCB0aGUgbmV0d29yayBxdWFsaXR5LiBJZiBwYWNrZXQgbG9zcyB0 b28gbXVjaCwgdGhlIHBhY2tldCBqaXR0ZXIgd2lsbCBiZWNvbWUgYmlnLi4uDQoNCiAgICBidXQg dW5mb3J0dW5hdGVseSwgSSBmaW5kIHRoZSBmSml0dGVyIGNoYW5nZXMgc2xpZ2h0bHksYW5kIGl0 J3MgdmFsdWUgaGFzIGxpdHRsZSByZWxhdGlvbiB3aXRoIG5ldHdvcmsgcXVhbGl0eS5JIGRvbid0 IGtub3cgd2h5PyAgDQoNCiAgICBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBhbGwgeW91ciBhbnN3 ZXIhIA0KDQoNCiAgICAgICAgICAgICAgIFlvdXJzIFNpbmNlcmVseQ0KIAkJCQkNCg0KoaGhoaGh oaGhoaGhoaGhoUZhbmd3ZWl3ZWkNCqGhoaGhoaGhoaGhoaGhoaFmYW5nd2Vpd2VpQHRvbS5jb20N CqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNC0xMC0yMw0KDQogID09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gICAgICAgIA0KICBXZWl3ZWkgRmFuZyAg DQogIE5ldHdvcmsgRW11bGF0aW9uIEdyb3VwICAgICAgICAgICAgICAgICAgDQogIExhYiBmb3Ig Q29tcHV0ZXIgQXJjaGl0ZWN0dXJlIGFuZCBOZXR3b3JrIFRlY2hub2xvZ3kgDQogIEJlaSBIYW5n IFVuaXZlcnNpdHkNCiAgUC5CLjogMzcgWHVleXVhbiBSb2FkICBCZWlqaW5nIDEwMDA4MyAgUC5S LkNoaW5hICAgICAgIA0KICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQo= --===============0702704375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0702704375==-- From avt-bounces@ietf.org Mon Oct 25 04:06:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29104 for ; Mon, 25 Oct 2004 04:06:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM05x-0008Vs-GZ for avt-archive@ietf.org; Mon, 25 Oct 2004 04:20:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzp6-0001Og-8E; Mon, 25 Oct 2004 04:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzHZ-0007jz-Ly; Mon, 25 Oct 2004 03:28:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26560; Mon, 25 Oct 2004 03:28:43 -0400 (EDT) Received: from namasmtp01.nmss.com ([63.163.229.7] helo=nmss.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzUw-0007ku-Hr; Mon, 25 Oct 2004 03:42:36 -0400 Received: from ([192.168.100.65]) by namasmtp01.nmss.com with SMTP ; Mon, 25 Oct 2004 03:28:03 -0400 Received: from namasmtp02.nmss.com by [192.168.100.65] via smtpd (for namasmtp01.nmss.com [192.168.96.7]) with SMTP; Mon, 25 Oct 2004 03:33:50 -0400 To: avt@ietf.org, csp@csperkins.org, David.Lindbergh@polycom.com, internet-drafts@ietf.org, Magnus Westerlund , oritl@microsoft.com, restrick@cisco.com, "Even, Roni" , "Brough Turner" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Mon, 25 Oct 2004 03:30:34 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 10/25/2004 03:28:04 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE5ABDFB6EB3A8f9e8a93df938690918c0ABBE5ABDFB6EB3A" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 X-Mailman-Approved-At: Mon, 25 Oct 2004 04:03:12 -0400 Cc: Andrea Basso Subject: [AVT] Internet draft submission: draft-basso-avt-videoconreq-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c8611c7316981838cbe4195d07ac7fdb --0__=0ABBE5ABDFB6EB3A8f9e8a93df938690918c0ABBE5ABDFB6EB3A Content-type: text/plain; charset=us-ascii Attached you will find the updated draft-basso-avt-videoconreq-02.txt Summary of updates with respect to draft-basso-avt-videoconreq-01.txt 1. Document updated to be conformant to Guidelines to Authors of Internet-Drafts 2. Section 5.2.4 RateNotify command removed. 3. Section 7.1 Clarified reliable versus unreliable delivery. 4. Added Section 7.2 Transport alternatives 5. Section 7.4 Relation with signaling. Removed 6. Section 9.8 Interoperability with other protocols. Removed 7. Section 9.9 MUST has been changed to SHOULD. 8. Updated references (See attached file: draft-basso-avt-videoconreq-02.txt) Andrea Basso NMS Communications (732) 936-2118 --0__=0ABBE5ABDFB6EB3A8f9e8a93df938690918c0ABBE5ABDFB6EB3A Content-type: application/octet-stream; name="draft-basso-avt-videoconreq-02.txt" Content-Disposition: attachment; filename="draft-basso-avt-videoconreq-02.txt" Content-Transfer-Encoding: base64 DQoNCiAgIEF1ZGlvIFZpZGVvIFRyYW5zcG9ydCBHcm91cCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gQmFzc28gDQpEb2N1bWVudDogZHJhZnQtYmFz c28tYXZ0LXZpZGVvY29ucmVxLTAyLnR4dCAgICAgICAgIE5NUyBDb21tdW5pY2F0aW9ucyANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBPLkxldmluIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNaWNyb3NvZnQgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4uIElzbWFpbCANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBT eXN0ZW1zIA0KICAgRXhwaXJlczogQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBPY3RvYmVyIDIwMDQgDQogICAgDQogICAgDQogICAgDQogICAgICAgICAgIFJl cXVpcmVtZW50cyBmb3IgdHJhbnNwb3J0IG9mIHZpZGVvIGNvbnRyb2wgY29tbWFuZHMgDQogDQog ICAgDQpTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJ bnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIA0KICAgYWxsIHBy b3Zpc2lvbnMgb2YgUkZDIDM2NjcgWzJdLiAgDQogICAgDQogICBJbnRlcm5ldC1EcmFmdHMgYXJl IHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyANCiAgIFRhc2sg Rm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRo YXQgICAgICANCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9j dW1lbnRzIGFzICANCiAgIEludGVybmV0LURyYWZ0cy4gDQogICAgDQogICBJbnRlcm5ldC1EcmFm dHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMg DQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueSANCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ bnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIA0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiANCiAgICANCiAgIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0IA0KICAgVGhlIGxpc3Qgb2Yg SW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogDQogICBCeSBzdWJtaXR0 aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkg DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9y IHNoZSBpcyBhd2FyZSANCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFu eSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcyANCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2Vk LCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIFJGQyAzNjY4LiANCiANCiANCiANCkFi c3RyYWN0IA0KICAgIA0KICAgQSB2YXJpZXR5IG9mIHZpZGVvIGNvbW11bmljYXRpb24gc2Vydmlj ZXMgc3VjaCBhcyB2aWRlbyBjb25mZXJlbmNpbmcgDQogICBhbmQgdmlkZW8gbWVzc2FnaW5nIHJl bHkgb24gdGhlIGNhcGFiaWxpdHkgb2YgdmlkZW8gZW5jb2RlcnMgYW5kIA0KICAgZGVjb2RlcnMg dG8gcmVzcG9uZCB0byBjb250cm9sIGNvbW1hbmRzLiBUaGlzIGRvY3VtZW50IG91dGxpbmVzIHRo aXMgDQogICBzZXQgb2YgY29tbWFuZHMgYXMgd2VsbCBhcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0 aGVpciB0cmFuc3BvcnQuIA0KICAgIA0KICAgIA0KICAgICAgICAgDQogDQogDQpiYXNzbyAgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyAgQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2Ug MV0gDQoMICAgICAgICAgICAgICBDb2RlYyBDb250cm9sIFJlcXVpcmVtZW50cyAgICBPY3RvYmVy IDIwMDQgDQogDQogDQpDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgDQogICAgDQog ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsIA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwg ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGlu dGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbMV0uIA0KIA0KICAgIA0KVGFibGUg b2YgQ29udGVudHMgDQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIA0KICAgMi4gQmFja2dyb3VuZC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgIDMu IFZpZGVvIGNvZGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjMgDQogICA0LiBVc2UgQ2FzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0KICAgNS4gQ29kZWMgQ29tbWFuZHMuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgICAgIDUuMSBEZWNv ZGVyIENvbnRyb2wgQ29tbWFuZHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUg DQogICAgICA1LjIgRW5jb2RlciBDb250cm9sIENvbW1hbmRzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi42IA0KICAgNi4gR2VuZXJhbCByZXF1aXJlbWVudHMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNiANCiAgICAgIDYuMSBSZXVzZSBvZiBFeGlz dGluZyBQcm90b2NvbHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgICA2 LjIgTWFpbnRhaW4gRXhpc3RpbmcgUHJvdG9jb2wgSW50ZWdyaXR5Li4uLi4uLi4uLi4uLi4uLi4u Li4uLi43IA0KICAgICAgNi4zIEF2b2lkIER1cGxpY2F0aW5nIEV4aXN0aW5nIFByb3RvY29scy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAgICAgIDYuNCBFZmZpY2llbmN5Li4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICA3LiBDb2RlYyBDb250 cm9sIFJlcXVpcmVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43IA0K ICAgICAgNy4xIFJlbGlhYmxlIGFuZCBVbnJlbGlhYmxlIERlbGl2ZXJ5Li4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNyANCiAgICAgIDcuMiBUcmFuc3BvcnQgYWx0ZXJuYXRpdmVzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICA3LjMgQ2FwYWJpbGl0eSBkZXNj cmlwdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44IA0KICAgICAgNy40 IFJlbGF0aW9uIHdpdGggbWVkaWEgc2Vzc2lvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uOCANCiAgICAgIDcuNSBCaWRpcmVjdGlvbmFsIHRyYW5zcG9ydC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICA3LjYgRXh0ZW5zaWJpbGl0eS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44IA0KICAgICAgNy43IFVuaWNhc3Qg YW5kIE11bHRpY2FzdCBTdXBwb3J0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAg ICAgIDcuOCBUaW1lbHkgZGVsaXZlcnkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjkgDQogICA4LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgOS4gSUFOQSBDb25zaWRlcmF0aW9ucy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDEwLiBBY2tu b3dsZWRnbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjkgDQogICAxMS4gQ29weXJpZ2h0IE5vdGljZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi45IA0KICAgMTIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCANCiAgIDEzLiBJUFIgTm90aWNlcy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTAgDQogICBB dXRob3IncyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjExIA0KICAgIA0KICAgIA0KV2hhdCBpcyBuZXcgZnJvbSB2ZXJzaW9uIDAxIA0KICAg IA0KICAgMS4gRG9jdW1lbnQgdXBkYXRlZCB0byBiZSBjb25mb3JtYW50IHRvIEd1aWRlbGluZXMg dG8gQXV0aG9ycyBvZiANCiAgIEludGVybmV0LURyYWZ0cyANCiAgIDIuIFNlY3Rpb24gNS4yLjQg UmF0ZU5vdGlmeSBjb21tYW5kIHJlbW92ZWQuIA0KICAgMy4gU2VjdGlvbiA3LjEgQ2xhcmlmaWVk IFJlbGlhYmxlIHZlcnN1cyB1bnJlbGlhYmxlIGRlbGl2ZXJ5LiANCiAgIDQuIEFkZGVkIFNlY3Rp b24gNy4yIFRyYW5zcG9ydCBhbHRlcm5hdGl2ZXMgIA0KICAgNS4gU2VjdGlvbiA3LjQgUmVsYXRp b24gd2l0aCBzaWduYWxpbmcuIFJlbW92ZWQgIA0KICAgNi4gU2VjdGlvbiA5LjggSW50ZXJvcGVy YWJpbGl0eSB3aXRoIG90aGVyIHByb3RvY29scy4gUmVtb3ZlZCANCiAgIDcuIFNlY3Rpb24gOS45 IE1VU1QgaGFzIGJlZW4gY2hhbmdlZCB0byBTSE9VTEQuIA0KIA0KIA0KQmFzc28gICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDJdIA0K DCAgICAgICAgICAgICAgQ29kZWMgQ29udHJvbCBSZXF1aXJlbWVudHMgICAgT2N0b2JlciAyMDA0 IA0KIA0KIA0KICAgOC4gVXBkYXRlZCByZWZlcmVuY2VzIA0KICAgIA0KICAgIA0KV2hhdCBpcyBu ZXcgZnJvbSB2ZXJzaW9uIDAwIA0KIA0KICAgMS4gQWRkZWQgYm9pbGVycGxhdGUgdGV4dC4gIA0K ICAgMi4gU2VjLiAzOiBDbGFyaWZpY2F0aW9uIG9mIHRlcm1pbm9sb2d5LiAgDQogICAzLiBTZWMu IDYgOiBjbGFyaWZpY2F0aW9uIHRoZSByZWZlcmVuY2UgdG8gSUVURiBwcm90b2NvbHMgb25seS4g DQogICA0LiBIYXJtb25pemF0aW9uIHdpdGggSC4yNDEuIA0KICAgIA0KICAgIA0KICAgIA0KICAg IA0KMS4gSW50cm9kdWN0aW9uIA0KICAgIA0KICAgQSB2YXJpZXR5IG9mIHZpZGVvIGNvbW11bmlj YXRpb24gc2VydmljZXMgc3VjaCBhcyB2aWRlbyBjb25mZXJlbmNpbmcgDQogICBhbmQgdmlkZW8g bWVzc2FnaW5nIHJlbHkgb24gdGhlIGNhcGFiaWxpdHkgb2YgdmlkZW8gZW5jb2RlcnMgYW5kIA0K ICAgZGVjb2RlcnMgdG8gcmVzcG9uZCB0byBjb250cm9sIGNvbW1hbmRzLiBUaGlzIGRvY3VtZW50 IG91dGxpbmVzIGEgDQogICBnZW5lcmljIHNldCBvZiBjb21tYW5kcyBhcHBsaWNhYmxlIHRvIGEg dmFyaWV0eSBvZiB2aWRlbyBjb2RlY3MgYXMgDQogICB3ZWxsIGFzIHRoZSByZXF1aXJlbWVudHMg Zm9yIHRoZWlyIHRyYW5zcG9ydC4gDQogICAgDQoyLiBCYWNrZ3JvdW5kIA0KIA0KICAgUlRQIFs5 XSBpcyB0aGUgcHJvdG9jb2wgb2YgY2hvaWNlIGZvciB0aGUgZGVsaXZlcnkgb2YgcmVhbCB0aW1l IA0KICAgbWVkaWEuIFJUQ1AsIHRoZSBjb21wYW5pb24gY29udHJvbCBwcm90b2NvbCwgYWxsb3dz IHNvbWUgZm9ybSBvZiANCiAgIG1vbml0b3Jpbmcgb2YgdGhlIG1lZGlhIGRlbGl2ZXJ5LiBBbiBl bmhhbmNlZCBSVENQIGZlZWRiYWNrIHNjaGVtZSANCiAgIGVuYWJsaW5nIGEgZ2VuZXJpYyBkZWNv ZGVyIHRvIHByb3ZpZGUgaGludHMgdG8gdGhlIGNvcnJlc3BvbmRpbmcgDQogICBlbmNvZGVyIGlu IGNhc2Ugb2YgbmV0d29yayBsb3NzZXMgaGFzIGJlZW4gZGVzY3JpYmVkIGluIFs3XS4gU2ltaWxh ciANCiAgIHNvbHV0aW9ucyB3ZXJlIHByb3ZpZGVkIGZvciBzcGVjaWZpYyBjb2Rpbmcgc2NoZW1l cyBzdWNoIGFkIEguMjYxIFszXSANCiAgIEguMjYzIFs0XSBhbmQgTVBFRy00IFs1XS4gIA0KICAg Q3VycmVudGx5LCB0aGVyZSBpcyBubyBzdGFuZGFyZCBwcm90b2NvbCBzdXBwb3J0IHRoYXQgYWxs b3dzIGEgZ2l2ZW4gDQogICBhcHBsaWNhdGlvbiB0byBleGNoYW5nZSBjb250cm9sIGNvbW1hbmRz IHdpdGggYSBnaXZlbiBjb2RlYy4gIA0KIA0KICAgICANCjMuIFZpZGVvIGNvZGluZyANCiAgICAN CiAgIEluIGN1cnJlbnQgY29kaW5nIHNjaGVtZXMgc3VjaCBhcyBILjI2MSBbMl0sIEguMjYzIFsz XSwgTVBFRy0xLCAyLDQgDQogICBbNV0sIEguMjY0IFs2XSBwaWN0dXJlcyBjYW4gYmUgY29kZWQg d2l0aCB2YXJpb3VzIG1vZGFsaXRpZXMgaS5lLiANCiAgIGludHJhIG8gcHJlZGljdGVkIHBpY3R1 cmVzLiBGdXJ0aGVybW9yZSBwaWN0dXJlcyBjYW4gYmUgdXNlZCBhcyANCiAgIHJlZmVyZW5jZXMg aW4gdGhlIGRlY29kaW5nIHByb2Nlc3Mgb3Igbm90LiAgDQogICBNb3JlIHByZWNpc2VseSwgaW50 cmEgcGljdHVyZXMgYXJlIHBpY3R1cmVzIHRoYXQgY2FuIGJlIGRlY29kZWQgDQogICB3aXRob3V0 IGZpcnN0IGRlY29kaW5nIGFueSBvdGhlciBwaWN0dXJlLiBQcmVkaWN0ZWQgKG9yIG5vbi1pbnRy YSkgDQogICBwaWN0dXJlcyBtYXkgcmVxdWlyZSBkYXRhIGZyb20gb25lIG9yIG1vcmUgcHJldmlv dXNseSBkZWNvZGVkIA0KICAgcGljdHVyZXMgaW4gb3JkZXIgdG8gYmUgZGVjb2RlZC4gQSByZWZl cmVuY2UgcGljdHVyZSBpcyBhIHBpY3R1cmUgDQogICB0aGF0IGlzIHN0b3JlZCBpbiB0aGUgZGVj b2RlciBmb3IgdXNlIGFzIGEgcmVmZXJlbmNlIGluIHRoZSBkZWNvZGluZyANCiAgIHByb2Nlc3Mg b2Ygc29tZSBzdWJzZXF1ZW50IHBpY3R1cmUgaW4gdGhlIHZpZGVvIGJpdHN0cmVhbS4gRmluYWxs eSBhIA0KICAgbm9uLXJlZmVyZW5jZSBwaWN0dXJlIGlzIGEgcGljdHVyZSB0aGF0IGlzIG5vdCB1 c2VkIGFzIGEgcmVmZXJlbmNlIA0KICAgZm9yIHRoZSBkZWNvZGluZyBwcm9jZXNzIG9mIGFueSBv dGhlciBwaWN0dXJlIGluIHRoZSBiaXRzdHJlYW0uIFRoZSANCiAgIGNvbmNlcHRzIG9mIGludHJh IHZlcnN1cyBub24taW50cmEgYW5kIHJlZmVyZW5jZSB2ZXJzdXMgbm9uLXJlZmVyZW5jZSANCiAN CiANCkJhc3NvICAgICAgICAgICAgICAgICAgICBFeHBpcmVzICBBcHJpbCAyMDA1ICAgICAgICAg ICAgICAgICBbUGFnZSAzXSANCgwgICAgICAgICAgICAgIENvZGVjIENvbnRyb2wgUmVxdWlyZW1l bnRzICAgIE9jdG9iZXIgMjAwNCANCiANCiANCiAgIGFyZSBpbmRlcGVuZGVudC4gQSBwYXJ0aWN1 bGFyIHBpY3R1cmUgY2FuIGluIGdlbmVyYWwgYmUgYW55IG9uZSBvZiANCiAgIHRoZSBmb3VyIHR5 cGVzLCBpbnRyYSByZWZlcmVuY2UsIG5vbi1pbnRyYSByZWZlcmVuY2UsIGludHJhICANCiAgIG5v bi1yZWZlcmVuY2UsIG5vbi1pbnRyYSBub24tcmVmZXJlbmNlLiANCiANCiAgIEZ1cnRoZXJtb3Jl IHZpZGVvIHBpY3R1cmVzIGFyZSBub3QgY29kZWQgYXMgYSB3aG9sZSBidXQgYXJlIA0KICAgcGFy dGl0aW9uZWQgaW4gc21hbGwgYmxvY2tzIGNhbGxlZCBtYWNyb2JvbG9ja3MgKE1CKSBhbmQgZXZl cnkgTUIgaXMgDQogICBpbmRpdmlkdWFsbHkgY29kZWQuIE1CcyBhcmUgZ3JvdXBlZCB0b2dldGhl ciBpbiBzZXRzIG9mIHZhcmlhYmxlIA0KICAgc2l6ZS4gU3VjaCBzZXRzIGFyZSBjYWxsZWQsIGlu IGRlcGVuZGVuY2Ugb2YgdGhlIGNvZGluZyBzdGFuZGFyZCwgDQogICBzbGljZXMgb3IgR3JvdXAg b2YgQmxvY2tzIChHb0JzKS5TdWNoIHNldHMgb2YgTUIgY2FuIGJlIHNjYXR0ZXJlZCBpbiANCiAg IHRoZSBwaWN0dXJlLiANCiANCjQuIFVzZSBDYXNlcyANCiAgICANCiAgIFRoaXMgc2VjdGlvbiBk ZXNjcmliZXMgdXNlIGNhc2VzIG9mIGNvZGVjIGNvbnRyb2wgY29tbWFuZHMuICAgIA0KICAgIA0K ICAgMS4gQSB1c2UgY2FzZSBpbmNsdWRlcyBhbiBSVFAgdmlkZW8gbWl4ZXIgY29tcG9zaW5nIG11 bHRpcGxlIGVuY29kZWQgDQogICB2aWRlbyBzb3VyY2VzIGludG8gYSBzaW5nbGUgZW5jb2RlZCB2 aWRlbyBzdHJlYW0uIEVhY2ggdGltZSBhIHZpZGVvIA0KICAgc291cmNlIGlzIHRvIGJlIGFkZGVk IHRvIHRoZSB2aWRlbyBjb21wb3NpdGlvbiwgdGhlIFJUUCBtaXhlciBuZWVkcyANCiAgIHRvIHJl cXVlc3QgYW4gZW5jb2RlZCByZWZlcmVuY2UgcGljdHVyZSBmcm9tIHRoZSB2aWRlbyBzb3VyY2Ug b3IgYSANCiAgIHNwZWNpZmljIGFyZWEgb2YgdGhlIHBpY3R1cmUgZGVmaW5lZCBieSBvbmUgb3Ig bW9yZSBzbGljZXMuICANCiAgICANCiAgIDIuIEFub3RoZXIgdXNlIGNhc2UgaW5jbHVkZXMgYW4g UlRQIHZpZGVvIG1peGVyIHRoYXQgcmVjZWl2ZXMgDQogICBtdWx0aXBsZSBlbmNvZGVkIFJUUCB2 aWRlbyBzdHJlYW1zIGZyb20gY29uZmVyZW5jZSBwYXJ0aWNpcGFudHMgYW5kIA0KICAgZHluYW1p Y2FsbHkgc2VsZWN0cyBvbmUgb2YgdGhlIHN0cmVhbXMgdG8gYmUgaW5jbHVkZWQgaW4gaXRzIG91 dHB1dCANCiAgIFJUUCBzdHJlYW0uICBGb3IgZXZlcnkgbmV3IHZpZGVvIHN0cmVhbSBzZWxlY3Rl ZCwgdGhlIG1peGVyIHdpbGwgDQogICByZXF1ZXN0IGEgaW50cmEgcGljdHVyZSBmcm9tIHRoZSBy ZW1vdGUgc291cmNlIGluIG9yZGVyIGZvciB0aGUgDQogICByZWNlaXZpbmcgZW5kcG9pbnRzIHRv IGJlIGFibGUgdG8gZGVjb2RlIGFuZCBkaXNwbGF5IHRoZSBvdXRwdXQgDQogICBzdHJlYW0gc21v b3RobHkgd2hlbiB0aGUgc3dpdGNoIG9jY3Vycy4gVGhlIHZpZGVvIG1peGVyIGluIHRoaXMgDQog ICBzY2VuYXJpbyB3aWxsIHN0b3AgdGhlIGRlbGl2ZXJ5IG9mIHRoZSBjdXJyZW50IFJUUCBzdHJl YW0gYW5kIGl0IHdpbGwgDQogICB3YWl0IGZvciB0aGUgaW50cmEgcGljdHVyZSBmcm9tIHRoZSBz b3VyY2UgYmVmb3JlIGl0IHN3aXRjaGVzIHRvIHRoYXQgDQogICBzb3VyY2UuICAgICAgDQogDQog ICAzLiBBbm90aGVyIHVzZSBjYXNlIGluY2x1ZGVzIGEgZ2l2ZW4gYXBwbGljYXRpb24gdGhhdCBu ZWVkcyB0byBzaWduYWwgDQogICB0byB0aGUgcmVtb3RlIGVuY29kZXIgYSByZXF1ZXN0IG9mIGNo YW5nZSBpbiB0aGUgY29kaW5nIHN0cmF0ZWd5IA0KICAgYXNraW5nIHRvIGRlbGl2ZXIgdmlkZW8g cGljdHVyZXMgYXQgYSBsb3dlciBmcmFtZSByYXRlIGJ1dCB3aXRoIA0KICAgYmV0dGVyIHBpY3R1 cmUgcXVhbGl0eSBvciB2aWNlIHZlcnNhLiBTdWNoIHJlcXVlc3RzIG1heSBiZSBiYXNlZCBvbiAN CiAgIGlucHV0IGZyb20gdGhlIGVuZCB1c2VyLiANCiAgICANCiAgIDQuIEFub3RoZXIgdXNlIGNh c2UgaW5jbHVkZXMgYW4gYXBwbGljYXRpb24gdGhhdCBoYXMgYmVjYW1lIGF3YXJlIG9mIA0KICAg cGFja2V0IGxvc3NlcyBhbmQgaW4gb3JkZXIgdG8gbWl0aWdhdGUgdGhlaXIgZWZmZWN0IHJlcXVl c3RzIGFuIGludHJhICAgDQogICBwaWN0dXJlIGZyb20gdGhlIHJlbW90ZSBlbmNvZGVyLiBUaGlz IHdpbGwgc3RvcCB0aGUgc3BhdGlhbCBhbmQgDQogICB0ZW1wb3JhbCBwcm9wYWdhdGlvbiBvZiBj b2RpbmcgZXJyb3JzIGluaGVyZW50IHRvIGNvbW1vbmx5IHVzZWQgDQogICBwcmVkaWN0aXZlIHZp ZGVvIGNvZGluZyBzY2hlbWVzLiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIG9idGFpbiByYW5kb20g DQogICBhY2Nlc3MgcmVjb3Zlcnkgd2l0aG91dCBhIGZhc3QgdXBkYXRlLiBUaGlzIGlzIHNvbWV0 aW1lcyBjYWxsZWQgDQogICAiZ3JhZHVhbCBkZWNvZGVyIHJlZnJlc2giLiBTZWUgZm9yIGV4YW1w bGUgdGhlIHJlY292ZXJ5IHBvaW50IFNFSSANCiAgIG1lc3NhZ2UgaW4gSC4yNjQvQVZDIFs2XS4g DQogICAgDQogICA1LiBBbm90aGVyIHVzZSBjYXNlIGluY2x1ZGVzIGEgdmlkZW8gbWl4ZXIgdGhh dCBzd2l0Y2hlcyBpdHMgb3V0cHV0IA0KICAgc3RyZWFtIHRvIGEgbmV3IHZpZGVvIHNvdXJjZS4g VGhlIHZpZGVvIG1peGVyIHdpbGwgaW5zdHJ1Y3QgdGhlIA0KIA0KIA0KQmFzc28gICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDRdIA0K DCAgICAgICAgICAgICAgQ29kZWMgQ29udHJvbCBSZXF1aXJlbWVudHMgICAgT2N0b2JlciAyMDA0 IA0KIA0KIA0KICAgcmVjZWl2aW5nIGVuZHBvaW50cyBieSBtZWFucyBvZiBhIGNvZGVjIGNvbnRy b2wgY29tbWFuZCB0byBjb21wbGV0ZSANCiAgIHRoZSBkZWNvZGluZyBvZiB0aGUgY3VycmVudCBw aWN0dXJlIGFuZCB0aGVuIHdhaXQgZm9yIGEgbmV3IHZpZGVvIA0KICAgcmVmZXJlbmNlIHBpY3R1 cmUuIENvbmN1cnJlbnRseSwgdGhlIHZpZGVvIG1peGVyIHJlcXVlc3RzIGEgcmVmZXJlbmNlIA0K ICAgcGljdHVyZSBmcm9tIHRoZSBuZXcgdmlkZW8gc291cmNlIGFuZCBpbW1lZGlhdGVseSBzd2l0 Y2hlcyB0byB0aGUgbmV3IA0KICAgc291cmNlLiBPbmNlIHRoZSBuZXcgc291cmNlIHJlY2VpdmVz IHRoZSByZXF1ZXN0IGZvciB0aGUgcmVmZXJlbmNlIA0KICAgcGljdHVyZSBhbmQgYWN0cyBvbiBp dCwgdGhlIHJlY2VpdmluZyBlbmRwb2ludHMgd2lsbCByZXN0YXJ0IGRlY29kaW5nIA0KICAgYW5k IGRpc3BsYXlpbmcgdGhlIG5ldyBwaWN0dXJlLiAgDQogICBUaGUgbWFpbiBiZW5lZml0IG9mIHRo aXMgbWV0aG9kIGFzIG9wcG9zZWQgdG8gdGhlIHZpZGVvIG1peGVyIA0KICAgc3RvcHBpbmcgdmlk ZW8gdHJhbnNtaXNzaW9uIG9mIHRoZSBuZXcgc291cmNlIHVudGlsIGl0IGRldGVjdHMgYSBuZXcg DQogICByZWZlcmVuY2UgcGljdHVyZSwgYXMgaW4gdXNlIGNhc2UgMiwgaXMgdGhhdCB0aGUgdmlk ZW8gbWl4ZXIgZG9lcyBub3QgDQogICBoYXZlIHRvIGRpc2NvdmVyIHRoZSBiZWdpbm5pbmcgb2Yg YSByZWZlcmVuY2UgcGljdHVyZS4gVGhpcyBjYW4gDQogICBzaW1wbGlmeSB0aGUgdmlkZW8gbWl4 ZXIgdGFzayBlc3BlY2lhbGx5IGluIHRoZSBjYXNlIGluIHdoaWNoIHRoZSANCiAgIHBpY3R1cmUg aGFzIG11bHRpcGxlIHJlZmVyZW5jZSBwaWN0dXJlcy4gDQogDQogICA2LiBBbm90aGVyIHVzZSBj YXNlIGluY2x1ZGVzIGEgdmlkZW8gbWl4ZXIgdGhhdCBkeW5hbWljYWxseSBzZWxlY3RzIA0KICAg b25lIG9mIHRoZSByZWNlaXZlZCB2aWRlbyBzdHJlYW1zIHRvIGJlIHNlbnQgb3V0IHRvIHBhcnRp Y2lwYW50cyBhbmQgDQogICB0cmllcyB0byBwcm92aWRlIHRoZSBoaWdoZXN0IGJpdCByYXRlIHBv c3NpYmxlIHRvIGFsbCBwYXJ0aWNpcGFudHMgDQogICB3aGlsZSBtaW5pbWl6aW5nIHN0cmVhbSB0 cmFuc3JhdGluZy4gT25lIHdheSBvZiBhY2hpZXZpbmcgdGhpcyBpcyBmb3IgDQogICB0aGUgbWl4 ZXIgdG8gc2V0dXAgc2Vzc2lvbnMgd2l0aCBlbmRwb2ludHMgdXNpbmcgdGhlIG1heGltdW0gYml0 IHJhdGUgDQogICBhY2NlcHRlZCBieSB0aGF0IGVuZHBvaW50IGFuZCBieSB0aGUgY2FsbCBhZG1p c3Npb24gbWV0aG9kIHVzZWQgYnkgDQogICB0aGUgbWl4ZXIuICANCiAgIEJ5IG1lYW5zIG9mIGNv bW1hbmRzIHRoYXQgYWxsb3cgZmxvdyBjb250cm9sLCB0aGUgbWl4ZXIgY2FuIHRoZW4gDQogICBy ZWR1Y2UgdGhlIG1heGltdW0gYml0IHJhdGUgc2VudCBieSBlbmRwb2ludHMgdG8gdGhlIGxvd2Vz dCBjb21tb24gDQogICBkZW5vbWluYXRvciBvZiBhbGwgcmVjZWl2ZWQgc3RyZWFtcy4gQXMgdGhl IGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IgDQogICBjaGFuZ2VzIGR1ZSB0byBlbmRwb2ludHMg am9pbmluZyBvciBsZWF2aW5nLCB0aGUgbWl4ZXIgY2FuIGFkanVzdCB0aGUgDQogICBsaW1pdHMg dG8gd2hpY2ggZW5kcG9pbnRzIGNhbiBzZW5kIHRoZWlyIHN0cmVhbXMgdG8gbWF0Y2ggdGhlIG5l dyANCiAgIGxpbWl0LiANCiAgIFRoZSBtaXhlciB0aGVuIHdvdWxkIHJlcXVlc3QgYSBuZXcgbWF4 aW11bSBiaXQgcmF0ZSwgd2hpY2ggaXMgZXF1YWwgDQogICBvciBsZXNzIHRoYW4gdGhlIG1heGlt dW0gYml0LXJhdGUgbmVnb3RpYXRlZCBhdCBzZXNzaW9uIHNldHVwLCBmb3IgYSANCiAgIHNwZWNp ZmljIG1lZGlhIHN0cmVhbSwgYW5kIHRoZSByZW1vdGUgZW5kcG9pbnQgY2FuIHJlc3BvbmQgd2l0 aCB0aGUgDQogICBhY3R1YWwgYml0LXJhdGUgdGhhdCBpdCBjYW4gc3VwcG9ydC4gIA0KICAgIA0K IA0KNS4gQ29kZWMgQ29tbWFuZHMgDQogICAgDQogICBUaGUgZW5zZW1ibGUgb2YgY29tbWFuZHMg ZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBpcyBkaXZpZGVkIGludG8gDQogICB0d28gc2V0cy4g VGhlIGZpcnN0IHNldCBpbmNsdWRlcyBjb21tYW5kcyB0aGF0IGFyZSBzZW50IHRvIGRlY29kZXJz IA0KICAgdHlwaWNhbGx5IHRvIGNvbnRyb2wgdGhlIHByZXNlbnRhdGlvbiBvZiB0aGUgY29udGVu dC4gVGhlIHNlY29uZCBzZXQgDQogICBpbmNsdWRlcyBjb21tYW5kcyB0aGF0IGFyZSBzZW50IHRv IHJlbW90ZSBlbmNvZGVycy4gDQogICAgDQo1LjEgRGVjb2RlciBDb250cm9sIENvbW1hbmRzIA0K IA0KICAgMS4gVmlkZW9GcmVlemVQaWN0dXJlICANCiAgICAgDQogICBJdCBpbnN0cnVjdHMgdGhl IHZpZGVvIGRlY29kZXIgdG8gY29tcGxldGUgdGhlIGRlY29kaW5nIG9mIHRoZSANCiAgIGN1cnJl bnQgdmlkZW8gcGljdHVyZSBhbmQgc3Vic2VxdWVudGx5IGRpc3BsYXkgaXQgdW50aWwgYSB0aW1l b3V0IA0KICAgcGVyaW9kIGlzIGVsYXBzZWQgb3IgdGhlIHJlY2VpcHQgb2YgYSBtZXNzYWdlIHRo YXQgaW5kaWNhdGVzIHRoZSANCiAgIHJlbGVhc2Ugb2YgdGhlIGZyb3plbiBwaWN0dXJlIGFuZCBy ZXN1bWUgbm9ybWFsIGRlY29kaW5nIGFuZCANCiAgIHByZXNlbnRhdGlvbi4gTm90ZSB0aGF0IHRo ZSBmcmVlemUgcGljdHVyZSByZWxlYXNlIGNvbW1hbmQgaXMgcGFydCBvZiANCiANCiANCkJhc3Nv ICAgICAgICAgICAgICAgICAgICBFeHBpcmVzICBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICBb UGFnZSA1XSANCgwgICAgICAgICAgICAgIENvZGVjIENvbnRyb2wgUmVxdWlyZW1lbnRzICAgIE9j dG9iZXIgMjAwNCANCiANCiANCiAgIHRoZSBILjI2MSwgSC4yNjIsIEguMjYzIGFuZCBILjI2NCBi aXRzdHJlYW1zLiBDb2Rpbmcgc2NoZW1lcyB0aGF0IA0KICAgc3VwcG9ydCBwaWN0dXJlIGZyZWV6 ZSByZWxlYXNlIGluIHRoZWlyIGJpdHN0cmVhbXMsIE1VU1QgdXNlIGZyZWV6ZSANCiAgIHJlbGVh c2UgdG8gc2lnbmFsIHRoZSByZW1vdGUgZW5kIHRvIHJlc3VtZSBkZWNvZGluZy4gIA0KICAgSC4y NjQgc3BlY2lmaWVzIGEgdGltZW91dCBwZXJpb2Qgb2YgYXQgbGVhc3QgNiBzZWNvbmRzIGZyb20g dGhlIA0KICAgcmVjZWlwdCBvZiB0aGUgVmlkZW9GcmVlemVQaWN0dXJlLiBTZWUgdXNlIGNhc2Ug NSBmb3IgYW4gZXhhbXBsZSBvZiANCiAgIGhvdyBzdWNoIGNvbW1hbmQgbWlnaHQgYmUgdXNlZC4g DQogICAgDQo1LjIgRW5jb2RlciBDb250cm9sIENvbW1hbmRzIA0KICAgIA0KICAgMS4gdmlkZW9G YXN0VXBkYXRlUGljdHVyZSAgDQogICAgDQogICBBICJmYXN0IHVwZGF0ZSIsIGFsc28ga25vd24g YXMgYW4gImluc3RhbnRhbmVvdXMgZGVjb2RlciByZWZyZXNoIiwgDQogICBpbnZvbHZlcyBzZW5k aW5nIGFuIGludHJhIHBpY3R1cmUgdG8gYSBkZWNvZGVyIGFuZCB0aGVyZWFmdGVyIA0KICAgcmVm cmFpbmluZyBmcm9tIHVzaW5nIGFueSBwaWN0dXJlIHNlbnQgcHJpb3IgdG8gdGhhdCBpbnRyYSBw aWN0dXJlIGFzIA0KICAgYSByZWZlcmVuY2UgZm9yIHRoZSBkZWNvZGluZyBwcm9jZXNzIG9mIGFu eSBzdWJzZXF1ZW50IHBpY3R1cmUgc2VudCANCiAgIGluIHRoZSBzdHJlYW0uIA0KICAgVGhlIHZp ZGVvRmFzdFVwZGF0ZVBpY3R1cmUgY29tbWFuZCBpbnN0cnVjdHMgdGhlIHZpZGVvIGVuY29kZXIg dG8gDQogICBjb21wbGV0ZSB0aGUgZW5jb2Rpbmcgb2YgdGhlIGN1cnJlbnQgdmlkZW8gcGljdHVy ZSBhbmQgdG8gZ2VuZXJhdGUgYSANCiAgIGZ1bGwgaW50cmEgcGljdHVyZSBhdCB0aGUgZWFybGll c3Qgb3Bwb3J0dW5pdHkuIFRoZSBldmFsdWF0aW9uIG9mIA0KICAgc3VjaCBvcHBvcnR1bml0eSBp bmNsdWRlcyB0aGUgY3VycmVudCBlbmNvZGVyIGNvZGluZyBzdHJhdGVneSBhbmQgdGhlIA0KICAg Y3VycmVudCBhdmFpbGFibGUgbmV0d29yayByZXNvdXJjZXMuIEFuIEguMjY0IGVuY29kZXIgY2Fu IHJlYWN0IHRvIGEgDQogICBWaWRlb0Zhc3RVcGRhdGVQaWN0dXJlIGNvbW1hbmQgd2l0aCBhbiBJ RFIgcHJvY2VkdXJlIG9yIGEgZ3JhZHVhbCANCiAgIHJlY292ZXJ5IHByb2NlZHVyZSBhcyBzcGVj aWZpZWQgaW4gWzEwXSANCiAgICANCiAgIEludHJhIHBpY3R1cmVzLCBpbmRlcGVuZGVudGx5IGZy b20gdGhlIGluc3RhbnQgaW4gdGltZSB3aGVuIHRoZXkgYXJlIA0KICAgZW5jb2RlZCwgYXJlIGlu IGdlbmVyYWwgc2V2ZXJhbCB0aW1lcyBsYXJnZXIgaW4gc2l6ZSB0aGFuIHByZWRpY3RlZCANCiAg IHBpY3R1cmVzLiAgVGh1cyBpbiBzY2VuYXJpb3MgaW4gd2hpY2ggdGhlIGF2YWlsYWJsZSBiYW5k d2lkdGggaXMgDQogICBzbWFsbCB0aGUgdXNlIG9mIGEgaW50cmEgcGljdHVyZSBpbXBsaWVzIGEg ZGVsYXkgdGhhdCBpcyANCiAgIHNpZ25pZmljYW50bHkgbG9uZ2VyIHRoYW4gdGhlIHR5cGljYWwg cGljdHVyZSBkdXJhdGlvbi4gIA0KIA0KICAgMi4gVmlkZW9UZW1wb3JhbFNwYXRpYWxUcmFkZU9m ZihpbmRleCkgIA0KICAgIA0KICAgSXQgaW5zdHJ1Y3RzIHRoZSB2aWRlbyBlbmNvZGVyIHRvIGNo YW5nZSBpdHMgdHJhZGUtb2ZmIGJldHdlZW4gDQogICB0ZW1wb3JhbCBhbmQgc3BhdGlhbCByZXNv bHV0aW9uLiBJbmRleCBhc3N1bWVzIHZhbHVlcyBmcm9tIE8gdG8gMzEgdG8gDQogICBpbmRpY2F0 ZSBtb25vdG9uaWNhbGx5IGEgZGVzaXJlIGZvciBoaWdoZXIgZnJhbWUgcmF0ZS4gIA0KICAgSW4g Z2VuZXJhbCB0aGUgZW5jb2RlciByZWFjdGlvbiB0aW1lIG1heSBiZSBzaWduaWZpY2FudGx5IGxv bmdlciB0aGFuIA0KICAgdGhlIHR5cGljYWwgcGljdHVyZSBkdXJhdGlvbi4gDQogDQogICAzLiAg UmF0ZVJlcXVlc3QoTWF4Qml0cmF0ZSkgDQogICAgDQogICBJdCBpbnN0cnVjdHMgdGhlIGZhci1l bmQgZW5jb2RlciB0byBjaGFuZ2UgdGhlIG1heGltdW0gYml0IHJhdGUgb2YgDQogICB0aGUgZ2l2 ZW4gbWVkaWEgc3RyZWFtIGJlaW5nIHRyYW5zbWl0dGVkLiBNYXhCaXRSYXRlIGluZGljYXRlcywg aW4gDQogICB1bml0cyBvZiAxMDAgYml0L3MsIHRoZSBuZXcgcmVxdWVzdGVkIG1heGltdW0gYml0 IHJhdGUgZm9yIHRoZSANCiAgIGFzc29jaWF0ZWQgbWVkaWEgc3RyZWFtLiBUaGUgbmV3IHJlcXVl c3RlZCBiaXQgcmF0ZSBoYXMgdG8gYmUgZXF1YWwgDQogICB0byBvciBsZXNzIHRoYW4gdGhlIGJp dCByYXRlIG5lZ290aWF0ZWQgZHVyaW5nIHNlc3Npb24gc2V0dXAuIA0KICAgIA0KIA0KNi4gR2Vu ZXJhbCByZXF1aXJlbWVudHMgDQogDQogDQogDQpCYXNzbyAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyAgQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQoMICAgICAgICAgICAg ICBDb2RlYyBDb250cm9sIFJlcXVpcmVtZW50cyAgICBPY3RvYmVyIDIwMDQgDQogDQogDQo2LjEg IFJldXNlIG9mIEV4aXN0aW5nIFByb3RvY29scyAgDQogICAgDQogICBUaGUgY29kZWMgY29udHJv bCBtZXNzYWdlcyBzaG91bGQgYmUgdHJhbnNwb3J0ZWQgdXNpbmcgYW4gYWxyZWFkeSANCiAgIGV4 aXN0aW5nIHRyYW5zcG9ydCBwcm90b2NvbCB3aGVuZXZlciBwb3NzaWJsZS4gVGhlIHRyYW5zcG9y dCBwcm90b2NvbCANCiAgIHNob3VsZCBhbGxvdyBhdCBhIG1pbmltdW0gdGhlIGxldmVyYWdpbmcg b2YgaXRzIHNlY3VyaXR5IGVsZW1lbnRzLiANCiANCjYuMiAgTWFpbnRhaW4gRXhpc3RpbmcgUHJv dG9jb2wgSW50ZWdyaXR5IA0KICAgIA0KICAgSW4gbWVldGluZyB0aGUgcmVxdWlyZW1lbnQgb2Yg U2VjdGlvbiA3LCB0aGUgY29kZWMgY29udHJvbCB0cmFuc3BvcnQgDQogICBtZWNoYW5pc20gTVVT VCBOT1QgYnJlYWsgZXhpc3RpbmcgcHJvdG9jb2xzIG9yIGNhdXNlIGJhY2t3YXJkIA0KICAgY29t cGF0aWJpbGl0eSBwcm9ibGVtcy4gIA0KICAgIA0KNi4zIEF2b2lkIER1cGxpY2F0aW5nIEV4aXN0 aW5nIFByb3RvY29scyANCiAgICANCiAgIFRoZSBjb2RlYyBjb250cm9sIG1lY2hhbmlzbSBTSE9V TEQgTk9UIGR1cGxpY2F0ZSB0aGUgZnVuY3Rpb25hbGl0eSBvZiANCiAgIGV4aXN0aW5nIElFVEYg cHJvdG9jb2xzLiAgVGhlIGZvY3VzIG9mIGNvZGVjIGNvbnRyb2wgaXMgbmV3IA0KICAgZnVuY3Rp b25hbGl0eSBub3QgYWRkcmVzc2VkIGJ5IGV4aXN0aW5nIElFVEYgcHJvdG9jb2xzIG9yIGV4dGVu ZGluZyANCiAgIGV4aXN0aW5nIElFVEYgcHJvdG9jb2xzIHdpdGhpbiB0aGUgc3RydWN0dXJlcyBv ZiB0aGUgcmVxdWlyZW1lbnQgaW4gDQogICBTZWN0aW9uIDcuICBXaGVyZSBhbiBleGlzdGluZyBJ RVRGIHByb3RvY29sIGNhbiBiZSBncmFjZWZ1bGx5IA0KICAgZXh0ZW5kZWQgdG8gc3VwcG9ydCBj b2RlYyBjb250cm9sIHJlcXVpcmVtZW50cywgc3VjaCBleHRlbnNpb25zIGFyZSANCiAgIGFjY2Vw dGFibGUgYWx0ZXJuYXRpdmVzIGZvciBtZWV0aW5nIHRoZSByZXF1aXJlbWVudHMuIA0KIA0KNi40 IEVmZmljaWVuY3kgDQogICAgDQogICBUaGUgY29kZWMgY29udHJvbCB0cmFuc3BvcnQgbWVjaGFu aXNtIFNIT1VMRCBlbXBsb3kgcHJvdG9jb2wgZWxlbWVudHMgDQogICBrbm93biB0byByZXN1bHQg aW4gZWZmaWNpZW50IG9wZXJhdGlvbi4gIFRlY2huaXF1ZXMgdG8gYmUgY29uc2lkZXJlZCANCiAg IGluY2x1ZGUgcmUtdXNlIG9mIHRyYW5zcG9ydCBjb25uZWN0aW9ucyBhY3Jvc3Mgc2Vzc2lvbnMg aS5lLiBjb2RlYyANCiAgIGNvbnRyb2wgbWVzc2FnZXMgdGhhdCBjb250cm9scyBkaWZmZXJlbnQg bWVkaWEgc2Vzc2lvbnMgbWF5IGJlIA0KICAgYWdncmVnYXRlZCBvbiBvbmUgY29kZWMgY29udHJv bCB0cmFuc3BvcnQgY2hhbm5lbCBhbmQgcGlnZ3liYWNraW5nIG9mIA0KICAgcmVzcG9uc2VzIG9u IHJlcXVlc3RzIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiAgDQogDQogDQo3LiBDb2RlYyBDb250 cm9sIFJlcXVpcmVtZW50cyANCiANCjcuMSBSZWxpYWJsZSBhbmQgVW5yZWxpYWJsZSBEZWxpdmVy eS4gDQogICAgDQogICBUaGUgY29tbWFuZHMgVmlkZW9QaWN0dXJlRnJlZXplIGFuZCBWaWRlb1Rl bXBvcmFsU3BhdGlhbFRyYWRlT2ZmIGFuZCAgDQogICB0aGUgY29tbWFuZHMgcmVsYXRpdmUgdG8g ZmxvdyBjb250cm9sIGFzIFJhdGVSZXF1ZXN0IHJlcXVpcmUgYSANCiAgIHJlbGlhYmxlIGRlbGl2 ZXJ5LiAgDQogDQogICBUaGUgY29tbWFuZCB2aWRlb0Zhc3RVcGRhdGVQaWN0dXJlIGltcGxpZXMg YSBzcGVjaWZpYyBtb2RpZmljYXRpb24gb2YgDQogICB0aGUgbWVkaWEsIHdoaWNoIGlzIGRlbGl2 ZXJlZCBpbiBhbiB1bnJlbGlhYmxlIGZhc2hpb24uIEdpdmVuIHRoYXQgDQogICB0aGUgZGVsaXZl cnkgb2YgdGhlIG1lZGlhIGlzIHVucmVsaWFibGUsIHRoZSBzZW5kZXIgY2Fubm90IHJlbHkgb24g DQogICB0aGUgZmFjdCB0aGF0IHRoZSByZXF1ZXN0IGhhcyBiZWVuIHNhZmVseSBkZWxpdmVyZWQg YnV0IG5lZWRzIHRvIA0KICAgYXNzdXJlIHRoYXQgdGhlIHJlcXVlc3RlZCBtb2RpZmljYXRpb24g b2YgdGhlIGRhdGEgKGkuZS4sIGluc2VydGlvbiANCiAgIG9mIGEgcmVmZXJlbmNlIHBpY3R1cmUp IGlzIHJlY2VpdmVkIGJlZm9yZSB0YWtpbmcgYW55IGFjdGlvbi4gVGh1cyANCiAgIHRoZSByZWNl aXZlciBoYXMgYWx3YXlzIHRvICJvYnNlcnZlIiB0aGUgaW5jb21pbmcgZGF0YSBmb3IgdGhlIA0K ICAgcmVxdWVzdGVkIGNoYW5nZSBpbmRlcGVuZGVudGx5IG9mIHRoZSBtZXRob2Qgb2YgZGVsaXZl cnkgb2YgdGhlIA0KICAgdmlkZW9GYXN0VXBkYXRlUGljdHVyZSBjb21tYW5kLiBWaWRlb0Zhc3RV cGRhdGVQaWN0dXJlIGNhbiBiZSB0aHVzIA0KIA0KIA0KQmFzc28gICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDddIA0KDCAgICAgICAg ICAgICAgQ29kZWMgQ29udHJvbCBSZXF1aXJlbWVudHMgICAgT2N0b2JlciAyMDA0IA0KIA0KIA0K ICAgZGVsaXZlcmVkIG92ZXIgYW4gdW5yZWxpYWJsZSBjaGFubmVsLiBJZiB0aGUgZXhwZWN0ZWQg Y2hhbmdlIGluIHRoZSANCiAgIG1lZGlhIGRvZXMgbm90IGhhcHBlbiB0aGUgY29tbWFuZCB3aWxs IGJlIHJldHJhbnNtaXR0ZWQuIA0KIA0KNy4yIFRyYW5zcG9ydCBhbHRlcm5hdGl2ZXMgDQogICAg DQogICBDb21tYW5kcyBzdWNoIFZpZGVvVGVtcG9yYWxTcGF0aWFsVHJhZGVPZmYgYW5kIFJhdGVS ZXF1ZXN0IHJlbGF0aXZlIA0KICAgdG8gZmxvdyBjb250cm9sIGNhbiBiZSBpbnRlcnByZXRlZCBh cyBjaGFuZ2VzIG9mIGEgZ2l2ZW4gcHJlc2VudGF0aW9uIA0KICAgZGVzY3JpcHRpb24gYW5kIHBv dGVudGlhbGx5IGNhcnJpZWQgdmlhIGV4aXN0aW5nIHByb3RvY29scyBzdWNoICBTRFAuIA0KICAg VGhpcyBpcyBub3QgdGhlIGNhc2Ugb2YgdGhlIFZpZGVvRmFzdFVwZGF0ZVBpY3R1cmUgYW5kIA0K ICAgVmlkZW9QaWN0dXJlRnJlZXplIGNvbW1hbmRzLiAgDQogDQo3LjMgQ2FwYWJpbGl0eSBkZXNj cmlwdGlvbiAgDQogICAgDQogICBUaGUgY2FwYWJpbGl0eSBvZiBjb2RlYyBjb250cm9sIGZvciBl YWNoIHN1cHBvcnRlZCBtZXNzYWdlIHNob3VsZCBiZSANCiAgIGRlc2NyaWJlZCBhbmQgbmVnb3Rp YXRlZCwgZm9yIGV4YW1wbGUgdXNpbmcgU0RQIG9mZmVyL2Fuc3dlciwgZm9yIA0KICAgYm90aCBz ZW5kZXJzIGFuZCByZWNlaXZlcnMgZHVyaW5nIHNlc3Npb24gc2V0dXAuIFRoZSB0cmFuc3BvcnQg DQogICBwcm90b2NvbCB1c2VkIGZvciB0aGUgZGVsaXZlcnkgb2YgY29kZWMgY29udHJvbCBtZXNz YWdlcyBzaG91bGQgYWxzbyANCiAgIGJlIHNwZWNpZmllZCBhcyBvZiBzZXNzaW9uIHNldHVwLiAg IA0KIA0KNy40IFJlbGF0aW9uIHdpdGggbWVkaWEgc2Vzc2lvbiANCiAgICAgDQogICBUaGUgZGVs aXZlcnkgY2hhbm5lbCBvZiB0aGUgY29kZWMgY29udHJvbCBtZXNzYWdlcyBtdXN0IGJlIGFzc29j aWF0ZWQgDQogICB3aXRoIHRoZSBtZWRpYSBzZXNzaW9uIGl0IGNvbnRyb2xzLiBVc2luZyBvbmUg Y29kZWMgY29udHJvbCBjaGFubmVsIA0KICAgcGVyIG1lZGlhIHNlc3Npb24gYW5kIGFzc29jaWF0 aW5nIHRoZSB0d28gY2hhbm5lbHMgZHVyaW5nIHNlc3Npb24gDQogICBzZXR1cCBjb3VsZCBhY2hp ZXZlIHRoaXMgcHVycG9zZS4gQWx0ZXJuYXRpdmVseSBvbmUgbWVkaWEgY29udHJvbCANCiAgIGNo YW5uZWwgY291bGQgYmUgdXNlZCBmb3IgbXVsdGlwbGUgbWVkaWEgc2Vzc2lvbnMuIEluIHRoaXMg Y2FzZSB0aGUgDQogICBjb250cm9sbGVkIG1lZGlhIHNlc3Npb24gTVVTVCBiZSBpZGVudGlmaWVk IGluIGVhY2ggY29kZWMgY29udHJvbCANCiAgIG1lc3NhZ2UuIA0KICAgIA0KICAgVGhlIHRyYW5z cG9ydCBjaGFubmVsIG9mIHRoZSBjb2RlYyBjb250cm9sIG1lc3NhZ2VzIHNob3VsZCBmb2xsb3cg YSANCiAgIHNpbWlsYXIgcGF0aCB0byB0aGF0IG9mIHRoZSBtZWRpYSBzZXNzaW9uIGl0IGNvbnRy b2xzLiAgDQogICBJbnRlci1vcGVyYWJpbGl0eSB3aXRoIG90aGVyIHN0YW5kYXJkcyBmb3IgY29k ZWMgY29udHJvbCBkZWxpdmVyeSANCiAgIG1pZ2h0IGNhdXNlIGEgZGV2aWF0aW9uIGZyb20gdGhp cyByZXF1aXJlbWVudC4gDQogDQogICAgICAgDQo3LjUgQmlkaXJlY3Rpb25hbCB0cmFuc3BvcnQg DQogICAgDQogICBNZXNzYWdlcyBjYW4gYmUgb3JpZ2luYXRlZCBmcm9tIHJlY2VpdmVycyBhcyB3 ZWxsIGFzIGEgc2VuZGVycyB0aHVzIA0KICAgdGhlIHRyYW5zcG9ydCBtZWNoYW5pc20gbXVzdCBh bGxvdyBiaS1kaXJlY3Rpb25hbCBleGNoYW5nZSBvZiANCiAgIG1lc3NhZ2VzLiANCiAgICANCjcu NiBFeHRlbnNpYmlsaXR5IA0KICAgIA0KICAgQ29kZWMgY29udHJvbCBtZXNzYWdlIHN5bnRheCBz aG91bGQgYmUgZXh0ZW5zaWJsZSB0byBlYXNpbHkgc3VwcG9ydCANCiAgIHRoZSBhZGRpdGlvbiBv ZiBuZXcgY29udHJvbCBtZXNzYWdlcy4gIA0KICAgIA0KNy43IFVuaWNhc3QgYW5kIE11bHRpY2Fz dCBTdXBwb3J0ICANCiAgICANCg0KIA0KIA0KQmFzc28gICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDhdIA0KDCAgICAgICAgICAgICAg Q29kZWMgQ29udHJvbCBSZXF1aXJlbWVudHMgICAgT2N0b2JlciAyMDA0IA0KIA0KIA0KICAgVGhl IGNvZGVjIGNvbnRyb2wgdHJhbnNwb3J0IE1VU1Qgd29yayBhbmQgc2NhbGUgZm9yIG1lZGlhIHNl c3Npb25zIA0KICAgdGhhdCB1c2UgcG9pbnQtdG8tcG9pbnQgdW5pY2FzdC4gIA0KICAgIA0KICAg VGhlIGNvZGVjIGNvbnRyb2wgdHJhbnNwb3J0IE1VU1Qgd29yayBhbmQgc2NhbGUgZm9yIG1lZGlh IHNlc3Npb25zIA0KICAgdGhhdCB1c2UgU1NNIChTb3VyY2UgU3BlY2lmaWMgTXVsdGljYXN0KSBh bmQgaGFzIGEgc21hbGwgdG8gbW9kZXJhdGUgDQogICBncm91cCBzaXplLiANCiAgICANCiAgIFRo ZSBjb2RlYyBjb250cm9sIHRyYW5zcG9ydCB3aWxsIG5vdCBhZGRyZXNzIEFTTSAoQW55IFNvdXJj ZSANCiAgIE11bHRpY2FzdCkgbWVkaWEgc2Vzc2lvbnMgaW4gd2hpY2ggbWVkaWEgc291cmNlcyBh cmUgbm90IGtub3duIHVudGlsIA0KICAgdGhleSBzdGFydCB0cmFuc21pc3Npb24uICANCiANCiAN CjcuOCBUaW1lbHkgZGVsaXZlcnkgDQogICAgDQogICBGb3Igc29tZSB2aWRlbyBzZXJ2aWNlcyB0 aGUgYWJpbGl0eSB0byB0cmFuc21pdCBjb2RlYyBjb250cm9sIA0KICAgY29tbWFuZHMgaW4gYSB0 aW1lbHkgZmFzaGlvbiBpcyBlc3NlbnRpYWwgdG8gdGhlIGRlbGl2ZXJ5IG9mIGEgaGlnaCANCiAg IHF1YWxpdHkgdXNlciBleHBlcmllbmNlLiBUaGUgZGVsYXkgaW50cm9kdWNlZCBieSB0aGUgdHJh bnNwb3J0IA0KICAgcHJvdG9jb2wgU0hPVUxEIGJlIG5lZ2xpZ2libGUgd2l0aCByZXNwZWN0IG9m IHRoZSB0aW1lIGNvbnN0YW50cyBvZiANCiAgIHRoZSBkZWxpdmVyZWQgbWVkaWEgc3RyZWFtLiAg IA0KIA0KIA0KOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogICAgDQogICA8VE9ETz4gDQog ICAgDQo5LiBJQU5BIENvbnNpZGVyYXRpb25zIA0KIA0KICAgPFRPRE8+IA0KIA0KMTAuIEFja25v d2xlZGdtZW50cyANCiANCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gYWNrbm93bGVkZ2Ug dGhlIGNvbW1lbnRzIGZyb20gYXJvdW5kIHRoZSANCiAgIENvbW11bml0eSBpbiBoZWxwaW5nIHJl ZmluZSB0aGlzIGRvY3VtZW50LiBQYXJ0aWN1bGFyIHJlY29nbml0aW9uIA0KICAgZ29lcyB0byBS b25pIEV2ZW5zLiAgDQogICAgDQogDQoxMS4gQ29weXJpZ2h0IE5vdGljZSANCiANCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLiAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0IA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250 YWluZWQgaW4gQkNQIDc4LCBhbmQgDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRo ZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLiANCiAgICANCiAgIFRoaXMgZG9jdW1l bnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBh biANCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElP TiBIRS9TSEUgUkVQUkVTRU5UUyANCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCANCiAgIEVOR0lORUVSSU5HIFRBU0sg Rk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgDQogICBJ TkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0Yg VEhFIA0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMg T1IgQU5ZIElNUExJRUQgDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gDQogDQogDQpCYXNzbyAgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyAgQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgOV0gDQoMICAg ICAgICAgICAgICBDb2RlYyBDb250cm9sIFJlcXVpcmVtZW50cyAgICBPY3RvYmVyIDIwMDQgDQog DQogDQogDQogDQogICAgDQoxMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyANCiAgICAgICAgICAg ICAgICAgICAgIA0KICAgIA0KICAgIA0KICAgMSBTLiBCcmFkbmVyLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCANCiAgICAgIExldmVscyIsIEJDUCAx NCwgUkZDIDIxMTksIE1hcmNoIDE5OTcgDQogICAgDQogICAyIFMuIEJyYWRuZXIgIklFVEYgUmln aHRzIGluIENvbnRyaWJ1dGlvbnMiIFJGQyAzNjY3IEZlYnJ1YXJ5IDIwMDQgICANCiAgICANCiAg IDMgIElUVS1UIFJlY29tbWVuZGF0aW9uIEguMjYxICgxOTkzKSwgVmlkZW8gY29kZWMgZm9yIGF1 ZGlvdmlzdWFsIA0KICAgICAgc2VydmljZXMgYXQgcCAuIDY0IGtiaXQvcy4gDQogICAgIA0KICAg NCBJVFUtVCBSZWNvbW1lbmRhdGlvbiBILjI2MyAoMTk5OCksIFZpZGVvIGNvZGluZyBmb3IgbG93 IGJpdCByYXRlIA0KICAgICAgY29tbXVuaWNhdGlvbi4gDQogICAgDQogICA1IElTTy9JRUMgMTQ0 OTYtMjoyMDAxL0FtZC4xOjIwMDIsICJJbmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0gIA0KICAgICAg ICAgICBDb2Rpbmcgb2YgYXVkaW8tdmlzdWFsIG9iamVjdHMgLSBQYXJ0MjogVmlzdWFsIiwgMjAw MS4gDQogICAgICANCiAgIDYgSm9pbnQgVmlkZW8gVGVhbSBvZiBJVFUtVCBhbmQgSVNPL0lFQyBK VEMgMSwgRHJhZnQgSVRVLVQgDQogICAgICBSZWNvbW1lbmRhdGlvbiBhbmQgRmluYWwgRHJhZnQg SW50ZXJuYXRpb25hbCBTdGFuZGFyZCBvZiBKb2ludCANCiAgICAgIFZpZGVvIFNwZWNpZmljYXRp b24gKElUVS1UIFJlYy4gSC4yNjQgfCBJU08vSUVDIDE0NDk2LTEwIEFWQyksIA0KICAgICAgSm9p bnQgVmlkZW8gVGVhbSAoSlZUKSBvZiBJU08vSUVDIE1QRUcgYW5kIElUVS1UIFZDRUcsIEpWVC1H MDUwLCANCiAgICAgIE1hcmNoIDIwMDMuIA0KICAgIA0KICAgNyBKLiBPdHQgZXQgYWwuIEV4dGVu ZGVkIFJUUCBQcm9maWxlIGZvciBSVENQLWJhc2VkIEZlZWRiYWNrIA0KICAgICAgKFJUUC9BVlBG KSwgZHJhZnQtaWV0Zi1hdnQtcnRjcC1mZWVkYmFjay0wOS50eHQsIEF1Z3VzdCAyMDA0LCBJRVRG IA0KICAgICAgRHJhZnQuIFdvcmsgaW4gcHJvZ3Jlc3MuIA0KICAgICANCiAgIDggVC4gVHVybGV0 dGkgYW5kIEMuIEh1aXRlbWEsICJSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIEguMjYxIFZpZGVvIA0K ICAgICAgU3RyZWFtcywgUkZDIDIwMzIsIE9jdG9iZXIgMTk5Ni4gDQogICAgIA0KICAgOSBILiBT Y2h1bHpyaW5uZSwgUy4gQ2FzbmVyLCBSLiBGcmVkZXJpY2ssIGFuZCBWLiBKYWNvYnNvbiwgIlJU UDogQSANCiAgICAgIFRyYW5zcG9ydCBQcm90b2NvbCBmb3IgUmVhbC10aW1lIEFwcGxpY2F0aW9u cyIsIFJGQzM1NTAgU1REIDY0IA0KICAgICAgSnVseSAyMDAzLiANCiAgICANCiAgIDEwIElUVS1U IFJlY29tbWVuZGF0aW9uIEguMjQxICgwNy8yMDAzKSwgRXh0ZW5kZWQgdmlkZW8gcHJvY2VkdXJl cyANCiAgICAgIGFuZCBjb250cm9sIHNpZ25hbHMgZm9yIEguMzAwLXNlcmllcyB0ZXJtaW5hbHMu IA0KICAgIA0KICAgMTEgUy4gQnJhZG5lciAiSW50ZWxsZWN0dWFsIFByb3BlcnR5IHJpZ2h0cyBp biBJRVRGIFRlY2hub2xvZ3kiIA0KICAgICAgUkZDMzY2OCwgRmVicnVhcnkgMjAwNCANCiAgICAN CiAgICANCiAgIDEzLiAgSVBSIE5vdGljZXMgIA0KICAgICAgICANCiAgICAgIFRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55ICAN Cg0KIA0KIA0KQmFzc28gICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgIEFwcmlsIDIwMDUgICAg ICAgICAgICAgICAgW1BhZ2UgMTBdIA0KDCAgICAgICAgICAgICAgICAgQ29kZWMgQ29udHJvbCBS ZXF1aXJlbWVudHMgICAgT2N0b2JlciAyMDA0IA0KICAgIA0KICAgIA0KICAgICAgSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVk IA0KICAgICAgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0 ZWNobm9sb2d5IA0KICAgICAgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVu dCB0byB3aGljaCBhbnkgbGljZW5zZSANCiAgICAgIHVuZGVyIHN1Y2ggcmlnaHRzIG1pZ2h0IG9y IG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IA0KICAgICAgcmVwcmVzZW50IHRo YXQgaXQgaGFzIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgDQog ICAgICBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVz cGVjdCB0byByaWdodHMgDQogICAgICBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZSBmb3VuZCBpbiBC Q1AgNzggYW5kIEJDUCA3OS4gDQogICAgICAgDQogICAgICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1 cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueSANCiAgICAgIGFzc3VyYW5j ZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4g DQogICAgICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1p c3Npb24gZm9yIHRoZSB1c2UgDQogICAgICBvZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBp bXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcyANCiAgICAgIHNwZWNpZmljYXRpb24gY2FuIGJl IG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSANCiAgICAgIGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiAgICAgICAgICAgICAgICAgDQogICAgICAgDQogICAg ICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBh dHRlbnRpb24gDQogICAgICBhbnkgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGlj YXRpb25zLCBvciBvdGhlciANCiAgICAgIHByb3ByaWV0YXJ5IHJpZ2h0cyB0aGF0IG1heSBjb3Zl ciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIA0KICAgICAgdG8gaW1wbGVtZW50IHRo aXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIA0KICAg ICAgSUVURiBhdCBpZXRmLWlwckBpZXRmLm9yZy4gDQogICAgICAgDQogICAgICAgDQogICBBdXRo b3IncyBBZGRyZXNzZXMgDQogICAgICAgDQogICAgICBBbmRyZWEgQmFzc28gDQogICAgICBOTVMg Q29tbXVuaWNhdGlvbnMgDQogICAgICAyMDAgU2h1bHR6IERyaXZlIA0KICAgICAgUmVkIEJhbmss IE5KIDA3NzAxIFVTQSANCiAgICAgIFBob25lOiAoNzMyKSA5MzYtMjExOCANCiAgICAgIEVtYWls OiBhbmRyZWFfYmFzc29Abm1zcy5jb20gDQogICAgDQogICAgICBPcml0IExldmluIA0KICAgICAg TWljcm9zb2Z0IENvcnBvcmF0aW9uIA0KICAgICAgT25lIE1pY3Jvc29mdCBXYXkgDQogICAgICBS ZWRtb25kLCBXQSAgOTgwNTIgVVNBIA0KICAgICAgRU1haWw6IG9yaXRsQG1pY3Jvc29mdC5jb20g DQogICAgICAgDQogICAgICAgDQogICAgICBOZXJtZWVuIElzbWFpbCAgDQogICAgICBDaXNjbyBT eXN0ZW1zLCBJbmMuICANCiAgICAgIDE3MCBXZXN0IFRhc21hbiBEcml2ZSAgICAgICAgICAgICAN CiAgICAgIFNhbiBKb3NlLCBDQSA5NTEzNC0xNzA2LCBVU0EgICAgICANCiAgICAgIFBob25lOiAr MSA0MDggODUzIDg3MTQgDQogICAgICBFbWFpbDogbmlzbWFpbEBjaXNjby5jb20gICAgIA0KDQoN Cg0KDQoNCiAgICANCiAgICANCiAgIEJhc3NvICAgICAgICAgICAgICAgICAgICBFeHBpcmVzICBB cHJpbCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDExXSANCgw= --0__=0ABBE5ABDFB6EB3A8f9e8a93df938690918c0ABBE5ABDFB6EB3A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --0__=0ABBE5ABDFB6EB3A8f9e8a93df938690918c0ABBE5ABDFB6EB3A-- From avt-bounces@ietf.org Mon Oct 25 04:39:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01325 for ; Mon, 25 Oct 2004 04:39:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM0bj-0000cS-AK for avt-archive@ietf.org; Mon, 25 Oct 2004 04:53:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0MK-0003eg-OI; Mon, 25 Oct 2004 04:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0Hb-0003Tt-Pv for avt@megatron.ietf.org; Mon, 25 Oct 2004 04:32:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00820 for ; Mon, 25 Oct 2004 04:32:49 -0400 (EDT) Received: from mailrelay.pel.panasonic.de ([194.162.191.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM0V1-0000VF-8i for avt@ietf.org; Mon, 25 Oct 2004 04:46:43 -0400 Received: from localhost ([127.0.0.1]) by MailRelay.PEL.Panasonic.de; Mon, 25 Oct 2004 10:31:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2004 10:32:10 +0200 Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31330DD1@lan-ex-01.panasonic.de> Thread-Topic: Request for WG Last-Call for draft-ietf-avt-rtp-3gpp-timed-text-07.txt Thread-Index: AcStHH08EmuIB4ZAR1y0arLaWzNP1AAKk0QgA0gEpCA= From: "Rey Jose" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: "Magnus Westerlund \(KI/EAB\)" , Colin Perkins Subject: [AVT] Request for WG Last-Call for draft-ietf-avt-rtp-3gpp-timed-text-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Hi all, The last update of this draft was published by the ID manager on October = 8th: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-07= .txt Comments during and after the IETF have been incorporated into -06 (in = -07 only editorial nits were corrected using the webtool) and sent to = the list on September 10th. No comments have followed.=20 Additionally, the draft has already passed the 2-week review period by = IETF-types (sent to mailing list on September = 13th).=20 So I'd like to ask for WGLC. Thanks, Jos=E9 =20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Mon Oct 25 06:55:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12726 for ; Mon, 25 Oct 2004 06:55:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM2jK-0003Wl-AQ for avt-archive@ietf.org; Mon, 25 Oct 2004 07:09:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2Sh-0001GL-ST; Mon, 25 Oct 2004 06:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2RV-00019K-92 for avt@megatron.ietf.org; Mon, 25 Oct 2004 06:51:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12315 for ; Mon, 25 Oct 2004 06:51:10 -0400 (EDT) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM2em-0003Pt-4P for avt@ietf.org; Mon, 25 Oct 2004 07:05:06 -0400 Received: from [68.217.4.235] (port=1242 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CM2RH-00032k-Rr; Mon, 25 Oct 2004 06:50:59 -0400 From: "Alan Clark" To: "Fangweiwei" , "avt" Subject: RE: [AVT] questions about jitter Date: Mon, 25 Oct 2004 06:51:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <200410230119.VAA20236@ietf.org> Importance: Normal X-Spam-Score: 2.9 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA12315 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Hi It depends on the delay variation introduced by your model. In many case= s high levels of packet delay variation introduced on access links or low bandwidth LANs tend to be non-Gaussian in nature .. using a smoothed PPDV model may not be representative. The VoIP Troubleshooter site discusses this in some detail and also has a downloadable IP network simulator that uses a time series model to generate delay traces. Regards Alan Clark Telchemy PS: In your equation - presumably d is an absolute value. -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of Fangweiwei Sent: Friday, October 22, 2004 9:19 PM To: avt Subject: [AVT] questions about jitter avt=A3=AChi=A3=A1 As I know, Jitter is standard deviation of inter-packet time ,but As in the RFC3350: fJitter +=3D (1.0/16.0) * ((double)d - fJitter); I don't know why RFC 3550 computes it as that. Now I do some work as Network Emulation. And when I changed the virtu= al network, from good to bad (eg.packet loss), I calculate the packet jitter using standard deviation fomula.and It reflects that the network quality.= If packet loss too much, the packet jitter will become big... but unfortunately, I find the fJitter changes slightly,and it's value has little relation with network quality.I don't know why? Thank you very much for all your answer! Yours Sincerely =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Fangweiwei =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1fangweiwei@tom.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-10-23 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Weiwei Fang Network Emulation Group Lab for Computer Architecture and Network Technology Bei Hang University P.B.: 37 Xueyuan Road Beijing 100083 P.R.China =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 26 05:03:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13868 for ; Tue, 26 Oct 2004 05:03:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNSD-0006Ve-Hd for avt-archive@ietf.org; Tue, 26 Oct 2004 05:17:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNCk-0000kc-JK; Tue, 26 Oct 2004 05:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMN9B-00085I-W1 for avt@megatron.ietf.org; Tue, 26 Oct 2004 04:57:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13405 for ; Tue, 26 Oct 2004 04:57:38 -0400 (EDT) Received: from radmail1.rad.co.il ([62.0.23.193] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNMl-0006NS-SR for avt@ietf.org; Tue, 26 Oct 2004 05:11:46 -0400 Received: from antivir1.rad.co.il ([127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id i9Q8uYS8004029 for ; Tue, 26 Oct 2004 10:56:34 +0200 (IST) Received: from mailframer.rad.co.il (mailframer.rad.co.il [192.114.24.181]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id i9Q8uY5J004026 for ; Tue, 26 Oct 2004 10:56:34 +0200 (IST) Received: (from root@localhost) by mailframer.rad.co.il (8.12.11/8.12.9/Submit) id i9Q8xukD021807 for avt@ietf.org; Tue, 26 Oct 2004 10:59:56 +0200 Received: from exrad2.ad.rad.co.il ([192.114.24.112]) by mailframer.rad.co.il (8.12.11/8.12.9) with ESMTP id i9Q8xuwv021802; Tue, 26 Oct 2004 10:59:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AVT] questions about jitter Date: Tue, 26 Oct 2004 10:55:34 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5203353C0F@exrad2.ad.rad.co.il> Thread-Topic: [AVT] questions about jitter Thread-Index: AcS6gQMEQHevKjtWSdyV2AKOB9vwWAAtprKw From: "Yaakov Stein" To: "avt" X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Fangweiwei X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0599978935==" Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This is a multi-part message in MIME format. --===============0599978935== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB39.8E7DD07D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BB39.8E7DD07D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 3550 states that the jitter SHOULD be calculated continuously as each data packet i is received. The standard deviation is basically a block calculation, although it can be computed recursively using buffers. The method proposed in the RFC is a simple 1-lag IIR smoothing filter with an empirically set decay time. Although I personally wouldn't have used the wording "optimal first-order estimator", it certainly is the most straightforward way to compute a time-averaged jitter value. In any case, why do you want to compute PDV if your problem is packet loss rate ? The jitter is an additional characteristic, and shouldn't directly effect "network quality" (e.g. perceived audio quality) unless there are large PDV swings, causing jitter buffer over- or under-flow and hence "internal" packet loss. Y(J)S ------_=_NextPart_001_01C4BB39.8E7DD07D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC 3550 states that the jitter = SHOULD be=20 calculated continuously as each
data packet i is received. The = standard=20 deviation is basically a block calculation,
although it can be = computed=20 recursively using buffers.

The method proposed in the = RFC is a=20 simple 1-lag IIR smoothing filter
with an empirically set decay time. = Although I personally
wouldn't have used the wording "optimal = first-order=20 estimator",
it certainly is the most straightforward way to compute a = time-averaged jitter=20 value.

In any case, why do you want to compute PDV if = your
problem is=20 packet loss rate ?  The jitter is an additional = characteristic,
and=20 shouldn't directly effect "network quality" (e.g. perceived audio=20 quality)
unless there are large PDV swings, causing jitter buffer = over- or=20 under-flow
and hence "internal" packet=20 loss.

Y(J)S


------_=_NextPart_001_01C4BB39.8E7DD07D-- --===============0599978935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0599978935==-- From avt-bounces@ietf.org Tue Oct 26 09:43:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05508 for ; Tue, 26 Oct 2004 09:43:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMRpF-0003OE-PB for avt-archive@ietf.org; Tue, 26 Oct 2004 09:57:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMRa3-0007jr-S2; Tue, 26 Oct 2004 09:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMRYn-0007SY-9D for avt@megatron.ietf.org; Tue, 26 Oct 2004 09:40:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05404 for ; Tue, 26 Oct 2004 09:40:23 -0400 (EDT) Received: from web8407.mail.in.yahoo.com ([202.43.219.155]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMRmQ-0003LT-NV for avt@ietf.org; Tue, 26 Oct 2004 09:54:32 -0400 Message-ID: <20041026131532.74755.qmail@web8407.mail.in.yahoo.com> Received: from [203.129.220.115] by web8407.mail.in.yahoo.com via HTTP; Tue, 26 Oct 2004 14:15:32 BST Date: Tue, 26 Oct 2004 14:15:32 +0100 (BST) From: rahul agrawal To: mankin@psg.com, avt@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.3 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [AVT] query X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0814748430==" Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 --===============0814748430== Content-Type: multipart/alternative; boundary="0-166083665-1098796532=:70244" --0-166083665-1098796532=:70244 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit sir/mam, i read the iLBC codec but its not clearly understood, so sir please tell me what should i do. i am working to improve the sound quality which gets degraded in the channel. so please help me. --------------------------------- Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. --0-166083665-1098796532=:70244 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
sir/mam,
             i read the iLBC codec but its not clearly understood, so sir please tell me what should i do. i am working to improve the sound quality which gets  degraded in the channel.
 
so please help me.

Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish. --0-166083665-1098796532=:70244-- --===============0814748430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0814748430==-- From avt-bounces@ietf.org Tue Oct 26 12:12:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19132 for ; Tue, 26 Oct 2004 12:12:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMU9g-0006aQ-MS for avt-archive@ietf.org; Tue, 26 Oct 2004 12:26:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTtA-0002Pj-Mt; Tue, 26 Oct 2004 12:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTmq-00018o-Nr for avt@megatron.ietf.org; Tue, 26 Oct 2004 12:03:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18460 for ; Tue, 26 Oct 2004 12:03:02 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMU0X-0006Og-1Z for avt@ietf.org; Tue, 26 Oct 2004 12:17:13 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9QG32R2014414 for ; Tue, 26 Oct 2004 18:03:02 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 18:03:03 +0200 Received: from [147.214.34.66] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.66]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJQ1WW05; Tue, 26 Oct 2004 18:03:02 +0200 Message-ID: <417E7536.3010500@ericsson.com> Date: Tue, 26 Oct 2004 18:03:02 +0200 X-Sybari-Trust: 81628721 ad48f3dd 35d21225 00000179 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Rey Jose References: <9D277E44D6EF0942B928C6F0DE99BB31330DD1@lan-ex-01.panasonic.de> In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31330DD1@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2004 16:03:03.0075 (UTC) FILETIME=[45DAC730:01C4BB75] X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: [AVT] Re: Request for WG Last-Call for draft-ietf-avt-rtp-3gpp-timed-text-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 7bit Hi Jose, I have reviewed the draft, and found some things that needs to be correct. However I think it is getting close. 1. Section 2.3.4: bullet 3: " 3. for PAYLOAD 3: ts(#6)= ts(#7)= rtpsts2= rtpts3 In this case rtpts3 must be equal to rtpts2 in order to be able to assign this fragment to the correct sample (TS4). Additionally, note that units 6 and 7 have the same timestamp since they belong to the same text sample (also TS4)." I think this paragraph is hard to understand, and maybe even misleading. ts(#6) is equal to ts(#7) due to the rule that if type 2 and 3 are present in the same payload they must all have the same timestamp. The current second sentence gives the impression that due to that the TS are the same, they belong to the same sample, while the reason is the rule. I also think one should clarify that the values of SDUR are ignored in this case. I would recommend that the comment is totally rewritten. 2. Section 3: " Note that TYPE 5 units do not make use of the timestamp and therefore the above does not apply for this particular case." I have two comments around this. First, there should be a clarification on how to set the RTP timestamp if one makes packets with only Type 5 packets. I would recommend to set it according to the current TS value. Secondly, I think some clarification on when Type 5 packets shall be assumed to become active. From the point they are received, when they are unpacked, i.e. order in the RTP packet may have some meaning, or when other packets type the type 5 was attached to is utilized. I think this has some impact, although the guard band for dynamic types normally would prevent it. 3. Section 3.1.1: Bullet about LEN: o Finally, the LEN (16 bits) "Length Field": indicates the size (in bytes) of this header field and all the fields following, i.e. the LEN field followed by the unit payload (text strings and modifiers, if any). It might be beneficial to be clear to add a comment, that the only thing excluded from the LEN field is the U|R|Type byte first in the payload header. 4. Section 3.1.6: " The SIDX value is in the (inclusive) interval [0,127], as this unit contains a dynamic sample description." It is not written explicitly that the SIDX value in a TYPE 5 payload is the SIDX value for that content. I would propose something like this: "The SIDX value that is assigned to the sample description carried as sample content of this unit. As any sample description carried is a dynamic one, the possible SIDX values are in the (inclusive) interval[0,127]." 5. Section 12.1, I think should be moved into 3.1.6 as it contains normative language about the handling of dynamic sample descriptions. 6. Section 6.1, last paragraph: I think the SHALL is very unnecessary, I think a informative sentence is sufficient. What interoperability effect would occur, and what does help with the definition that appropriate values needs to be used. 7. Section 7.1: I think that a number of parameters are misclassified. Any parameter that do not need to be included in all messages belongs under Optional parameters. I think that include: max-w, max-h, width, and height. This also has effect in 8.1. 8. Section 7.1: I think there should be an appropriate reference to figure 5.1 in [1] for how the tx, ty, width, height parameters work. 9. Section 7.1: Author/Change controller section in the template. As the mime type belongs to IETF, the following split between author and change controller is appropriate: " Author: Jose Rey Yoshinori Matsui Change Controller: IETF Audio/Video Transport working group delegated from the IESG. " The Change controller section is provided by Allison and originates from one of the APPS ADs. 10. Section 8.2, third paragraph: "As stated in the O/A model, some "fmtp" (payload-format-specific) parameters have a clear meaning and shall be included in the answer as present in the offer. Other parameters may need to be set among parties, because it is not clear that offerer and answerer shall use the same values. A third type of parameters may take different values for offerers and answerers." This paragraph has several sentences of unclear wording: First sentence, was is meant with "clear meaning". I think we usually call them symmetric, and that is due to that both end-point needs to use the same value for some reason. Second sentence, what is meant with "set among parties"? It doesn't seem to be declarative (which is the third alternative), so what is special with these and what is the difference in relation to symmetric and declarative parameters? 11. Section 8.2.1, bullet 1, a, i: Should it also be added, that unless special preference exist the offered value should be used? 12. Section 8.2.1, bullet 2: "2. Parameters describing the display capabilities, ..." Which parameters are included in this category? Please be explicit about this. 13. Section 8.2.1, bullet 3, b: Please clarify that the tx3g applies in the offerers or answerers transmission direction. 14. Section 8.2.2: Last bullet: The usage of "sver" in multicast? Is it really possible to offer more than one version that all uses? Especially if the version result in that different parsing of the samples must be used, then one can really only offer one. Otherwise one needs to agree on the version used. 15. Section 8.3: "In this case the answerer's "max-h" and "max-w" are compatible with the offerer's "height" and "width". Otherwise, the answerer would have to remove this stream and the answerer issue a new offer taking the answerer's capabilities into account." I would like to make you aware that the offerer will not receive a payload type at all if the answerer has to refuse the stream due to that height and width are larger then the supported max-w and max-h. The only way to ensure that this would happened would be do define multiple payload types, with at least one that is guaranteed to be acceptable, thus allowing the answerer to give his max-w and max-h parameters. Then the offerer can re-issue the offerer with the knowledge about the answerers capability. 16. Section 8.4, second paragraph: "In this case, the receiver of a session description MUST support the parameters and given values for the streams or else it MUST reject the session." I think one can without changing the sentence meaning replace the first MUST with "requires to" 17. Another "sver" related question, which i thought of in relation to the example of a Sendonly offer: What happens if the sample description format is version dependent? In that case you can't include the tx3g parameter until you have agreed on the version you are going to use. The resolution would to offer different versions using different payload types. 18. Section 12.1: The algorithm description. I have some problem with the current description. Bullet 3, has an IF without an clear argument. Also I think it fails to properly describe if the new X must be the next value or values above the current active set. Or if one is allowed to send an X=127 in a session that had the inactive set to be [64..127]? Thus resulting in that the currently active set is completely inactivated. 19. Section 12.3: o the Decoding Time to Sample Box (stts): the 24 least significant bits of the "sample_delta" are mapped to the field SDUR (Text Sample Duration), I think this is incorrectly stated, I think one should use as many bits as existing in the mapping to the SDUR value. Please consider that if one strictly takes the lower 24, values one can't scale in the mapping, or do ceiling value with the bits one have. Lets assume that one can only represent number with 3 digits, and SDUR would be 1023, then one could send this sample as one with SDUR=999 and another with TS=TS_org+999 and SDUR=24. Editorial comments E1. Where has all the page break markers gone? E2. Section 2.3.4, Bullet 1, the note: "Note that no sdur value is assigned to TYPE 5 units, and they are taken into account in the timestamp calculation." Is there a missing "not" ".. and they are taken into .."? E3. Section 6.1, second paragraph: "O/A" do not abbreviate here. E4. Section 7.1, tx3g: Please include a reference after the first reference to BASE64 encoding. E5. Section 7.1, Additional information: The first sentence has lower case "the" in the first sentence. E6. Section 8.2, third paragraph: " may take the values sendrecv, sendonly andrecvonly." missing space between "and" and "recvonly". E7. Section 8.2.1, bullet 1, second sentence: Unclear what "they" refer to, please write out "The offerer or answerer". E8. Section 8.3: "Note also that the answerer's text box dimensions fit .." Shouldn't text box be text track in this sentence? E9. Section 11: Ref [1] exist in 6.0.0 version. Also [16] is available in rel 6 if that is desired to be used as ref instead of the REL5 version. If there is any unclarities about my comments, simply ask about it. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Tue Oct 26 16:06:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10023 for ; Tue, 26 Oct 2004 16:06:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMXoP-000405-KY for avt-archive@ietf.org; Tue, 26 Oct 2004 16:20:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXZB-0000S2-HD; Tue, 26 Oct 2004 16:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXNq-0003Ef-2I; Tue, 26 Oct 2004 15:53:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08495; Tue, 26 Oct 2004 15:53:27 -0400 (EDT) Message-Id: <200410261953.PAA08495@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 15:53:27 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-uxp-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams Author(s) : G. Liebl, et al. Filename : draft-ietf-avt-uxp-07.txt Pages : 29 Date : 2004-10-26 This document specifies an efficient way to ensure erasure- resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon (RS) codes together with interleaving. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Furthermore, protection of non-progressive multimedia streams is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By applying interleaving and RS codes a payload format is defined, which can be easily integrated into the existing framework for RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-uxp-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-uxp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-uxp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26160414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-uxp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-uxp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160414.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Tue Oct 26 16:15:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11230 for ; Tue, 26 Oct 2004 16:15:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMXxA-0004LG-Kx for avt-archive@ietf.org; Tue, 26 Oct 2004 16:30:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXZF-0000VH-Sp; Tue, 26 Oct 2004 16:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXOH-0003V0-St; Tue, 26 Oct 2004 15:53:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08551; Tue, 26 Oct 2004 15:53:55 -0400 (EDT) Message-Id: <200410261953.PAA08551@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 15:53:55 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Profile for TCP Friendly Rate Control Author(s) : L. Gharai Filename : draft-ietf-avt-tfrc-profile-03.txt Pages : 13 Date : 2004-10-26 This memo specifies a profile called "RTP/AVPCC" for the use of the real-time transport protocol (RTP) and its associated control protocol, RTCP, with the TCP Friendly Rate Control (TFRC). TFRC is an equation based congestion control scheme for unicast flows operating in a best effort Internet environment. This profile provides RTP flows with the mechanism to use congestion control in best effort IP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-tfrc-profile-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-tfrc-profile-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26160429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tfrc-profile-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tfrc-profile-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160429.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Wed Oct 27 08:36:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29889 for ; Wed, 27 Oct 2004 08:36:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnGF-0004J7-Of for avt-archive@ietf.org; Wed, 27 Oct 2004 08:50:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMn0r-0007Cw-BF; Wed, 27 Oct 2004 08:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMmzZ-0006pO-7d for avt@megatron.ietf.org; Wed, 27 Oct 2004 08:33:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29755 for ; Wed, 27 Oct 2004 08:33:27 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnDQ-0004FD-Kv for avt@ietf.org; Wed, 27 Oct 2004 08:47:49 -0400 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:59397) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CMmz2-0003Mw-QY; Wed, 27 Oct 2004 13:32:56 +0100 In-Reply-To: <000001c4b877$19eedcc0$5401a8c0@hobel> References: <000001c4b877$19eedcc0$5401a8c0@hobel> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <516D42D0-2814-11D9-AFD3-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] bandwidth feedback in draft-ietf-avt-rtcp-feedback-11.txt Date: Wed, 27 Oct 2004 13:32:51 +0100 To: "'Jim Kleck'" X-Mailer: Apple Mail (2.619) X-Spam-Score: 1.1 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: "" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit The RTP profile for TFRC and the work of the DCCP working group might also be of interest. Colin On 22 Oct 2004, at 21:38, Stephan Wenger wrote: > Dear Jim, > > RTP is considered an application layer protocol, not a transport layer > protocol. RTCP feedback message are application layer feedback. > > Schemes like yours have been proposed before. Their problem is that > they do > not work. > > The standard solution for your problem (without additional signaling > support) would be to mimic TCP congestion control mechanisms. Google > for > "TCP Westwood", and you will find a dozen papers or so. Standard RCTP > receiver reports are perfectly fine for this purpose. However, even > if you > were using a high enough report frequency, you could not avoid losses, > because only the losses would tell you to reduce your bandwidth. TCP > will > always claim as much bandwidth as it can get, and only stop asking for > it > when it senses excessive losses. > > In the 3GPP environment, the AVP (and AVPF) can be augmented with a > "jitter > buffer fullness" indication, which reports the status of the receiver > (jitter) buffer -- which, in turn, could be used to calculate your > target > bandwidth, doing a bit of straightforward math. This may work over the > point-to-point wireless link to the mobile terminal, assuming an > overprovisioned core network. It will not work on a LAN, or a > best-effort > WAN. > > With respect to your proposal: As long as your LAN has (statistically) > a > lower bandwidth then the typical TCP sender's sending capability, your > media > transport will be messed up from time to time, no matter what. Unless > you > use exotic stuff such as negotiated quality (Intserv, Diffserv) or > DCCP. > > Writing this after 22 hours of no-sleep, > Stephan > > > -----Original Message----- > From: Jim Kleck [mailto:jimk@8x8.com] > Sent: Thursday, October 21, 2004 7:28 PM > To: avt@ietf.org > Cc: jo@tzi.org; stewe@stewe.org; sato652@oki.com; > burmeister@panasonic.de; > rey@panasonic.de > Subject: [AVT] bandwidth feedback in > draft-ietf-avt-rtcp-feedback-11.txt > > (resent to CC the draft authoers) > > Hi all, > > > We have a SIP video conferencing application which operates over > broadband. Typically our videophone is on a local network behind a > router connected to a DSL or cable modem. > > When another device on the local network asynchronously starts using > bandwidth, e.g. by doing an FTP, we experience either increasing > latency > as transmitted packets are buffered along the path and/or we experience > dropped packets. > > Both of these conditions are detectable by using RTCP Sender Reports > and Receiver Reports, but the question is: how far should our > application reduce its transmit bandwidth? RTCP reports indicate > number of lost packets or increasing latency, but due to the varying > transmit bandwidth of the video (i.e. small bandwidth during periods > of little motion, larger bandwidth during periods of large motion), > this does not easily translate into how far to reduce the transmit > bandwidth. > > The far end's receiver does, however, have the means to easily > calculate both the sender's transmit bandwidth for a particular period > (by comparing the two most recently received RTCP Sender Reports) and > the actual received bandwidth for that comparable period (by comparing > the time and the received byte count at the reception of those two > RTCP Sender Reports). Note that the receive bandwidth alone is not > sufficient because of the varying video bandwidth. > > So given these transmit and receive bandwidths, the difference is the > amount by which the sender has overfilled the pipe. This difference is > not exact because RTP/RTCP packets can get out of sequence, so the > difference is only meaningful if it exceeds some threshold. > > Now all that is needed is a way for the receiver to communicate this > difference back to the sender. This could certainly be done using an > Application Layer Feedback Message but it is the receiver's RTP layer > which processes the RTCP Sender Reports and Receiver Reports and which > can calculate the bandwidth difference. This puts the feedback more > in the Transport Layer area. However, the sender (i.e. the endpoint > that receives the feedback) must pass the information up to the > application, so maybe it belongs in the Application Layer area after > all. But this kind of feedback seems of general use to me, possibly > useful for many types of payload. It should thus be standardized and > not left up the the applications nor put into the Payload Specific > area. > > So, I propose a new transport layer feedback message with a single FCI > field containing an unsigned 32 bit value. This FCI field would contain > the bandwidth difference detected by the receiver. Upon receiving this > feedback, the sender can then reduce its maximum transmit bandwidth by > the difference. > > > > > > Thank you for your time, > > Jim Kleck > 8x8, Inc _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 08:56:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01213 for ; Wed, 27 Oct 2004 08:56:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnZR-0004hP-Cg for avt-archive@ietf.org; Wed, 27 Oct 2004 09:10:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnKC-0002Gv-VR; Wed, 27 Oct 2004 08:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnIz-0001rD-UI for avt@megatron.ietf.org; Wed, 27 Oct 2004 08:53:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00946 for ; Wed, 27 Oct 2004 08:53:31 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnWr-0004bM-K8 for avt@ietf.org; Wed, 27 Oct 2004 09:07:53 -0400 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:59440) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CMnIT-0004lO-I2; Wed, 27 Oct 2004 13:53:01 +0100 In-Reply-To: <4164A7D3.1030707@motorola.com> References: <4164A7D3.1030707@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20D66020-2817-11D9-AFD3-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] Re: VMR-WB RTP Payload and Storage Formats Date: Wed, 27 Oct 2004 13:52:58 +0100 To: Qiaobing Xie X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: magnus.westerlund@ericsson.com, avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit On 7 Oct 2004, at 03:20, Qiaobing Xie wrote: > Colin Perkins wrote: >> I would have thought the conference bridge could act as an RTP >> translator, and resample as appropriate for some participants? > > Use this as an example - here we have the advanced codec vmr-wb saying > "you no longer need to worry about resampling at the bridge. Just send > me the frames and I can handle them at either rates (8k or 16k)." But > RTP payload says: "No, you cann't do that, even I know you are capable > of it. You still have to stick with the tradition and pay the cost of > signaling the rate change and building the resampling function into > the bridge." I think this as a failure of taking full advantage of the > codec capability. I don't disagree. However, we need to develop a solution that retains the utility and extensibility of RTP and RTP implementations. My concern with a fixed 16 kHz rate for VMR-WB is that it doesn't allow payload format independent implementations, since it offers a differing interpretation of the RTP timestamp than do other audio payload formats. To some extent that's unavoidable when we move to variable rate codecs, but it would greatly benefit implementers if we could develop a single approach to supporting variable rate codecs. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 09:56:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04494 for ; Wed, 27 Oct 2004 09:56:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoVU-0005fs-Uh for avt-archive@ietf.org; Wed, 27 Oct 2004 10:10:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMoGM-0001Qh-T0; Wed, 27 Oct 2004 09:54:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMoEi-00012M-FT for avt@megatron.ietf.org; Wed, 27 Oct 2004 09:53:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04372 for ; Wed, 27 Oct 2004 09:53:10 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoSa-0005d4-Dj for avt@ietf.org; Wed, 27 Oct 2004 10:07:33 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9RDrAfM027492 for ; Wed, 27 Oct 2004 15:53:10 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Oct 2004 15:53:09 +0200 Received: from [147.214.34.66] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.66]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJRTCAYF; Wed, 27 Oct 2004 15:53:09 +0200 Message-ID: <417FA845.50201@ericsson.com> Date: Wed, 27 Oct 2004 15:53:09 +0200 X-Sybari-Trust: b68da296 8cefd49f fd62097d 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2004 13:53:09.0888 (UTC) FILETIME=[4B2A9000:01C4BC2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Subject: [AVT] Preliminary Agenda for IETF 61 in Washington X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Hi AVTers This is the preliminary agenda for AVT. If you spot any errors or are missing from the agenda and have some issues to discuss, please contact the chairs ASAP. Please use the below template when submitting requests: A. Presentation Title: B. Name of presenter: C. Draft Reference(s): D. Requested amount of time in minutes: Please note that the session schedule is not yet fixed, thus the date and times for the AVT sessions may move. Cheers Magnus ---- Start of Agenda ----- Audio/Video Transport Working Group CHAIRS: Colin Perkins Magnus Westerlund WEDNESDAY, November 10, 2004 09:00-11:30 ======================================== Introduction and Status Update (Chairs) 20 min MIDI RFC 2032 bis RFC 2429 bis draft-basso-avt-videoconreq-02.txt RTP Timestamp usage for variable sample rate audio codecs (Wenger) draft-ietf-avt-variable-rate-audio-00.txt (Chairs) Mail Discussion 30 min Open issues in RFC 2833bis (Taylor) draft-ietf-avt-rfc2833bis-05.txt 15 min VMR-WB RTP Payload and File Format Internet Drafts (Ahmadi) draft-ietf-avt-vmr-wb-file-format-00.txt 15 min draft-ietf-avt-rtp-vmr-wb-05.txt Update of RTP payload format for AMR and AMR-WB (Westerlund) draft-ietf-avt-rtp-amr-bis-00.txt 15 min Changes in JPEG 2000 Video RTP Payload Format (Leung) draft-ietf-avt-jpeg2000-06.txt 15 min RTCP XR MIB (Clark & Pendleton) draft-ietf-avt-rtcp-xr-mib-00.txt 15 min Far End Camera Control protocol (Even) draft-even-avt-h224-00.txt 15 min THURSDAY, November 11, 2004 1300-1500 [Nothing] ---- End of Agenda ---- -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 15:21:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04735 for ; Wed, 27 Oct 2004 15:21:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMtaJ-00051f-6A for avt-archive@ietf.org; Wed, 27 Oct 2004 15:35:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtJn-0005eW-5m; Wed, 27 Oct 2004 15:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtJH-0005Ou-50 for avt@megatron.ietf.org; Wed, 27 Oct 2004 15:18:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04334 for ; Wed, 27 Oct 2004 15:18:12 -0400 (EDT) Received: from mail.8x8.com ([192.84.19.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMtXB-0004w3-9q for avt@ietf.org; Wed, 27 Oct 2004 15:32:38 -0400 Received: from [192.168.85.113] (unknown [192.168.85.113]) by mail.8x8.com (Postfix) with ESMTP id 900041E1A3; Wed, 27 Oct 2004 12:17:27 -0700 (PDT) Message-ID: <417FF447.90606@8x8.com> Date: Wed, 27 Oct 2004 12:17:27 -0700 From: Jim Kleck User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ladan@isi.edu Subject: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback in RTP? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit The draft-ietf-avt-tfrc-profile-03.txt is specifically restricted to unicast, and specifies feedback possibly once per data packet. This can generate too much feedback traffic in the case of one-to-one video conferencing (which typically operates at 64K - 512K bps). However, this case offers a ready feedback path with much less overhead: the data pkts coming from the far end. An additional extension to the RTP hdr could possibly add the feedback at a small cost. The challenges with this scheme are: - there is an implicit tie between the Tx and Rx RTP sessions, but in a one-to-one video conference that should not be too hard to formalize - if the app does not recv any data pkts from the farend for a while then there will be no feedback, that could mean the far end has nothing to send (in which case a noop RTP pkt with the feedback could be specified, see draft-wing-avt-rtp-noop-01.txt, with no worries about using extra bandwidth because the lack of data makes that bandwidth available... or use the suggested Receiver Report extensions), or it could mean that there is some network problem Does this seem worth further investigation? Jim Kleck 8x8, Inc _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 16:05:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08561 for ; Wed, 27 Oct 2004 16:05:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMuGs-0005y0-5G for avt-archive@ietf.org; Wed, 27 Oct 2004 16:19:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMu0j-0002XP-Gf; Wed, 27 Oct 2004 16:03:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtwK-0000yU-Jj for avt@megatron.ietf.org; Wed, 27 Oct 2004 15:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07929 for ; Wed, 27 Oct 2004 15:58:34 -0400 (EDT) Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=mail.tvol.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMuAE-0005pz-T9 for avt@ietf.org; Wed, 27 Oct 2004 16:13:00 -0400 Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NPY8BGNR; Wed, 27 Oct 2004 15:57:26 -0400 To: "Yaakov Stein" Subject: Re: [AVT] questions about jitter References: <27A0F290348F8E45AEF79889DDE65A5203353C0F@exrad2.ad.rad.co.il> From: Randell Jesup Date: 27 Oct 2004 16:01:55 -0400 In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5203353C0F@exrad2.ad.rad.co.il> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Fangweiwei , avt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 "Yaakov Stein" writes: >RFC 3550 states that the jitter SHOULD be calculated continuously as each >data packet i is received. The standard deviation is basically a block >calculation, although it can be computed recursively using buffers. > >The method proposed in the RFC is a simple 1-lag IIR smoothing filter >with an empirically set decay time. Although I personally >wouldn't have used the wording "optimal first-order estimator", >it certainly is the most straightforward way to compute a time-averaged >jitter value. > >In any case, why do you want to compute PDV if your problem is packet loss >rate ? The jitter is an additional characteristic, and shouldn't directly >effect "network quality" (e.g. perceived audio quality) unless there are >large PDV swings, causing jitter buffer over- or under-flow and hence >"internal" packet loss. Jitter is relevant to audio quality on it's own, separately from packet loss - it affects (strongly) the minimum amount of jitter buffer required to avoid underflow losses, and that delay affects call quality in an interactive stream. "Packet loss" in RTCP _should_ be "packets lost or arriving out-of-order too late to be played" which is essentially the post-jitter-buffer loss rate. So a post-jitter loss rate of 0% may still have horrid quality if the jitter buffer average depth has to be 500ms to achieve that loss rate (note: the jitter value in reported RTCP wouldn't be 500ms in this case). Note that RFC 3550 RTCP defines "loss" in a very weird way; it allows very late packets to not be considered "lost", and it counts duplicates as multiple separate packets (so if you lose packet N, and get two of packet N+1, that's considered 0 loss!!!) Also, since loss is based on the last packet received (packet N), if the previous packet (N-1) arrives out-of-order (but in time to be played) after the RTCP is sent, the RTCP will show that as a loss, and in the next RTCP an extra packet will be counted (and yes, this can lead to negative loss rates). So for many uses, while amusing, the RTCP data on loss (and probably jitter) is close to worthless, and certainly has to be taken as at best fuzzy data. Post-jitter data (handling late packets, duplicates, etc) is more useful in most cases. I'm sure part of the reason it's defined this way is so an RTP stack can calculate the loss & jitter simply without having to communicate in any way with the jitter buffer. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team rjesup@wgate.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 17:07:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15149 for ; Wed, 27 Oct 2004 17:07:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvEr-0007nw-VB for avt-archive@ietf.org; Wed, 27 Oct 2004 17:21:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuo8-0004Ng-Gp; Wed, 27 Oct 2004 16:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMudU-0007kp-F4 for avt@megatron.ietf.org; Wed, 27 Oct 2004 16:43:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12049 for ; Wed, 27 Oct 2004 16:43:10 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMurP-0006ru-JU for avt@ietf.org; Wed, 27 Oct 2004 16:57:37 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61146 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CMucu-0004r4-EO; Wed, 27 Oct 2004 21:42:36 +0100 In-Reply-To: References: <27A0F290348F8E45AEF79889DDE65A5203353C0F@exrad2.ad.rad.co.il> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] questions about jitter Date: Wed, 27 Oct 2004 21:42:31 +0100 To: Randell Jesup X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: Fangweiwei , Yaakov Stein , avt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit On 27 Oct 2004, at 21:01, Randell Jesup wrote: > "Yaakov Stein" writes: >> RFC 3550 states that the jitter SHOULD be calculated continuously as >> each >> data packet i is received. The standard deviation is basically a block >> calculation, although it can be computed recursively using buffers. >> >> The method proposed in the RFC is a simple 1-lag IIR smoothing filter >> with an empirically set decay time. Although I personally >> wouldn't have used the wording "optimal first-order estimator", >> it certainly is the most straightforward way to compute a >> time-averaged >> jitter value. >> >> In any case, why do you want to compute PDV if your problem is packet >> loss >> rate ? The jitter is an additional characteristic, and shouldn't >> directly >> effect "network quality" (e.g. perceived audio quality) unless there >> are >> large PDV swings, causing jitter buffer over- or under-flow and hence >> "internal" packet loss. > > Jitter is relevant to audio quality on it's own, separately > from > packet loss - it affects (strongly) the minimum amount of jitter buffer > required to avoid underflow losses, and that delay affects call > quality in > an interactive stream. > > "Packet loss" in RTCP _should_ be "packets lost or arriving > out-of-order > too late to be played" which is essentially the post-jitter-buffer loss > rate. So a post-jitter loss rate of 0% may still have horrid quality > if > the jitter buffer average depth has to be 500ms to achieve that loss > rate > (note: the jitter value in reported RTCP wouldn't be 500ms in this > case). > > Note that RFC 3550 RTCP defines "loss" in a very weird way; it allows > very > late packets to not be considered "lost", and it counts duplicates as > multiple separate packets (so if you lose packet N, and get two of > packet > N+1, that's considered 0 loss!!!) Also, since loss is based on the > last > packet received (packet N), if the previous packet (N-1) arrives > out-of-order (but in time to be played) after the RTCP is sent, the > RTCP > will show that as a loss, and in the next RTCP an extra packet will > be counted (and yes, this can lead to negative loss rates). > > So for many uses, while amusing, the RTCP data on loss (and probably > jitter) is close to worthless, and certainly has to be taken as at best > fuzzy data. Post-jitter data (handling late packets, duplicates, etc) > is > more useful in most cases. I'm sure part of the reason it's defined > this > way is so an RTP stack can calculate the loss & jitter simply without > having to communicate in any way with the jitter buffer. And there's RFC 3611 if you need more detailed statistics. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 17:15:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16276 for ; Wed, 27 Oct 2004 17:15:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvMj-0007zd-T7 for avt-archive@ietf.org; Wed, 27 Oct 2004 17:29:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuob-0004W2-29; Wed, 27 Oct 2004 16:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuf5-0008LV-16 for avt@megatron.ietf.org; Wed, 27 Oct 2004 16:44:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12211 for ; Wed, 27 Oct 2004 16:44:48 -0400 (EDT) Received: from mail.8x8.com ([192.84.19.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMut0-0006v8-Bz for avt@ietf.org; Wed, 27 Oct 2004 16:59:15 -0400 Received: from [192.168.85.113] (unknown [192.168.85.113]) by mail.8x8.com (Postfix) with ESMTP id 4450C1E1B8; Wed, 27 Oct 2004 13:44:13 -0700 (PDT) Message-ID: <4180089D.6040809@8x8.com> Date: Wed, 27 Oct 2004 13:44:13 -0700 From: Jim Kleck User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: fandreas@cisco.com, oran@cisco.com, dwing@cisco.com Subject: [AVT] draft-wing-avt-rtp-noop-01.txt - another use Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Another use for these RTP no-ops is to probe to see if enough tx bandwidth is available to send good video at the beginning of a video call.... or is this a no-no since one would be using a lot of bandwidth (say up to 512K, although only for a short time) and if everyone did it there would be no bandwidth left for real data? Jim Kleck 8x8, Inc _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 17:16:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16391 for ; Wed, 27 Oct 2004 17:16:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvOA-00081P-JI for avt-archive@ietf.org; Wed, 27 Oct 2004 17:31:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMv0a-0003rr-Og; Wed, 27 Oct 2004 17:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuo5-0004M3-Gg for avt@megatron.ietf.org; Wed, 27 Oct 2004 16:54:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13088 for ; Wed, 27 Oct 2004 16:54:07 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMv1z-0007AK-Rr for avt@ietf.org; Wed, 27 Oct 2004 17:08:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2004 14:02:41 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9RKrSk2009734; Wed, 27 Oct 2004 13:53:28 -0700 (PDT) Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id i9RKsxHm001562; Wed, 27 Oct 2004 13:55:03 -0700 In-Reply-To: <4180089D.6040809@8x8.com> References: <4180089D.6040809@8x8.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3915C2FE-285A-11D9-BDDE-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [AVT] draft-wing-avt-rtp-noop-01.txt - another use Date: Wed, 27 Oct 2004 16:53:15 -0400 To: Jim Kleck X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098910505.744067"; x:"432200"; a:"rsa-sha1"; b:"nofws:654"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"F3XjgexsNOS6iwdoeBSYcZ6xchjFNFf29DhNvxsvZlpRLe+BTVZcrhHfJznhl" "VH2nkS/OYKeoD8gmHO1pLceKrZBStowFFqntfR/3WiMKVOuqpYBNB3su4o1wR" "EJQFzJRL6c3ttmoPahCv5aQjfvWtDw2EuH5/t/yS27htScYlI="; c:"From: David R Oran "; c:"Subject: Re: [AVT] draft-wing-avt-rtp-noop-01.txt - another use"; c:"Date: Wed, 27 Oct 2004 16:53:15 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: fandreas@cisco.com, avt@ietf.org, dwing@cisco.com X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Sure, modulo one's opinion on whether bandwidth probing is a good idea or not. On Oct 27, 2004, at 4:44 PM, Jim Kleck wrote: > Another use for these RTP no-ops is to probe to see if enough tx > bandwidth is > available to send good video at the beginning of a video call.... or > is this a no-no > since one would be using a lot of bandwidth (say up to 512K, although > only for > a short time) and if everyone did it there would be no bandwidth left > for real data? > > Jim Kleck > 8x8, Inc > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 17:19:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16748 for ; Wed, 27 Oct 2004 17:19:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvR4-00085k-Vm for avt-archive@ietf.org; Wed, 27 Oct 2004 17:34:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMv64-0006WU-D5; Wed, 27 Oct 2004 17:12:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuqz-0005SR-I5 for avt@megatron.ietf.org; Wed, 27 Oct 2004 16:57:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13423 for ; Wed, 27 Oct 2004 16:57:07 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMv4u-0007I7-QM for avt@ietf.org; Wed, 27 Oct 2004 17:11:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2004 14:15:31 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9RKu9YJ020080; Wed, 27 Oct 2004 13:56:10 -0700 (PDT) Received: from DWINGW2K4 (rtp-vpn2-402.cisco.com [10.82.241.146]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA16917; Wed, 27 Oct 2004 13:56:17 -0700 (PDT) From: "Dan Wing" To: "Jim Kleck" , , Subject: RE: [AVT] draft-wing-avt-rtp-noop-01.txt - another use Date: Wed, 27 Oct 2004 13:56:17 -0700 Keywords: dwing_to_me Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <4180089D.6040809@8x8.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit That's a reasonable use, I suppose. It does have the problem you describe where testing the link could, itself, cause the link's quality to fail for other calls. Better would be to use RSVP over a bandwidth-constrained link so that you could determine if a call could be brought up over that link. -d > -----Original Message----- > From: Jim Kleck [mailto:jimk@8x8.com] > Sent: Wednesday, October 27, 2004 1:44 PM > To: fandreas@cisco.com; oran@cisco.com; dwing@cisco.com > Cc: avt@ietf.org > Subject: [AVT] draft-wing-avt-rtp-noop-01.txt - another use > > > Another use for these RTP no-ops is to probe to see if enough tx > bandwidth is > available to send good video at the beginning of a video call.... or is > this a no-no > since one would be using a lot of bandwidth (say up to 512K, although > only for > a short time) and if everyone did it there would be no bandwidth left > for real data? > > Jim Kleck > 8x8, Inc > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 18:03:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20143 for ; Wed, 27 Oct 2004 18:03:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMw7c-0000R1-QA for avt-archive@ietf.org; Wed, 27 Oct 2004 18:18:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvqv-0002C0-4d; Wed, 27 Oct 2004 18:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAQ2-0005Gz-Iq; Mon, 25 Oct 2004 15:22:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26002; Mon, 25 Oct 2004 15:22:12 -0400 (EDT) Received: from pobox.sfu.ca ([142.58.101.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMAdX-0005Z4-Fb; Mon, 25 Oct 2004 15:36:12 -0400 Received: from liupc (liupc.cs.sfu.ca [199.60.14.115]) (authenticated bits=0) by pobox.sfu.ca (8.12.10/8.12.10/SFU-6.0G) with ESMTP id i9PJAnB5004487 (version=SSLv2 cipher=DES-CBC3-MD5 bits=168 verify=NOT); Mon, 25 Oct 2004 12:10:50 -0700 (PDT) Message-Id: <200410251910.i9PJAnB5004487@pobox.sfu.ca> Date: Mon, 25 Oct 2004 12:10:49 -0700 From: "Jiangchuan Liu" To: "multicomm" , "avt" , "iptel" , "manet" Organization: Simon Fraser University, Vancouver, BC, Canada X-mailer: Foxmail 5.0 beta2 [cn] Mime-Version: 1.0 X-Virus-Scanned: by antibody.sfu.ca running antivirus scanner X-Spam-Score: 1.1 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Wed, 27 Oct 2004 18:01:07 -0400 Subject: [AVT] CFP: First IEEE International Workshop on Multimedia Systemsand Networking (WMSN'05) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcliu@cs.sfu.ca List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0084866803==" Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --===============0084866803== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGxlYXNlIGFjY2VwdCBvdXIgYXBvbG9naWVzIGlmIHlvdSByZWNlaXZlIG11bHRpcGxlIGNvcGll cy4NCg0KQ0FMTC1GT1IgUEFQRVJTDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KICBUaGUgRmlyc3QgSUVFRSBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIE11bHRpbWVkaWEg U3lzdGVtcyBhbmQgTmV0d29ya2luZyAoV01TTicwNSkNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW4gY29uanVuY3Rpb24gd2l0aCANClRoZSAyNHRoIElFRUUgSW50ZXJuYXRpb25hbCBQ ZXJmb3JtYW5jZSBDb21wdXRpbmcgYW5kIENvbW11bmljYXRpb25zIENvbmZlcmVuY2UgKElQQ0ND JzA1KSANCg0KICAgICAgICAgICAgICAgICAgICAgQXByaWwgNy05LCAyMDA1IC0gUGhvZW5peCwg QXJpem9uYQ0KIA0KICAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuY3Muc2Z1LmNhL35qY2xp dS9XTVNOMDUuaHRtDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogDQogDQpX aXRoIHRoZSByYXBpZCBkZXZlbG9wbWVudCBvZiBwZXJzb25hbCBjb21wdXRlcnMgYW5kIHRoZSB3 aWRlc3ByZWFkIHBlbmV0cmF0aW9uIG9mIA0KYnJvYWRiYW5kIGFjY2Vzc2VzLCBtdWx0aW1lZGlh IHNlcnZpY2VzIGFyZSBnZXR0aW5nIGluY3JlYXNpbmdseSBwb3B1bGFyIGFtb25nIHVzZXJzIA0K YW5kIGhhdmUgY29udHJpYnV0ZWQgdG8gYSBzaWduaWZpY2FudCBhbW91bnQgb2YgdG9kYXmhr3Mg bmV0d29yayB0cmFmZmljLiAgVGhlIG9iamVjdGl2ZSANCm9mIHRoaXMgd29ya3Nob3AgaXMgdG8g cHJlc2VudCBzdGF0ZS1vZi10aGUtYXJ0IHJlc2VhcmNoIGFuZCBkZXZlbG9waW5nIGFjdGl2aXRp ZXMgDQpjb250cmlidXRpbmcgdG8gYWxsIGZhY2V0cyBvZiBtdWx0aW1lZGlhIHN5c3RlbXMgYW5k IG5ldHdvcmtpbmcuIFdlIGFyZSBpbnZpdGluZyBib3RoIA0KdGhlb3JldGljYWwgYW5kIGV4cGVy aW1lbnRhbCBwYXBlcnMgYXMgd2VsbCBhcyB3b3JrLWluLXByb2dyZXNzIHJlcG9ydHMuIFRvcGlj cyBvZiANCmludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86IA0KDQotIERl c2lnbiBhbmQgcGVyZm9ybWFuY2Ugb2YgbWVkaWEgc2VydmVycywgb3BlcmF0aW5nIHN5c3RlbXMs IGFuZCBtaWRkbGV3YXJlDQotIFFvUyBjb250cm9sIGFuZCBzY2hlZHVsaW5nIGZvciBJbnRlcm5l dCBtZWRpYSBkZWxpdmVyeWluZw0KLSBNZWRpYSBzdHJlYW1pbmcgb24gb3ZlcmxheSBhbmQgcGVl ci10by1wZWVyIG5ldHdvcmtzDQotIFdpcmVsZXNzIG11bHRpbWVkaWEgc3lzdGVtcyBhbmQgcGVy Zm9ybWFuY2UNCi0gTW9iaWxpdHkgaW4gbXVsdGltZWRpYSANCg0KIA0KVGVjaG5pY2FsIFByb2dy YW0gQ29tbWl0dGVlOg0KDQpDaGFpcnM6DQoNCkppYW5nY2h1YW4gTGl1ICAgICAgICAgICAJICBR aWFuIFpoYW5nDQpTaW1vbiBGcmFzZXIgVW5pdmVyc2l0eSAJICBNaWNyb3NvZnQgUmVzZWFyY2gs IEFzaWEgDQpCcml0aXNoIENvbHVtYmlhLCBDYW5hZGEJICBCZWlqaW5nLCBDaGluYQ0KDQpNZW1i ZXJzOg0KDQpBcG9zdG9saXMgU2Fsa2ludHppcywgICAgICAgTW90b3JvbGEgQ29ycG9yYXRpb24N Ckxhc3psbyBCb2Vzem9lcm1lbnlpLCAgICAgICBVbml2ZXJzaXR5IG9mIEtsYWdlbmZ1cnQNCkdy YXkgUy4tSC4gQ2hhbiwgICAgICAgICAgICBIb25nIEtvbmcgVW5pdmVyc2l0eSBvZiBTY2llbmNl IGFuZCBUZWNobm9sb2d5DQpKaWFuY29uZyAoS2VudCkgQ2hlbiwgICAgICAgUHJpbmNldG9uIFVu aXZlcnNpdHkNClhpYW93ZW4gQ2h1LCAgICAgICAgICAgICAgICBIb25nIEtvbmcgQmFwdGlzdCBV bml2ZXJzaXR5DQpab25nbWluZyBGZWksICAgICAgICAgICAgICAgVW5pdmVyc2l0eSBvZiBLZW50 dWNreQ0KWmhpaGFpIEhlLCAgICAgICAgICAgICAgICAgIFVuaXZlcnNpdHkgb2YgTWlzc291cmkt Q29sdW1iaWENCk1vaGFtZWQgSGVmZWVkYSwgICAgICAgICAgICBTaW1vbiBGcmFzZXIgVW5pdmVy c2l0eQ0KQmFvY2h1biBMaSwgICAgICAgICAgICAgICAgIFVuaXZlcnNpdHkgb2YgVG9yb250bw0K V2Fuaml1biBMaWFvLCAgICAgICAgICAgCU5hdGlvbmFsIFRhaXdhbiBVbml2ZXJzaXR5DQpNYXJj byBSb2NjZXR0aSwgICAgICAgICAgICAgVW5pdmVyc2l0eSBvZiBCb2xvZ25hIA0KWHVlbWluIChT aGVybWFuKSBTaGVuLCAgICAgIFVuaXZlcnNpdHkgb2YgV2F0ZXJsb28NCkFudGhvbnkgVmV0cm8s ICAgICAgICAgICAgICBNaXRzdWJpc2hpIEVsZWN0cmljIFJlc2VhcmNoIExhYm9yYXRvcmllcw0K QmluIFdhbmcsICAgICAgICAgICAgICAgICAgIFdyaWdodCBTdGF0ZSBVbml2ZXJzaXR5DQpEYXBl bmcgT2xpdmVyIFd1LCAgICAgICAgICAgVW5pdmVyc2l0eSBvZiBGbG9yaWRhDQpIYWl0YW8gV3Us ICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0IFJlc2VhcmNoIEFzaWENCkxpIFhpYW8sICAgICAg ICAgICAgICAgICAgICBNaWNoaWdhbiBTdGF0ZSBVbml2ZXJzaXR5DQpGYW4gWWFuZywgICAgICAg ICAgICAgICAgICAgTWljcm9zb2Z0IFJlc2VhcmNoIEFzaWENCkhlYXRoZXIgWXUsICAgICAgICAg ICAgICAgICBQYW5hc29uaWMgVGVjaG5vbG9naWVzDQpIYWlmZW5nIFpodSwgICAgICAgICAgICAg ICAgQ2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHkNCg0KSW1wb3J0YW50IERhdGVzOg0KDQpTdWJt aXNzaW9uIERlYWRsaW5lOiAgICAgICBOb3ZlbWJlciAyMCwgMjAwNA0KQWNjZXB0YW5jZSBOb3Rp ZmljYXRpb246ICAgRGVjZW1iZXIgMjAsIDIwMDQNCkNhbWVyYS1SZWFkeSBSZWNlaXZlZDogICAg IEphbnVhcnkgMTUsIDIwMDUNCg0KU3VibWlzc2lvbiBndWlkZWxpbmU6DQoNCldlIHNvbGljaXQg b25seSBvcmlnaW5hbCBhbmQgdW5wdWJsaXNoZWQgcGFwZXJzLiBBY2NlcHRlZCBwYXBlcnMgd2ls bCBiZSBwdWJsaXNoZWQgaW4gSVBDQ0MgDQpwcm9jZWVkaW5ncyBieSB0aGUgSUVFRSBwcmVzcy4g QSBzdWJtaXNzaW9uIHNob3VsZCBub3QgZXhjZWVkIDIwIGRvdWJsZSBzcGFjZWQgcGFnZXMgd2l0 aCBhIA0KZm9udCBzaXplIG9mIG5vIGxlc3MgdGhhbiAxMXB0LCBhbmQgc2hvdWxkIGluY2x1ZGUg YSBjb3ZlciBwYWdlIHdpdGggYXV0aG9yIG5hbWVzIGFuZCBhZmZpbGlhdGlvbnMsIA0KYXMgd2Vs bCBhcyB0aGUgZmF4LCB0ZWxlcGhvbmUgbnVtYmVyLCBhbmQgZS1tYWlsIGFkZHJlc3MgZm9yIHRo ZSBjb250YWN0IGF1dGhvci4gUGxlYXNlIHN1Ym1pdCANCmluIFBERiBmb3JtYXQgYnkgZW1haWwg dG8gUHJvZi4gSmlhbmdjaHVhbiBMaXUgKGpjbGl1QGNzLnNmdS5jYSkuICBBbiBhY2tub3dsZWRn ZW1lbnQgd2l0aCBhIA0KcGFwZXIgSUQgd2lsbCBiZSBnZW5lcmF0ZWQuIFBsZWFzZSBjb250YWN0 IFRQQyBjaGFpcnMgaWYgbm8gYWNrbm93bGVkZ2VtZW50IGlzIHJlY2VpdmVkIHdpdGhpbiANCnRo cmVlIGRheXMgYWZ0ZXIgc3VibWlzc2lvbi4gDQoNCg== --===============0084866803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --===============0084866803==-- From avt-bounces@ietf.org Wed Oct 27 18:10:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20888 for ; Wed, 27 Oct 2004 18:10:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwDg-0000Y9-Hs for avt-archive@ietf.org; Wed, 27 Oct 2004 18:24:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvqv-0002Ca-Kz; Wed, 27 Oct 2004 18:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMG3z-0006Ud-PD for avt@megatron.ietf.org; Mon, 25 Oct 2004 21:23:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28121 for ; Mon, 25 Oct 2004 21:23:49 -0400 (EDT) Received: from services106.cs.uwaterloo.ca ([129.97.152.164] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGHY-0006ZD-Ez for avt@ietf.org; Mon, 25 Oct 2004 21:37:52 -0400 Received: from cpu110.cs.uwaterloo.ca (daemon@cpu110.cs.uwaterloo.ca [129.97.152.198]) by services106.cs.uwaterloo.ca (8.11.7/8.11.7) with ESMTP id i9Q1DNH20029; Mon, 25 Oct 2004 21:13:25 -0400 (EDT) Received: (from hyh2li@localhost) by cpu110.cs.uwaterloo.ca (8.11.7/8.11.7) id i9Q1Axs02564; Mon, 25 Oct 2004 21:10:59 -0400 (EDT) Date: Mon, 25 Oct 2004 21:10:58 -0400 (EDT) From: Herman Li To: Undisclosed Recipients Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at rhadamanthus by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75g on localhost X-Virus-Status: Clean X-Spam-Score: 2.7 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Wed, 27 Oct 2004 18:01:07 -0400 Subject: [AVT] Networking 2005 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Apologies if you receive multiple copies of this email -------------------------------------------------------------------- IFIP NETWORKING 2005 -- CALL FOR PAPERS University of Waterloo, Waterloo Ontario Canada May 2 - 6, 2005 http://www.cs.uwaterloo.ca/Networking2005/topics/call_papers.html Due date for submissions: November 8, 2004 Networking 2005 is the fourth event in the series of International Conferences on Networking, organized by the IFIP Technical Committee on Communication Systems (TC 6). Previous events were held in Paris (France) in 2000, Pisa (Italy) in 2002, and Athens (Greece) in 2004. Based on the success of this biannual event, IFIP TC 6 decided to hold the Networking conference every year starting in 2005. Networking 2005 will take place between May 2 and 6, at the University of Waterloo, Ontario, Canada. The conference is organized by the University of Waterloo and sponsored by the IFIP working groups on Network and Internetwork Architectures (WG 6.2), Performance of Communication Systems (WG 6.3), Wireless Communications (WG 6.8), and Photonic Networking (WG 6.10). Networking 2005 will be structured along three tracks: Networking Technologies, Services and Protocols Performance of Computer and Communication Networks Mobile and Wireless Communications Systems For more information on topics of interest and submission guidelines, please visit the conference Web page at: http://www.cs.uwaterloo.ca/Networking2005/index.html -------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Wed Oct 27 18:42:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24558 for ; Wed, 27 Oct 2004 18:42:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwjH-0001FW-5q for avt-archive@ietf.org; Wed, 27 Oct 2004 18:57:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwTx-0007mt-9D; Wed, 27 Oct 2004 18:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwNU-0006Pv-CP for avt@megatron.ietf.org; Wed, 27 Oct 2004 18:34:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23864 for ; Wed, 27 Oct 2004 18:34:44 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwbR-00013c-9k for avt@ietf.org; Wed, 27 Oct 2004 18:49:13 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62469 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CMwMy-0007cF-UQ for avt@ietf.org; Wed, 27 Oct 2004 23:34:17 +0100 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <545576F4-2868-11D9-8AB3-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: avt From: Colin Perkins Date: Wed, 27 Oct 2004 23:34:14 +0100 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [AVT] AVT at IETF 61 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Folks, Note that the latest draft agenda has AVT scheduled for 15:30-17:30 on Monday and 13:00-15:00 on Thursday. This is a change from the previously announced schedule. If this causes significant problems please let the chairs know immediately. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 28 05:02:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21362 for ; Thu, 28 Oct 2004 05:02:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN6Og-00046T-NU for avt-archive@ietf.org; Thu, 28 Oct 2004 05:16:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN69M-0006Av-1b; Thu, 28 Oct 2004 05:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN641-0005Hr-1r for avt@megatron.ietf.org; Thu, 28 Oct 2004 04:55:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20569 for ; Thu, 28 Oct 2004 04:55:18 -0400 (EDT) Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN6I1-0003uF-2g for avt@ietf.org; Thu, 28 Oct 2004 05:09:50 -0400 Received: from antivir1.rad.co.il ([127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id i9S8sGS8029605 for ; Thu, 28 Oct 2004 10:54:16 +0200 (IST) Received: from mailframer.rad.co.il (mailframer.rad.co.il [192.114.24.181]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id i9S8sF5J029601 for ; Thu, 28 Oct 2004 10:54:15 +0200 (IST) Received: (from root@localhost) by mailframer.rad.co.il (8.12.11/8.12.9/Submit) id i9S8vrS2001974 for avt@ietf.org; Thu, 28 Oct 2004 10:57:53 +0200 Received: from exrad2.ad.rad.co.il ([192.114.24.112]) by mailframer.rad.co.il (8.12.11/8.12.9) with ESMTP id i9S8vrqb001969; Thu, 28 Oct 2004 10:57:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [AVT] questions about jitter Date: Thu, 28 Oct 2004 10:53:14 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5203353FD6@exrad2.ad.rad.co.il> Thread-Topic: [AVT] questions about jitter Thread-Index: AcS8XyBNdIGXQN5xQQSNnMEyN7ibYwAaNc+w From: "Yaakov Stein" To: "Randell Jesup" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailframer.rad.co.il id i9S8vrqb001969 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 8bit Cc: Fangweiwei , avt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit > Jitter is relevant to audio quality on it's own, > separately from packet loss - it affects (strongly) the > minimum amount of jitter buffer required to avoid underflow > losses, and that delay affects call quality in an interactive > stream. Of course the absolute amount of delay is important in interactive systems, but (assuming that echo is not an issue) perhaps not as important as was once thought. In any case, there is a trade-off between the effect of jitter buffer minimum delay and packet-loss degradation. I suggest consulting ITU-T P.1010 and G.1020 on this issue. In addition, modern methods of processing audio packets can greatly reduce the minimal delay as compared to static jitter buffer mechanisms. Y(J)S _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 28 08:06:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05570 for ; Thu, 28 Oct 2004 08:06:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9Go-0007jr-Rz for avt-archive@ietf.org; Thu, 28 Oct 2004 08:20:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN91S-0005A6-BF; Thu, 28 Oct 2004 08:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8wU-0004SO-Cw for avt@megatron.ietf.org; Thu, 28 Oct 2004 07:59:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05159 for ; Thu, 28 Oct 2004 07:59:45 -0400 (EDT) Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9AX-0007cu-Dj for avt@ietf.org; Thu, 28 Oct 2004 08:14:18 -0400 Received: from [68.158.2.200] (port=1366 helo=telws116) by mx.cbeyond.com with asmtp (Exim 4.34) id 1CN8wA-0001N7-KJ; Thu, 28 Oct 2004 07:59:26 -0400 From: "Alan Clark" To: "Randell Jesup" , "Yaakov Stein" Subject: RE: [AVT] questions about jitter Date: Thu, 28 Oct 2004 07:59:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Fangweiwei , avt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit >So for many uses, while amusing, the RTCP data on loss (and probably >jitter) is close to worthless, and certainly has to be taken as at best >fuzzy data. Post-jitter data (handling late packets, duplicates, etc) is >more useful in most cases. I'm sure part of the reason it's defined this >way is so an RTP stack can calculate the loss & jitter simply without >having to communicate in any way with the jitter buffer. This is one reason that the RFC3611 VoIP metrics:- (a) tightens up the definition of "lost" (b) reports discarded packets, i.e. a packet is either usable, lost or discarded (c) reports discards rather than jitter, as it is a more concrete measure of what happened as a result of jitter The whole problem becomes a little more complex when you assume that jitter is a time variant process, which it generally is. What is the meaning of a short term average jitter measure when the jitter level is not constant? With regard to the relationship between jitter level and jitter buffer size - this also is a more complex problem in practice as jitter is typically heavily time varying and jitter buffers are often dynamic. AS mentioned in an earlier posting to AVT - there is an interesting (free) tool on the www.voiptroubleshooter.com web site - on the "online diagnosis" page. This uses a time series model as a basis for generating a sequence of packet delays and exports these to a log file for analysis if needed. Alan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 28 08:37:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07685 for ; Thu, 28 Oct 2004 08:37:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9ki-0008L1-QZ for avt-archive@ietf.org; Thu, 28 Oct 2004 08:51:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9TX-0001ht-EW; Thu, 28 Oct 2004 08:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9QK-0000yd-TU for avt@megatron.ietf.org; Thu, 28 Oct 2004 08:30:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07157 for ; Thu, 28 Oct 2004 08:30:36 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9eE-0008Cc-IS for avt@ietf.org; Thu, 28 Oct 2004 08:45:09 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9SCUOfM019607 for ; Thu, 28 Oct 2004 14:30:24 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Oct 2004 14:30:24 +0200 Received: from [147.214.34.66] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.66]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJQFJJGJ; Thu, 28 Oct 2004 14:30:24 +0200 Message-ID: <4180E65F.2060402@ericsson.com> Date: Thu, 28 Oct 2004 14:30:23 +0200 X-Sybari-Trust: f87e779b ad48f3dd 0a52791a 00000179 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2004 12:30:24.0207 (UTC) FILETIME=[E5CD85F0:01C4BCE9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Subject: [AVT] Problems with uRTR: draft-ietf-avt-variable-rate-audio-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Hi, I have discussed the issue around RTP timestamp for variable sampling rate codecs with my colleagues and also Colin to get as good idea of the issues as possible. We also went through the exercise of to see what the usage of an uRTR (unified RTP timestamp rate) concept would mean for the RTP payload format for AMR-WB+. This revealed a number of issues. Lets start with a brief explanation of the system view for codec like AMR-WB+: 1. Input sampling (Input Sampling Rate) -> 2. encoding into frames using a specific codec internal sampling frequency (ISF) -> 3. RTP packetization, and assigning an RTP TS value for each frame (RTP TS rate) -> 4. Transmission -> 5. RTP Reception -> 6. Buffering -> 7. Decoding to Output Sampling Rate -> 8. Audio playout (Output Sampling Rate) In such a codec system, the Input Sampling Frequency must not necessary match the output sampling frequency. The audio signals bandwidth is dependent on the selected ISF. Thus Input and output sampling frequency should be larger then ISF. The RTP payload and timestamp must provide the receiver with sufficient information for: - Recovery of decoding and playout position and order - Intermedia synchronization First, a common thing when using an RTP timestamp rate not matching the input sampling rate is that the sampling instance may not be represented by an integer timestamp value, instead it may be fractional. This can lead to a initial offset error to another media, when starting decoding, due to the rounding. When one uses uRTR or a timestamp rate that results in that the transport units, either samples or audio frames, do not have integer timestamp tick duration is that one may get in-stream jitter. This is due to that a frame has a duration in the RTP timestamp domain that is fractional, the rounding error becomes the error in placing the data correctly on the timescale. This may not be a serious problem for frame based codecs as long as all data arrives, as then one can run a scheme that concatenates the data to be decoded into a correct stream. Thus the decoder output should be correctly and unjittered stream. However if losses occurs then one may needs to insert the data without the help of prior data to determine what the fractional offset it, thus potentially introducing jitter in the placement. If I understand things correctly, the inter media synchronization error is normally not a problem as humans are quite tolerable to offset. However we are very sensitive to jitter within an audio stream. The error introduced by fractional frame lengths will also have impact on the RTP payload design. When aggregating frames for frame-based codecs the normal RTP timestamp recovery scheme is to calculate the RTP TS as: RTP TS value + N * , where N is the number of frames prior to this frame. However if one can't express the frame duration in integer number of RTP ticks, then the error is multiplied by N. Thus an error can grove to several timestamp ticks. Or one uses an scheme that provide absolute RTP TS offset values, which will raise the need overhead for aggregation. For sample based codecs where the smallest unit is a sample, the fractional error may be even harder to handle due to need for greater precision in alignment and potential less regular borders between packets. There also seem very hard to select a uRTR that will work well. First, audio has two families for frequencies used: - 8000, 16000, 24000, 32000, 48000, 96000, 192000 - 11025, 22050, 44100, 88200 The frequency span is also quite large due different applications. The higher values of 192k and 88.2k are used in SACD and DVD-Audio and can be expected to occur. Thus selection of a common rate within what is practically feasible (lower than a few MHz due to the wrap around) within RTP seem to not be possible. Thus any selected rate would most likely result in a compromise leading to bad conversion factors for either of the two families. Due to these issues, I think AMR-WB+ should keep its 72kHz RTP timestamp rate, as it provides the codec with the necessary audio frame location on full resolution clock without jitter. It also has quite good clock conversion factors for commonly used output frequencies: Hz # of 72kHz ticks per left column frequency tick 8000 9 16000 4,5 24000 3 25600 2,8125 32000 2,25 44100 1,632653061 48000 1,5 Another common problem with uRTR and more free choice of the RTP timestamp rate is the impact on the client implementations. Most multi-media clients are driven by the audio card clock. The client implementation uses the audio clock and to know when it needs to decode, remove data from receiver buffer, etc. Thus RTP timestamp rates will need to be converted to that clock and errors may arise also here. Allowing different rates to be used on different codecs will result in the need for handling conversion for more than one rate. Thus making codec plug-ins a more difficult. In conclusion, not using uRTR will more likely allow for maintained precision of where the audio data belongs. The client implementation will be slightly more impacted then what it would be for uRTR however I think this might be the price we need to accept. I would also propose that the issues around RTP timestamp rates for audio is documented in a informational RFC. This would included both the recommendation to use input sampling frequency when applicable. Variable rate codec do expose limitations in RTP and these should also be documented. Further recommendations on how to select rates, and that these may need to be considered already in codec development should also be part of it. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 28 09:02:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09592 for ; Thu, 28 Oct 2004 09:02:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNA8p-0000Sk-Gp for avt-archive@ietf.org; Thu, 28 Oct 2004 09:16:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9tZ-00071c-Qg; Thu, 28 Oct 2004 09:00:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9l9-0005CR-W3 for avt@megatron.ietf.org; Thu, 28 Oct 2004 08:52:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08659 for ; Thu, 28 Oct 2004 08:52:07 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9zD-0000Bd-Mt for avt@ietf.org; Thu, 28 Oct 2004 09:06:41 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9SCi47X001483 for ; Thu, 28 Oct 2004 07:44:04 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9SCi27X001447 for ; Thu, 28 Oct 2004 07:44:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] questions about jitter Date: Thu, 28 Oct 2004 14:52:02 +0200 Message-ID: Thread-Topic: [AVT] questions about jitter Thread-Index: AcS8ap2TFiCFC3jZQhOeRNPKYfkbmAAgaArA From: "Romascanu, Dan \(Dan\)" To: "Colin Perkins" , "Randell Jesup" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: Fangweiwei , Yaakov Stein , avt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable > > > > Note that RFC 3550 RTCP defines "loss" in a very weird way;=20 > it allows=20 > > very > > late packets to not be considered "lost", and it counts=20 > duplicates as > > multiple separate packets (so if you lose packet N, and get two of=20 > > packet > > N+1, that's considered 0 loss!!!) Also, since loss is based on the=20 > > last > > packet received (packet N), if the previous packet (N-1) arrives > > out-of-order (but in time to be played) after the RTCP is sent, the=20 > > RTCP > > will show that as a loss, and in the next RTCP an extra packet will > > be counted (and yes, this can lead to negative loss rates). > > > > So for many uses, while amusing, the RTCP data on loss (and probably > > jitter) is close to worthless, and certainly has to be=20 > taken as at best > > fuzzy data. Post-jitter data (handling late packets,=20 > duplicates, etc)=20 > > is > > more useful in most cases. I'm sure part of the reason=20 > it's defined=20 > > this > > way is so an RTP stack can calculate the loss & jitter=20 > simply without > > having to communicate in any way with the jitter buffer. >=20 > And there's RFC 3611 if you need more detailed statistics. >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 > I've run into similar issues when doing RAQMON and trying to refer RFC = 3550 for some of the metrics to measure application QoS. At the end of = the day we had to define new or supplementary metrics for jitter, loss = and discards, and differentiate between the network and application = layer metrics. It looks like RFC 3550 is in need of a revision on this = respect. =20 Regards, Dan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 28 10:11:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15407 for ; Thu, 28 Oct 2004 10:11:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBDn-00024u-O3 for avt-archive@ietf.org; Thu, 28 Oct 2004 10:25:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAuS-0004zg-ME; Thu, 28 Oct 2004 10:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAry-0003cz-Ng for avt@megatron.ietf.org; Thu, 28 Oct 2004 10:03:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14433 for ; Thu, 28 Oct 2004 10:03:14 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNB5t-0001sz-62 for avt@ietf.org; Thu, 28 Oct 2004 10:17:48 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9SE32WR006341 for ; Thu, 28 Oct 2004 16:03:02 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Oct 2004 16:03:01 +0200 Received: from [147.214.34.66] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.66]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSL52TH; Thu, 28 Oct 2004 16:03:01 +0200 Message-ID: <4180FC15.80806@ericsson.com> Date: Thu, 28 Oct 2004 16:03:01 +0200 X-Sybari-Trust: 312179d6 bfd556f1 a08104cf 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: multipart/mixed; boundary="------------030702090305090009020503" X-OriginalArrivalTime: 28 Oct 2004 14:03:01.0951 (UTC) FILETIME=[D679F4F0:01C4BCF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [AVT] Updated AVT agenda for IETF 61 in Washington D.C. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. --------------030702090305090009020503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, As Colin announced AVT is now Monday and Thursday. We also received one more request for agenda time. Thus I have moved around a few things. People that had requested Wednesday are scheduled on the Monday session. Please send any comments as soon as possible. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com --------------030702090305090009020503 Content-Type: text/plain; name="Agenda-v1.txt" Content-Disposition: inline; filename="Agenda-v1.txt" Content-Transfer-Encoding: base64 QXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdvcmtpbmcgR3JvdXANCg0KQ0hBSVJTOiBDb2xpbiBQ ZXJraW5zICAgICA8Y3NwQGNzcGVya2lucy5vcmc+DQogICAgICAgIE1hZ251cyBXZXN0ZXJs dW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQoNCg0KTW9uZGF5LCBOb3Zl bWJlciA4LCAyMDA0IDE1OjMwLTE3OjMwDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNCkludHJvZHVjdGlvbiBhbmQgU3RhdHVzIFVwZGF0ZQkJCQkgICAg ICAgKENoYWlycykgIA0KCSAgICAgICAgIAkJCQkJCSAyMCBtaW4NCk1JREkNClJGQyAyMDMy IGJpcw0KUkZDIDI0MjkgYmlzDQpkcmFmdC1iYXNzby1hdnQtdmlkZW9jb25yZXEtMDIudHh0 DQoNClJUUCBUaW1lc3RhbXAgdXNhZ2UgZm9yIHZhcmlhYmxlIHNhbXBsZSByYXRlIGF1ZGlv IGNvZGVjcyAgICAgIChXZW5nZXIpDQoJZHJhZnQtaWV0Zi1hdnQtdmFyaWFibGUtcmF0ZS1h dWRpby0wMC50eHQJICAgICAgIChDaGFpcnMpDQoJTWFpbCBEaXNjdXNzaW9uCQkJCQkJIDMw IG1pbg0KDQpWTVItV0IgUlRQIFBheWxvYWQgYW5kIEZpbGUgRm9ybWF0IEludGVybmV0IERy YWZ0cwkgICAgICAgKEFobWFkaSkNCglkcmFmdC1pZXRmLWF2dC12bXItd2ItZmlsZS1mb3Jt YXQtMDAudHh0CQkgMTUgbWluDQoJZHJhZnQtaWV0Zi1hdnQtcnRwLXZtci13Yi0wNS50eHQN Cg0KVXBkYXRlIG9mIFJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgQU1SIGFuZCBBTVItV0IJCSAg IChXZXN0ZXJsdW5kKQ0KCWRyYWZ0LWlldGYtYXZ0LXJ0cC1hbXItYmlzLTAwLnR4dAkJCSAx NSBtaW4NCg0KQ2hhbmdlcyBpbiBKUEVHIDIwMDAgVmlkZW8gUlRQIFBheWxvYWQgRm9ybWF0 CQkJKExldW5nKQ0KCWRyYWZ0LWlldGYtYXZ0LWpwZWcyMDAwLTA2LnR4dAkJCQkgMTUgbWlu DQoNClJUQ1AgWFIgTUlCCQkJCQkgICAgKENsYXJrICYgUGVuZGxldG9uKQ0KCWRyYWZ0LWll dGYtYXZ0LXJ0Y3AteHItbWliLTAwLnR4dAkJCSAxNSBtaW4NCg0KDQpUSFVSU0RBWSwgTm92 ZW1iZXIgMTEsIDIwMDQgMTMwMC0xNTAwDQoNCkludHJvZHVjdGlvbgkJCQkJCSAgICAgICAo Q2hhaXJzKQ0KCQkJCQkJCQkgIDUgbWluDQoNClJUUCBQcm9maWxlIGZvciBUQ1AgRnJpZW5k bHkgUmF0ZSBDb250cm9sCQkJKExhZGFuKQ0KZHJhZnQtaWV0Zi1hdnQtdGZyYy1wcm9maWxl LTAzLnR4dAkJCQkgMjUgbWluDQoNCk9wZW4gaXNzdWVzIGluIFJGQyAyODMzYmlzCQkJCSAg ICAgICAoVGF5bG9yKQ0KCWRyYWZ0LWlldGYtYXZ0LXJmYzI4MzNiaXMtMDUudHh0CQkJIDE1 IG1pbg0KDQpGYXIgRW5kIENhbWVyYSBDb250cm9sIHByb3RvY29sCQkJCQkgKEV2ZW4pDQpk cmFmdC1ldmVuLWF2dC1oMjI0LTAwLnR4dAkJCQkJIDE1IG1pbg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLSAqIC0= --------------030702090305090009020503 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --------------030702090305090009020503-- From avt-bounces@ietf.org Thu Oct 28 10:47:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19553 for ; Thu, 28 Oct 2004 10:47:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBnE-0002uH-E3 for avt-archive@ietf.org; Thu, 28 Oct 2004 11:02:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBUK-0000hn-4o; Thu, 28 Oct 2004 10:42:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBPC-0007pp-Oz for avt@megatron.ietf.org; Thu, 28 Oct 2004 10:37:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18322 for ; Thu, 28 Oct 2004 10:37:33 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBd8-0002ev-F8 for avt@ietf.org; Thu, 28 Oct 2004 10:52:09 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9SEbNWR015099 for ; Thu, 28 Oct 2004 16:37:23 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Oct 2004 16:37:22 +0200 Received: from [147.214.34.66] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.66]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSL5RXP; Thu, 28 Oct 2004 16:37:22 +0200 Message-ID: <41810422.3070701@ericsson.com> Date: Thu, 28 Oct 2004 16:37:22 +0200 X-Sybari-Trust: 22ffce0d bfd556f1 a08104cf 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2004 14:37:22.0635 (UTC) FILETIME=[A2BD61B0:01C4BCFB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [AVT] Work on FEC framework for RTP within 3GPP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi, I would like to make all aware of the work on a FEC framework for RTP that is ongoing within the 3GPP SA4. It was agreed in the SA4 ad hoc meeting 11-13th of October on a working assumption that is according to: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/Ad-hoc_PSM/Docs/S4-AHP159.zip with the following changes: - The FEC stream and the original data stream will be SSRC multiplexed instead of session multiplexed. - The FEC payload header (the "FEC Tag") will be moved from last in the payload to first in the payload for the original stream format. 3GPP SA4 will continue to work in neckbreaking speed on this. A proposal for specification text for this FEC framework is expected to be available in time for the next SA4 meeting (22-26th Nov). The specification text needs to be approved on that meeting to meet the current deadline. Comments on the approach is solicited. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 28 10:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19738 for ; Thu, 28 Oct 2004 10:49:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBox-0002xM-9R for avt-archive@ietf.org; Thu, 28 Oct 2004 11:04:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBYP-0001qH-BQ; Thu, 28 Oct 2004 10:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBQ3-00083P-Hk; Thu, 28 Oct 2004 10:38:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18391; Thu, 28 Oct 2004 10:38:26 -0400 (EDT) Message-Id: <200410281438.KAA18391@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 10:38:26 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback Author(s) : J. Chesterfield, et al. Filename : draft-ietf-avt-rtcpssm-08.txt Pages : 40 Date : 2004-10-27 This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcpssm-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcpssm-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28105507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcpssm-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcpssm-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105507.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 28 10:56:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20748 for ; Thu, 28 Oct 2004 10:56:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBvl-0003Bi-Us for avt-archive@ietf.org; Thu, 28 Oct 2004 11:11:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBYq-00028M-1g; Thu, 28 Oct 2004 10:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBQY-00089m-Jy; Thu, 28 Oct 2004 10:38:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18431; Thu, 28 Oct 2004 10:38:57 -0400 (EDT) Message-Id: <200410281438.KAA18431@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 10:38:57 -0400 Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for JPEG 2000 Video Streams Author(s) : S. Futemma, et al. Filename : draft-ietf-avt-rtp-jpeg2000-06.txt Pages : 27 Date : 2004-10-27 This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, JPEG 2000. JPEG 2000 features are considered and there are provisions in this payload format for scalability, prioritization of different parts of the codestream, and error recovery. JPEG 2000 is a truly scalable compression technology allowing applications to encode one way and decode many different ways. Extending from one image to a series of JPEG 2000 images, one has a JPEG 2000 video stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-jpeg2000-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28105521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-jpeg2000-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105521.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart-- From avt-bounces@ietf.org Thu Oct 28 14:34:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11095 for ; Thu, 28 Oct 2004 14:34:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNFL0-0002lb-7B for avt-archive@ietf.org; Thu, 28 Oct 2004 14:49:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCmF-0005Mi-Hn; Thu, 28 Oct 2004 12:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBqu-0007K6-CE for avt@megatron.ietf.org; Thu, 28 Oct 2004 11:06:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22412 for ; Thu, 28 Oct 2004 11:06:11 -0400 (EDT) Received: from out008pub.verizon.net ([206.46.170.108] helo=out008.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNC4z-0003en-LS for avt@ietf.org; Thu, 28 Oct 2004 11:20:47 -0400 Received: from [65.114.168.149] by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20041028150604.PQNZ11892.out008.verizon.net@[65.114.168.149]>; Thu, 28 Oct 2004 10:06:04 -0500 In-Reply-To: <417FF447.90606@8x8.com> References: <417FF447.90606@8x8.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ladan Gharai Subject: Re: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback in RTP? Date: Thu, 28 Oct 2004 11:05:28 -0400 To: Jim Kleck X-Mailer: Apple Mail (2.619) X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [65.114.168.149] at Thu, 28 Oct 2004 10:06:03 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Jim: Thank you for your feedback - you raise a good point and actually the ratio between data and feedback traffic is currently an open issue on the draft, discussed in Section 9. RFC 3350 recommends that feedback traffic not exceed %5 of the data traffic. However, there are combinations of data rates, RTTs and packet sizes in which if the AVPCC profile is to abide by TFRC's (RFC 3448) feedback requirements, then feedback traffic will exceed 5% of data traffic For example: a 512kbps flow with packet sizes of 50bytes and RTT=5ms, will generate at least 140kbps of RTCP feedback (according to the current version of the draft) - which is some what excessive and counter intuitive to congestion control. The same data flow with RTTs of 10ms, 20ms and 100ms will generate 70kbps, 35kbps and 7kbps of feedback (at 14%, 6%, 1.3% of the data traffic). Small RTTs (<10ms) and data rates of < 1Mbps generally translate to (depending on packet sizes) to few packets per RTT - one solution could be to modify feedback timing requirements, such that the ratio of feedback to data traffic is not prohibitive in instances where RTTs and number of packets per RTT are relatively small. Imbedding control traffic in the RTP packet does not present a general solution, because as you point out, it would only work for two-way traffic and even in the case of two-way traffic it is generally complicated and not always possible given TFRCs timing requirements for feedback. Ladan On Oct 27, 2004, at 3:17 PM, Jim Kleck wrote: > The draft-ietf-avt-tfrc-profile-03.txt is specifically restricted to > unicast, > and specifies feedback possibly once per data packet. This can generate > too much feedback traffic in the case of one-to-one video conferencing > (which typically operates at 64K - 512K bps). However, this case offers > a ready feedback path with much less overhead: the data pkts coming > from > the far end. An additional extension to the RTP hdr could possibly add > the feedback at a small cost. The challenges with this scheme are: > > - there is an implicit tie between the Tx and Rx RTP sessions, but in > a one-to-one video conference that should not be too hard to formalize > > - if the app does not recv any data pkts from the farend for a while > then > there will be no feedback, that could mean the far end has nothing to > send > (in which case a noop RTP pkt with the feedback could be specified, > see draft-wing-avt-rtp-noop-01.txt, with no worries about using extra > bandwidth because the lack of data makes that bandwidth available... > or use the suggested Receiver Report extensions), or it could mean > that > there is some network problem > > > Does this seem worth further investigation? > > Jim Kleck > 8x8, Inc > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Thu Oct 28 19:06:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05856 for ; Thu, 28 Oct 2004 19:06:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJZZ-00020m-Lb for avt-archive@ietf.org; Thu, 28 Oct 2004 19:20:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGV8-0007Vb-9A; Thu, 28 Oct 2004 16:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNEJL-0007XX-Te for avt@megatron.ietf.org; Thu, 28 Oct 2004 13:43:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29615 for ; Thu, 28 Oct 2004 13:43:43 -0400 (EDT) From: sassan.ahmadi@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNEXR-0007HC-RC for avt@ietf.org; Thu, 28 Oct 2004 13:58:19 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SHhXe06062; Thu, 28 Oct 2004 20:43:33 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 20:43:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9SHh2AV024657; Thu, 28 Oct 2004 20:43:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00YqgvPu; Thu, 28 Oct 2004 20:43:01 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SHgxa21232; Thu, 28 Oct 2004 20:42:59 +0300 (EET DST) Received: from sdebe002.NOE.Nokia.com ([172.19.201.138]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 12:41:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Oct 2004 10:41:39 -0700 Message-ID: <0B08EA1BF5F6304992CDC985EE02209E02342C01@sdebe002.americas.nokia.com> Thread-Topic: [AVT] Problems with uRTR: draft-ietf-avt-variable-rate-audio-00.txt Thread-Index: AcS860+DfbWf5weIRb+J3ueY5QXU1gAKWufQ X-Priority: 1 Priority: Urgent Importance: high To: , X-OriginalArrivalTime: 28 Oct 2004 17:41:47.0918 (UTC) FILETIME=[662992E0:01C4BD15] X-Spam-Score: 1.6 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: [AVT] Discussion of draft-ietf-avt-variable-rate-audio-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Dear AVT Chairs, Since the agenda/schedule of the AVT meetings has unexpectedly changed = yesterday, and given that some people like myself would not be able to = attend the Monday meeting, it would be greatly appreciated if the = discussion of draft-ietf-avt-variable-rate-audio-00.txt is rescheduled = for Thursday afternoon so that we can attend and contribute to the = discussion. Your consideration is appreciated in advance. Regards -Sassan Ahmadi _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 29 01:18:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09963 for ; Fri, 29 Oct 2004 01:18:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPOG-0005CI-5l for avt-archive@ietf.org; Fri, 29 Oct 2004 01:33:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNP7P-0005Qp-Ty; Fri, 29 Oct 2004 01:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNP4n-0002Gs-Ur for avt@megatron.ietf.org; Fri, 29 Oct 2004 01:13:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09674 for ; Fri, 29 Oct 2004 01:13:24 -0400 (EDT) From: phil@plus24.com Message-Id: <200410290513.BAA09674@ietf.org> Received: from host-84-9-85-174.bulldogdsl.com ([84.9.85.174] helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNPIr-00055T-1B for avt@ietf.org; Fri, 29 Oct 2004 01:28:07 -0400 To: avt@ietf.org Date: Fri, 29 Oct 2004 06:13:11 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="37642130" X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [AVT] robos! X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 --37642130 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit receitas de bolo!! --37642130 Content-Type: application/x-zip-compressed; name=":-).zip" Content-Disposition: attachment; filename=":-).zip" Content-Transfer-Encoding: base64 --37642130 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --37642130-- From avt-bounces@ietf.org Fri Oct 29 03:32:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02518 for ; Fri, 29 Oct 2004 03:32:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNRTL-0007bM-H5 for avt-archive@ietf.org; Fri, 29 Oct 2004 03:46:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNR24-0008Fw-A8; Fri, 29 Oct 2004 03:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQtL-0002KZ-Ca for avt@megatron.ietf.org; Fri, 29 Oct 2004 03:09:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00752 for ; Fri, 29 Oct 2004 03:09:40 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNR7Y-00071m-Mq for avt@ietf.org; Fri, 29 Oct 2004 03:24:25 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60307 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CNQso-0007Tu-CQ; Fri, 29 Oct 2004 08:09:10 +0100 In-Reply-To: <0B08EA1BF5F6304992CDC985EE02209E02342C01@sdebe002.americas.nokia.com> References: <0B08EA1BF5F6304992CDC985EE02209E02342C01@sdebe002.americas.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6A76693D-2979-11D9-8F23-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 29 Oct 2004 08:09:03 +0100 To: X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: [AVT] Re: Discussion of draft-ietf-avt-variable-rate-audio-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Sassan, On 28 Oct 2004, at 18:41, wrote: > Since the agenda/schedule of the AVT meetings has unexpectedly changed > yesterday, and given that some people like myself would not be able to > attend the Monday meeting, it would be greatly appreciated if the > discussion of draft-ietf-avt-variable-rate-audio-00.txt is rescheduled > for Thursday afternoon so that we can attend and contribute to the > discussion. As I said in reply to your private request on the same subject, we'll try to arrange this. Note, however, that it becomes very difficult to arrange the meeting agenda if participants only attend for a subset of the meeting. I would strongly urge members of the working group to either attend for the entire IETF meeting, or to wait until the final IETF agenda is posted before arranging their travel. The dates for agenda slots frequently changes at the last minute. It is not advisable to use the early draft IETF agenda to arrange travel (indeed, the agenda is still changing as conflicts between working groups are resolved). -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 29 10:42:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05772 for ; Fri, 29 Oct 2004 10:42:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNYBP-0000Q7-HQ for avt-archive@ietf.org; Fri, 29 Oct 2004 10:56:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNXes-00011C-Dy; Fri, 29 Oct 2004 10:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNXWy-00048f-Rw for avt@megatron.ietf.org; Fri, 29 Oct 2004 10:15:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02961 for ; Fri, 29 Oct 2004 10:15:02 -0400 (EDT) Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNXlC-0008BA-4d for avt@ietf.org; Fri, 29 Oct 2004 10:29:51 -0400 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i9TEEQ1l020112 for ; Fri, 29 Oct 2004 10:14:26 -0400 (EDT) Received: from sonusmail03.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Fri, 29 Oct 2004 10:14:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback in RTP? Date: Fri, 29 Oct 2004 10:14:25 -0400 Message-ID: Thread-Topic: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback in RTP? Thread-Index: AcS9HPEt8O7ZPZeZQjSNXaPZDorLeAAoo6CQ From: "Phelan, Tom" To: "Ladan Gharai" , "Jim Kleck" X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: IETF AVT WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Hi, For those of you AVT'ers interested in TFRC and its possible uses for = streaming media, I released a paper earlier this month on a simulation = study of TFRC with self-limiting sources such as streaming voice. The = paper is available at http://www.phelan-4.com/dccp/tfrc-self-limit.pdf. = Overall, the paper presents a rather bleak picture of the suitability of = TFRC for voice applications. There is an active discussion of this paper and its implications on the = DCCP mailing list. At the current time, Sally Floyd is proposing some = possible modifications to the TFRC algorithm, to help it work better = with voice media streams. This appears promising, but the discussion of = these mods is at an early stage. Anyone with an interest is welcomed to join the discussion, of course. Tom Phelan > -----Original Message----- > From: Ladan Gharai [mailto:ladan@isi.edu] > Sent: Thursday, October 28, 2004 11:05 AM > To: Jim Kleck > Cc: IETF AVT WG > Subject: Re: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback > in RTP? >=20 >=20 > Jim: >=20 > Thank you for your feedback - you raise a good point and actually the=20 > ratio between data and feedback traffic is currently an open issue on=20 > the draft, discussed in Section 9. >=20 > RFC 3350 recommends that feedback traffic not exceed %5 of the data=20 > traffic. > However, there are combinations of data rates, RTTs and packet sizes =20 > in which if the AVPCC profile is to abide by TFRC's (RFC=20 > 3448) feedback=20 > requirements, then feedback traffic will exceed 5% of data traffic >=20 > For example: > a 512kbps flow with packet sizes of 50bytes and RTT=3D5ms, will=20 > generate at least 140kbps of RTCP feedback (according to the current=20 > version of the draft) - which is some what excessive and counter=20 > intuitive to congestion control. > The same data flow with RTTs of 10ms, 20ms and 100ms=20 > will generate=20 > 70kbps, 35kbps and 7kbps of feedback (at 14%, 6%, 1.3% of the data=20 > traffic). >=20 > Small RTTs (<10ms) and data rates of < 1Mbps generally translate to=20 > (depending on packet sizes) to few packets per RTT - one solution=20 > could be to modify feedback timing requirements, such that=20 > the ratio of=20 > feedback to data traffic is not prohibitive in instances=20 > where RTTs and=20 > number of packets per RTT are relatively small. >=20 > Imbedding control traffic in the RTP packet does not present=20 > a general=20 > solution, because as you point out, it would only work for two-way=20 > traffic and even in the case of two-way traffic it is generally=20 > complicated and not always possible given TFRCs timing=20 > requirements for=20 > feedback. >=20 > Ladan >=20 > On Oct 27, 2004, at 3:17 PM, Jim Kleck wrote: >=20 > > The draft-ietf-avt-tfrc-profile-03.txt is specifically=20 > restricted to=20 > > unicast, > > and specifies feedback possibly once per data packet. This=20 > can generate > > too much feedback traffic in the case of one-to-one video=20 > conferencing > > (which typically operates at 64K - 512K bps). However, this=20 > case offers > > a ready feedback path with much less overhead: the data pkts coming=20 > > from > > the far end. An additional extension to the RTP hdr could=20 > possibly add > > the feedback at a small cost. The challenges with this scheme are: > > > > - there is an implicit tie between the Tx and Rx RTP=20 > sessions, but in > > a one-to-one video conference that should not be too hard=20 > to formalize > > > > - if the app does not recv any data pkts from the farend=20 > for a while=20 > > then > > there will be no feedback, that could mean the far end has=20 > nothing to=20 > > send > > (in which case a noop RTP pkt with the feedback could be specified, > > see draft-wing-avt-rtp-noop-01.txt, with no worries about=20 > using extra > > bandwidth because the lack of data makes that bandwidth=20 > available... > > or use the suggested Receiver Report extensions), or it could mean=20 > > that > > there is some network problem > > > > > > Does this seem worth further investigation? > > > > Jim Kleck > > 8x8, Inc > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 29 11:59:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10971 for ; Fri, 29 Oct 2004 11:59:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZO0-00024q-9M for avt-archive@ietf.org; Fri, 29 Oct 2004 12:13:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZ0Z-0001WH-8J; Fri, 29 Oct 2004 11:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNYrF-0004ib-Cr for avt@megatron.ietf.org; Fri, 29 Oct 2004 11:40:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10013 for ; Fri, 29 Oct 2004 11:40:02 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZ5N-0001jV-66 for avt@ietf.org; Fri, 29 Oct 2004 11:54:52 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9TFdpfM000285 for ; Fri, 29 Oct 2004 17:39:52 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 17:39:51 +0200 Received: from [147.214.34.66] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.66]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSMD7XD; Fri, 29 Oct 2004 17:39:51 +0200 Message-ID: <41826447.9060206@ericsson.com> Date: Fri, 29 Oct 2004 17:39:51 +0200 X-Sybari-Trust: a527f9a8 bfd556f1 5130fd7a 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Subject: Re: [AVT] Updated AVT agenda for IETF 61 in Washington D.C. References: <4180FC15.80806@ericsson.com> In-Reply-To: <4180FC15.80806@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2004 15:39:51.0964 (UTC) FILETIME=[87ED55C0:01C4BDCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Hi, Here is a new version of the agenda. We would like to finalize the agenda on Monday, so please send any comments ASAP. Have a nice weekend reading drafts Magnus --------------------------------- Audio/Video Transport Working Group CHAIRS: Colin Perkins Magnus Westerlund Monday, 8 November 2004, 15:30-17:30 ==================================== Introduction and Status Update (Chairs) draft-ietf-avt-rtp-midi-format-06.txt 20 min draft-ietf-avt-rtp-midi-guidelines-06.txt draft-ietf-avt-rfc2032-bis-03.txt draft-ietf-avt-rfc2429-bis-03.txt draft-basso-avt-videoconreq-02.txt draft-ietf-avt-audio-t140c-00.txt draft-ietf-avt-rfc2793bis-09.txt RTCP XR MIB (Clark & Pendleton) draft-ietf-avt-rtcp-xr-mib-00.txt 15 min Open issues in RFC 2833bis (Taylor) draft-ietf-avt-rfc2833bis-05.txt 15 min Far End Camera Control protocol (Even) draft-even-avt-h224-00.txt 15 min Thursday, 11 November 2004, 13:00-15:00 ====================================== Introduction (Chairs) 5 min RTP Profile for TCP Friendly Rate Control (Gharai) draft-ietf-avt-tfrc-profile-03.txt 25 min RTP Timestamp Usage for Variable Sample Rate Audio Codecs (Chairs) draft-ietf-avt-variable-rate-audio-00.txt (Wenger) Discussion on mailing list 30 min RTP Payload and File Format for VMR-WB (Ahmadi) draft-ietf-avt-vmr-wb-file-format-00.txt 15 min draft-ietf-avt-rtp-vmr-wb-05.txt RTP Payload Format for AMR and AMR-WB (Westerlund) draft-ietf-avt-rtp-amr-bis-00.txt 15 min RTP Payload Format for JPEG 2000 (Leung) draft-ietf-avt-jpeg2000-06.txt 15 min - * - -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 29 12:52:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14899 for ; Fri, 29 Oct 2004 12:52:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaDD-0003GA-U4 for avt-archive@ietf.org; Fri, 29 Oct 2004 13:06:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZjN-0004su-OB; Fri, 29 Oct 2004 12:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZg3-00015h-VK for avt@megatron.ietf.org; Fri, 29 Oct 2004 12:32:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13245 for ; Fri, 29 Oct 2004 12:32:33 -0400 (EDT) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZuM-0002k8-4a for avt@ietf.org; Fri, 29 Oct 2004 12:47:23 -0400 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i9TGW2iN005989; Fri, 29 Oct 2004 18:32:02 +0200 Received: from ox.inria.fr (ox.inria.fr [138.96.88.70]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i9TGVvRn005916; Fri, 29 Oct 2004 18:31:57 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ox.inria.fr (8.12.10/8.12.5) with ESMTP id i9TFDbf5032694; Fri, 29 Oct 2004 17:13:38 +0200 Message-ID: <41825E21.5070005@sophia.inria.fr> Date: Fri, 29 Oct 2004 17:13:37 +0200 From: Abdelbasset Trad User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040914 X-Accept-Language: fr-FR,en MIME-Version: 1.0 To: "Phelan, Tom" Subject: Re: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback in RTP? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (sophia.inria.fr [138.96.64.20]); Fri, 29 Oct 2004 18:31:58 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Hi, I am interested by this topic, I have proposed a scheme: TFRC for RTP audio packets with variable size (using RTP packet multiplexing at an IP-telephony GW). Here is my paper: http://www-sop.inria.fr/planete/atrad/paper-icn04-trad.pdf Cheers, Abdelbasset Trad Phelan, Tom wrote: >Hi, > >For those of you AVT'ers interested in TFRC and its possible uses for streaming media, I released a paper earlier this month on a simulation study of TFRC with self-limiting sources such as streaming voice. The paper is available at http://www.phelan-4.com/dccp/tfrc-self-limit.pdf. Overall, the paper presents a rather bleak picture of the suitability of TFRC for voice applications. > >There is an active discussion of this paper and its implications on the DCCP mailing list. At the current time, Sally Floyd is proposing some possible modifications to the TFRC algorithm, to help it work better with voice media streams. This appears promising, but the discussion of these mods is at an early stage. > >Anyone with an interest is welcomed to join the discussion, of course. > >Tom Phelan > > > >>-----Original Message----- >>From: Ladan Gharai [mailto:ladan@isi.edu] >>Sent: Thursday, October 28, 2004 11:05 AM >>To: Jim Kleck >>Cc: IETF AVT WG >>Subject: Re: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback >>in RTP? >> >> >>Jim: >> >>Thank you for your feedback - you raise a good point and actually the >>ratio between data and feedback traffic is currently an open issue on >>the draft, discussed in Section 9. >> >>RFC 3350 recommends that feedback traffic not exceed %5 of the data >>traffic. >>However, there are combinations of data rates, RTTs and packet sizes >>in which if the AVPCC profile is to abide by TFRC's (RFC >>3448) feedback >>requirements, then feedback traffic will exceed 5% of data traffic >> >>For example: >> a 512kbps flow with packet sizes of 50bytes and RTT=5ms, will >>generate at least 140kbps of RTCP feedback (according to the current >>version of the draft) - which is some what excessive and counter >>intuitive to congestion control. >> The same data flow with RTTs of 10ms, 20ms and 100ms >>will generate >>70kbps, 35kbps and 7kbps of feedback (at 14%, 6%, 1.3% of the data >>traffic). >> >>Small RTTs (<10ms) and data rates of < 1Mbps generally translate to >>(depending on packet sizes) to few packets per RTT - one solution >>could be to modify feedback timing requirements, such that >>the ratio of >>feedback to data traffic is not prohibitive in instances >>where RTTs and >>number of packets per RTT are relatively small. >> >>Imbedding control traffic in the RTP packet does not present >>a general >>solution, because as you point out, it would only work for two-way >>traffic and even in the case of two-way traffic it is generally >>complicated and not always possible given TFRCs timing >>requirements for >>feedback. >> >>Ladan >> >>On Oct 27, 2004, at 3:17 PM, Jim Kleck wrote: >> >> >> >>>The draft-ietf-avt-tfrc-profile-03.txt is specifically >>> >>> >>restricted to >> >> >>>unicast, >>>and specifies feedback possibly once per data packet. This >>> >>> >>can generate >> >> >>>too much feedback traffic in the case of one-to-one video >>> >>> >>conferencing >> >> >>>(which typically operates at 64K - 512K bps). However, this >>> >>> >>case offers >> >> >>>a ready feedback path with much less overhead: the data pkts coming >>>from >>>the far end. An additional extension to the RTP hdr could >>> >>> >>possibly add >> >> >>>the feedback at a small cost. The challenges with this scheme are: >>> >>>- there is an implicit tie between the Tx and Rx RTP >>> >>> >>sessions, but in >> >> >>> a one-to-one video conference that should not be too hard >>> >>> >>to formalize >> >> >>>- if the app does not recv any data pkts from the farend >>> >>> >>for a while >> >> >>>then >>> there will be no feedback, that could mean the far end has >>> >>> >>nothing to >> >> >>>send >>> (in which case a noop RTP pkt with the feedback could be specified, >>> see draft-wing-avt-rtp-noop-01.txt, with no worries about >>> >>> >>using extra >> >> >>> bandwidth because the lack of data makes that bandwidth >>> >>> >>available... >> >> >>> or use the suggested Receiver Report extensions), or it could mean >>>that >>> there is some network problem >>> >>> >>>Does this seem worth further investigation? >>> >>>Jim Kleck >>>8x8, Inc >>> >>> >>>_____ >>> -- ------------------------------------------ Abdelbasset TRAD INRIA Planete Project 2004 Route des Lucioles, BP-93 06902 Sophia-Antipolis Cedex, France Phone: (+33) 4 92 38 50 22 Fax: (+33) 4 92 38 79 78 Email: atrad@sophia.inria.fr http://www-sop.inria.fr/planete/atrad ------------------------------------------ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 29 15:57:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00862 for ; Fri, 29 Oct 2004 15:57:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNd6G-0007VS-S5 for avt-archive@ietf.org; Fri, 29 Oct 2004 16:11:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNclF-0004ro-GT; Fri, 29 Oct 2004 15:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcMG-0000Vy-QN; Fri, 29 Oct 2004 15:24:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27793; Fri, 29 Oct 2004 15:24:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcab-0006cj-E6; Fri, 29 Oct 2004 15:39:09 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CNcKv-0006U2-EL; Fri, 29 Oct 2004 15:22:57 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 29 Oct 2004 15:22:57 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: avt chair , avt chair , Internet Architecture Board , avt mailing list , RFC Editor Subject: [AVT] Protocol Action: 'RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding' to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 The IESG has approved the following document: - 'RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding ' as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary Distributed speech recognition (DSR) technology in this architecture uses remote device acting as a thin client, also known as the front-end, to communicate with a speech recognition server, also called a speech engine, over a network connection, to obtain speech recognition services. More details on DSR over Internet can be found in RFC 3557 To achieve interoperability with different client devices and speech engines, the first ETSI standard DSR front-end ES 201 108 was published in early 2000 and an RTP packetization for ES 201 108 frames is defined in RFC 3557 by IETF. In ES 202 050, ETSI issues another standard for an Advanced DSR front-end that provides substantially improved recognition performance when background noise is present. The codecs in ES 202 050 use a slightly different frame format from those of ES 201 108 and thus the two do not inter-operate with each other. The RTP packetization for ES 202 050 front-end defined in this document uses the same RTP packet format layout as that defined in RFC 3557. The differences are in the DSR codec frame bit definition and the payload type MIME registration. The two further standards, ES 202 211 and ES 202 212, for which this document offers payloads, provide extensions to the each of the DSR front-end standards. These respective extensions allow the speech waveform to be reconstructed for human audition and they can also be used to improve recognition performance for tonal languages. This is done by sending additional pitch and voicing information for each frame along with the recognition features. Working Group Summary The document was sent to the ietf-types list for MIME type review and did not surface any concerns. The DSR issues were reviewed by the SPEECHSC WG at the time of RFC 3557, and the Area Director viewed this document as having no new issues. The working group supported advancing this document. Protocol Quality This document was reviewed for the IESG by Magnus Westerlund and Allison Mankin. RFC Editor Notes Section 4 OLD: Author/Change controller: * Qiaobing.Xie@motorola.com * IETF Audio/Video transport working group NEW: Author: * Qiaobing.Xie@motorola.com Change controller: * IETF Audio/Video transport working group delegated by the IESG Section 5 The following paragraph should be moved out of Section 5, and become Section 4.3 Congestion Control: Congestion control for RTP MUST be used in accordance with RFC 3550 [9], and any applicable RTP profile, e.g. RFC 3551 [10]. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Fri Oct 29 16:46:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09684 for ; Fri, 29 Oct 2004 16:46:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdsU-0001ZB-5Y for avt-archive@ietf.org; Fri, 29 Oct 2004 17:01:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcm2-0005Z6-89; Fri, 29 Oct 2004 15:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNccN-000450-H7 for avt@megatron.ietf.org; Fri, 29 Oct 2004 15:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29252 for ; Fri, 29 Oct 2004 15:40:57 -0400 (EDT) Received: from fep10.012.net.il ([212.117.129.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcqh-0006wf-RO for avt@ietf.org; Fri, 29 Oct 2004 15:55:48 -0400 Received: from isrexch01.israel.polycom.com ([212.199.61.2]) by fep10.012.net.il with ESMTP id <20041029194003.ZTQA1249.fep10@isrexch01.israel.polycom.com>; Fri, 29 Oct 2004 21:40:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Updated AVT agenda for IETF 61 in Washington D.C. Date: Fri, 29 Oct 2004 21:40:01 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C2B643F@IsrExch01.israel.polycom.com> Thread-Topic: [AVT] Updated AVT agenda for IETF 61 in Washington D.C. Thread-Index: AcS90FR5/QVpv68tTZCaSdSPLuWPIAAHpUXg From: "Even, Roni" To: "Magnus Westerlund" , "IETF AVT WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Magnus, In the status please add draft-ietf-avt-rfc2190-to-historic-00.txt so we can progress it Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Friday, October 29, 2004 5:40 PM To: IETF AVT WG Subject: Re: [AVT] Updated AVT agenda for IETF 61 in Washington D.C. Hi, Here is a new version of the agenda. We would like to finalize the agenda on Monday, so please send any comments ASAP. Have a nice weekend reading drafts Magnus --------------------------------- Audio/Video Transport Working Group CHAIRS: Colin Perkins Magnus Westerlund Monday, 8 November 2004, 15:30-17:30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Introduction and Status Update (Chairs) draft-ietf-avt-rtp-midi-format-06.txt 20 min draft-ietf-avt-rtp-midi-guidelines-06.txt draft-ietf-avt-rfc2032-bis-03.txt draft-ietf-avt-rfc2429-bis-03.txt draft-basso-avt-videoconreq-02.txt draft-ietf-avt-audio-t140c-00.txt draft-ietf-avt-rfc2793bis-09.txt RTCP XR MIB (Clark & Pendleton) draft-ietf-avt-rtcp-xr-mib-00.txt 15 min Open issues in RFC 2833bis (Taylor) draft-ietf-avt-rfc2833bis-05.txt 15 min Far End Camera Control protocol (Even) draft-even-avt-h224-00.txt 15 min Thursday, 11 November 2004, 13:00-15:00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Introduction (Chairs) 5 min RTP Profile for TCP Friendly Rate Control (Gharai) draft-ietf-avt-tfrc-profile-03.txt 25 min RTP Timestamp Usage for Variable Sample Rate Audio Codecs (Chairs) draft-ietf-avt-variable-rate-audio-00.txt (Wenger) Discussion on mailing list 30 min RTP Payload and File Format for VMR-WB (Ahmadi) draft-ietf-avt-vmr-wb-file-format-00.txt 15 min draft-ietf-avt-rtp-vmr-wb-05.txt RTP Payload Format for AMR and AMR-WB (Westerlund) draft-ietf-avt-rtp-amr-bis-00.txt 15 min RTP Payload Format for JPEG 2000 (Leung) draft-ietf-avt-jpeg2000-06.txt 15 min - * - --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-bounces@ietf.org Sat Oct 30 14:20:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08856 for ; Sat, 30 Oct 2004 14:20:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNy4x-00072r-PP for avt-archive@ietf.org; Sat, 30 Oct 2004 14:35:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNxhQ-0005jI-5z; Sat, 30 Oct 2004 14:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNxZG-0002yI-SS; Sat, 30 Oct 2004 14:03:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07977; Sat, 30 Oct 2004 14:03:09 -0400 (EDT) Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNxnn-0006jx-KT; Sat, 30 Oct 2004 14:18:12 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1184183df71; Sun, 31 Oct 2004 02:04:42 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd417ec523; Wed, 27 Oct 2004 04:17:53 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm0417eb1dd; Wed, 27 Oct 2004 04:17:53 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 27 Oct 2004 04:17:53 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXZF-0000SU-Lw; Tue, 26 Oct 2004 16:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXNq-0003Ef-2I; Tue, 26 Oct 2004 15:53:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08495; Tue, 26 Oct 2004 15:53:27 -0400 (EDT) Message-Id: <200410261953.PAA08495@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 15:53:27 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn X-Spam-Score: 0.4 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-uxp-07.txt X-BeenThere: avt@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: avt-bounces@ietf.org Errors-To: avt-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams Author(s) : G. Liebl, et al. Filename : draft-ietf-avt-uxp-07.txt Pages : 29 Date : 2004-10-26 This document specifies an efficient way to ensure erasure- resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon (RS) codes together with interleaving. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Furthermore, protection of non-progressive multimedia streams is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By applying interleaving and RS codes a payload format is defined, which can be easily integrated into the existing framework for RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-uxp-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-uxp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-uxp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26160414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-uxp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-uxp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160414.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --NextPart--