From exim@www1.ietf.org Sat Nov 1 05:06:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02811 for ; Sat, 1 Nov 2003 05:06:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFsdj-0006D9-0Q for avt-archive@odin.ietf.org; Sat, 01 Nov 2003 05:05:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1A5oUQ023874 for avt-archive@odin.ietf.org; Sat, 1 Nov 2003 05:05:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFscv-00065Y-SA; Sat, 01 Nov 2003 05:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbbo-0006QF-0f for avt@optimus.ietf.org; Fri, 31 Oct 2003 10:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04700 for ; Fri, 31 Oct 2003 10:54:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbbl-0002BG-00 for avt@ietf.org; Fri, 31 Oct 2003 10:54:41 -0500 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 1AFbbk-0002Al-00 for avt@ietf.org; Fri, 31 Oct 2003 10:54:41 -0500 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-1) for id 1AFbbG-0007Gn-Kq; Fri, 31 Oct 2003 16:54:10 +0100 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Fri, 31 Oct 2003 16:54:10 +0100 (CET) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-1) for id 1AFbbG-0007GD-Js; Fri, 31 Oct 2003 16:54:10 +0100 Received: from almathea (mail@almathea.tkn.TU-Berlin.DE [130.149.49.56]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h9VFs9n13113 for ; Fri, 31 Oct 2003 16:54:09 +0100 Received: from karl by almathea with local (Exim 3.35 #1 (Debian)) id 1AFbbF-0006aF-00 for ; Fri, 31 Oct 2003 16:54:09 +0100 To: avt@ietf.org Message-Id: From: Holger Karl Date: Fri, 31 Oct 2003 16:54:09 +0100 X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Fri, 31 Oct 2003 16:54:10 +0100 Subject: [AVT] Call for Papers: WiOpt'04 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Apologies if you receive multiple copies of this call! Please note the deadline extension! ---------------------------------------------------------------------- DEADLINE EXTENSION The submission deadline has been extended to the 12th of November, 2003. *************************************************** ******** 2nd CALL FOR PAPERS ******** *************************************************** * * * WiOpt '04 * * * * 2nd Workshop on Modeling and Optimization * * in Mobile, Ad Hoc and Wireless Networks * * * * March 24 - 26, 2004, Cambridge, UK * * * * * *************************************************** Workshop Website: http://www.cl.cam.ac.uk/Research/SRG/wiopt04/ This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocol design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad hoc networks. Papers to be presented at WiOpt'04 will be selected based on extended abstracts of up to 8 pages, double-spaced, 12 point font size. The submission should not exceed 3000 words including tables and figures, each of which count as 250 words. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of the MONET journal. Plenary Speakers: Bruce Hajek (University of Illinois at Urbana-Champaign, USA) Ian Akyildiz (Georgia Institute of Technology, USA) IMPORTANT DATES: Submission of extended abstract: Nov. 12, 2003 (EXTENDED!). Notification of acceptance: Jan. 15, 2004. Camera ready copy: Feb. 15, 2004. (Further details on the workshop website, http://www.cl.cam.ac.uk/Research/SRG/wiopt04/) General chairman: Imrich Chlamtac Vice General Chair: Roger Whitaker Program Co-Chairs: Marco Conti and Tamer Basar Program committee of the conference: Eitan Altman, Venkat Anantharam, Konstantin Avrachenkov, Andrew Campbell, X. Cao, A. Chockalingam, Jon Crowcroft, Anthony Ephremides, Silvia Giordano, Stephen V. Hanly, Jean-Pierre Hubaux, Holger Karl, Peter Key, P. R. Kumar, Peter Marbach, Derek Mcauley, Archan Misra, Philippe Nain, Sven Oestring, Yoshikuni Onozato, Ariel Orda, Ramesh Rao, Catherine Rosenberg, Ness Shroff, Violet Syrotiuk, Thierry Turletti, Adam Wolisz, Jeff Wieselthier, Moshe Zukerman Local Arrangements Co-Chair: Sven Oestring, Julian Chesterfield and Rajiv Chakravorty Treasurer: Meng How Lim Publicity Chair: Holger Karl The workshop is co-sponsored by * Univ. of Cambridge * IIT (Istituto di Informatica e Telematica) * IEEE IT Society (technical co-sponsorship) (ACM sponsorship is pending.) Additional financial support is provided by: * Intel * Microsoft Research _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Nov 1 12:42:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11322 for ; Sat, 1 Nov 2003 12:42:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFzl5-0006ZT-6s for avt-archive@odin.ietf.org; Sat, 01 Nov 2003 12:41:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1HftaP025260 for avt-archive@odin.ietf.org; Sat, 1 Nov 2003 12:41:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFzkC-0006VX-Q7; Sat, 01 Nov 2003 12:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFzjg-0006VH-O6 for avt@optimus.ietf.org; Sat, 01 Nov 2003 12:40:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11288 for ; Sat, 1 Nov 2003 12:40:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFzjf-0003VN-00 for avt@ietf.org; Sat, 01 Nov 2003 12:40:27 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AFzje-0003VK-00 for avt@ietf.org; Sat, 01 Nov 2003 12:40:26 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA1HeKSs018934; Sat, 1 Nov 2003 18:40:20 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Sat, 1 Nov 2003 18:40:32 +0100 Message-ID: <034BEFD03799D411A59F00508BDF754602BF41CA@esealnt448.al.sw.ericsson.se> From: "Magnus Westerlund (KI/EAB)" To: "'hatanaka@av.crl.sony.co.jp '" , "'jun@av.crl.sony.co.jp '" , "'matthew.romaine@jp.sony.com '" , "'avt@ietf.org '" Date: Sat, 1 Nov 2003 18:32:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] Comments on draft-hatanaka-avt-rtp-atracx-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, Here is my comments on draft-hatanaka-avt-rtp-atracx-03.txt 1. There seem to be some problem with the page length, it varies widely between some pages. 2. I think the introduction chapter is lacking some information. Due to the massive amount of functionality in the payload format there is a need to motivate some of this. Also some more details around the codex is needed, especially that has impact on the transport. For example is the codec using fixed time length slots, and what is there length? 3. In general I think the payload format is suffering of an extreme case of feature creap. Every imaginable possible usage has been given functionality without thinking if RTP or other layers can help provide the functionality. I think more work concering what intended use cases to solve is needed. Thus enable propoer understanding of the requierments. This mail will actually mostly consist of questions regarding what is necessary. 4. Starting in section 1.2 and figure 1: What is the motivation behind the usage of segments and what are they purpose. As I understand they have multiple of usages and not all seems appropriate for RTP. To my understanding segements can be used to: - Carry individual mono or stereo encoding blocks, part of a multi block channel combination, for example 5.1. - Carry a complete encoding block, including 5.1 - Use multiple segments to carry multiple blocks of multi-channel content. - Carry multiple different sources in one payload? (This is definitly not appropriate) This latitude in the usage makes it hard to grepp how it should be best implemented and used. I think one should review the segment concept and if it really is appropriate and need, or if other solutions can be found. 5. Section, 2.1, figure 2: This figure is very confusing, when introducing a format it is normal useful to start on high level and few details, I would basically recommend a figure with: RTP header, payload header, data blocks, etc. 6. The bit-fields drawings are confusing as they are lacking a horisontal divider between different rows of octets. Thus one has a hard time knowing if somehting is spread over multiple lines but consist of only one single octet row. 7. Section 2.3, the version field: Is this the version of the payload format? If it is, its not appropriate. Having the version in the payload format prevents the signaling protocol to know what versions are supported, etc. Thus it is better to have the version handling on the signalling layer, for example thru the usage of different MIME types for different versions that are not compatible. 8. Section 2.3: What is the purpose of the FRSEQNO? I don't see the meaning of this, I assume that one can use RTP TS to recover the slot the data belongs to. 9. Section 2.3: The elementID: I am not certain of the purpose of this identifier. Are they used to identify different segments? IF the purposes is to identify different sources the RTP SSRC exist for this purpose. 10. Section 2.3: The segments are they each having an individual complet RTP payload header as described in figure 3? 11. Figure 4: In this example, are there really need to be able to send 12+2 channels in the same RTP payload? How is the mapping between the different multi-channel accomplished? Each of the individual combinations, like 5.1 has a unique mapping and an assumed speaker setup but what does it mean when one have both 5.1 and 7.1 in a slot? 12. Section 2.3 The combination of the two frame blocks, how is this accomplished? Like when the LFE is combined with another stereo block? 13. Section 4. The meta data: If there isn't already defined a number of given metadata block types why is the metadata ID need. In the interest of interoperability isn't it best that meta data actually is understood and therefore defined. Thus each type could be assigned an ID. 14. What TS rate are you going to support, I woul assume, any of the three sampling rates, as long as you do not envision that one will switch frequently between them. In my opinion you need to go back to the drawing board and rethink the design. This design seems to be much to complex for the purpose. However as you haven't clearly communicated the purpose I am not certain. I think there exist simple solutions. If I would do this I would structure the payload format this way. Remove the segment concept totally. If one needs to send several multichannel encodings in the same session I would use the SSRC instead. Create a payload format that allows for aggregation of several slots in a nice way, thus enable the redundancy scheme. The payload would then look like: [RTP header] [Payload header] [Slot header: TS offset, nr of blocks(n)] n*[Block: block type, block len, data] [Slot header: TS offset, nr of blocks(m)] m*[Block: block type, block len, data] The payload would consist of a nested strucuture. First a packet common payload header, carrying any common information (not having analyzed what needs to go here). For each time slot there is a header giving the number of blocks the slot consist of and what the RTP TS offset is in regards to the RTP TS. Within each time slot there can be a number of blocks. Each block carries a type identifier, audio, metadata, etc, and a length field, then is the data of the block. The slot headers block count is used to know when there should be a new slot header if there still are more unparsed bytes of the packet. The redunancy mechanism does not use any explicit type of data structure unless the codec requries it. IF redundancy is used the receiver may receive multiple sets of blocks for the same slot. The receiver simply selects the most appropriat, usually the one with most channels. If priority is important to carry, that can be added to the appropriate header, probably block header. As I see it the priority in the payload is only useful if one foresees that one will have gateways or repacking entities when sending from IP to another net with possibly redudeced capabilities. In the IP to IP case the sender needs to perform all bit-rate adaptation prior to packetization. Editorial comments: - Read the ID nits and follow them. http://www.ietf.org/ID-nits.html - Rethink the structure of the draft, introducation, definitions, general functionality, then details to make it more readible. I am very willing to discuss this in Minneapolis. Cheers Magnus _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Nov 2 04:01:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10895 for ; Sun, 2 Nov 2003 04:01:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGE6V-0000C8-MZ for avt-archive@odin.ietf.org; Sun, 02 Nov 2003 04:01:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA290xsq000702 for avt-archive@odin.ietf.org; Sun, 2 Nov 2003 04:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGE5b-00009g-Ak; Sun, 02 Nov 2003 04:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGE4a-00008L-Ud for avt@optimus.ietf.org; Sun, 02 Nov 2003 03:59:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10849 for ; Sun, 2 Nov 2003 03:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGE4Y-0003us-00 for avt@ietf.org; Sun, 02 Nov 2003 03:58:58 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1AGE4X-0003uf-00 for avt@ietf.org; Sun, 02 Nov 2003 03:58:57 -0500 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Sun, 2 Nov 2003 10:55:19 +0200 Message-ID: From: "Even, Roni" To: "'avt@ietf.org '" Date: Sun, 2 Nov 2003 10:55:18 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Subject: [AVT] SDP parameters for supporting H.263 and H.261 options Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, This is a short summary of the presentation we intend to have in Minneapolis There were two drafts submitted addressing the same topic which is adding optional SDP parameters to H.261 and H.263 for specifying codec parameters. draft-even-avt-h263-h261-options-00.txt - uses fmtp draft-nismail-mmusic-sdp-video-00.txt - uses gpmd Issues to be discussed during the IETF meeting: 1. Can we adopt this work as an AVT working group item 2. GPMD is not an RFC and might not be adopted hence authors prefer to use fmtp. We would like to discuss the process for doing that. 3. We are soliciting input on the defined parameters, did we specify all. Thanks Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Nov 2 08:51:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15821 for ; Sun, 2 Nov 2003 08:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGId8-0005GW-7A for avt-archive@odin.ietf.org; Sun, 02 Nov 2003 08:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2Dovs7019868 for avt-archive@odin.ietf.org; Sun, 2 Nov 2003 08:50:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGIcE-000571-Fl; Sun, 02 Nov 2003 08:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGIbj-00056a-G1 for avt@optimus.ietf.org; Sun, 02 Nov 2003 08:49:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15804 for ; Sun, 2 Nov 2003 08:49:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGIbi-0006ap-00 for avt@ietf.org; Sun, 02 Nov 2003 08:49:30 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AGIbh-0006ab-00 for avt@ietf.org; Sun, 02 Nov 2003 08:49:29 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62219 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AGIbA-0003Qh-00; Sun, 02 Nov 2003 13:48:56 +0000 Date: Sun, 2 Nov 2003 13:48:50 +0000 Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: avt@ietf.org To: Linus Walleij From: Colin Perkins In-Reply-To: Message-Id: <4A2FE588-0D3B-11D8-B1B9-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, Oct 14, 2003, at 22:15 Europe/London, Linus Walleij wrote: > One minor: > > This document also serves as the MIME type registration according > RFC > ^ > to > Apart from that it's ready to roll, IMHO. I caught a few minor things: - Section 2 is missing the citation [2] - Section 3: "A sample rate of 8000 Hz is used" -> "MUST be used"? - Section 3 needs to indicate that other RTP header fields are used as specified in RFC 3550 and any applicable profile. - Section 6: This is a payload format, not a profile. Need to reword the first paragraph appropriately. - Section 6: Would be appropriate to mention that RTP is not an appropriate transfer protocol for reliable octet streams, and that TCP is better in those cases. Should probably also mention the importance of congestion control, and reference the discussion in RFC 3551. - Reference [10] should include the draft filename, so the RFC Editor can track the dependency Other than these details, I think it's ready to go. If other members of the group have comments, they should be sent to the mailing list by the 14th of November (the last day of the IETF meeting), so a revised draft can be submitted immediately the archives re-open. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Nov 2 13:33:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21764 for ; Sun, 2 Nov 2003 13:33:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGN1p-00083S-UY for avt-archive@odin.ietf.org; Sun, 02 Nov 2003 13:32:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2IWjDM030918 for avt-archive@odin.ietf.org; Sun, 2 Nov 2003 13:32:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGN18-0007w1-4N; Sun, 02 Nov 2003 13:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGN0R-0007sT-19 for avt@optimus.ietf.org; Sun, 02 Nov 2003 13:31:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21731 for ; Sun, 2 Nov 2003 13:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGN0O-0001Ox-00 for avt@ietf.org; Sun, 02 Nov 2003 13:31:16 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AGN0O-0001Ot-00 for avt@ietf.org; Sun, 02 Nov 2003 13:31:16 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63205 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AGMzt-00042D-00; Sun, 02 Nov 2003 18:30:45 +0000 Date: Sun, 2 Nov 2003 18:30:40 +0000 Subject: Re: [AVT] TCP framing update Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: avt@ietf.org To: John Lazzaro From: Colin Perkins In-Reply-To: <200310210332.h9L3WHBM026162@ribbit.CS.Berkeley.EDU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, Oct 21, 2003, at 04:32 Europe/London, John Lazzaro wrote: > Just submitted an updated version of the TCP framing > I-D (draft-lazzaro-avt-rtp-framing-contrans-02.txt) to > internet-drafts@ietf.org, you can pick it up at: > > http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-contrans.txt > > Only the name and date have been updated -- the memo had been > awaiting re-chartering, and was about to expire. The re-chartering > text of interest is: > >> - to provide a framing mechanism for RTP over TCP and TLS > > The draft-lazzaro-avt-rtp-framing-contrans-02.txt draft is > driven from two requirements, which were culled from earlier > discussions on avt@ietf.org, and from the discussion in San > Francisco in the spring: > > -1- Compatibility with the TCP framing format in earlier > versions of the RTP RFCs. > > -2- Compatibility with draft-ietf-mmusic-sdp-comedia-05.txt > > It would be good to get feedback on whether the document falls > short on either requirement. > > My take on the San Francisco discussions is that there is a > need for a protocol that meets these requirements, to support existing > codebases. Based on that assessment, I'd like to request WG Item > status for draft-lazzaro-avt-rtp-framing-contrans-02.txt. If anyone objects to this being an AVT work item - to address the charter text mentioned above - please comment to the mailing list by 14th November 2003. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 3 01:26:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08588 for ; Mon, 3 Nov 2003 01:26:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGY9p-0007gs-7X for avt-archive@odin.ietf.org; Mon, 03 Nov 2003 01:25:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA36PjF8029558 for avt-archive@odin.ietf.org; Mon, 3 Nov 2003 01:25:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGY98-0007bt-Vg; Mon, 03 Nov 2003 01:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGY8A-0007aa-Ua for avt@optimus.ietf.org; Mon, 03 Nov 2003 01:24:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08545 for ; Mon, 3 Nov 2003 01:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGY87-0000gr-00 for avt@ietf.org; Mon, 03 Nov 2003 01:23:59 -0500 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 1AGY87-0000fm-00 for avt@ietf.org; Mon, 03 Nov 2003 01:23:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Moving draft-jones-avt-audio-t38-01.txt forward Date: Mon, 3 Nov 2003 08:23:56 +0200 Message-ID: Thread-Topic: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Thread-Index: AcOf8kACfObUzXUAR5ScS2Ab8ksqaABNdcKwACc14qA= From: "Vladimir Ulybin" To: Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, Together with advantages (encryption for security needs, the same port/address for RTP+audio and RTP+t38) the proposed encapsulation of T.38 into RTP has some disadvantages. 1. The protection from and recovery of packet lost in T.38 is usually stronger than that of RTP. So, using the RTP error correction for T.38 seems to be problematic. 2. The bi-directional switching between Voice-Band-Data and T.38 modes remains problematic as in current implementations because the RTP payload of VBD has no ID of fax session. The more attractive approach is given in delayed contribution 303 of CISCO (May 2003, ITU-T, Study Group 16) to support RTP encapsulated into T.38. That idea is inversed to the discussed one, and has more capabilities for implementation of reliable fax transfer. Regards, Vladimir Ulybin AudioCodes, Ltd. =20 -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Friday, October 31, 2003 11:01 PM To: avt@ietf.org Subject: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Folks, I would like to seek agreement from the AVT group to move the document audio/t38 document forward. As I have mentioned previously, the ITU would like to incorporate this in T.38 in an amendment to be approved in January 2004. The motivation for transporting T.38 via RTP is probably obvious to most. In fact, I recall several saying that that is the way it should have been done from the outset. Most certainly, this will prove to be a good step in leveraging SRTP for fax to address security needs. The document is relatively short, just seeking the MIME registration. The technical details will be specified in the ITU-T Recommendation T.38. Can I get agreement to make this an official working group item? Can we try to get this approved by the January 2004 ITU-T SG16 meeting? Thanks, Paul _______________________________________________ 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 exim@www1.ietf.org Mon Nov 3 03:36:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23737 for ; Mon, 3 Nov 2003 03:36:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGaBd-0006KP-1M for avt-archive@odin.ietf.org; Mon, 03 Nov 2003 03:35:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA38ZjlD024326 for avt-archive@odin.ietf.org; Mon, 3 Nov 2003 03:35:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGaAv-0006Do-9y; Mon, 03 Nov 2003 03:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGaAL-0006Cw-U6 for avt@optimus.ietf.org; Mon, 03 Nov 2003 03:34:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23714 for ; Mon, 3 Nov 2003 03:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGaAJ-0001zb-00 for avt@ietf.org; Mon, 03 Nov 2003 03:34:23 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AGaAI-0001zY-00 for avt@ietf.org; Mon, 03 Nov 2003 03:34:22 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA38YMI2025053; Mon, 3 Nov 2003 09:34:22 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6MH17XK; Mon, 3 Nov 2003 09:34:22 +0100 Message-ID: <3FA61308.3060603@ericsson.com> Date: Mon, 03 Nov 2003 09:34:16 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: IETF AVT WG References: <3F9E6B28.6090307@ericsson.com> <3FA29C84.8A6D7C@motorola.com> In-Reply-To: <3FA29C84.8A6D7C@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Comments on DSR drafts Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Qiaobing, See comments inline. Qiaobing Xie wrote: > Hi, Magnus, > > Thank you very much for the feedback. Please see my comments/answers > in-line. > > Magnus Westerlund wrote: > >>Hi Qiaobing, >> >>I have looked at your three dsr drafts: >> draft-ietf-avt-dsr-es202050-01.txt >> draft-xie-avt-xdsr-es202211-00.txt >> draft-xie-avt-xadsr-es202212-00.txt >> >>1. My first comment is that these three draft could easily be folded >>into a single draft. To my understanding they have a lot in common. The >>only real difference is the actual internal frame format and that 050 >>have shorter frames then 211 and 212. Then there is the need define >>individual MIME types for each. However this seems to be about all. >>Having a single draft will reduce the workload on IESG and RFC editor >>slightly. It will also make it less RFC to keep track of. > > > I talked with Steve C. about this a year ago. At that time, the > front-ends were at very different maturity levels in ETSI. So we agreed > to create separate draft for each front-end. Now things have progressed > and my understanding is that all three front-ends above are finalized in > ETSI. So, I think to combine them may be a good thing to do. > > We can either merge 050 and 212 into one draft (since they are more > logically related) and leave 211 stand-alone, or fold all three into one > draft. I will double-check with my ETSI colleagues about this and if > there is no other issues, will release merged version after this IETF > meeting. > I think they from an RTP transport perspective are all the same and therefore could be had in one specification. > >>3. I think the security consideration is a bit thin. Are you really >>certain that the format does not result in any special considerations? > > > Besides defining their specific frame bit-format, these payload > definitions do not add anything else to the standard RTP functions (they > may be one of the most straightforward RTP payloads). I really do not > see any special security issues introduced. I'd appreciate for any input > on this. > Okay, good. There is no DSR frame that can creates unusual high processing requirements on receiver side? Except for the merger there seem to be few problems with these formats. I would some more revisions to get the editorial nits right. I spotted some minor editorial things, I didn't comment on them due to that I saw the need to merge the document and that process will probably reveal them and create some other instead. 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 exim@www1.ietf.org Mon Nov 3 06:57:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28438 for ; Mon, 3 Nov 2003 06:57:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGdK7-00005w-N6 for avt-archive@odin.ietf.org; Mon, 03 Nov 2003 06:56:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Buh54000358 for avt-archive@odin.ietf.org; Mon, 3 Nov 2003 06:56:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGdJS-0008Tv-8G; Mon, 03 Nov 2003 06:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGdIl-0008T8-NK for avt@optimus.ietf.org; Mon, 03 Nov 2003 06:55:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28401 for ; Mon, 3 Nov 2003 06:55:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGdIh-0004Fm-00 for avt@ietf.org; Mon, 03 Nov 2003 06:55:15 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AGdIg-0004Fj-00 for avt@ietf.org; Mon, 03 Nov 2003 06:55:14 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA3BtESs029181; Mon, 3 Nov 2003 12:55:15 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6NMGT84; Mon, 3 Nov 2003 12:55:14 +0100 Message-ID: <3FA6421D.9030304@ericsson.com> Date: Mon, 03 Nov 2003 12:55:09 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gamze Seckin CC: Alan Tseng , IETF AVT WG References: <787ED0EC136B854DB341E7662D666CD6540E86@bels002.mediator.com> In-Reply-To: <787ED0EC136B854DB341E7662D666CD6540E86@bels002.mediator.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Comments on draft-tseng-rtcp-streaming-extns-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Gamze, Comments inline: Gamze Seckin wrote: > > 2. Regarding the corruption statistics. For media that uses codec that > have prediction any error normally remains for a rather long time. > However it is very difficult to determine when the effects has been > removed. Therefore this measurement is hard to derive on the receiver > side. Combined with the definition it only provides a good, possibly bad > indication. Also looking at the reasons for corruption, the only real > reason is lost or late packets. A good feeling for the quality can be > determined by the server simply by employing packet loss vector > reporting and knowing when the buffer is empty. > > [g]packet loss is definitely a way of estimating corruption, but this > gives an algorithm in the decoder (or pre-decoder)a chance to provide > better statistics. Yes, it might be possible for such an algorithm to do this. However the measurement will not provide that much information. I think you basically can only say this is good enough or not, there will not exist any possibility to say how bad things actually are. Otherwise you will need to clearly specify how this measurement algorithm shall work. However one concern here is that the corruption measurement will be quite complex and require rather much memory to perform properly. In a video decoder it will require the measurement tool to track how the error propagates over the screen. For some audio codecs it will be impossible to determine when the error is totally removed from the loop. To do this you would need to have information about what the correct state is. > > 3. The rebuffering measurements makes more sense. However there are at > least one client that does not really perform rebuffering, namely > quicktime. Instead is assumes that if the transmitted bit-rate is > acceptable any short term effects will go away and the client will later > have a buffer fullness given by the initial buffering delay. The > interesting thing about this measurement is that in 3GPP they already > have a way of letting the server measure when rebuffering takes place, > namely the OBSN reporting specified in TS 26.234 REL 6 (only preliminary > versions available). > > [g] yes, and I believe those statistics are useful, however they are > tight with rate adaptation (only turned on when rate-adaptation > is enabled) and tightly coupled with other rtsp messages. Yes, they however is another way of measuring this. I think the rebuffering measure is possibly more useful then the corruption measurement. > 6. Section 1. Last sentence: "As all the other report blocks > defined in [1], the streaming report blocks are applicable to > one-to-one or one-to-many applications that generate > RTCP SR or RR reports." This sentence is not really correct. The use of > the RTCP XR reports is possible in any application sending RTCP. > > [g] himm,i am confused i thought that the first sentence covers everything - what is left out? > So [1] needs to be updated too? What I object against is the distinction around RTCP SR or RR reports and the use of generate. I would rather formulate it as: As all the other report blocks defined in [1], the streaming report blocks are applicable to one-to-one or one-to-many applications that send RTCP in the desired direction. > 8. Section 2, Figure 1. This figure shows this report formats potential > need to have reporting from all layers on the receiving side. This might > be a problem for certain application architectures. I am not saying that > it can't be used, its only that some applications may have difficulties > to include your reports. > > [g] we believe the statistics reported should be extensible also should be allowed to be ignored. > So if an end side cannot support it should put simply a zero - what do you think? I think one need to consider the meaningfulness of allowing only some of the measurement to be given. > 10. Section 3.3, PAge 5, first bullet after figure 2: > "- at the AVP module: Packet drop and packet errors can sometimes be > detected by incorrect or missing sequence number or checksum. " Do you > really need to consider bit-errors, the only allowed possibility for > bit-errors in RTP is if partial checksums are used. Bit-errors surviving > to the transport layer is the meaning to be caught by the UDP, etc., > checksum. > > [g] there could be cases where bit errors are propagated (e.g. udp lite). I think that one should be clearer about that this then. However the usage of UDP-Lite is still under a lot of discussion within the IETF. There are some very though problems for IP to accept bit-errors partially. If one are using another transport of RTP then it might be more common. I would still like you to be more clear that this might be the case if one uses such mechanisms as UDP-Lite and payload formats + codecs that accept 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 exim@www1.ietf.org Mon Nov 3 13:44:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14156 for ; Mon, 3 Nov 2003 13:44:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjgE-0006nf-1k for avt-archive@odin.ietf.org; Mon, 03 Nov 2003 13:43:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Ihw0i026094 for avt-archive@odin.ietf.org; Mon, 3 Nov 2003 13:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjfJ-0006cl-7N; Mon, 03 Nov 2003 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjef-0006cF-Vw for avt@optimus.ietf.org; Mon, 03 Nov 2003 13:42:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14080 for ; Mon, 3 Nov 2003 13:42:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGjed-0002Iq-00 for avt@ietf.org; Mon, 03 Nov 2003 13:42:19 -0500 Received: from ribbit.cs.berkeley.edu ([128.32.112.203]) by ietf-mx with esmtp (Exim 4.12) id 1AGjed-0002In-00 for avt@ietf.org; Mon, 03 Nov 2003 13:42:19 -0500 Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1]) by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id hA3IgITA001262 for ; Mon, 3 Nov 2003 10:42:18 -0800 (PST) Received: (from lazzaro@localhost) by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id hA3IgILf001261 for avt@ietf.org; Mon, 3 Nov 2003 10:42:18 -0800 (PST) Date: Mon, 3 Nov 2003 10:42:18 -0800 (PST) From: John Lazzaro Message-Id: <200311031842.hA3IgILf001261@ribbit.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Re: Comments on draft-tseng-rtcp-streaming-extns-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Magnus Westerlund writes: > > I think that one should be clearer about that this then. However the > usage of UDP-Lite is still under a lot of discussion within the IETF. > There are some very though problems for IP to accept bit-errors > partially. If one are using another transport of RTP then it might be > more common. I would still like you to be more clear that this might be > the case if one uses such mechanisms as UDP-Lite and payload formats + > codecs that accept it. It might be time for AVT to set a provisional policy with regards to what payload format authors should or should not be doing with respect to UDP-lite. If one is starting with a blank sheet of paper to design a payload format, the road one takes to fully leverage UDP-lite is a different road from the norm. In the RTP MIDI case, for example, I would need to add in a few checksums words in key places for the recovery journal system to work well in a world where delivered packets may have bit-errors in the payload. This seemed too complicated to add to a payload format so close to completion, so I decided not to go that route. But maybe a payload author starting design work today should make a different decision ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 3 20:59:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08418 for ; Mon, 3 Nov 2003 20:59:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqTU-00030n-0l for avt-archive@odin.ietf.org; Mon, 03 Nov 2003 20:59:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA41xFVS011531 for avt-archive@odin.ietf.org; Mon, 3 Nov 2003 20:59:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqTF-0002zK-2v; Mon, 03 Nov 2003 20:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqSg-0002yk-8v for avt@optimus.ietf.org; Mon, 03 Nov 2003 20:58:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08390 for ; Mon, 3 Nov 2003 20:58:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqSd-0002oI-00 for avt@ietf.org; Mon, 03 Nov 2003 20:58:23 -0500 Received: from porter.east.isi.edu ([65.114.168.19]) by ietf-mx with esmtp (Exim 4.12) id 1AGqSd-0002oF-00 for avt@ietf.org; Mon, 03 Nov 2003 20:58:23 -0500 Received: from isi.edu (java.east.isi.edu [65.114.168.149]) by porter.east.isi.edu (8.12.8/8.12.8) with ESMTP id hA41wOwN003114 for ; Mon, 3 Nov 2003 20:58:24 -0500 (EST) Date: Mon, 3 Nov 2003 20:57:04 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ladan Gharai To: avt@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3058A794-0E6A-11D8-8232-000A95C47376@isi.edu> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [AVT] Summary changes to draft-ietf-avt-uncomp-video-04.txt. Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all: The following is a list of changes made to draft-ietf-avt-uncomp-video-04.txt: 1. For interlaced video the M bit is set at the end of both fields, and it indicates the end of a field. 2. The qualifier for RTP timestamps has been changed to SHOULD (from MUST): "A 90 kHz timestamp SHOULD be used ..." 3. Two new SDP parameters have introduced: - chromo-position: designates the position of the chromo values relative to luma values - top-field-first: for interlaced video, defines with which field are the chromo samples first transmitted. We feel with these changes the draft is complete and ready for Last Call, and would like to receive feedback from the community in this regard. Thank you, Ladan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 09:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15882 for ; Tue, 4 Nov 2003 09:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2G3-0000Zv-0z for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 09:34:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4EYBaQ002219 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 09:34:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2Ft-0000ZB-Az; Tue, 04 Nov 2003 09:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2FX-0000Yp-Pf for avt@optimus.ietf.org; Tue, 04 Nov 2003 09:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15867 for ; Tue, 4 Nov 2003 09:33:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH2FS-0006L9-00 for avt@ietf.org; Tue, 04 Nov 2003 09:33:34 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AH2FR-0006L6-00 for avt@ietf.org; Tue, 04 Nov 2003 09:33:33 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA4EXWI2017577; Tue, 4 Nov 2003 15:33:32 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6NMTJAN; Tue, 4 Nov 2003 15:33:32 +0100 Message-ID: <3FA7B8B3.5080603@ericsson.com> Date: Tue, 04 Nov 2003 15:33:23 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ersue Mehmet CC: "'ari.lakaniemi@nokia.com'" , "'avt@ietf.org'" , Wenk Stefan References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: RFC3267 question regarding not sending of NO_DATA Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Ersue, This comment actually applies to payload format in general. If you look at the Octet-algined mode this section is referenced regarding the definition of the FT field. We should probably try to restructure this or make it clearer that it applies for both bandwidth-efficient and octet-align mode in the draft standard version. The reasoning that it is very unnecessary to transmit NO_DATA frames when they instead can be deducted from the RTP TS is true for all modes, except interleaving where it does not hold. I hope this clarifies it for you. Cheers Magnus Ersue Mehmet wrote: > Hi Magnus, Ari, > > we are implementing RFC3267 octet aligned mode and during the > compliance cross check one question arose: > > On page 18 in chapter 4.3.2, which belongs to chapter > "4.3 Bandwidth efficient mode" is written: > > "Note that packets containing only NO_DATA frames SHOULD NOT be > transmitted. Also, frame-blocks containing only NO_DATA frames at > the end of a packet SHOULD NOT be transmitted, except in the case of > interleaving." > > First we assumed that packets with only NO_DATA SHOULD NOT be sent > in Bandwith efficient mode only, because this is in the "Bandwith > efficient" chapter. > On the other hand we do not understand the remark in the next sentence, > because it mentions interleaving. Interleaving is defined for Octet > Aligned only. (See 3.8). > > Are these "SHOULD NOT"s now valid also for "Octet Aligned"? > > > Best Regards, > Mehmet -- 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 exim@www1.ietf.org Tue Nov 4 09:35:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15927 for ; Tue, 4 Nov 2003 09:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2Gu-0000o0-RO for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 09:35:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4EZ4Ck003050 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 09:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2Gr-0000h1-LF; Tue, 04 Nov 2003 09:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH213-0008Mu-BP for avt@optimus.ietf.org; Tue, 04 Nov 2003 09:18:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15461 for ; Tue, 4 Nov 2003 09:18:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH211-0006AT-00 for avt@ietf.org; Tue, 04 Nov 2003 09:18:39 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AH211-0006AP-00 for avt@ietf.org; Tue, 04 Nov 2003 09:18:39 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hA4EIZF15937; Tue, 4 Nov 2003 15:18:36 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA4EIYs12230; Tue, 4 Nov 2003 15:18:34 +0100 (MET) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA00134; Tue, 4 Nov 2003 15:18:33 +0100 (MET) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Nov 2003 15:18:32 +0100 Message-ID: From: Ersue Mehmet To: "'magnus.westerlund@ericsson.com'" , "'ari.lakaniemi@nokia.com'" Cc: "'avt@ietf.org'" , Wenk Stefan Date: Tue, 4 Nov 2003 15:18:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [AVT] RFC3267 question regarding not sending of NO_DATA Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Magnus, Ari, we are implementing RFC3267 octet aligned mode and during the compliance cross check one question arose: On page 18 in chapter 4.3.2, which belongs to chapter "4.3 Bandwidth efficient mode" is written: "Note that packets containing only NO_DATA frames SHOULD NOT be transmitted. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted, except in the case of interleaving." First we assumed that packets with only NO_DATA SHOULD NOT be sent in Bandwith efficient mode only, because this is in the "Bandwith efficient" chapter. On the other hand we do not understand the remark in the next sentence, because it mentions interleaving. Interleaving is defined for Octet Aligned only. (See 3.8). Are these "SHOULD NOT"s now valid also for "Octet Aligned"? Best Regards, Mehmet _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 09:49:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16273 for ; Tue, 4 Nov 2003 09:49:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2UU-0001cK-8b for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 09:49:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4En6r0006184 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 09:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2UP-0001b1-0P; Tue, 04 Nov 2003 09:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2TW-0001UH-Km for avt@optimus.ietf.org; Tue, 04 Nov 2003 09:48:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16243 for ; Tue, 4 Nov 2003 09:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH2TU-0006UA-00 for avt@ietf.org; Tue, 04 Nov 2003 09:48:04 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AH2TU-0006U7-00 for avt@ietf.org; Tue, 04 Nov 2003 09:48:04 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA4Em3I2023351 for ; Tue, 4 Nov 2003 15:48:03 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6NMTPBM; Tue, 4 Nov 2003 15:48:03 +0100 Message-ID: <3FA7BC1A.7030804@ericsson.com> Date: Tue, 04 Nov 2003 15:47:54 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] AVT meeting Slides and Summary Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, As pointed out in the mail with the preliminary agenda, ALL persons with agenda time needs to do two things prior to the meeting: 1. Send a summary of open issues to the AVT mailing list. This needs to be done ASAP. The deadline for this has already passed! 2. Send slides in ppt or pdf to BOTH chairs before 12 noon EST (GMT -05:00) on Friday the 7th November. If this is not accomplished we chairs may resolve any scheduling difficulties or time constraints by excluding you from the agenda. Best Regards Magnus Westerlund & Colin Perkins _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 10:36:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18882 for ; Tue, 4 Nov 2003 10:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3Dx-0003bB-DG for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 10:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Fa516013829 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 10:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3Du-0003aI-D2; Tue, 04 Nov 2003 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3DO-0003ZN-OE for avt@optimus.ietf.org; Tue, 04 Nov 2003 10:35:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18810 for ; Tue, 4 Nov 2003 10:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3DM-00074G-00 for avt@ietf.org; Tue, 04 Nov 2003 10:35:28 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AH3DL-000748-00 for avt@ietf.org; Tue, 04 Nov 2003 10:35:27 -0500 Received: from mcomreyj ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Nov 2003 16:35:19 +0100 Reply-To: From: "Jose Rey" To: Date: Tue, 4 Nov 2003 16:35:16 +0100 Message-ID: <000901c3a2e9$40a32820$05640a0a@panasonic.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-OriginalArrivalTime: 04 Nov 2003 15:35:19.0428 (UTC) FILETIME=[40C5A440:01C3A2E9] Content-Transfer-Encoding: 7bit Subject: [AVT] Summary changes draft-rey-avt-3gpp-timed-text-01.txt and Timed Text presentation in Minneapolis Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, this is what I would like to discuss on Monday: - draft-rey-avt-3gpp-timed-text-01.txt presents a payload format for the 3GPP Timed Text media format. With respect to the -00 version in general all sections were completed: * completed empty sections from -00 draft. * abstract and introduction re-arranged. Moved section "Basics of the 3GP File Structure" to end of the document as Annex B. * SLEN, SIDX and SDUR lengths fixed to 16, 16 and 24 bits, respectively. * New OPTIONAL header, SPLDESC, added to transport sample description in-band. * Section 4 on payload format expanded: text header, fragment header and sample description header are fully specified. * SMIL usage section added. - Generic vs. Specific transport: in Vienna the issue was raised whether it should be more generic. After the publication of -01 version, little feedback has been heard about this; we would like to hear evereyone's opinion so the work can continue without surprises in the future. - fragmentation headers: the draft also defines complex fragmentation headers (FHDR, MTSF) that enable to get the most out of each fragment even when previous fragments were lost. What is the opinion of the WG on this? This may be an overkill as it increases complexity for just a couple of cases in which they will be used... - the PT-multiplexing will be abandoned because it is complex and gives problems, for example in SDP and ROHC. Instead additional fields in fixed header wil be used. - the sizes of length, index and duration fields of the text samples (SLEN, SIDX and SDUR) are currently 16, 16 and 24 bits. We are not clear if this is enough/too much. They allow for text samples sizes up 64KBytes, 65536 different indexes and a duration of samples up to four hours. When thinking on reducing these lengths one could argue to reduce SLEN to 1 byte but 256Bytes is too small . Taking a non-multiple of 8 is not an option because of parsing complexity, so 16bits is OK. For SIDX, 8 bits, should be enough I don't think there would be more than 256 sample descriptions in a text sample. And for SDUR, 16 bits would mean @1Khz ~1 minute, which is too short for streaming, so we propose to keep 24bits; also to cope with the case of different clockrate values. Comments? - resilient transport: when a packet is fragmented into several pieces, we think *at least* the fragments containing plain text strings shall be playable regardless of previous arrived or not (i.e. self-contained). Making the modifier boxes also resilient introduces complexity, as seen with the MTSF headers in the -01 draft. Therefore the tradeoff here would be to keep/adapt the necessary fields in the fragment header (FHDR) to display isolated text strings but abandon the MTSF headers for the modifier boxes. A solution for the latter could be to protect this through retransmissions, FEC or else. - the -01 draft does not specify how to reassemble fragments. This will be specified. - all other comments on the list noted. That's all, see you in Minneapolis. thanks, Jose ____________________________________ Jose Rey Mobile Multimedia Team - MCOM Group Panasonic European Laboratories GmbH Email: rey@panasonic.de Tel: +49(0)6103-766-134 Fax: +49(0)6103-766-166 http://www.pel.panasonic.de ____________________________________ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 13:21:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26203 for ; Tue, 4 Nov 2003 13:21:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5nb-00009N-3S for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 13:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4IL3UB000576 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 13:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5nZ-00008v-By; Tue, 04 Nov 2003 13:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5nX-00008i-Ne for avt@optimus.ietf.org; Tue, 04 Nov 2003 13:21:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26163 for ; Tue, 4 Nov 2003 13:20:45 -0500 (EST) From: David.Leon@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5nV-0002AJ-00 for avt@ietf.org; Tue, 04 Nov 2003 13:20:57 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AH5nU-0002A8-00 for avt@ietf.org; Tue, 04 Nov 2003 13:20:56 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4IKtF22740 for ; Tue, 4 Nov 2003 20:20:55 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Nov 2003 20:20:55 +0200 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 12:20:39 -0600 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 Subject: RE: [AVT] Retransmission draft Date: Tue, 4 Nov 2003 12:20:38 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA4010289F9@daebe009.americas.nokia.com> Thread-Topic: [AVT] Retransmission draft Thread-Index: AcOX9OQk2fZEoQHIT+qZwtoJZZGCIQLCwixw To: , Cc: , X-OriginalArrivalTime: 04 Nov 2003 18:20:39.0258 (UTC) FILETIME=[597393A0:01C3A300] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I think it would be good to put the current IPR situation into = perspective. All that we know is that Matsushita have a patent = application that could be applicable to the retransmission draft = according to their judgement. This does not mean that an actual patent will be granted or that the = retransmission draft would really infringe on such a patent. At this = point of time, saying that the retransmission draft is patented is only = speculation. Such speculation should not in my opinion prevent the draft = from progressing. David. > > > > Taking all the above into account and considering that > > independent of the patent situation this work is intended to be=20 > > included in > > the next release of 3GPP, we would like to ask the group to proceed=20 > > with the > > draft on standards track. > > > > cheers, > > Jose >=20 > [takes working group chair hat off] >=20 > 3GPP is only one forum which uses IETF standards, and one=20 > where dealing=20 > with IPR issues is commonplace. Having patented standards is=20 > more of an=20 > issue for open source developers, who are often excluded by the=20 > licensing terms. Would Matsushita be willing to clarify if the=20 > "reasonable, nondiscriminatory" terms allow open source=20 > implementations=20 > to use the retransmission format (this will probably require a=20 > Royalty-Free license)? >=20 > [puts working group chair hat on again] >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=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 exim@www1.ietf.org Tue Nov 4 13:22:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26241 for ; Tue, 4 Nov 2003 13:22:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5oY-0000K5-Bv for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 13:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4IM2J7001208 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 13:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5oX-0000Iw-RN; Tue, 04 Nov 2003 13:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5ni-0000Af-0K for avt@optimus.ietf.org; Tue, 04 Nov 2003 13:21:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26187 for ; Tue, 4 Nov 2003 13:20:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5nf-0002Ao-00 for avt@ietf.org; Tue, 04 Nov 2003 13:21:07 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AH5nf-0002A6-00 for avt@ietf.org; Tue, 04 Nov 2003 13:21:07 -0500 Received: from alor ([130.209.247.84]:53738 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AH5nB-0006zH-00; Tue, 04 Nov 2003 18:20:37 +0000 Date: Tue, 4 Nov 2003 18:20:30 +0000 Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Vladimir Ulybin" From: Colin Perkins In-Reply-To: Message-Id: <926D7D46-0EF3-11D8-83F8-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vladimir, On Monday, Nov 3, 2003, at 06:23 Europe/London, Vladimir Ulybin wrote: > Together with advantages (encryption for security needs, the same > port/address for RTP+audio and RTP+t38) the proposed encapsulation of > T.38 into RTP has some disadvantages. > > 1. The protection from and recovery of packet lost in T.38 is usually > stronger than that of RTP. So, using the RTP error correction for T.38 > seems to be problematic. > > 2. The bi-directional switching between Voice-Band-Data and T.38 modes > remains problematic as in current implementations because the RTP > payload of VBD has no ID of fax session. > > The more attractive approach is given in delayed contribution 303 of > CISCO (May 2003, ITU-T, Study Group 16) to support RTP encapsulated > into > T.38. That idea is inversed to the discussed one, and has more > capabilities for implementation of reliable fax transfer. Since the RTP payload format for T.38 is being developed in ITU-T SG16, these comments would be better suited to that forum. The MIME type registration we are developing here is dependent on that work, and will only be published as an RFC when the ITU completes the revision to T.38 including the payload format. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 13:29:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26553 for ; Tue, 4 Nov 2003 13:29:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5vK-0000ud-5p for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 13:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4IT2RN003474 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 13:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5vJ-0000tR-Gs; Tue, 04 Nov 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5uR-0000qq-CC for avt@optimus.ietf.org; Tue, 04 Nov 2003 13:28:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26402 for ; Tue, 4 Nov 2003 13:27:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5uP-0002Ez-00 for avt@ietf.org; Tue, 04 Nov 2003 13:28:05 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AH5uO-0002ET-00 for avt@ietf.org; Tue, 04 Nov 2003 13:28:04 -0500 Received: from alor ([130.209.247.84]:53741 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AH5tu-00070o-00; Tue, 04 Nov 2003 18:27:34 +0000 Date: Tue, 4 Nov 2003 18:27:29 +0000 Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Paul E. Jones" From: Colin Perkins In-Reply-To: <00cd01c39ff2$04b63d60$0401a8c0@berlin> Message-Id: <8C68CB19-0EF4-11D8-83F8-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul, On Friday, Oct 31, 2003, at 21:00 Europe/London, Paul E. Jones wrote: > I would like to seek agreement from the AVT group to move the document > audio/t38 document forward. As I have mentioned previously, the ITU > would > like to incorporate this in T.38 in an amendment to be approved in > January > 2004. > > The motivation for transporting T.38 via RTP is probably obvious to > most. > In fact, I recall several saying that that is the way it should have > been > done from the outset. Most certainly, this will prove to be a good > step in > leveraging SRTP for fax to address security needs. > > The document is relatively short, just seeking the MIME registration. > The > technical details will be specified in the ITU-T Recommendation T.38. > > Can I get agreement to make this an official working group item? Can > we try to get this approved by the January 2004 ITU-T SG16 meeting? After discussion, Magnus and I have decided that it is not appropriate to make this an official work item of AVT, because the payload format is not being developed in AVT. We are, however, willing to review the format and recommend its publication to the IESG, assuming there is consensus from the working group that this is appropriate. Accordingly, this message is to solicit comments from the working group on the suitability of this MIME type registration for publication (assuming a matching payload format is developed by ITU SG16). Please send comments by Monday 17th November, so we have time to co-ordinate publication schedules with the ITU, IESG and RFC Editor. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 14:37:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00047 for ; Tue, 4 Nov 2003 14:37:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6zD-0007Ui-9g for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 14:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Jb6ft028764 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 14:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6z9-0007Sx-9k; Tue, 04 Nov 2003 14:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6yV-0007QN-7P for avt@optimus.ietf.org; Tue, 04 Nov 2003 14:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00012 for ; Tue, 4 Nov 2003 14:36:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6yS-0003bS-00 for avt@ietf.org; Tue, 04 Nov 2003 14:36:20 -0500 Received: from [63.163.229.65] (helo=[208.236.204.65]) by ietf-mx with smtp (Exim 4.12) id 1AH6yR-0003bO-00 for avt@ietf.org; Tue, 04 Nov 2003 14:36:20 -0500 Received: from namasmtp02.nmss.com by [208.236.204.65] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 4 Nov 2003 14:37:08 -0500 To: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Tue, 4 Nov 2003 14:36:11 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 11/04/2003 02:36:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [AVT] Summary discussion items form Minneapolis - draft-basso-avt-videoconreq-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , We are planning to briefly discuss the draft draft-basso-avt-videoconreq-00.txt in the coming IETF. The draft looks at the requirements for the transport of video codec control commands. We are specifically interested in discussing: 1- List of commands: The current draft has a comprehensive list of commands for codec control. Some of them are popular in particular in video conferencing applications. Some others are much less popular and almost never used in current applications. So the list needs trimming. We are looking for comments on commands that need to be added to the list and the ones that can be safely removed. 2- Reliability Requirements of codec control commands: We are looking for comments on the reliability requirements for each of commands discussed in the list resulting from the discussion of item 1. 3- Next steps: Is AVT a good home for the follow-up draft that will describe the mechanisms of transport video codec control commands? -Andrea Andrea Basso NMS Communications _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 20:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15631 for ; Tue, 4 Nov 2003 20:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCfY-0006f6-Em for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 20:41:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA51fCFF025607 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 20:41:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCfO-0006eG-BX; Tue, 04 Nov 2003 20:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCej-0006dw-AR for avt@optimus.ietf.org; Tue, 04 Nov 2003 20:40:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15585 for ; Tue, 4 Nov 2003 20:40:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCeg-0001Ou-00 for avt@ietf.org; Tue, 04 Nov 2003 20:40:19 -0500 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AHCeg-0001Om-00 for avt@ietf.org; Tue, 04 Nov 2003 20:40:18 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hA51bgN6003510 for ; Tue, 4 Nov 2003 20:39:49 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C01A27516; Tue, 4 Nov 2003 20:39:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: Tue, 4 Nov 2003 19:39:48 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0201EF05@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [AVT] Draft agenda for Minneapolis Thread-Index: AcOdps80y2HTzLFLTsqCP603KtRQ1gFk37BQ From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" Content-Transfer-Encoding: quoted-printable Subject: [AVT] RE: Agenda for Minneapolis Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable All, Here is a brief summary regarding the following agenda item: > RTP Header Compression over Multi-Hop Paths (Ash) 30 > draft-ash-e2e-voip-hdr-comp-rqmts-01.txt http://ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt Some service providers (such as AT&T) have plans to migrate large = amounts of legacy voice traffic to VoIP, as well as to provide VPN = services enabling VoIP. VoIP typically uses the encapsulation = voice/RTP/UDP/IP/. When MPLS=20 labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an=20 MPLS VPN, the packet header is at least 48 bytes, while the voice=20 payload is often no more than 30 bytes. VoIP header compression can = significantly reduce the VoIP overhead through various compression = mechanisms. This is important on access links where bandwidth is = scarce, and can be important on backbone facilities, especially where = costs are high (e.g., some global cross-sections). Providing VoIP = header compression over multiple hop paths avoids multiple = compression/decompression cycles at each router, and thereby increases = the processing scalability of the maximum number of simultaneous VoIP = flows which use header compression at each router. =20 =20 I will summarize the problem statement, goals, example scenarios, = requirements, and work items as described in = http://ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt.= =20 I'll also discuss the following issues: 1. Protocol extensions -- Extensions are proposed to [cRTP] and [ECRTP], = which involve a new packet type field to identify FULL_HEADER, = CONTEXT_STATE, etc. packets. New objects are defined for [RSVP-TE]. = Extensions are also proposed to RFC2547 VPNs, which create 'SCID routing = tables' to allow routing based on the session context ID (SCID). These = extensions need coordination with other WGs (e.g., MPLS). 2. Resynchronization -- VoIP header compression over multiple-hop paths = using cRTP header compression might not perform well with frequent = resynchronizations. [ECRTP] seems appropriate in this context. The = 'simple' header compression approach would avoid the need for = resynchronization, but achieves less efficiency than cRTP. 3. Scalability -- VoIP header compression over multiple-hop paths = applied between CE-CE would perhaps require a large number of LSPs to be = created. There is concern for CE ability to do the necessary processing = and the scalability of the architecture. 4. LDP application -- It would be desirable to signal the MPLS LSPs with = LDP, since many RFC2547 VPN implementations use LDP as the underlying = LSP signaling mechanism. Please review the document and raise any issues/comments to the list. Thanks, Jerry Ash _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 21:32:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16996 for ; Tue, 4 Nov 2003 21:32:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDSn-0001ky-Vs for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 21:32:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA52W5MK006731 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 21:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDSk-0001kL-4X; Tue, 04 Nov 2003 21:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDS5-0001jk-V8 for avt@optimus.ietf.org; Tue, 04 Nov 2003 21:31:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16948 for ; Tue, 4 Nov 2003 21:31:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDS3-00022A-00 for avt@ietf.org; Tue, 04 Nov 2003 21:31:19 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AHDS2-000227-00 for avt@ietf.org; Tue, 04 Nov 2003 21:31:18 -0500 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hA52VGBQ014138; Tue, 4 Nov 2003 21:31:17 -0500 Message-ID: <067a01c3a344$b5bcf8b0$85aa6b80@cisco.com> From: "Paul E. Jones" To: "Colin Perkins" Cc: References: <8C68CB19-0EF4-11D8-83F8-000A957FC5F2@csperkins.org> Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Date: Tue, 4 Nov 2003 21:29:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin, It's perfectly fine with me if we take this course of action. I just want to ensure that we have the necessary MIME registration in place, so whatever is necessary to make that happen, I'm willing to do it. Please advise on the next step to be taken to get the necessary registration. Paul ----- Original Message ----- From: "Colin Perkins" To: "Paul E. Jones" Cc: Sent: Tuesday, November 04, 2003 1:27 PM Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward > Paul, > > On Friday, Oct 31, 2003, at 21:00 Europe/London, Paul E. Jones wrote: > > I would like to seek agreement from the AVT group to move the document > > audio/t38 document forward. As I have mentioned previously, the ITU > > would > > like to incorporate this in T.38 in an amendment to be approved in > > January > > 2004. > > > > The motivation for transporting T.38 via RTP is probably obvious to > > most. > > In fact, I recall several saying that that is the way it should have > > been > > done from the outset. Most certainly, this will prove to be a good > > step in > > leveraging SRTP for fax to address security needs. > > > > The document is relatively short, just seeking the MIME registration. > > The > > technical details will be specified in the ITU-T Recommendation T.38. > > > > Can I get agreement to make this an official working group item? Can > > we try to get this approved by the January 2004 ITU-T SG16 meeting? > > After discussion, Magnus and I have decided that it is not appropriate > to make this an official work item of AVT, because the payload format > is not being developed in AVT. We are, however, willing to review the > format and recommend its publication to the IESG, assuming there is > consensus from the working group that this is appropriate. > > Accordingly, this message is to solicit comments from the working group > on the suitability of this MIME type registration for publication > (assuming a matching payload format is developed by ITU SG16). Please > send comments by Monday 17th November, so we have time to co-ordinate > publication schedules with the ITU, IESG and RFC Editor. > > -- > Colin Perkins > http://csperkins.org/ > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 4 22:38:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21455 for ; Tue, 4 Nov 2003 22:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEUg-0007RA-TF for avt-archive@odin.ietf.org; Tue, 04 Nov 2003 22:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA53c68i028572 for avt-archive@odin.ietf.org; Tue, 4 Nov 2003 22:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEUb-0007QF-B5; Tue, 04 Nov 2003 22:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHETi-00079b-RW for avt@optimus.ietf.org; Tue, 04 Nov 2003 22:37:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21407 for ; Tue, 4 Nov 2003 22:36:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHETf-0003KZ-00 for avt@ietf.org; Tue, 04 Nov 2003 22:37:03 -0500 Received: from ns6.sony.co.jp ([137.153.0.32]) by ietf-mx with esmtp (Exim 4.12) id 1AHETe-0003KW-00 for avt@ietf.org; Tue, 04 Nov 2003 22:37:02 -0500 Received: from mail7.sony.co.jp (mail7.sony.co.jp [43.0.1.209]) by ns6.sony.co.jp (R8/Sony) with ESMTP id hA53axb21101; Wed, 5 Nov 2003 12:36:59 +0900 (JST) Received: from mail7.sony.co.jp (localhost [127.0.0.1]) by mail7.sony.co.jp (R8/Sony) with ESMTP id hA53ax908418; Wed, 5 Nov 2003 12:36:59 +0900 (JST) Received: from localhost.localdomain ([43.13.117.111]) by mail7.sony.co.jp (R8/Sony) with ESMTP id hA53aww08406; Wed, 5 Nov 2003 12:36:58 +0900 (JST) Received: from AVGPU.av.crl.sony.co.jp (avgpu.av.crl.sony.co.jp [43.13.117.113] (may be forged)) by localhost.localdomain (8.12.8/8.12.8) with SMTP id hA53awh2004646; Wed, 5 Nov 2003 12:36:58 +0900 Message-Id: <200311050335.AA00603@AVGPU.av.crl.sony.co.jp> Date: Wed, 05 Nov 2003 12:35:48 +0900 To: "Magnus Westerlund (KI/EAB)" Cc: hatanaka@av.crl.sony.co.jp, matthew.romaine@jp.sony.com, avt@ietf.org, nishi@av.crl.sony.co.jp, jun@av.crl.sony.co.jp From: Jun Matsumoto In-Reply-To: <034BEFD03799D411A59F00508BDF754602BF41CA@esealnt448.al.sw.ericsson.se> References: <034BEFD03799D411A59F00508BDF754602BF41CA@esealnt448.al.sw.ericsson.se> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii Subject: [AVT] Re: Comments on draft-hatanaka-avt-rtp-atracx-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear Mr.Westerlund, >In my opinion you need to go back to the drawing board and rethink the design. >This design seems to be much to complex for the purpose. However as you haven't clearly >communicated the purpose I am not certain. I think there exist simple solutions. OK, We agree that the complexity of our proposal. Reffering your advise, we will re-design a simplified payload format, and then make a proposal as ***-atracx-04.txt by Seoul meeting. We have decided we do not go to Minneapolis meeting, so we would like you to cancel our presentation time slot. Thank you very much for your useful advise. Best Regards, -------------------------------------- Jun Matsumoto Audio Codec Development Department Sony Corporation, IMNC jun@av.crl.sony.co.jp -------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 02:24:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18365 for ; Wed, 5 Nov 2003 02:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHI1V-0003g3-JW for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 02:24:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA57ODEJ014092 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 02:24:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHI1J-0003eL-7u; Wed, 05 Nov 2003 02:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHI1B-0003dy-NH for avt@optimus.ietf.org; Wed, 05 Nov 2003 02:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17487 for ; Wed, 5 Nov 2003 02:23:39 -0500 (EST) From: ari.lakaniemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHI17-0005yE-00 for avt@ietf.org; Wed, 05 Nov 2003 02:23:49 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHI16-0005yA-00 for avt@ietf.org; Wed, 05 Nov 2003 02:23:48 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA57NmF17278 for ; Wed, 5 Nov 2003 09:23:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Nov 2003 09:23:45 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 09:23:44 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 09:23:41 +0200 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: Wed, 5 Nov 2003 09:23:38 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C5909840001AC865B@trebe004.europe.nokia.com> Thread-Topic: RTP payload format for AMR-WB+ audio codec Thread-Index: AcOjbbtnu30FluCdTAaGzqw6L3tAng== To: X-OriginalArrivalTime: 05 Nov 2003 07:23:41.0438 (UTC) FILETIME=[BD0351E0:01C3A36D] Content-Transfer-Encoding: quoted-printable Subject: [AVT] RTP payload format for AMR-WB+ audio codec Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hello all, Here is a very short summary about the agenda item "RTP payload format = for AMR-WB+ audio codec" (draft-sjoberg-avt-rtp-amrwbplus-00.txt). As the title suggests, the draft proposes an RTP payload format for the = AMR-WB+ codec, which is currently being specified by 3GPP TSG SA WG4. = The main topics of the presentation/discussion are 1. Introduction of the AMR-WB+ codec - audio extension to the AMR-WB speech codec 2. Proposal for the RTP payload format for AMR-WB+ codec - based on AMR-WB RTP payload format (RFC 3267) 3. Summary of differences between the AMR-WB RTP format and the proposed = format for AMR-WB+ 4. Next steps - feedback from the group - group work item? --- Ari Lakaniemi Nokia Research Center _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 05:51:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00225 for ; Wed, 5 Nov 2003 05:51:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLFl-0000CJ-3X for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 05:51:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Ap9M6000755 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 05:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLFd-0000BV-CZ; Wed, 05 Nov 2003 05:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLFX-0000B4-3U for avt@optimus.ietf.org; Wed, 05 Nov 2003 05:50:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00198; Wed, 5 Nov 2003 05:50:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLFT-0001Cj-00; Wed, 05 Nov 2003 05:50:51 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AHLFS-0001Ca-00; Wed, 05 Nov 2003 05:50:50 -0500 Received: from pulusuk ([130.209.244.207]:49177 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AHLEy-0002BW-00; Wed, 05 Nov 2003 10:50:20 +0000 Date: Wed, 5 Nov 2003 10:50:19 +0000 Content-Type: multipart/mixed; boundary=Apple-Mail-2--472093619 Mime-Version: 1.0 (Apple Message framework v552) Cc: Magnus Westerlund , agenda@ietf.org, Eddie Kohler To: avt@ietf.org From: Colin Perkins Message-Id: X-Mailer: Apple Mail (2.552) Subject: [AVT] Revised AVT agenda Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --Apple-Mail-2--472093619 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Folks, As you may have noticed, the final IETF agenda moves the first AVT slot, giving us 30 minutes less discussion time. Attached is a revised agenda, taking this into account. Apologies for the change - there were scheduling conflicts which have, so far, proved impossible to resolvable. -- Colin Perkins http://csperkins.org/ --Apple-Mail-2--472093619 Content-Disposition: attachment; filename=agenda.txt Content-Type: text/plain; x-unix-mode=0644; name="agenda.txt" Content-Transfer-Encoding: 7bit Audio/Video Transport Working Group CHAIRS: Colin Perkins Magnus Westerlund Monday, 10th October 2003 at 13:00-15:00 ======================================== Introduction and Status Update (Chairs) 5 draft-ietf-avt-crtp-enhance-07.txt => RFC 3545 draft-ietf-avt-rtp-new-12.txt => RFC 3550 draft-ietf-avt-profile-new-13.txt => RFC 3551 draft-ietf-avt-rtp-mime-06.txt => RFC 3555 draft-ietf-avt-rtcp-bw-05.txt => RFC 3556 draft-ietf-avt-dsr-05.txt => RFC 3557 draft-ietf-avt-evrc-smv-03.txt => RFC 3558 draft-ietf-avt-rtp-retransmission-09.txt [AD Evaluation] draft-ietf-avt-rtcp-feedback-07.txt [AD Evaluation] draft-burmeister-avt-rtcp-feedback-sim-02.txt [AD Evaluation] draft-ietf-avt-tcrtp-07.txt [AD Evaluation] draft-ietf-srtp-09.txt [IESG review] draft-ietf-avt-mpeg4-simple-08.txt [RFC Editor] draft-ietf-avt-rtcp-report-extns-06.txt [RFC Editor] draft-ietf-avt-uxp-06.txt draft-ietf-avt-rfc2833bis-03.txt draft-ietf-avt-rtp-clearmode-03.txt draft-ietf-avt-mpeg1and2-mod-00.txt draft-kerr-avt-vorbis-rtp-03.txt draft-herlein-speex-rtp-profile-01.txt draft-jones-avt-audio-t38-01.txt draft-ramalho-rgl-rtpformat-02.txt draft-chen-rtp-bv-00.txt Updates on behalf of author (Chairs) 10 draft-ietf-avt-ulp-08.txt draft-ietf-avt-rtp-jpeg2000-04.txt draft-ietf-avt-midi-rtp-00.txt draft-ietf-avt-midi-guidelines-00.txt draft-lazzaro-avt-rtp-framing-contrans-02.txt RTP payload format for AMR-WB+ audio codec (Lakaniemi) 15 draft-sjoberg-avt-rtp-amrwbplus-00.txt Highlights of VMR-WB RTP Payload and Storage Format (Ahmadi) 15 draft-ahmadi-avt-rtp-vmr-wb-00.txt RTP payload formats for ETSI DSR front ends (Xie) 15 draft-ietf-avt-dsr-es202050-01.txt draft-xie-avt-xdsr-es202211-00.txt draft-xie-avt-xadsr-es202212-00.txt RTP payload format for ATRAC-X (Hatanaka) 15 draft-hatanaka-avt-rtp-atracx-03.txt Internet Low Bit Rate Codec & its RTP payload format (Duric) 15 draft-ietf-avt-rtp-ilbc-03.txt draft-ietf-avt-ilbc-codec-03.txt RTP Payload for Text Conversation (Hellstrom) 15 draft-hellstrom-avt-rfc2793bis-02.txt Way forward for the RTP payload format for Timed Text (Rey) 15 draft-rey-avt-3gpp-timed-text-01.txt Wednesday, 12th October 2003 at 09:00-11:30 =========================================== RTP Payload Format for Uncompressed Video (Gharai) 10 draft-ietf-avt-uncomp-video-04.txt RTP payload Format for H.264 Video (Wenger) 15 draft-ietf-avt-rtp-h264-03.txt RTCP Extensions for SSM with Unicast Feedback (Ott) 15 draft-ietf-avt-rtcpssm-05.txt Extended Secure RTP Profile for RTCP-based Feedback (Ott) 15 draft-ietf-avt-profile-savpf-00.txt RTCP Streaming Extended Reports (Tseng) 15 draft-tseng-avt-rtcp-streaming-extens-00.txt Proposed additions to RTP MIB (Clark) 15 draft-clark-avt-rtpmibv2-00.txt Datagram Congestion Control Protocol (DCCP) and RTP (Kohler) 15 draft-ietf-dccp-spec-05.txt draft-ietf-dccp-ccid2-04.txt draft-ietf-dccp-ccid3-04.txt draft-ietf-dccp-ccid3-thin-00.txt RTP Header Compression over Multi-Hop Paths (Ash) 15 draft-ash-e2e-voip-hdr-comp-rqmts-01.txt Requirements for transport of video control commands (Basso) 15 draft-basso-avt-videoconreq-00.txt SDP parameters for supporting H.263 and H.261 options (Even/Ismail) 20 draft-even-avt-h263-h261-options-00.txt draft-nismail-mmusic-sdp-video-00.txt --Apple-Mail-2--472093619-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 08:16:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04553 for ; Wed, 5 Nov 2003 08:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNW2-0000Jd-Hk for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 08:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5DG6gh001204 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 08:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNVw-0000Ih-Qf; Wed, 05 Nov 2003 08:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHNVf-0000CL-9f for avt@optimus.ietf.org; Wed, 05 Nov 2003 08:15:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04432 for ; Wed, 5 Nov 2003 08:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNVe-0003mt-00 for avt@ietf.org; Wed, 05 Nov 2003 08:15:42 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AHNVd-0003mp-00 for avt@ietf.org; Wed, 05 Nov 2003 08:15:41 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA5DFZI2025034; Wed, 5 Nov 2003 14:15:36 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHXBFJY4; Wed, 5 Nov 2003 14:15:39 +0100 Message-ID: <3FA8F7EC.6020800@ericsson.com> Date: Wed, 05 Nov 2003 14:15:24 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun Matsumoto CC: hatanaka@av.crl.sony.co.jp, matthew.romaine@jp.sony.com, avt@ietf.org, nishi@av.crl.sony.co.jp References: <034BEFD03799D411A59F00508BDF754602BF41CA@esealnt448.al.sw.ericsson.se> <200311050335.AA00603@AVGPU.av.crl.sony.co.jp> In-Reply-To: <200311050335.AA00603@AVGPU.av.crl.sony.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Comments on draft-hatanaka-avt-rtp-atracx-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Jun, I hope that you are not discouraged to continue the work by my rather long mail. As I see it there are some problems that one faces when trying to write a payload format for a codec within the AVT WG. The first is a matter of learning. One needs to have a rather good understanding of the codecs capabilities and working to know what requirements it has on the transport, thus it is usually codec people that comes to AVT. Then one must learn about how RTP and IP works and what the available mechanisms are. This will require one to learn a rather big pile of documents. Sorry to say we chairs or other group members does not always have the time to early enough point out some important details. I hope we in the future can improve this and also create some more informational material to help RTP payload designers. I am also very sorry to hear that you are not coming to Minneapolis, I would have very much liked to discuss your payload format's design. Having direct communication can help immensely to ensure that the important aspects are covered. I would also recommend that you try to create a new proposal in good time prior to the IETF meeting, thus we can make better progress. People usually have more time for discussion things when not stressed by deadlines or hugh workload prior to a meeting. It also allows you time to discuss or ask questions halfway the design process. When it comes to payload format design I think there are some general things that needs to be ensured: - Follow the application level framing principle, i.e. self contained packets. - Keep it simple. - Utilize the available mechanism in RTP in a good way. Again if you have questions regarding design choices, please voice them to the list. Best Regards Magnus Jun Matsumoto wrote: > Dear Mr.Westerlund, > > >>In my opinion you need to go back to the drawing board and rethink the design. >>This design seems to be much to complex for the purpose. However as you haven't clearly >>communicated the purpose I am not certain. I think there exist simple solutions. > > > OK, We agree that the complexity of our proposal. > Reffering your advise, we will re-design a simplified payload format, > and then make a proposal as ***-atracx-04.txt by Seoul meeting. > > We have decided we do not go to Minneapolis meeting, so we would like you > to cancel our presentation time slot. > > Thank you very much for your useful advise. > > Best Regards, > > -------------------------------------- > Jun Matsumoto > > Audio Codec Development Department > Sony Corporation, IMNC > > jun@av.crl.sony.co.jp > -------------------------------------- -- 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 exim@www1.ietf.org Wed Nov 5 08:53:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05626 for ; Wed, 5 Nov 2003 08:53:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO5m-0002Oq-CU for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 08:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Dr2Uh009218 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 08:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO5l-0002OT-74; Wed, 05 Nov 2003 08:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO5C-0002Ma-33 for avt@optimus.ietf.org; Wed, 05 Nov 2003 08:52:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05600 for ; Wed, 5 Nov 2003 08:52:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHO5A-0004RN-00 for avt@ietf.org; Wed, 05 Nov 2003 08:52:24 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AHO59-0004RK-00 for avt@ietf.org; Wed, 05 Nov 2003 08:52:24 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA5DqFI2010689; Wed, 5 Nov 2003 14:52:15 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6M2RAW9; Wed, 5 Nov 2003 14:52:15 +0100 Message-ID: <3FA90084.6040500@ericsson.com> Date: Wed, 05 Nov 2003 14:52:04 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Li CC: "'Colin Perkins'" , IETF AVT WG References: <004301c3a325$11306e90$2400a8c0@divxnetworks.com> In-Reply-To: <004301c3a325$11306e90$2400a8c0@divxnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: ULP multiplexing schemes Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Adam, I thought this mail being of such general discussion value that I CC the mailing list in my response, I hope you don't feel hurt. Adam Li wrote: > Hi Magnus, > > I have a couple of questions about multiplexing. > > RFC 3550 says "For efficient protocol processing, the number of > multiplexing points should be minimized, as described in the integrated > layer processing design principle." It specifically recommends against > multiplexing multiple stream of different media type in the same session > based on PT and SSRC. (It does recognize multiplexing media of the same > type with SSRC.) With this, shouldn't we discourage multiplexing, i.e., > putting the media and FEC streams (they should be regarded as different > media?) in the same address/port and multiplexing them only based on PT > or SSRC? Yes, and no. In some sense one might consider it as another media, and thus send it in a separate session. Using separate sessions has the advantage when one likes to be able do disconnect the ULP media. On the other hand the ULP stream is the same media as it encodes over. IT shares the timestamp behaviour, delivery requirements, etc. If you look in the list of argument in RFC 3550 against multiplexing separate media into the a single session you see that they does not apply for this case: 1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings. This does not apply as they after reconstruction are a single stream. 2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss. As the ULP simply integrates into the timestamp space and does not really use it, there is no problem. The sequence number does for most payload formats not create any problem, the current exceptions are some fragmented video formats and RFC 2793. It is after all if the there is needed to know if the lost packet was an ULP packet or real media that enables the usage of this or not. 3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field. This is not a concern for ULP as it does not use the TS space, and packet loss reports can just as well be done aggregated then separated. 4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. An mixer is an user of ULP to recovery the stream for mixing therefore it is not a problem. 5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. This is a valid reason and in cases where it applies the session multiplexing should be used. Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two. So in summary, there are two of these points that applies for ULP as I see it: 2 and 5. And this is fully dependent on the use cases and media transported. I think the concerns around point 2 is the more important one and these can be addressed though the usage of RFC 2198 for ULP information. > > Another question is about the Session Multiplexing. It seems that we > usually refer to multiplexing as the practice of putting multiple > streams in the same socket connection (same address/port pair), and > separate the streams based on some marks on the packets. If two streams > are in separate sessions, then maybe it is a little confusing to call > them multiplexing. Yes, however there is a clear binding between the ULP stream and its original data stream. Without the capability to bind them together the ULP information becomes useless. > > I guess you are more concerned about how we can associate the FEC > streams to the payload streams under different scenarios, right? Sending > the FEC stream in another session seems is just a very special case of > the many other ways to send the FEC stream separately. And it is a quite > un-natural way. It is not obvious how to associate a stream in one > session to another stream in another session? I feel it may not be > necessary to specify all the details for every combinations and > possibilities, because there are simply way too many of them to send two > streams separately. This is exactly my concerns, and I do not agree that there is not need to specify how they are used. I can agree that not all possible needs to be specified, however I feel that the different major cases needs to be defined. As I see it we have three different ways that for different usage are needed due to different scenarios, these should be clearly specified how to use. The three cases are: - PT multiplexing, restricted for some payload formats that needs it sequence number untouched, RFC 2793 and some fragmentation schemes in some payload formats, like H.264 will not like it. - Usage of RFC 2198 to include ULP data as redundant data. - Sending ULP in separate RTP session, need when one wants to have separate treatment of the data streams or avoid sending useless data to receivers that can't decode it. > > My suggestion is that we simply mention in the draft that PT > multiplexing is possible, SSRC multiplex is not possible, and refer to > the RFC 3550 to discourage multiplexing FEC stream with the payload > through the same address/port. > All of the three above mentioned methods has separate concerns regarding signalling and usage. For example the session multiplexing scheme needs to use grouping of media lines (RFC3388) to bind them together explicitly. There are also SSRC consideration rules for this, see the RTP retransmission draft. The usage of RED is already in there, and some paragraphs about the PT multiplexing and its concerns are also needed. I would also include a motivation why SSRC multiplexing is not a good method. 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 exim@www1.ietf.org Wed Nov 5 11:43:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12518 for ; Wed, 5 Nov 2003 11:43:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQkM-00047K-G8 for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 11:43:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Gh6EC015802 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 11:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQkH-00046I-NV; Wed, 05 Nov 2003 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQjf-00045a-Vn for avt@optimus.ietf.org; Wed, 05 Nov 2003 11:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12498 for ; Wed, 5 Nov 2003 11:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQje-0006ic-00 for avt@ietf.org; Wed, 05 Nov 2003 11:42:22 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AHQjd-0006iZ-00 for avt@ietf.org; Wed, 05 Nov 2003 11:42:22 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA5GgKSs029460 for ; Wed, 5 Nov 2003 17:42:21 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6M2TT8L; Wed, 5 Nov 2003 17:42:20 +0100 Message-ID: <3FA92861.9080704@ericsson.com> Date: Wed, 05 Nov 2003 17:42:09 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Summary for draft-ietf-avt-rtp-h264-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi This is the summary of open issues to be discussed for the H.264 RTP payload format: o The security section needs review. o An optional MIME/SDP parameter, max-don-diff, was added as an option to control the receiver buffering in the interleaved packetization mode. max-don-diff is specified similarly to the maximum displacement parameter in the draft-ietf-avt-mpeg4-simple Internet Draft, but instead of using a maximum difference in terms of RTP timestamps a maximum difference in terms of decoding order numbers is used. Does max-don-diff bring benefits that justify the complicated receiver description? o ITU-T H.241 provides a way for decoders to signal capability for greater processing speed or memory amount than required in the profile and level that is used. H.241 specifies CustomMaxMBPS, CustomMaxFS, CustomMaxDPB, and CustomMaxBRandCPB. Should similar parameters be specified as optional MIME/SDP parameters to enhance the capability exchange procedure of SIP-based video conferencing? Please send any comment to the AVT list. Best Regards 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 exim@www1.ietf.org Wed Nov 5 12:37:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14178 for ; Wed, 5 Nov 2003 12:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRae-0007f3-1l for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 12:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Hb7Qw029406 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 12:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRaX-0007cg-TE; Wed, 05 Nov 2003 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRZy-0007bO-Et for avt@optimus.ietf.org; Wed, 05 Nov 2003 12:36:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14139 for ; Wed, 5 Nov 2003 12:36:12 -0500 (EST) From: sassan.ahmadi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRZw-0007P5-00 for avt@ietf.org; Wed, 05 Nov 2003 12:36:24 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHRZw-0007P2-00 for avt@ietf.org; Wed, 05 Nov 2003 12:36:24 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5HaNF16808 for ; Wed, 5 Nov 2003 19:36:23 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Nov 2003 19:36:23 +0200 Received: from sdebe002.NOE.Nokia.com ([172.19.201.138]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 09:36:14 -0800 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: Wed, 5 Nov 2003 09:36:14 -0800 Message-ID: <0B08EA1BF5F6304992CDC985EE02209E0C9642@sdebe002.americas.nokia.com> Thread-Topic: [AVT] AVT meeting Slides and Summary Thread-Index: AcOi4tXJW4VK3KsQTEyk28Yoyw6ObAA25pGw To: X-OriginalArrivalTime: 05 Nov 2003 17:36:14.0751 (UTC) FILETIME=[4FB1D2F0:01C3A3C3] Content-Transfer-Encoding: quoted-printable Subject: [AVT] RTP Payload and Storage File Formats for VMR-WB Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable All, The following is a summary of the agenda item "Highlights of VMR-WB RTP = Payload and Storage Format". A new Internet Draft (ID) has recently been proposed for VMR-WB; i.e., = the new cdma2000 wideband speech codec standard.=20 Due to algorithmic similarities between VMR-WB and AMR-WB and = understanding that the two codecs are interoperable, a large part of = RFC3267 has been reused in VMR-WB payload and storage formats. It was = ensured that the reuse of the existing formats for AMR-WB has not = compromised the optimal operation of VMR-WB; given the differences = between the native systems for which the two codecs have been developed. = =20 I will provide a short presentation on 11/10/03, highlighting the = important aspects of this new ID. The outline of my presentation is as = follows: * Background on VMR-WB * Motivation for the Codec Interoperability * Interoperability with AMR-WB * Overview of VMR-WB RTP Payload Format * Overview of VMR-WB Storage File Format * Applications of VMR-WB Your feedback and comments are welcomed.=20 Regards -Sassan Ahmadi, Ph.D. Nokia Inc. USA _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 14:05:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17459 for ; Wed, 5 Nov 2003 14:05:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSxp-0004fL-4p for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 14:05:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5J59QU017936 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 14:05:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSxi-0004ej-HZ; Wed, 05 Nov 2003 14:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSxS-0004e6-Nz for avt@optimus.ietf.org; Wed, 05 Nov 2003 14:04:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17438; Wed, 5 Nov 2003 14:04:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSxQ-0000v2-00; Wed, 05 Nov 2003 14:04:44 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AHSxP-0000uu-00; Wed, 05 Nov 2003 14:04:43 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hA5J4hW13416; Wed, 5 Nov 2003 11:04:43 -0800 (PST) Message-Id: <200311051904.hA5J4hW13416@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Nov 2003 11:04:42 -0800 Subject: [AVT] RFC 3611 on RTP Control Protocol Extended Reports (RTCP XR) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3611 Title: RTP Control Protocol Extended Reports (RTCP XR) Author(s): T. Friedman, R. Caceres, A. Clark, Eds. Status: Standards Track Date: November 2003 Mailbox: timur.friedman@lip6.fr, caceres@watson.ibm.com, alan@telchemy.com Pages: 55 Characters: 126736 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtcp-report-extns-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3611.txt This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031105110307.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3611 --OtherAccess Content-Type: Message/External-body; name="rfc3611.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031105110307.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 17:50:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28240 for ; Wed, 5 Nov 2003 17:50:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWTm-0004gK-Q2 for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 17:50:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5MoMXj017992 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 17:50:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWTS-0004eT-MB; Wed, 05 Nov 2003 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWT1-0004Qu-FJ for avt@optimus.ietf.org; Wed, 05 Nov 2003 17:49:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28204 for ; Wed, 5 Nov 2003 17:49:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWSy-00056j-00 for avt@ietf.org; Wed, 05 Nov 2003 17:49:32 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AHWSx-00056B-00 for avt@ietf.org; Wed, 05 Nov 2003 17:49:32 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hA5MmxoK012169; Wed, 5 Nov 2003 15:48:59 -0700 (MST) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Date: Wed, 5 Nov 2003 15:48:59 -0700 Message-ID: Thread-Topic: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Thread-Index: AcOf8i8E3Y9dOALPRq2EPGmu6PnUfQD+NHBA From: "Jean-Francois Mule" To: "Paul E. Jones" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Paul, I did a brief review of draft 01 - glad to see updtl is not the end game for t.38 fax. Find below some comments. Hope this helps.=20 Jean-Francois. --- editorial comment In section 3, secure RTP should be named or mentioned as one of the advantages of going to t38/rtp for its overall capabilities. The concern is that the paragraph in section 3 only refers to confidentiality of fax streams (encryption) while I think that authentication is going to be as important.=20 Also consider change "an RTP" to "a RTP" -- A number of issues were raised with respect to the usage of UDPTL for the long-term, though. Specifically, there were concerns over the fact that UDPTL does not provide the same kind of statistics reporting as RTCP. Further, there are no procedures in place for encrypting the UDPTL stream. While the latter could be addressed in UDPTL, doing so would require a lot of effort and would largely be a duplication of the security work already on-going within the IETF. -- --- technical comment The section 6 (security considerations) is rather silent on the security threats.=20 Looking at the IFP packet format, I would argue that those packets do expose serious threats to the communication that you don't see in audio voice. If you insert a bad RTP packet voice payload, oh well, you may hear some garbage or clipping. With rtp/t38 fax, bad packets may cause real harm:=20 + denial of service attacks can be mounted by inserting RTP/t38 packets with hdlc-sig-end data field can simply terminate the fax control channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily create those packets. + theft of terminal identity? In some countries, faxes have more legal value that emails and the access to the rtp packet content could change the Called Subscriber ID frame (phone numbers), etc. As you well know, this info is usually not coded in RTP but in signaling protocols. I'm sure the Study Group has thought of more. Could some examples of security threats be given in the security consideration section and shouldn't this section again reference SRTP?=20 -- The IFP packets carried via RTP do not carry any particular security risks in and of themselves. However, as with other audio packets, there is the potential for unauthorized eavesdropping or manipulation of facsimile transmissions if the media stream is not properly secured. The security considerations discussed in the RTP specification [3] and any applicable RTP profile (for example, [8]) are also applicable. -- > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com]=20 > Sent: Friday, October 31, 2003 2:01 PM > To: avt@ietf.org > Subject: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward >=20 >=20 > Folks, >=20 > I would like to seek agreement from the AVT group to move the=20 > document audio/t38 document forward. As I have mentioned=20 > previously, the ITU would like to incorporate this in T.38 in=20 > an amendment to be approved in January 2004. >=20 > The motivation for transporting T.38 via RTP is probably=20 > obvious to most. In fact, I recall several saying that that=20 > is the way it should have been done from the outset. Most=20 > certainly, this will prove to be a good step in leveraging=20 > SRTP for fax to address security needs. >=20 > The document is relatively short, just seeking the MIME=20 > registration. The technical details will be specified in the=20 > ITU-T Recommendation T.38. >=20 > Can I get agreement to make this an official working group=20 > item? Can we try to get this approved by the January 2004=20 > ITU-T SG16 meeting? >=20 > Thanks, > Paul >=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 exim@www1.ietf.org Wed Nov 5 17:54:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28388 for ; Wed, 5 Nov 2003 17:54:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWXQ-0004zm-QV for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 17:54:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Ms8GK019161 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 17:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWXJ-0004t4-HC; Wed, 05 Nov 2003 17:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWX9-0004se-Nr for avt@optimus.ietf.org; Wed, 05 Nov 2003 17:53:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28332 for ; Wed, 5 Nov 2003 17:53:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWX7-0005AN-00 for avt@ietf.org; Wed, 05 Nov 2003 17:53:49 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AHWX6-0005A4-00 for avt@ietf.org; Wed, 05 Nov 2003 17:53:48 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hA5MrFoK012633; Wed, 5 Nov 2003 15:53:15 -0700 (MST) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Date: Wed, 5 Nov 2003 15:53:15 -0700 Message-ID: Thread-Topic: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Thread-Index: AcOjAZFXK4ffn0goTw6mVmTH84RhawA7Yfmg From: "Jean-Francois Mule" To: "Colin Perkins" , "Paul E. Jones" Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Colin Perkins wrote: > After discussion, Magnus and I have decided that it is not=20 > appropriate=20 > to make this an official work item of AVT, because the payload format=20 > is not being developed in AVT. We are, however, willing to review the=20 > format and recommend its publication to the IESG, assuming there is=20 > consensus from the working group that this is appropriate. This is appropriate in my opinion. I also agree with Paul that it is important to move this forward asap and facilitate the ITU meeting. > Accordingly, this message is to solicit comments from the=20 > working group=20 > on the suitability of this MIME type registration for publication=20 > (assuming a matching payload format is developed by ITU SG16). Please=20 > send comments by Monday 17th November, so we have time to co-ordinate=20 > publication schedules with the ITU, IESG and RFC Editor. Sent my comments. Jean-Francois Mule jfm@cablelabs.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 18:25:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00624 for ; Wed, 5 Nov 2003 18:25:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX1N-0004fp-GI for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 18:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NP5vW017964 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 18:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX1J-0004eP-Kt; Wed, 05 Nov 2003 18:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX17-0004e1-9z for avt@optimus.ietf.org; Wed, 05 Nov 2003 18:24:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00602 for ; Wed, 5 Nov 2003 18:24:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHX14-0005ZK-00 for avt@ietf.org; Wed, 05 Nov 2003 18:24:46 -0500 Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1AHX13-0005Z6-00 for avt@ietf.org; Wed, 05 Nov 2003 18:24:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A3F3.ECA9E64C" Date: Wed, 5 Nov 2003 15:24:13 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD6540E8F@bels002.mediator.com> Thread-Topic: Comments on draft-tseng-rtcp-streaming-extns-00.txt Thread-Index: AcOiAVpcaMLTsQwuTpebEuANl/NCPwB8Vj2gAAAE3UA= From: "Gamze Seckin" To: "Magnus Westerlund" , "IETF AVT WG" Cc: "Alan Tseng" Subject: [AVT] FW: Comments on draft-tseng-rtcp-streaming-extns-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A3F3.ECA9E64C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, please see comments inline. =20 thanks g -----Original Message----- From: Magnus Westerlund [ = mailto:magnus.westerlund@ericsson.com] Sent: Monday, November 03, 2003 3:55 AM To: Gamze Seckin Cc: Alan Tseng; IETF AVT WG Subject: Re: Comments on draft-tseng-rtcp-streaming-extns-00.txt Hi Gamze, Comments inline: Gamze Seckin wrote: > > 2. Regarding the corruption statistics. For media that uses codec that > have prediction any error normally remains for a rather long time. > However it is very difficult to determine when the effects has been > removed. Therefore this measurement is hard to derive on the receiver > side. Combined with the definition it only provides a good, possibly = bad > indication. Also looking at the reasons for corruption, the only real > reason is lost or late packets. A good feeling for the quality can be > determined by the server simply by employing packet loss vector > reporting and knowing when the buffer is empty. > > [g]packet loss is definitely a way of estimating corruption, but this > gives an algorithm in the decoder (or pre-decoder)a chance to provide > better statistics. Yes, it might be possible for such an algorithm to do this. However the measurement will not provide that much information. I think you basically can only say this is good enough or not, there will not exist any possibility to say how bad things actually are. Otherwise you will need to clearly specify how this measurement algorithm shall work. However one concern here is that the corruption measurement will be quite complex and require rather much memory to perform properly. In a video decoder it will require the measurement tool to track how the error propagates over the screen. For some audio codecs it will be impossible to determine when the error is totally removed from the loop. To do this you would need to have information about what the correct state is. [Gamze Seckin] I agree that measuring corruption is difficult and is a = best effort method.=20 However it is a useful metric to asses quality of streaming and = applications who provide this information should be encouraged to send = it.=20 > > 3. The rebuffering measurements makes more sense. However there are at > least one client that does not really perform rebuffering, namely > quicktime. Instead is assumes that if the transmitted bit-rate is > acceptable any short term effects will go away and the client will = later > have a buffer fullness given by the initial buffering delay. The > interesting thing about this measurement is that in 3GPP they already > have a way of letting the server measure when rebuffering takes place, > namely the OBSN reporting specified in TS 26.234 REL 6 (only = preliminary > versions available). > > [g] yes, and I believe those statistics are useful, however they are > tight with rate adaptation (only turned on when rate-adaptation > is enabled) and tightly coupled with other rtsp messages. Yes, they however is another way of measuring this. I think the rebuffering measure is possibly more useful then the corruption measurement. =20 [Gamze Seckin] i think we agree on the usefulness of measuring = rebuffering. > 6. Section 1. Last sentence: "As all the other report blocks > defined in [1], the streaming report blocks are applicable to > one-to-one or one-to-many applications that generate > RTCP SR or RR reports." This sentence is not really correct. The use = of > the RTCP XR reports is possible in any application sending RTCP. > > [g] himm,i am confused i thought that the first sentence covers = everything - what is left out? > So [1] needs to be updated too? What I object against is the distinction around RTCP SR or RR reports and the use of generate. I would rather formulate it as: As all the other report blocks defined in [1], the streaming report blocks are applicable to one-to-one or one-to-many applications that send RTCP in the desired direction. [Gamze Seckin] thanks - agreed.=20 > 8. Section 2, Figure 1. This figure shows this report formats = potential > need to have reporting from all layers on the receiving side. This = might > be a problem for certain application architectures. I am not saying = that > it can't be used, its only that some applications may have = difficulties > to include your reports. > > [g] we believe the statistics reported should be extensible also = should be allowed to be ignored. > So if an end side cannot support it should put simply a zero - what do = you think? I think one need to consider the meaningfulness of allowing only some of the measurement to be given. [Gamze Seckin] some metrics can be still useful without the complete = set. I believe this is an application dependent issue.=20 > 10. Section 3.3, PAge 5, first bullet after figure 2: > "- at the AVP module: Packet drop and packet errors can sometimes be > detected by incorrect or missing sequence number or checksum. " Do you > really need to consider bit-errors, the only allowed possibility for > bit-errors in RTP is if partial checksums are used. Bit-errors = surviving > to the transport layer is the meaning to be caught by the UDP, etc., > checksum. > > [g] there could be cases where bit errors are propagated (e.g. udp = lite). I think that one should be clearer about that this then. However the usage of UDP-Lite is still under a lot of discussion within the IETF. There are some very though problems for IP to accept bit-errors partially. If one are using another transport of RTP then it might be more common. I would still like you to be more clear that this might be the case if one uses such mechanisms as UDP-Lite and payload formats + codecs that accept it. [Gamze Seckin] noted. thanks,=20 g=20 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 ------_=_NextPart_001_01C3A3F3.ECA9E64C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
please=20 see comments inline.
 
thanks
g

-----Original=20 Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent:=20 Monday, November 03, 2003 3:55 AM
To: Gamze Seckin
Cc: Alan Tseng; = IETF=20 AVT WG
Subject: Re: Comments on=20 draft-tseng-rtcp-streaming-extns-00.txt


Hi = Gamze,

Comments=20 inline:

Gamze Seckin wrote:

>
> 2. Regarding the=20 corruption statistics. For media that uses codec that
> have = prediction=20 any error normally remains for a rather long time.
> However it is = very=20 difficult to determine when the effects has been
> removed. = Therefore this=20 measurement is hard to derive on the receiver
> side. Combined = with the=20 definition it only provides a good, possibly bad
> indication. = Also=20 looking at the reasons for corruption, the only real
> reason is = lost or=20 late packets. A good feeling for the quality can be
> determined = by the=20 server simply by employing packet loss vector
> reporting and = knowing when=20 the buffer is empty.
>
> [g]packet loss is definitely a way = of=20 estimating corruption, but this
 > gives an algorithm in the = decoder=20 (or pre-decoder)a chance to provide
 > better = statistics.

Yes,=20 it might be possible for such an algorithm to do this. However=20 the
measurement will not provide that much information. I think=20 you
basically can only say this is good enough or not, there will not = exist
any possibility to say how bad things actually are. Otherwise = you=20 will
need to clearly specify how this measurement algorithm shall=20 work.

However one concern here is that the corruption measurement = will=20 be
quite complex and require rather much memory to perform properly. = In=20 a
video decoder it will require the measurement tool to track how=20 the
error propagates over the screen. For some audio codecs it will=20 be
impossible to determine when the error is totally removed from the = loop.
To do this you would need to have information about what the=20 correct
state is.

[Gamze Seckin] I agree that measuring corruption is = difficult=20 and is a best effort method.
However it is a useful metric to asses quality of = streaming and=20 applications who provide this information should be encouraged to send = it.=20

>
> 3. The rebuffering measurements = makes more=20 sense. However there are at
> least one client that does not = really=20 perform rebuffering, namely
> quicktime. Instead is assumes that = if the=20 transmitted bit-rate is
> acceptable any short term effects will = go away=20 and the client will later
>   have a buffer fullness = given by=20 the initial buffering delay. The
> interesting thing about this=20 measurement is that in 3GPP they already
> have a way of letting = the=20 server measure when rebuffering takes place,
> namely the OBSN = reporting=20 specified in TS 26.234 REL 6 (only preliminary
> versions=20 available).
>
> [g] yes, and I believe those statistics are = useful,=20 however they are
 > tight with rate adaptation (only turned = on when=20 rate-adaptation
 > is enabled) and tightly coupled with other = rtsp=20 messages.

Yes, they however is another way of measuring this. I = think=20 the
rebuffering measure is possibly more useful then the=20 corruption
measurement.
 
[Gamze Seckin]  i think we agree = on the=20 usefulness of measuring rebuffering.


> 6. = Section 1.=20 Last sentence: "As all the other report blocks
> defined in [1], = the=20 streaming report blocks are applicable to
> one-to-one or = one-to-many=20 applications that generate
> RTCP SR or RR reports." This sentence = is not=20 really correct. The use of
> the RTCP XR reports is possible in = any=20 application sending RTCP.
>
> [g] himm,i am confused i = thought that=20 the first sentence covers everything - what is left out?
> So [1] = needs to=20 be updated too?

What I object against is the distinction around = RTCP SR=20 or RR reports
and the use of generate. I would rather formulate it=20 as:

As all the other report blocks defined in [1], the streaming=20 report
blocks are applicable to one-to-one or one-to-many = applications=20 that
send RTCP in the desired direction.

[Gamze=20 Seckin] thanks - agreed. 

> 8. Section = 2,=20 Figure 1. This figure shows this report formats potential
> need = to have=20 reporting from all layers on the receiving side. This might
> be a = problem=20 for certain application architectures. I am not saying that
> it = can't be=20 used, its only that some applications may have difficulties
> to = include=20 your reports.
>
> [g] we believe the statistics reported = should be=20 extensible also should be allowed to be ignored.
> So if an end = side=20 cannot support it should put simply a zero - what do you think?

I = think=20 one need to consider the meaningfulness of allowing only some of
the=20 measurement to be given.
[Gamze Seckin] some metrics can be still useful = without the=20 complete set. I believe this is an application=20 dependent issue. 

> 10. Section 3.3, = PAge 5,=20 first bullet after figure 2:
> "- at the AVP module: Packet drop = and=20 packet errors can sometimes be
> detected by incorrect or missing = sequence=20 number or checksum. " Do you
> really need to consider bit-errors, = the=20 only allowed possibility for
> bit-errors in RTP is if partial = checksums=20 are used. Bit-errors surviving
> to the transport layer is the = meaning to=20 be caught by the UDP, etc.,
> checksum.
>
> [g] there = could be=20 cases where bit errors are propagated (e.g. udp lite).

I think = that one=20 should be clearer about that this then. However the
usage of UDP-Lite = is=20 still under a lot of discussion within the IETF.
There are some very = though=20 problems for IP to accept bit-errors
partially. If one are using = another=20 transport of RTP then it might be
more common. I would still like you = to be=20 more clear that this might be
the case if one uses such mechanisms as = UDP-Lite and payload formats +
codecs that accept it.
[Gamze=20 Seckin] noted.

thanks, 
g 

Cheers

Magnus=20 Westerlund

Multimedia Technologies, Ericsson Research=20 EAB/TVA/A
------------------------------------------------------------= ----------
Ericsson=20 AB            = ;   =20 | Phone +46 8 4048287
Torshamsgatan=20 23           | = Fax  =20 +46 8 7575550
S-164 80 Stockholm, Sweden | mailto:=20 magnus.westerlund@ericsson.com

------_=_NextPart_001_01C3A3F3.ECA9E64C-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 18:30:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00900 for ; Wed, 5 Nov 2003 18:30:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX6F-000543-5d for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 18:30:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NU76u019450 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 18:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX6B-0004zO-7e; Wed, 05 Nov 2003 18:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX5w-0004yY-2S for avt@optimus.ietf.org; Wed, 05 Nov 2003 18:29:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00872 for ; Wed, 5 Nov 2003 18:29:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHX5t-0005e3-00 for avt@ietf.org; Wed, 05 Nov 2003 18:29:45 -0500 Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1AHX5s-0005dD-00 for avt@ietf.org; Wed, 05 Nov 2003 18:29:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt Date: Wed, 5 Nov 2003 15:29:14 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD65411D1@bels002.mediator.com> Thread-Topic: Comments on draft-tseng-rtcp-streaming-extns-00.txt Thread-Index: AcOeOCAZztdgQZ7JSbyWZW3X3Dc/xwBpqOjAAQVeaBA= From: "Gamze Seckin" To: "Magnus Westerlund" , "Alan Tseng" Cc: "IETF AVT WG" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Magnus, about your comment "7. Section 2, You talk about AVP, but this extension is not dependent = on=20 any special profile and seems to be compatible with any of the four=20 available or under development profiles that exist." Do you also mean AVPF? Since I am confused about the relationship = between AVPF and RFC3611. thx g -----Original Message----- From: Gamze Seckin=20 Sent: Friday, October 31, 2003 11:08 AM To: Magnus Westerlund; Alan Tseng Cc: IETF AVT WG Subject: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt Hi Magnus,=20 thanks for the comments. See my response inline. best regards gamze -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday, October 29, 2003 8:17 AM To: Alan Tseng; Gamze Seckin Cc: IETF AVT WG Subject: Comments on draft-tseng-rtcp-streaming-extns-00.txt Hi, Here is my comments on your draft: 1. First I think the draft isn't very clear on why any metrics are=20 needed. In the 3GPP document it only states: "The objective of the=20 streaming service quality metrics is to offer to the service providers=20 means to evaluate the end user experience.". This doesn't make it very=20 clear what the real needs are. I think further developing of this is=20 needed. [g]you are right, the draft does not talk about that clearly. We should = add that. 2. Regarding the corruption statistics. For media that uses codec that=20 have prediction any error normally remains for a rather long time.=20 However it is very difficult to determine when the effects has been=20 removed. Therefore this measurement is hard to derive on the receiver=20 side. Combined with the definition it only provides a good, possibly bad = indication. Also looking at the reasons for corruption, the only real=20 reason is lost or late packets. A good feeling for the quality can be=20 determined by the server simply by employing packet loss vector=20 reporting and knowing when the buffer is empty. [g]packet loss is definitely a way of estimating corruption, but this = gives an algorithm in the decoder (or pre-decoder)a chance to provide = better statistics. 3. The rebuffering measurements makes more sense. However there are at=20 least one client that does not really perform rebuffering, namely=20 quicktime. Instead is assumes that if the transmitted bit-rate is=20 acceptable any short term effects will go away and the client will later = have a buffer fullness given by the initial buffering delay. The=20 interesting thing about this measurement is that in 3GPP they already=20 have a way of letting the server measure when rebuffering takes place,=20 namely the OBSN reporting specified in TS 26.234 REL 6 (only preliminary = versions available). [g] yes, and I believe those statistics are useful, however they are = tight with rate adaptation (only turned on when rate-adaptation is = enabled) and tightly coupled with other rtsp messages. 4. As state privately before this drafts need to be checked against the=20 ID nits: http://www.ietf.org/ID-nits.html [g] yes, we should definitely do that thanks. 5. Section 1. The introduction is basically the same as the=20 introduction. I would recommend you to write a better more informative=20 introduction. [g] agreed. 6. Section 1. Last sentence: "As all the other report blocks defined in [1], the streaming report blocks are applicable to one-to-one or one-to-many applications that generate RTCP SR or RR reports." This sentence is not really correct. The use of=20 the RTCP XR reports is possible in any application sending RTCP. [g] himm,i am confused i thought that the first sentence covers = everything - what is left out?=20 So [1] needs to be updated too? 7. Section 2, You talk about AVP, but this extension is not dependent on = any special profile and seems to be compatible with any of the four=20 available or under development profiles that exist. [g] agreed. 8. Section 2, Figure 1. This figure shows this report formats potential=20 need to have reporting from all layers on the receiving side. This might = be a problem for certain application architectures. I am not saying that = it can't be used, its only that some applications may have difficulties=20 to include your reports. [g] we believe the statistics reported should be extensible also should = be allowed to be ignored.=20 So if an end side cannot support it should put simply a zero - what do = you think? 9. Section 3.1, first paragraph: "All timestamps reported by the XR=20 packet SHALL be RTP timestamps. All durations SHALL be in units of the=20 RTP timebase." This definition is not clear, because in applications=20 allowing for switching between payload types the rate can change. I=20 think that the intention of using the RTP timestamp value for indication = over what interval which the report covers is a good one. However some=20 more consideration over formulation must be done. [g] valid point - I guess we need to think more about the corner cases. 10. Section 3.3, PAge 5, first bullet after figure 2: "- at the AVP module: Packet drop and packet errors can sometimes be detected by incorrect or missing sequence number or checksum. " Do you=20 really need to consider bit-errors, the only allowed possibility for=20 bit-errors in RTP is if partial checksums are used. Bit-errors surviving = to the transport layer is the meaning to be caught by the UDP, etc.,=20 checksum. [g] there could be cases where bit errors are propagated (e.g. udp = lite). 11. Section 6. The streaming metrics should probably have a value to=20 combine with the parameter to indicate how often the report block should = be included. This seem to be a block that is not needed very often. [g] valid point, note taken. 12. Section 8. The security section does not look sufficient. I guess=20 that the consideration for this is rather similar to the VoIP block.=20 However I think there should be made some effort to indicate the main=20 security concerns also in this document. [g] agreed. 13. Section 12. The references need to be divided into Normative and=20 Informative ones. [g] agreed. 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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 19:04:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02262 for ; Wed, 5 Nov 2003 19:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXd9-0000T9-AS for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 19:04:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6047sd001766 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 19:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXd4-0000RI-6F; Wed, 05 Nov 2003 19:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXcf-0000QQ-Aq for avt@optimus.ietf.org; Wed, 05 Nov 2003 19:03:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02231 for ; Wed, 5 Nov 2003 19:03:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXcb-0006D3-00 for avt@ietf.org; Wed, 05 Nov 2003 19:03:33 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AHXcb-0006D0-00 for avt@ietf.org; Wed, 05 Nov 2003 19:03:33 -0500 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hA603SBQ017460; Wed, 5 Nov 2003 19:03:29 -0500 Message-ID: <036501c3a3f9$3af7d310$48bc47ab@cisco.com> From: "Paul E. Jones" To: "Jean-Francois Mule" , References: Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Date: Wed, 5 Nov 2003 19:02:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jean-Francois, It has been a long time! Hope you're doing well... Comments below: > --- editorial comment > In section 3, secure RTP should be named or mentioned as one of the > advantages of going to t38/rtp for its overall capabilities. The concern > is that the paragraph in section 3 only refers to confidentiality of fax > streams (encryption) while I think that authentication is going to be as > important. I purposely did not address SRTP, because this brings in a different RTP profile (SAVP) and I've not fully studied what (if anything) needs to be done to use that profile. Further, SRTP is still in draft form. I really don't want to have interdependencies. If SRTP can be used without any textual changes to this document, then is begs the question as to whether anything needs to be said. If textual changes are required here OR to T.38, then it strongly suggests we need to address it separately. Advise welcome, but please keep in mind that Q11/16 would like to have this MIME registration before the Jan 2004 meeting of SG16. > Also consider change "an RTP" to "a RTP" This is the most interesting request I've seen. Doing a Google search, I see 18K pages with "an RTP" and 13K pages with "a RTP". Which is correct? It looks right to see "a RTP", but it just doesn't "sound" right. Spelling out RTP, I'd agree with "a Real..." > -- > A number of issues were raised with respect to the usage of UDPTL for > the long-term, though. Specifically, there were concerns over the > fact that UDPTL does not provide the same kind of statistics > reporting as RTCP. Further, there are no procedures in place for > encrypting the UDPTL stream. While the latter could be addressed in > UDPTL, doing so would require a lot of effort and would largely be a > duplication of the security work already on-going within the IETF. > -- What was the specifc change you want made above? Just calling out the "an RTP"? > > --- technical comment > The section 6 (security considerations) is rather silent on the security > threats. > Looking at the IFP packet format, I would argue that those packets do > expose serious threats to the communication that you don't see in audio > voice. If you insert a bad RTP packet voice payload, oh well, you may > hear some garbage or clipping. With rtp/t38 fax, bad packets may cause > real harm: > + denial of service attacks can be mounted by inserting RTP/t38 packets > with hdlc-sig-end data field can simply terminate the fax control > channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily create those > packets. > + theft of terminal identity? In some countries, faxes have more legal > value that emails and the access to the rtp packet content could change > the Called Subscriber ID frame (phone numbers), etc. As you well know, > this info is usually not coded in RTP but in signaling protocols. > > I'm sure the Study Group has thought of more. Could some examples of > security threats be given in the security consideration section and > shouldn't this section again reference SRTP? These are both valid points. I fully support the addition of some text that highlights this fact. I would not want to call these out explicitly, necessarily, as there may be other places (e.g., modification or injection of NSF data, etc.), so I think it's reasonable to speak to this generically. Would you like to suggest some text? I'd be happy to incorporate it. Paul > -- > The IFP packets carried via RTP do not carry any particular security > risks in and of themselves. However, as with other audio packets, > there is the potential for unauthorized eavesdropping or manipulation > of facsimile transmissions if the media stream is not properly > secured. > > The security considerations discussed in the RTP specification [3] > and any applicable RTP profile (for example, [8]) are also > applicable. > -- > > > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Friday, October 31, 2003 2:01 PM > > To: avt@ietf.org > > Subject: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward > > > > > > Folks, > > > > I would like to seek agreement from the AVT group to move the > > document audio/t38 document forward. As I have mentioned > > previously, the ITU would like to incorporate this in T.38 in > > an amendment to be approved in January 2004. > > > > The motivation for transporting T.38 via RTP is probably > > obvious to most. In fact, I recall several saying that that > > is the way it should have been done from the outset. Most > > certainly, this will prove to be a good step in leveraging > > SRTP for fax to address security needs. > > > > The document is relatively short, just seeking the MIME > > registration. The technical details will be specified in the > > ITU-T Recommendation T.38. > > > > Can I get agreement to make this an official working group > > item? Can we try to get this approved by the January 2004 > > ITU-T SG16 meeting? > > > > Thanks, > > Paul > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Wed Nov 5 19:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02263 for ; Wed, 5 Nov 2003 19:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXd9-0000Tm-DP for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 19:04:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6047ru001768 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 19:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXd3-0000R2-FC; Wed, 05 Nov 2003 19:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXcX-0000QL-Fy for avt@optimus.ietf.org; Wed, 05 Nov 2003 19:03:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02228 for ; Wed, 5 Nov 2003 19:03:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXcU-0006Cw-00 for avt@ietf.org; Wed, 05 Nov 2003 19:03:26 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AHXcT-0006Cb-00 for avt@ietf.org; Wed, 05 Nov 2003 19:03:25 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61947 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AHXbz-0005SC-00; Thu, 06 Nov 2003 00:02:55 +0000 Date: Thu, 6 Nov 2003 00:02:53 +0000 Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-ilbc-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alan Duric To: avt@ietf.org From: Colin Perkins In-Reply-To: <200310282023.PAA22543@ietf.org> Message-Id: <91466570-0FEC-11D8-8A82-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, Oct 28, 2003, at 20:23 Europe/London, 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 Payload Format for iLBC Speech > Author(s) : A. Duric, S. Andersen > Filename : draft-ietf-avt-rtp-ilbc-03.txt > Pages : 12 > Date : 2003-10-28 > > This document describes the RTP payload format for the internet Low > Bit Rate Coder (iLBC) Speech [1] developed by Global IP Sound > (GIPS). Also, within the document there are included necessary > details for the use of iLBC with MIME and SDP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ilbc-03.txt I have a few minor comments - almost all editorial - on this version: - Note that the codec has changed again? One extra bit for each frame size, replacing a previously unused but with an empty frame indicator. Is the bitstream now stable? - The abstract cannot contain citations - Section 2: Please remove the word "freeware" from the codec description. I expect this falls foul of RFC 2026 section 10.3.2 (b), and it will be easier if all the IPR discussion is left to the codec draft. - Section 2: when discussing how the codec bitstream is packed into an octet sequence, why SHOULD not MUST? - Section 3: spelling mistake: "bellow" -> "below" - Section 3: "No addition header specific to this payload format" -> "No additional header..." - Section 3: The packet format diagram needs to be a numbered figure, with caption. - As mentioned previously, the comment about CableLabs intending to adopt iLBC as their standard is not appropriate in the payload format. It's not appropriate for us to publish a standard saying what another standards body may do in future. - A few formatting nits: Bad chars at 356 Bad chars at 357 Bad chars at 477 Bad chars at 478 Bad chars at 529 draft-ietf-avt-rtp-ilbc-03.txt: 5 lines containing non-US-ASCII characters - think these are all Microsoft "smart" quotes. draft-ietf-avt-rtp-ilbc-03.txt: 12 formfeeds not on a line by themselves - Shouldn't the mode parameter allow "30" as a legal value? Doesn't hurt to be explicit... Also missing a close ")" in this paragraph too. Cheers, -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 19:27:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02874 for ; Wed, 5 Nov 2003 19:27:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXzL-00025m-Of for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 19:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA60R3S8008011 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 19:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXzK-000250-Me; Wed, 05 Nov 2003 19:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXzH-00024k-DQ for avt@optimus.ietf.org; Wed, 05 Nov 2003 19:26:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02860 for ; Wed, 5 Nov 2003 19:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXzF-0006V8-00 for avt@ietf.org; Wed, 05 Nov 2003 19:26:57 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AHXzF-0006UK-00 for avt@ietf.org; Wed, 05 Nov 2003 19:26:57 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62321 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AHXyl-0005Tm-00; Thu, 06 Nov 2003 00:26:27 +0000 Date: Thu, 6 Nov 2003 00:26:25 +0000 Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Jean-Francois Mule" , To: "Paul E. Jones" From: Colin Perkins In-Reply-To: <036501c3a3f9$3af7d310$48bc47ab@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, Nov 6, 2003, at 00:02 Europe/London, Paul E. Jones wrote: ... >> Also consider change "an RTP" to "a RTP" > > This is the most interesting request I've seen. Doing a Google > search, I > see 18K pages with "an RTP" and 13K pages with "a RTP". Which is > correct? > It looks right to see "a RTP", but it just doesn't "sound" right. > Spelling > out RTP, I'd agree with "a Real..." http://www.google.com/search?q=%22a+or+an%22 Cheers, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 19:51:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03492 for ; Wed, 5 Nov 2003 19:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYMZ-0003oG-9V for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 19:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA60p3q4014611 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 19:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYMY-0003nU-Cr; Wed, 05 Nov 2003 19:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYLe-0003me-OC for avt@optimus.ietf.org; Wed, 05 Nov 2003 19:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03455 for ; Wed, 5 Nov 2003 19:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHYLc-0006mR-00 for avt@ietf.org; Wed, 05 Nov 2003 19:50:04 -0500 Received: from ip72.usw4.rb1.bel.nwlink.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1AHYLc-0006m6-00 for avt@ietf.org; Wed, 05 Nov 2003 19:50:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Nov 2003 16:49:33 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD6540E90@bels002.mediator.com> Thread-Topic: Comments on draft-tseng-rtcp-streaming-extns-00.txt Thread-Index: AcOeOCAZztdgQZ7JSbyWZW3X3Dc/xwBpqOjAAQVeaBAAAlbnIA== From: "Gamze Seckin" To: "IETF AVT WG" , "Alan Tseng" Content-Transfer-Encoding: quoted-printable Subject: [AVT] Summary of discussion items for draft-tseng-rtcp-streaming-extns-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, During IETF 58 in Minneapolis we would like to discuss the following = issues wrt draft-tseng-rtcp-streaming-extns-00.txt: - review objectives and motivations for streaming rtcp reports - review parameter types and packet format - we would like to also get comments on issues such as: * RTP timestamp usage * relationship to AVPF * reporting frequency * security concerns =09 your comments are appreciated, best regards, g ____________________________ Gamze Seckin, Ph.D. Vidiator Technology (US) Inc. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 5 20:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04385 for ; Wed, 5 Nov 2003 20:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYqd-0005eK-8Y for avt-archive@odin.ietf.org; Wed, 05 Nov 2003 20:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA61M7hl021686 for avt-archive@odin.ietf.org; Wed, 5 Nov 2003 20:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYqW-0005ck-QK; Wed, 05 Nov 2003 20:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHYpd-0005Z7-HL for avt@optimus.ietf.org; Wed, 05 Nov 2003 20:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04352 for ; Wed, 5 Nov 2003 20:20:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHYpb-0007Db-00 for avt@ietf.org; Wed, 05 Nov 2003 20:21:03 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AHYpa-0007DY-00 for avt@ietf.org; Wed, 05 Nov 2003 20:21:02 -0500 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hA61KvBQ017708; Wed, 5 Nov 2003 20:20:58 -0500 Message-ID: <000901c3a404$0de239a0$48bc47ab@cisco.com> From: "Paul E. Jones" To: "Colin Perkins" Cc: "Jean-Francois Mule" , References: Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Date: Wed, 5 Nov 2003 20:19:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Based on what I could find, the use of "an" or "a" is based on sound, not spelling. Thus, "an RTP" is right... but who can trust these documents on the web? ;-) pj ----- Original Message ----- From: "Colin Perkins" To: "Paul E. Jones" Cc: "Jean-Francois Mule" ; Sent: Wednesday, November 05, 2003 7:26 PM Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward > On Thursday, Nov 6, 2003, at 00:02 Europe/London, Paul E. Jones wrote: > ... > >> Also consider change "an RTP" to "a RTP" > > > > This is the most interesting request I've seen. Doing a Google > > search, I > > see 18K pages with "an RTP" and 13K pages with "a RTP". Which is > > correct? > > It looks right to see "a RTP", but it just doesn't "sound" right. > > Spelling > > out RTP, I'd agree with "a Real..." > > http://www.google.com/search?q=%22a+or+an%22 > > Cheers, > Colin > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 6 02:43:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27308 for ; Thu, 6 Nov 2003 02:43:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHen1-0002Cl-Nq for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 02:42:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA67gl1m008469 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 02:42:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHemH-00026P-So; Thu, 06 Nov 2003 02:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHelp-00022f-K0 for avt@optimus.ietf.org; Thu, 06 Nov 2003 02:41:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27276 for ; Thu, 6 Nov 2003 02:41:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHell-0004Av-00 for avt@ietf.org; Thu, 06 Nov 2003 02:41:29 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AHell-0004As-00 for avt@ietf.org; Thu, 06 Nov 2003 02:41:29 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hA67fTSs024049; Thu, 6 Nov 2003 08:41:30 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHXBN222; Thu, 6 Nov 2003 08:41:36 +0100 Message-ID: <3FA9FB1C.9080600@ericsson.com> Date: Thu, 06 Nov 2003 08:41:16 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gamze Seckin CC: Alan Tseng , IETF AVT WG Subject: Re: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt References: <787ED0EC136B854DB341E7662D666CD65411D1@bels002.mediator.com> In-Reply-To: <787ED0EC136B854DB341E7662D666CD65411D1@bels002.mediator.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Gamze, To my knowledge there is no profile dependencies in RFC 3611. Thus it can be used for any of the four profiles defined or under definition. My comment was to point out this fact and that it seems inappropriate to talk about any special profile in this context. cheers Magnus Gamze Seckin wrote: > Hi Magnus, > > about your comment > "7. Section 2, You talk about AVP, but this extension is not dependent on > any special profile and seems to be compatible with any of the four > available or under development profiles that exist." > > Do you also mean AVPF? Since I am confused about the relationship between AVPF and RFC3611. > > thx > g > -----Original Message----- > From: Gamze Seckin > Sent: Friday, October 31, 2003 11:08 AM > To: Magnus Westerlund; Alan Tseng > Cc: IETF AVT WG > Subject: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt > > > > Hi Magnus, > thanks for the comments. > See my response inline. > > best regards > gamze > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, October 29, 2003 8:17 AM > To: Alan Tseng; Gamze Seckin > Cc: IETF AVT WG > Subject: Comments on draft-tseng-rtcp-streaming-extns-00.txt > > > Hi, > > Here is my comments on your draft: > > 1. First I think the draft isn't very clear on why any metrics are > needed. In the 3GPP document it only states: "The objective of the > streaming service quality metrics is to offer to the service providers > means to evaluate the end user experience.". This doesn't make it very > clear what the real needs are. I think further developing of this is > needed. > > [g]you are right, the draft does not talk about that clearly. We should add that. > > 2. Regarding the corruption statistics. For media that uses codec that > have prediction any error normally remains for a rather long time. > However it is very difficult to determine when the effects has been > removed. Therefore this measurement is hard to derive on the receiver > side. Combined with the definition it only provides a good, possibly bad > indication. Also looking at the reasons for corruption, the only real > reason is lost or late packets. A good feeling for the quality can be > determined by the server simply by employing packet loss vector > reporting and knowing when the buffer is empty. > > [g]packet loss is definitely a way of estimating corruption, but this gives an algorithm in the decoder (or pre-decoder)a chance to provide better statistics. > > 3. The rebuffering measurements makes more sense. However there are at > least one client that does not really perform rebuffering, namely > quicktime. Instead is assumes that if the transmitted bit-rate is > acceptable any short term effects will go away and the client will later > have a buffer fullness given by the initial buffering delay. The > interesting thing about this measurement is that in 3GPP they already > have a way of letting the server measure when rebuffering takes place, > namely the OBSN reporting specified in TS 26.234 REL 6 (only preliminary > versions available). > > [g] yes, and I believe those statistics are useful, however they are tight with rate adaptation (only turned on when rate-adaptation is enabled) and tightly coupled with other rtsp messages. > > 4. As state privately before this drafts need to be checked against the > ID nits: http://www.ietf.org/ID-nits.html > > [g] yes, we should definitely do that thanks. > > 5. Section 1. The introduction is basically the same as the > introduction. I would recommend you to write a better more informative > introduction. > > [g] agreed. > > 6. Section 1. Last sentence: "As all the other report blocks > defined in [1], the streaming report blocks are applicable to > one-to-one or one-to-many applications that generate > RTCP SR or RR reports." This sentence is not really correct. The use of > the RTCP XR reports is possible in any application sending RTCP. > > [g] himm,i am confused i thought that the first sentence covers everything - what is left out? > So [1] needs to be updated too? > > 7. Section 2, You talk about AVP, but this extension is not dependent on > any special profile and seems to be compatible with any of the four > available or under development profiles that exist. > > [g] agreed. > > 8. Section 2, Figure 1. This figure shows this report formats potential > need to have reporting from all layers on the receiving side. This might > be a problem for certain application architectures. I am not saying that > it can't be used, its only that some applications may have difficulties > to include your reports. > > [g] we believe the statistics reported should be extensible also should be allowed to be ignored. > So if an end side cannot support it should put simply a zero - what do you think? > > 9. Section 3.1, first paragraph: "All timestamps reported by the XR > packet SHALL be RTP timestamps. All durations SHALL be in units of the > RTP timebase." This definition is not clear, because in applications > allowing for switching between payload types the rate can change. I > think that the intention of using the RTP timestamp value for indication > over what interval which the report covers is a good one. However some > more consideration over formulation must be done. > > [g] valid point - I guess we need to think more about the corner cases. > > 10. Section 3.3, PAge 5, first bullet after figure 2: > "- at the AVP module: Packet drop and packet errors can sometimes be > detected by incorrect or missing sequence number or checksum. " Do you > really need to consider bit-errors, the only allowed possibility for > bit-errors in RTP is if partial checksums are used. Bit-errors surviving > to the transport layer is the meaning to be caught by the UDP, etc., > checksum. > > [g] there could be cases where bit errors are propagated (e.g. udp lite). > > 11. Section 6. The streaming metrics should probably have a value to > combine with the parameter to indicate how often the report block should > be included. This seem to be a block that is not needed very often. > > [g] valid point, note taken. > > 12. Section 8. The security section does not look sufficient. I guess > that the consideration for this is rather similar to the VoIP block. > However I think there should be made some effort to indicate the main > security concerns also in this document. > > [g] agreed. > > 13. Section 12. The references need to be divided into Normative and > Informative ones. > > [g] agreed. > > 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 > -- 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 exim@www1.ietf.org Thu Nov 6 11:22:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16496 for ; Thu, 6 Nov 2003 11:22:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmtY-0000xx-68 for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 11:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6GM4Me003683 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 11:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmtV-0000xA-A3; Thu, 06 Nov 2003 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmtR-0000wt-OL for avt@optimus.ietf.org; Thu, 06 Nov 2003 11:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16458 for ; Thu, 6 Nov 2003 11:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmtP-0003Yd-00 for avt@ietf.org; Thu, 06 Nov 2003 11:21:55 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AHmtO-0003Y0-00 for avt@ietf.org; Thu, 06 Nov 2003 11:21:54 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA6GLM824830; Thu, 6 Nov 2003 11:21:22 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VRTPGYCH; Thu, 6 Nov 2003 11:21:23 -0500 Received: from nortelnetworks.com (acart1h5.ca.nortel.com [47.129.129.213]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NK50; Thu, 6 Nov 2003 11:21:22 -0500 Message-ID: <3FAA7500.5030300@nortelnetworks.com> Date: Thu, 06 Nov 2003 11:21:20 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org, hgs@cs.columbia.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Review comments on draft-ietf-avt-rfc2833bis-03.txt (part 1) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I made a bunch of comments, most of them editorial, on 2833bis last August. You'll be pleased to know that I am passing the remainder of my editorial comments to Henning offline. However, I had a couple of technical comments buried in my earlier message that I will repeat here: Section 3.5, description of duration field: If a softstate duration expires without refresh, what should the receiver do? I would suggest adding words to the effect that if a soft state expires, the receiver SHOULD consider the state to be "unknown". Flash event: can keep the same coding, but should be moved from Table 2 to Table 5, along with the note that Flash can happen only when the state is "offhook". Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 6 13:36:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22070 for ; Thu, 6 Nov 2003 13:36:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHozL-0000DI-Lj for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 13:36:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6IaB4a000819 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 13:36:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHozC-0000Cz-PN; Thu, 06 Nov 2003 13:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoyj-0000Bo-T4 for avt@optimus.ietf.org; Thu, 06 Nov 2003 13:35:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22003 for ; Thu, 6 Nov 2003 13:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoyh-0005Y8-00 for avt@ietf.org; Thu, 06 Nov 2003 13:35:31 -0500 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx with esmtp (Exim 4.12) id 1AHoyg-0005XL-00 for avt@ietf.org; Thu, 06 Nov 2003 13:35:31 -0500 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id hA6IXqrY013191 for ; Thu, 6 Nov 2003 10:33:52 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 6 Nov 2003 10:33:17 -0800 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id hA6IXI0n010322; Thu, 6 Nov 2003 10:33:19 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <005201c39a2f$38102b30$05640a0a@panasonic.de> References: <005201c39a2f$38102b30$05640a0a@panasonic.de> Date: Thu, 6 Nov 2003 10:33:35 -0800 To: rey@panasonic.de, "'Magnus Westerlund'" From: Dave Singer Cc: "'IETF AVT WG'" , "Jan van der Meer (E-mail)" , "Yoshinori Matsui (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [AVT] RE: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I am not attending MPS so I'm going to give my comments here. I hope they're helpful. My comments on the draft are in roughly three buckets: (a) whether we should have it at all (b) the overall nature of the draft, (c) detailed comments and (d) where to go. (a) Do we want it at all? I think yes, for the following reasons. Ideally, we see an authoring language from w3c, for which there is a similarly powerful RTP expression, and that these are supersets of the 3GPP format. But the ideal is unlikely. For a start, the w3c format is designed to be able to express things as diverse as 3GPP and EIA sub-titling. It is unlikely that any given delivery system will be able to carry everything that can be expressed in the w3c format; profiles will be needed for different delivery environments. A generic timed text format, which would need to cover captioning (both for hearing disabled and for language, which are different), displayed timed text (e.g. titling), karaoke, ticker tapes, and so on. Having participated in the w3c discussions so far, I am realizing how broad this question is. This is akin to searching for a generic 'video' payload format, or, dare I say it, a generic MPEG-4 format! Secondly, I don't see a reason why text (which is a data type) shouldn't be treated like video. That is, different ways to express ('compress') the text are conveyed in different 'codecs' and different payload formats. We tried a fairly general-purpose format in the MPEG-4 'simple' draft and it was not pleasant. Targetted formats for well-defined coding systems work better. So, I am not convinced that a targetted 3GPP timed text format is 'wrong'. As long as we admit that there may (will) be a family of text presentation formats (like audio and video), it is not a problem, either. (b) Overall comments. The 3GPP timed text spec is conceptually pretty simple; this payload format seems pretty complex. There are several bit-fields, for example. It uses two payload type indicators. I think that we can use one payload type indicator, and one header which tells us (i) is the 'static information' present? (ii) is this a single fragment or a set of whole samples? (iii) what are the various offsets etc. I get the idea of giving the explicit offset to the start of a box, and also the need to 'place' a fragment in the string, and so on. I'm just aware that it comes across complex as is, and wonder if we can't skin it slightly differently -- possibly at the expense of a few bytes for unusual cases -- for a simpler spec. I'm willing to spend time in this direction if there is consensus that such an exploration take place. (c) Details. I have a number of detailed comments: things talked about before they are defined (e.g. T=1 in 4.1); what is the SIDX field for? and so on. However, I'd rather see us work out the direction in general (a) and the approach (b) before dealing with details. (d) Where to go. I think we should proceed with this. Though it is not on the table for release 6 of 3GPP officially, no-one there will object if text becomes streamable: it's a useful good idea. I don't think the W3C work is either going to complete soon, or be a direct translation into an RTP format, and that's the only 'bigger' idea on the horizon. And I don't think this should be shoe-horned into the MPEG-4 payload format either; it has unique needs (and it ought to be possible to make it simpler). A liaison or communication from the chairs to 3GPP and W3C saying what the Minneapolis meeting thinks is the direction would be prudent and courteous, however. -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 6 13:44:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22572 for ; Thu, 6 Nov 2003 13:44:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHp6w-0000rY-6B for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 13:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Ii2ud003271 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 13:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHp6v-0000qD-FQ; Thu, 06 Nov 2003 13:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHp6R-0000pI-VQ for avt@optimus.ietf.org; Thu, 06 Nov 2003 13:43:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22405 for ; Thu, 6 Nov 2003 13:43:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHp6P-0005hF-00 for avt@ietf.org; Thu, 06 Nov 2003 13:43:29 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AHp6O-0005fV-00 for avt@ietf.org; Thu, 06 Nov 2003 13:43:28 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hA6IgtoK028332; Thu, 6 Nov 2003 11:42:55 -0700 (MST) 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] Moving draft-jones-avt-audio-t38-01.txt forward Date: Thu, 6 Nov 2003 11:42:54 -0700 Message-ID: Thread-Topic: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Thread-Index: AcOkBD5komhnocTTQKCQtoVJurOxwwAkUBLA From: "Jean-Francois Mule" To: "Paul E. Jones" , "Colin Perkins" Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Yes, you're right, forget my french and my comment... I have been misled, it is "an RTP". > The "Oxford Companion to the English Language" says, "...the=20 > use of "a"=20 > or "an" indicates whether a writer is thinking of them as=20 > letters or words". >=20 > Less ambiguously, "A Modern Guide to English Usage" says "The test is=20 > how people say or read such designations", and it gives the=20 > example of "an MA degree" as being proper. Thx, Jean-Fran=E7ois=20 > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com]=20 > Sent: Wednesday, November 05, 2003 6:20 PM > To: Colin Perkins > Cc: Jean-Francois Mule; avt@ietf.org > Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward >=20 >=20 > Based on what I could find, the use of "an" or "a" is based=20 > on sound, not spelling. Thus, "an RTP" is right... but who=20 > can trust these documents on the web? ;-) >=20 > pj >=20 > ----- Original Message -----=20 > From: "Colin Perkins" > To: "Paul E. Jones" > Cc: "Jean-Francois Mule" ; > Sent: Wednesday, November 05, 2003 7:26 PM > Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward >=20 >=20 > > On Thursday, Nov 6, 2003, at 00:02 Europe/London, Paul E.=20 > Jones wrote:=20 > > ... > > >> Also consider change "an RTP" to "a RTP" > > > > > > This is the most interesting request I've seen. Doing a Google=20 > > > search, I see 18K pages with "an RTP" and 13K pages with=20 > "a RTP". =20 > > > Which is correct? > > > It looks right to see "a RTP", but it just doesn't "sound" right. > > > Spelling > > > out RTP, I'd agree with "a Real..." > > > > http://www.google.com/search?q=3D%22a+or+an%22 > > > > Cheers, > > Colin > > >=20 >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 6 13:45:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22598 for ; Thu, 6 Nov 2003 13:45:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHp7v-0000yj-Bl for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 13:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Ij39Z003686 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 13:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHp7u-0000vD-Fi; Thu, 06 Nov 2003 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHp7A-0000uD-1a for avt@optimus.ietf.org; Thu, 06 Nov 2003 13:44:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22553 for ; Thu, 6 Nov 2003 13:44:03 -0500 (EST) From: sassan.ahmadi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHp77-0005kD-00 for avt@ietf.org; Thu, 06 Nov 2003 13:44:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHp77-0005k7-00 for avt@ietf.org; Thu, 06 Nov 2003 13:44:13 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA6IiAY21462 for ; Thu, 6 Nov 2003 20:44:11 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Nov 2003 20:44:10 +0200 Received: from sdebe002.NOE.Nokia.com ([172.19.201.138]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 12:44:00 -0600 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, 6 Nov 2003 10:43:59 -0800 Message-ID: <0B08EA1BF5F6304992CDC985EE02209E0C9643@sdebe002.americas.nokia.com> Thread-Topic: Comments on draft-tseng-rtcp-streaming-extns-00.txt Thread-Index: AcOeOCAZztdgQZ7JSbyWZW3X3Dc/xwBpqOjAAQVeaBAAAlbnIAAi+ntA To: X-OriginalArrivalTime: 06 Nov 2003 18:44:00.0564 (UTC) FILETIME=[F1856740:01C3A495] Content-Transfer-Encoding: quoted-printable Subject: [AVT] Summary of discussion items for draft-ahmadi-avt-rtp-vmr-wb-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable All, During the 58th IETF meetings in Minneapolis we would like to discuss = the following issues wrt draft-ahmadi-avt-rtp-vmr-wb-00.txt: -Background on VMR-WB -Similarities and differences with RFC3267 -Highlights of the proposed draft Given the large amount of similarities (reuse) between this internet = draft and RFC3267, I hope that AVT WG can focus mostly on the new items = and hopefully accelerate the development of a RFC for VMR-WB. Therefore, I would like to ask AVT WG to adopt this draft as WG work = item (document) to help faster completion of a RFC for VMR-WB. Your help and feedback/comments are greatly appreciated. Regards -Sassan Ahmadi, Ph.D. VMR-WB Project Manager Nokia Inc. USA=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 6 13:53:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22777 for ; Thu, 6 Nov 2003 13:53:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpFg-0001Ix-OA for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 13:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Ir4HL004999 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 13:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpFd-0001I5-MH; Thu, 06 Nov 2003 13:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpEi-0001GK-4t for avt@optimus.ietf.org; Thu, 06 Nov 2003 13:52:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22753 for ; Thu, 6 Nov 2003 13:51:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpEf-0005oX-00 for avt@ietf.org; Thu, 06 Nov 2003 13:52:01 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AHpEf-0005oC-00 for avt@ietf.org; Thu, 06 Nov 2003 13:52:01 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id hA6IpToK029529; Thu, 6 Nov 2003 11:51:29 -0700 (MST) 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] Moving draft-jones-avt-audio-t38-01.txt forward Date: Thu, 6 Nov 2003 11:51:29 -0700 Message-ID: Thread-Topic: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Thread-Index: AcOj+Wu4J1/mYjmHRs2Tnj1Hij6XWwAnHRRQ From: "Jean-Francois Mule" To: "Paul E. Jones" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Paul wrote: > I purposely did not address SRTP, because this brings in a=20 > different RTP profile (SAVP) and I've not fully studied what=20 > (if anything) needs to be done to use that profile. Further,=20 > SRTP is still in draft form. I really don't want to have=20 > interdependencies. I'll let other folks comment on whether it is appropriate to not address = the draft's connections with SRTP. > > -- > > A number of issues were raised with respect to the usage of=20 > UDPTL for > > the long-term, though. Specifically, there were=20 > concerns over the > > fact that UDPTL does not provide the same kind of statistics > > reporting as RTCP. Further, there are no procedures in place for > > encrypting the UDPTL stream. While the latter could be=20 > addressed in > > UDPTL, doing so would require a lot of effort and would=20 > largely be a > > duplication of the security work already on-going within=20 > the IETF. > > -- >=20 > What was the specifc change you want made above? Just=20 > calling out the "an RTP"? How about something like: s/encrypting the UDPTL stream/authenticating or encrypting the UDPTL = stream > > --- technical comment > > The section 6 (security considerations) is rather silent on the=20 > > security threats. Looking at the IFP packet format, I would=20 > argue that=20 > > those packets do expose serious threats to the=20 > communication that you=20 > > don't see in audio voice. If you insert a bad RTP packet voice=20 > > payload, oh well, you may hear some garbage or clipping.=20 > With rtp/t38=20 > > fax, bad packets may cause real harm: > > + denial of service attacks can be mounted by inserting RTP/t38=20 > > + packets > > with hdlc-sig-end data field can simply terminate the fax control=20 > > channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily create=20 > > those packets. > > + theft of terminal identity? In some countries, faxes have=20 > more legal > > value that emails and the access to the rtp packet content could=20 > > change the Called Subscriber ID frame (phone numbers), etc. As you=20 > > well know, this info is usually not coded in RTP but in signaling=20 > > protocols. > > > > I'm sure the Study Group has thought of more. Could some=20 > examples of=20 > > security threats be given in the security consideration section and=20 > > shouldn't this section again reference SRTP? >=20 > These are both valid points. I fully support the addition of=20 > some text that highlights this fact. I would not want to=20 > call these out explicitly, necessarily, as there may be other=20 > places (e.g., modification or injection of NSF data, etc.),=20 > so I think it's reasonable to speak to this generically. >=20 > Would you like to suggest some text? I'd be happy to incorporate it. I would rather let you wordsmith my comments into something general you = like on this one.=20 Jean-Fran=E7ois=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 6 14:28:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24372 for ; Thu, 6 Nov 2003 14:28:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpnX-0004Nc-IH for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 14:28:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6JS3xS016814 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 14:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpnV-0004Mt-1a; Thu, 06 Nov 2003 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpnF-0004MN-Vs for avt@optimus.ietf.org; Thu, 06 Nov 2003 14:27:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24345 for ; Thu, 6 Nov 2003 14:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpnD-0006Jt-00 for avt@ietf.org; Thu, 06 Nov 2003 14:27:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AHpnC-0006Jo-00 for avt@ietf.org; Thu, 06 Nov 2003 14:27:42 -0500 Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2003 11:29:17 -0800 Received: from cscoamera13263.cisco.com (sjc-vpn4-739.cisco.com [10.21.82.227]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hA6JR9rY000907; Thu, 6 Nov 2003 11:27:10 -0800 (PST) Message-Id: <6.0.0.22.2.20031106112128.03b0d9b0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 11:27:08 -0800 To: "Jean-Francois Mule" From: Mark Baugher Subject: RE: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Cc: "Paul E. Jones" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 10:51 AM 11/6/2003, Jean-Francois Mule wrote: >Paul wrote: > > I purposely did not address SRTP, because this brings in a > > different RTP profile (SAVP) and I've not fully studied what > > (if anything) needs to be done to use that profile. Further, > > SRTP is still in draft form. I really don't want to have > > interdependencies. >I'll let other folks comment on whether it is appropriate to not address=20 >the draft's connections with SRTP. I think that there is _an_ SRTP connection (or is it connexion :?) that=20 should be referred to in the security considerations. The text that is in= =20 the current draft could be extended slightly to say that t38 is vulnerable= =20 to attacks that are common on other types of RTP payloads and that the=20 security considerations and mechanisms of RTP and SRTP apply to t38. Mark > > > -- > > > A number of issues were raised with respect to the usage of > > UDPTL for > > > the long-term, though. Specifically, there were > > concerns over the > > > fact that UDPTL does not provide the same kind of statistics > > > reporting as RTCP. Further, there are no procedures in place for > > > encrypting the UDPTL stream. While the latter could be > > addressed in > > > UDPTL, doing so would require a lot of effort and would > > largely be a > > > duplication of the security work already on-going within > > the IETF. > > > -- > > > > What was the specifc change you want made above? Just > > calling out the "an RTP"? > >How about something like: >s/encrypting the UDPTL stream/authenticating or encrypting the UDPTL stream > > > > > --- technical comment > > > The section 6 (security considerations) is rather silent on the > > > security threats. Looking at the IFP packet format, I would > > argue that > > > those packets do expose serious threats to the > > communication that you > > > don't see in audio voice. If you insert a bad RTP packet voice > > > payload, oh well, you may hear some garbage or clipping. > > With rtp/t38 > > > fax, bad packets may cause real harm: > > > + denial of service attacks can be mounted by inserting RTP/t38 > > > + packets > > > with hdlc-sig-end data field can simply terminate the fax control > > > channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily create > > > those packets. > > > + theft of terminal identity? In some countries, faxes have > > more legal > > > value that emails and the access to the rtp packet content could > > > change the Called Subscriber ID frame (phone numbers), etc. As you > > > well know, this info is usually not coded in RTP but in signaling > > > protocols. > > > > > > I'm sure the Study Group has thought of more. Could some > > examples of > > > security threats be given in the security consideration section and > > > shouldn't this section again reference SRTP? > > > > These are both valid points. I fully support the addition of > > some text that highlights this fact. I would not want to > > call these out explicitly, necessarily, as there may be other > > places (e.g., modification or injection of NSF data, etc.), > > so I think it's reasonable to speak to this generically. > > > > Would you like to suggest some text? I'd be happy to incorporate it. >I would rather let you wordsmith my comments into something general you=20 >like on this one. > >Jean-Fran=E7ois > >_______________________________________________ >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 exim@www1.ietf.org Thu Nov 6 16:43:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02625 for ; Thu, 6 Nov 2003 16:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHruF-0005nO-5L for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 16:43:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Lh7V3022271 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 16:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHru9-0005mG-7r; Thu, 06 Nov 2003 16:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrtA-0005kJ-KF for avt@optimus.ietf.org; Thu, 06 Nov 2003 16:42:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02587 for ; Thu, 6 Nov 2003 16:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrt8-00013Q-00 for avt@ietf.org; Thu, 06 Nov 2003 16:41:58 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AHrt7-00013N-00 for avt@ietf.org; Thu, 06 Nov 2003 16:41:58 -0500 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hA6LfeBQ021103; Thu, 6 Nov 2003 16:41:40 -0500 Message-ID: <013101c3a4ae$95159430$74bc47ab@cisco.com> From: "Paul E. Jones" To: "Jean-Francois Mule" , "Mark Baugher" Cc: References: <6.0.0.22.2.20031106112128.03b0d9b0@mira-sjc5-6.cisco.com> Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Date: Thu, 6 Nov 2003 16:40:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by paris.packetizer.org id hA6LfeBQ021103 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Mark, Your comments are valid. In fact, it's SRTP that is one driver (but not = the only driver) for wanting to move to RTP. But, I hesitate to mention SRTP without discussing the use of SRTP. Is there specific text that you'd like to propose. If you propose it and folks agree, I definitely have no objections to incorporating it. Paul ----- Original Message -----=20 From: "Mark Baugher" To: "Jean-Francois Mule" Cc: "Paul E. Jones" ; Sent: Thursday, November 06, 2003 2:27 PM Subject: RE: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward > At 10:51 AM 11/6/2003, Jean-Francois Mule wrote: > >Paul wrote: > > > I purposely did not address SRTP, because this brings in a > > > different RTP profile (SAVP) and I've not fully studied what > > > (if anything) needs to be done to use that profile. Further, > > > SRTP is still in draft form. I really don't want to have > > > interdependencies. > >I'll let other folks comment on whether it is appropriate to not addre= ss > >the draft's connections with SRTP. > > I think that there is _an_ SRTP connection (or is it connexion :?) that > should be referred to in the security considerations. The text that is= in > the current draft could be extended slightly to say that t38 is vulnera= ble > to attacks that are common on other types of RTP payloads and that the > security considerations and mechanisms of RTP and SRTP apply to t38. > > Mark > > > > > > -- > > > > A number of issues were raised with respect to the usage of > > > UDPTL for > > > > the long-term, though. Specifically, there were > > > concerns over the > > > > fact that UDPTL does not provide the same kind of statistics > > > > reporting as RTCP. Further, there are no procedures in place = for > > > > encrypting the UDPTL stream. While the latter could be > > > addressed in > > > > UDPTL, doing so would require a lot of effort and would > > > largely be a > > > > duplication of the security work already on-going within > > > the IETF. > > > > -- > > > > > > What was the specifc change you want made above? Just > > > calling out the "an RTP"? > > > >How about something like: > >s/encrypting the UDPTL stream/authenticating or encrypting the UDPTL stream > > > > > > > > --- technical comment > > > > The section 6 (security considerations) is rather silent on the > > > > security threats. Looking at the IFP packet format, I would > > > argue that > > > > those packets do expose serious threats to the > > > communication that you > > > > don't see in audio voice. If you insert a bad RTP packet voice > > > > payload, oh well, you may hear some garbage or clipping. > > > With rtp/t38 > > > > fax, bad packets may cause real harm: > > > > + denial of service attacks can be mounted by inserting RTP/t38 > > > > + packets > > > > with hdlc-sig-end data field can simply terminate the fax control > > > > channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily creat= e > > > > those packets. > > > > + theft of terminal identity? In some countries, faxes have > > > more legal > > > > value that emails and the access to the rtp packet content could > > > > change the Called Subscriber ID frame (phone numbers), etc. As y= ou > > > > well know, this info is usually not coded in RTP but in signaling > > > > protocols. > > > > > > > > I'm sure the Study Group has thought of more. Could some > > > examples of > > > > security threats be given in the security consideration section a= nd > > > > shouldn't this section again reference SRTP? > > > > > > These are both valid points. I fully support the addition of > > > some text that highlights this fact. I would not want to > > > call these out explicitly, necessarily, as there may be other > > > places (e.g., modification or injection of NSF data, etc.), > > > so I think it's reasonable to speak to this generically. > > > > > > Would you like to suggest some text? I'd be happy to incorporate i= t. > >I would rather let you wordsmith my comments into something general yo= u > >like on this one. > > > >Jean-Fran=E7ois > > > >_______________________________________________ > >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 exim@www1.ietf.org Thu Nov 6 19:16:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09771 for ; Thu, 6 Nov 2003 19:16:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuIV-0008MG-Sb for avt-archive@odin.ietf.org; Thu, 06 Nov 2003 19:16:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA70GJ1i032122 for avt-archive@odin.ietf.org; Thu, 6 Nov 2003 19:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuIE-0008KK-KR; Thu, 06 Nov 2003 19:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuHV-0008GI-FU for avt@optimus.ietf.org; Thu, 06 Nov 2003 19:15:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09739 for ; Thu, 6 Nov 2003 19:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHuHT-0003L8-00 for avt@ietf.org; Thu, 06 Nov 2003 19:15:15 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AHuHS-0003Jy-00 for avt@ietf.org; Thu, 06 Nov 2003 19:15:14 -0500 Received: from cscoamera13263.cisco.com (sjc-vpn4-739.cisco.com [10.21.82.227]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hA70EerY016001; Thu, 6 Nov 2003 16:14:41 -0800 (PST) Message-Id: <6.0.0.22.2.20031106150436.03b997f0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 16:14:39 -0800 To: "Paul E. Jones" From: Mark Baugher Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Cc: "Jean-Francois Mule" , , Mats =?iso-8859-1?Q?N=E4slund?= , karl.norrman@ericsson.com, mcgrew@cisco.com, "Elisabetta Carrara (KI/EAB)" In-Reply-To: <013101c3a4ae$95159430$74bc47ab@cisco.com> References: <6.0.0.22.2.20031106112128.03b0d9b0@mira-sjc5-6.cisco.com> <013101c3a4ae$95159430$74bc47ab@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Paul I think the approach that you mentioned in the security consideration is= =20 good since it relies on the security consideration and security mechanisms= =20 found in RTP and SRTP. What is needed is to specify what might be specific= =20 to the fax payload type with respect to SRTP. I'd say that a short 32-bit= =20 tag is a SHOULD NOT for fax and not a MAY as it is with other applications= =20 owing to the fact that the effects of fraud are so much greater form=20 certain fax applications than is generally true for voice. I'd offer=20 something like this. "T38 is vulnerable to attacks that are common on other types of RTP=20 payloads. The security considerations and mechanisms of RTP and SRTP apply= =20 to T38. Regarding SRTP configuration, fax payloads SHOULD NOT use an=20 HMAC-SHA1 authentication tag that is shorter than 80 bits." Mark At 01:40 PM 11/6/2003, Paul E. Jones wrote: >Mark, > >Your comments are valid. In fact, it's SRTP that is one driver (but not= the >only driver) for wanting to move to RTP. But, I hesitate to mention SRTP >without discussing the use of SRTP. > >Is there specific text that you'd like to propose. If you propose it and >folks agree, I definitely have no objections to incorporating it. > >Paul > >----- Original Message ----- >From: "Mark Baugher" >To: "Jean-Francois Mule" >Cc: "Paul E. Jones" ; >Sent: Thursday, November 06, 2003 2:27 PM >Subject: RE: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward > > > > At 10:51 AM 11/6/2003, Jean-Francois Mule wrote: > > >Paul wrote: > > > > I purposely did not address SRTP, because this brings in a > > > > different RTP profile (SAVP) and I've not fully studied what > > > > (if anything) needs to be done to use that profile. Further, > > > > SRTP is still in draft form. I really don't want to have > > > > interdependencies. > > >I'll let other folks comment on whether it is appropriate to not= address > > >the draft's connections with SRTP. > > > > I think that there is _an_ SRTP connection (or is it connexion :?) that > > should be referred to in the security considerations. The text that is= in > > the current draft could be extended slightly to say that t38 is= vulnerable > > to attacks that are common on other types of RTP payloads and that the > > security considerations and mechanisms of RTP and SRTP apply to t38. > > > > Mark > > > > > > > > > -- > > > > > A number of issues were raised with respect to the usage of > > > > UDPTL for > > > > > the long-term, though. Specifically, there were > > > > concerns over the > > > > > fact that UDPTL does not provide the same kind of statistics > > > > > reporting as RTCP. Further, there are no procedures in place= for > > > > > encrypting the UDPTL stream. While the latter could be > > > > addressed in > > > > > UDPTL, doing so would require a lot of effort and would > > > > largely be a > > > > > duplication of the security work already on-going within > > > > the IETF. > > > > > -- > > > > > > > > What was the specifc change you want made above? Just > > > > calling out the "an RTP"? > > > > > >How about something like: > > >s/encrypting the UDPTL stream/authenticating or encrypting the UDPTL >stream > > > > > > > > > > > --- technical comment > > > > > The section 6 (security considerations) is rather silent on the > > > > > security threats. Looking at the IFP packet format, I would > > > > argue that > > > > > those packets do expose serious threats to the > > > > communication that you > > > > > don't see in audio voice. If you insert a bad RTP packet voice > > > > > payload, oh well, you may hear some garbage or clipping. > > > > With rtp/t38 > > > > > fax, bad packets may cause real harm: > > > > > + denial of service attacks can be mounted by inserting RTP/t38 > > > > > + packets > > > > > with hdlc-sig-end data field can simply terminate the fax control > > > > > channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily create > > > > > those packets. > > > > > + theft of terminal identity? In some countries, faxes have > > > > more legal > > > > > value that emails and the access to the rtp packet content could > > > > > change the Called Subscriber ID frame (phone numbers), etc. As= you > > > > > well know, this info is usually not coded in RTP but in signaling > > > > > protocols. > > > > > > > > > > I'm sure the Study Group has thought of more. Could some > > > > examples of > > > > > security threats be given in the security consideration section= and > > > > > shouldn't this section again reference SRTP? > > > > > > > > These are both valid points. I fully support the addition of > > > > some text that highlights this fact. I would not want to > > > > call these out explicitly, necessarily, as there may be other > > > > places (e.g., modification or injection of NSF data, etc.), > > > > so I think it's reasonable to speak to this generically. > > > > > > > > Would you like to suggest some text? I'd be happy to incorporate= it. > > >I would rather let you wordsmith my comments into something general you > > >like on this one. > > > > > >Jean-Fran=E7ois > > > > > >_______________________________________________ > > >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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 7 04:17:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06671 for ; Fri, 7 Nov 2003 04:17:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2js-0001qu-AS for avt-archive@odin.ietf.org; Fri, 07 Nov 2003 04:17:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79H8wK007119 for avt-archive@odin.ietf.org; Fri, 7 Nov 2003 04:17:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2jl-0001pQ-IP; Fri, 07 Nov 2003 04:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2jY-0001lD-83 for avt@optimus.ietf.org; Fri, 07 Nov 2003 04:16:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06607 for ; Fri, 7 Nov 2003 04:16:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2jV-0001em-00 for avt@ietf.org; Fri, 07 Nov 2003 04:16:45 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AI2jU-0001dz-00 for avt@ietf.org; Fri, 07 Nov 2003 04:16:44 -0500 Received: from mcomreyj ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Fri, 7 Nov 2003 10:15:18 +0100 Reply-To: From: "Jose Rey" To: "'Dave Singer'" , "'Magnus Westerlund'" Cc: "'IETF AVT WG'" , "Jan van der Meer \(E-mail\)" , "Yoshinori Matsui \(E-mail\)" Date: Fri, 7 Nov 2003 10:15:11 +0100 Message-ID: <003b01c3a50f$a9a4ace0$05640a0a@panasonic.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: X-OriginalArrivalTime: 07 Nov 2003 09:15:18.0806 (UTC) FILETIME=[A9C81360:01C3A50F] Content-Transfer-Encoding: 7bit Subject: [AVT] RE: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Dave, thanks for your comments. I also think it is better to stay in the abstract plane for now, and leave the details for later...and I appreciate very much your readiness to help. Please see inline. ---cut--- > > (b) Overall comments. > > The 3GPP timed text spec is conceptually pretty simple; this payload > format seems pretty complex. There are several bit-fields, for > example. It uses two payload type indicators. I think that we can > use one payload type indicator, and one header which tells us (i) is > the 'static information' present? (ii) is this a single fragment or a > set of whole samples? (iii) what are the various offsets etc. > > I get the idea of giving the explicit offset to the start of a box, > and also the need to 'place' a fragment in the string, and so on. > I'm just aware that it comes across complex as is, and wonder if we > can't skin it slightly differently -- possibly at the expense of a > few bytes for unusual cases -- for a simpler spec. > > I'm willing to spend time in this direction if there is consensus > that such an exploration take place. > Yes, the draft is pretty complex and yes we can make it simpler, of course by having more overhead. The draft has a lot of functionalities, which would probably (?) be seldom used. The question is where and how to cut down. In particular, the thing that 'bothers' me most is the following: the draft allows for self-contained packets of the two kinds of text sample fragments: those containing text strings and those that not. Apart from the current composition of the headers, 1) do we want to keep that? 2) or is it enough to guarantee the display of just the text strings (plain) in the case of packet losses? Is it correct to assume modifier boxes would very seldom expand over several RTP packets so that the effort for specific modifier field fragment headers would not be worth? or is it preferable to stay in the safe side and contemplate those rare cases also by introducing overhead? Comments are welcome! > (c) Details. > > I have a number of detailed comments: things talked about before > they are defined (e.g. T=1 in 4.1); what is the SIDX field for? and > so on. However, I'd rather see us work out the direction in general > (a) and the approach (b) before dealing with details. > I agree, I prefer to comment this later, it might change. > (d) Where to go. > > I think we should proceed with this. Though it is not on the table > for release 6 of 3GPP officially, no-one there will object if text > becomes streamable: it's a useful good idea. I don't think the W3C > work is either going to complete soon, or be a direct translation > into an RTP format, and that's the only 'bigger' idea on the horizon. > And I don't think this should be shoe-horned into the MPEG-4 payload > format either; it has unique needs (and it ought to be possible to > make it simpler). > > A liaison or communication from the chairs to 3GPP and W3C saying > what the Minneapolis meeting thinks is the direction would be prudent > and courteous, however. Good idea. cheers, Jose > -- > David Singer > Apple Computer/QuickTime > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 7 12:13:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23122 for ; Fri, 7 Nov 2003 12:13:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAAU-0001Ef-Bo for avt-archive@odin.ietf.org; Fri, 07 Nov 2003 12:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7HD661004721 for avt-archive@odin.ietf.org; Fri, 7 Nov 2003 12:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAAQ-0001D2-3M; Fri, 07 Nov 2003 12:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIA9c-0001B4-L0 for avt@optimus.ietf.org; Fri, 07 Nov 2003 12:12:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22758 for ; Fri, 7 Nov 2003 12:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIA9b-0007gL-00 for avt@ietf.org; Fri, 07 Nov 2003 12:12:11 -0500 Received: from h007.c015.snv.cp.net ([209.228.35.122] helo=c015.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AIA9a-0007gI-00 for avt@ietf.org; Fri, 07 Nov 2003 12:12:10 -0500 Received: (cpmta 3402 invoked from network); 7 Nov 2003 09:12:08 -0800 Received: from 81.225.123.108 (HELO caruso) by smtp.globalipsound.com (209.228.35.122) with SMTP; 7 Nov 2003 09:12:08 -0800 X-Sent: 7 Nov 2003 17:12:08 GMT From: "Alan Duric" To: "'IETF AVT WG'" Date: Fri, 7 Nov 2003 18:10:06 +0100 Message-ID: <002a01c3a552$01a52f90$0b02a8c0@global.int> 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, Build 10.0.3416 Importance: Normal In-Reply-To: <3FA92861.9080704@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] Summary for draft-ietf-avt-rtp-ilbc-03.txt and draft-ietf-avt-ilbc-codec-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, during the 58th IETF meeting in Minneapolis there will be discussed following wrt draft-ietf-avt-rtp-ilbc-03.txt and draft-ietf-avt-rtp-ilbc-03.txt: # changes since the last version of (draft-ietf-avt-rtp-ilbc-03.txt) - input reflecting AVT chairs input on 02 version (clarified a number of ID nits and descriptions) - changes in file format (2 different file types, empty frame introduced) # changes since the last version of (draft-ietf-avt-ilbc-codec-03.txt) - input reflecting AVT chairs input on 02 version (clarified a number of ID nits and descriptions, 2 compiler errors in the source code due to formatting fixed) - empty frame introduction (no effect on existing implementations) # Update on running implementations # WGLC (proposal) for both of the drafts Your feedback/comments are greatly appreciated. Regards, Alan ________________________________________________________________________ ____________ Cuius rei demonstrationem mirabilem sane detexi hanc marginis exiguitas non caperet. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 7 16:21:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08311 for ; Fri, 7 Nov 2003 16:21:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2Z-0001Vv-5g for avt-archive@odin.ietf.org; Fri, 07 Nov 2003 16:21:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LLBDw005774 for avt-archive@odin.ietf.org; Fri, 7 Nov 2003 16:21:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2P-0001Ng-G7; Fri, 07 Nov 2003 16:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE1c-0001IU-96 for avt@optimus.ietf.org; Fri, 07 Nov 2003 16:20:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08120; Fri, 7 Nov 2003 16:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1a-00037v-00; Fri, 07 Nov 2003 16:20:10 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AIE1Z-000377-00; Fri, 07 Nov 2003 16:20:09 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 30260; Fri, 07 Nov 2003 16:26:46 -0500 (EST) 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 Date: Fri, 7 Nov 2003 16:19:34 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F693A@zoe.office.snowshore.com> Thread-Topic: Comments on draft-even-avt-h263-h261-options-00 Thread-Index: AcOla1OqRTV+kbv3ThGkLxVO/RC+Gg== From: "Eric Burger" To: , Content-Transfer-Encoding: quoted-printable Subject: [AVT] Comments on draft-even-avt-h263-h261-options-00 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Section 4: In the example "CIF=3D4 QCIF=3D3 SQCIF=3D2 XMAX=3D360 YMAX=3D240 = MPI=3D2", the text says that the MPI=3D2 parameter goes with SQCIF=3D2. = How does it know? Nits - Section 2 ABNF Size =3D "QCIF" "=3D" "mpi | "CIF" "=3D" mpi Size =3D "QCIF" "=3D" mpi | "CIF" "=3D" mpi ^ Section 3 ABNF "CIF4" "=3D" mpi I "CIF16" "=3D" mpi "CIF4" "=3D" mpi | "CIF16" "=3D" mpi ^ Here #term means comma separated list of term. Here #term means comma separated list of terms. ^ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 7 19:04:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15285 for ; Fri, 7 Nov 2003 19:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGaL-00039U-V4 for avt-archive@odin.ietf.org; Fri, 07 Nov 2003 19:04:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA804DWW012073 for avt-archive@odin.ietf.org; Fri, 7 Nov 2003 19:04:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGa9-00037G-UC; Fri, 07 Nov 2003 19:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGZt-000368-OQ for avt@optimus.ietf.org; Fri, 07 Nov 2003 19:03:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15246 for ; Fri, 7 Nov 2003 19:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGZq-0005Jb-00 for avt@ietf.org; Fri, 07 Nov 2003 19:03:42 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AIGZp-0005Iq-00 for avt@ietf.org; Fri, 07 Nov 2003 19:03:41 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA803YSr028327; Fri, 7 Nov 2003 17:03:34 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hA802VDX019824; Fri, 7 Nov 2003 18:02:31 -0600 Message-ID: <3FAC3345.C694D8B7@motorola.com> Date: Fri, 07 Nov 2003 18:05:25 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: IETF AVT WG References: <3F9E6B28.6090307@ericsson.com> <3FA29C84.8A6D7C@motorola.com> <3FA61308.3060603@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Comments on DSR drafts Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Magnus, Magnus Westerlund wrote: ... > I think they from an RTP transport perspective are all the same and > therefore could be had in one specification. Ok, I will merge the three into one draft after the IETF. > Okay, good. There is no DSR frame that can creates unusual high > processing requirements on receiver side? To my knowledge the values in a DSR frame (mostly indexes of a small, fixed size codebook) are not capable of creating this type of threats. regards, -Qiaobing _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 7 19:14:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15760 for ; Fri, 7 Nov 2003 19:14:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGjs-0004A1-H5 for avt-archive@odin.ietf.org; Fri, 07 Nov 2003 19:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA80E41Q015971 for avt-archive@odin.ietf.org; Fri, 7 Nov 2003 19:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGjp-00048w-BC; Fri, 07 Nov 2003 19:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGjl-00048P-FQ for avt@optimus.ietf.org; Fri, 07 Nov 2003 19:13:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15754 for ; Fri, 7 Nov 2003 19:13:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGjj-0005Vr-00 for avt@ietf.org; Fri, 07 Nov 2003 19:13:55 -0500 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1AIGjj-0005Vo-00 for avt@ietf.org; Fri, 07 Nov 2003 19:13:55 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id hA80DreS025116; Fri, 7 Nov 2003 17:13:53 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hA80CoDX026227; Fri, 7 Nov 2003 18:12:51 -0600 Message-ID: <3FAC35B1.3A8CEBAE@motorola.com> Date: Fri, 07 Nov 2003 18:15:45 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: avt@ietf.org References: <3FAA187B.5070505@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Discussion points for "RTP payload formats for ETSI DSR front ends" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, all, ... > RTP payload formats for ETSI DSR front ends (Xie) 15 > draft-ietf-avt-dsr-es202050-01.txt > draft-xie-avt-xdsr-es202211-00.txt > draft-xie-avt-xadsr-es202212-00.txt In the above presentation, I will discuss the following: - A review of changes made to es202050-01 draft since it was presented in IETF 56th. - An introduction to es202211-00 and es202212-00 drafts and their differences from the 2 previous DSR front ends. - A proposal to merge the three drafts into one WG item. - There are no other open issues. regards, -Qiaobing _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Nov 8 06:18:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13105 for ; Sat, 8 Nov 2003 06:18:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR6k-0000ue-QV for avt-archive@odin.ietf.org; Sat, 08 Nov 2003 06:18:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8BIMEW003462 for avt-archive@odin.ietf.org; Sat, 8 Nov 2003 06:18:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR6O-0000sJ-Ns; Sat, 08 Nov 2003 06:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIR5q-0000rW-7A for avt@optimus.ietf.org; Sat, 08 Nov 2003 06:17:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13066; Sat, 8 Nov 2003 06:17:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIR5m-0005UB-00; Sat, 08 Nov 2003 06:17:22 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 1AIR5l-0005Tw-00; Sat, 08 Nov 2003 06:17:21 -0500 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Sat, 8 Nov 2003 13:16:19 +0200 Message-ID: From: "Even, Roni" To: "'Eric Burger'" , avt@ietf.org, mmusic@ietf.org Date: Sat, 8 Nov 2003 13:16:16 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Subject: [AVT] RE: [MMUSIC] Comments on draft-even-avt-h263-h261-options-00 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Eric, The 2 in SQCIF=2 is the MPI value. The MPI but it self relates to the custom format x=360, y=240, MPI=2. Roni ************************************* Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Friday, November 07, 2003 11:20 PM To: avt@ietf.org; mmusic@ietf.org Subject: [MMUSIC] Comments on draft-even-avt-h263-h261-options-00 Section 4: In the example "CIF=4 QCIF=3 SQCIF=2 XMAX=360 YMAX=240 MPI=2", the text says that the MPI=2 parameter goes with SQCIF=2. How does it know? Nits - Section 2 ABNF Size = "QCIF" "=" "mpi | "CIF" "=" mpi Size = "QCIF" "=" mpi | "CIF" "=" mpi ^ Section 3 ABNF "CIF4" "=" mpi I "CIF16" "=" mpi "CIF4" "=" mpi | "CIF16" "=" mpi ^ Here #term means comma separated list of term. Here #term means comma separated list of terms. ^ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 10 09:57:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21811 for ; Mon, 10 Nov 2003 09:57:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDTo-0008Pk-Rn for avt-archive@odin.ietf.org; Mon, 10 Nov 2003 09:57:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAEvOUw032340 for avt-archive@odin.ietf.org; Mon, 10 Nov 2003 09:57:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDTR-0008Or-2f; Mon, 10 Nov 2003 09:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCZd-0005vO-Ex for avt@optimus.ietf.org; Mon, 10 Nov 2003 08:59:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19744; Mon, 10 Nov 2003 08:59:07 -0500 (EST) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCZb-0004op-00; Mon, 10 Nov 2003 08:59:19 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AJCZZ-0004om-00; Mon, 10 Nov 2003 08:59:17 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 6D1565AA15; Mon, 10 Nov 2003 14:59:09 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 82AD919C4C; Mon, 10 Nov 2003 14:59:07 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 821E919C45; Mon, 10 Nov 2003 14:59:06 +0100 (MET) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id OAA28722; Mon, 10 Nov 2003 14:59:05 +0100 (MET) To: , "'IETF AVT WG'" Cc: avt-admin@ietf.org, Colin Perkins , Magnus Westerlund , "'Dave Singer'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 10 Nov 2003 14:57:05 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1|June 9, 2003) at 10/11/2003 14:57:07 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mixed 004CD08BC1256DDA_=" Subject: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --=_mixed 004CD08BC1256DDA_= Content-Type: multipart/alternative; boundary="=_alternative 004CD08DC1256DDA_=" --=_alternative 004CD08DC1256DDA_= Content-Type: text/plain; charset="us-ascii" Dear Jose, all, I will not be in Minneapolis either but would like to provide some input on the issue of transport of 3GPP timed text. I know this input is very late; my appologies for that. As you know also MPEG is working on timed text; currently the Committe Draft (CD) is ballotted, and MPEG schedules to enter the next phase in about one month and to finish the work in July 2004. The end-result will be part 17 of MPEG-4, defining MPEG-4 text streams. Through liaisons, MPEG tries to harmonize its work with the work that is already carried out in 3GPP and also with ongoing work in W3C. Most important in this respect is that MPEG focusses at maximum commonality with the timed text format defined by 3GPP for download. In summary, the current CD of MPEG-4 part 17 specifies streaming of the 3GPP timed text format by defining a very straightforward way to transcode the 3GPP format into the MPEG-4 structure of a decoder configuration and text access units. Please find the Committee Draft (a public document) attached to this email. So far, 3GPP expressed through liaison statements to be very pleased with the work done by MPEG. Once the work is finished, the timed text format can be streamed using "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is scheduled to be published as RFC very soon. In summary this approach would work as follows: - media type: "video", - MIME subtype name: mpeg4-generic, - streamType (required parameter in RFC#simple): indicates MPEG-4 text stream as defined in ISO 14496-17, - profile-level-id (required parameter in RFC#simple): specifies the functional subset as defined in the current 3GPP timed text specification, - config (required parameter in RFC#simple): carries the decoder configuration specified for text streams in ISO 14496-17, - the RTP payload contains either (a) one fragment of a text access unit or (b) one or more complete text access units, - the RTP payload carries one AU-header for each carried text access unit, - in the RTP payload the concatenated AU-headers preceed concatenated data of text access units, as defined in RFC#simple, - each AU-header contains (at least) the following information on the associated text access unit: (a) the size of the text access unit, (b) the time stamp of the text access unit, - if deemed necessary, the AU-header may also carry the index of a text access unit (fragment) and/or an indication whether the associated text access unit is a random access point. In RFC#simple the fields in the AU-header are configurable, but if desired one or two new modes for RFC#simple could be defined with fixed length fields, for example one using an 8 bit AU-size field (for most common applications) and another using 16 bits AU-size field for applications using (very) large text access units. The above "RFC#simple approach" has a high level of commonality with draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small differences that can be fixed either way, but roughly the "RFC#simple approach" is a simplified version of draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the "RFC#simple" approach does not have the advanced error resiliency measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt. In my view not only in IETF, but also in 3GPP and in MPEG a number of basic issues should be discussed, such as: - are the error resiliency features of draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to justify their complexity (note that a partly corrupted subtitle may not have much more value to the user than a missing one); - is it desirable to define a 3GPP timed text transport solution based on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one that will be available based on RFC#simple; - is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt specifies a mode or an extension of RFC#simple; - how can a timing conflict (if any) between release 6 of 3GPP and part 17 of MPEG-4 be resolved (note that such conflict will only exist if 3GPP adopts streaming of timed text as a work item and if 3GPP decides that this functionality has to be in release 6). I hope you will have a fruitful discussion on this subject in Mineapolis. But, this is not just an IETF issue. Therefore, as both 3GPP and MPEG are main "customers" of a timed text streaming solution, I suggest that IETF requests 3GPP and MPEG to advice IETF as to the most desirable direction for resolving this issue. Note that both 3GPP and MPEG will have meetings where this issue can be discussed well before the end of this year. Best regards, Jan van der Meer --=_alternative 004CD08DC1256DDA_= Content-Type: text/html; charset="us-ascii"
Dear Jose, all,

I will not be in Minneapolis either but would like to provide some input on the issue of transport of 3GPP timed text. I know this input is very late; my appologies for that.

As you know also MPEG is working on timed text; currently the Committe Draft (CD) is ballotted, and MPEG schedules to enter the next phase in about one month and to finish the work in July 2004. The end-result will be part 17 of MPEG-4, defining MPEG-4 text streams. Through liaisons, MPEG tries to harmonize its work with the work that is already carried out in 3GPP and also with ongoing work in W3C. Most important in this respect is that MPEG focusses at maximum commonality with the timed text format defined by 3GPP for download. In summary, the current CD of MPEG-4 part 17 specifies streaming of the 3GPP timed text format by defining a very straightforward way to transcode the 3GPP format into the MPEG-4 structure of a decoder configuration and text access units. Please find the Committee Draft (a public document) attached to this email. So far, 3GPP expressed through liaison statements to be very pleased with the work done by MPEG.

Once the work is finished, the timed text format can be streamed using "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is scheduled to be published as RFC very soon. In summary this approach would work as follows:
- media type: "video",
- MIME subtype name: mpeg4-generic,
- streamType (required parameter in RFC#simple): indicates MPEG-4 text stream as defined in ISO 14496-17,
- profile-level-id (required parameter in RFC#simple): specifies the functional subset as defined in the current 3GPP timed text specification,
- config (required parameter in RFC#simple): carries the decoder configuration specified for text streams in ISO 14496-17,
- the RTP payload contains either (a) one fragment of a text access unit or (b) one or more complete text access units,
- the RTP payload carries one AU-header for each carried text access unit,
- in the RTP payload the concatenated AU-headers preceed concatenated data of text access units, as defined in RFC#simple,
- each AU-header contains (at least) the following information on the associated text access unit: (a) the size of the text access unit, (b) the time stamp of the text access unit,
- if deemed necessary, the AU-header may also carry the index of a text access unit (fragment) and/or an indication whether the associated text access unit is a random access point.
In RFC#simple the fields in the AU-header are configurable, but if desired one or two new modes for RFC#simple could be defined with fixed length fields, for example one using an 8 bit AU-size field (for most common applications) and another using 16 bits AU-size field for applications using (very) large text access units.
 
The above "RFC#simple approach" has a high level of commonality with draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small differences that can be fixed either way, but roughly the "RFC#simple approach" is a simplified version of draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the "RFC#simple" approach does not have the advanced error resiliency measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt.

In my view not only in IETF, but also in 3GPP and in MPEG a number of basic issues should be discussed, such as:
- are the error resiliency features of draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to justify their complexity (note that a partly corrupted subtitle may not have much more value to the user than a missing one);
- is it desirable to define a 3GPP timed text transport solution based on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one that will be available based on RFC#simple;
- is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt specifies a mode or an extension of RFC#simple;
- how can a timing conflict (if any) between release 6 of 3GPP and part 17 of MPEG-4 be resolved (note that such conflict will only exist if 3GPP adopts streaming of timed text as a work item and if 3GPP decides that this functionality has to be in release 6).

I hope you will have a fruitful discussion on this subject in Mineapolis. But, this is not just an IETF issue. Therefore, as both 3GPP and MPEG are main "customers" of a timed text streaming solution, I suggest that IETF requests 3GPP and MPEG to advice IETF as to the most desirable direction for resolving this issue. Note that both 3GPP and MPEG will have meetings where this issue can be discussed well before the end of this year.

Best regards,

Jan van der Meer

--=_alternative 004CD08DC1256DDA_=-- --=_mixed 004CD08BC1256DDA_= Content-Type: application/zip; name="w5782.zip" Content-Disposition: attachment; filename="w5782.zip" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UEsDBBQAAAAIAPZUJC/4yJaF25YAAAD6AQAJAAAAdzU3ODIuZG9j7FtdjCTXVa6NDcsYF3/ezQNS 0NUAYsbp6e3umf2ZWYHone7ZbWvnR9PtXVtZFKq7b8+UXV3Vrqqe2d5gJQILWbwAEnKkgNBAhIWD RMQbSAiEYvHzEvLGQ17CI1J4ROIpy3fOvbf+uubH3lgRkmu1W133nnvuOeee/6r9zr//7Pf+7G9+ /j+twvVr1nPWD54uWD+eGfsM/r5qHn7Gsh7idgl/f/D06VMa6uHvFH+ffnr9v7m+/xf/ZH3h1xee t6z//bl/TE4WFw7+J//Qsn7K6r/Rf2PtubXnrLlr4fnPWt97z7IeuJf475eblvWbGP+9H5uHpevp 058+97e53uV//3rZSu709wX8/lvcX8T9+c+ruey9lcVQUffvHMzfv4L73qFlxbh/iPsfZeC/+b5l fR9qPXQt6+/BiQiwN56/PVHzxfsHb1nWP1y2rIOZZf0JTOS53wJuwL/wvrKYF99XcBe5/xLuf/yX lrWPhf/9Dcv6CeCpYXzdmr8M3923SyYtRVf2buDMvfZ+Hr4oT8Ofuej5u7i7WPdZ3H//HTVevBP+ d5+bx1N8fqGwv1n/US/Dj8FHeK5YKb6v496APH/7Ty1r6fl5Pj/u9bWvq7vh5zVX6eUfhN/+3de6 37pk4Izeffcr0AvQ8Y0/h8Vk8Pwz8LQw/mXQX7OU/vGF8a/h9j9/pR4//zuWtXNJPT+y0v3NdQ/8 fIj7i9BjqKD14bJ6fvdl9Xwe32Yfcxk42odMo6g/2fPO3s+7ivBFfTR3Y490//BzlnX/Fct653Mp ntk7Sg+zcHQRHF2fsS4lZ/Dp9en16VV2dXZ67f2dZq+zu9O8L3b37zZ3Ol1+FFu7+6Lba+60mvst PWbnAHJr26LVFju7+9vN+wa409291mlvild6m/Vr3c3G+rWHd+t1e3O31dm5K3a3xPbuA/q119ns vbrf7grsJZqvtjq7pyzduX7zVsN+ZerNRKNWW7VtuzuLYjmO7J4be3JDLGwG47Ebx1KKVuiMYhGM xPZe++7KmojiUDpj1z8QsXwci1EQjp3Ytjs7W0Qz89Nrb97b2b2/e/d1ezMYEiiWO9OhG6wcudHU 8UTQf0MO4kh8Vew5YSzqNzdEN8HbI7xbGu+LL4luuyfOlf+P+rpvdaw7VtvyrS3LtTxLWjuWY41x F9aitWltINa0rMAaILOnUR85U4Q5B7+GuHcxFuOPi+cDzDwC7AFgQ0A8sv6l9ne1b9b+tfat2n/U HmGnrrVrreDeBuYvWnVrDX/WrRsYq1s3MbKEmWWrCsy04yLwX/kR03DVeol3aKO6EaCiZd3Dbg5m 1W57+H2AkbqW1661jT8dQPewps1r9q0mpNtL+DkLZn6/XfBxwLy61hPcic8AT7TfB9aJ5uia5ujE aiCLqFmr+HVFCGD18EcAhwssh1pyISiO8De0juRwUVz54EQb3AnZ1clXRdPzROgeHELXQxnJEGBX lUbfd/ttP5axxAqxaJZttk7qa2vrN1bqN4GuZNSs7tzpzSYS5hoqBOLGKhbgXw3QavU6vfvtNbFI FnaSt7CM5WLR2QB5fKsg1VcTbuADbnDoB15wMAOvZ9s6sfPxVuYpaIjFf/P+ayz9WLh+HAbD6SB2 R0BiRgf4J3S8E+VbXMmsJZPBeKJ+Om4oQdMPDVeeyvrHlpPe68wT+6RQJzy0gsF9xz+YOgdSLLax YzuZehiEb2K65cSYIi1fqd1cadwATPqQxdONGcnSam1ZJFEF0PmBZMVueOD47hPmbTWxi9QWSgHr qQFlrCYBvdPstl9vN/fFIplIMtwc+0FhiOid9smy5ifUaAc2G/q8KwQL5vyhEw75TMomEgSTaf91 6YRKZFpYRZnuFMnZl6OdgCNkwh/7gQyT/JxdcFf6BehfyPkSM5TbZDr+6C6o1epuduUgLNBcNrTJ aYVYTNWzSepZEXvuIJ6GsiK2p17sjuXQdQQEJ+5B1qF6zOg6kD4jhtRIDUlZU+olplSwsXQiPbK7 LLR6HaD1eoZVHm6s0xGvZ7bjYWRhghbwPfXk95tI3hZFg4TW0MOe27/X2Glut8XiPekw0zSf/M6A 1fNg9QxYsonbb8lokDsXPdYqG2yXDW7lBpGvwlQeyPxhb7Z3SkahRCWj4BxD293Wjljs9loCDxFJ u1ElFgoj6Rp2KNADHN5qDYCrtZTM/YlXpLyz2S3uutW5D3Gv0eBaZjTccj2544zJ9rPgLXnKxI4T nzJDw7vesLhxErIhplPnINgiDypRmFtkJuZWdODxZv7gMAwebJ060z51Jq8SrVZ76JIZZNzTfntr zgU/ells3mvuqzJA5NywAldGUARTtoDa5MTAdUvhYE0nOwlM6jELcFdtikwbJydFUA5Yc0jTkGUr +FxadhpLWWdof0Rp9FJGn1kgKOZSNu+WAcE12eSRZeyErhNn5cKOek56CW0qi5lj45PKPPIbN/Ib /xCzNOzTfLW322u/1hPtteaD9n5PXLEfOqEPiuzeoRuJYTCYqt0i4Qcxwgk5MFEe4Kuiw4BDF4Wx 25/GckgsIds/cuUxhyJQQOgMZDRlmYg4EINDJFlSHLvxYTCNaTN3IHnN2Jnx3n0JTCMZhkCLBU7E 1JRTYu/LgTtxsVVE5xAzL1y9O6GE6I7cWGEBBci6KrwvwKQbGhqjChMxcgfqiOk4/RlI8OSRA4lM YES46YoGs8eH7oBxzHgT55j/9XmbSRgcuXDT0XQyCXAuOHEjWsZeta++uBlMZoxNM69OgMSdPQVH HMOIGYHqRiiCVYNCs4g9ATkw+FawOxSUOO7PCGFVPDyEVyZawc9Eq5HiMYc9KkEfQXwsCdJWPt9p JAnxhBQOUnd8BUPYifpIHwpOQB5JL5gwK9h1IKOICKXshDYYJqc/CV3g5fGIo94oDMaEDGciAYPo GefU0wc40QQrCh0oFMO7MetOP2VSDisgJyANwgKA+pHeucgTPQS80WQaToJIFmg7DmmdX0YjKd9b UxlBCqM8F1CEhJICAwRJAjO74SQi6Xl0EmAjws4IoeDEGQ5RPEegGPqP4WMfo15wzPwEtP2vRGIs x31Q3g+GM3MQg2AKxzBTxkACYQpluGF/oeMPSceVOoymqNL1JhV4JU9ODgNfCn9KKCti5DxOftNs +kRah4EBvJLvDiB5N4OIjHUCzifkeZGhajJSld8m6w/NOKlNlgkgmQR+5PahtEZSUerKzTJEC0x2 N/msNOOjECkJKXXORFM1NwdwCBL7kk4URwTLHVZ/A+eYsQ3aN3I8GZkziox2ZbxYGMwcLyZbmI2V 84EqITOFW45oO+cglJI9oP3ADTwHupigwV7gibxm1bY3A5/cS7SwhwzPfqm3uykeIeeor6BgehRz 7ZWQVlmvPHlyB8JBEUA/t6Dg4G/IDzhd+biCHPzR8RUzsfCS2GvebVOQ+WIvGKzdWL+F6I9Acygu XTly3at2Fn059GoCDfB6deH8FWtqBaJwo7rAjU3VP9Vhr3zR9WTRql7kDNhvTH0X0ildcyNZs1Zd 6LoHiAw6HscXQ7CuEDSu2tf1pqGEGENgKV1QryULblQXWnKAjDzECY7cg2noJNrTo5pMtXSHCqZ8 /3pdoVu9al+1zZlR+1ossXHkQl421eJdTAzUY8tJ0PCGxxSCRhIbJyEtwZN6aVicC+Veyhshhpar oqdNh5YqQyHJlgfhSCUNOFvPm4mBE4Yu+V240BiZ9fTgkM2cMyf4Hy+NM1FVtB3Yad6NYQvyWMpV JzZHHCurdspQpWaNtQ4sJDoEBhpkL8iuB2arQ4SMYHJEI7kOJ07RVAssBhmhw7sdBEeY5GDusR/0 A38lO1ghoj3XcSOg5lSDY5njRYGInTclx07jqkm+VZbNIPA8px/gtHAeAw/uAYI0mUqBpLZyvakM uJ+k4s4Ssu1l4gonAW8DjkLOWGRxTZTXnap92slSasPZgD6PwQAq6vgDmZIXTslXHrhHEH6aDXDi 30L2CUdxJCE7zoUbVZs0CzEDgE70prLVecUgjeJsil30aXpX1S9qTiV+GEx0MkRUlW5E6AduOJjC R6tMkUBz5sC6dxRQMlcVe1Mol84Uz8pMOfKCfR0PjzAFMqBrnnSiWNy8fvLLJprlNxtgmiMIbSmr dpPSD95OpbbHviESsQmR0vXceKbUOArG0iDFkY/zWbEJgDoKcWjVxkVGns1ylVZGh6RGOiM/lN5w LjzDzYC00YzppUQqZM2LpjDTPELzUi5pxYljSM+EYBJNL6/QbNRmEZeHFVHenqqI7rSfOgLUkI31 injGplmBYGgM2I6MOIl7D8kY7UAWDfWeUtzgqQPpw+96IuZm28csHjds9ZIQpaN+S8nPjQ3xgOHU 4+qG4k49rW0IikW0HRkofAkpkpq7viH2qaaSNBMFI6pZ1MyNDdGSHmwUSWNGNKTVBzp8bCWp1VJr u7O1rBai3tydANx9ggMEypjrIFIL/dY0DgJP030LpFFcoLY4ONayFYlsY6WqIEJ09pD6x7SbXrue Jf0QpsX7DGU0CN0J0adFVYMwhkfE+hBCGsrAiHip+WBT01wngSJHy61nNYCVJnYt/QPX1+KpQ+Qq QJJURq7SfHpNq6ZxBJ297T0qSCj1g5roCZzG9t5ayQocBQgqmcBJNH13XJS5fE1jBiNbry0L++yu Qi6l43fJuebGJ9jNyG4sbFXVdieoz01pTYXhCJKN1DqVFcLZNLPPOVNz6IlqFj9JZOZSO5WsKCIS AI1bleXFFdyRUIRRoQhHdCypGsJokkTSQk7eshmloRjMzaW1tp1ng7Oxi1C/5wzelLHJ7ACTLpJl xA/lBElqRGFeMzHQJKhIxYpFxS8ZG/NP5S91IyqmY0A+XR3FUIXs4kndRtWlXbxPucJAxYtEoaMs cEXsb23+YuSOJ57e8LAAQVxppzBI3AAZOw82jDyzbNo2p4ZF9tlZIHvQKjR0YkfpSXKeWha3KUrK UhQAxqFSWwS+jlKh8USZPyWkSMNhy47iZX4tBU9NAqaJ6q6GzagUhbPVu3t7JFu+97qNG9XG2nUk LFNOpJMjoT1SKkhnItJBlYmUk48JN1vJ83qoflrzzi1xI86rEaKGOgsu5MCSenkTz5lVBSdo+kmJ dg4dq9/xoVQrfZqegwFDiIvYiotvhQ4Fr+iB+jElREhRwpCbhhFSGHbuw4JwKiKYqLQK6XC5MLLn MTQ1mJt1cZQYORSso6SjEMoxJ2Tl3HF7JyMS3QjSSRfzZbKAjJhK5c6bu/QZxEAiwg5ZVhUES1IX 6oUGPrJm6l6CwaEESZxVT9gjCNQBkdTuLeGNS4kMPzgLllnx0Eocx4X5KD1RlDYjohyB06WuCTz8 arW+sJX3u3kTLg59yRYLwLJkuFkZec7BsviSvbDQd+Ol+o1lMhDlgWxB19v2AiFpwc5vi8x17ZpO w5LdtfwJkqsH/Na0GVdkv20TzY2FbtE39fTCpWWWqbLZpIin0jzzmDf11MSFsvFKkbAUt1tY2HMo ka6T+1O/xHtZ8NFH2dZOmH/vVLc0t6gqdlBjbCjbyqzKh2AT1UjPWD+z3tZDshQfqsjyRIYB1QDj IFSHsTJG/ARYiAQ5Rb+tB+8Ej5dktFw5j8jLl+2zmzuiGHtV5UIdO16nPLKjZ/mbBpj/VIra49od ppymfZ3q0LxulZJ6KEhsS9BrJlQlfSKhB9jKaUwOTVdSxQcBNnVYSTyYIkRpSoT82SiwgU8ZyEVp adpJuZZThXGqIe4/KJkAZfTWlFLliftYenNpFnlOOqvsS5ekBkbxyRm0gkURmpI2cHwOIEHEL0g1 u1wa6t6oWTxRFRcJdyzh0omkOdcMuelGv3bjKbM5UVGDXb1b4dPCFBXdnsJcUSWnqsd1onGns9U1 vKp3AIM3E6q53e4raJXSVEXboMzQyE7P7FvhFo72o1R0cwqT5SihMNOXznABn/nQqEaOuSwOHY+z apEXJ+mrBjLszOlP8UjmsegugOnWGYITTeI3d+nrCNVroJwJSoEiPX3hZUhIeD19b2YcxanPYlN5 LPUIcmxiZeBNCSVFPpeTdRiOK4/UyStPMTNB72w5nSmkrKkwKvqmIWczQvcPj90huT2N8FByO7GA juN0VERw7MKO49mEGhuI8YfOEaWV8H9c0CKBhX9XxR2sQQnRAfmqkxqQKhmmlA3f40TJzfC7khKn njV5Wk7YzQjE+G4tsRtrtZfXbtXYC2l1yuhGQgUpCRMCY73Z4CVkT6v42Vjjn+krNAU4d4I6XUl9 ZlbgrDPaVnhAKwhTq5hP9k/llu6hE6T82TOPbiElP0tcqi/5DPZU3IwVBW7iCXk1byUYjSKp3tjC acSkDnqsAl820a/6PhmNjI8D6lIBF/eDjWLkKcyRxm/2ueoDRXrjvoyPpVaUOJgg8I9iNXe2+ZXD GhorRqpIj72ZLjsptFFepD8eYPWhuETxIm/BEbffvJl+fY3kIqbWeTCNI3oFUkYYxUF1zkcyDe4X Oqps3UWknMkZZwR8LJxg0LvbPLPJy9ELSDNXl3KQN0KqiD5s74L0a/eTZx8C4a4+1cQgykH6f+A8 i3Si9KTOFxHPcgOuj3D6LBKy7ZdEe/tOuyX2oC7hXoCSt9o9DI6rt4S4cumqvaVFhgw5SQJ08l9q 5IU8BqnfR3njh7ww0A/FcO+YgjCErOVQWXRZapdUrPnlUZIWct88Ddk9LVz1bGpw7ffV+3vi2HSo 4au8YWSaQtR28qYme6EiGdkYyWiQI8m0XIolgNq9gNpVKDdsR41w+sA5ObM1X76dkwXaVDAqivUO JKFBprXsRFEwcDmPzfujJNJG52cGnAmTBcxrAVc6xA4IUXqu+OGGSExB0EmLdcWzkm3KVWknQwWg vEDOOoJKOpuk/qVVL9R24EEqWcWg7Jl6OFqfTT1MrWGxIagUv7WMZPfgVwGQneyBZxTrCmAh3ey2 GqsvL5j23Ep6DisqzmZyXA2+urxg/n9IiiDXGigFpAbChbbhxoIQwrQWMvH/dsmECqL5mTnHV1iY 94Bq8u1EQMkJrajzW1GWcvt0ADrZJTU6nFu3fDvpexQ1g1XCfls863VK48RWrRw9/J6gD4X6s9jU 1yYXL2165A26oPWo3HRyV2gBxNwQaejGSEM3RhQBNgrxGkZw27q8rxXj8uXa43rt8oX7JYIX1BnN eh5NUyHf2rq8F7pH0K3Ll+0LKZyRjOn8Gc/AvoYbroN8TqKUsZJTwMq80lVKw23iYgX377NxoDPS 74LV+1jeknvAKamcV0XBmUV1bAoDM+HNUvhcJZ+ri6t2zogzUsmrS1EkRbd5iqe0s3n8exjSDXPq cNOnZYUCUcGVpqhJcvsZO1c6nY80n3CfgtW8RAliP4i5zzefR70nztkoTdBLcvKl/AbLuSSdE6Y+ Erv0c7vyDL0E0ETC29lsMSFA5YUl6d4ZmNJ0WE+cR55d1PfzRHVW8XKmoCi7vIic5uE+pphOR0RS Up95XoAwuzR86GAhSrS4UhRZmhK6Y37BzdVT+m1D6Qbs+aPyzbWtmx4wQ6ZfXOVQKl+1tFwRpg/o DNX/ueAPdOZSTsqUJSeQJqn2h7qloIQ1nz0Wg03xTfEcLaelULyuAK17tJR7zkQ0HQHO5U+3s36R iI3pu2BfZpwRUX5KyX7GC4qEyLJXFM/+jiIrAyfSShBtZAN/0pVWMTv5Asw00+u1SsbFF0issDc0 cd3nl19I6yHSmL+RguLpxkr60v1CUbdieiKZDP9MOz417Tef+eYSkYxoiq/ALshFLhom1DLF+Yin 93dNHVauw/TKRtlMaXiM+NNu6h6G6nOtYaTKGD4PgtYvedzyqAs2+pH6rxunAWhzriRlrPZt3IFJ BFA4/8IXAfzdnTNxdE/Z/C+BeW5OJROKFvApzJuxNs1EAoYkzXkr8+2PVu0Sm/o/9u4DPooyb+D4 M7ubTQIJIZUktAChiKJBQtX36C10BL1TgqCchI4FDxWREghFIQjqIaCACNK8ACIqEgSVcvgKSH8p toCQoIdEUEDgfs+U3WdbErzzRfk44bu7z8wzZef/PM88M7uzGJ+rqHmL6VGGh9dJUv7Cw23mBTj5 XuXqPa/kjXjUaM7U63Guouguy/rdKf6uBYfrQ7T8WnFSUkxqrJKoqyf83KPldW9Tye7dDw9vZX13 8LEnhnvcZ2bdIux7y5TfG4PdC3p0xAN+lmXdh+x7f5trPnkjpPdc+t3W3pvgda+1exGDzZu8vZbi uvfbe0Gt3TuziBvl/N8n98vn66WHkrzdu3Rq3lm+6Njlntbdved+fEBscAkCnVTCUHOmU5JyU+LF lfxtDFDW/evtrgG/wu6y1ty8e/MW7Vt6r/H2Eq5QjujUunvb1tdUNUscr1+4+KLfnPydv0dDhFiJ NfgcV3AVIlSIBmiIe/Bn/AX3Qv4U3yuYj4VIKi1EVSRjOB5BNmYhKEwIJ2rjFvRAT2RgICZgIiZj Kt7DehzCYVQLZ7n44dSxU/tObc9dl7tk7qzsqdmzxswa+djIQX5ExmVkj5ohhrQTjqEYEaI54zJG pz8jRIR9oPzZGyPVM0SL8cw5rJZGZhEalxH0VEdBymm8cs8nU8wXa8xXP2Rsy7R4Zg91PIpKsfpY ZVqyPo0FyckiXJmSJGJ98slMccbYLmlCdIU1WpRVclcQvULGeszfzpUx1iNfoLFhjA1ziNoy/rcR 614hRjl4ySwHG5CLjdiqlIdyXmVhSqwQhfJXQLUaQqyrZBcFJUt8bSX2B4W4Ex5TZOJYwMQ+NbHN SjzexCZyrMTQp5xiqfwNRpk4ZXOImeovHx1TEzPkPPFkm7fCJrwGbZIQvMsa/ZyaCKulP3bdInfH VacWJrq7X/bvJ3ex3KPRi85YqXJGKlmZu3NRc4cRpGStYbLWKFlr3Moh2iVr5hRyhm8JElojh5XX IaxXwULYk219k21qWuvrmre0no7M3GXrA/f4snJrkzoIMQalGHH58mXv9//HcEMODofQNLtsV+9D OtbhHWhlKC0YjCH4GFtxDJ/jC3wFWwT5EI4IpKAumqI5+qAvMjAQUzAVM/EC3sBSLMMKrMf72ICN 2It92I+D8idiy7JtKIcE3IYUpKIB0tABHdEZwzAcT+MZzMcCrMIaHMBBFOBbXMFViEjeGyIRhWjE 4iH0x2K8gV3YjW9wCpfwM65ARPEP0YhFOdyCOjj/Xf53vxYZ2UDHOt+jouglt+d2pKIN2qI9OuAh 9MdwPILnMA0vYTaWYhmWYyVysREfYDP2YC/24QBO4hTycRpXcBUimv2NGMQiDvGojZtxC25FV3RD HzyAJ/AkRmE0nsM0TMcMzMcCLMQirMXbeAfvYSd2YTf24CROIR+nYYuhfMMBJxKQiPKoiPpogIZo jG7ojrvQEwMxCIMxFOORGfPbir/cngnIwjy8glexAOvwDt7FeuzGZ9iDvdiHU8hHAU7jW0RytIxC IsqjAhqhMf6EpmiJVuiDvngQ/dAfGZiEybFG/+L5WO99dmTPkfPfbVqzaaHxsMZ4nDb6u9FDXO1b FeN90+NpUdvWMi3G9b6HZ1DsBO++kpFDn5zqO1nUVPefmYvd6JMxSe31kc93SYmuZfhOq+a1Fn9r iDSmKpFL9IqtGtRriP9Nct/OxFq8jQ+wCZvxIfJwHD/hAi7iEirH0W9ALdyEW1AH7ZGGLuiKHuiJ h/EIHsMIPIEn8SJewmy8jGVYji3Yim3IP5T/8YZDy+dNfXLDPOO1v8cNg1yhFxXV2P+CeLliYubw F5P/NKbe0anpde4QqNQWX65rq0t25/O3EbWmmLGWcZ1j7u/m9FmXIhdbkBlPW5dAO4d20MrTT7Q6 zOPocV9Qe88X1Cnn1MQZ2RePN7vsZzynKImtVuKuGTYx35pHTpnvuGokJn/rFK8IZZiiJp4SQe55 /A9lskSZzH4iAlH9EllqzKITIp1Ub4joLNlbdmc4e0V24vuRaZsrE31o/T8/qDGJvEb3XqsuHx36 iYJWU3/t6uproov10iG6usd2c4/tm0x1kkvTXCcM//ESmUHfPrls+yTewK5g+Ry96IhxXhMu470d J/ANmhLvZuWMMtAC6eiNJXjDLBfL8D42KGVElo8GShl5kzJScLhg2wfvLJ69ePKoAfffe3/nVp0/ aNa4WbirXMozZ6utinbVNVlUjfIZ510XjNHy7NxcQpRXSaeIi2RXqkHgKiISvOZsIDdHryOVveph A6/VJ/hZvjGlqu8y3VXP3PYIV5tgjPBuBZK92ibjbN1769Ujl7/pvkeuCn6rv4iTdVnGansFinJF jstohe74EGdRpZIQd2MKduBndKgsRCfcjR1ViH9VIf5ajeMABe2MWmePCbs7sVOt5xvUCrleTay1 sp1l5jXqPB6JVf/VxHo18Q91C1bKk2Rryko120r1za1U3zaD1hCTMQqZQgRNNM7f42uM01uOSNnK +DRD/ZQWprh2yv8SThS3hJHuJcRYsW9hxr4Tupnxvwt/x2wsxGt4HxuQi03YbJaTXdiNfBTgNM7g e7MM2SgzdlRARVRCZSRVMspXQzRCN3THXeiBHwu/K/ym8OjBozs37czZtHPTSzxPNJ9HmM/9Nu0U SbaQsfaBD7NfnSFaXMbrSU9594qMHOdFcTmeKiJHSlzGioYrrLbLukTXDX31q4BGTnm97TG4lymK WKarJyeX7DUt0hirjCq67VPb1hirnbwzZKyrR2i1CM7hGfp/2VNT7uOeZv0ehMGYgInIwiRMNuv+ CqzEFmzFNmzHPysZ7cJRHJMxw0+4gIu4VMloM26hraiDNmiLdmiPtMpGe9KxsrsNkUU3AwMwFMNx 9tCus7s2nt2lP79pPs8zn5+Vz5ljRo4Zxp/VkPj2m733QKC+shG3dHtxpeUrW3E5+heb43QRpda3 BFx7GSyihNWW+3Ui5uIwkqsLcR/SUYe2rA9G1BTicfwNL+BFvIZFeB2L8RbWIrwWTQ4icOBmDjN1 WPOt1HNUQX10RDoexFs4iWa3URaQhufwAhZiYIoQ2U1kOyD/Cr4uOLz/04LCrYUbCze+vbFw9bLV C5bNmTF5xpwFy1YvGz2ctPAcEq2r6XZ2k4PdZBdD20Wxa6IcyvXzFrW1XiFj5WGRrbfOksxL5FFG umuazT2ulHucx3X5GP26fIR19NaMJTqNtPA9//IudWGx+iurTFopORediVDXqwi1l2Ckp985yiNd tv/z7rTTe4nykfHiJlnXjiYb8R6CUZiCxfgAF1CdMtAXk7ASn+MKyhHvFLQ3y4Z3uZBl4LJ6ULyo JgqsA+mm+36viRMBp3yp9h+OqAXy/9TEPmuH1O5nF8UNjmzRv58eRtl70K/96ylHa9erbtbnAWW6 ccSfqUVmDrkij/e9ed2H18ZUe0PhlGcv9E/KyRhVRCVcxCVZf28idkirTbuMdPTGfj/1uR7S0Bt/ RQ5WY41St/OtnSFPD4+r/acvrPd/IkQmNHfCYx6PKV9Yfa5rmsehJoICLOCglag02GvKHitx7IL2 ayY8tkCN/YtmZNmWUjVE6TauT34cCT6fBsVqRp569DedtmwtxUbXT55iRy+S3T9KW7I1T7yMj9ru ZtDeDkgx2t0pmIpzOA9nXSGCcVHdMx6J79XEUXm23qKKEHX7BYsx1jtZkRDiOc8gNWqBF13CeYyh 5HsgnW5Pv4OUqLhkrVyy1v4hWbdsLw4WQfvjHbz2J3hWK3vI/kShZWjjqglnYlVXlDTjOXo/e0tc NZMleo45b0+sGttAS9zvkKPKG08VjKeKxlPqfqfQStkHi77n7Xu1mATZ+Y/IjLdHZp78Oc7a9t6M 6MOIvtY7DJX5NKf6aaC7zITJeOajXj0h/reBENObGMfbf+AMvkelO+ir4+Y7hXgUF9H5f4RYgjfw I0r/SYgm6IgHMQKv/Um4m3wjhnY1ERIwoQT0rJWY1D3VnfDJdrSIUqSs9FNrSu/KJKzLSU+kBXlO CVzytqu19b+bcJUiq65HJBilONWj8I689loenOD5abA7/uVkrGdgOVZgJd40478O7+I9syxYsW5E XBsrMX4P67EX+5DdlGXiJE7hNM7jRzzQjPKBkShAZHMh7sRoJLQQogZq4nH8DeOxHf/EDhxESkva FLRAS6S3ImoYgqF4prUQYzAXX7aWfccTx34sPPDJRwcKcwvf1cnH3FVLZhfO/mTVkkL+eLWkcDpm 6y/1JBVZvQ6cklZf9tHKu3p3slMpO5S9YfT0oty9TWuCT2/Q7MUNq6WpvcgIVy+SHiTT/PdNw9Rc 8pxlqMPaOrYswT7w6XV1WpSSpxLGgoUcfbf+7Rc93BHq+5EnjI1k/N7HfpxDFDGKR+OmRhxl/PJR YMbRil0mnmumHAtkCf4VE64LybISliCxoZZNfKtO0XtkU5xGQv/yyMEo9ZDxmx/C9Pbe1c672nd9 vKaM14qt9a4WRkTIGE7DTOQ2k1+EMYdpt9vFBHWfPfE73Gf+hmvdj0NlD6FauWvqIYTQAbDND7KF r04SzgeCfbbBmRPtPeoX9Rl40PsM+hV/ofcbXC8ruF9WdL9U+xBhTmGXMd+IHdjb7I/4B4j/hhs1 /jLm+/AlTjX7I/4B4n9P/A0afxnz/GZGXyzB7HPJfpbsX8k+lexHXUaPtvQlMBXP4nhbr7IyWT3Y Zlo969DMYJGpHpNdidDpNq8p1jzydNEzYZ1DeGTzWLRc6SgrIc+dPaZ4JIwhJPB5tNdxU4//9zdo /MvI/vF5/GzGOYo9Eo19+LyNb8z/hTvaUT2QBdFeCA01UR8T6XNGduB8EfJ7pVXM75aOxTiMRyYm YCqexXOYhumYgefxd8zGy5iDuXgFr2ITNuP82bzzeWfPnz18dk/eHp4Nn2w+u56/VctXzV+13Hqa kfWUUIY4tR9c3/XRr4hWr7ia4ysYef1MkXPEGlftU9IGqdd1S1lnDIN8ziEGmdd5Zcrslfs7y/C6 Eux1DuF7zbmosxKr9+/n7OTW42Y8ZQyziF3ZDp7xeyZA/GSsss14ydjMM+Pj+ibHG21s4oxVVz98 OMidWPpYqDshT70L1Or5tZVIO6AZ3/iWCXmx8JCV2NjfJg6o4fzMmvJWFX9TNH9T9FPv4cKY8k7A BXhkWxJwadZQNlV+D1v/mDexuq1MZoYWiXT0Qd9km5HD+CA4P9lPDhqPVBGfeeZqQqYmytfoU415 HI2ttknWfkcDjyt+egEJTgzQ17euIdT3ew1BRMt6dALf4CRO4SIuIaGjEIlIQV20QVtkYABG4WnM xTwsxwpsxoc4jhP4BidxCgU4jbBOQoQjCVVQDclohdb4M/6C+9AL4zAeEzARWZiEFViJ3fgMe7AX +7AfB3AJ504cObh7y+7cg1t2G3/GK/l4MFf9ezt3ee7bC+YseD53zsHdBxfMkUFVa2tL+S3jUspr j9orx/TU7w6RrYL7w7gw2Sp4f7LkfTYe69vSqC2BHjCrLl97SxXtc29KDKf5ryhxv524DMRKM1b5 ZryqmvG514xHltd+vqzWnktqdTivTilh4oeASwu8ntMBp+SpCb0FCYs2ss20xtZKDxZT1QUwBKea 35oy6lcb2QeYmuDZBxA9NGFP1fRjvVwsszvDfI7r/sbpB+5rOWpzsBbioVRtCqssrTcx0Ysq2JS+ qo1Gw2OUCG7suiPE+MwolVYhVf0ESWtM0bbqSdXOQnRBV3RDd0zGFLwNWxe5/5XhnLov89Upi6wX csfOVXesxwJeVhNei1YGj0X/Rga55/QS4t6/egk59rsqIfKhlGwbf0YSMa7S2SgH1dAeaeiEzn7K xl14FI8hC5OU8jIVq7Aab2GtWYbW4TCOQFCetC5GuQqCE9WQjOqogZqohV5Ix1iMw3hkYgIm4tzp vKN5h/J25R3a8dGhdz/Kw6G8VXmL81adm8+0+YdmTZ715KzJZuKjQxWM1llvA+O8G2mPu+riXI21 b48xTm9V1SNBrNW+F9nql6SVD3WtJ9LzSDLCfS1XvZewrM+xxPeY5e84JVLk/rfDYcahpp/9+xXe VUvnOjWxVk2sVBML1SailzVWtgo91FbBawHKPOrgr0XOTPy91TdaYX3L6/42tlyEyvhmYT3exxf4 0oz51xBdkc2GwwY7HAiCE8EIQRPcgTR0QEd0wjAMx3hkYgImIguTMBkbkIuv8DXycFyuj1Jul51Z BMm+jzw5R4isITOM+xVL49y/zp04dmDHR5t3rN3xUc7S148pfyStyebUBR4Hnl8yeJ6bOd3Per0M VJPj/bY6ssWxUxPV2hzn5/zUaG2utc4X108VKUW9zz+GG3+IqefxAwTmf8Au/yNLn/9E2fvnB1p2 6dSpfY8erVsnterevE0P60cSivqfqP3/9sP1/QWEmLr6BoSHF7+zbsBBtvPe7XlHpZ3+Qc38pvVC HsMXq8dwV59fDrPklNKxxlUb/dprmUgj0cLK8tlzDnf+FvKIWLu85xHRfTQsHZtQY4yzdGyUZmS3 nsc4y0R6j/vFR8Oy+umS8Q356EUj9Wsk6tFcny4CTjeO7v7OCQ78lvsoIlg9FsvjbqBj7EU12j+p m3VG7bEdV6e8ar2QxeWlgAvwSDxvZQt879b//6BcZ/MT4Tnlf2+9UP16ov5+QhuJ0BRHTErT4K51 0kJQo2uoqNBVE02Gy25C5ZzxtyblbGteJae5oyqqZTd3JKN6jhCpcs5SKVrd7LJak+FyaZVzxpF7 C7m726vmfGmrlv2sLTm7oa16TkNbuZyPbfE55bW6okyKrahZEu3es9xhrijSWJexdSWd2XsX/zF4 DvJjkVbF5ip6CNm1Pf+JC+99GvnsOLFMdFhaWtZcWUblIfV+TvaGiQcpLg1EY9FI3E6fM4XH67bq euK6rTpVXLdV1xfXbdUNxHVbdWNxnVZdVz+zuk6rritkH0w9JGkv7tWqPC6/sFx/f5DQ7IlVq5FK /Dd7ZwIe0/XH/XvPzNyJxFb7FhFrS8W+a0OsLZFUMAmxpITElsUW1NZKUGqEEhKCxhKCRFEJUruK VixFiapEUmvJ2Coikvf7O3dm7q2iifr3eZ/3eW+eT+a3fOdu555zz71zz0zNtv3s+EfZ9ETzv3ho uSKNqrPMudEFO0HUWiT882YdPP7M8q4ytEOGmTfNVlBPNapVKn9Tc/Mfx0GUErQmOqS+1dqaaD/w ZWFWzQQ7E32ZiLYjraGzSKe6AlHeV6VN5u7mzKaC3tQAMo022+XrToMdDrC1/ZadfDorNr1A0FOc z5mkZYQhjlVNBei5vqjMba6sTQc7QQjEIoYc7sKfUD4JvZAfknYyyi6wT9/IH7I/eHK+pnHNmvZH 6q4ZUKfdzG/sbv5kq9UOjP54XdkDXu/UnPe5Y/vaaxp/M/Nerh+rJbLPmcbpXZ/Z77iP9G1+rnWd Gudmlhn52Uy79Qtq51Ryj737fNqNiXtK2VZpvMN38/RHT56fig/I/b7X1cv2o+/U/DF4w66ELQf2 HFq8+pjJbXqtuBVL03/4tumWyNX3Kg64kDi3zqnTXTtX/fLeg2Fn+9Xbdv7sieqN/dzLxu2aMP/K vO2dP11zfvYP+f3Eggs90h7v9PU6kXuizbgVJQfGDDvbecC2vle//eiPrFH30z/t63HekFnzSqNl J3ZV9fzWadmE/inZrt2lu5NrNrqS22/yJt/ZSauqRPxy+sSpnZsbekX6tn84+keP3O1td/16bvjH HzSolSRF1NmdNfXRHc9zE7YMMnbPaV/5yePErbsL3hvaZtPqmAjPcfO/j/51VbCLe/a26V/sj/6s 3uw7QWMePGkzpYd37VOG3i0+GmPv2+NpsiFzdvyGGq2fxT3NWL9+9/FD56rs3dQwY3b8gNCkjXeX 3Rs3aPiimOBzKy6fch0Tn/Bk5OOoU7/OGTtycNh+/zl7wq82T202Y0le2I6GbX69HVUm48H12XbD PUZUXHAy6vSUDr9lXZhUbqH9/ZkT/tx6r87gx0m7p+v3et1+/OO4AS4bp4w6/3N0tU2dbLv+Xv67 6obGwdfW3Z98oUS1u4agCzt3OWV8kupwK2rAmazFfzT77kjSk7ulDz09frjP3KQJveKaGX82LX02 pc2Dj+ODb3s1WfrjdNvwGXNG5t4PGOy6oO2G3LidV+e3r214fKT8ntOTLhyJHbo5LmNS7VIpfe0D Q1s+WhFZaULPXS3yKmQ5Jm1us+30zO+/r9vV3qNEiau1IHHaFng29ZN6zZvcXp57rNez8yQ6UX1z m84z3MvGLNzkVrxAmNx92+Yj5SeezT6NWY+MyAioh/eVTzw0PNeVZj2mSd5jelc1g2fH/d70pqVh +5djfZZm2Nrd7NECc+7vN2dqWsvrsc1OdbkxdceBScYtDb4wHR9Z1ftiePkSwX3v1G5adeeZRzHZ cfN6d/viEWJTwucMkz4ICnV6tKrFJ7f9Tp83tVuMiHl73p3Q3G9UTsPjnZp+cT3RRZObyyN+OdUn dx+efs223t0LB4u5ft22yjrjFj931+qLK/e5NKb5nJulRn5z7kx62cPOHSh0zbbdrUl+iAyRt6h4 /cDQk4+immNxCUdNvyzB4n5PPGSb+zvN3NM/Z34KFtfU20ectqnux/Ylbl87vjhm5Nw9pjYNIprt G37hhE/L4x+l9p62ZEc/5665medykmNHDd8aHfLBkh19bmRtOa/bjzJZt23FrrbpE7qn9l6R4hVX YvqAwwEdBzYb1eKHUdEr19+uN2KrlINiiYHKu33H4ZvKpnjdqT3iz1YT0+I3ILbZtHnxjnMHs7ZM sCmgrcA7+17rW3fEJvsUr1H18p0OX+1FofS+tUdsckWoWX6Fw4PdEFqaubTeiE2/I6TL//jw4J4U ylhaZ8Sms1lbdgkzHHtdqeZ1anLGJ7t+3buo1h1dI0PDn7Ni10dOPx0x6ObG6Ce5mdiRFfcNynJx a7/WbvyGinvSJ7XIW3jOPiW0ZIhL1ePrKqal78bxda7h8dDrIS6aWLdGzQ8EoDh2dXNKDDn00dRN kw4N2tDG3zl72tCNz0feHhm81tattVZ/K7RTzupK+eJtTZZLneiEshNP27W7P6ly/sTbd7NcdNEJ lVuesYu6v7tS/pTbj7Nc2kQnsGU/2zUwGarkf3r7aJZL5egE4eNbobocu6DpueETWrcZMXBl+2+/ H/c8qu2Gn+5kxtn7rtpZL+hD5+srJtV48Cx1eucLP985GvfJ0dwq1z32ep4ftjqt2cUZP+6bG5kx 8Gb/41Wq9fp+44+R5yY2HGZf7bfs1ICGX05+3jSqfFz3kQ3/qHGo3e2PLpf8cNeovRVG7H9QkOb0 oPp2Q7tdSQ/i75afWmva0fyKew/dH7nt4lcNHo8buOKX4SkV60S0P7N02wfNUt28+p+889mJpaOD D8bOe5ryy3srr9ofCSjd6IaQ8+UPxitpV+w3ZK8b3rbZKlOv+rGPV339MObJjBGDr7a6kvyn8/D9 zX1SJmwf3PTR2V7tpo5ZXd85fsj4/CNxSRtHnYj7etrDw1PrTmiZvOT7n/9MDdp4t96pz6sPmrc6 u3/qihuLnqxqN6ag2g33oaf+jEgceGV15pWH66cMqD4pe7yv3bAb5d1Gr+rr+Wv01kvLGk6eN8F+ wM67k6vfKegR0uxwz84XOuU/HexQ+1y5q8EuozdeNEQ2efRkVJmRxRc8/jn/3QelL1ee1+DIzTl+ ZepLbcKcF7U/MlFKt/V69EHzYkt1H5QoqAtF0jsGP7cCO1eXXXNKhs1oMXnuXe/QBs1j9nsvcT+5 JiljxKI5F3vV8j641hA5O/hAizyP6N9nX0zdHX22WkwBJD+sOdHj2ZyUTqNvzAgMff4oG8t27lMl fyxmPLmiIWR+vqurS7KufFhBW8x4X1iDLTEzvJa431nzq8kQPudianZgaJdHdi2K7bI5UXyGEyRf p9vuuDliZJmRFX5qmeef5fjdw8bbGi/83n2Je+aa46aHWNCI5tsaL5geW3dt2MHAww49q3/ablK6 bfKtgDO1+wTc9ND/0ulUTsaK5sYfwisG1j36/J38lbXr5F/J93Zt+XyI68q2967e2vh8epZjnemD vddWfX4ysvWEX7PH5gw83unjvNREl3a5o5oH3U4sOBV2Naz9uiOnjpSPPNvqzJFNmfm+YVdnIhJv bOD5qJjbXI8fpl02uS2e83VOvX1JkTGPVvtfOxdUEDAozblz9d7XHI6U//NM9nl639Sw/Uvwvquz GoyOmdGp7MaFz2Y0zzuJFciv6+3T8HkVWqf9w3Ia0Ar8nujy3vPPKNKocV7ryd3nFRTfZnr3eXGK OA/P8UiB5r3EQ565TWi1ZxwwPaR3fZLoUnJaT5pzUpjzXCzLYW6DR+tOncXSp8e3bd/Mqcsfk8Un a76q5TUos/sk167roo7p5gwKrPVB+1IbjznbD5u88Yt7kR4dW7mWrxZTcTMOywmL/jS6OzhWLJlZ bGnC6kGxR5yH5EyNfbLIbu/92bYh8wfFHrg6NmfApt2L7eIzi/2esHDQuz8MDsiJ22RYYhdnmt3U s3OjrzMatcybfO7h8dCkkEOjl3dp9NOxGb+aNnq41au4IaNYl8Z4yyGHgBzdOV2Wy4fRjauFnbE7 fD+7ad7o26ODfRpHn9ZP+dlumimgRd7Yc1eOh0bdn90r0D75dLGCKYcDul1Z6J0oufnpDKfttpri m+dtOOeaElo3xEXLpjh+PiM8Y8A5732jykxvdTLCFHp14MP1Vw8/O+H2rNsm42K71RnFHA4MvhVa yuTcPG/auWfHQ5NDDl021ZuSMSbPuWp+y9tjsg5VDTkkhYQOujhz/xnTL73j61S8kF6sR0abKT7v 5Tc93Gi9U52K1zOLjZs5qdTJaoO3bdpx269u4i8lRnz+7IrdimL3xlXt9qBF5fAzVSpWm3Lwq3KJ 1XtNqZt46gP7rFG9dDEt+gYuGBRra/vr7Rp3HdZ+6OJU7VjZ+j7Oye7zUJJP3LMdK07MLFbeVCHZ fdb+K6bdvQPqVBz0Q9kTPvbJ7gv3/2YyeMTXrdgvo5hvwtxB7x4ePDrnYeyNcLtx92dfajx/0PKv ChIz3DZG93Lqebjsl0OqJbvPdv7NZBdrdzz0s/Y+1FemKwrq91K3l7rqksC/QJT3nM1f9UtfICoU F+SrjpIC9cL51zHSVyUK5q/wE8oJ/ItShQoC/9pToRKoDKqAqqAasAfVgQOoARxBTVAL1AZ1QF1Q D7wL3gP1QQPwPmgo8OHHQiNA1yt0rUM3E+iqnrrldJ1LVwetQGtAV4BtQTvQHnwAPgTOoAPoKPD7 z0InQb5U6wK6gm6gu8AfbxU+Bj1AfkFBgStezY8v8I9GPwG9gQdYCZ5D0w+v4816en6sPxgA6CPw gWCQQFduuGYAPuBTMBTQdZEvGA5GAD/gD+hzu1FgNBgDxoIAQX4sMQgEg3Hm5X1lXodJeA0Bk8EU Qb4U/QxMA9PBDDBToHUPwN94lEUXzHc85kXvKPxUQdCJBeaJjgmpmHzb9oCc7qrWDimoMcfT47Do SY75oejO2APj+V54s8lWYNbl0/TP7xCEnuBeVdk2YOuDsec78+voCdi/vnw/FHaqguVTfSjK8mlK Xya/uqH0R2KZQ7FMd14Wo1//xhemCoIoUh2kZas+UvnL5O77Yxjtd8v+V+cG8/sFTfgtuTagGWpR m1fM52VTJSzfsu38SvurWcOi3E69E3Zb2CwkvXeTNJblm+78FPbi8kXsgdH8qH+z6U3Kn6Zy5lcN 9npv1PJeQp/X6l81lcTyqc2kw7mwy/cCrIVsi2h5AnDUBZqPhKJOZd5g+6kALI/DU5vBzK+Ezmy/ rv2n/Kvaf8q92P5TrKr59f9P/3dNonz6f+NJRKlqbOVj/8W6T+d1V/+hwQHjAoaPV/2iaw13+cdn +If8vCfh6vGXEB1Qf/sBWOFRm2+DXrIG//zFKa+f/qSvQOHH7uAD4ZmzK9Nx/UijEbqIH/uMrTER 0M9Tufr6BlN9+BjnqrE4W040vw5D2xWMV1e8+vIzcdGm/ALqc/29CHi/7PzJ8yudqpZeEmEjNHj/ 6Tbq7+wT5XpH+bmCvPWLBLk/FivIfbhEQe7DHRDkdum4INfl04Jcny8Kcp1O5/GVTVrUofkho5lW hd5Rja8B1ey6UinUYipbeanyZLnnWcyssOEK2oaK5kgt8/moqtCnl7t7OepdiNRLKyhw43valfdr bM1qW66iA/GR5q/zpK0rZY6U4yotWiF+R9u8LtRe8Vvi3CrOAm062JGlFamloq3PY/zoFOR909B8 RziX6azzkOOiNU/rYC85CiaB5qYoXj4/xl9N1vkK1snyLtpztAUVzHuSRo7EY1ZNsHkdbeT3UV4S 5BpJ+//Zy2rlnTLC4qDHkzrADNTb+vf0eDypL5C3o7F5eRq+J3g3jJFVzrp3mEjm39ZGI6+Nv/7l a/P6uSl7ZIVg2WKtdU+Y6yaT4zqurqqN1jnqPZkn++v+01r3l+zrCrXkv5ahZR6ieUknWRssKVCn XhIt4WVzlvd6ovkMukiecQdBoF+TGlejl++kGr0DxviMFV6+13XmtX713ncSKwmW9af30hmxqe0W 9pWOjtR+6p85k5rjaK+NWlMLTWFtgeoP+ZVx1STPSRTUe+LVZdsPwWUQD2Ay6r2TZz3C1MeNxOdD a1obzbqBeaGcZOh/f05P/O/BMcA2MFem6DsjLuPFOkFLtILfkmOAbWCtVfpGiMt4MSdoiZrwHTkG 2AZWS6WvgriMF6sMLVECfnGOAbaBlVTpdYjLeDEttESO6MmecAywDeypqOhNiMt4sWyxPycT/jWO AbaBZan0lxGX8WJp0BKp8E9yDLAN7JRKfwxxGS92FFoiCX4ixwDbwPao9NsRl/FiCdAS6+DHcAyw DWy9Sr8ScRkvFgUtsRx+BMcA28BWiHJJi4LSRv21Lmr+1gq8eGRV18tHVi39mx1ZDnovVsMMtQY1 OT3h9+A4wHbQK0eWg74z4jKO+k7QEq3gt+Q4wHbQt1bpGyEu46h3gpaoCd+R4wDbQV9Lpa+CuIyj vjK0RAn4xTkOsB30JVV6HeIyjnottESOWEP/hOMA20GvHFkOehPiMo76bLEmJxP+NY4DbAd9lkp/ GXEZR30atEQq/JMcB9gO+lMq/THEZRz1R6ElkuAnchxgO+j3qPTbEZdx1CdAS6yDH8NxgO2gX6/S r0RcxlEfBS2xHH4ExwG2g/5tHFl0VPVjb95meaGGW1otT7QGnuZWqoe51eqJjCs0Fn1n2JZWqxN0 ncytVEtzq9UK+tYqfSPYllbLCToncyvlaG61akJfS6WvAtvSalWGrrK5lSpubrVKQF9SpdfBtrRa WugIaqWemFutHNTsp6KiN8G2tFrZ0GWbW6lr5lYrE/oslf4ybEurlQZdmrmVOmlutVKhP6XSH4Nt abWOQnfU3EolmlutJOj3qPTbYVtarQToEsytVIy51VoH/XqVfiVsS6sVBV2UuZWKMLday6FfAc3b ObKidfJRFaN7kyPrG50XW8PxZKs5PUEP+ERPtlbnCo1yZH2j64w40Qk6ohVoCZ9oBX1rlb4R7EaI E07QETWBI3yiJvS1VPoqsKsgTlSGjigBisMnSkBfUqXXwdYhTmihI3LE1bon4hpOjrhW91RU9CbY JsSJbOiITHANPpEJfZZKfxn2ZcSJNOiIVHASPpEK/SmV/hjsY4gTR6EjkkAifCIJ+j0q/XbY2xEn EqAj1oEY+MQ66Ner9Cthr0SciIKOWA4i4BPLoV8Bzb8/sq6b2yw785H1Qv/XekxZeqmUr6NhQo44 AfX5C53lSLQs7+VHpC3fLqwNC+F9mFtiCLPEbomzUH5rdDZslu5Nt4K24Lr5nE5bUtitoG3Q4HxX tK0IwfpTaxbCbKxbIeptcEbNEUX9LbGwW2FZG3Vtrqp9LAbpZoqxGvW7X9XzL2yPna5Em9qeE49q KMZ77ILSU39Vz7wwcy5mnvN4/nRVQ7Q4/2ZulvVcoKUY/71q83oSr5rzy68gZkBYEQfAI7xmaAt3 dahcSc3WzNbIV1L6DoW9ktKYS/rV138v397D2vPi/6ZcymHOb6NcSvO55WnOi3R3Rv718Dq4piuP taSyeX3JWGvTT8qVtu4VV9qSuRZ01IVLflrhL7XAZL5WVa60pVfUoXd0orRK21pbmDr0X1890/3m prb3tX21tAcsv7ncEHuzFvZkGaEJ9uiry/7lx3o+gh8ijYZImCoVvX9QwCZLgkZG1IRIjDMa/ihO ARsNxkiKfhjiMqJmKLSEAX4/TgEzAE+V3g1xGVHTC1rCBX5HTgFzAZ1U+raIy4iaNtASDeG/zylg DYGTSl8HcRlRUxtaohL8ipwCVglUVulLIy4jakpBS2jgM04B0wCtSv9MJ2hkRE2ujnHuwb/LKWD3 QLZO0V9HXEbU/A4tcQn+RU4BuwTSVPoziMuImtPQEkfgH+YUsCPgqEq/D3EZUbMXWiIe/jZOAYsH CSr9RsRlRM0GaIlI+Cs4BSwSRKn0ixGXETXh0BKh8GdzClgoCFPppyEuI2o+g5YIhB/AKWCBIEil 90NcRtSMgJYYAL8/p4ANAN4qvQfiMqKmN7REV/hdOAWsK+j2FvpDCyW5Ji3B69A3qElGyUdaZCZc GiIt5vSB78ExwjZKfSVF3xNxmXCpB7SEM/wPOUbYRqmDSt8KcZlwqSW0RH3473GMsI1SA5W+JuIy 4ZIjtER5+OU4RthGqYJKXwJxmXCpOLSEAL9ARxhhGyVRpc9BXCZceqJbzLkD/zbHCNso/aFT9JmI y4RL16AlLsA/zzHCNkq/qPSpiMuESyehJQ7CP8AxwjZKh1T6JMRlwqVEaIkt8OM4RthGaatKvw5x mXApBloiAv4yjhG2UVqu0hsRlwmXFkJLfA5/FscI2yh9odJPQVwmXJoMLTEG/miOEbZRGqvS+yIu Ey4Ng5bwhG/gGGEbJS+V3h1xmXDJDVqiE3wXjhG2Uer8FmtGWQg76YpeM96xcdG9Y9OBU9rGmaMF GviE1qajTgeNRZ+nd9Hl6TtwnumdOdngHnwiW99RZ9Ir+huwbyBOXIeOSAOX4BNp0F9W6c/CPos4 cQY64ig4Ap84Cv0xlT4ZdjLixD7oiAQQD59IgH67Sh8LOxZxYiN0RBSIhE9EQb9SpV8CewnixGLo iDAQCp8Ig36OSj8d9nTEiWnQEUEgED4RBH2wSu8P2x9xwg86whsMgE94Qz9Qpe8Duw/ihAd0RDfQ FT7RDfruKr0zbGfEiQ+hI5qCJvCJptA3U+nrw66POPEedIQ9qAafsIe+ukpfHnZ5xIly0BE2QA+f sIG+mEovwEbnnVMgOXMeggdSB85DqaPukaTo78C+gzhxGzriN3AFPvEb9FdV+guwLyBOnIeOSAHH 4RMp0J9Q6Q/CPog4cQA6YifYAZ/YCf0ulX4L7C2IE3HQEatBNHxiNfRrVPoI2BGIE8ugIxYBnD04 iyTqU7u8pZZguFZuCUZp36QlGKl9x8aPU9pmBEcLNPAJrY2/VgeN0hKM1Obp/TjP9CM42eAefCJb 76816RX9Ddg3ECeuQ0ekgUvwiTToL6v0Z2GfRZw4Ax1xFByBTxyF/phKnww7GXFiH3REAoiHTyRA v12lj4UdizixEToiCkTCJ6KgX6nSL4G9BHFiMXREGAiFT4RBP0elnw57OuLENOiIIBAInwiCPlil 94ftjzjhBx3hDQbAJ7yhH6jS94HdB3HCAzqiG+gKn+gGfXeV3hm2M+LEh9ARTUET+ERT6Jup9PVh 10eceA86wh5Ug0/YQ19dpS8PuzziRDnoCBugh0/YQF9MpRdgC4gTBdIIzkPwAFeYxEPJX/tIUvR3 YN9BnLgNHfEbuAKf+A36qyr9BdgXECfOQ0ekgOPwiRToT6j0B2EfRJw4AB2xE+yAT+yEfpdKvwX2 FsSJOOiI1SAaPrEa+jUqfQTsCMSJZdARi4ARPrEI+nBo/n1LQNed98y95bJS4e+72WsEaRx6kpaW w7K81993q6G5j96+INXAVZslFiSVRt9UkIKk+4W+e2hZG3W7VVU7Qbqlw7wLdc+gsNf69NxZU9s+ 0gda2iO4zGeNX3t1X/g7O32knW/xjlsf6ae3cMetJHZ0MjZ0EV7n64p6x22xZvF/cMdNLhF/3Rgb c4lcelsl8kA70uZtlIh8ry1N62/zJvfaXiyTVL18rn6ol3vtL6+hOmudsNTQdH2oNl1f64X7+7qX 1lCdtYaa9HPxLjqLztVaYmf0jrp09MFMeH15DdUV6v5+P635/pa28FsxgflpM0HRtiKEeWk98a4Q FmLdigzYgsZPm4Hcm24FPXlAW0L9pn/6fFg+ol/sN/Vn79h4ckrbGDhaoIFPaG28mM5G+XwyT9+f 5ek9Oc/0Bk42uAefyNZ7MZNe0d+AfQNx4jp0RBq4BJ9Ig/6ySn8W9lnEiTPQEUfBEfjEUeiPqfTJ sJMRJ/ZBRySAePhEAvTbVfpY2LGIExuhI6JAJHwiCvqVKv0S2EsQJxZDR4SBUPhEGPRzVPrpsKcj TkyDjggCgfTkFQiCPlil94ftjzjhBx3hDQbAJ7yhH6jS94HdB3HCAzqiG+gKn+gGfXeV3hm2M+LE h9ARTUET+ERT6Jup9PVh10eceA86ogZwgE/IT6j88+fPfz9yX36GvC9t0kyT/MTCnCH/67vq9OR2 U9szUqhINbZ7QLD/lICx431GN0erWQmtpqO59azxmha08G39GSmRyW195bfQ1p+RzjBq6wOGDx/n O57Wt5Jgjxa/qG19IzSHTyBeh9c22v87P/GSP/2oqg3V0Nr18w0e7z+USsmBlxKVz9spoeaaUM3b K6GqmNvbKKF7zHwG0MhXzoU9jwmaCUzQ9Cjieay0JgTv8mT3mfJp+332ET+PldZ89MbnsQ+xxOkQ 78Vr3D/cI3/ZeWwPm6VNYjO1iWwGZzfsnWw+WKDdxb7Sfgd2w7bod7GliH+N/BLtDvAt7O0sAiyH vQKxFcgtt+q/ZWsRX4P8am0CiIe9lcWBLdptbCv8rYhvseq3sV2I70R+h3YLiIO9me0GibCTEEtC LtGqj2MHET+A/H7tJhALewP7CZzUbmSp8FMRP2nVb2QXED+P/DnterAOdgz7BVyEfQmxS8hdtOrX sQzE05G/qv0GrIW9mv0B7mrXsHvw7yF+16pfw/5E/DHyj7TRYBXslSwHPIWdi1guck+t+lVM1K1i gm4lK9BGgUjYy1lxUEK3gpXURYIo2Bb9ClYB8fLIl9NFgGWwl7JKoDLsKohVQa6yVb+M1UTcEfka uq/BEtjh7H3QULeYOcF3QryhVb+YtUS8BfLNdYuAEfZC1hq0gd0WsbbItVHueTMXxDsi30H3FVgA +0vmCnrp5jM3+G6I97Lq5zMD4v2Q76ubB+bCnsM8gRfs/oj1R065pz6XfYq4D/JDdGEgFPYXbAwY q5vNAuAHIK7cs5/NJiE+EfkJus/BLNgz2WQwBfZUxKYiN8Wqn8U+R3wW8jN1M8B02J+xr8BC3TRm hG9EfKFVP41FIL4M+aW6qWAK7MlsBYiEHYVYFHKRVv0UFoP4N8iv1YWASbAnsK1gm24ii4cfj/g2 q34i2434d8jv0o0H42AHsySwB/ZexPYit8eqH8cOI34I+YO6IBAIeyxLBad0Aew0/NOIn7LqA9gv iF9A/rxuDBgNexS7BNJgX0bsMnLKp6GjWSbi15DP0I0E/rBHsHsgW+fHTPBNiCuftvqxHMSfIP+n bjjwhT2M5YJnsPMQy0PumVXvyzSSL2PSMCZKQ8GnsIewkqCU5MNKwy+NeCnrZ1w+rBLiFZGvIA0G g2APZFVAVdjVEKuGXFWrfhCrjXgt5GtK3mAAbC/mBBpJ/Vlj+I0Rb2TV92etEW+FfEvJExhg92Nt QTvY7RFrj1w7q97AOiPeCXkXqS/oA7s3cwPukgf7BP4niLtb9R7ME3ED8v2kT4A7bDfWHwyA7Y2Y N3IDrHp3Ngzxoch/KvUCrrB7sAAQKPVkQfCDEA+06nuyyYiHID9J+hh8BLs7mwo+gz0NsWnIfWbV f8RmI/4F8p9L3UBX2J2ZESySurBw+OGIL7Lqu7AViC9HPkLqBFxgd2RRYCXsVYitQm6lVe/C1iO+ DvkYqQNwhu3MYjkd2CaOC5DPTEXvFyv9Y7n3VJqf+QRhHz/3iYzV9Jg8brwvDXjm52Itz9LSXtXL /ftIIfX015FFNI9/O3Ls/4VJYx53+pEwVhjOR5UXbaLxp9SnoxKS+zX/PNF+l8y2u+DPxz5PEIIF Xz6KvWjTm4x/zVfpOvElB5tHfdcQ+mIdijKOj8Z/05FFx1phl0/Hq7vZ1gkefNT5GMGHj723lEMw j4zH3gng4/1fNb0rMKGo2z8R7HtftmeBz8EXYDYIBWFgjiCPL5wHvgTzwQJB3ncxeDUK8rjDcIG+ s1Xgv6byNVgKaGh7BFgO6Fm1SPP7vsHrKhAtyN8NuwasNefWCcoY5A2wNwryeMZNYDOIA1sE+QcG 6GuI40EC2A6+BTvATkH+NYLvBPknChIF+XcL9oC9YB9IBt+D/YI8PvIgOAQOgyPgKDgGfhDkcZMp 4AT4EfwEToJUcEqQx1OeEehHpgThZ3AOnAcXBHmM30WBfnJGENLAZfAruAJ+A1dBOsgA10CmIP9W ze/gOrgBboJbgvwTKHcE+pUbQbgL7oFsYAL3wQPwUJC/q5l+O4W+je+JIH+x7lOBvrtX4D+K87Lx 168bf5oeuvrBUze/0nHhNkKDejsuNUZswfvyWHDKDwH0Tj9BPqbpeKG2nsqS6sQBQR4bTvuN2gda f6ontF405o1uvfNx5KI82rSSKM8vSyt/RwidiV41apjy9J4Xx+gKyP9TjpbRTBhbg2z6vpKXjVEW sIwOyKVPnH+A9GSbvs/uNO3RIZHsmQEHRs2ETW0ZXdl1AyMbyG0AxWyEeaVHFLeMq91anp7f/Kdx tQfwxtPsxTMVLb0o42p9/yfjak+zA/yp57czrpbmpihePr+ij6ulMjBC9w5yB1kRxtWeVMbVJutt Q97OuNpuorw2k9nL1+b1c1P2yMvG1Zr38AvjatNFH3YcrdZf99//YlytSfDHkk4X4R7mzf/sHqY8 rjZLSBP/Nq4WdU/CcW4HJI4dtqc49qpdEe9A0dmBzpAnzKj3zuue3aD51NZIwnHzXwrnCP7LKPmD nBROMmwZJb+Hk8L5DraMkt/BSeHEw5ZR8ls4KZxY2DJKfj0nhbMWtoySj+akcCJhyyj5CE4KZwls GSW/iJPCWQBbRsnP46Rw5sKW+adrjX/+rH0wk0vuU/ZmJTcExz3hwzkCW0bJH+T4cJJhyyj5PRwf znewZZT8Do4PJx62jJLfwvHhxMKWUfLrOT6ctbBllHw0x4cTCVtGyUdwfDhLYMso+UUcH84C2DJK fh7HhzMXtsy/LzkqNap3b17nqLbJf0qNS7Hm5dom1zylxil5ubbJNU+pcUperm1yzVNqnJKXa5tc 85Qap+Tl2ibXPKXGKXm5tsk1T6lxSl6ubXLNU2qckpdrm1zzlBqn5OXaJtc8pcalvKWSuyrKpXZN fJOSyxCPC+mcI1YyRKXkMsSDiBHJVpT8Hth7ECO+s6Lkd8DegRgRb0XJb4G9BTEi1oqSXw97PWLE WitKPhp2NGJEpBUlHwE7AjFiiRUlvwj2IsSIBVaU/DzY8xAj5lrJeAtjsb8R5DoXby65F/of1jKz 9BIsn7TE4tooVrhYxBGB23AVRbUiBq+WWIxwge/vbXh9062gLaAtoTaftqSwW0Hb4Im2tWhb8TPW mWr2z9geS6wf28Zb6X4sptBlYVkbdW2pqo0VzogzhdaF6nkVtsckP720UnBRjZ9Tekqv6hkV/lPE lcJn3GuIbfw3c7Os52y+nvJTVmX4eupfs54v78HNgK8X5fsMa8WifMp78z/7lFfe3mXiSuF/Uy7e Iv911n9dLqX53PpgbsqzVsV539qOl83rS8Zam146rtFcR18Y13hQbMJCROEvtaDw4xq3iyL7UizK Exj/3dWL/Mn+ejFYpD1gGddY0rwnJezr4kU+1mnl94uUFYT6rOjnX0F8lxEipzZsGSXvyAiRYw9b RslXYYTIqQBbRsmXZYTIKQVbRskXZ4TIsYEto+R1jBA5WHUzSj5fJEROLmwZJf9EJETOQ9gySt4k EiLnD9gySv6WSIic32HLKHmcO4HI+Q22jJK/LBL/h70zgYuqahv4uXcGGJiBQawQN0Yrl8xPlnzd CMhUslJx+9K0wFgURETAV3BjysQ2l4os4RWXXNBMSVMzFxYVN9RJcReBxARcmEgURZjvec65y7AZ IN/7e3/f75vf7z/nmee589znLPecc8/cO5ejXACZIdtzOISjGEBmyPaTHMJRjoHMkO1ZHMJRMkFm sJrmpLpv+sjai2ctyw3Szs1oWS68jkdcKe1BZsh2Jx5xpTwLMkO2O/CIK8UOZIZsV/OIK8UKZIZs V/KIK4WAzJDtVRziSnkIMkO23+cQV0oZyAzZXsohrpRbIDNkexGHuFIKQWbI9gIOcaXkgsyQ7Zc5 xJVyHmSGbD/LIa6U0yAzZHs2h7hSjoLMkO2HOcSVkgEyo+VaznZIM7mmt5xUiCKVT6dskciQIt8E 8ibQIeslZPtakNeCDkmWkO1JICeBDvlWQrYngJwAOmSZhGxfDPJi0CGfSsj2eJDjQYd8JCHb40CO Ax0yR0K2x4AcAzokWkK2zwB5BuiQaRKyPRTkUNAhwRKyPQDkANAhfhKyfSLIE0GHjJOQ7WNBHgs6 ZKSEbB8O8nDQIW9KyHYfkH1Ah7wuIdu9QfYGHeIhIdv7gdwPdEhvCdnuBrIb6BAXiZZq2bOElj27 WS07Flp1DGWLRKxZy46FVh1DWS8h29eCvBZ0SLKEbE8COQl0yLcSsj0B5ATQIcskZPtikBeDDvlU QrbHgxwPOuQjCdkeB3Ic6JA5ErI9BuQY0CHRErJ9BsgzQIdMk5DtoSCHgg4JlpDtASAHgA7xk5Dt E0GeCDpknIRsHwvyWNAhIyVk+3CQh4MOeVNCtvuA7AM65HUJ2e4NsjfoEA8J2d4P5H6gQ3pLyHY3 kN1Ah7hIxLZAy8Z55CNhtLfiG38ereIIDzNIXjwSxP09+TxazVXCLIXwas5Suu6yC29Jx+cufGWj VwPEaMyPw3bKbjCKE96/Rc+j2V0x7flQTrgrxv3Js/XGn6m1579qwTPo9nyi2Rl0q2aeQW8DpSds fBXSy1xTz6D/nfcpneIMvFAjX7dUjWzgTvMtUSP21Fsyd4qvee5s2ahz59p1ksizsWcjz2ZV9R+h da+MXs3rudX8L7XW6/7uyugN/AL4Fo4kCzhRl8TvAl06twHS+o/Qv78yGtfrIjl2vhrXhFwYSAxX ATQtF2dJFHcUvnWWzJdycR9kwsVw98HW3FzgL02YE5wH/N3vFebXd8vzgGPAUcoWCXm9fhPIm0CH rJeQ7WtBXgs6JFlCtieBnAQ65FsJ2Z4AcgLokGUSsn0xyItBh3wqIdvjQY4HHfKRhGyPAzkOdMgc CdkeA3IM6JBoCdk+A+QZoEOmScj2UJBDQYcES8j2AJADQIf4S/z97x2Nvc9nJN+Pe4mPqfHt/5RV Jnafz2D+I1LzPp9W9NdwK9BqaO+D/dDT95WD+aIWXGcczBuJfBcJxquC/aib3FdqObb62wfSEO4/ cwWYrQa+z71MVwPF+3zsIbcquhqobqEacoA9tFwN2YC3mjVk3awawuvWsAfFdfrZTRgHCGcAIpo4 DljCCEBgJKg0+/WpkoTTccCSC2/2OJBG2CiGV/HhM+2bOg4UEz1XJHCTfEwpAkT7TbIIdPHcH5D+ QT6h3ARE+x/kc9B9xt2AtJAshZQh2m+Qr0D/JfAVd518DSlDtBeSb0DP+J2sABJBXiHZfyf/4pAC ykqQk4GVkr2ArOaQfMo6YD18XifZ88lGDsmjpACb4HOKZM8jP4BuM3cN0lyyDVKGaL9GtoP+J2A7 d5XsgJQh2nPJLtDvBHZxV8ivlKuAaL9C9oNuH3cZ0svkAMgM0X6ZpHPIJcoh4DB8PiTZL5Ej3EWJ o8Ax2EZeQ7tITnDIBeA8OQ2pAZDX4C6QM6BnnCNnIc0Bzkr28+Q86M8B57kcmGkj5wDRnkNyQXcV Wm8ucA1khmg/SwpAn8+dgfQMuUE5S+TV6TOkiPuN3AQwLaacAUT7b+QWhxiA06QUUiNQKtkNpAz0 jFPkL0jvAfLq+WlyH/SMk3D+eJJUgiyvvp8kVRySTakG2QRUS/ZswvHZ0EWcgPQEsaBkA6L9BFHx x+F89DhNrSknANF+nGhAp4aRXQMjvD3OACii/RhpDXoHoDV/BPq2owKi/Sh5DvSMLNIWaAdyW8me RTrwyGFKR5CdgY6S/TDpxCOHKC8CXeDzi5L9EOnGH5ToDrwE23SX7AfJy6DrwWdCmkFcIGWI9kzi Dno3wJ1PJ69AyhDtGaQP6P8BYNqXkgGwnqbp85z/v2/j/9ILnzk3i97xgFKIcBdE45+G1w3Gbrwe HK+1ZOPd37+WAClOTLaos6+m3Q/Rtxn3P+Dc5LYwiXAlY8DvB81+Bp0d7F9sk43d/3pg5BYmt8D9 H9JsobH7x+cVbhHyryVFimkKPDaLFd3gsx5ODfLtGSjjcWtj9l3ha5yWlCme4/A5nEe1eLy6kDNa pWDXknNWb9PNdmsHwfsYyMU0enePjgyHdBako+hT7ybRvFWsjOVXFziQT4DAjRoXlbAv1Om6aFxY H7JOi3Ho6V0H7LVeK/QUKnwiKOuFNtGtUOaJtRJPor7X4j4siKnKC9LOOvacTXyJKWxF+y78lslU KmlNJpzdEmG6quN0LPMWuD37Bsr+Cn+FKOuVetrdaYlaGU1TYmTPc7Q06uAdO2XcuBPKAlbCLlAX QNTGFyD9EGebqgWoVqXBSGgPcw+cAJs4PNuBPhZkb9LxT6x13BJtqHsADcGZGLXsToO/FM8I+zB7 6fFNSwxWeN7jTJ5Rsm2fVeK2v3aYeZscTxzgNvzkMUxhp1DTjxST6TbVCppRjKpKgQ9bxcoNNEvN Ky+hwEHaZyI0zM5C5x1BKhXiNvgQMfEz2vBhW87ESulBrWwfnQTfYjrZS+Pie4P5LkyOrZU7dOQA PlrX8BFYi8b5MInFpzQfkHBjL3JJaHqXtWx4exGKtGaxY1EpJX+iUEJLUEsqFCUq9FWqaCOYOd7K WiwX9tK4+BOjlY7KJiIe23QhfgUTULN8+XIibiduo9frmYvsFcTdPZtkZ5vI9u3b62zn7u5O09zc XPqdYcOGkZKSErPtsqk9ONidoEv3Fe6s/YBPU3Zwg/tFG8YMeybp6ekNboc2EszygXeKNbSd+woT WWHKpv4wHwQOanyIL1fnoOYacVDTO98U2GV+r8VH4rKugavVNWAdXnyCFx0mUHF6OOxb63Jo58DD lAg/d9YZaAfBkzaC3Ug7CR684ue9xN6CdRS6J3ZPHQWpoRg0QgxN7Z58Ya+jiDApsxadsFT8zLzx 0mfmUSF99hdu4BE/M8/+4Flj5g9fEUJtWUgaLCdOkttIXRSWj0KSHaTjB2V9PV7amHl5xsyLg5kX ezMv9nDkaZQvWOARyBvbY6kRlRGPOpwS4P/oaYnC+DNNlUYcDjlibbQndV88saHfQ+cYEW6PtwE6 CHr6W5cN3hapNuLjqOMILijpybrusfwiGnXNLp4jraQuHm8ZY108tFHqTc+lcoZnfJVa0kqI5qBa 7Cs4Estria2RPb52lVbqc0iKVgfvr4eFBEzVRU/XBQWGROuGTYKpeaQuOiQ6LEgXFR0bBrOetVrM fSfhW5vpANqJiHWIOcOBXsyZQsjZAsgZjMxSzhJ6xPJNyVO+EvNEtLXzhF/mhTwlU/0qaWKBeRrV YJ7wWjmapSjb0UEB08MDdWFB/wwKsx0zJSRSlIdMnxkZPUX8EBIsylgKHaVSsKX709BIUFZQWSmV zugapWMgcukoGygde23TSsdfm8r5W+rta5cOnTBwrHTGUT0rHVbrq7VofwlYo6059PPCO079Ksza yGYtjoIcEfMjHk+127NFA/nqq29yvqwMdnXzhcerNc/y9S7VN5QvXLoW8qXCeM1z9qgZObNsIGe6 uU3Nmc7e8EzdnKF7VTNyxtfI2cVG5uwNIueMrlhq5Jx9SPOxAH/6VX3NLVn1OUngru2fQtJgtuNA cHKmIkp6o6iXAn95t2/krEJHfqUzn0EwtQ+GKf1MOJliJ5E45Q8hkwk+5Peuokojz3hq9anUsRXM eLB//lHD+uf1GtyO9c94U59OxfrnVzVN6J9Vcv+8GtK1GqF/xjeo9Sgom5doALd/j+XTaKl/yOFN lw1Nu8X6TlWmKr3t+quxXofQfZrXawqVbeElHovCuKUjxM1sDGP9ibw4gnGuMotTIcQp1qGeGG7I cZq3TmIWLakn2nybCLtvLTBar3qirXurpNAg7czCZjIOrxgmdsQDOaHbgze9WXEOom0PV705Yh7a Kfq7gInDf/6qGaCLAgs0VVnbs0ULePa287ar69kS3tKfynOqkkVd27PVU3v2VqNnbzV6HmfmWVWr OTTk2YDv5Df6Xn/kRoVRUde/dQv5N2L0dkYF+sd/fBCbs02d5vzGn81pzkTha5Vvc1OBzflV/Fyr OeOKFG3OPdk1LkJjFs7jdNiYmSw25nVmQaqFIMW5GzrdYNITj6zBXNNDdbEkipuKdGsM1bOeUDVS qOziDzFWW7NYbWvEihUm9vG2tQp0IR016pthPrk3M6iIpc5Wb4P+E83Kwq5Ohd3+oTml0M86QkU0 Ohsshf71lAJuI97sIJaAtVkJWNcoAfODDb/6dB0EfNuSWBo1tT3bt4Bnna3ONr2O51aqp+0gqGd7 Vl/mnh2e2rNBhZ4Nqtpdw3O1WkJzuwY48KClEVomSURuaY51Wtq6n5rT0ojGW2VQ39RgSxuAn2u1 NGxJ+KSwGh2DDTWypsZksamtNQuxjRCi3DGY4tdBx3DIszmBxll1t7dvpaUTCI96ArURAq3ZLajN IlXXiNS8spxaqLIMqnRtupY1M3P/7VrMf6qSWLLGZt6M2z91M8bxR2fPxubviVyHHeo0M/2g5tTe Q42BhzHIFmvvdVoPNWsP/+VFvq6mJ7sUQqxEYWVUh5XIZLESN5qF2rFOc2Pj0M9rmhOwUeFv6WMV ocKAX6snYPwRTrzApFa49mbh2tcI17xNOLdQm8AWUV+b0MGbd6PahKoBz8Rar4yw8LWtc6KEb/+G EyVCIh2x/DjiQs0z4ax3Mp2HlLOlY/C8rRVbuwpzYqcECqoezJH/pRf+s1ARYf2KkbC6riDsyiMM AOsff17AKQj+TxOGO4FjJ6ri/zRh0xkR3jMqIDIoKFw3esr0WUyPxeo7JSQsJCKK5gN/81MI+2L5 kn/LrS91a2Ut9ncNph3t2bYYd+2rsDCuQUHBk2aGResGBUWFTA5/4l9KaezZOmBHwf0QOHSjdGOj ggKlaDsKe2LedGOCpkWETYoOqmHHkhodBjM63RhcZYuSjPW+mvr/W3M59g9SaF9GWD18R1gZ4P+b 4TFxlLBTSly+xkXjQsLqAv8fDFst/u8WdjtYn3013zvGX88LqriUc6kw099jjfbeBsdH+XmhFbkp e79U97luvTK//+w1ravL4/OW/NphT4RtssFm62rHdwv8QiqGbUr6Sj3M+LFKeW+g0tT54O6UnpGd Cpaen2vtF7Go+9xix1/8HoaYupWPjCxw9yhQVPTYb+SqF8WnLZ3tvCfVcURMu+pBvfYtNk0+mDdk /+KJMYoRF8k2g7qdsU/b6ndLdhZmtvWY1N3Dp9fLh/2CK9bnrC/MnOsxye5Q8cJ+FS/29ZrXZVnl qYBjP9x4q+py3N3zx396bD1xaHLezfAfV16feGfC/Kl3L4du7+y1YOroE73Kls7xuhO1e2j1xo4n /nmrLGr3o0fve10xvfPOLtXuh35+lQtmPdhpCux6Jc930apfgipLczK6htteMkwY/1s/D8/ilaVd w6NW7jFpV/2ycM669Hbtht79smDmTp8DEaWf5+ROnvZN+GuFAz2nVt71vOT0cek5P8uCsZWXTvuW zplc5JPx8oPvV9+Z5Zn34NTs+Nmb3H/uH/PR5GN7i1qHD9s14Og9z9/bbkk8smPVmvd/9Mxz/r2L V17k1LTnvh5zYI7q1PSen43dmnRwx2djZ4T29Nyw619zHwRk/Vd0z8Je2sBhhb8WHzngfP/U7NxX xvReUjjFrbPrYrXd/vwhkd84Do3ziu3fZvNwq36Jo197e7TFkaKFm3XvjLUKManKW0UWuCT7WlcW L3zzsSI+bdFs7Z7UdiNS9LuLFto8vhOf9s3sHnuM/ZN97W4VLYx8XB6flji7955UmxHdFgy+N9Cp +oODq3xeXTrxu8+7ZsePv5cZ9viIbVz/8ujISW2TfZXXC3ttW62K21fg6Ou4TP0wJjOizZBemiNp J4w7Nu04tjAjZqBz0bBe9zLSzhn3jpz1vGN4Vuv+GTPvDez6+JZtWoeZAyIL2nqs6T2oeKGx15j5 jysnb1teuuxIlePKkPkHqqIej6lye3Xq3fuTL0VmXXu37wH/0AJFa58v9nw4fofTjuDgyPthVQr3 KXduPsqt7vLsqfKTt/y35t0p/W+3C47X5pR+vO/TstlJ43/87s/Ts7aWHo2O4WMtlvapfjvtT5u0 qinFpyILz9kea+f1k/+62+tTrr21Pa4kWJubnx1ZEq7dGRgy86dFSzYVDtC3vtbvwv152ZFdup8o npNcGuA03PX08ZFHxj66cv96yT+qPJcXXP1nRmlAn7/abXw+Let6W9PjvCO7UpzuBpd/sndo1ZC/ Xiq3LH/B40b4mBF74/TvbJr6eHHJ+LI8N8/T8yzmj9j//jeZfMnCQLXThGVlcduSu/plVYza3f78 yLR159PffRBU7lD1VuHU0dUnQp9/aJnlN+NCZtsS06htmV1KTgYmOV1JKLuQMq1wukt13t3PUxMf zSrpcLFg66gBxbO+Kn3j4Q85nmX7vzAdfs+6R8q3PzzIn1dSFVjpNMfrxjZf56/jDlUsuqs2epSP Ku9TcfW9DUt+c37e5HGj1+i4rqbEP7ddvelvXf7BTIcDa6qX356QdWDow7cS7vQcuXz3uBevuo0b tN/73CLLawPPGSYog3J6Vw+c6RQ7OispZr3Lqkfjz2kSR+/WTc0Y91eCl9/OTqcD9+18MOE7n/fW zufu7N+zWTHPqux+97itJW9X9/oiL//kh33L3Tf3uPrGvNaXhn2R+1119oSgLx/479v74BWP/2Hv 2qOjKLP8rerqR9J5dh4kIUATQoAI5P3gYeh0QgwxhLyEiBgTiIjKyxieIiD2DK5keAt7BmZAxAOi LohH3V1HRZyTdXF2ZUbA8ayKLjA+zs4gCBxBSO+99+vqrqruhHDG/WePnfN1dVV/3++73733u9+9 t76uTLyx68CEiO9+22j6xro5uvLqlANJV2O6zl/qNv1298oZ51yjL9cefrbz+QkNq9yflZWsufDm W59kr7uWU5A48LvZB9zX3BcvPXAl72TbRWvyrrO3h+ftH1TX0JJ5uawtOqew4NyHtRs2f9hyPfZ8 UfZvrrVezh9/ZnLDI9eKr+aNWPXrzKG7Pvzh1c/Lsp9Z/vR027r9H7x/LOmerRf3HTh3Niu7+3fT Ira8MOyF7V/cf770tfUrB1z9YIS39HLm1UFJp7+e7Ak7cebk7D+7b6R88nDnvElX407sOLuqbcWO acqZ/YNqx7Vun7b/8+dXbV8x7VhW4/lN52etOFiU2FV7+uCVsqGXpcOmzuffiRzwXNSmQW3XZ50v Gb574MvrS5/ZfvDANy/++0enX//Li1vODkvyvrkk62zdhvrTR0d8+1HbvuRxz1z8fuuZr0ac21D/ +gTH3559+54CT0W37ZnSXaWfD7884GPbyc7r7V1Z33sHrJz8+PaHpFEvHHS+ueaVbSO8H3+befH1 zjcurH0v+9sZJ6Wx18pOvnbp481Lqq+W3TXt4ujOJVcedVbcXv6Z8s7e7oRPDib9+PyC6y+PXTal 69Xr4wbvuBZVEGO5+uTJv156Y0t01dUn74pa1nlhcPdfs59avjsl/L39a7dEPjC36digvRWbNrRd H7gKLu3724vhrTtPT0n4Y79NG+68euNE/MWZXcN+9FreqDt9YOCatS/s2zR51v98uXXVjl9P6k46 s+Ha47uLFmUlrB3TPeqA523Pippj70wclX7fkaUvnI47vP+x/blN1W955obNWtewctv0SW+vuXBu 5ZKvKz6b/PKpjmlZDx3+wn1w3Ucf/9uXJxt+ufKrV1/6+PJju15u3PFuQ0b1H/o/PNS7b+OOa96S r/712I1ub3zuqv+8vmvi4c7vln/phd0TC2z/CInpUr90adJsWnSlbRGWwYtBniMVnDKDZJppxaMk mw7FDVkM0kzrkMWSfChu7FQ7yNvmQtwpWrS9ilj/+3SMv4JvCYVSP3qMp7GP/FMW4N9utV4xRVh+ puz/E2V1Osq0VEXEiRYRRJUcwfSY8iXG9gPT1wxIbu/sfOnpRgl+hvzpIBf0CGlPEJBRsaQ09gRS mqjYIOCRp0wgBzXJOmUXv6rwOrCittP/gzEEvyjLNFISAU+xJOK7cklEMbWSuP8zQxIxXpskop+5 kogPOyQRf9B/yqHIJwXLpIYpWZMmljkby5xVWHKyGsqcuWOcNU4YzXWYBqxDn/k3Ig8sam+FMqf/ OzxXY8eGjrbRbQs6QF9XnFO/+SDq8pNv/c/wnbagvc2Zkz06G1yEt/7b44TLn30v/jz+kwlTG96T +PPOyBVN+JliKBo/HbvCxPFfinrfb9xb/Caf/I+TO0f3j9myHeO3kVf/iYyH4uMxfT8HBF8XgojX VoMY51MgYjyK7yg+p/iO5LMbBP/3g+D/IRDx+T+DkNcRENh/Ab1cCLN19vwF7eDksSyGwC7En2D/ 7S0/f52euZzvU0YJyngn6ELfc+hv9eWAW9//S3p66z31/LrV/n/q19/TP+lBc6k4PhYT3qd8C4mu 97lOqRTSQFX7OBMSMhEi4QwyhYsxWMLEPDoivqqgZI1hXpcvmLVo3v3zO9huTW6ga3iJZwV9Hq1+ P7oYLo05/Aj8/LrJKx624xySYCdtrQB1m0IjGskLXhmPga2vFqjx2wHa00wZJFO6ydFG5iZ+73fQ mm5KhSlVMtRhua9SUuZVhtnmV8Yqj+KxA4/LQXLRhp3lGtQIqES70wpt/NuDB9BC5cBIvJYDtM1W wh7Aki6FZ4C9QoLIrnDpkCRvlLJRUaI9aCWxONoudqM93BslZaZLrgxoxmstWFrTKftVYHuirAoV qQlkVyz23aTpOyyob3qW+jCsFZ4h2StkhLZ4CXo8uDKkyK4o0xyJ+pZTZf6xiwJlVYmIaOoDch4j mxBZtlcoiJziR5YJmXCPy/JWeaHJhxwP1aC4chC5uldk2uDsxBbhGSZ7hQXxTJFdsSYCKlZML5k6 lFoh03Iwu0oRrbxXtAKgNceMaIq9woZoSmSXTQNTDBZXHaIU94pCtyvo+drhGWZ7RTiimKml1dV6 05ZF3NKKLS32ihhsaaGWtj60LOaWNmxptVfEYksrtQzrQ8sx3DIMW9rsFQ5saSNulbouep8lbvlN VmLQFqdaXiVbEYXeF+KK7oQKXiHFb2amwoOu772v4jGAEqH5xYnTMKecQK5cvysmnydoVj+Em+ZS kEBWlSzxcHjYdcn7Lh4DBtXKWE7UlgfhUe5f9o26HLqnDDZIXsYeSdvTcN6ztmdrJlJkVwTruHxJ ov9HQNqYBOMRhbRxvAGFNDsZLTBrdrZvzkR2WaWtsrRaVmdJIbYm7Ss0tCbt7YfeDmtvNraz+5RN 4omANHZPIX3LNbQjPY2nOzikp9TOBrKqo9SmNUSbQm4TJ7TS0KYG25BtqtG0MUMpntfARKD7XGm0 OTldQmtk9RkkGuyxbjJ+P8hoeFrxG2FvUun3MDheScaj1oIG8GqANDEBGIgEcdMW07lFomhB5hE1 kWhul2br7OlMlD9pF3lqAb1cBvQ/L/qRxWaAaBbRHAmlhJZ0qxzrmXsjYMqb8UoLXkGTDrRdvBHt 9hqpVtNPOLixD/IcH0ada0RdXso6lwZJ1EeUZ7c5GosKuRTuxbNmLAxZAW5E3CxV6OalG/HakFIt XiLqFq8ytGeT7GU8FsQgrXJAFdQizh6pSoNjD4EjLHsiei2M9XYwVgxi1SHW4T5g5TFWf4F1IBgr CqU12bVJOipp14TEkFgVKKd2nq9O9rXb/L+4c0Aqrm9/QnDBwBYPsaARypDKP0nalTkmJLIeLQUG EL3Rnv5SQCbNeMbyaIMaRP1vqU2DmnRL9AoOp6DHh70Q2QFlIsK5lyaox14u6rjiuCntKvKgAP1f SJKe/hnQQJ6FPOMWkfMY2dkjZ4RmuCGN/Ra3xopbMW6hmRWIiBIxnvL7Q3GIQTit9BQBtAnYdgJi pMluDYWEQXPoUd9KRLSkCVp2xmgn484YHmUVehB7IEeu0tAR64uf5vnHVM9r1P2+/2k1C98pyqRx zKuMQF8sQlnE69tApMctl+tWJiNWYB46ID3I26MIvJo5k68ZlYLYFCnez62Ghmjl8tlal86eiLWV OPGghqsOyAiBQKvJHnhE1q4mNh9CB499Hv8vsShwZ2qHLXpeI2t7llEfaO1Nw9WUee9E/V3YreW/ 09SCV7jnWrgbl9zNcq2Ob8YY2gmTWTtIK0bo6R9V7iTNsqGnbEFP2YJjaXLtgWcNY5nIMfEcRHmU 13MaS6FN0oylEjJRG16RK3XaMJH1ez7S08H+RShtiILKTC1SOdyGYzpq0AUjklYXRoaQyUJIJ8sk L9RZJkJZjC1JzxcyTimitvn+2xuNKwdGCb7H2QOISZ7r3mTPJW+KRx7UP2P1beXvWrM8v0JRxNmp M+GRVMFQslqy1mJHh+iReCD+w5zQqNEhqK/w6aR2RbIiFk5hloT4fXAKZFHbyC4zSOg3iFXJhyFW pHzWTMmUH4TTgfavnaURrJfTuXeHabpuJBW8eV78ZzwnZ2FIFqpEAC16DlGDHgkT1Cj5CeKlCARF tb6RaVfvCAN2B885McZktLfo56h27FOE+xQwtEL3BoQtq4apqLE5Jm1cEst+71zmOv2evA31cxnz v519kfnoJ1CtkkzJnRmhtUS54CRLZNJ6axZGW+Cby0RvPo4t3Utjo++nQgZSUGeaCopfYx3+Nr1r fwrbwomVFpwFKANQ5mMRxEj1MABpmWmq18yEyBC4gbmQgvNX1QiNAJYGNCKUtbMxJlG1hI9tTH9R kF6aUE9k9t8lg/9u9SHM41ikFejZRMUULTMlSRlHoz1bJJJcMx4pFMb+B5HPZXLp+KzGQoLPDoyF mAbB6rMy0uDzaRMBPf+7yFKZtBFAWG9ylrVyrodw8q90vLX61+Ol4OSYPw3G0SiiPevR+Wn3qvwE HMd69CTavTgWH0UOwrTz+lMPkT1gihhnvLAwTejmFnsDs7YZr7TglcAoHRQJRLhEJNATZh5j3q7H /DQYU8wWxLkJXj7jlQRWHz2e02TAi7oJXgHjTRB4XwfhfW3Ei74JXiHjuQTeIcWId0gx4MXcBK+I 8UoF3lKzEW+p2YAXexO8YsZzCzyXxYjnshjwHDfBG8N4ZQLPZjXi2aw6vEoYzHpdqbMZWjx9voFy 9+UgIsm4vRtxkpJ7TE1n+ub5TJ2lnsQeRTv7sotglsY3GobrisiPWX1LwEbJJULSuL1HTPF7CyW2 2/48GMalY2E4zuFWZawuyqlm2kQ+gryYmT57YDf4jFk40nZFa4cUTb4hDe5QPelYzzmdB9VfasEr vNJWQi5Fk0qlzg6pKOqMrRRIhbIRqVDWIOWRResRSczTSQKpzmREqjNpkPIpjuwRSczQKoE0VzEi zVU0SAWkDT0iibl5p0BaazYirTX7kaogG5GOKlXqT0FAlZRAcrPlpzWbeJ+M35h8sX08GJwblGoh +WZKjQYrsgcsIYFk9GBVvMQQeEXkefURT2SIavx4SSHwiiky7CNePuNN8eOlhMAbQ3Pc3De8Asar 9eOlBuFNhXLEc5inaqSqxSsDkfOjWbSIvYzBUOfHGwC+yRmEWw0TXbHmNLPWk4ruBVfIJo7WUsrZ DeQkzkZJcnKurBoqEC33FtDyGK1B5O4GqWiHFIF2B6K5bwEtn9EaRS7PqaK5LNSyHiqRg/Xm+j6j kVRS4C51pmhj87Uii9QIOeStmbW5EO0M0duyIShFVSJpavYrhEyaYCxZOXNTD7LWogp5DIFpAhlF ks7IxQqJJBh5HFm+PiLnMXKTQEbxZDCyzUriCUYeT5awj8j5jHy3QEZRDWfkP4eRqIJn0u1kGc01 fUIWM2m6n8+ZQXgrMNq74D1sXqFZLcM5Wp7Fa5zWt86Fe4B96wEQ9oV0xLTbvNraEuayOyMh+osY Pzm6LugOlAnjalPIO1BLYRLZVPNSzWiisHcRi1IenzRP7xOXwAyhg/PR7m/+MdBbeptFAmkov2fw +zB+H1UOMc1YuwVr+6IAkT2XDNlzC/bcgKtqDfry9EsHB9wrvG/V1/BHAJnY+gLQMdDahDNF5PDD oFnYA84jU136BzjBdfO47n1itnNdypTHSvpMuahLOhILLWIu5woDlq6o+IND4hcwfqvIyftpyQlZ t5DrzhS5eK5bAqkom1xLiU7TtPdHjDnNcNSZaM/v5WYsIickGe4wKNxeRMsx2FK4/jyYI2p8nA9T XMYcVoS/XbD3JjPacF9vwzWtZIyDcpmu2aIPuk3ZY808rvmAqHm8t5r5XHOOqFmt9FKzgGs+2Iea hVzzIVFzN90CGQsj0DN8xaL3DGv9s6I3z7AYptO8smjvs4VjW4pMiW/aWS3jVZt/lmb66NNqiNUX t6uypzb0ng13sqSydb00sG4sQmzt/hSZ3wvBRX6FRasTYdhCPJSA6osMCOEsAEq7UrIVeqCqASjO nYWtxd064iPNoWnIt1irPn/RAMJnFzoThf63NuNWAlVIV5pVq+s23nkzE7S5mGjEwEghXtyBpihB WJN6pi/Xql1No3T3FYOzRUlo4fS3PtSkhchyN8JIoDE3aixzvA5zAaJS/o54PYdlIzK193Mez4Gf oz3vA4VLzXikIIm8iCEss2oNakwIVG0+SqAtQrSNEqVim/FICVgImcuy69C03EuFxb44S73dLpLy Ipklojfi5EXvI8hJxY8Yq0FUcz+qPQjk8PrxnR7KIxmSSChdonKmXKLTnkYQeenhOL4RPMKlvuiN 0hsiUBM0CUu2xloYsr2Yh6THy9TGvnblUEJrtVUbn5mhUcOROFhOHInDtUXoFEeedhEdOuHOylSy w6NZD0o0EiMeT0HJB1tDCzzGfA3stGiGOJZ4s6a9mduXgcjxFKIXwJkqG8jH5aQMCI/yXJKiPccx 2Mu+IaTEHLkXLzfj5Ra87OdOJsS73rXy3AyBn8s0Pc53zQAyIMH1R6ybEbIuWWAZVuK7CxK5nitk PbK/qbCKvaTjstShoGZ2oDPQ+WMzHlvwSD31c13osacC7mk195TE9UL3VMg9PcE9dShkl+kmaqyn 5RrdOm3BIyEk94JQxAhrboKQ0gtCMSM82StCCfRnGZSERKD8STJ4EEGhhU3dqKNuzAGKksWd60qd /VuOf24I3L2mnYK/IH210gxW77STxgbyGTTX6pSjOksazkhqRCG8BbIp0fBLoXcK+f2cFMUVUFiU h3QWRW2/EOdYO1umObx2FcBaobayvH0omlxPKqptqpTepkgyeoL4rmTw52H8+V78rhkLCC9O2IU1 Nr1dUPtaDGqu+ymkUqbcbWu6HE4jdWdKNLXcPFa+D2kYa3A2ORr+wTBWQcNIpmGPbaRutSIMmtlz eUWT4Wmubed1sM7mVjKDKA7kt6j+Onwf6eOkFtnMdatxzaQZYINOookZ33vtQq79qz7Vnu/DXt/H 2gJ7g792va92fRBXG1Cjy3X2Mxk2UjtH2x7OsVHy7gfZl2PzSUomQ9oE3QswsgwT8djGFZuA98Fw Do9w0mCTwPkOJDZ2BelQlA7F6TCmXIZKpiwefSQz+kiA60tYBEYwER2VYYqbqU0L0+pAtGEFVO91 D0drm81rTThs9q/6lFli7yFMe98sqkeMMYwQA1tAvwlD3YFBWO4+YhX7sLYaPBF1BwZh1fcRq8iH 9QzoN2GIHRgnWAIzw05oJGDlaKtaI4dO2CZmyRIYlioVyQ2m+crT5uct71o/tf0QFmfPiqiKnB31 RPRvYk44zsfZEzIS3f3uTVqWvDXlUP8PUr8aIA8a6Bwz+K60hUM60/cNfS/j82HXhidk5txWPRL6 9gpoAErcyRwlz7i2SmHvGCWPnoWD4lelA4/D0bQ+dIe66es+oJyx2PNN4bB4wKp4iXPZcG4ynCuG c7Ph3GI4txrOjf313D9A7/3fyksdt3iJPkVPAl+girGIEQi6+RkAvkfJiKd8qLuaAe5GmG3R2Hag 4DB+v43q0r7kcBir+bxQ8/k5/2eSgVIqeJB023OMGVMqeJCWIc4Vl+CBek4b8IkH/u8HCxnov7cY vrf6z5N8/annES79uc3Yf6mh/1J9//QiPqi8eC4O4KUEgMsDBF+ovJ+BXjg6cafHCT6Jl14G9JsR hfls5vyrXgZUNwzoic3hcELSyiALaCcP8Fq9HcurWN7CQpbiHRD/C4Q3uGOrflimYWny0fsNwgxG IdyN5RqWYdjxbiw2JGYAlqFYzmDZGi3Gtg9LSyxApANjZBznL7DsiRNjfgVLWjxAHZbVWF7D8g2W TOTFPVgOJAi+vIYlEz3erVh+nwywLgVgfH+A32H5A5b/wvINFjP6KYOwNGHxYDmC5SssEcjXEiz/ 296ZQElRnXv89t6zwAzDOiDQJKiYKDoMy6ARBtlHBBQCkR0EgiuriMoyLFFREtEoJjkJ8jQmKDwy LicvJho9PkXNojyDiS+rC4sYldEkah7Geb+v7q3u6uqq6hmQMCo159fTVf/+vrp1625Vt+6tqbAU boat8NvOOs7DxHfExPsVsBxWwIVdlZoEl8MVcG+KMMEj8Cj0+RyNLWqk6bAKauFWuBcehSehhOZL KyiD1jActsK98CY8fZI+18/CAXgDxp+s1JdhDsyFkT3wSyF86mlKvX2GUgehJWljTIVOIytgJdxI o/wFuJAG939CnAZ1AibAJfBt2AZPwG4IU6F3gj4wHhbCVfAtOAgjqMJHQg2cC0/A7+A1eBPegneh M43hLvAFqITeUA0jYCTUwDKau7+FL1CyboRHz9RpewoV5YNnK/UQvAF/hSEDlPoOzBio1L5qpeaT fxbASlgFf4a/wMvwCrwKr8HbcBBk3pVD8CH8C4afQ1jgFngWigezDiOhBlbDGngYfgr7oNcQjgV6 Qx9YDTvgR1AH98PrcADaDqVagVlwEcyG6+BVeA32wF4YNAwdZsMcmAvbYA/shX2wHwaT3+fAXPgq zINLh+vxSWZKExKbwax81rVbmlFYbjiuNVkLis/r3VpdgLZFr3pqyQCt9Ei0UN5juM6tPZDR1vnt r9pDUxlteXPWHHHmHS9aW+/WwnpFtH4B8dl8tM6p8wO1kIemjBYO0CIBWjRAiwVo8QAtEaAlA7SC AK0wQCsK0IoDtBYBWssArSRAK/XRlBrqmT7zp+sgbaOPllSVqVCjfEor1V50+iz31FSgpvfnlz6d dtIKthf3/pxakJ29P78077STVra9uPfn1ILsgrUOEG6UnbTus7VNn2Kt8fEiVzNHrt2bo5n0qFLy phJHmjdaVGtBPnU68ys/nXZy1WUv7nTm1ILs7P1FjaYC9jfh5Izi3p9TC7L75Gg6XvzqI6ddJ/ub LKFgrXcqWLPLMy/NLnuasr9gbdNxrdlrh3tuP24tu6wTLV3WBWrZ5aDRovntPu0+m9O5PbaaIWWt hDooZx3u1Hzsqhqj9Un9W7RSWwsOZ0e3Vp3RctreDq2vj8+k085eZlifCbHr77b7wFoJfelaWuxG k9rFTrlK9clrF/Gx28hnb7ed/oF1DDmaXiyf4aPgM3YYx+d5HvRKwnN/Dju/sBwtLSicPsenjoad lIPZ4QzJg4XKLiN9NFc72Winas3/2A87LCpASxyNsHjGp0Nr0jFYy5ZAzfMYopYWCziGpocl/7kN is+AdB2c/5pbWPp7708FafnSmU96+USleT9NPo/34R7vw/2k9uF+Fvtu5WVPfvn5s6759N0ek7D4 9FF+prVv+WtBdbul5fSXNjttdd5jyOm7DWe0ILtPuhaUV8TOp+/WsvPpL000L82379ZoIQ9NGc2z H8tonn0PRosGaJ73yo3m2XdrNM++W6N59t0azbPv1miefbdG8+y7NZpn363RPPtujebZd2s0z75b o5X6aL59twn/dJ1f8+m7TRT69926fPbvnFZM+iz31FSgVujfd+uyO9HZVxygBdnZ+/NL8067K519 xQFakF2w1jEUToUbZfeFz2ckHZZNnpr6VGg6Xuw0ERQvf87xeTjathzN7DvnmthoUUuLZfs0VFtr Jp35lZ9Ou02OPl93OnNqQXb2/qJGUwH7+5yzrzhAC7I71ppq5PHZ8eJXHzntutrfVG68ODWxc/bd eml22vXS7LLHrQXtL1jbdFxr9trhntuPW8su60TLlHVBmoyHUm7NlIOH6zO7bG2+PoOOvTmd2+ak 6Trcu6wbcFbojPPMlpDBemDrU6JJvGS3vW+yksv+a8OJ71QrVZqlqXSbQbScNrvt08vOoQXZlbm1 8gDtWPlUvn2NVlzn9DFbdqdZdj59sN6aXo6KJuEs8kwTXfMeXwvP49uWuPWw7Lom7lb+/TxB2jfl n1vTfUABx67D0sbnGI5FWEKeYen6MWqhRmmyLmliYcNGq5+sRLSoaFssu6RPum6aFmqU9ipfX61g ezga1thhSTW7sHT13N+2QM3TZ4eMT++wpALCos9Roef+dH7v7hMv4WqP8+4IS6FPWDztHGGx80PI 3p+11AZoNwVqKmCRsMmu5d1iXQK4GC7F6d3wB5iA4QtQyOXv1xzEcXY9JLkcWw8b5LIsrlT3FsRY mVLr2ih1a1ulnmmn1I5OSo3H+YLuSm08U6lXhir1xLlKHTpPqevGEEe36GLii0oXCaeBjBGWw5Q5 XWSuFpmHReYWGaisoctqiJJ5u/U+b2Q/IfZxKv5LcPQ6xgnSwN0DlPp6tVI/h91wAPYOV2oz+36R fYfZ96tw3UYdBplTQPqwZZ4amVdCZouQOVWqlMyQpdRZSuZBVupsJXOP6Kr+HBgMHJIaqWR+BR2m wltkJindt/0jOAj10J64PBl6wGxYDzfCg/A0PAN74HU4AOXEdRX0hzXwU/gZtCPuZ8BM+CV0J/5P hLNhIFTDTLgMLoebYTPcCY/B0/AMHIB34W+QINwFEnboCCdAZ6iEPtAXpsNSuAq+Ad+E2+Be2Abb 4Tn4I/wJZBqBUlJmK+gLNXAuTIXpMAMWwCJYDE9BLEkUwukwDIbDJJgK02AhLAGZfewmuAVuhXtg K9wLT8HzsAvehPfgfUgWcHxQBJ2hK6SgF/SGPjAcRkINTIXpMAMWw5WwFNbDTbABfgSPwePwEvwB /ghvwttwEBogVEiagzbQHjpAT5Db2hUwHEZCDcyEi2A2LINr4Fq4TSYngDugDh6AB+FZ+CX8Cl6F PbAXPoSPoAHaFbFPKAe5Xd4LKmEE1MC5sACuhmvgDvge3AWPwROwE/bDO9CmmPgr1s9tDIaJ5vmN lXA93ARbYQc8CLvgN/AS/AM+gALKixNb6Oc9hsJm89zHIxBvqZ//6GSe+5DnOt6HEGXLCZCC06EG xsBMWA4rYRPcDw/CL2Av7IciyoqToAd8CSbChXAT/AC2mudD5JmN1nBZF/1cRCGFQnGFnvegdbxN w+21xz8zn20/js9I7mfbYq+teX83xvps0aah9YmE8PHGf7bdIB44pjNva7h9ndSXJHNrHgupN6Va 76h0PSl10Fy4BuQ+RR3shNfhQziBsv6LcA7Mga+GdL26AbaY+vVJeMnUs2HK+hhII/NUOD+s695r YQvcBc/Cr019/Df5bUTXyxXQG/rCZKg1dfTdcA/8EP4Ioaiut88ydccsqIU1pi7/KfwCfgUHIRLT 9bvUKbNgNqyBdaa+b91ticSV/mzseesWuMXvu98Wx3YKiHqpqTnGejlT4WimJWcj69WqyzulSmY/ kd82qNraWvW+PONdosL1colWqpL1SdsoKs22SL00RUpUtL6Htb2gvlTlLmFVaNlJOytmfi/NgzKz XXzJ/CjjVFG9JKHHQrKvX1otOJk9J6miEWoJNTBiNSJVq/qoCUVDwzglyXC6Gq/kZTOVNIvO4LMP TaJKmim9fLTeNGX8tSrw1vpa3/20/r52VXzz03RIc7W+fFbQzOqfo4lVBbrYy7TDI2lsyQteZLpI mRJqtJppvXSnJY3BIa7JCe2pSyuMOkYtYn2mkhcMXeOYLLTYms54luVXJpgSRnKGxlgTVMsex5tX XOipwBal9aTldzxr42Uqb47bvaUyZ0uvnC0VHNkQ60+Oe5QVQpkKU4deaxOtid0uNb+xX7BU6LCT CUe1RUng0Vbm0SuM13Mo3sYRugthkLqA9qxsHURsy5SixVl7lmlL7TgqcCjZ2xZYv7vQOkeLKFRz j0sm2dTbMxPA6lcsLjGxprcPVzKpXzLrlzIppt4yjsb4OCUTtS4yobbXCtJ6ZlI3vW181raECdtw 4zeRtnOuj3es63Qyynpd33B8XmalqBGc7dFsO484zGyrSG9LmJQnL65aTAiTrvUhOVuG5mwZhmfx N96chwlqjnWkg/ntaNc2nWqd2wpNyPWaPR11sdmaSVP2lGlxs/cLlLwSyV4bacV43FgN43NUOrcO w687t9qaHENuTtbaaCtNutXCtFe9fQyfs9Phzc2n/jlYx4+/ruO0hTlCe39SRshErEuslJNbbniV JXpPXoreR5EJg+S3q5W8pmieNXVwC5/tEwiNvzY0QBtictdQq4y0c7zksjaEcgJ5bXo6r8yxzr1M finnYTo+JYfO5DjsErq3VQ9UWeX0GdYU4t5Kpa/S21fp46v09VX6+SpVvkp/H0UmTixCqbD+dP0l x9jfN2TyOz+ll0dLIXepo5rvQOtkDjwEe6EjTba10N40yQaYZthGeBzekOYZl9edoDfMgJvhPnge ZNa1fjANFsJOkCevJsMi2AA/gJ3wFhTQ+OgClTACpsESuBHq4H/hLWmgcCnZFk6HETALrobbDffD Lxy8Bv8ytKc9XQEji/Rj/vYUc/J4vDwSf19KP/Yuj7TLo+vyuHqheRxdHuWWx5ZlsRtz8lCGtJKk vWUO2ZpRxwTTar7Lw1/ShJeHueShLWm7SXO+TMmkyDLRtX4tfTslEzvrZr70gEhTv5OSCXHldWu6 2S/Pr6SUNTuf+pySVykoRXAVwVUEVxFc61bWKUrf/nHf0pLbS9KWlFtMzltb7ttNcqvL65aT3P6q VvryQ9qWcutJboUNVfp2mETPCJW5FXWukmm4FaW7vM6By2QlE2mr6vOVsl47IMMv8iG3ruSW1Xpz i0puTVWZW1EzzK2ngeZW02Zza+ldV9pcam4V3WduDZWaW0F22pRbPnKrZ6q5tXOLuZXzvLl1E5Q2 HzO3XOy02f5jSJsxEsxDcluRk36N3AbgxP8spdRKTvYwTvZ+TvZFJm0uhwOOtGmfZxkG8yh+noSn YBf8Bn4Pe+GvUA/vwwfmdsduEuAeSJIIO0B7El8XeIoE+BxUEI4z4R54AOYRpkUwgwR5CdzWXQ8T 2QaPwFPwazgI78MhiBH+HnAGrIMN8CD87EQ9dOTv8D6EOMbToB9sgP+Au+D7J+m8+QKEiIMCKIFy OB0Gw//AXtgP70AFmeEsKCeuupn8PBu2w+OwB96Gv8NH8CcyxpvwDhyCFmSS9pCCShgE42AazIP1 ZKCb4T6ogx/Dc/AaHIDeZK4BZrjJl2EmXAJXw2r4FfxWhp+QAd+DjWTCb8MBMuBBqCETjoW5cBl8 E+6Crpz3ntAbBsB5MAWehd9ADzJtrwF66MloWAzLYTAZ+Tz4LtwJZWTqE6r1sJR/wEAy+OhBempB GZoiaStG6SaccJgcqX1zpZNrXf6c+XCy0sPSZILt5ynkd8N3KdjvgjXk7Y3wT1OQy1Crdd11Ptrq kY8k31SYfPN1k28eceSbDSaP1JDmLzhZD5maBDJcqhgmwmS4FObDd2AzbIc6+G94Gl6E30GctFsI XeHz0B/Ohq/AFFgGy+Hb8L0+mfQtQ6Pmm+FRX6vSQ6ReqdLDpPrCP0jTH5lhUgtNOj7dpNvdJt1W DtDDpb47QA+ZmgVLSZvLqjPp8q1BepjU/w3SQ6RaURG1ga8N1UOWnOlWONODIO1YIH8xF8qkJWl4 yNBF6daRW+EybNEebmgPKZThg10dwwQHOIYF2kMBV5j2zhWmzSPD/qStI8PypGxcCVf00kPvrjTn +QkzLK6LGfrmnH5UzkU3GgTD4DIaBbWD9RC0nwzWQ8v2w6xheqiYDBOT4WGzh+shYc5zFM058sPB Kwbdseks2bSFnjI6puabl4HMVNI2W97Q0LBp/KlnT1INJdl/IbUC7ZIdO7e7FdFWou2YOWOzl7YK 7YE3fvyBl1aLVjOx486xHvtbjbZv6ZfKx3hoa9A2nPXzmaM9tLVoU3a8Mfk8D+0GtN+P+uA9tyLa erQ25bNfHuVh9+gF78Y+mDAq0V65l5BKjr0nuWdfl6vb0N4tpa1bRjtX21EKdr2zbNk93+ieu79S 9ZOV2yvrrx97h0yJH7HSQpzzkrRa0y/1m1zVa/SwJ9uqaVzpzLAmZrd9Vg5ZUbXve+GD59OmlInz Mz4phTreMW3rP/9+c7ucY1Dq5fjFc885u6ylV1h6FN6waMf9k+6coCaqr6gLs3z+M3r7iltbTHrX yy5k4iBnoTVVsm53rNW6b33UVl5+szsWn8b6DNYl3fXMY/lwNG35cBTLh6ONtdwcSVtujmC5OdJY y7XhtOXaMJZrw9mWueeeK56A4xxTE1Lnw/wemP9XfbAL7wNukgvvI2+SC+8o8HDhH4vzQmkX80K4 mBdqbCx6W3ruPJzrI8BFxGqUTLV2HzEFotNJ21KV8+qUPslQ36SSF5+MqQkTgLAEIMGV4BVKXt+6 TG1RdhyEIq6gqHiHjMNMYJyOxUTiw/YQy+dhV9jlIWY89OQ40l7Sx+bjpSrq8pJweOlJqDKeCpro qcDlqSclmsNbUaC3LTGXtyIPbz05ZvEY9j39L5emPda1xuPLpeIxonpQsp5i2UZ9betap207tMW2 rrVtmzC2/vutbZe2fb09trXtbNuksW3v6MKaZ7KOTvW7MlnOOse7/LJc+41+LrZkih8rIreY4ke/ 981yMV8Fu1iQTLtYkMTFgqR2kcBFQrv4YZ5QVBelXVQX4aK6qMkHUtoy7aK0JS5KWzb5QCQJGBcv l5ok0MQDkZRgXFipSFJCEw9EEoRxUdvOJIgmHsjY8rSLseW4GFvucyBeRbHOYHWUhmPNgUgBVEdp OPYjncFC6njxdWyKL9tjC6fLAI8tfHz1pFDL8lcS4C+ZSPsrCfDXkxjN9tmqUT5b5fHZ07yNJGJP wO6ofeO+tW8yq7qVG6o6bOGo24fy8BG1LDKpNByNN8IqnrbKpEwsk/ktk1mWmdQo1oV5rQtzrDMp 0PJQnM9DsacHO9U1pE2Dvaij/muvBmDS+nX2OyjtAjekfu7batV2qYi2S0WaZlcX1XZ10abZVce1 XXXcy675xPTR/PWR5ORJyr/uySllHDVHVNnp26/eCbKOK2fu8Ktzcjw4aoqkcucvv/omyEthjpdo tqesuiaoZij29BRzeWtsPdPS11vc7TGopnF4LA30mMjx2ri6piyv12TGs3IvEctzVVTef5o5M1VR efEpjSrHfYJobuLMY5zVKormps485jlNomhu8szjwrM9FM1Nn3nc+DaGorkJNJK+BHnmUPYlyDOH cBXYEormptA87vI2hqK5SVS7TCbkxaqZxJRMyAtWcdmo9lA0N43mcdvYJpFdyWctHTLVYaYBrqtF SaGn+CZvbakrxMyJTUW0ZSh9JetnqavEzOHoqlGufLVlyNdSV4qW5UsFcbtylDubdmj9rp7lwtFk 863FcX3hqK+eo3mv2uWK0dguK4nrK0ZtG8t71e64WzCiLH78bsHxuwWf8rsF8tiLdDoox+Jel86M 5qS716VjxLkuHR7Odemoca7nO173unQCBa2vzbO+Js/66jzrtXnWpfPnSNZvcPmTjh/n+qo8+so8 +oo8+nKX7l53n98jXXenH3d6cf9eOsmc69L55VyXDj3nesOncmmj8i0JNU85hwDI0oJv8pD2LDXH eqx1tkpZj2IvVkuUxFSQ1zJKqIJoBGLg9z3z68cve2NpOVs6QQl4fW+sVykwxLUklL1mD7Ieu3aU uid1rVo5dZX1Xuvt/bZbmjyCIKPW7JmBvWYClkdH7Bl4j2TWXXuGXXkcc1919gy6MjuuzITbmFlv /10z3tqP5XUbVWbhXiSOZZD4ppBn8zWtC5tD+b/bfoTJia/n+LM1p19sou592du8tq9qHW60fWO2 NVSHakPp9z//ZFR5oTSr5bss9v9wbxOc6WyYTmNy+jA9IHKLXFlXW/+t+4pbpF2p11OhamVeDp5Q XyY7XmqNIbmKT9nqLAntV4hL8Ru2h2c5vstvh7fbKMEOxyOxaCwciV5/jUqxudb2Y7+FXJ7llzED i5FH8/8q/l/Afi+3Rr2QGPETVrFYKBxKxMPpa1pHK1fVyoc8RS/Fx3yKDZLySdbei+Iyr0A47Lv3 QebZebEZ2MeySUQKwuFYOOprI6MsrrTspKiyQ63UWaGNodWJcCROqrEW69fxgkxQtadzrGf1Z5qi r80jL+4ittpuDNXGia2CaDiWjEQfC6sthz58ep5te6e5IjitobIhpVrO7fxVZY0DSfF5sRk9MB+9 z0nyKzluoj1qHXc3lXUMOlTj2f88E8uEPG7FsXItOXE80RTYdsEtz81+nnS6MLm1Q2m9xJ5uWT73 wlU7/wzyPWpdd+8sUOrhfnLbqZu1LVK6NGfrUrOrbpFSz1F7x5fGLK+EO0Zmq4dUbe2A3tK5Us7Z 0k/JTxukkeXFNy99L8iL32LdQbCSYkHl2oVynv7yl6Dfj7A+T6mX56BCA5X6fsRq9qzyQ6rLhgZd 9I8ip52ppig96uxKq5SQUTlSUkjukSbCOGsEzJJ0epzieCZtCrl7gTUC6mJrTIw9kialhpgcOMXK PRdZ424Ww1y2TrFGDl1u2enxe+JVxljNVj1hPt/KzRit0/k/lFCmrFFmKVVj/legjLO+yVgUKSFS Jj6cz8xlPz+Xu8iTsHLjWTd9iinmi4n/Yq72i8lBxdgXoxdTWhdTshSrAiiEIpC/FtASSqAUWkEZ tFbFnvs7vjTb5f8BUEsBAhQAFAAAAAgA9lQkL/jIloXblgAAAPoBAAkAAAAAAAAAAQAgALaBAAAA AHc1NzgyLmRvY1BLBQYAAAAAAQABADcAAAAClwAAAAA= --=_mixed 004CD08BC1256DDA_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 10 11:16:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27623 for ; Mon, 10 Nov 2003 11:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEhz-0005tr-6A for avt-archive@odin.ietf.org; Mon, 10 Nov 2003 11:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGG7fn022658 for avt-archive@odin.ietf.org; Mon, 10 Nov 2003 11:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEhv-0005rb-2y; Mon, 10 Nov 2003 11:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEhL-0005ps-7X for avt@optimus.ietf.org; Mon, 10 Nov 2003 11:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27453 for ; Mon, 10 Nov 2003 11:15:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEhJ-00073c-00 for avt@ietf.org; Mon, 10 Nov 2003 11:15:25 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AJEhJ-00072E-00 for avt@ietf.org; Mon, 10 Nov 2003 11:15:25 -0500 Received: from dyn138-191.ietf58.ietf.org ([130.129.138.191]:50167 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AJEgm-0002GV-00; Mon, 10 Nov 2003 16:14:52 +0000 Date: Mon, 10 Nov 2003 11:14:46 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Magnus Westerlund To: avt@ietf.org From: Colin Perkins Content-Transfer-Encoding: 7bit Message-Id: <00B10F96-1399-11D8-AEB0-000A957FC5F2@csperkins.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [AVT] Slides for Monday AVT session Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Copies of the presentation materials which will be used in AVT this afternoon can be retrieved as http://www.dcs.gla.ac.uk/~csp/ietf58-avt-mon.zip These will migrate onto the IETF server after the meeting. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 10 15:03:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09324 for ; Mon, 10 Nov 2003 15:03:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIFf-0005vN-Az for avt-archive@odin.ietf.org; Mon, 10 Nov 2003 15:03:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAK373X022772 for avt-archive@odin.ietf.org; Mon, 10 Nov 2003 15:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIFZ-0005uj-Gw; Mon, 10 Nov 2003 15:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIFR-0005uQ-2d for avt@optimus.ietf.org; Mon, 10 Nov 2003 15:02:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09315 for ; Mon, 10 Nov 2003 15:02:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIFE-0003YK-00 for avt@ietf.org; Mon, 10 Nov 2003 15:02:40 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AJIFE-0003YB-00 for avt@ietf.org; Mon, 10 Nov 2003 15:02:40 -0500 Received: from mcomlap9 ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 Nov 2003 21:02:28 +0100 From: =?iso-8859-1?Q?Jos=E9_Rey?= To: , "'IETF AVT WG'" Cc: "Colin Perkins" , "Magnus Westerlund" , "'Dave Singer'" , "Yoshinori Matsui" Subject: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Date: Mon, 10 Nov 2003 21:02:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-OriginalArrivalTime: 10 Nov 2003 20:02:28.0900 (UTC) FILETIME=[918F7640:01C3A7C5] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA09316 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jan, all, > -----Urspr=FCngliche Nachricht----- > Von: Jos=E9 Rey [mailto:rey@panasonic.de] > Gesendet: Montag, 10. November 2003 18:11 > An: Jose Rey > Betreff: > > > Dear Jose, all, > > I will not be in Minneapolis either but would like to provide > some input > on the issue of transport of 3GPP timed text. I know this > input is very > late; my appologies for that. > > As you know also MPEG is working on timed text; currently the Committe > Draft (CD) is ballotted, and MPEG schedules to enter the next phase in > about one month and to finish the work in July 2004. The > end-result will > be part 17 of MPEG-4, defining MPEG-4 text streams. Through liaisons, > MPEG tries to harmonize its work with the work that is already carried > out in 3GPP and also with ongoing work in W3C. Most important in this > respect is that MPEG focusses at maximum commonality with the > timed text > format defined by 3GPP for download. In summary, the current CD of > MPEG-4 part 17 specifies streaming of the 3GPP timed text format by > defining a very straightforward way to transcode the 3GPP format into > the MPEG-4 structure of a decoder configuration and text access units. > Please find the Committee Draft (a public document) attached to this > email. So far, 3GPP expressed through liaison statements to be very > pleased with the work done by MPEG. > > Once the work is finished, the timed text format can be streamed using > "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is scheduled to > be published as RFC very soon. In summary this approach would work as > follows: > - media type: "video", > - MIME subtype name: mpeg4-generic, > - streamType (required parameter in RFC#simple): indicates MPEG-4 text > stream as defined in ISO 14496-17, > - profile-level-id (required parameter in RFC#simple): specifies the > functional subset as defined in the current 3GPP timed text > specification, > - config (required parameter in RFC#simple): carries the decoder > configuration specified for text streams in ISO 14496-17, > - the RTP payload contains either (a) one fragment of a text > access unit > or (b) one or more complete text access units, > - the RTP payload carries one AU-header for each carried text access > unit, > - in the RTP payload the concatenated AU-headers preceed concatenated > data of text access units, as defined in RFC#simple, > - each AU-header contains (at least) the following information on the > associated text access unit: (a) the size of the text access unit, (b) > the time stamp of the text access unit, > - if deemed necessary, the AU-header may also carry the index > of a text > access unit (fragment) and/or an indication whether the > associated text > access unit is a random access point. > In RFC#simple the fields in the AU-header are configurable, but if > desired one or two new modes for RFC#simple could be defined > with fixed > length fields, for example one using an 8 bit AU-size field (for most > common applications) and another using 16 bits AU-size field for > applications using (very) large text access units. > > The above "RFC#simple approach" has a high level of commonality with > draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small > differences that can be fixed either way, but roughly the "RFC#simple > approach" is a simplified version of > draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the > "RFC#simple" approach does not have the advanced error resiliency > measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt. > > In my view not only in IETF, but also in 3GPP and in MPEG a number of > basic issues should be discussed, such as: > - are the error resiliency features of > draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to > justify their complexity (note that a partly corrupted > subtitle may not > have much more value to the user than a missing one); This is a good question which I will also ask during my presentation on Monday. This is a question which certainly needs feedback of the group. The complexity can be reduced, we have to agree where to cut down: do we need the MTSF headers? or do we want to just keep resiliency for plain text fragments?, for example. PT multiplexing will probably be abandoned for a simpler scheme. > - is it desirable to define a 3GPP timed text transport solution based > on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one > that will be > available based on RFC#simple; Allowing both would mean that one does not have to implement RFC#simple in order to transport timed text, which I think is desireable. > - is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt > specifies a mode or an extension of RFC#simple; Would this mean that the RFC#simple has to be implemented to use the draft? I think this is not a good idea. > - how can a timing conflict (if any) between release 6 of > 3GPP and part > 17 of MPEG-4 be resolved (note that such conflict will only exist if > 3GPP adopts streaming of timed text as a work item and if 3GPP decides > that this functionality has to be in release 6). > We are targetting to include this in Release 6 (03/04). According to your information above MPEG4 timed text will be ready in July'04, which is out of the deadline. Apart from that, current Release 6 does not use the RFC#simple for streaming... so one would not be able to use timed text in Release 6. Assuming timed text comes into the Release 6 agenda, what I would like to know is what should, in your opinion, the current draft include in order to consider the MPEG work and the possible extensions it may incorporate ?. It is now the time to talk about these issues if the draft shall consider the MPEG work. > I hope you will have a fruitful discussion on this subject in > Mineapolis. You can dowload the session slides and take a look at the presentation which is related to this email. cheers, Jose >But, this is not just an IETF issue. Therefore, > as both 3GPP > and MPEG are main "customers" of a timed text streaming solution, I > suggest that IETF requests 3GPP and MPEG to advice IETF as to the most > desirable direction for resolving this issue. Note that both 3GPP and > MPEG will have meetings where this issue can be discussed well before > the end of this year. > > Best regards, > > Jan van der Meer > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 04:32:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25203 for ; Tue, 11 Nov 2003 04:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJUse-0007a8-7A for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 04:32:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB9WCXR029140 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 04:32:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJUsT-0007ZB-3i; Tue, 11 Nov 2003 04:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJUrp-0007X9-32 for avt@optimus.ietf.org; Tue, 11 Nov 2003 04:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25168; Tue, 11 Nov 2003 04:31:07 -0500 (EST) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJUrl-0000I9-00; Tue, 11 Nov 2003 04:31:17 -0500 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 1AJUrk-0000I4-00; Tue, 11 Nov 2003 04:31:16 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 426292B7F5; Tue, 11 Nov 2003 10:31:13 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id E303D19C72; Tue, 11 Nov 2003 10:31:11 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id B2EB01A0E7; Tue, 11 Nov 2003 10:21:20 +0100 (MET) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id KAA00395; Tue, 11 Nov 2003 10:21:19 +0100 (MET) To: =?ISO-8859-1?Q?Jos=E9_Rey?= Cc: "'IETF AVT WG'" , avt-admin@ietf.org, "Colin Perkins" , "Magnus Westerlund" , "Yoshinori Matsui" , "'Dave Singer'" Subject: Re: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 11 Nov 2003 10:19:15 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1|June 9, 2003) at 11/11/2003 10:19:21, Serialize complete at 11/11/2003 10:19:21 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00336142C1256DDB_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00336142C1256DDB_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jos=E9, > Allowing both would mean that one does not have to implement RFC#simple > in order to transport timed text, which I think is desireable. Could you please clarify the above statement. It is possible to have a=20 straightforward solution for transport of time text based on RFC#simple=20 and your draft is a second and more complex solution that is more=20 desirable because then there is no need to implement the simpler one ?? Best regards, Jan Jos=E9 Rey Sent by:=20 avt-admin@ietf.org 2003-11-10 09:02 PM =20 To: Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS "'IETF AVT WG'" cc: "Colin Perkins" "Magnus Westerlund" "'Dave Singer'" "Yoshinori Matsui" Subject: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-t= imed-text-01.txt Classification:=20 Jan, all, > -----Urspr=FCngliche Nachricht----- > Von: Jos=E9 Rey [mailto:rey@panasonic.de] > Gesendet: Montag, 10. November 2003 18:11 > An: Jose Rey > Betreff: > > > Dear Jose, all, > > I will not be in Minneapolis either but would like to provide > some input > on the issue of transport of 3GPP timed text. I know this > input is very > late; my appologies for that. > > As you know also MPEG is working on timed text; currently the Committe > Draft (CD) is ballotted, and MPEG schedules to enter the next phase in > about one month and to finish the work in July 2004. The > end-result will > be part 17 of MPEG-4, defining MPEG-4 text streams. Through liaisons, > MPEG tries to harmonize its work with the work that is already carried > out in 3GPP and also with ongoing work in W3C. Most important in this > respect is that MPEG focusses at maximum commonality with the > timed text > format defined by 3GPP for download. In summary, the current CD of > MPEG-4 part 17 specifies streaming of the 3GPP timed text format by > defining a very straightforward way to transcode the 3GPP format into > the MPEG-4 structure of a decoder configuration and text access units. > Please find the Committee Draft (a public document) attached to this > email. So far, 3GPP expressed through liaison statements to be very > pleased with the work done by MPEG. > > Once the work is finished, the timed text format can be streamed using > "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is scheduled to > be published as RFC very soon. In summary this approach would work as > follows: > - media type: "video", > - MIME subtype name: mpeg4-generic, > - streamType (required parameter in RFC#simple): indicates MPEG-4 text > stream as defined in ISO 14496-17, > - profile-level-id (required parameter in RFC#simple): specifies the > functional subset as defined in the current 3GPP timed text > specification, > - config (required parameter in RFC#simple): carries the decoder > configuration specified for text streams in ISO 14496-17, > - the RTP payload contains either (a) one fragment of a text > access unit > or (b) one or more complete text access units, > - the RTP payload carries one AU-header for each carried text access > unit, > - in the RTP payload the concatenated AU-headers preceed concatenated > data of text access units, as defined in RFC#simple, > - each AU-header contains (at least) the following information on the > associated text access unit: (a) the size of the text access unit, (b) > the time stamp of the text access unit, > - if deemed necessary, the AU-header may also carry the index > of a text > access unit (fragment) and/or an indication whether the > associated text > access unit is a random access point. > In RFC#simple the fields in the AU-header are configurable, but if > desired one or two new modes for RFC#simple could be defined > with fixed > length fields, for example one using an 8 bit AU-size field (for most > common applications) and another using 16 bits AU-size field for > applications using (very) large text access units. > > The above "RFC#simple approach" has a high level of commonality with > draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small > differences that can be fixed either way, but roughly the "RFC#simple > approach" is a simplified version of > draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the > "RFC#simple" approach does not have the advanced error resiliency > measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt. > > In my view not only in IETF, but also in 3GPP and in MPEG a number of > basic issues should be discussed, such as: > - are the error resiliency features of > draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to > justify their complexity (note that a partly corrupted > subtitle may not > have much more value to the user than a missing one); This is a good question which I will also ask during my presentation on Monday. This is a question which certainly needs feedback of the group. The complexity can be reduced, we have to agree where to cut down: do we need the MTSF headers? or do we want to just keep resiliency for plain text fragments?, for example. PT multiplexing will probably be abandoned for a simpler scheme. > - is it desirable to define a 3GPP timed text transport solution based > on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one > that will be > available based on RFC#simple; Allowing both would mean that one does not have to implement RFC#simple in order to transport timed text, which I think is desireable. > - is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt > specifies a mode or an extension of RFC#simple; Would this mean that the RFC#simple has to be implemented to use the draft? I think this is not a good idea. > - how can a timing conflict (if any) between release 6 of > 3GPP and part > 17 of MPEG-4 be resolved (note that such conflict will only exist if > 3GPP adopts streaming of timed text as a work item and if 3GPP decides > that this functionality has to be in release 6). > We are targetting to include this in Release 6 (03/04). According to your information above MPEG4 timed text will be ready in July'04, which is out of the deadline. Apart from that, current Release 6 does not use the RFC#simple for streaming... so one would not be able to use timed text in Release 6. Assuming timed text comes into the Release 6 agenda, what I would like to know is what should, in your opinion, the current draft include in order to consider the MPEG work and the possible extensions it may incorporate ?. It is now the time to talk about these issues if the draft shall consider the MPEG work. > I hope you will have a fruitful discussion on this subject in > Mineapolis. You can dowload the session slides and take a look at the presentation which is related to this email. cheers, Jose >But, this is not just an IETF issue. Therefore, > as both 3GPP > and MPEG are main "customers" of a timed text streaming solution, I > suggest that IETF requests 3GPP and MPEG to advice IETF as to the most > desirable direction for resolving this issue. Note that both 3GPP and > MPEG will have meetings where this issue can be discussed well before > the end of this year. > > Best regards, > > Jan van der Meer > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 00336142C1256DDB_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Jos=E9,

> Allowing both would mean that = one does not have to implement RFC#simple
> in order to transport timed text, which I think is desireable.<= font size=3D2 face=3D"sans-serif">

Could you please clarify the above s= tatement. It is possible to have a straightforward solution for transport o= f time text based on RFC#simple and your draft is a second and more complex= solution that is more desirable because then there is no need to implement= the simpler one ??

Best regards,

Jan







Jos=E9 Rey <rey@panasonic.de&g= t;

Sent by:
avt-admin@ietf.org

2003-11-10 09:02 PM

       
        To: &nbs= p;      Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS
"'IETF AVT WG'" <avt@ietf.org>
        cc: &nbs= p;      "Colin Perkins" <csp@csperkins.org><= br> "Magnus Westerlund" <magnus.westerlund@ericsson.com>
"'Dave Singer'" <singer@apple.com>
"Yoshinori Matsui" <matsui.yoshinori@jp.panasonic.com>
        Subject:=        AW: [AVT] More comments on draft-rey-avt-rtp-3g= pp-timed-text-01.txt

        Classific= ation:        





Jan, all,


> -----Urspr=FCngliche Nachricht-----
> Von: Jos=E9 Rey [mailto:rey@panasonic.de]
> Gesendet: Montag, 10. November 2003 18:11
> An: Jose Rey
> Betreff:
>
>
> Dear Jose, all,
>
> I will not be in Minneapolis either but would like to provide
> some input
> on the issue of transport of 3GPP timed text. I know this
> input is very
> late; my appologies for that.
>
> As you know also MPEG is working on timed text; currently the Committe=
> Draft (CD) is ballotted, and MPEG schedules to enter the next phase in=
> about one month and to finish the work in July 2004. The
> end-result will
> be part 17 of MPEG-4, defining MPEG-4 text streams. Through liaisons,<= br> > MPEG tries to harmonize its work with the work that is already carried=
> out in 3GPP and also with ongoing work in W3C. Most important in this<= br> > respect is that MPEG focusses at maximum commonality with the
> timed text
> format defined by 3GPP for download. In summary, the current CD of
> MPEG-4 part 17 specifies streaming of the 3GPP timed text format by
> defining a very straightforward way to transcode the 3GPP format into<= br> > the MPEG-4 structure of a decoder configuration and text access units.=
> Please find the Committee Draft (a public document) attached to this > email. So far, 3GPP expressed through liaison statements to be very
> pleased with the work done by MPEG.
>
> Once the work is finished, the timed text format can be streamed using=
> "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is sc= heduled to
> be published as RFC very soon. In summary this approach would work as<= br> > follows:
> - media type: "video",
> - MIME subtype name: mpeg4-generic,
> - streamType (required parameter in RFC#simple): indicates MPEG-4 text=
> stream as defined in ISO 14496-17,
> - profile-level-id (required parameter in RFC#simple): specifies the > functional subset as defined in the current 3GPP timed text
> specification,
> - config (required parameter in RFC#simple): carries the decoder
> configuration specified for text streams in ISO 14496-17,
> - the RTP payload contains either (a) one fragment of a text
> access unit
> or (b) one or more complete text access units,
> - the RTP payload carries one AU-header for each carried text access > unit,
> - in the RTP payload the concatenated AU-headers preceed concatenated<= br> > data of text access units, as defined in RFC#simple,
> - each AU-header contains (at least) the following information on the<= br> > associated text access unit: (a) the size of the text access unit, (b)=
> the time stamp of the text access unit,
> - if deemed necessary, the AU-header may also carry the index
> of a text
> access unit (fragment) and/or an indication whether the
> associated text
> access unit is a random access point.
> In RFC#simple the fields in the AU-header are configurable, but if
> desired one or two new modes for RFC#simple could be defined
> with fixed
> length fields, for example one using an 8 bit AU-size field (for most<= br> > common applications) and another using 16 bits AU-size field for
> applications using (very) large text access units.
>
> The above "RFC#simple approach" has a high level of commonal= ity with
> draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small
> differences that can be fixed either way, but roughly the "RFC#si= mple
> approach" is a simplified version of
> draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the
> "RFC#simple" approach does not have the advanced error resil= iency
> measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt.
>
> In my view not only in IETF, but also in 3GPP and in MPEG a number of<= br> > basic issues should be discussed, such as:
> - are the error resiliency features of
> draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to
> justify their complexity (note that a partly corrupted
> subtitle may not
> have much more value to the user than a missing one);

This is a good question which I will also ask during my presentation on
Monday.  This is a question which certainly needs feedback of the grou= p.
The complexity can be reduced, we have to agree where to cut down: do we
need the MTSF headers? or do we want to just keep resiliency for plain
text fragments?, for example.  PT multiplexing will probably be
abandoned for a simpler scheme.

> - is it desirable to define a 3GPP timed text transport solution based=
> on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one
> that will be
> available based on RFC#simple;

Allowing both would mean that one does not have to implement RFC#simple
in order to transport timed text, which I think is desireable.

> - is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt
> specifies a mode or an extension of RFC#simple;

Would this mean that the RFC#simple has to be implemented to use the
draft? I think this is not a good idea.

> - how can a timing conflict (if any) between release 6 of
> 3GPP and part
> 17 of MPEG-4 be resolved (note that such conflict will only exist if > 3GPP adopts streaming of timed text as a work item and if 3GPP decides=
> that this functionality has to be in release 6).
>

We are targetting to include this in Release 6 (03/04). According to
your information above MPEG4 timed text will be ready in July'04, which
is out of the deadline. Apart from that, current Release 6 does not use
the RFC#simple for streaming... so one would not be able to use timed
text in Release 6.

Assuming timed text comes into the Release 6 agenda, what I would like
to know is what should, in your opinion, the current draft include in
order to consider the MPEG work and the possible extensions it may
incorporate ?. It is now the time to talk about these issues if the
draft shall consider the MPEG work.


> I hope you will have a fruitful discussion on this subject in
> Mineapolis.

You can dowload the session slides and take  a look at the presentatio= n
which is related to this email.

cheers,

Jose

>But, this is not just an IETF issue. Therefore,
> as both 3GPP
> and MPEG are main "customers" of a timed text streaming solu= tion, I
> suggest that IETF requests 3GPP and MPEG to advice IETF as to the most=
> desirable direction for resolving this issue. Note that both 3GPP and<= br> > MPEG will have meetings where this issue can be discussed well before<= br> > the end of this year.
>
> Best regards,
>
> Jan van der Meer
>
>


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

--=_alternative 00336142C1256DDB_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 05:17:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26118 for ; Tue, 11 Nov 2003 05:17:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVa5-0001S0-K1 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 05:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABAH5o8005548 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 05:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVa3-0001RN-Jc; Tue, 11 Nov 2003 05:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVZH-0001Na-8m for avt@optimus.ietf.org; Tue, 11 Nov 2003 05:16:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26061; Tue, 11 Nov 2003 05:16:02 -0500 (EST) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJVZD-0000l9-00; Tue, 11 Nov 2003 05:16:11 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AJVZD-0000l6-00; Tue, 11 Nov 2003 05:16:11 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 4EA7161A07; Tue, 11 Nov 2003 11:16:08 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 5F54419C4B; Tue, 11 Nov 2003 11:16:07 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id A130419C48; Tue, 11 Nov 2003 11:16:06 +0100 (MET) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id LAA17114; Tue, 11 Nov 2003 11:16:06 +0100 (MET) To: Colin Perkins Cc: avt@ietf.org, avt-admin@ietf.org Subject: Re: [AVT] Slides for Monday AVT session X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 11 Nov 2003 11:13:23 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1|June 9, 2003) at 11/11/2003 11:14:07, Serialize complete at 11/11/2003 11:14:07 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00385676C1256DDB_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00385676C1256DDB_= Content-Type: text/plain; charset="us-ascii" Hello Colin, Thanks for making the slides available. I can read all of them, except the one on Timed Text, which is corrupted when reading it with my Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I would appreciate if you could resolve that. Best regards, Jan Colin Perkins Sent by: avt-admin@ietf.org 2003-11-10 05:14 PM To: avt@ietf.org cc: Magnus Westerlund (bcc: Jan vanderMeer/EHV/CE/PHILIPS) Subject: [AVT] Slides for Monday AVT session Classification: Copies of the presentation materials which will be used in AVT this afternoon can be retrieved as http://www.dcs.gla.ac.uk/~csp/ietf58-avt-mon.zip These will migrate onto the IETF server after the meeting. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 00385676C1256DDB_= Content-Type: text/html; charset="us-ascii"
Hello Colin,

Thanks for making the slides available. I can read all of them, except the one on Timed Text, which is corrupted when reading it with my Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I would appreciate if you could resolve that.

Best regards,

Jan







Colin Perkins <csp@csperkins.org>

Sent by:
avt-admin@ietf.org

2003-11-10 05:14 PM

       
        To:        avt@ietf.org
        cc:        Magnus Westerlund <magnus.westerlund@ericsson.com>
(bcc: Jan vanderMeer/EHV/CE/PHILIPS)
        Subject:        [AVT] Slides for Monday AVT session

        Classification:        




Copies of the presentation materials which will be used in AVT this
afternoon can be retrieved as
http://www.dcs.gla.ac.uk/~csp/ietf58-avt-mon.zip

These will migrate onto the IETF server after the meeting.

Colin


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

--=_alternative 00385676C1256DDB_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 11:12:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07571 for ; Tue, 11 Nov 2003 11:12:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb7o-0002q5-JI for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:12:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGCG5D010869 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:12:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb7Y-0002o7-Q1; Tue, 11 Nov 2003 11:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb7S-0002nd-U5 for avt@optimus.ietf.org; Tue, 11 Nov 2003 11:11:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07550 for ; Tue, 11 Nov 2003 11:11:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJb7Q-0005CR-00 for avt@ietf.org; Tue, 11 Nov 2003 11:11:52 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AJb7P-0005CM-00 for avt@ietf.org; Tue, 11 Nov 2003 11:11:51 -0500 Received: from dyn133-85.ietf58.ietf.org ([130.129.133.85]:51020 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AJb6u-0006e7-00; Tue, 11 Nov 2003 16:11:20 +0000 Date: Tue, 11 Nov 2003 11:11:18 -0500 Subject: Re: [AVT] Slides for Monday AVT session Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: avt@ietf.org To: jan.vandermeer@philips.com From: Colin Perkins In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, Nov 11, 2003, at 05:13 US/Eastern, jan.vandermeer@philips.com wrote: > Thanks for making the slides available. I can read all of them, except > the one on Timed Text, which is corrupted when reading it with my > Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I > would appreciate if you could resolve that. I updated the zip file - maybe it's better now? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 11:26:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08272 for ; Tue, 11 Nov 2003 11:26:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbLD-0004ET-KN for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGQ77R016267 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbL8-00049D-Lz; Tue, 11 Nov 2003 11:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbKO-00040e-7i for avt@optimus.ietf.org; Tue, 11 Nov 2003 11:25:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08135; Tue, 11 Nov 2003 11:25:03 -0500 (EST) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbKN-0005PO-00; Tue, 11 Nov 2003 11:25:15 -0500 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 1AJbKM-0005PK-00; Tue, 11 Nov 2003 11:25:14 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 8BACA2B7D9; Tue, 11 Nov 2003 17:25:08 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 407A519C45; Tue, 11 Nov 2003 17:25:08 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id DE6E119C46; Tue, 11 Nov 2003 17:25:07 +0100 (MET) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id RAA15507; Tue, 11 Nov 2003 17:25:07 +0100 (MET) To: Colin Perkins Cc: avt@ietf.org, avt-admin@ietf.org Subject: Re: [AVT] Slides for Monday AVT session X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 11 Nov 2003 17:23:06 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1|June 9, 2003) at 11/11/2003 17:23:08, Serialize complete at 11/11/2003 17:23:08 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005A2F8DC1256DDB_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 005A2F8DC1256DDB_= Content-Type: text/plain; charset="us-ascii" Colin, Thanks for your effort, but unfortunately the timed-text presentation is still corrupted. Because of the problem I installed the latest version of the Acrobat Reader, but that did not help. Best regards, Jan Colin Perkins Sent by: avt-admin@ietf.org 2003-11-11 05:11 PM To: Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS cc: avt@ietf.org Subject: Re: [AVT] Slides for Monday AVT session Classification: On Tuesday, Nov 11, 2003, at 05:13 US/Eastern, jan.vandermeer@philips.com wrote: > Thanks for making the slides available. I can read all of them, except > the one on Timed Text, which is corrupted when reading it with my > Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I > would appreciate if you could resolve that. I updated the zip file - maybe it's better now? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 005A2F8DC1256DDB_= Content-Type: text/html; charset="us-ascii"
Colin,

Thanks for your effort, but unfortunately the timed-text presentation is still corrupted. Because of the problem I installed the latest version of the Acrobat Reader, but that did not help.

Best regards,

Jan







Colin Perkins <csp@csperkins.org>

Sent by:
avt-admin@ietf.org

2003-11-11 05:11 PM

       
        To:        Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS
        cc:        avt@ietf.org
        Subject:        Re: [AVT] Slides for Monday AVT session

        Classification:        




On Tuesday, Nov 11, 2003, at 05:13 US/Eastern,
jan.vandermeer@philips.com wrote:
> Thanks for making the slides available. I can read all of them, except
> the one on Timed Text, which is corrupted when reading it with my
> Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I
> would appreciate if you could resolve that.

I updated the zip file - maybe it's better now?

Colin


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

--=_alternative 005A2F8DC1256DDB_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 11:28:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08468 for ; Tue, 11 Nov 2003 11:28:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbN8-0004ZA-80 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:28:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGS6bG017535 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbN4-0004YH-EY; Tue, 11 Nov 2003 11:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbMV-0004W0-4i for avt@optimus.ietf.org; Tue, 11 Nov 2003 11:27:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08352 for ; Tue, 11 Nov 2003 11:27:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbMU-0005Rz-00 for avt@ietf.org; Tue, 11 Nov 2003 11:27:26 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AJbMT-0005Rw-00 for avt@ietf.org; Tue, 11 Nov 2003 11:27:25 -0500 Received: from mcomlap9 ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 17:27:13 +0100 From: "Jose Rey" To: , "'IETF AVT WG'" Cc: "Colin Perkins" , "Magnus Westerlund" , "'Dave Singer'" , "Yoshinori Matsui" Subject: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Date: Tue, 11 Nov 2003 17:27:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-OriginalArrivalTime: 11 Nov 2003 16:27:13.0289 (UTC) FILETIME=[A9AB5F90:01C3A870] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08353 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, for those that did not attend the AVT session on Monday, there was a number of comments and useful feedback during the timed text presentation. In particular, it was suggested that the draft sticks too much to the 3gp file format itself and does not look at the particularities of the RTP transport (Colin please correct me if the language is wrong). Currently the draft just reads the text samples from the 3gp file and puts them into RTP packets. If a packet is too big for one RTP packet then it is cut and a fragment header is used to be able to interpret the information in that fragment. As long as fragmentation happens rarely then this could be the best option. On the other side, there's the option (which I call 'pure ALF approach' in the slides) to preprocess the data read from the 3gp file before packetising. This preprocessing would not only cut the text samples to fix the RTP packet size but also re-arrange the packets so that the fragments are not only self-contained but contain all the decorations. This approach requires to define extra headers for the cases in which the modifier boxes would have to be split into several RTP packets. You can download some clarifying slides at http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format or from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in MSPowerPoint format. The current approach makes sense if the text samples are regularly small and one or several of them fit into an RTP packet. Fragmentation would happen seldom. The 'pure alf approach' is, in general, the most correct one, and so also the one that requires more header definitions. If fragmentation is a rare event, this overhead may be not worth (?). The question to the group is pretty simple: which approach should be pursued? We appreciate your feedback, cheers, Jose > -----Urspr=FCngliche Nachricht----- > Von: avt-admin@ietf.org [mailto:avt-admin@ietf.org]Im Auftrag von Jos=E9 > Rey > Gesendet: Montag, 10. November 2003 21:02 > An: jan.vandermeer@philips.com; 'IETF AVT WG' > Cc: Colin Perkins; Magnus Westerlund; 'Dave Singer'; Yoshinori Matsui > Betreff: AW: [AVT] More comments on > draft-rey-avt-rtp-3gpp-timed-text-01.txt > > > > Jan, all, > > > > -----Urspr=FCngliche Nachricht----- > > Von: Jos=E9 Rey [mailto:rey@panasonic.de] > > Gesendet: Montag, 10. November 2003 18:11 > > An: Jose Rey > > Betreff: > > > > > > Dear Jose, all, > > > > I will not be in Minneapolis either but would like to provide > > some input > > on the issue of transport of 3GPP timed text. I know this > > input is very > > late; my appologies for that. > > > > As you know also MPEG is working on timed text; currently > the Committe > > Draft (CD) is ballotted, and MPEG schedules to enter the > next phase in > > about one month and to finish the work in July 2004. The > > end-result will > > be part 17 of MPEG-4, defining MPEG-4 text streams. Through > liaisons, > > MPEG tries to harmonize its work with the work that is > already carried > > out in 3GPP and also with ongoing work in W3C. Most > important in this > > respect is that MPEG focusses at maximum commonality with the > > timed text > > format defined by 3GPP for download. In summary, the current CD of > > MPEG-4 part 17 specifies streaming of the 3GPP timed text format by > > defining a very straightforward way to transcode the 3GPP > format into > > the MPEG-4 structure of a decoder configuration and text > access units. > > Please find the Committee Draft (a public document) attached to this > > email. So far, 3GPP expressed through liaison statements to be very > > pleased with the work done by MPEG. > > > > Once the work is finished, the timed text format can be > streamed using > > "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is > scheduled to > > be published as RFC very soon. In summary this approach > would work as > > follows: > > - media type: "video", > > - MIME subtype name: mpeg4-generic, > > - streamType (required parameter in RFC#simple): indicates > MPEG-4 text > > stream as defined in ISO 14496-17, > > - profile-level-id (required parameter in RFC#simple): specifies the > > functional subset as defined in the current 3GPP timed text > > specification, > > - config (required parameter in RFC#simple): carries the decoder > > configuration specified for text streams in ISO 14496-17, > > - the RTP payload contains either (a) one fragment of a text > > access unit > > or (b) one or more complete text access units, > > - the RTP payload carries one AU-header for each carried text access > > unit, > > - in the RTP payload the concatenated AU-headers preceed > concatenated > > data of text access units, as defined in RFC#simple, > > - each AU-header contains (at least) the following > information on the > > associated text access unit: (a) the size of the text > access unit, (b) > > the time stamp of the text access unit, > > - if deemed necessary, the AU-header may also carry the index > > of a text > > access unit (fragment) and/or an indication whether the > > associated text > > access unit is a random access point. > > In RFC#simple the fields in the AU-header are configurable, but if > > desired one or two new modes for RFC#simple could be defined > > with fixed > > length fields, for example one using an 8 bit AU-size field > (for most > > common applications) and another using 16 bits AU-size field for > > applications using (very) large text access units. > > > > The above "RFC#simple approach" has a high level of commonality with > > draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small > > differences that can be fixed either way, but roughly the > "RFC#simple > > approach" is a simplified version of > > draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the > > "RFC#simple" approach does not have the advanced error resiliency > > measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt. > > > > In my view not only in IETF, but also in 3GPP and in MPEG a > number of > > basic issues should be discussed, such as: > > - are the error resiliency features of > > draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to > > justify their complexity (note that a partly corrupted > > subtitle may not > > have much more value to the user than a missing one); > > This is a good question which I will also ask during my > presentation on > Monday. This is a question which certainly needs feedback of > the group. > The complexity can be reduced, we have to agree where to cut > down: do we > need the MTSF headers? or do we want to just keep resiliency for plain > text fragments?, for example. PT multiplexing will probably be > abandoned for a simpler scheme. > > > - is it desirable to define a 3GPP timed text transport > solution based > > on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one > > that will be > > available based on RFC#simple; > > Allowing both would mean that one does not have to implement > RFC#simple > in order to transport timed text, which I think is desireable. > > > - is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt > > specifies a mode or an extension of RFC#simple; > > Would this mean that the RFC#simple has to be implemented to use the > draft? I think this is not a good idea. > > > - how can a timing conflict (if any) between release 6 of > > 3GPP and part > > 17 of MPEG-4 be resolved (note that such conflict will only exist if > > 3GPP adopts streaming of timed text as a work item and if > 3GPP decides > > that this functionality has to be in release 6). > > > > We are targetting to include this in Release 6 (03/04). According to > your information above MPEG4 timed text will be ready in > July'04, which > is out of the deadline. Apart from that, current Release 6 > does not use > the RFC#simple for streaming... so one would not be able to use timed > text in Release 6. > > Assuming timed text comes into the Release 6 agenda, what I would like > to know is what should, in your opinion, the current draft include in > order to consider the MPEG work and the possible extensions it may > incorporate ?. It is now the time to talk about these issues if the > draft shall consider the MPEG work. > > > > I hope you will have a fruitful discussion on this subject in > > Mineapolis. > > You can dowload the session slides and take a look at the > presentation > which is related to this email. > > cheers, > > Jose > > >But, this is not just an IETF issue. Therefore, > > as both 3GPP > > and MPEG are main "customers" of a timed text streaming solution, I > > suggest that IETF requests 3GPP and MPEG to advice IETF as > to the most > > desirable direction for resolving this issue. Note that > both 3GPP and > > MPEG will have meetings where this issue can be discussed > well before > > the end of this year. > > > > Best regards, > > > > Jan van der Meer > > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Nov 11 11:33:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08578 for ; Tue, 11 Nov 2003 11:33:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbRw-0004o5-CX for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:33:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGX4c4018460 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbRt-0004nB-O0; Tue, 11 Nov 2003 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbRV-0004mh-LB for avt@optimus.ietf.org; Tue, 11 Nov 2003 11:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08563 for ; Tue, 11 Nov 2003 11:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbRU-0005XN-00 for avt@ietf.org; Tue, 11 Nov 2003 11:32:36 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AJbRU-0005XK-00 for avt@ietf.org; Tue, 11 Nov 2003 11:32:36 -0500 Received: from mcomlap9 ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 17:31:38 +0100 From: "Jose Rey" To: , "Colin Perkins" Cc: Subject: AW: [AVT] Slides for Monday AVT session Date: Tue, 11 Nov 2003 17:31:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C3A879.A9B7A580" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-OriginalArrivalTime: 11 Nov 2003 16:31:38.0637 (UTC) FILETIME=[47D443D0:01C3A871] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C3A879.A9B7A580 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08564 Content-Transfer-Encoding: quoted-printable Jan, you can download the ppt version of it under http://www.pel.panasonic.de/ietf/docs/ietf58-tt.ppt cheers, Jos=E9 -----Urspr=FCngliche Nachricht----- Von: avt-admin@ietf.org [mailto:avt-admin@ietf.org]Im Auftrag von jan.vandermeer@philips.com Gesendet: Dienstag, 11. November 2003 17:23 An: Colin Perkins Cc: avt@ietf.org; avt-admin@ietf.org Betreff: Re: [AVT] Slides for Monday AVT session Colin, Thanks for your effort, but unfortunately the timed-text presentation i= s still corrupted. Because of the problem I installed the latest version of the Acrobat Reader, but that did not help. Best regards, Jan Colin Perkins Sent by: avt-admin@ietf.org 2003-11-11 05:11 PM To: Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS cc: avt@ietf.org Subject: Re: [AVT] Slides for Monday AVT session Classification: On Tuesday, Nov 11, 2003, at 05:13 US/Eastern, jan.vandermeer@philips.com wrote: > Thanks for making the slides available. I can read all of them, excep= t > the one on Timed Text, which is corrupted when reading it with my > Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I > would appreciate if you could resolve that. I updated the zip file - maybe it's better now? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------=_NextPart_000_0006_01C3A879.A9B7A580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jan,=20 you can download the ppt version of it under http://www.p= el.panasonic.de/ietf/docs/ietf58-tt.ppt
 
cheers,
 
Jos=E9
 
 
-----Urspr=FCngliche Nachricht-----
Von: = avt-admin@ietf.org=20 [mailto:avt-admin@ietf.org]Im Auftrag von=20 jan.vandermeer@philips.com
Gesendet: Dienstag, 11. = November 2003=20 17:23
An: Colin Perkins
Cc: avt@ietf.org;=20 avt-admin@ietf.org
Betreff: Re: [AVT] Slides for Monday AVT=20 session


Colin,=20

Thanks for your effort, but = unfortunately=20 the timed-text presentation is still corrupted. Because of the problem = I=20 installed the latest version of the Acrobat Reader, but that did not=20 help.

Best=20 regards,

Jan








Colin = Perkins=20 <csp@csperkins.org>=20

Sent by:
avt-admin@ietf.org=20

2003-11-11 05:11 PM =

        =
        To: =    =20    Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS =
        cc: =    =20    avt@ietf.org
 =20       Subject:        Re: = [AVT]=20 Slides for Monday AVT session=20

       =20 Classification:        =20




On=20 Tuesday, Nov 11, 2003, at 05:13 US/Eastern, =
jan.vandermeer@philips.com=20 wrote:
> Thanks for making the slides available. I can read all = of them,=20 except
> the one on Timed Text, which is corrupted when reading = it with=20 my
> Acrobat Reader 6.0. Acrobat tells it's a font encoding = problem. I=20
> would appreciate if you could resolve that.

I updated = the zip=20 file - maybe it's better=20 = now?

Colin


____________________________________________= ___
Audio/Video=20 Transport Working=20 = Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt


------=_NextPart_000_0006_01C3A879.A9B7A580-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 11:38:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08877 for ; Tue, 11 Nov 2003 11:38:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbWm-0005uz-Or for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:38:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGc3Jw022682 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbWk-0005tK-1E; Tue, 11 Nov 2003 11:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbVp-0005bN-3T for avt@optimus.ietf.org; Tue, 11 Nov 2003 11:37:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08782; Tue, 11 Nov 2003 11:36:52 -0500 (EST) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbVn-0005bQ-00; Tue, 11 Nov 2003 11:37:03 -0500 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 1AJbVm-0005bN-00; Tue, 11 Nov 2003 11:37:03 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl4.philips.com (Postfix) with ESMTP id B61FE2B9EC; Tue, 11 Nov 2003 17:37:02 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 7518919C45; Tue, 11 Nov 2003 17:37:01 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id D895619C4B; Tue, 11 Nov 2003 17:37:00 +0100 (MET) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id RAA20515; Tue, 11 Nov 2003 17:37:00 +0100 (MET) To: Colin Perkins Cc: avt@ietf.org, avt-admin@ietf.org Subject: Re: [AVT] Slides for Monday AVT session X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 11 Nov 2003 17:34:58 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1|June 9, 2003) at 11/11/2003 17:35:01, Serialize complete at 11/11/2003 17:35:01 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005B45DCC1256DDB_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 005B45DCC1256DDB_= Content-Type: text/plain; charset="us-ascii" Hello Colin, From Jose's latest email: > You can download some clarifying slides at > http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format or > from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in MSPowerPoint > format. The pdf above does not work for me either, but the ppt does. Perhaps it is possible to upload the original ppt ? Best regards, Jan Jan vanderMeer 2003-11-11 05:23 PM To: Colin Perkins cc: avt@ietf.org avt-admin@ietf.org Subject: Re: [AVT] Slides for Monday AVT session Classification: Unclassified Colin, Thanks for your effort, but unfortunately the timed-text presentation is still corrupted. Because of the problem I installed the latest version of the Acrobat Reader, but that did not help. Best regards, Jan Colin Perkins Sent by: avt-admin@ietf.org 2003-11-11 05:11 PM To: Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS cc: avt@ietf.org Subject: Re: [AVT] Slides for Monday AVT session Classification: On Tuesday, Nov 11, 2003, at 05:13 US/Eastern, jan.vandermeer@philips.com wrote: > Thanks for making the slides available. I can read all of them, except > the one on Timed Text, which is corrupted when reading it with my > Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I > would appreciate if you could resolve that. I updated the zip file - maybe it's better now? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 005B45DCC1256DDB_= Content-Type: text/html; charset="us-ascii"
Hello Colin,

From Jose's latest email:

> You can download some clarifying slides at
> http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format or
> from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in MSPowerPoint
> format.

The pdf above does not work for me either, but the ppt does. Perhaps it is possible to upload the original ppt ?

Best regards,

Jan







Jan vanderMeer

2003-11-11 05:23 PM


        To:        Colin Perkins <csp@csperkins.org>
        cc:        avt@ietf.org
avt-admin@ietf.org
        Subject:        Re: [AVT] Slides for Monday AVT sessionLink

        Classification:        Unclassified



Colin,

Thanks for your effort, but unfortunately the timed-text presentation is still corrupted. Because of the problem I installed the latest version of the Acrobat Reader, but that did not help.

Best regards,

Jan







Colin Perkins <csp@csperkins.org>

Sent by:
avt-admin@ietf.org

2003-11-11 05:11 PM

       
        To:        Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS
        cc:        avt@ietf.org
        Subject:        Re: [AVT] Slides for Monday AVT session

        Classification:        




On Tuesday, Nov 11, 2003, at 05:13 US/Eastern,
jan.vandermeer@philips.com wrote:
> Thanks for making the slides available. I can read all of them, except
> the one on Timed Text, which is corrupted when reading it with my
> Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I
> would appreciate if you could resolve that.

I updated the zip file - maybe it's better now?

Colin


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt



--=_alternative 005B45DCC1256DDB_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 11:53:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09655 for ; Tue, 11 Nov 2003 11:53:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJblI-00089m-Nr for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGr46W031352 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 11:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJblF-00088T-In; Tue, 11 Nov 2003 11:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbku-00086o-FI for avt@optimus.ietf.org; Tue, 11 Nov 2003 11:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09617 for ; Tue, 11 Nov 2003 11:52:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbkt-0005vN-00 for avt@ietf.org; Tue, 11 Nov 2003 11:52:39 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AJbks-0005vK-00 for avt@ietf.org; Tue, 11 Nov 2003 11:52:38 -0500 Received: from mcomlap9 ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 17:52:29 +0100 From: "Jose Rey" To: , "Colin Perkins" Cc: Subject: AW: [AVT] Slides for Monday AVT session Date: Tue, 11 Nov 2003 17:52:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C3A87C.93081F60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-OriginalArrivalTime: 11 Nov 2003 16:52:29.0663 (UTC) FILETIME=[317FAEF0:01C3A874] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C3A87C.93081F60 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA09618 Content-Transfer-Encoding: quoted-printable Jan, > You can download some clarifying slides at > http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format or > from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in MSPowerPoin= t > format. the ppt is also there, as it says above. cheers, Jos=E9 -----Urspr=FCngliche Nachricht----- Von: avt-admin@ietf.org [mailto:avt-admin@ietf.org]Im Auftrag von jan.vandermeer@philips.com Gesendet: Dienstag, 11. November 2003 17:35 An: Colin Perkins Cc: avt@ietf.org; avt-admin@ietf.org Betreff: Re: [AVT] Slides for Monday AVT session Hello Colin, From Jose's latest email: > You can download some clarifying slides at > http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format or > from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in MSPowerPo= int > format. The pdf above does not work for me either, but the ppt does. Perhaps it= is possible to upload the original ppt ? Best regards, Jan Jan vanderMeer 2003-11-11 05:23 PM To: Colin Perkins cc: avt@ietf.org avt-admin@ietf.org Subject: Re: [AVT] Slides for Monday AVT sessionLi= nk Classification: Unclassified Colin, Thanks for your effort, but unfortunately the timed-text presentation i= s still corrupted. Because of the problem I installed the latest version of the Acrobat Reader, but that did not help. Best regards, Jan Colin Perkins Sent by: avt-admin@ietf.org 2003-11-11 05:11 PM To: Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS cc: avt@ietf.org Subject: Re: [AVT] Slides for Monday AVT session Classification: On Tuesday, Nov 11, 2003, at 05:13 US/Eastern, jan.vandermeer@philips.com wrote: > Thanks for making the slides available. I can read all of them, excep= t > the one on Timed Text, which is corrupted when reading it with my > Acrobat Reader 6.0. Acrobat tells it's a font encoding problem. I > would appreciate if you could resolve that. I updated the zip file - maybe it's better now? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------=_NextPart_000_0006_01C3A87C.93081F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jan,=20
 
> You can download some clarifying = slides=20 at
> http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf = format=20 or
> from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in=20 MSPowerPoint
> format.
 
the ppt is also there, as it says=20 above.
 
cheers,
 
Jos=E9
 
 
-----Urspr=FCngliche Nachricht-----
Von: = avt-admin@ietf.org=20 [mailto:avt-admin@ietf.org]Im Auftrag von=20 jan.vandermeer@philips.com
Gesendet: Dienstag, 11. = November 2003=20 17:35
An: Colin Perkins
Cc: avt@ietf.org;=20 avt-admin@ietf.org
Betreff: Re: [AVT] Slides for Monday AVT=20 session


Hello = Colin,

From Jose's = latest=20 email:

> You can = download=20 some clarifying slides at
>=20 http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format = or
>=20 from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in=20 MSPowerPoint
> format.

The=20 pdf above does not work for me either, but the ppt does. Perhaps it is = possible to upload the original ppt ?

Best regards,

Jan








Jan=20 vanderMeer=20

2003-11-11 05:23 PM =


      =   To:=20        Colin Perkins=20 <csp@csperkins.org>
 =20       cc:      =20  avt@ietf.org
avt-admin@ietf.org
        Subject: =  =20      Re: [AVT] Slides for Monday AVT = sessionLink=20

       =20 Classification:        Unclassified=20



Colin,

Thanks = for your=20 effort, but unfortunately the timed-text presentation is still = corrupted.=20 Because of the problem I installed the latest version of the Acrobat = Reader,=20 but that did not help.

Best=20 regards,

Jan








Colin = Perkins=20 <csp@csperkins.org>=20

Sent by:
avt-admin@ietf.org=20

2003-11-11 05:11 PM =

        =
        To: =    =20    Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS =
        cc: =    =20    avt@ietf.org
 =20       Subject:        Re: = [AVT]=20 Slides for Monday AVT session=20

       =20 Classification:        =20




On=20 Tuesday, Nov 11, 2003, at 05:13 US/Eastern, =
jan.vandermeer@philips.com=20 wrote:
> Thanks for making the slides available. I can read all = of them,=20 except
> the one on Timed Text, which is corrupted when reading = it with=20 my
> Acrobat Reader 6.0. Acrobat tells it's a font encoding = problem. I=20
> would appreciate if you could resolve that.

I updated = the zip=20 file - maybe it's better=20 = now?

Colin


____________________________________________= ___
Audio/Video=20 Transport Working=20 = Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt




------=_NextPart_000_0006_01C3A87C.93081F60-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 12:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10737 for ; Tue, 11 Nov 2003 12:12:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc3f-0002Ij-FU for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 12:12:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHC3uA008839 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 12:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc3d-0002I4-PC; Tue, 11 Nov 2003 12:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc2y-0002GE-2N for avt@optimus.ietf.org; Tue, 11 Nov 2003 12:11:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10648 for ; Tue, 11 Nov 2003 12:11:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJc2w-0006I3-00 for avt@ietf.org; Tue, 11 Nov 2003 12:11:18 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AJc2v-0006Ge-00 for avt@ietf.org; Tue, 11 Nov 2003 12:11:17 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id hABH9wio068566; Tue, 11 Nov 2003 09:09:58 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Nov 2003 09:09:57 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17CAA@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" , Gamze Seckin Cc: Alan Tseng , IETF AVT WG Subject: RE: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt Date: Tue, 11 Nov 2003 09:09:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Alan and Gamze: My comments on this draft: General comment: would it be possible to provide the means for server to signal to client the interval for Quality Metrics reporting? For instance an optional parameter in RTSP Play response? 1. Like Magnus, I don't feel "AVP Module" (defined in section 2) is a right choice of name. I suggest "Transport Handler" might be a better fit in naming the concept (to differentiate with source codec). 2. Please in the introduction provide some insight of your motivations. If one implements this draft, would one use it for debugging only, or for billing also? We'd like to see a generic proposal that will, if possible, satisfy the desire to do QOS based billing, as well as network monitoring / user experience monitoring/survey. 3. In section 3.3, it appeared that it is assuming that a RTP packet will contain only one or partial VOP so that the AVP module could determine the corruption period from the RTP timestamp. However, in the multi-VOP RTP packet, then the corruption period need to contain multi-VOPs. Just a suggestion to consider the multi-VOP case. 4. Sometimes player freezes not due to "rebuffering" (underflow of player buffer). For example, for live streaming, packets not get sent by the server due to late arrival from author. If server drop packets intentionally, then the player will not detect seq number gap in this case. There could be other reason that player will freeze not due to rebuffering (but then jump in play time later). Will this be included in the rebuffering matrices? According to the definition, it should. So "rebuffering' in this draft does not always refer to "underflow of player buffer"? For instance, we've seen freezing due to overflow (caused by bad server scheduling) and/or player processor overload. 5.Typo on Page 10, "pts_stop" ... "beginning" should be "end" 6. On 3.4 last sentence, for rebuffering, then there should not reach end of playback since the player is not playing and the playtime is stalled. So we are not sure if this sentence applies to rebuffering (at least the rebuffering due to buffer underflow). It does have some implications if the player did not receive any more data and abort due to timeout (i.e., staying in rebuffering and timeout). So we think these two cases (normal rebuffering, or rebuffering with timeout) needs to be considered. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, November 05, 2003 11:41 PM > To: Gamze Seckin > Cc: Alan Tseng; IETF AVT WG > Subject: Re: [AVT] RE: Comments on > draft-tseng-rtcp-streaming-extns-00.txt > > > Hi Gamze, > > To my knowledge there is no profile dependencies in RFC 3611. Thus it > can be used for any of the four profiles defined or under > definition. My > comment was to point out this fact and that it seems inappropriate to > talk about any special profile in this context. > > cheers > > Magnus > > Gamze Seckin wrote: > > > Hi Magnus, > > > > about your comment > > "7. Section 2, You talk about AVP, but this extension is > not dependent on > > any special profile and seems to be compatible with any of the four > > available or under development profiles that exist." > > > > Do you also mean AVPF? Since I am confused about the > relationship between AVPF and RFC3611. > > > > thx > > g > > -----Original Message----- > > From: Gamze Seckin > > Sent: Friday, October 31, 2003 11:08 AM > > To: Magnus Westerlund; Alan Tseng > > Cc: IETF AVT WG > > Subject: [AVT] RE: Comments on > draft-tseng-rtcp-streaming-extns-00.txt > > > > > > > > Hi Magnus, > > thanks for the comments. > > See my response inline. > > > > best regards > > gamze > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Wednesday, October 29, 2003 8:17 AM > > To: Alan Tseng; Gamze Seckin > > Cc: IETF AVT WG > > Subject: Comments on draft-tseng-rtcp-streaming-extns-00.txt > > > > > > Hi, > > > > Here is my comments on your draft: > > > > 1. First I think the draft isn't very clear on why any metrics are > > needed. In the 3GPP document it only states: "The objective of the > > streaming service quality metrics is to offer to the > service providers > > means to evaluate the end user experience.". This doesn't > make it very > > clear what the real needs are. I think further developing > of this is > > needed. > > > > [g]you are right, the draft does not talk about that > clearly. We should add that. > > > > 2. Regarding the corruption statistics. For media that uses > codec that > > have prediction any error normally remains for a rather long time. > > However it is very difficult to determine when the effects has been > > removed. Therefore this measurement is hard to derive on > the receiver > > side. Combined with the definition it only provides a good, > possibly bad > > indication. Also looking at the reasons for corruption, the > only real > > reason is lost or late packets. A good feeling for the > quality can be > > determined by the server simply by employing packet loss vector > > reporting and knowing when the buffer is empty. > > > > [g]packet loss is definitely a way of estimating > corruption, but this gives an algorithm in the decoder (or > pre-decoder)a chance to provide better statistics. > > > > 3. The rebuffering measurements makes more sense. However > there are at > > least one client that does not really perform rebuffering, namely > > quicktime. Instead is assumes that if the transmitted bit-rate is > > acceptable any short term effects will go away and the > client will later > > have a buffer fullness given by the initial buffering delay. The > > interesting thing about this measurement is that in 3GPP > they already > > have a way of letting the server measure when rebuffering > takes place, > > namely the OBSN reporting specified in TS 26.234 REL 6 > (only preliminary > > versions available). > > > > [g] yes, and I believe those statistics are useful, however > they are tight with rate adaptation (only turned on when > rate-adaptation is enabled) and tightly coupled with other > rtsp messages. > > > > 4. As state privately before this drafts need to be checked > against the > > ID nits: http://www.ietf.org/ID-nits.html > > > > [g] yes, we should definitely do that thanks. > > > > 5. Section 1. The introduction is basically the same as the > > introduction. I would recommend you to write a better more > informative > > introduction. > > > > [g] agreed. > > > > 6. Section 1. Last sentence: "As all the other report blocks > > defined in [1], the streaming report blocks are applicable to > > one-to-one or one-to-many applications that generate > > RTCP SR or RR reports." This sentence is not really > correct. The use of > > the RTCP XR reports is possible in any application sending RTCP. > > > > [g] himm,i am confused i thought that the first sentence > covers everything - what is left out? > > So [1] needs to be updated too? > > > > 7. Section 2, You talk about AVP, but this extension is not > dependent on > > any special profile and seems to be compatible with any of the four > > available or under development profiles that exist. > > > > [g] agreed. > > > > 8. Section 2, Figure 1. This figure shows this report > formats potential > > need to have reporting from all layers on the receiving > side. This might > > be a problem for certain application architectures. I am > not saying that > > it can't be used, its only that some applications may have > difficulties > > to include your reports. > > > > [g] we believe the statistics reported should be extensible > also should be allowed to be ignored. > > So if an end side cannot support it should put simply a > zero - what do you think? > > > > 9. Section 3.1, first paragraph: "All timestamps reported by the XR > > packet SHALL be RTP timestamps. All durations SHALL be in > units of the > > RTP timebase." This definition is not clear, because in > applications > > allowing for switching between payload types the rate can change. I > > think that the intention of using the RTP timestamp value > for indication > > over what interval which the report covers is a good one. > However some > > more consideration over formulation must be done. > > > > [g] valid point - I guess we need to think more about the > corner cases. > > > > 10. Section 3.3, PAge 5, first bullet after figure 2: > > "- at the AVP module: Packet drop and packet errors can sometimes be > > detected by incorrect or missing sequence number or > checksum. " Do you > > really need to consider bit-errors, the only allowed > possibility for > > bit-errors in RTP is if partial checksums are used. > Bit-errors surviving > > to the transport layer is the meaning to be caught by the > UDP, etc., > > checksum. > > > > [g] there could be cases where bit errors are propagated > (e.g. udp lite). > > > > 11. Section 6. The streaming metrics should probably have a > value to > > combine with the parameter to indicate how often the report > block should > > be included. This seem to be a block that is not needed very often. > > > > [g] valid point, note taken. > > > > 12. Section 8. The security section does not look > sufficient. I guess > > that the consideration for this is rather similar to the > VoIP block. > > However I think there should be made some effort to > indicate the main > > security concerns also in this document. > > > > [g] agreed. > > > > 13. Section 12. The references need to be divided into > Normative and > > Informative ones. > > > > [g] agreed. > > > > 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 > > > > -- > > 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 exim@www1.ietf.org Tue Nov 11 13:45:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14988 for ; Tue, 11 Nov 2003 13:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdVm-0001XC-8b for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 13:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIjAYw005897 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 13:45:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdVd-0001WY-6l; Tue, 11 Nov 2003 13:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdVS-0001WF-6D for avt@optimus.ietf.org; Tue, 11 Nov 2003 13:44:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14906 for ; Tue, 11 Nov 2003 13:44:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdVP-0007jb-00 for avt@ietf.org; Tue, 11 Nov 2003 13:44:47 -0500 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx with esmtp (Exim 4.12) id 1AJdVO-0007ir-00 for avt@ietf.org; Tue, 11 Nov 2003 13:44:47 -0500 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id hABIiGrY004439 for ; Tue, 11 Nov 2003 10:44:16 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 11 Nov 2003 10:43:42 -0800 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id hABIhjwx024103; Tue, 11 Nov 2003 10:43:45 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 11 Nov 2003 10:43:56 -0800 To: Jose Rey , jan.vandermeer@philips.com, "'IETF AVT WG'" From: Dave Singer Subject: Re: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Cc: Colin Perkins , Magnus Westerlund , Yoshinori Matsui Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 17:27 +0100 11/11/03, Jose Rey wrote: >Hi all, > >for those that did not attend the AVT session on Monday, there was a >number of comments and useful feedback during the timed text >presentation. > >In particular, it was suggested that the draft sticks too much to the >3gp file format itself and does not look at the particularities of the >RTP transport (Colin please correct me if the language is wrong). >Currently the draft just reads the text samples from the 3gp file and >puts them into RTP packets. If a packet is too big for one RTP packet >then it is cut and a fragment header is used to be able to interpret the >information in that fragment. As long as fragmentation happens rarely >then this could be the best option. > >On the other side, there's the option (which I call 'pure ALF approach' >in the slides) to preprocess the data read from the 3gp file before >packetising. This preprocessing would not only cut the text samples to >fix the RTP packet size but also re-arrange the packets so that the >fragments are not only self-contained but contain all the decorations. >This approach requires to define extra headers for the cases in which >the modifier boxes would have to be split into several RTP packets. > >You can download some clarifying slides at >http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format or >from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in MSPowerPoint >format. > >The current approach makes sense if the text samples are regularly small >and one or several of them fit into an RTP packet. Fragmentation would >happen seldom. The 'pure alf approach' is, in general, the most correct >one, and so also the one that requires more header definitions. If >fragmentation is a rare event, this overhead may be not worth (?). The >question to the group is pretty simple: which approach should be >pursued? I think we can find a middle ground. I think=20 that text samples over 512 bytes are quite rare,=20 and over 1400 bytes very rare indeed. I don't=20 mind going to a format which is less file-format=20 centric, but I don't think we should spend a lot=20 of time optimizing fragmented text access units. > > >We appreciate your feedback, > >cheers, > > >Jose > > > > > >> -----Urspr=FCngliche Nachricht----- >> Von: avt-admin@ietf.org [mailto:avt-admin@ietf.org]Im Auftrag von Jos=E9 >> Rey >> Gesendet: Montag, 10. November 2003 21:02 >> An: jan.vandermeer@philips.com; 'IETF AVT WG' >> Cc: Colin Perkins; Magnus Westerlund; 'Dave Singer'; Yoshinori Matsui >> Betreff: AW: [AVT] More comments on >> draft-rey-avt-rtp-3gpp-timed-text-01.txt >> >> >> >> Jan, all, >> >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: Jos=E9 Rey [mailto:rey@panasonic.de] >> > Gesendet: Montag, 10. November 2003 18:11 >> > An: Jose Rey >> > Betreff: >> > >> > >> > Dear Jose, all, >> > >> > I will not be in Minneapolis either but would like to provide >> > some input >> > on the issue of transport of 3GPP timed text. I know this >> > input is very >> > late; my appologies for that. >> > >> > As you know also MPEG is working on timed text; currently >> the Committe >> > Draft (CD) is ballotted, and MPEG schedules to enter the >> next phase in >> > about one month and to finish the work in July 2004. The >> > end-result will >> > be part 17 of MPEG-4, defining MPEG-4 text streams. Through >> liaisons, >> > MPEG tries to harmonize its work with the work that is >> already carried >> > out in 3GPP and also with ongoing work in W3C. Most >> important in this >> > respect is that MPEG focusses at maximum commonality with the >> > timed text >> > format defined by 3GPP for download. In summary, the current CD of >> > MPEG-4 part 17 specifies streaming of the 3GPP timed text format by >> > defining a very straightforward way to transcode the 3GPP >> format into >> > the MPEG-4 structure of a decoder configuration and text > > access units. >> > Please find the Committee Draft (a public document) attached to this >> > email. So far, 3GPP expressed through liaison statements to be very > > > pleased with the work done by MPEG. >> > >> > Once the work is finished, the timed text format can be >> streamed using >> > "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is >> scheduled to >> > be published as RFC very soon. In summary this approach >> would work as >> > follows: >> > - media type: "video", >> > - MIME subtype name: mpeg4-generic, >> > - streamType (required parameter in RFC#simple): indicates >> MPEG-4 text >> > stream as defined in ISO 14496-17, >> > - profile-level-id (required parameter in RFC#simple): specifies the >> > functional subset as defined in the current 3GPP timed text >> > specification, >> > - config (required parameter in RFC#simple): carries the decoder >> > configuration specified for text streams in ISO 14496-17, >> > - the RTP payload contains either (a) one fragment of a text >> > access unit >> > or (b) one or more complete text access units, >> > - the RTP payload carries one AU-header for each carried text access >> > unit, >> > - in the RTP payload the concatenated AU-headers preceed >> concatenated >> > data of text access units, as defined in RFC#simple, >> > - each AU-header contains (at least) the following >> information on the >> > associated text access unit: (a) the size of the text >> access unit, (b) >> > the time stamp of the text access unit, >> > - if deemed necessary, the AU-header may also carry the index >> > of a text >> > access unit (fragment) and/or an indication whether the >> > associated text >> > access unit is a random access point. >> > In RFC#simple the fields in the AU-header are configurable, but if >> > desired one or two new modes for RFC#simple could be defined >> > with fixed >> > length fields, for example one using an 8 bit AU-size field >> (for most >> > common applications) and another using 16 bits AU-size field for >> > applications using (very) large text access units. >> > >> > The above "RFC#simple approach" has a high level of commonality with >> > draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small >> > differences that can be fixed either way, but roughly the >> "RFC#simple >> > approach" is a simplified version of >> > draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the >> > "RFC#simple" approach does not have the advanced error resiliency >> > measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt. >> > >> > In my view not only in IETF, but also in 3GPP and in MPEG a >> number of >> > basic issues should be discussed, such as: >> > - are the error resiliency features of >> > draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to >> > justify their complexity (note that a partly corrupted >> > subtitle may not >> > have much more value to the user than a missing one); >> >> This is a good question which I will also ask during my >> presentation on >> Monday. This is a question which certainly needs feedback of >> the group. >> The complexity can be reduced, we have to agree where to cut >> down: do we >> need the MTSF headers? or do we want to just keep resiliency for plain >> text fragments?, for example. PT multiplexing will probably be >> abandoned for a simpler scheme. >> >> > - is it desirable to define a 3GPP timed text transport >> solution based >> > on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one >> > that will be >> > available based on RFC#simple; >> >> Allowing both would mean that one does not have to implement >> RFC#simple >> in order to transport timed text, which I think is desireable. >> >> > - is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt >> > specifies a mode or an extension of RFC#simple; >> >> Would this mean that the RFC#simple has to be implemented to use the >> draft? I think this is not a good idea. >> >> > - how can a timing conflict (if any) between release 6 of >> > 3GPP and part >> > 17 of MPEG-4 be resolved (note that such conflict will only exist if >> > 3GPP adopts streaming of timed text as a work item and if >> 3GPP decides >> > that this functionality has to be in release 6). > > > >> >> We are targetting to include this in Release 6 (03/04). According to >> your information above MPEG4 timed text will be ready in > > July'04, which >> is out of the deadline. Apart from that, current Release 6 >> does not use >> the RFC#simple for streaming... so one would not be able to use timed >> text in Release 6. >> >> Assuming timed text comes into the Release 6 agenda, what I would like >> to know is what should, in your opinion, the current draft include in >> order to consider the MPEG work and the possible extensions it may >> incorporate ?. It is now the time to talk about these issues if the >> draft shall consider the MPEG work. >> >> >> > I hope you will have a fruitful discussion on this subject in >> > Mineapolis. >> >> You can dowload the session slides and take a look at the >> presentation >> which is related to this email. >> >> cheers, >> >> Jose >> >> >But, this is not just an IETF issue. Therefore, >> > as both 3GPP >> > and MPEG are main "customers" of a timed text streaming solution, I >> > suggest that IETF requests 3GPP and MPEG to advice IETF as >> to the most >> > desirable direction for resolving this issue. Note that >> both 3GPP and >> > MPEG will have meetings where this issue can be discussed >> well before >> > the end of this year. >> > >> > Best regards, >> > >> > Jan van der Meer >> > >> > >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 11 16:05:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22081 for ; Tue, 11 Nov 2003 16:05:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfhL-0004rr-Jg for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 16:05:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABL5FtW018665 for avt-archive@odin.ietf.org; Tue, 11 Nov 2003 16:05:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfh8-0004qM-Sy; Tue, 11 Nov 2003 16:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfgt-0004ps-4g for avt@optimus.ietf.org; Tue, 11 Nov 2003 16:04:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21996 for ; Tue, 11 Nov 2003 16:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfgr-00029Q-00 for avt@ietf.org; Tue, 11 Nov 2003 16:04:45 -0500 Received: from ejchesterfield.plus.com ([212.159.56.89] helo=localhost.localdomain) by ietf-mx with esmtp (Exim 4.12) id 1AJfgq-00029C-00 for avt@ietf.org; Tue, 11 Nov 2003 16:04:44 -0500 Received: from thechesterfields.org (jdesk [127.0.0.1]) (authenticated bits=0) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hABKvDwW025072 for ; Tue, 11 Nov 2003 20:57:14 GMT Message-ID: <3FB14D29.9060001@thechesterfields.org> Date: Tue, 11 Nov 2003 20:57:13 +0000 From: Julian Chesterfield User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Summary of discussion items for draft-ietf-avt-rtcpssm Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joerg will be presenting an overview of updates and open issues for draft-ietf-avt-rtcpssm at the meeting tomorrow. Here's an outline of changes to the draft since last time: - draft-ietf-avt-rtcpssm current version -05 - Updated refs into normative vs informative. - Added clarifiying text for each summary type to explain what information is provided. - Clarified bandwidth allocation rules for source in reflection vs summarised modes. In summary mode, the sender will use the receiver's bandwidth for the feedback channel for summaries. - 64 bit timestamp used in RSI header. Open issue: Security considerations section needs slimming down, it is currently a little too detailed. We've tried to present info as a 'cookbook' style approach to security components complying to the requirements. We'll need to determine what level of information is required to explain the motivation for the security requirements, and whether we can cut down some of the detail e.g. attack vulnerabilities, types of attack etc.. So feedback form the group on this issue is particularly solicited. Otherwise, we hope to have any final updates/requests into the draft by december for a final call version. Many thanks, Julian Chesterfield _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 12 09:54:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19669 for ; Wed, 12 Nov 2003 09:54:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwNh-0005Dz-Ul for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 09:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACEs565020059 for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 09:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwNd-0005D7-7c; Wed, 12 Nov 2003 09:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwMg-0005As-0c for avt@optimus.ietf.org; Wed, 12 Nov 2003 09:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19595 for ; Wed, 12 Nov 2003 09:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwMe-0007f2-00 for avt@ietf.org; Wed, 12 Nov 2003 09:53:00 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AJwMd-0007eZ-00 for avt@ietf.org; Wed, 12 Nov 2003 09:52:59 -0500 Received: from [130.129.134.230] (port=52054 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AJwM7-00026N-00; Wed, 12 Nov 2003 14:52:27 +0000 Date: Wed, 12 Nov 2003 08:52:24 -0600 Subject: Re: [AVT] Slides for Monday AVT session Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Magnus Westerlund To: avt@ietf.org From: Colin Perkins In-Reply-To: <00B10F96-1399-11D8-AEB0-000A957FC5F2@csperkins.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The slides for Wednesday are now available at http://www.dcs.gla.ac.uk/~csp/ietf58-avt-wed.zip Colin On Monday, Nov 10, 2003, at 10:14 US/Central, Colin Perkins wrote: > Copies of the presentation materials which will be used in AVT this > afternoon can be retrieved as > http://www.dcs.gla.ac.uk/~csp/ietf58-avt-mon.zip > > These will migrate onto the IETF server after the meeting. > > Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 12 11:33:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25814 for ; Wed, 12 Nov 2003 11:33:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxvg-0005SA-FI for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 11:33:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGXGRE020959 for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 11:33:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxvS-0005Qf-Ad; Wed, 12 Nov 2003 11:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxuk-0005PZ-72 for avt@optimus.ietf.org; Wed, 12 Nov 2003 11:32:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25738 for ; Wed, 12 Nov 2003 11:32:05 -0500 (EST) From: igor.curcio@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxuj-0001hg-00 for avt@ietf.org; Wed, 12 Nov 2003 11:32:17 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJxui-0001hc-00 for avt@ietf.org; Wed, 12 Nov 2003 11:32:16 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACGWE623801 for ; Wed, 12 Nov 2003 18:32:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 18:32:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 18:32:14 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 18:32:13 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 18:32:13 +0200 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 Subject: RE: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt Date: Wed, 12 Nov 2003 18:32:12 +0200 Message-ID: <7F874D8CD4FDA54AAAE7C8B43D32B80702DA6293@trebe004.europe.nokia.com> Thread-Topic: [AVT] RE: Comments on draft-tseng-rtcp-streaming-extns-00.txt Thread-Index: AcOodw8xIEUxxG0ERmOk1AutAF8h7QAwOAwA To: , Cc: , X-OriginalArrivalTime: 12 Nov 2003 16:32:13.0544 (UTC) FILETIME=[870C6680:01C3A93A] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, some comments on the draft. 1. Overall the draft is interesting. 2. I support most of the comments already given by Magnus and Thomas. In = particular, I would like to stress the fact that the concept of = corruption is fuzzy. For example a data loss of 1 second does not = necessarily map to a subjective quality degradation of 1 second. It = might be shorter or longer, depending on how error concealment is done. = Especially for video, this is a complicated issue. And yet one aspect = where the complexity relies, is the difficulty of extracting the needed = information from the decoder, either because of lack of interfaces or = because it is computationally intensive to perform this task.=20 Regards, Igor =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 Igor D.D. Curcio Nokia Corporation Mobile Software, Architecture & Roadmapping Multimedia streaming and video telephony P.O. Box 88 33721 Tampere Finland =20 Tel. +358 800 8000 Email: igor.curcio@nokia.com WWW www.nokia.com > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of ext > Thomas Zeng > Sent: 11 November, 2003 19:10 > To: 'Magnus Westerlund'; Gamze Seckin > Cc: Alan Tseng; IETF AVT WG > Subject: RE: [AVT] RE: Comments on > draft-tseng-rtcp-streaming-extns-00.txt >=20 >=20 > Hi Alan and Gamze: >=20 > My comments on this draft: >=20 > General comment: would it be possible to provide the means=20 > for server to > signal to client the interval for Quality Metrics reporting?=20 > For instance an > optional parameter in RTSP Play response? >=20 > 1. Like Magnus, I don't feel "AVP Module" (defined in section=20 > 2) is a right > choice of name. I suggest "Transport Handler" might be a better fit in > naming the concept (to differentiate with source codec). >=20 > 2. Please in the introduction provide some insight of your=20 > motivations. If > one implements this draft, would one use it for debugging only, or for > billing also? We'd like to see a generic proposal that will,=20 > if possible, > satisfy the desire to do QOS based billing, as well as=20 > network monitoring / > user experience monitoring/survey. >=20 > 3. In section 3.3, it appeared that it is assuming that a RTP=20 > packet will > contain only one or partial VOP so that the AVP module could=20 > determine the > corruption period from the RTP timestamp. However, in the=20 > multi-VOP RTP > packet, then the corruption period need to contain multi-VOPs. Just a > suggestion to consider the multi-VOP case. >=20 > 4. Sometimes player freezes not due to "rebuffering"=20 > (underflow of player > buffer). For example, for live streaming, packets not get sent by the > server due to late arrival from author. If server drop packets > intentionally, then the player will not detect seq number gap=20 > in this case. > There could be other reason that player will freeze not due=20 > to rebuffering > (but then jump in play time later). Will this be included in the > rebuffering matrices? According to the definition, it should. So > "rebuffering' in this draft does not always refer to=20 > "underflow of player > buffer"? For instance, we've seen freezing due to overflow=20 > (caused by bad > server scheduling) and/or player processor overload. >=20 > 5.Typo on Page 10, "pts_stop" ... "beginning" should be "end" >=20 > 6. On 3.4 last sentence, for rebuffering, then there should=20 > not reach end of > playback since the player is not playing and the playtime is=20 > stalled. So we > are not sure if this sentence applies to rebuffering (at least the > rebuffering due to buffer underflow). It does have some=20 > implications if the > player did not receive any more data and abort due to timeout=20 > (i.e., staying > in rebuffering and timeout). So we think these two cases (normal > rebuffering, or rebuffering with timeout) needs to be considered. >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Wednesday, November 05, 2003 11:41 PM > > To: Gamze Seckin > > Cc: Alan Tseng; IETF AVT WG > > Subject: Re: [AVT] RE: Comments on=20 > > draft-tseng-rtcp-streaming-extns-00.txt > >=20 > >=20 > > Hi Gamze, > >=20 > > To my knowledge there is no profile dependencies in RFC=20 > 3611. Thus it=20 > > can be used for any of the four profiles defined or under=20 > > definition. My=20 > > comment was to point out this fact and that it seems=20 > inappropriate to=20 > > talk about any special profile in this context. > >=20 > > cheers > >=20 > > Magnus > >=20 > > Gamze Seckin wrote: > >=20 > > > Hi Magnus, > > >=20 > > > about your comment > > > "7. Section 2, You talk about AVP, but this extension is=20 > > not dependent on=20 > > > any special profile and seems to be compatible with any=20 > of the four=20 > > > available or under development profiles that exist." > > >=20 > > > Do you also mean AVPF? Since I am confused about the=20 > > relationship between AVPF and RFC3611. > > >=20 > > > thx > > > g > > > -----Original Message----- > > > From: Gamze Seckin=20 > > > Sent: Friday, October 31, 2003 11:08 AM > > > To: Magnus Westerlund; Alan Tseng > > > Cc: IETF AVT WG > > > Subject: [AVT] RE: Comments on=20 > > draft-tseng-rtcp-streaming-extns-00.txt > > >=20 > > >=20 > > >=20 > > > Hi Magnus,=20 > > > thanks for the comments. > > > See my response inline. > > >=20 > > > best regards > > > gamze > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Wednesday, October 29, 2003 8:17 AM > > > To: Alan Tseng; Gamze Seckin > > > Cc: IETF AVT WG > > > Subject: Comments on draft-tseng-rtcp-streaming-extns-00.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > Here is my comments on your draft: > > >=20 > > > 1. First I think the draft isn't very clear on why any=20 > metrics are=20 > > > needed. In the 3GPP document it only states: "The=20 > objective of the=20 > > > streaming service quality metrics is to offer to the=20 > > service providers=20 > > > means to evaluate the end user experience.". This doesn't=20 > > make it very=20 > > > clear what the real needs are. I think further developing=20 > > of this is=20 > > > needed. > > >=20 > > > [g]you are right, the draft does not talk about that=20 > > clearly. We should add that. > > >=20 > > > 2. Regarding the corruption statistics. For media that uses=20 > > codec that=20 > > > have prediction any error normally remains for a rather=20 > long time.=20 > > > However it is very difficult to determine when the=20 > effects has been=20 > > > removed. Therefore this measurement is hard to derive on=20 > > the receiver=20 > > > side. Combined with the definition it only provides a good,=20 > > possibly bad=20 > > > indication. Also looking at the reasons for corruption, the=20 > > only real=20 > > > reason is lost or late packets. A good feeling for the=20 > > quality can be=20 > > > determined by the server simply by employing packet loss vector=20 > > > reporting and knowing when the buffer is empty. > > >=20 > > > [g]packet loss is definitely a way of estimating=20 > > corruption, but this gives an algorithm in the decoder (or=20 > > pre-decoder)a chance to provide better statistics. > > >=20 > > > 3. The rebuffering measurements makes more sense. However=20 > > there are at=20 > > > least one client that does not really perform rebuffering, namely=20 > > > quicktime. Instead is assumes that if the transmitted bit-rate is=20 > > > acceptable any short term effects will go away and the=20 > > client will later=20 > > > have a buffer fullness given by the initial buffering=20 > delay. The=20 > > > interesting thing about this measurement is that in 3GPP=20 > > they already=20 > > > have a way of letting the server measure when rebuffering=20 > > takes place,=20 > > > namely the OBSN reporting specified in TS 26.234 REL 6=20 > > (only preliminary=20 > > > versions available). > > >=20 > > > [g] yes, and I believe those statistics are useful, however=20 > > they are tight with rate adaptation (only turned on when=20 > > rate-adaptation is enabled) and tightly coupled with other=20 > > rtsp messages. > > >=20 > > > 4. As state privately before this drafts need to be checked=20 > > against the=20 > > > ID nits: http://www.ietf.org/ID-nits.html > > >=20 > > > [g] yes, we should definitely do that thanks. > > >=20 > > > 5. Section 1. The introduction is basically the same as the=20 > > > introduction. I would recommend you to write a better more=20 > > informative=20 > > > introduction. > > >=20 > > > [g] agreed. > > >=20 > > > 6. Section 1. Last sentence: "As all the other report blocks > > > defined in [1], the streaming report blocks are applicable to > > > one-to-one or one-to-many applications that generate > > > RTCP SR or RR reports." This sentence is not really=20 > > correct. The use of=20 > > > the RTCP XR reports is possible in any application sending RTCP. > > >=20 > > > [g] himm,i am confused i thought that the first sentence=20 > > covers everything - what is left out?=20 > > > So [1] needs to be updated too? > > >=20 > > > 7. Section 2, You talk about AVP, but this extension is not=20 > > dependent on=20 > > > any special profile and seems to be compatible with any=20 > of the four=20 > > > available or under development profiles that exist. > > >=20 > > > [g] agreed. > > >=20 > > > 8. Section 2, Figure 1. This figure shows this report=20 > > formats potential=20 > > > need to have reporting from all layers on the receiving=20 > > side. This might=20 > > > be a problem for certain application architectures. I am=20 > > not saying that=20 > > > it can't be used, its only that some applications may have=20 > > difficulties=20 > > > to include your reports. > > >=20 > > > [g] we believe the statistics reported should be extensible=20 > > also should be allowed to be ignored.=20 > > > So if an end side cannot support it should put simply a=20 > > zero - what do you think? > > >=20 > > > 9. Section 3.1, first paragraph: "All timestamps reported=20 > by the XR=20 > > > packet SHALL be RTP timestamps. All durations SHALL be in=20 > > units of the=20 > > > RTP timebase." This definition is not clear, because in=20 > > applications=20 > > > allowing for switching between payload types the rate can=20 > change. I=20 > > > think that the intention of using the RTP timestamp value=20 > > for indication=20 > > > over what interval which the report covers is a good one.=20 > > However some=20 > > > more consideration over formulation must be done. > > >=20 > > > [g] valid point - I guess we need to think more about the=20 > > corner cases. > > >=20 > > > 10. Section 3.3, PAge 5, first bullet after figure 2: > > > "- at the AVP module: Packet drop and packet errors can=20 > sometimes be > > > detected by incorrect or missing sequence number or=20 > > checksum. " Do you=20 > > > really need to consider bit-errors, the only allowed=20 > > possibility for=20 > > > bit-errors in RTP is if partial checksums are used.=20 > > Bit-errors surviving=20 > > > to the transport layer is the meaning to be caught by the=20 > > UDP, etc.,=20 > > > checksum. > > >=20 > > > [g] there could be cases where bit errors are propagated=20 > > (e.g. udp lite). > > >=20 > > > 11. Section 6. The streaming metrics should probably have a=20 > > value to=20 > > > combine with the parameter to indicate how often the report=20 > > block should=20 > > > be included. This seem to be a block that is not needed=20 > very often. > > >=20 > > > [g] valid point, note taken. > > >=20 > > > 12. Section 8. The security section does not look=20 > > sufficient. I guess=20 > > > that the consideration for this is rather similar to the=20 > > VoIP block.=20 > > > However I think there should be made some effort to=20 > > indicate the main=20 > > > security concerns also in this document. > > >=20 > > > [g] agreed. > > >=20 > > > 13. Section 12. The references need to be divided into=20 > > Normative and=20 > > > Informative ones. > > >=20 > > > [g] agreed. > > >=20 > > > Cheers > > >=20 > > > Magnus Westerlund > > >=20 > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > >=20 > >=20 > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto:=20 > magnus.westerlund@ericsson.com > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > >=20 > >=20 > > --=20 > >=20 > > Magnus Westerlund > >=20 > > Multimedia Technologies, Ericsson Research EAB/TVA/A > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >=20 > >=20 > > _______________________________________________ > > 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 exim@www1.ietf.org Wed Nov 12 14:40:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03659 for ; Wed, 12 Nov 2003 14:40:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0qe-0001oK-10 for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 14:40:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACJeFQi006956 for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 14:40:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0qS-0001ls-SI; Wed, 12 Nov 2003 14:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0qB-0001kZ-LJ for avt@optimus.ietf.org; Wed, 12 Nov 2003 14:39:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03600 for ; Wed, 12 Nov 2003 14:39:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0q8-0004RY-00 for avt@ietf.org; Wed, 12 Nov 2003 14:39:44 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AK0q8-0004RV-00 for avt@ietf.org; Wed, 12 Nov 2003 14:39:44 -0500 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 hACJbJJK001403 for ; Wed, 12 Nov 2003 14:37:19 -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 hACJbEJK001264 for ; Wed, 12 Nov 2003 14:37:15 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A954.B3AC496C" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 12 Nov 2003 21:39:35 +0200 Message-ID: Thread-Topic: RTP MIB Extensions Thread-Index: AcOpVLK6KcUgZCTJRkeD87yZeVI5uQ== From: "Romascanu, Dan (Dan)" To: Cc: , "Bert Wijnen (E-mail)" Subject: [AVT] RTP MIB Extensions Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A954.B3AC496C Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please allow me to make more clear my points expressed in the final = minutes of the AVT WG meeting today related to = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-clark-avt-rtpmibv= 2-00.txt 1. This MIB includes extensions to the RTP MIB (RFC 2959) related to = RTCP-XR (RFC 3611). At the same time, there seems to be a need to update = RFC 2959 as result of the evolution of the Real Time Protocol from RFC = 1889 to RFC 3550. I strongly suggest to do this in two separate MIBs = separate documents: - a new RTP MIB, updating to RFC 2959 - a supplementary RTCP-XR MIB, with the MIB objects relevant for hosts = or monitors running RTCP-XR.=20 This more modular and scalable structure would allow the two different = MIBs to be progressed separately, without creating a tight dependency = among them, and would allow adding other modules in the future. 2. There is a need for a better coordination, and possibly some = consolidation between the RTCP-XR MIB and work being done in other WGs = in the IETF - especially the RMON MIB WG = (http://www.ietf.cnri.reston.va.us/html.charters/rmonmib-charter.html) = work on Application Performance Monitoring and Real-Time Application = Monitoring to create a consistent framework for performance monitoring, = and avoid duplication. While RTCP-XR covers an important aspect of media = monitoring when RTP is used, it does not cover the whole application = space where RTP streams can be used. I would be glad to provide more = information, or work with the authors of the different proposals in AVT = to try to reach this goal.=20 Regards, Dan =20 ------_=_NextPart_001_01C3A954.B3AC496C Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RTP MIB Extensions

Please allow me to make more = clear my points expressed in the final minutes of the AVT WG meeting = today related to http://www.ietf.cnri.reston.va.us/internet-drafts/draft= -clark-avt-rtpmibv2-00.txt

1. This MIB includes = extensions to the RTP MIB (RFC 2959) related to RTCP-XR (RFC 3611). At = the same time, there seems to be a need to update RFC 2959 as result of = the evolution of the Real Time Protocol from RFC 1889 to RFC 3550. I = strongly suggest to do this in two separate MIBs separate = documents:

- a new RTP MIB, updating to = RFC 2959

- a supplementary RTCP-XR = MIB, with the MIB objects relevant for hosts or monitors running = RTCP-XR.

This more modular and = scalable structure would allow the two different MIBs to be progressed = separately, without creating a tight dependency among them, and would = allow adding other modules in the future.

2. There is a need for a = better coordination, and possibly some consolidation between the RTCP-XR = MIB and work being done in other WGs in the IETF - especially the RMON = MIB WG (http://www.ietf.cnri.reston.va.us/html.charters/rmonmib-charter.html= ) work on Application Performance Monitoring and Real-Time = Application Monitoring to create a consistent framework for performance = monitoring, and avoid duplication. While RTCP-XR covers an important = aspect of media monitoring when RTP is used, it does not cover the whole = application space where RTP streams can be used. I would be glad to = provide more information, or work with the authors of the different = proposals in AVT to try to reach this goal.

Regards,

Dan

 

------_=_NextPart_001_01C3A954.B3AC496C-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 12 14:46:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03897 for ; Wed, 12 Nov 2003 14:46:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0wJ-0002RF-Gg for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 14:46:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACJk70Z009352 for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 14:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0wG-0002QB-Hm; Wed, 12 Nov 2003 14:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0vw-0002IL-LS for avt@optimus.ietf.org; Wed, 12 Nov 2003 14:45:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03867 for ; Wed, 12 Nov 2003 14:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0vt-0004WD-00 for avt@ietf.org; Wed, 12 Nov 2003 14:45:41 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AK0vs-0004W7-00 for avt@ietf.org; Wed, 12 Nov 2003 14:45:41 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hACJjcSs018743 for ; Wed, 12 Nov 2003 20:45:39 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 20:45:38 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: avt@ietf.org Date: Wed, 12 Nov 2003 20:45:12 +0100 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 Content-Transfer-Encoding: quoted-printable Subject: [AVT] HC over multihop / MPLS Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable As I promised in the WG session, I'll try to share my thoughts on the HC over multihop/MPLS issue. The AVT charter states the following as a WG task:=20 "to review the applicability of Compressed RTP operation on MPLS networks, developing extensions as necessary" With the following milestones: Nov 03 Initial draft requirements for ECRTP over MPLS; discuss with = MPLS WG Nov 03 Initial draft requirements for ECRTP over MPLS; discuss with = MPLS WG However, the current draft refers to "VoIP Header Compression over = Multi-Hop Paths", which is not the same thing. The draft clearly shows that = compression over multihop paths is one thing, and compression over MPLS another. = Further, the draft takes a wider scope, and talks about header compression = generally, not only ECRTP as the charter says. The following observations can be made: * If work is to done for header compression over multihop and/or MPLS, = it might make sense to not only address ECRTP. * The only work in this that naturally could belong in the AVT WG would = be to make sure ECRTP would work in these scenarios. In my = understanding, this should already be the case with ECRTP (as well as some ROHC = profiles), which is also indicated by the multihop req draft. * Header compression over multihop paths [ described by the multihop = req draft as where one wants to avoid decompression/compression steps at intermediate routers if the same compression scheme is supported at = both incoming and outgoing interfaces ] is fully possible also without any = new standards, as it would only be an implementation issue for each = intermediate router to bind an incoming compressed stream to its corresponding = outgoing compressed stream. In a path A->B->C, where B is the intermediate = router negotiating use of e.g. CRTP with both A and C, it is fully up to the implementation of B to avoid unnecessary decompression/compression = and just forward compressed packets as-is ("CID routing"). * The only significant standardization work I can see is to define how = to do header compression (e.g. IPHC, CRTP/ECRTP, ROHC) over MPLS, which = is probably a work that would require some coordination with AVT and = ROHC individuals, but the core of that work does not naturally belong to ROHC or AVT. Would not the MPLS WG be a more proper place? Just a few thoughts, let's get discussions going! /L-E=20 ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated.=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 12 15:51:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08755 for ; Wed, 12 Nov 2003 15:51:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1ww-0003Ky-Kl for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 15:50:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKoo5o012773 for avt-archive@odin.ietf.org; Wed, 12 Nov 2003 15:50:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1vY-00039o-In; Wed, 12 Nov 2003 15:49:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxyN-0005l8-RV for avt@optimus.ietf.org; Wed, 12 Nov 2003 11:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25958; Wed, 12 Nov 2003 11:35:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxyM-0001lw-00; Wed, 12 Nov 2003 11:36:02 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AJxyL-0001lE-00; Wed, 12 Nov 2003 11:36:01 -0500 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 hACGZUlf006061; Wed, 12 Nov 2003 11:35:30 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 12 Nov 2003 11:35:25 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 11:35:25 -0500 Message-ID: From: "Phelan, Tom" To: "'avt@ietf.org'" Cc: "'dccp@ietf.org'" Date: Wed, 12 Nov 2003 11:35:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [AVT] DCCP for media applications Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, Judging from the discussion that just finished, it seems that the AVT group has a reasonable interest in the issues involved in using DCCP for media applications. I encourage the people here to look at http://www.phelan-4.com/dccp/draft-phelan-dccp-media-00.txt, and to comment on the issues it describes. This draft is likely to be the basis for a forthcoming DCCP User Guide, and application expertise is needed to be sure that we've covered the issues. Thanks, Tom Phelan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 11:46:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07023 for ; Thu, 13 Nov 2003 11:46:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKbs-0002hO-6c for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 11:46:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGkKVl010368 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 11:46:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKbZ-0002gI-1I; Thu, 13 Nov 2003 11:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKam-0002Te-13 for avt@optimus.ietf.org; Thu, 13 Nov 2003 11:45:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06966 for ; Thu, 13 Nov 2003 11:44:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKak-0000Xl-00 for avt@ietf.org; Thu, 13 Nov 2003 11:45:10 -0500 Received: from via-smtp1.imconline.net ([66.155.127.67]) by ietf-mx with esmtp (Exim 4.12) id 1AKKak-0000Vr-00 for avt@ietf.org; Thu, 13 Nov 2003 11:45:10 -0500 Received: from telchemy.com ([66.155.69.251]) by via-smtp1.imconline.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 11:43:01 -0500 Received: from alansnotebook [130.129.132.93] by telchemy.com with ESMTP (SMTPD32-8.03) id A4936890144; Thu, 13 Nov 2003 11:42:59 -0500 From: "Alan Clark" To: "Romascanu, Dan \(Dan\)" , Cc: , "Bert Wijnen \(E-mail\)" Subject: RE: [AVT] RTP MIB Extensions Date: Thu, 13 Nov 2003 11:43:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C3A9DB.55B40920" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 13 Nov 2003 16:43:01.0703 (UTC) FILETIME=[33CB5D70:01C3AA05] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C3A9DB.55B40920 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit RTP MIB ExtensionsDan I have no issue with the idea of progressing updates to the RTP MIB and keeping the RTCP XR MIB separate - I'll update the draft accordingly. There is also no disagreement that the RTCP XR VoIP metrics only address VoIP whereas the envisaged scope of RAQMON is broader. Regards Alan Clark Telchemy -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, November 12, 2003 2:40 PM To: avt@ietf.org Cc: mankin@psg.com; Bert Wijnen (E-mail) Subject: [AVT] RTP MIB Extensions Please allow me to make more clear my points expressed in the final minutes of the AVT WG meeting today related to http://www.ietf.cnri.reston.va.us/internet-drafts/draft-clark-avt-rtpmibv2-0 0.txt 1. This MIB includes extensions to the RTP MIB (RFC 2959) related to RTCP-XR (RFC 3611). At the same time, there seems to be a need to update RFC 2959 as result of the evolution of the Real Time Protocol from RFC 1889 to RFC 3550. I strongly suggest to do this in two separate MIBs separate documents: - a new RTP MIB, updating to RFC 2959 - a supplementary RTCP-XR MIB, with the MIB objects relevant for hosts or monitors running RTCP-XR. This more modular and scalable structure would allow the two different MIBs to be progressed separately, without creating a tight dependency among them, and would allow adding other modules in the future. 2. There is a need for a better coordination, and possibly some consolidation between the RTCP-XR MIB and work being done in other WGs in the IETF - especially the RMON MIB WG (http://www.ietf.cnri.reston.va.us/html.charters/rmonmib-charter.html) work on Application Performance Monitoring and Real-Time Application Monitoring to create a consistent framework for performance monitoring, and avoid duplication. While RTCP-XR covers an important aspect of media monitoring when RTP is used, it does not cover the whole application space where RTP streams can be used. I would be glad to provide more information, or work with the authors of the different proposals in AVT to try to reach this goal. Regards, Dan ------=_NextPart_000_000B_01C3A9DB.55B40920 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RTP MIB Extensions
Dan
 
I have=20 no issue with the idea of progressing updates to the RTP MIB and keeping = the=20 RTCP XR MIB separate - I'll update the draft accordingly.  There is = also no=20 disagreement that the RTCP XR VoIP metrics only address VoIP whereas the = envisaged scope of RAQMON is broader. 
 
Regards
 
Alan=20 Clark
Telchemy
 
 
-----Original Message-----
From: avt-admin@ietf.org = [mailto:avt-admin@ietf.org]On Behalf Of Romascanu, Dan=20 (Dan)
Sent: Wednesday, November 12, 2003 2:40 = PM
To:=20 avt@ietf.org
Cc: mankin@psg.com; Bert Wijnen=20 (E-mail)
Subject: [AVT] RTP MIB = Extensions

Please allow me to make more = clear my=20 points expressed in the final minutes of the AVT WG meeting today = related to=20 http://www.ietf.cnri.reston.va.us/internet-drafts/draft= -clark-avt-rtpmibv2-00.txt

1. This MIB includes = extensions to the RTP=20 MIB (RFC 2959) related to RTCP-XR (RFC 3611). At the same time, there = seems to=20 be a need to update RFC 2959 as result of the evolution of the Real = Time=20 Protocol from RFC 1889 to RFC 3550. I strongly suggest to do this in = two=20 separate MIBs separate documents:

- a new RTP MIB, updating to = RFC=20 2959

- a supplementary RTCP-XR = MIB, with the MIB=20 objects relevant for hosts or monitors running RTCP-XR.

This more modular and = scalable structure=20 would allow the two different MIBs to be progressed separately, = without=20 creating a tight dependency among them, and would allow adding other = modules=20 in the future.

2. There is a need for a = better=20 coordination, and possibly some consolidation between the RTCP-XR MIB = and work=20 being done in other WGs in the IETF - especially the RMON MIB WG (http://www.ietf.cnri.reston.va.us/html.charters/rmonmib-charter.html= )=20 work on Application Performance Monitoring and Real-Time Application=20 Monitoring to create a consistent framework for performance = monitoring, and=20 avoid duplication. While RTCP-XR covers an important aspect of media=20 monitoring when RTP is used, it does not cover the whole application = space=20 where RTP streams can be used. I would be glad to provide more = information, or=20 work with the authors of the different proposals in AVT to try to = reach this=20 goal.

Regards,

Dan

 

------=_NextPart_000_000B_01C3A9DB.55B40920-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 20:14:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02859 for ; Thu, 13 Nov 2003 20:14:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSXN-0007cL-09 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 20:14:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1ECHH029235 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 20:14:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSXC-0007ai-Fc; Thu, 13 Nov 2003 20:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSWs-0007Ua-HL for avt@optimus.ietf.org; Thu, 13 Nov 2003 20:13:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02827 for ; Thu, 13 Nov 2003 20:13:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSWq-0001ku-00 for avt@ietf.org; Thu, 13 Nov 2003 20:13:40 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AKSWp-0001kY-00 for avt@ietf.org; Thu, 13 Nov 2003 20:13:39 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAE1D8m01992 for ; Thu, 13 Nov 2003 20:13:09 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3H88LAP; Thu, 13 Nov 2003 20:13:09 -0500 Received: from nortelnetworks.com (acart07x.ca.nortel.com [47.130.16.252]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NND3; Thu, 13 Nov 2003 20:13:09 -0500 Message-ID: <3FB42C22.20605@nortelnetworks.com> Date: Thu, 13 Nov 2003 19:13:06 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] V.8bis messages in RFC 2833bis Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit While rewriting RFC 2833bis I found that the use of V.21 events with V.8bis signalling was underspecified. V.21 simply transmits bits at 300 bits/s using pure tones of specified frequencies to represent "0"s and "1"s. (V.21 has two channels, but that is irrelevant here.) A V.8bis message is a sequence of octets, where the carried information is preceded by HDLC flags and succeeded by a checksum and more HDLC flags. To prevent false identification of HDLC flags within the carried information, extra zeros are inserted after sequences of five "1"s and stripped out again at the receiving end. It doesn't seem necessary to carry the HDLC flags, and probably not the checksum (assuming redundancy encoding provides a sufficient degree of reliability). The HDLC flags represent a minimum of 24 bits and a maximum of 64, each one of which is a separate event. The checksum adds another 16 bits. Zero stuffing adds some more. Are there any existing implementations, and do they transmit the flags and checksum or not? On a related topic, how many V.21 bits should be reported per packet, given that they are propagated at 33 ms intervals? Any recommendation? Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 20:45:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04031 for ; Thu, 13 Nov 2003 20:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKT1F-00020h-21 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 20:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1j5LQ007711 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 20:45:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKT1D-0001zg-0v; Thu, 13 Nov 2003 20:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKT13-0001zE-Gr for avt@optimus.ietf.org; Thu, 13 Nov 2003 20:44:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04011 for ; Thu, 13 Nov 2003 20:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKT11-0002Dw-00 for avt@ietf.org; Thu, 13 Nov 2003 20:44:51 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AKT10-0002Dj-00 for avt@ietf.org; Thu, 13 Nov 2003 20:44:50 -0500 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAE1iJm02911 for ; Thu, 13 Nov 2003 20:44:20 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WTC1JDGZ; Thu, 13 Nov 2003 20:44:20 -0500 Received: from nortelnetworks.com (acart07x.ca.nortel.com [47.130.16.252]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NNDZ; Thu, 13 Nov 2003 20:44:20 -0500 Message-ID: <3FB43373.2050701@nortelnetworks.com> Date: Thu, 13 Nov 2003 19:44:19 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] More on V.21 events Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thinking about V.21 a bit more, I realized that it isn't clear when an event should be rteported. The choices are to report an event every time a bit is sent (i.e., 300 events per second), or else every time a transition occurs (which means something less than 150 events per second). Of course, the event rate itself doesn't mean too much without also specifying the rate at which event updates are issued. But if updates are issued every 66.7 ms or more, the number of event reports would be halved on the average. So: should we specify one approach or the other, or allow either and require implementations to be able to handle events spanning multiple bits? Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 21:12:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05198 for ; Thu, 13 Nov 2003 21:12:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTRM-0004Cw-Cl for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 21:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2C4uw016137 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 21:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTRJ-0004Bh-4N; Thu, 13 Nov 2003 21:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTQp-0004BI-9E for avt@optimus.ietf.org; Thu, 13 Nov 2003 21:11:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05050 for ; Thu, 13 Nov 2003 21:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTQm-0002hE-00 for avt@ietf.org; Thu, 13 Nov 2003 21:11:28 -0500 Received: from p11.n-slpop01.stsn.com ([12.168.96.11] helo=slpop.smtp.stsn.com) by ietf-mx with esmtp (Exim 4.12) id 1AKTQl-0002g9-00 for avt@ietf.org; Thu, 13 Nov 2003 21:11:28 -0500 Received: from vit ([10.11.23.33]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 19:06:26 -0700 From: "Gunnar Hellstrom" To: "Tom Taylor" , Subject: SV: [AVT] More on V.21 events Date: Thu, 13 Nov 2003 20:11:00 -0600 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FB43373.2050701@nortelnetworks.com> Importance: Normal X-OriginalArrivalTime: 14 Nov 2003 02:06:26.0906 (UTC) FILETIME=[E943FBA0:01C3AA53] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Have you decided how you will report V.21 110 bits/second. It is used in large parts of Europe and South America for text telephony. ( sorry, I should have read what applications are in scope before putting this question, maybe it is totally out of scope that a textphone call needs to be decoded and transmitted this way. ) Regards Gunnar Hellstrom ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Ursprungligt meddelande----- Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor Skickat: den 13 november 2003 19:44 Till: avt@ietf.org Amne: [AVT] More on V.21 events Thinking about V.21 a bit more, I realized that it isn't clear when an event should be rteported. The choices are to report an event every time a bit is sent (i.e., 300 events per second), or else every time a transition occurs (which means something less than 150 events per second). Of course, the event rate itself doesn't mean too much without also specifying the rate at which event updates are issued. But if updates are issued every 66.7 ms or more, the number of event reports would be halved on the average. So: should we specify one approach or the other, or allow either and require implementations to be able to handle events spanning multiple bits? Tom Taylor _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 21:30:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06518 for ; Thu, 13 Nov 2003 21:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTiq-0005xx-Je for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 21:30:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2U8Qv022927 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 21:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTik-0005wb-L3; Thu, 13 Nov 2003 21:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKThs-0005uP-TO for avt@optimus.ietf.org; Thu, 13 Nov 2003 21:29:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06451 for ; Thu, 13 Nov 2003 21:28:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKThp-0003Bj-00 for avt@ietf.org; Thu, 13 Nov 2003 21:29:05 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AKTho-0003BL-00 for avt@ietf.org; Thu, 13 Nov 2003 21:29:04 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAE2SMm05110; Thu, 13 Nov 2003 21:28:22 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3H88LK6; Thu, 13 Nov 2003 21:28:23 -0500 Received: from nortelnetworks.com (acart15f.ca.nortel.com [47.130.24.129]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NND0; Thu, 13 Nov 2003 21:28:21 -0500 Message-ID: <3FB43DC5.8080102@nortelnetworks.com> Date: Thu, 13 Nov 2003 20:28:21 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom CC: avt@ietf.org Subject: Re: SV: [AVT] More on V.21 events References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'll adjust the wording to allow for rates lower than 300 bits/s. My original question still stands, but is perhaps less pressing at lower rates. Actually, I'm in favour of requiring an event to be reported for each bit sent. This increases redundancy in a natural manner, since event completions are transmitted redundantly. Gunnar Hellstrom wrote: > Have you decided how you will report V.21 110 bits/second. It is used in > large parts of Europe and South America for text telephony. > > ( sorry, I should have read what applications are in scope before putting > this question, maybe it is totally out of scope that a textphone call needs > to be decoded and transmitted this way. ) > > Regards > Gunnar Hellstrom > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor > Skickat: den 13 november 2003 19:44 > Till: avt@ietf.org > Amne: [AVT] More on V.21 events > > > Thinking about V.21 a bit more, I realized that it isn't clear when an > event should be rteported. The choices are to report an event every > time a bit is sent (i.e., 300 events per second), or else every time a > transition occurs (which means something less than 150 events per > second). Of course, the event rate itself doesn't mean too much without > also specifying the rate at which event updates are issued. But if > updates are issued every 66.7 ms or more, the number of event reports > would be halved on the average. > > So: should we specify one approach or the other, or allow either and > require implementations to be able to handle events spanning multiple bits? > > Tom Taylor > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Nov 13 22:29:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08932 for ; Thu, 13 Nov 2003 22:29:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUdt-0001DF-EM for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 22:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3T5LX004655 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 22:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUdo-0001CX-W2; Thu, 13 Nov 2003 22:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUcz-0001Be-Tt for avt@optimus.ietf.org; Thu, 13 Nov 2003 22:28:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08916 for ; Thu, 13 Nov 2003 22:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUcw-0004Hc-00 for avt@ietf.org; Thu, 13 Nov 2003 22:28:06 -0500 Received: from p11.n-slpop01.stsn.com ([12.168.96.11] helo=slpop.smtp.stsn.com) by ietf-mx with esmtp (Exim 4.12) id 1AKUcv-0004HE-00 for avt@ietf.org; Thu, 13 Nov 2003 22:28:06 -0500 Received: from vit ([10.11.23.33]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 20:23:03 -0700 From: "Gunnar Hellstrom" To: "Tom Taylor" Cc: Subject: SV: SV: [AVT] More on V.21 events Date: Thu, 13 Nov 2003 21:27:36 -0600 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FB43DC5.8080102@nortelnetworks.com> Importance: Normal X-OriginalArrivalTime: 14 Nov 2003 03:23:03.0265 (UTC) FILETIME=[9CE8B510:01C3AA5E] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit OK, fine. You will have some nasty detection cases. Hope that detection precision is good enough for that. E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( if I get bit-order right ) The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms of 1180 Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character. The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of 1180 Hz, 81,9 ms of 980 Hz continued in 980 Hz. So, the difference is that the start bit is 9.1 ms in one case, and the start bit plus two data bits are 10 ms in the other case. Is this enough to decide on 110 or 300 bps and time the detector to generate bit events during the row of bits in steady 980 Hz? Is there a need for also a detector specification? Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Ursprungligt meddelande----- Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor Skickat: den 13 november 2003 20:28 Till: Gunnar Hellstrom Kopia: avt@ietf.org Amne: Re: SV: [AVT] More on V.21 events I'll adjust the wording to allow for rates lower than 300 bits/s. My original question still stands, but is perhaps less pressing at lower rates. Actually, I'm in favour of requiring an event to be reported for each bit sent. This increases redundancy in a natural manner, since event completions are transmitted redundantly. Gunnar Hellstrom wrote: > Have you decided how you will report V.21 110 bits/second. It is used in > large parts of Europe and South America for text telephony. > > ( sorry, I should have read what applications are in scope before putting > this question, maybe it is totally out of scope that a textphone call needs > to be decoded and transmitted this way. ) > > Regards > Gunnar Hellstrom > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor > Skickat: den 13 november 2003 19:44 > Till: avt@ietf.org > Amne: [AVT] More on V.21 events > > > Thinking about V.21 a bit more, I realized that it isn't clear when an > event should be rteported. The choices are to report an event every > time a bit is sent (i.e., 300 events per second), or else every time a > transition occurs (which means something less than 150 events per > second). Of course, the event rate itself doesn't mean too much without > also specifying the rate at which event updates are issued. But if > updates are issued every 66.7 ms or more, the number of event reports > would be halved on the average. > > So: should we specify one approach or the other, or allow either and > require implementations to be able to handle events spanning multiple bits? > > Tom Taylor > > > _______________________________________________ > 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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 22:45:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09740 for ; Thu, 13 Nov 2003 22:45:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtT-0002hH-Ek for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3jBif010356 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 22:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtL-0002cD-Ou; Thu, 13 Nov 2003 22:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUtE-0002bE-PX for avt@optimus.ietf.org; Thu, 13 Nov 2003 22:44:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09675 for ; Thu, 13 Nov 2003 22:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUtB-0004bU-00 for avt@ietf.org; Thu, 13 Nov 2003 22:44:53 -0500 Received: from p11.n-slpop01.stsn.com ([12.168.96.11] helo=slpop.smtp.stsn.com) by ietf-mx with esmtp (Exim 4.12) id 1AKUtA-0004bC-00 for avt@ietf.org; Thu, 13 Nov 2003 22:44:52 -0500 Received: from vit ([10.11.23.33]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 20:39:53 -0700 From: "Gunnar Hellstrom" To: "avt IETF" , , "Frank Shearar" Subject: [avt] SV: RFC2793bis and byte orders and other details Date: Thu, 13 Nov 2003 21:44:27 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000001c3a90d$1a96b820$2b01a8c0@wsfrank> Importance: Normal X-OriginalArrivalTime: 14 Nov 2003 03:39:53.0187 (UTC) FILETIME=[F6DE9330:01C3AA60] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA09676 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable In the avt meeting, the RFC2793bis RTP Payload for Text Conversation was accepted as an avt workgroup item. I promised to produce draft-avt-rfc2793bis-00 out of draft-hellstrom-avt-rfc2793bis-02 The current version is found at: http://www.ietf.org/internet-drafts/draft-hellstrom-avt-rfc2793bis-02.txt When I do that, I want to include actions on the comments so far. Therefore, I want to check the reaction on some suggestions. 1. Specify byte-order for the new T140block counter. ( motivation below f= rom Frank Shearar ) I doubt that it is advicable to specify byte order for one little piec= e of the packet. I assume that byte order issues are enough covered centrally in RTP. I would like to get comments on that assumption. 2. Open for other redundancy schemes than RFC2198, at least for the audio/t140 format Especially for the audio intermixed packetization audio/t140, there mi= ght be of interest to use any of the FEC mechanisms to gain reliability. It may for example be desirable to use the same FEC mechanism for the audio stream as for the interleaved text. The requirement to use the s= ame clock frequency for text and audio in the audio/t140 medium may also make= it hard to use RFC2198, because the maximum offset will not be long enough t= o cater for transmission only every 300 ms, when the clock frequency of the audio packetisation is used. ( for text/t140 it is 1000 Hz, and that is a suitable frequency to allow for redundancy. ) I recommend that I insert wording that for audio/t140 , any suitable FEC packetisation can be used. 3. IANA considerations The following IANA registrations shall be included in the draft: register media types for MIME and SDP usage: text/t140 - already done text/red audio/t140 register the main media type for sdp usage text register the attribute parameter cps=3D Register the capability for capability registration. text Anything more? Gunnar Hellstr=F6m ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Ursprungligt meddelande----- Fr=E5n: owner-toip@snowshore.com [mailto:owner-toip@snowshore.com]F=F6r Frank Shearar Skickat: den 12 november 2003 05:07 Till: toip@snowshore.com =C4mne: RFC2793bis and byte orders Hi all, I noticed that the RFC 2793bis draft never speaks of byte ordering. Is it assumed, since this is usually used in the context of RTP, that the byte order of the T140block counter is the byte order defined in RTP, i.e., network order? Wouldn't it be slightly better to specifically mention the byte order in = the draft, just to avoid any potential confusion? frank - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/toip_archive/maillist.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 23:25:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10868 for ; Thu, 13 Nov 2003 23:25:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVW5-0005hW-J8 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 23:25:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE4P5nr021913 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 23:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVW2-0005gm-Bz; Thu, 13 Nov 2003 23:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVVv-0005g7-Ey for avt@optimus.ietf.org; Thu, 13 Nov 2003 23:24:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10853 for ; Thu, 13 Nov 2003 23:24:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKVVt-00059z-00 for avt@ietf.org; Thu, 13 Nov 2003 23:24:53 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AKVVs-00059t-00 for avt@ietf.org; Thu, 13 Nov 2003 23:24:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAE4OEZ06359; Thu, 13 Nov 2003 23:24:14 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3H88L5Z; Thu, 13 Nov 2003 23:24:14 -0500 Received: from nortelnetworks.com (acart15f.ca.nortel.com [47.130.24.129]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NN14; Thu, 13 Nov 2003 23:24:14 -0500 Message-ID: <3FB458ED.2010102@nortelnetworks.com> Date: Thu, 13 Nov 2003 22:24:13 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom CC: avt@ietf.org Subject: Re: SV: SV: [AVT] More on V.21 events References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Where is this stuff specified? I can't find any sign of it in V.21 itself. Gunnar Hellstrom wrote: > OK, fine. > > You will have some nasty detection cases. Hope that detection precision is > good enough for that. > > E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( if > I get bit-order right ) > > The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms of 1180 > Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character. > > The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of 1180 > Hz, 81,9 ms of 980 Hz continued in 980 Hz. > > > So, the difference is that the start bit is 9.1 ms in one case, and the > start bit plus two data bits are 10 ms in the other case. Is this enough to > decide on 110 or 300 bps and time the detector to generate bit events during > the row of bits in steady 980 Hz? > > Is there a need for also a detector specification? > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > > > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor > Skickat: den 13 november 2003 20:28 > Till: Gunnar Hellstrom > Kopia: avt@ietf.org > Amne: Re: SV: [AVT] More on V.21 events > > > I'll adjust the wording to allow for rates lower than 300 bits/s. My > original question still stands, but is perhaps less pressing at lower rates. > > Actually, I'm in favour of requiring an event to be reported for each > bit sent. This increases redundancy in a natural manner, since event > completions are transmitted redundantly. > > Gunnar Hellstrom wrote: > > >>Have you decided how you will report V.21 110 bits/second. It is used in >>large parts of Europe and South America for text telephony. >> >>( sorry, I should have read what applications are in scope before putting >>this question, maybe it is totally out of scope that a textphone call > > needs > >>to be decoded and transmitted this way. ) >> >>Regards >>Gunnar Hellstrom >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>-----Ursprungligt meddelande----- >>Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor >>Skickat: den 13 november 2003 19:44 >>Till: avt@ietf.org >>Amne: [AVT] More on V.21 events >> >> >>Thinking about V.21 a bit more, I realized that it isn't clear when an >>event should be rteported. The choices are to report an event every >>time a bit is sent (i.e., 300 events per second), or else every time a >>transition occurs (which means something less than 150 events per >>second). Of course, the event rate itself doesn't mean too much without >>also specifying the rate at which event updates are issued. But if >>updates are issued every 66.7 ms or more, the number of event reports >>would be halved on the average. >> >>So: should we specify one approach or the other, or allow either and >>require implementations to be able to handle events spanning multiple > > bits? > >>Tom Taylor >> >> >>_______________________________________________ >>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 > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 23:29:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10993 for ; Thu, 13 Nov 2003 23:29:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVZv-0006E0-DD for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 23:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE4T3qY023872 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 23:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVZu-0006Cr-8i; Thu, 13 Nov 2003 23:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVZH-0006Bz-Dj for avt@optimus.ietf.org; Thu, 13 Nov 2003 23:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10959 for ; Thu, 13 Nov 2003 23:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKVZF-0005Cv-00 for avt@ietf.org; Thu, 13 Nov 2003 23:28:21 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1AKVZD-0005Cf-00 for avt@ietf.org; Thu, 13 Nov 2003 23:28:20 -0500 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAE4Rh600540; Thu, 13 Nov 2003 23:27:43 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WTC1JKYN; Thu, 13 Nov 2003 23:27:43 -0500 Received: from nortelnetworks.com (acart15f.ca.nortel.com [47.130.24.129]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NN1W; Thu, 13 Nov 2003 23:27:43 -0500 Message-ID: <3FB459BE.5070205@nortelnetworks.com> Date: Thu, 13 Nov 2003 22:27:42 -0600 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom CC: avt@ietf.org Subject: Re: SV: SV: [AVT] More on V.21 events References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Actually, I'm not sure this is relevant to 2833bis. 2833bis starts with the assumption that the sender recognizes the event. You're saying that a sender able to distinguish between 110 bits/s and 300 bits/s V.21 will be tough to build. 2833bis isn't specifying a universal gateway, just giving gateways a language. Gunnar Hellstrom wrote: > OK, fine. > > You will have some nasty detection cases. Hope that detection precision is > good enough for that. > > E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( if > I get bit-order right ) > > The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms of 1180 > Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character. > > The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of 1180 > Hz, 81,9 ms of 980 Hz continued in 980 Hz. > > > So, the difference is that the start bit is 9.1 ms in one case, and the > start bit plus two data bits are 10 ms in the other case. Is this enough to > decide on 110 or 300 bps and time the detector to generate bit events during > the row of bits in steady 980 Hz? > > Is there a need for also a detector specification? > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > > > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor > Skickat: den 13 november 2003 20:28 > Till: Gunnar Hellstrom > Kopia: avt@ietf.org > Amne: Re: SV: [AVT] More on V.21 events > > > I'll adjust the wording to allow for rates lower than 300 bits/s. My > original question still stands, but is perhaps less pressing at lower rates. > > Actually, I'm in favour of requiring an event to be reported for each > bit sent. This increases redundancy in a natural manner, since event > completions are transmitted redundantly. > > Gunnar Hellstrom wrote: > > >>Have you decided how you will report V.21 110 bits/second. It is used in >>large parts of Europe and South America for text telephony. >> >>( sorry, I should have read what applications are in scope before putting >>this question, maybe it is totally out of scope that a textphone call > > needs > >>to be decoded and transmitted this way. ) >> >>Regards >>Gunnar Hellstrom >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>-----Ursprungligt meddelande----- >>Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor >>Skickat: den 13 november 2003 19:44 >>Till: avt@ietf.org >>Amne: [AVT] More on V.21 events >> >> >>Thinking about V.21 a bit more, I realized that it isn't clear when an >>event should be rteported. The choices are to report an event every >>time a bit is sent (i.e., 300 events per second), or else every time a >>transition occurs (which means something less than 150 events per >>second). Of course, the event rate itself doesn't mean too much without >>also specifying the rate at which event updates are issued. But if >>updates are issued every 66.7 ms or more, the number of event reports >>would be halved on the average. >> >>So: should we specify one approach or the other, or allow either and >>require implementations to be able to handle events spanning multiple > > bits? > >>Tom Taylor >> >> >>_______________________________________________ >>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 > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 13 23:50:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11869 for ; Thu, 13 Nov 2003 23:50:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVuJ-0007Tc-3G for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 23:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE4o7rK028734 for avt-archive@odin.ietf.org; Thu, 13 Nov 2003 23:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVuE-0007So-Nk; Thu, 13 Nov 2003 23:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVtg-0007SC-Hw for avt@optimus.ietf.org; Thu, 13 Nov 2003 23:49:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11851 for ; Thu, 13 Nov 2003 23:49:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKVte-0005cI-00 for avt@ietf.org; Thu, 13 Nov 2003 23:49:26 -0500 Received: from p11.n-slpop01.stsn.com ([12.168.96.11] helo=slpop.smtp.stsn.com) by ietf-mx with esmtp (Exim 4.12) id 1AKVtd-0005c8-00 for avt@ietf.org; Thu, 13 Nov 2003 23:49:25 -0500 Received: from vit ([10.11.23.33]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 21:44:26 -0700 From: "Gunnar Hellstrom" To: "Tom Taylor" Cc: Subject: SV: SV: SV: [AVT] More on V.21 events Date: Thu, 13 Nov 2003 22:49:00 -0600 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FB458ED.2010102@nortelnetworks.com> Importance: Normal X-OriginalArrivalTime: 14 Nov 2003 04:44:26.0171 (UTC) FILETIME=[FB5908B0:01C3AA69] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The trick is that usually V.21 users have agreed before the call, what bitrate they will use. If a Swiss textphone user calls another, they both have V.21s running at 110 bps. So, then the modems trig on the start bit edge, and clock out its bits and sample the frequency in the middle of the bits. I guess that there are some words about that in V.21. Something about pre-agreed bitrate or so. But if you are designing a more general detector that has the ambition to detect and transmit all tone signals reliably, then you end up in the kind of tricky determination situations I mentioned. We already have it in the text telephone auto moding modem V.18, that also need to detect and discriminate between these quite close alternatives. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Ursprungligt meddelande----- Fran: Tom Taylor [mailto:taylor@nortelnetworks.com] Skickat: den 13 november 2003 22:24 Till: Gunnar Hellstrom Kopia: avt@ietf.org Amne: Re: SV: SV: [AVT] More on V.21 events Where is this stuff specified? I can't find any sign of it in V.21 itself. Gunnar Hellstrom wrote: > OK, fine. > > You will have some nasty detection cases. Hope that detection precision is > good enough for that. > > E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( if > I get bit-order right ) > > The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms of 1180 > Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character. > > The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of 1180 > Hz, 81,9 ms of 980 Hz continued in 980 Hz. > > > So, the difference is that the start bit is 9.1 ms in one case, and the > start bit plus two data bits are 10 ms in the other case. Is this enough to > decide on 110 or 300 bps and time the detector to generate bit events during > the row of bits in steady 980 Hz? > > Is there a need for also a detector specification? > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > > > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor > Skickat: den 13 november 2003 20:28 > Till: Gunnar Hellstrom > Kopia: avt@ietf.org > Amne: Re: SV: [AVT] More on V.21 events > > > I'll adjust the wording to allow for rates lower than 300 bits/s. My > original question still stands, but is perhaps less pressing at lower rates. > > Actually, I'm in favour of requiring an event to be reported for each > bit sent. This increases redundancy in a natural manner, since event > completions are transmitted redundantly. > > Gunnar Hellstrom wrote: > > >>Have you decided how you will report V.21 110 bits/second. It is used in >>large parts of Europe and South America for text telephony. >> >>( sorry, I should have read what applications are in scope before putting >>this question, maybe it is totally out of scope that a textphone call > > needs > >>to be decoded and transmitted this way. ) >> >>Regards >>Gunnar Hellstrom >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>-----Ursprungligt meddelande----- >>Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor >>Skickat: den 13 november 2003 19:44 >>Till: avt@ietf.org >>Amne: [AVT] More on V.21 events >> >> >>Thinking about V.21 a bit more, I realized that it isn't clear when an >>event should be rteported. The choices are to report an event every >>time a bit is sent (i.e., 300 events per second), or else every time a >>transition occurs (which means something less than 150 events per >>second). Of course, the event rate itself doesn't mean too much without >>also specifying the rate at which event updates are issued. But if >>updates are issued every 66.7 ms or more, the number of event reports >>would be halved on the average. >> >>So: should we specify one approach or the other, or allow either and >>require implementations to be able to handle events spanning multiple > > bits? > >>Tom Taylor >> >> >>_______________________________________________ >>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 > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 14 17:01:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00969 for ; Fri, 14 Nov 2003 17:01:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKm0J-0003Nc-Fe for avt-archive@odin.ietf.org; Fri, 14 Nov 2003 17:01:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEM1N4s012991 for avt-archive@odin.ietf.org; Fri, 14 Nov 2003 17:01:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlzy-0003MJ-46; Fri, 14 Nov 2003 17:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlzc-0003Ln-0H for avt@optimus.ietf.org; Fri, 14 Nov 2003 17:00:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00927 for ; Fri, 14 Nov 2003 17:00:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKlzZ-0004y9-00 for avt@ietf.org; Fri, 14 Nov 2003 17:00:37 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AKlzZ-0004y6-00 for avt@ietf.org; Fri, 14 Nov 2003 17:00:37 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hAEM0OBQ024059; Fri, 14 Nov 2003 17:00:24 -0500 Message-ID: <01d401c3aafa$b5220f40$0401a8c0@berlin> From: "Paul E. Jones" To: "Mark Baugher" , "Jean-Francois Mule" Cc: , =?iso-8859-1?Q?Mats__N=E4slund?= , , , "Elisabetta Carrara \(KI/EAB\)" , "Martin Euchner" References: <6.0.0.22.2.20031106112128.03b0d9b0@mira-sjc5-6.cisco.com> <013101c3a4ae$95159430$74bc47ab@cisco.com> <6.0.0.22.2.20031106150436.03b997f0@mira-sjc5-6.cisco.com> Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward Date: Fri, 14 Nov 2003 17:00:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by paris.packetizer.org id hAEM0OBQ024059 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Mark, Jean-Francois, Taking your input and that of others, I've drafted the following text for the "security considerations" section of this draft. Please tell me if y= ou like this or suggest specific changes: T38 is vulnerable to attacks that are common to other types of RTP and SRTP payloads. However, unlike audio, T.38 data may be manipulated in ways that are more obtrusive than audio. As examples, rogue packets may cause transmission failure and manipulated packets may alter terminal identity. The security considerations discussed in the RTP [3] and SRTP [5] specification and any applicable RTP profile (for example, [9]) are applicable to T.38. Regarding SRTP configuration, fax payloads SHOULD NOT use an HMAC-SHA1 authentication tag that is shorter than 80 bits Looking forward to your comments. Paul ----- Original Message -----=20 From: "Mark Baugher" To: "Paul E. Jones" Cc: "Jean-Francois Mule" ; ; "Mats N=E4slund" ; ; ; "Elisabetta Carrara (KI/EAB)" Sent: Thursday, November 06, 2003 7:14 PM Subject: Re: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward > Paul > I think the approach that you mentioned in the security consideratio= n is > good since it relies on the security consideration and security mechani= sms > found in RTP and SRTP. What is needed is to specify what might be specific > to the fax payload type with respect to SRTP. I'd say that a short 32-= bit > tag is a SHOULD NOT for fax and not a MAY as it is with other applicati= ons > owing to the fact that the effects of fraud are so much greater form > certain fax applications than is generally true for voice. I'd offer > something like this. > "T38 is vulnerable to attacks that are common on other types of RTP > payloads. The security considerations and mechanisms of RTP and SRTP apply > to T38. Regarding SRTP configuration, fax payloads SHOULD NOT use an > HMAC-SHA1 authentication tag that is shorter than 80 bits." > > Mark > At 01:40 PM 11/6/2003, Paul E. Jones wrote: > >Mark, > > > >Your comments are valid. In fact, it's SRTP that is one driver (but n= ot the > >only driver) for wanting to move to RTP. But, I hesitate to mention S= RTP > >without discussing the use of SRTP. > > > >Is there specific text that you'd like to propose. If you propose it = and > >folks agree, I definitely have no objections to incorporating it. > > > >Paul > > > >----- Original Message ----- > >From: "Mark Baugher" > >To: "Jean-Francois Mule" > >Cc: "Paul E. Jones" ; > >Sent: Thursday, November 06, 2003 2:27 PM > >Subject: RE: [AVT] Moving draft-jones-avt-audio-t38-01.txt forward > > > > > > > At 10:51 AM 11/6/2003, Jean-Francois Mule wrote: > > > >Paul wrote: > > > > > I purposely did not address SRTP, because this brings in a > > > > > different RTP profile (SAVP) and I've not fully studied what > > > > > (if anything) needs to be done to use that profile. Further, > > > > > SRTP is still in draft form. I really don't want to have > > > > > interdependencies. > > > >I'll let other folks comment on whether it is appropriate to not address > > > >the draft's connections with SRTP. > > > > > > I think that there is _an_ SRTP connection (or is it connexion :?) that > > > should be referred to in the security considerations. The text tha= t is in > > > the current draft could be extended slightly to say that t38 is vulnerable > > > to attacks that are common on other types of RTP payloads and that = the > > > security considerations and mechanisms of RTP and SRTP apply to t38. > > > > > > Mark > > > > > > > > > > > > -- > > > > > > A number of issues were raised with respect to the usage of > > > > > UDPTL for > > > > > > the long-term, though. Specifically, there were > > > > > concerns over the > > > > > > fact that UDPTL does not provide the same kind of statisti= cs > > > > > > reporting as RTCP. Further, there are no procedures in pl= ace for > > > > > > encrypting the UDPTL stream. While the latter could be > > > > > addressed in > > > > > > UDPTL, doing so would require a lot of effort and would > > > > > largely be a > > > > > > duplication of the security work already on-going within > > > > > the IETF. > > > > > > -- > > > > > > > > > > What was the specifc change you want made above? Just > > > > > calling out the "an RTP"? > > > > > > > >How about something like: > > > >s/encrypting the UDPTL stream/authenticating or encrypting the UDP= TL > >stream > > > > > > > > > > > > > > --- technical comment > > > > > > The section 6 (security considerations) is rather silent on t= he > > > > > > security threats. Looking at the IFP packet format, I would > > > > > argue that > > > > > > those packets do expose serious threats to the > > > > > communication that you > > > > > > don't see in audio voice. If you insert a bad RTP packet voic= e > > > > > > payload, oh well, you may hear some garbage or clipping. > > > > > With rtp/t38 > > > > > > fax, bad packets may cause real harm: > > > > > > + denial of service attacks can be mounted by inserting RTP/t= 38 > > > > > > + packets > > > > > > with hdlc-sig-end data field can simply terminate the fax control > > > > > > channel. Same with HDLC-FCS-BAD-Sig-End. And one can easily create > > > > > > those packets. > > > > > > + theft of terminal identity? In some countries, faxes have > > > > > more legal > > > > > > value that emails and the access to the rtp packet content co= uld > > > > > > change the Called Subscriber ID frame (phone numbers), etc. = As you > > > > > > well know, this info is usually not coded in RTP but in signaling > > > > > > protocols. > > > > > > > > > > > > I'm sure the Study Group has thought of more. Could some > > > > > examples of > > > > > > security threats be given in the security consideration secti= on and > > > > > > shouldn't this section again reference SRTP? > > > > > > > > > > These are both valid points. I fully support the addition of > > > > > some text that highlights this fact. I would not want to > > > > > call these out explicitly, necessarily, as there may be other > > > > > places (e.g., modification or injection of NSF data, etc.), > > > > > so I think it's reasonable to speak to this generically. > > > > > > > > > > Would you like to suggest some text? I'd be happy to incorpora= te it. > > > >I would rather let you wordsmith my comments into something genera= l you > > > >like on this one. > > > > > > > >Jean-Fran=E7ois > > > > > > > >_______________________________________________ > > > >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 > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 17 11:51:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20484 for ; Mon, 17 Nov 2003 11:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmap-0000bT-Ad for avt-archive@odin.ietf.org; Mon, 17 Nov 2003 11:51:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHGpFOg002315 for avt-archive@odin.ietf.org; Mon, 17 Nov 2003 11:51:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmab-0000ag-4m; Mon, 17 Nov 2003 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALmZd-0000ZN-H7 for avt@optimus.ietf.org; Mon, 17 Nov 2003 11:50:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20343 for ; Mon, 17 Nov 2003 11:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALmZc-0001VE-00 for avt@ietf.org; Mon, 17 Nov 2003 11:50:00 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ALmZb-0001UW-00 for avt@ietf.org; Mon, 17 Nov 2003 11:49:59 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHGnQh18784 for ; Mon, 17 Nov 2003 11:49:26 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3H89QL7; Mon, 17 Nov 2003 11:49:27 -0500 Received: from nortelnetworks.com (acart1bh.ca.nortel.com [47.129.129.27]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NN9V; Mon, 17 Nov 2003 11:49:27 -0500 Message-ID: <3FB8FC16.7020600@nortelnetworks.com> Date: Mon, 17 Nov 2003 11:49:26 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] V.8bis messages in RFC 2833bis References: <3FB42C22.20605@nortelnetworks.com> In-Reply-To: <3FB42C22.20605@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've swung the other way in my thinking. It seems to me the most common application for 2833 data events will be that of an IP bridge between two PSTN terminals. This means the signalling should be such as to require a minimum of application knowledge at either gateway. So Every bit should be passed along faithfully. There is a problem with V.8bis signals (as opposed to messages). The signals consist of two tone segments: 400 ms of dual-frequency tone that indicates only which party is sending, followed by 100 ms of signal-specific single tone. With the present set of V.8bis events, that means the sender has to wait something in excess of 400 ms before indicating what event is happening. The receiver starts playout 400+ ms late. I'm not sure if that has harmful effects -- the timing does not seem to be a problem in V.8bis itself, but maybe in interoperation with older modems ... Anyway, a V.8bis signal is often followed by a preamble tone and then by a V.8bis message (i.e. sequence of V.21 bits, as dicussed in my note below). The implication of the 400+ ms delay is that down the line, the receiver is going to have to buffer up to 150 bit events for playout when their time comes. I'm putting text in 2833bis to warn of this, but it seems to me matters could be improved if we added one or two events to indicate that segment 1 signal playout has begun. This would mean the receiver would only be behind by the amount of time the sender needed to recognize the tone and send out the initial message. Any comments by people who have done some implementation? Taylor, Tom-PT [CAR:5N00:EXCH] wrote: > While rewriting RFC 2833bis I found that the use of V.21 events with > V.8bis signalling was underspecified. V.21 simply transmits bits at 300 > bits/s using pure tones of specified frequencies to represent "0"s and > "1"s. (V.21 has two channels, but that is irrelevant here.) A V.8bis > message is a sequence of octets, where the carried information is > preceded by HDLC flags and succeeded by a checksum and more HDLC flags. > To prevent false identification of HDLC flags within the carried > information, extra zeros are inserted after sequences of five "1"s and > stripped out again at the receiving end. > > It doesn't seem necessary to carry the HDLC flags, and probably not the > checksum (assuming redundancy encoding provides a sufficient degree of > reliability). The HDLC flags represent a minimum of 24 bits and a > maximum of 64, each one of which is a separate event. The checksum adds > another 16 bits. Zero stuffing adds some more. > > Are there any existing implementations, and do they transmit the flags > and checksum or not? > > On a related topic, how many V.21 bits should be reported per packet, > given that they are propagated at 33 ms intervals? Any recommendation? > > Tom Taylor > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Nov 17 13:29:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27115 for ; Mon, 17 Nov 2003 13:29:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALo7V-0005LF-Sr for avt-archive@odin.ietf.org; Mon, 17 Nov 2003 13:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHIT5Dx020508 for avt-archive@odin.ietf.org; Mon, 17 Nov 2003 13:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALo7R-0005KC-49; Mon, 17 Nov 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALo6p-0005Jo-KU for avt@optimus.ietf.org; Mon, 17 Nov 2003 13:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27088 for ; Mon, 17 Nov 2003 13:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALo6n-0003qr-00 for avt@ietf.org; Mon, 17 Nov 2003 13:28:21 -0500 Received: from [65.192.41.10] (helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1ALo6n-0003qi-00 for avt@ietf.org; Mon, 17 Nov 2003 13:28:21 -0500 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hAHIRZHW048619; Mon, 17 Nov 2003 10:27:35 -0800 (PST) (envelope-from casner@acm.org) Date: Mon, 17 Nov 2003 10:27:35 -0800 (PST) From: Stephen Casner To: Tom Taylor cc: avt@ietf.org Subject: Re: [AVT] V.8bis messages in RFC 2833bis In-Reply-To: <3FB8FC16.7020600@nortelnetworks.com> Message-ID: <20031117102320.N75988@ash.packetdesign.com> References: <3FB42C22.20605@nortelnetworks.com> <3FB8FC16.7020600@nortelnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Mon, 17 Nov 2003, Tom Taylor wrote: > I've swung the other way in my thinking. It seems to me the most common > application for 2833 data events will be that of an IP bridge between > two PSTN terminals. This means the signalling should be such as to > require a minimum of application knowledge at either gateway. So Every > bit should be passed along faithfully. I agree with the penultimate sentence, but would modify the last one to say ever _tone_ should be passed along faithfully. As I argued a few meetings back, 2833 is a means to encode signaling tones more accurately and with fewer bits than low-data rate voice encodings can do. It is not a data transport. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 17 19:37:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15718 for ; Mon, 17 Nov 2003 19:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALtri-0002Vz-B7 for avt-archive@odin.ietf.org; Mon, 17 Nov 2003 19:37:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI0b9E7009621 for avt-archive@odin.ietf.org; Mon, 17 Nov 2003 19:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALtra-0002TV-0c; Mon, 17 Nov 2003 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALtrC-0002SG-Nb for avt@optimus.ietf.org; Mon, 17 Nov 2003 19:36:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15644 for ; Mon, 17 Nov 2003 19:36:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALtrA-0002Lt-00 for avt@ietf.org; Mon, 17 Nov 2003 19:36:36 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ALtrA-0002Ld-00 for avt@ietf.org; Mon, 17 Nov 2003 19:36:36 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60192 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ALtqa-0006Hj-00; Tue, 18 Nov 2003 00:36:00 +0000 Date: Tue, 18 Nov 2003 00:35:56 +0000 Subject: Re: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jose Rey , jan.vandermeer@philips.com, "'IETF AVT WG'" , Magnus Westerlund , Yoshinori Matsui To: Dave Singer From: Colin Perkins In-Reply-To: Message-Id: <2CB408E0-195F-11D8-B8F6-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, Nov 11, 2003, at 18:43 Europe/London, Dave Singer wrote: > At 17:27 +0100 11/11/03, Jose Rey wrote: >> Hi all, >> >> for those that did not attend the AVT session on Monday, there was a >> number of comments and useful feedback during the timed text >> presentation. ... >> The current approach makes sense if the text samples are regularly >> small >> and one or several of them fit into an RTP packet. Fragmentation would >> happen seldom. The 'pure alf approach' is, in general, the most >> correct >> one, and so also the one that requires more header definitions. If >> fragmentation is a rare event, this overhead may be not worth (?). >> The >> question to the group is pretty simple: which approach should be >> pursued? > > I think we can find a middle ground. I think that text samples over > 512 bytes are quite rare, and over 1400 bytes very rare indeed. I > don't mind going to a format which is less file-format centric, but I > don't think we should spend a lot of time optimizing fragmented text > access units. I think my question was more fundamental: do we need to support fragments at all? Or is it possible, assuming the text generator is aware of the network, that timed text samples can always be made it fit within the MTU? Are the large samples an innate property of text, or an artefact of the process which can be avoided by careful coding? -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 01:32:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24672 for ; Tue, 18 Nov 2003 01:32:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALzPN-0001v1-KW for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 01:32:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI6WHZ6007374 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 01:32:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALzP7-0001u8-Au; Tue, 18 Nov 2003 01:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALzO8-0001rr-Iw for avt@optimus.ietf.org; Tue, 18 Nov 2003 01:31:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24647 for ; Tue, 18 Nov 2003 01:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALzO5-0006fD-00 for avt@ietf.org; Tue, 18 Nov 2003 01:30:57 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1ALzO4-0006fA-00 for avt@ietf.org; Tue, 18 Nov 2003 01:30:56 -0500 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: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 18 Nov 2003 07:30:45 +0100 Message-ID: <8C7C642E667D8E4389197633C7D0E98301EFC1@lan-ex-01.panasonic.de> Thread-Topic: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Thread-Index: AcOta+6xSYLk70i7RFGRmhZsuhGgOgALqoKQ From: "Rey Jose" To: "Colin Perkins" , "Dave Singer" Cc: , "IETF AVT WG" , "Magnus Westerlund" , "Yoshinori Matsui" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, November 18, 2003 1:36 AM > To: Dave Singer > Cc: Rey Jose; jan.vandermeer@philips.com; 'IETF AVT WG'; Magnus > Westerlund; Yoshinori Matsui > Subject: Re: AW: [AVT] More comments on > draft-rey-avt-rtp-3gpp-timed-text-01.txt >=20 >=20 > On Tuesday, Nov 11, 2003, at 18:43 Europe/London, Dave Singer wrote: > > At 17:27 +0100 11/11/03, Jose Rey wrote: > >> Hi all, > >> > >> for those that did not attend the AVT session on Monday,=20 > there was a > >> number of comments and useful feedback during the timed text > >> presentation. > ... > >> The current approach makes sense if the text samples are regularly=20 > >> small > >> and one or several of them fit into an RTP packet.=20 > Fragmentation would > >> happen seldom. The 'pure alf approach' is, in general, the most=20 > >> correct > >> one, and so also the one that requires more header definitions. If > >> fragmentation is a rare event, this overhead may be not=20 > worth (?). =20 > >> The > >> question to the group is pretty simple: which approach should be > >> pursued? > > > > I think we can find a middle ground. I think that text=20 > samples over=20 > > 512 bytes are quite rare, and over 1400 bytes very rare indeed. I=20 > > don't mind going to a format which is less file-format=20 > centric, but I=20 > > don't think we should spend a lot of time optimizing=20 > fragmented text=20 > > access units. >=20 > I think my question was more fundamental: do we need to support=20 > fragments at all? Or is it possible, assuming the text generator is=20 > aware of the network, that timed text samples can always be=20 > made it fit=20 > within the MTU? >=20 > Are the large samples an innate property of text, or an=20 > artefact of the=20 > process which can be avoided by careful coding? >=20 for live streaming, on-the-fly MTU adaptation sounds reasonable; however = for the normal streaming scenario should every 3gp text file be = available as a streameable file in every possible MTU size?=20 Jose _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 06:15:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14572 for ; Tue, 18 Nov 2003 06:15:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3pA-0004NW-10 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 06:15:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBFCLC016826 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 06:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3oz-0004Me-By; Tue, 18 Nov 2003 06:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3oE-0004Ln-Hk for avt@optimus.ietf.org; Tue, 18 Nov 2003 06:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14509 for ; Tue, 18 Nov 2003 06:14:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3oA-0002hR-00 for avt@ietf.org; Tue, 18 Nov 2003 06:14:10 -0500 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 1AM3o9-0002h8-00 for avt@ietf.org; Tue, 18 Nov 2003 06:14:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ADC5.066D18C7" Date: Tue, 18 Nov 2003 13:13:42 +0200 Message-ID: Thread-Topic: BYE RTCP packet schedule. Thread-Index: AcOtxQatXlUyERj0EdiSgwDQt7+w2w== From: "Oren Peleg" To: , Cc: , "Sigal Cohen" Subject: [AVT] BYE RTCP packet schedule. Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADC5.066D18C7 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable According to RFC3550, the BYE packet should be sent no less then a = minimum interval from former RTCP packet. This can cause a resource = re-usage problems. Shouldn't it be more relaxed (at least for unicast = sessions) to enable sending an immediate BYE upon RTP session closing? Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------_=_NextPart_001_01C3ADC5.066D18C7 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable BYE RTCP packet schedule.

According to RFC3550, the BYE = packet should be sent no less then a minimum interval from former RTCP = packet. This can cause a resource re-usage problems. Shouldn't it be = more relaxed (at least for unicast sessions) to enable sending an = immediate BYE upon RTP session closing?

Thanks,

Oren Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email : Oren.Peleg@audiocodes.com

------_=_NextPart_001_01C3ADC5.066D18C7-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 09:17:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21629 for ; Tue, 18 Nov 2003 09:17:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM6fC-0006y1-IZ for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 09:17:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIEH6Zf026752 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 09:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM6f7-0006wt-42; Tue, 18 Nov 2003 09:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM6eW-0006wU-6M for avt@optimus.ietf.org; Tue, 18 Nov 2003 09:16:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21621 for ; Tue, 18 Nov 2003 09:16:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM6eU-0005nd-00 for avt@ietf.org; Tue, 18 Nov 2003 09:16:22 -0500 Received: from mail0.rawbw.com ([198.144.192.41]) by ietf-mx with esmtp (Exim 4.12) id 1AM6eT-0005na-00 for avt@ietf.org; Tue, 18 Nov 2003 09:16:22 -0500 Received: from io.herlein.com (m205-235.dsl.tsoft.com [198.144.205.235]) by mail0.rawbw.com (8.11.6p2/8.11.6) with ESMTP id hAIEG7o33743; Tue, 18 Nov 2003 06:16:07 -0800 (PST) Date: Tue, 18 Nov 2003 06:04:24 -0800 (PST) From: Greg Herlein X-X-Sender: gregh@io.herlein.com To: david.liu@st.com cc: avt@ietf.org Subject: Re: [AVT] Ask open source information on RTP/RTSP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Now I want to find a free RTP/RTSP streaming server to test > ip set top box which does as a RTP/RTSP client. RTSP Implementation List at: http://www.rtsp.org/2001/implementations.html Of these, MPEG4IP seems very solid and is commercial friendly open source, for the most part. http://mpeg4ip.sourceforge.net/ Apple, Helix, Live.com - all have footprints in the open source world. Helix is from Real and may be used non-commercially, or licensed on a per server basis for commercial applications. Vovida even has some stack elements. FFMPEG has ffserver, though it's perhaps not all that stable yet for production use. Good codec library too. http://ffmpeg.sourceforge.net/ I'm very intrigued by the idea of a set top box that is a RTSP/RTP client. Can you share more (publicly or privately) about your new product? I'd be interested in doing some testing on such a product, and even collaborating/assisting with your RTSP server needs. Greg Herlein VP Engineering Arkstream, Inc. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 09:52:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22942 for ; Tue, 18 Nov 2003 09:52:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7D5-0000KF-1J for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 09:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIEq7oD001248 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 09:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7Cz-0000JU-9U; Tue, 18 Nov 2003 09:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7CG-0000IN-Pq for avt@optimus.ietf.org; Tue, 18 Nov 2003 09:51:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22897 for ; Tue, 18 Nov 2003 09:51:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7CE-0006HY-00 for avt@ietf.org; Tue, 18 Nov 2003 09:51:14 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AM7CE-0006H0-00 for avt@ietf.org; Tue, 18 Nov 2003 09:51:14 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAIEoep14630; Tue, 18 Nov 2003 09:50:40 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3H80CMR; Tue, 18 Nov 2003 09:50:40 -0500 Received: from nortelnetworks.com (acart1mq.ca.nortel.com [47.129.130.76]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5N3JS; Tue, 18 Nov 2003 09:50:40 -0500 Message-ID: <3FBA31BF.2090409@nortelnetworks.com> Date: Tue, 18 Nov 2003 09:50:39 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom CC: avt@ietf.org Subject: Re: SV: SV: [AVT] More on V.21 events References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've had a couple of after-thoughts on your note. First: as far as I know, RFC 2833 does not pretend to cover V.21s, as opposed to V.21. As I understand it, the scope of 2833 is limited to session setup, not content once a session is started. For that you use G.711 or V.150.1 modem relay or perhaps CLEARMODE. Secondly, aren't your timings out by an order of magnitude? At 300 bits/s, surely each bit event can't take more than 3.3 ms. Gunnar Hellstrom wrote: > OK, fine. > > You will have some nasty detection cases. Hope that detection precision is > good enough for that. > > E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( if > I get bit-order right ) > > The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms of 1180 > Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character. > > The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of 1180 > Hz, 81,9 ms of 980 Hz continued in 980 Hz. > > > So, the difference is that the start bit is 9.1 ms in one case, and the > start bit plus two data bits are 10 ms in the other case. Is this enough to > decide on 110 or 300 bps and time the detector to generate bit events during > the row of bits in steady 980 Hz? > > Is there a need for also a detector specification? > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > > > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor > Skickat: den 13 november 2003 20:28 > Till: Gunnar Hellstrom > Kopia: avt@ietf.org > Amne: Re: SV: [AVT] More on V.21 events > > > I'll adjust the wording to allow for rates lower than 300 bits/s. My > original question still stands, but is perhaps less pressing at lower rates. > > Actually, I'm in favour of requiring an event to be reported for each > bit sent. This increases redundancy in a natural manner, since event > completions are transmitted redundantly. > > Gunnar Hellstrom wrote: > > >>Have you decided how you will report V.21 110 bits/second. It is used in >>large parts of Europe and South America for text telephony. >> >>( sorry, I should have read what applications are in scope before putting >>this question, maybe it is totally out of scope that a textphone call > > needs > >>to be decoded and transmitted this way. ) >> >>Regards >>Gunnar Hellstrom >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>-----Ursprungligt meddelande----- >>Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor >>Skickat: den 13 november 2003 19:44 >>Till: avt@ietf.org >>Amne: [AVT] More on V.21 events >> >> >>Thinking about V.21 a bit more, I realized that it isn't clear when an >>event should be rteported. The choices are to report an event every >>time a bit is sent (i.e., 300 events per second), or else every time a >>transition occurs (which means something less than 150 events per >>second). Of course, the event rate itself doesn't mean too much without >>also specifying the rate at which event updates are issued. But if >>updates are issued every 66.7 ms or more, the number of event reports >>would be halved on the average. >> >>So: should we specify one approach or the other, or allow either and >>require implementations to be able to handle events spanning multiple > > bits? > >>Tom Taylor >> >> >>_______________________________________________ >>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 > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 11:18:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28222 for ; Tue, 18 Nov 2003 11:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8YT-0005DF-C2 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 11:18:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGIHKI019971 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 11:18:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8YD-00056k-FP; Tue, 18 Nov 2003 11:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8Xg-00054s-BL for avt@optimus.ietf.org; Tue, 18 Nov 2003 11:17:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28161 for ; Tue, 18 Nov 2003 11:17:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8Xf-00001M-00 for avt@ietf.org; Tue, 18 Nov 2003 11:17:27 -0500 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 1AM8Xe-00001J-00 for avt@ietf.org; Tue, 18 Nov 2003 11:17:26 -0500 Received: from vit (135.240.13.217.in-addr.dgcsystems.net [217.13.240.135]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id hAIGHEd24310; Tue, 18 Nov 2003 17:17:14 +0100 (CET) From: "Gunnar Hellstrom" To: "Tom Taylor" Cc: "Paul Jones" , Subject: RE: SV: SV: [AVT] More on V.21 events Date: Tue, 18 Nov 2003 10:17:23 -0600 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.2910.0) In-Reply-To: <3FBA31BF.2090409@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, You are probably right, it would be a waste of bandwidth to send V.21 session data as RFC2833 signals. For V.21 session data in the text telephone case that I am thinking of, RFC2793 is to prefer. However, for DTMF, I think you should have detectors for RFC2833 on during the whole voice call, not just during session setup. What is V.21s? The timings are right. At 300 bits/s the bits are 3.3 ms. At 110 ms it is 9.1 ms. The tricky example was to distinguish between a character at 300 bits/s starting with start bit and two 0-bits giving a 9.9 ms long single tone, then followed by 6 1-bits, a stop bit and then line fill with steady 1. That will give the pattern of 9.9 ms of 1180 HZ followed by endless 980 Hz. The comparison was with a byte of FF in 110 bits/s V.21 that is 9.1 ms of 1180 Hz, followed by endless 980 Hz. If we follow the original idea, not to use RFC2833 for text telephony text, it may be OK to limit the support to 300 bits/s V.21. All the session startup examples of use of v.21 are using 300 bits/s. Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom Taylor Sent: Tuesday, November 18, 2003 8:51 AM To: Gunnar Hellstrom Cc: avt@ietf.org Subject: Re: SV: SV: [AVT] More on V.21 events I've had a couple of after-thoughts on your note. First: as far as I know, RFC 2833 does not pretend to cover V.21s, as opposed to V.21. As I understand it, the scope of 2833 is limited to session setup, not content once a session is started. For that you use G.711 or V.150.1 modem relay or perhaps CLEARMODE. Secondly, aren't your timings out by an order of magnitude? At 300 bits/s, surely each bit event can't take more than 3.3 ms. Gunnar Hellstrom wrote: > OK, fine. > > You will have some nasty detection cases. Hope that detection precision is > good enough for that. > > E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( if > I get bit-order right ) > > The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms of 1180 > Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character. > > The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of 1180 > Hz, 81,9 ms of 980 Hz continued in 980 Hz. > > > So, the difference is that the start bit is 9.1 ms in one case, and the > start bit plus two data bits are 10 ms in the other case. Is this enough to > decide on 110 or 300 bps and time the detector to generate bit events during > the row of bits in steady 980 Hz? > > Is there a need for also a detector specification? > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > > > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor > Skickat: den 13 november 2003 20:28 > Till: Gunnar Hellstrom > Kopia: avt@ietf.org > Amne: Re: SV: [AVT] More on V.21 events > > > I'll adjust the wording to allow for rates lower than 300 bits/s. My > original question still stands, but is perhaps less pressing at lower rates. > > Actually, I'm in favour of requiring an event to be reported for each > bit sent. This increases redundancy in a natural manner, since event > completions are transmitted redundantly. > > Gunnar Hellstrom wrote: > > >>Have you decided how you will report V.21 110 bits/second. It is used in >>large parts of Europe and South America for text telephony. >> >>( sorry, I should have read what applications are in scope before putting >>this question, maybe it is totally out of scope that a textphone call > > needs > >>to be decoded and transmitted this way. ) >> >>Regards >>Gunnar Hellstrom >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>-----Ursprungligt meddelande----- >>Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor >>Skickat: den 13 november 2003 19:44 >>Till: avt@ietf.org >>Amne: [AVT] More on V.21 events >> >> >>Thinking about V.21 a bit more, I realized that it isn't clear when an >>event should be rteported. The choices are to report an event every >>time a bit is sent (i.e., 300 events per second), or else every time a >>transition occurs (which means something less than 150 events per >>second). Of course, the event rate itself doesn't mean too much without >>also specifying the rate at which event updates are issued. But if >>updates are issued every 66.7 ms or more, the number of event reports >>would be halved on the average. >> >>So: should we specify one approach or the other, or allow either and >>require implementations to be able to handle events spanning multiple > > bits? > >>Tom Taylor >> >> >>_______________________________________________ >>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 > > > > _______________________________________________ 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 exim@www1.ietf.org Tue Nov 18 11:34:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28913 for ; Tue, 18 Nov 2003 11:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8nj-00067U-W7 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 11:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGY345023518 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 11:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8ni-00066R-Cs; Tue, 18 Nov 2003 11:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8mz-00064e-5G for avt@optimus.ietf.org; Tue, 18 Nov 2003 11:33:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28770 for ; Tue, 18 Nov 2003 11:33:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8my-0000Gg-00 for avt@ietf.org; Tue, 18 Nov 2003 11:33:16 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AM8mx-0000GG-00 for avt@ietf.org; Tue, 18 Nov 2003 11:33:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAIGWXJ04934; Tue, 18 Nov 2003 11:32:34 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3H80FY3; Tue, 18 Nov 2003 11:32:34 -0500 Received: from nortelnetworks.com (acart1mq.ca.nortel.com [47.129.130.76]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5N3K8; Tue, 18 Nov 2003 11:32:34 -0500 Message-ID: <3FBA49A0.90408@nortelnetworks.com> Date: Tue, 18 Nov 2003 11:32:32 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom CC: Paul Jones , avt@ietf.org Subject: Re: SV: SV: [AVT] More on V.21 events References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ah, now I understand -- you were talking bytes where I was thinking bits. It happens that V.21 uses F-subscript-A to designate the higher characteristic frequency (binary 0) of a channel. So I thought you were talking bits. Gunnar Hellstrom wrote: > Tom, > You are probably right, it would be a waste of bandwidth to send V.21 > session data as RFC2833 signals. > For V.21 session data in the text telephone case that I am thinking of, > RFC2793 is to prefer. > > However, for DTMF, I think you should have detectors for RFC2833 on during > the whole voice call, not just during session setup. > > What is V.21s? > > The timings are right. > At 300 bits/s the bits are 3.3 ms. At 110 ms it is 9.1 ms. > The tricky example was to distinguish between a character at 300 bits/s > starting with start bit and two 0-bits giving a 9.9 ms long single tone, > then followed by 6 1-bits, a stop bit and then line fill with steady 1. > That will give the pattern of 9.9 ms of 1180 HZ followed by endless 980 Hz. > The comparison was with a byte of FF in 110 bits/s V.21 that is 9.1 ms of > 1180 Hz, followed by endless 980 Hz. > > If we follow the original idea, not to use RFC2833 for text telephony text, > it may be OK to limit the support to 300 bits/s V.21. All the session > startup examples of use of v.21 are using 300 bits/s. > > > Gunnar > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom > Taylor > Sent: Tuesday, November 18, 2003 8:51 AM > To: Gunnar Hellstrom > Cc: avt@ietf.org > Subject: Re: SV: SV: [AVT] More on V.21 events > > > I've had a couple of after-thoughts on your note. > > First: as far as I know, RFC 2833 does not pretend to cover V.21s, as > opposed to V.21. As I understand it, the scope of 2833 is limited to > session setup, not content once a session is started. For that you use > G.711 or V.150.1 modem relay or perhaps CLEARMODE. > > Secondly, aren't your timings out by an order of magnitude? At 300 > bits/s, surely each bit event can't take more than 3.3 ms. > > Gunnar Hellstrom wrote: > > >>OK, fine. >> >>You will have some nasty detection cases. Hope that detection precision is >>good enough for that. >> >>E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( > > if > >>I get bit-order right ) >> >>The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms of > > 1180 > >>Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character. >> >>The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of > > 1180 > >>Hz, 81,9 ms of 980 Hz continued in 980 Hz. >> >> >>So, the difference is that the start bit is 9.1 ms in one case, and the >>start bit plus two data bits are 10 ms in the other case. Is this enough > > to > >>decide on 110 or 300 bps and time the detector to generate bit events > > during > >>the row of bits in steady 980 Hz? >> >>Is there a need for also a detector specification? >> >>Gunnar >> >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >> >> >>-----Ursprungligt meddelande----- >>Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor >>Skickat: den 13 november 2003 20:28 >>Till: Gunnar Hellstrom >>Kopia: avt@ietf.org >>Amne: Re: SV: [AVT] More on V.21 events >> >> >>I'll adjust the wording to allow for rates lower than 300 bits/s. My >>original question still stands, but is perhaps less pressing at lower > > rates. > >>Actually, I'm in favour of requiring an event to be reported for each >>bit sent. This increases redundancy in a natural manner, since event >>completions are transmitted redundantly. >> >>Gunnar Hellstrom wrote: >> >> >> >>>Have you decided how you will report V.21 110 bits/second. It is used in >>>large parts of Europe and South America for text telephony. >>> >>>( sorry, I should have read what applications are in scope before putting >>>this question, maybe it is totally out of scope that a textphone call >> >>needs >> >> >>>to be decoded and transmitted this way. ) >>> >>>Regards >>>Gunnar Hellstrom >>>------------------------------------------- >>>Gunnar Hellstrom >>>Omnitor AB >>>Renathvagen 2 >>>SE 121 37 Johanneshov >>>SWEDEN >>>+46 8 556 002 03 >>>Mob: +46 708 204 288 >>>www.omnitor.se >>>Gunnar.Hellstrom@Omnitor.se >>>-------------------------------------------- >>> >>> >>>-----Ursprungligt meddelande----- >>>Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Tom Taylor >>>Skickat: den 13 november 2003 19:44 >>>Till: avt@ietf.org >>>Amne: [AVT] More on V.21 events >>> >>> >>>Thinking about V.21 a bit more, I realized that it isn't clear when an >>>event should be rteported. The choices are to report an event every >>>time a bit is sent (i.e., 300 events per second), or else every time a >>>transition occurs (which means something less than 150 events per >>>second). Of course, the event rate itself doesn't mean too much without >>>also specifying the rate at which event updates are issued. But if >>>updates are issued every 66.7 ms or more, the number of event reports >>>would be halved on the average. >>> >>>So: should we specify one approach or the other, or allow either and >>>require implementations to be able to handle events spanning multiple >> >>bits? >> >> >>>Tom Taylor >>> >>> >>>_______________________________________________ >>>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 >> >> >> >> > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Nov 18 11:53:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29991 for ; Tue, 18 Nov 2003 11:53:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM96A-0008CX-2S for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 11:53:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGr6rV031504 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 11:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM965-0008BD-E5; Tue, 18 Nov 2003 11:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM95O-00088L-C4 for avt@optimus.ietf.org; Tue, 18 Nov 2003 11:52:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29918 for ; Tue, 18 Nov 2003 11:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM95N-0000fM-00 for avt@ietf.org; Tue, 18 Nov 2003 11:52:17 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AM95K-0000f8-00 for avt@ietf.org; Tue, 18 Nov 2003 11:52:15 -0500 Received: from [12.161.102.11] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 2051443; Tue, 18 Nov 2003 11:51:57 -0500 Date: Tue, 18 Nov 2003 11:52:01 -0500 Subject: Re: [AVT] Ask open source information on RTP/RTSP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: avt@ietf.org To: david.liu@st.com From: Marshall Eubanks In-Reply-To: Message-Id: <8798AF09-19E7-11D8-B99E-003065FC3726@multicasttech.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Darwin streaming server does this. Note that rtsp is not generally done with multicast. On Tuesday, November 18, 2003, at 02:12 AM, david.liu@st.com wrote: > Dear experts, > > Now I want to find a free RTP/RTSP streaming server to test ip set > top box > which does as a RTP/RTSP client. > > I am not very familiar with existed RTP/RTSP open source code. So > would you > like to give me some suggestions. > > If the server can support VOD and control stream bit rate, it is > better. > > best regards > david.liu > > ST Microelectronics Inc. > email: david.liu@st.com > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > Regards Marshall Eubanks T.M. Eubanks e-mail : marshall.eubanks@telesuite.com http://www.telesuite.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 12:49:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03700 for ; Tue, 18 Nov 2003 12:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9yP-0004DV-IW for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 12:49:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIHn9KM016163 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 12:49:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9yH-00048Z-Bw; Tue, 18 Nov 2003 12:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9xt-00043B-ID for avt@optimus.ietf.org; Tue, 18 Nov 2003 12:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03614 for ; Tue, 18 Nov 2003 12:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9xr-0001zN-00 for avt@ietf.org; Tue, 18 Nov 2003 12:48:35 -0500 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 1AM9xr-0001zJ-00 for avt@ietf.org; Tue, 18 Nov 2003 12:48:35 -0500 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9p2/8.12.9) with ESMTP id hAIHlJJq007088; Tue, 18 Nov 2003 09:48:34 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9p2/8.12.9/Submit) id hAIHlJiZ007087; Tue, 18 Nov 2003 09:47:19 -0800 (PST) (envelope-from rsf) Message-Id: <6.0.1.1.1.20031118093909.032bf110@localhost> X-Sender: rsf@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 18 Nov 2003 09:46:08 -0800 To: Marshall Eubanks From: Ross Finlayson Subject: Re: [AVT] Ask open source information on RTP/RTSP Cc: david.liu@st.com, avt@ietf.org In-Reply-To: <8798AF09-19E7-11D8-B99E-003065FC3726@multicasttech.com> References: <8798AF09-19E7-11D8-B99E-003065FC3726@multicasttech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , >Note that rtsp is not generally done with multicast. This, for some odd reason, is a common misconception about RTSP. But it's incorrect. RTSP can also be used to play multicast streams. It is an excellent way for a player client to get the SDP information for an ongoing multicast stream - as an alternative to having the player client read a local ".sdp" file (for example). (See, for example, section 14.4 in RFC 2326.) People may be confused by the fact that (i) RTSP is not *necessary* for playing multicast streams (because a client could, instead, just read a local ".sdp" file), and (ii) Apple's "Darwin Streaming Server" does not serve multicast streams via RTSP. (OTOH, Apple's QuickTime Player can play multicast RTSP/RTP streams just fine.) Ross (who has developed several multicast applications that use RTSP). _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 13:21:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05427 for ; Tue, 18 Nov 2003 13:21:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMATK-00060X-Bb for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 13:21:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIIL6ZN023094 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 13:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMATF-0005zW-J3; Tue, 18 Nov 2003 13:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMASf-0005yJ-4I for avt@optimus.ietf.org; Tue, 18 Nov 2003 13:20:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05371 for ; Tue, 18 Nov 2003 13:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMASd-0002bG-00 for avt@ietf.org; Tue, 18 Nov 2003 13:20:23 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AMASb-0002aK-00 for avt@ietf.org; Tue, 18 Nov 2003 13:20:21 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id hAIIJVpM018368; Wed, 19 Nov 2003 03:19:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id hAIIJXO13487; Wed, 19 Nov 2003 03:19:33 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id hAIIJVl01852; Wed, 19 Nov 2003 03:19:31 +0900 (JST) Received: (from root@localhost) by vsm.ctmo.mei.co.jp (8.9.1/8.9.1) id DAA07564; Wed, 19 Nov 2003 03:19:31 +0900 (JST) Received: from chorus.isl.mei.co.jp(132.182.1.10) by vsm.ctmo.mei.co.jp via smap (V2.0) id ; Wed, 19 Nov 03 03:18:28 +0900 Received: by chorus.isl.mei.co.jp (8.9.3p2/5.9:4.9:isl-mx-com:20000204) id DAA26623; Wed, 19 Nov 2003 03:18:24 +0900 (JST) Received: by gmail-gw.isl.mei.co.jp (8.9.1/5.9:4.9:isl-mx-com:980326) id DAA02450; Wed, 19 Nov 2003 03:29:07 +0900 (JST) Message-ID: <087d01c3ae00$87f72560$8f67d33d@viola> From: "Y. Matsui" To: "Rey Jose" , "Colin Perkins" , "Dave Singer" Cc: , "IETF AVT WG" , "Magnus Westerlund" References: <8C7C642E667D8E4389197633C7D0E98301EFC1@lan-ex-01.panasonic.de> Subject: Re: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Date: Wed, 19 Nov 2003 03:19:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jose, Colin, > > On Tuesday, Nov 11, 2003, at 18:43 Europe/London, Dave Singer wrote: > > > At 17:27 +0100 11/11/03, Jose Rey wrote: > > >> Hi all, > > >> > > >> for those that did not attend the AVT session on Monday, there was a > > >> number of comments and useful feedback during the timed text > > >> presentation. > > ... > > >> The current approach makes sense if the text samples are regularly small > > >> and one or several of them fit into an RTP packet. Fragmentation would > > >> happen seldom. The 'pure alf approach' is, in general, the most correct > > >> one, and so also the one that requires more header definitions. If > > >> fragmentation is a rare event, this overhead may be not worth (?). The > > >> question to the group is pretty simple: which approach should be pursued? > > > > > > I think we can find a middle ground. I think that text samples over > > > 512 bytes are quite rare, and over 1400 bytes very rare indeed. I > > > don't mind going to a format which is less file-format centric, but I > > > don't think we should spend a lot of time optimizing fragmented text > > > access units. > > > > I think my question was more fundamental: do we need to support > > fragments at all? I think fragmentation should be supported, though it must be very rare. > > Or is it possible, assuming the text generator is > > aware of the network, that timed text samples can always be > > made it fit within the MTU? This could be a recommendation or guideline for text sample creators. I think it may not be needed to define heavy fragment header for only very rare case. However, the payload format for timed text should allow at least the simple fragment of text sample, in order to support the timed text specification without any restrictions. > > Are the large samples an innate property of text, or an artefact of the > > process which can be avoided by careful coding? A possible example of the large sample would be the ending roll of the movie. > for live streaming, on-the-fly MTU adaptation sounds reasonable; however > for the normal streaming scenario should every 3gp text file be > available as a streameable file in every possible MTU size? Best regards, Yoshinori Matsui Panasonic/Matsushita _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 13:29:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05816 for ; Tue, 18 Nov 2003 13:29:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAb0-0006WZ-OF for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 13:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIIT27l025054 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 13:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAaz-0006VP-P0; Tue, 18 Nov 2003 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAa6-0006Lp-9D for avt@optimus.ietf.org; Tue, 18 Nov 2003 13:28:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05724 for ; Tue, 18 Nov 2003 13:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAa4-0002k6-00 for avt@ietf.org; Tue, 18 Nov 2003 13:28:04 -0500 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx with esmtp (Exim 4.12) id 1AMAa3-0002jb-00 for avt@ietf.org; Tue, 18 Nov 2003 13:28:03 -0500 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hAIIRXnc004276 for ; Tue, 18 Nov 2003 10:27:33 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 18 Nov 2003 10:26:56 -0800 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id hAIIQwwx006658; Tue, 18 Nov 2003 10:26:58 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <087d01c3ae00$87f72560$8f67d33d@viola> References: <8C7C642E667D8E4389197633C7D0E98301EFC1@lan-ex-01.panasonic.de> <087d01c3ae00$87f72560$8f67d33d@viola> Date: Tue, 18 Nov 2003 10:25:05 -0800 To: "Y. Matsui" , Rey Jose , Colin Perkins From: Dave Singer Subject: Re: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt Cc: jan.vandermeer@philips.com, IETF AVT WG , Magnus Westerlund Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I agree with Matsui-san. Large samples (e.g. a "ticker tape" which scrolls a long time, or the ending credits of a movie, likewise) might happen, but are rare. The most we should do is allow you to find the string-length (and hence the beginning of the modifier boxes). This might be as naive as putting the beginning of the modifier boxes at a packet boundary -- which also means you might send them twice, or whatever (very half-formed thought, you understand). At 3:19 AM +0900 11/19/03, Y. Matsui wrote: >Hi Jose, Colin, > >> > On Tuesday, Nov 11, 2003, at 18:43 Europe/London, Dave Singer wrote: >> > > At 17:27 +0100 11/11/03, Jose Rey wrote: >> > >> Hi all, >> > >> >> > >> for those that did not attend the AVT session on Monday, there was a >> > >> number of comments and useful feedback during the timed text >> > >> presentation. >> > ... >> > >> The current approach makes sense if the text samples are >>regularly small >> > >> and one or several of them fit into an RTP packet. Fragmentation would >> > >> happen seldom. The 'pure alf approach' is, in general, the most correct >> > >> one, and so also the one that requires more header definitions. If >> > >> fragmentation is a rare event, this overhead may be not worth (?). The >> > >> question to the group is pretty simple: which approach should >>be pursued? >> > > >> > > I think we can find a middle ground. I think that text samples over >> > > 512 bytes are quite rare, and over 1400 bytes very rare indeed. I >> > > don't mind going to a format which is less file-format centric, but I >> > > don't think we should spend a lot of time optimizing fragmented text >> > > access units. >> > >> > I think my question was more fundamental: do we need to support >> > fragments at all? > >I think fragmentation should be supported, though it must be very rare. > >> > Or is it possible, assuming the text generator is >> > aware of the network, that timed text samples can always be >> > made it fit within the MTU? > >This could be a recommendation or guideline for text sample creators. > >I think it may not be needed to define heavy fragment header for only >very rare case. However, the payload format for timed text should >allow at least the simple fragment of text sample, in order to >support the timed text specification without any restrictions. > >> > Are the large samples an innate property of text, or an artefact of the >> > process which can be avoided by careful coding? > >A possible example of the large sample would be the ending roll of the movie. > >> for live streaming, on-the-fly MTU adaptation sounds reasonable; however >> for the normal streaming scenario should every 3gp text file be >> available as a streameable file in every possible MTU size? > >Best regards, >Yoshinori Matsui >Panasonic/Matsushita -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 14:19:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07999 for ; Tue, 18 Nov 2003 14:19:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBNT-0001Dr-No for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 14:19:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIJJ7fb004697 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 14:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBNN-0001Cl-Ne; Tue, 18 Nov 2003 14:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBNG-0001CP-Ji for avt@optimus.ietf.org; Tue, 18 Nov 2003 14:18:54 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07917 for ; Tue, 18 Nov 2003 14:18:42 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AMBAr-0000YL-WD; Tue, 18 Nov 2003 14:06:05 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Tue, 18 Nov 2003 14:06:05 -0500 Subject: [AVT] Protocol Action: 'The Secure Real-time Transport Protocol' to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'The Secure Real-time Transport Protocol ' 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 This specification defines a profile for the Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) called the Secure Real-time Transport Protocol (SRTP). The security goals for SRTP are to ensure: * the confidentiality of the RTP and RTCP payloads, and * the integrity of the entire RTP and RTCP packets, together with protection against replayed packets. These security services are optional and independent from each other, except that SRTCP integrity protection is mandatory (malicious or erroneous alteration of RTCP messages could disrupt the processing of the RTP stream). Other, functional, goals for the protocol are: * a framework that permits upgrading with new cryptographic transforms, * low bandwidth cost, i.e., a framework preserving RTP header compression efficiency, The provision of integrity is strongly recommended for most applications of SRTP. The mandatory to implement transform for this profile is AES counter mode, and there are risks associated with not using cryptographic integrity with it (see Section 9.5). Working Group Summary The initial drafts had a default in which integrity services were not the norm and in which SRTCP did not have mandatory integrity protection. There was a lengthy security review to ensure that the authentication tag is recommended to most RTP recommendations. Protocol Quality The specification was reviewed for the IESG by Eric Rescorla and Allison Mankin. Implementations that tested the specification were discussed by the working group. RFC Editor Notes: Add a reference to RFC 1750 to the end of paragraph 1 of Section 1.1. Section 3.2.3 - Old: If no valid context can be found for a packet corresponding to a certain context identifier, that packet MUST be discarded from further processing. New: If no valid context can be found for a packet corresponding to a certain context identifier, that packet MUST be discarded. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 15:15:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12223 for ; Tue, 18 Nov 2003 15:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCFb-0004wy-Ho for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 15:15:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIKF3cl018995 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 15:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCFZ-0004wD-DR; Tue, 18 Nov 2003 15:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMCEv-0004sD-8K for avt@optimus.ietf.org; Tue, 18 Nov 2003 15:14:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12099 for ; Tue, 18 Nov 2003 15:14:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMCEt-0004f4-00 for avt@ietf.org; Tue, 18 Nov 2003 15:14:19 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMCEt-0004f1-00 for avt@ietf.org; Tue, 18 Nov 2003 15:14:19 -0500 Received: from [12.161.102.11] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 2051610; Tue, 18 Nov 2003 15:14:15 -0500 Date: Tue, 18 Nov 2003 15:14:21 -0500 Subject: Re: [AVT] Ask open source information on RTP/RTSP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: david.liu@st.com, avt@ietf.org To: Ross Finlayson From: Marshall Eubanks In-Reply-To: <6.0.1.1.1.20031118093909.032bf110@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, November 18, 2003, at 12:46 PM, Ross Finlayson wrote: > >> Note that rtsp is not generally done with multicast. > > This, for some odd reason, is a common misconception about RTSP. But > it's incorrect. > > RTSP can also be used to play multicast streams. It is an excellent > way for a player client to get the SDP information for an ongoing > multicast stream - as an alternative to having the player client read > a local ".sdp" file (for example). > > (See, for example, section 14.4 in RFC 2326.) > > People may be confused by the fact that (i) RTSP is not *necessary* > for playing multicast streams (because a client could, instead, just > read a local ".sdp" file), and (ii) Apple's "Darwin Streaming Server" > does not serve multicast streams via RTSP. (OTOH, Apple's QuickTime > Player can play multicast RTSP/RTP streams just fine.) > I agree with you - I believe that RTSP was developed for multicast. However, neither Darwin nor Helix will serve this (at least, the last time I checked this) - and RealOne won't play them. > Ross (who has developed several multicast applications that > use RTSP). > > > Regards Marshall Eubanks T.M. Eubanks e-mail : marshall.eubanks@telesuite.com http://www.telesuite.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 18 16:08:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16221 for ; Tue, 18 Nov 2003 16:08:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMD53-00089R-0R for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 16:08:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIL8C84031318 for avt-archive@odin.ietf.org; Tue, 18 Nov 2003 16:08:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMD4u-00087m-E4; Tue, 18 Nov 2003 16:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMD4D-0007yG-Um for avt@optimus.ietf.org; Tue, 18 Nov 2003 16:07:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16124 for ; Tue, 18 Nov 2003 16:07:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMD4C-00066d-00 for avt@ietf.org; Tue, 18 Nov 2003 16:07:20 -0500 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AMD4B-00066Z-00 for avt@ietf.org; Tue, 18 Nov 2003 16:07:19 -0500 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [AVT] Ask open source information on RTP/RTSP Date: Tue, 18 Nov 2003 16:06:38 -0500 Message-ID: Thread-Topic: [AVT] Ask open source information on RTP/RTSP Thread-Index: AcOuEPcCZ+jySRawS2+Lq785lhIuJQABkiUA From: "Matthew Heaney" To: "Marshall Eubanks" , "Ross Finlayson" Cc: , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable TrueCast uses RTSP to SETUP and PLAY multicast sessions. We're in the process of adding SAP support, but right now a client gets SDP info via the DESCRIBE response. > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com]=20 > Sent: Tuesday, November 18, 2003 3:14 PM > To: Ross Finlayson > Cc: david.liu@st.com; avt@ietf.org > Subject: Re: [AVT] Ask open source information on RTP/RTSP >=20 >=20 >=20 > On Tuesday, November 18, 2003, at 12:46 PM, Ross Finlayson wrote: >=20 > > > >> Note that rtsp is not generally done with multicast. > > > > This, for some odd reason, is a common misconception about=20 > RTSP. But > > it's incorrect. > > > > RTSP can also be used to play multicast streams. It is an excellent > > way for a player client to get the SDP information for an ongoing=20 > > multicast stream - as an alternative to having the player=20 > client read=20 > > a local ".sdp" file (for example). > > > > (See, for example, section 14.4 in RFC 2326.) > > > > People may be confused by the fact that (i) RTSP is not *necessary* > > for playing multicast streams (because a client could,=20 > instead, just=20 > > read a local ".sdp" file), and (ii) Apple's "Darwin=20 > Streaming Server"=20 > > does not serve multicast streams via RTSP. (OTOH, Apple's=20 > QuickTime=20 > > Player can play multicast RTSP/RTP streams just fine.) > > >=20 > I agree with you - I believe that RTSP was developed for multicast. > However, neither Darwin nor Helix will serve this (at least, the last=20 > time > I checked this) - and RealOne won't play them. >=20 >=20 > > Ross (who has developed several multicast applications that=20 > > use RTSP). > > > > > > > Regards > Marshall Eubanks >=20 > T.M. Eubanks > e-mail : marshall.eubanks@telesuite.com > http://www.telesuite.com >=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 exim@www1.ietf.org Wed Nov 19 02:51:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07563 for ; Wed, 19 Nov 2003 02:51:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMN7L-00010P-OD for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 02:51:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ7pFpJ003768 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 02:51:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMN77-0000xW-J1; Wed, 19 Nov 2003 02:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMYj-0006rI-OJ for avt@optimus.ietf.org; Wed, 19 Nov 2003 02:15:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21980 for ; Wed, 19 Nov 2003 02:15:16 -0500 (EST) From: david.liu@st.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMMYf-0001lT-00 for avt@ietf.org; Wed, 19 Nov 2003 02:15:25 -0500 Received: from beta.dmz-ap.st.com ([138.198.100.35]) by ietf-mx with esmtp (Exim 4.12) id 1AMMYf-0001lF-00 for avt@ietf.org; Wed, 19 Nov 2003 02:15:25 -0500 Received: from zeta.dmz-ap.st.com (ns6.st.com [138.198.234.13]) by beta.dmz-ap.st.com (STMicroelectronics) with SMTP id A39F6DAA3 for ; Wed, 19 Nov 2003 07:14:53 +0000 (GMT) Received: by zeta.dmz-ap.st.com (STMicroelectronics, from userid 60012) id 9046E48F7; Wed, 19 Nov 2003 07:14:53 +0000 (GMT) Received: from hkux01.hkg.st.com (localhost [127.0.0.1]) by zeta.dmz-ap.st.com (STMicroelectronics) with ESMTP id 03182185D for ; Wed, 19 Nov 2003 07:14:53 +0000 (GMT) Received: from localhost (root@localhost) by hkux01.hkg.st.com (8.9.3 (PHNE_24419)/8.9.3) with ESMTP id PAA22492 for ; Wed, 19 Nov 2003 15:14:37 +0800 (SST) X-OpenMail-Hops: 1 Date: Wed, 19 Nov 2003 15:14:34 +0800 Message-Id: MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="Q.TXT" ;Creation-Date="Wed, 19 Nov 2003 12:01:27 +0800" ;Modification-Date="Wed, 19 Nov 2003 15:14:30 +0800" Subject: [AVT] Questions on RTP/RTSP server 2 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear experts, Question1: ~~~~~~~~~~ Whether Networkplay Inc's Helix Universal server and Microsoft Multimedia Server can support RTP/RTSP? I only know Apple Inc's Quicktime Streaming server can from Apple website. Question2: ~~~~~~~~~~ Whether Networkplay Inc's Helix Universal server only support raw MPEG2 TS steam? I know it supports Real Media, Windows Media, QuickTime, MPEG 4, MP3, and more from realnetwork web site. best regards david.liu _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 19 02:51:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07562 for ; Wed, 19 Nov 2003 02:51:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMN7L-00010Q-OW for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 02:51:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ7pFZe003770 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 02:51:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMN78-0000xe-G9; Wed, 19 Nov 2003 02:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMMjW-000811-26 for avt@optimus.ietf.org; Wed, 19 Nov 2003 02:26:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02715 for ; Wed, 19 Nov 2003 02:26:24 -0500 (EST) From: david.liu@st.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMMjS-0001wc-00 for avt@ietf.org; Wed, 19 Nov 2003 02:26:34 -0500 Received: from beta.dmz-ap.st.com ([138.198.100.35]) by ietf-mx with esmtp (Exim 4.12) id 1AMMjR-0001w0-00 for avt@ietf.org; Wed, 19 Nov 2003 02:26:33 -0500 Received: from zeta.dmz-ap.st.com (ns6.st.com [138.198.234.13]) by beta.dmz-ap.st.com (STMicroelectronics) with SMTP id D2D40DAA3 for ; Wed, 19 Nov 2003 07:26:03 +0000 (GMT) Received: by zeta.dmz-ap.st.com (STMicroelectronics, from userid 60012) id BF7B448F7; Wed, 19 Nov 2003 07:26:03 +0000 (GMT) Received: from hkux01.hkg.st.com (localhost [127.0.0.1]) by zeta.dmz-ap.st.com (STMicroelectronics) with ESMTP id 2E11B185D for ; Wed, 19 Nov 2003 07:26:03 +0000 (GMT) Received: from localhost (root@localhost) by hkux01.hkg.st.com (8.9.3 (PHNE_24419)/8.9.3) with ESMTP id PAA24188 for ; Wed, 19 Nov 2003 15:25:46 +0800 (SST) X-OpenMail-Hops: 1 Date: Wed, 19 Nov 2003 15:25:40 +0800 Message-Id: In-Reply-To: MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="C.TXT" ;Creation-Date="Wed, 19 Nov 2003 12:01:27 +0800" ;Modification-Date="Wed, 19 Nov 2003 15:25:37 +0800" Subject: [AVT] Re: Questions on RTP/RTSP server 2 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear Experts, Sorry I send latest letter by mistake. Please ignore it and help me to see my questions in this mail. Question1: ~~~~~~~~~~ Whether Networkplay Inc's Helix Universal server and Microsoft Multimedia Server can support RTP/RTSP? I only know Apple Inc's Quicktime Streaming server can do it from Apple website. Question2: ~~~~~~~~~~ Whether Networkplay Inc's Helix Universal server supports raw MPEG2 TS stream? I know it supports Real Media, Windows Media, QuickTime, MPEG 4, MP3, and more from realnetwork web site. But I only want to test RTP/RTSP client, so specific stream file format is unnecessary. Whether Apple Quicktime server and Darwin server can support raw MPEG2 TS stream? best regards david.liu ______________________________ Reply Separator _________________________________ Subject: Questions on RTP/RTSP server 2 Author: david liu at china,shenzhenmktg,sh Date: 2003-11-19 12:01 Dear experts, Question1: ~~~~~~~~~~ Whether Networkplay Inc's Helix Universal server and Microsoft Multimedia Server can support RTP/RTSP? I only know Apple Inc's Quicktime Streaming server can from Apple website. Question2: ~~~~~~~~~~ Whether Networkplay Inc's Helix Universal server only support raw MPEG2 TS steam? I know it supports Real Media, Windows Media, QuickTime, MPEG 4, MP3, and more from realnetwork web site. best regards david.liu _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 19 13:03:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00064 for ; Wed, 19 Nov 2003 13:03:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfd-0003wy-Q0 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 13:03:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJI3HQf015137 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 13:03:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfP-0003kQ-43; Wed, 19 Nov 2003 13:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWfC-0003jP-HL for avt@optimus.ietf.org; Wed, 19 Nov 2003 13:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29969; Wed, 19 Nov 2003 13:02:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWf7-00059R-00; Wed, 19 Nov 2003 13:02:45 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMWf6-00058T-00; Wed, 19 Nov 2003 13:02:45 -0500 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 hAJI2Dlf018001; Wed, 19 Nov 2003 13:02:13 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 19 Nov 2003 13:02:09 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 13:02:09 -0500 Message-ID: From: "Phelan, Tom" To: "'dccp@ietf.org'" Cc: "'avt@ietf.org'" , "'mmusic@ietf.org'" Date: Wed, 19 Nov 2003 13:02:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, I've sent "Strategies for Media Applications Using DCCP" to the Internet-Drafts archive. While we're waiting for it to be added, it's also available at http://www.phelan-4.com/dccp/draft-phelan-dccp-media-00.txt. The plan is that this will soon evolve into a general DCCP User Guide. Abstract: This document discusses strategies for using DCCP as the transport protocol for streaming media applications. Of particular interest is how media streams can be adapted to the smoothly varying transmit rate requirements of CCID3, or TCP-Friendly Rate Control (TFRC). Also explored is the resulting network behavior of streams using these strategies and the fairness between these streams and TCP-based streams. Comments will be appreciated. In particular, I make the suggestion that media apps should transmit at up to twice their nominal maximum rate, when DCCP allows it, in order to provide protection from competing TCP applications. I know that the first time I heard someone make a similar suggestion I was horrified, but as I developed the issues it seemed to be necessary. Reactions to this will be appreciated. Tom P. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 19 15:21:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09273 for ; Wed, 19 Nov 2003 15:21:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYpC-0004Z9-4Y for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 15:21:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKLIRB017550 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 15:21:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYp0-0004Xj-Dg; Wed, 19 Nov 2003 15:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYoN-0004Vz-Ha for avt@optimus.ietf.org; Wed, 19 Nov 2003 15:20:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09078; Wed, 19 Nov 2003 15:20:14 -0500 (EST) Message-Id: <200311192020.PAA09078@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Nov 2003 15:20:13 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-framing-contrans-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --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 : Framing RTP and RTCP Packets over Connection-Oriented Transport Author(s) : J. Lazzaro Filename : draft-ietf-avt-rtp-framing-contrans-00.txt Pages : 8 Date : 2003-11-19 This memo defines a method for framing Real Time Protocol (RTP) and Real Time Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP and TLS). The memo also defines how to specify the framing method in a session description. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing-contrans-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-framing-contrans-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-framing-contrans-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: <2003-11-19144109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-framing-contrans-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-framing-contrans-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144109.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 19 15:27:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09670 for ; Wed, 19 Nov 2003 15:27:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYuo-000599-Th for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 15:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKR6l1019683 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 15:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYul-00056G-HG; Wed, 19 Nov 2003 15:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYuX-00055c-Es for avt@optimus.ietf.org; Wed, 19 Nov 2003 15:26:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09590; Wed, 19 Nov 2003 15:26:36 -0500 (EST) Message-Id: <200311192026.PAA09590@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: avt@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Nov 2003 15:26:35 -0500 Subject: [AVT] I-D ACTION:draft-jones-avt-text-red-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Registration of the text/red MIME Sub-Type Author(s) : P. Jones Filename : draft-jones-avt-text-red-00.txt Pages : 5 Date : 2003-11-19 This document defines the text/red MIME sub-type. The packetization and usage of this MIME type, which is intended for use within SDP, is specified within RFC 2198 and RFC 2793, respectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-avt-text-red-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-jones-avt-text-red-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-jones-avt-text-red-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: <2003-11-19144532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jones-avt-text-red-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jones-avt-text-red-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144532.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 19 16:17:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09669 for ; Wed, 19 Nov 2003 15:27:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYuo-000598-T9 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 15:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKR6q8019684 for avt-archive@odin.ietf.org; Wed, 19 Nov 2003 15:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYuj-000568-Jl; Wed, 19 Nov 2003 15:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYtx-00053R-Bc for avt@optimus.ietf.org; Wed, 19 Nov 2003 15:26:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09559; Wed, 19 Nov 2003 15:25:59 -0500 (EST) Message-Id: <200311192025.PAA09559@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: avt@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Nov 2003 15:25:59 -0500 Subject: [AVT] I-D ACTION:draft-jones-avt-audio-t38-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration Author(s) : P. Jones Filename : draft-jones-avt-audio-t38-02.txt Pages : 6 Date : 2003-11-19 This document defines the MIME sub-type audio/t38. The packetization and usage of this MIME type, which is intended for use within SDP, is specified within ITU-T Recommendation T.38. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-jones-avt-audio-t38-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-jones-avt-audio-t38-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: <2003-11-19144348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jones-avt-audio-t38-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-jones-avt-audio-t38-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144348.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 02:34:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20781 for ; Thu, 20 Nov 2003 02:34:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjK0-00046p-KG for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 02:33:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK7XmJO015748 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 02:33:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjJH-00042d-Ao; Thu, 20 Nov 2003 02:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjIa-0003y2-1S for avt@optimus.ietf.org; Thu, 20 Nov 2003 02:32:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20664; Thu, 20 Nov 2003 02:32:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjIW-0005RK-00; Thu, 20 Nov 2003 02:32:16 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMjII-0005Qf-00; Thu, 20 Nov 2003 02:32:02 -0500 Received: from dynamicsoft.com ([63.113.46.66]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAK7VZca019587; Thu, 20 Nov 2003 02:31:35 -0500 (EST) Message-ID: <3FBC6DD3.5000705@dynamicsoft.com> Date: Thu, 20 Nov 2003 02:31:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: [MMUSIC] DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, I don't think this solution will be acceptable to many of the network providers of interactive voip services. Many of them are insistent on using low rate codecs, like g.723, in order to reduce the costs of capacity in their networks. Doubling the rate would defeat the purpose of using these low rate codecs in the first place. -Jonathan R. Phelan, Tom wrote: > Comments will be appreciated. In particular, I make the suggestion that > media apps should transmit at up to twice their nominal maximum rate, when > DCCP allows it, in order to provide protection from competing TCP > applications. I know that the first time I heard someone make a similar > suggestion I was horrified, but as I developed the issues it seemed to be > necessary. Reactions to this will be appreciated. > > Tom P. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 06:58:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00192 for ; Thu, 20 Nov 2003 06:58:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnRp-0002wU-V8 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 06:58:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKBw9Zr011306 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 06:58:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnRh-0002uH-Pq; Thu, 20 Nov 2003 06:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMnRd-0002u1-To for avt@optimus.ietf.org; Thu, 20 Nov 2003 06:57:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00126 for ; Thu, 20 Nov 2003 06:57:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMnRa-0001LD-00 for avt@ietf.org; Thu, 20 Nov 2003 06:57:54 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AMnRZ-0001Ki-00 for avt@ietf.org; Thu, 20 Nov 2003 06:57:54 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAKBukSs020101; Thu, 20 Nov 2003 12:56:46 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XFF6CJF8; Thu, 20 Nov 2003 12:56:46 +0100 Message-ID: <3FBCABFC.3020207@ericsson.com> Date: Thu, 20 Nov 2003 12:56:44 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oren Peleg CC: schulzrinne@cs.columbia.edu, casner@acm.org, avt@ietf.org, Sigal Cohen Subject: Re: [AVT] BYE RTCP packet schedule. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Oren, I think you should go re-read section 6.3.7 of RFC 3550. The relaxation you ask for exist. The described algorithm needs only to be used if there are more than 50 participants in the session. Most unicast sessions does not use more than 50 SSRCs in total. Secondly if on has a problem to wait the time the derivation algorithm results in then on MAY leave without sending a BYE packet. Quoted from section 6.3.7 of RFC 3550: o When the participant decides to leave the system, tp is reset to tc, the current time, members and pmembers are initialized to 1, initial is set to 1, we_sent is set to false, senders is set to 0, and avg_rtcp_size is set to the size of the compound BYE packet. The calculated interval T is computed. The BYE packet is then scheduled for time tn = tc + T. o Every time a BYE packet from another participant is received, members is incremented by 1 regardless of whether that participant exists in the member table or not, and when SSRC sampling is in use, regardless of whether or not the BYE SSRC would be included in the sample. members is NOT incremented when other RTCP packets or RTP packets are received, but only for BYE packets. Similarly, avg_rtcp_size is updated only for received BYE packets. senders is NOT updated when RTP packets arrive; it remains 0. o Transmission of the BYE packet then follows the rules for transmitting a regular RTCP packet, as above. Please look at the first bullet. In this you reset a lot of variables. This will result in that if no BYE packet you will based on bandwidth be able to send pretty quickly. If a min_rtcp_intreval is set then that will be halved due to the initial variable being set to true. Thus the restriction on sending BYE is only required to be used for group size over 50 participants. And even then the sending of a BYE is prioritized while still being limited to avoid feedback explosion at session endings. I hope this clarifies things for you. Best Regards Magnus Oren Peleg wrote: > According to RFC3550, the BYE packet should be sent no less then a > minimum interval from former RTCP packet. This can cause a resource > re-usage problems. Shouldn't it be more relaxed (at least for unicast > sessions) to enable sending an immediate BYE upon RTP session closing? > > Thanks, > > Oren Peleg > > Work phone No. : 03 - 5394167 > > Home phone No. : 03 - 5335913 > > Cell phone No. : 055 - 669613 > > Email : Oren.Peleg@audiocodes.com > -- 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 exim@www1.ietf.org Thu Nov 20 09:35:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06168 for ; Thu, 20 Nov 2003 09:35:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMptm-0005yJ-El for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 09:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEZA4p022908 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 09:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpte-0005wg-28; Thu, 20 Nov 2003 09:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpt4-0005tf-8u for avt@optimus.ietf.org; Thu, 20 Nov 2003 09:34:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06133 for ; Thu, 20 Nov 2003 09:34:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpt2-0003rY-00 for avt@ietf.org; Thu, 20 Nov 2003 09:34:24 -0500 Received: from h248s128a234n47.user.nortelnetworks.com ([47.234.128.248] helo=zcars04f.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpt1-0003rO-00 for avt@ietf.org; Thu, 20 Nov 2003 09:34:23 -0500 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAKEXZJ21649 for ; Thu, 20 Nov 2003 09:33:36 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XCDCSD5V; Thu, 20 Nov 2003 09:33:36 -0500 Received: from nortelnetworks.com (acart1cn.ca.nortel.com [47.129.129.64]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NPD4; Thu, 20 Nov 2003 09:33:36 -0500 Message-ID: <3FBCD0BF.7060201@nortelnetworks.com> Date: Thu, 20 Nov 2003 09:33:35 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] VBD vs. RFC 2833 vs. V.150.1 for V.21 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't know if this is the right place to ask this question, or whether I should go to Study Group 16. During my rewrite of RFC 2833 I'm trying to add a few words of advice about the encoding of V.21 used to carry the conversation, as opposed to control signalling. This comes up with respect to text telephones. V.21 is a frequency shift modem operating at up to 300 bits/s, one pure tone for "0", another for "1". By my rough calculations, using G.711 for carrying the tones takes more bandwidth than RFC 2833, assuming similar packetization intervals. I see it as: G.711 = 64000 bits/s. RFC 2833 events = 300 bit events/s x 16 bits/event report x 4 repetition factor = 19200 bits/s. There's more for redundancy headers, but this is the right order of magnitude. V.150.1 modem relay would be more compact still, since it reports octets rather than bits per sample. So the advice would be to carry V.21 as RFC 2833 events or use V.150.1 modem relay in preference to G.711. Do I have it right, or was I too careless with my calculations? Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 10:37:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09719 for ; Thu, 20 Nov 2003 10:37:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqrn-0001vo-5B for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 10:37:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKFbA5L007374 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 10:37:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqrf-0001qr-1j; Thu, 20 Nov 2003 10:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMqr0-0001pv-3t for avt@optimus.ietf.org; Thu, 20 Nov 2003 10:36:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09625; Thu, 20 Nov 2003 10:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMqqx-0004k7-00; Thu, 20 Nov 2003 10:36:19 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMqqx-0004jd-00; Thu, 20 Nov 2003 10:36:19 -0500 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 hAKFZmlf021027; Thu, 20 Nov 2003 10:35:48 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 10:35:36 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 10:35:36 -0500 Message-ID: From: "Phelan, Tom" To: "'Jonathan Rosenberg'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Date: Thu, 20 Nov 2003 10:35:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [MMUSIC] DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Jonathan, Thanks for the comments. The actual proposal is to send up to double the nominal transmit rate when there's available bandwidth, and to reduce the rate as necessary if there isn't enough bandwidth. This doubling is to allow fair sharing of the chokepoint bandwidth (between DCCP media apps and TCP apps), and to avoid what appears to me to be the potential for bullying from TCP applications that want to suck up all the bandwidth they can. It doesn't preclude using low-rate codecs, or mean that the access link must support the double rate for the connection to function well. This recommendation was meant for best-effort environments, where the voice traffic receives no special treatment, and must compete with TCP apps for network resources. I can see how this would require a network that gave special treatment to voice packets to provision double the capacity, though. This fairness problem is difficult. All of the research I'm familiar with approaches it from the direction of other apps being fair to TCP. I'm not aware of any other methods for ensuring that non-TCP apps get their fair share when competing with TCP. If you (or anyone else) knows of something I'd appreciate the pointer. Tom P. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, November 20, 2003 2:32 AM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: Re: [MMUSIC] DCCP Media Guide > > > Tom, > > I don't think this solution will be acceptable to many of the network > providers of interactive voip services. Many of them are insistent on > using low rate codecs, like g.723, in order to reduce the costs of > capacity in their networks. Doubling the rate would defeat > the purpose > of using these low rate codecs in the first place. > > -Jonathan R. > > Phelan, Tom wrote: > > > > Comments will be appreciated. In particular, I make the > suggestion that > > media apps should transmit at up to twice their nominal > maximum rate, when > > DCCP allows it, in order to provide protection from competing TCP > > applications. I know that the first time I heard someone > make a similar > > suggestion I was horrified, but as I developed the issues > it seemed to be > > necessary. Reactions to this will be appreciated. > > > > Tom P. > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 11:06:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10877 for ; Thu, 20 Nov 2003 11:06:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrJp-0003qv-Rz for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 11:06:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKG69Ei014805 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 11:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrJi-0003lk-Mf; Thu, 20 Nov 2003 11:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrJ8-0003fZ-2O for avt@optimus.ietf.org; Thu, 20 Nov 2003 11:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10786; Thu, 20 Nov 2003 11:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrJ5-0005CB-00; Thu, 20 Nov 2003 11:05:23 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMrJ4-0005BX-00; Thu, 20 Nov 2003 11:05:22 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27132; Thu, 20 Nov 2003 11:04:50 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17127; Thu, 20 Nov 2003 11:04:50 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 11:04:50 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B60F9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" , "'Jonathan Rosenberg'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 11:04:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , To me, this is just nonsense. I can't imagine anyone deploying such a solution. This is forcing the problem to fit the solution, and it's not the right way to go. If you want it to work, the protocol has to take the characteristics of the flows as they are, and not as you would like them to be. Real time media, streaming or realtime, is either constant bit rate, or pretty close to it. That's how it works. Our challenge is to make the protocols work with this data, not change the data, especially silly ideas like doubling the bandwidth. We make video telephones. They nominally send 4 megabits. Would you like us to double that, under any circumstances? I thought not. Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Thursday, November 20, 2003 10:36 AM > To: 'Jonathan Rosenberg' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Hi Jonathan, > > Thanks for the comments. The actual proposal is to send up > to double the > nominal transmit rate when there's available bandwidth, and > to reduce the > rate as necessary if there isn't enough bandwidth. This > doubling is to > allow fair sharing of the chokepoint bandwidth (between DCCP > media apps and > TCP apps), and to avoid what appears to me to be the > potential for bullying > from TCP applications that want to suck up all the bandwidth > they can. It > doesn't preclude using low-rate codecs, or mean that the > access link must > support the double rate for the connection to function well. > > This recommendation was meant for best-effort environments, > where the voice > traffic receives no special treatment, and must compete with > TCP apps for > network resources. I can see how this would require a > network that gave > special treatment to voice packets to provision double the > capacity, though. > > This fairness problem is difficult. All of the research I'm > familiar with > approaches it from the direction of other apps being fair to > TCP. I'm not > aware of any other methods for ensuring that non-TCP apps get > their fair > share when competing with TCP. If you (or anyone else) knows > of something > I'd appreciate the pointer. > > Tom P. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, November 20, 2003 2:32 AM > > To: Phelan, Tom > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > Tom, > > > > I don't think this solution will be acceptable to many of > the network > > providers of interactive voip services. Many of them are > insistent on > > using low rate codecs, like g.723, in order to reduce the costs of > > capacity in their networks. Doubling the rate would defeat > > the purpose > > of using these low rate codecs in the first place. > > > > -Jonathan R. > > > > Phelan, Tom wrote: > > > > > > > Comments will be appreciated. In particular, I make the > > suggestion that > > > media apps should transmit at up to twice their nominal > > maximum rate, when > > > DCCP allows it, in order to provide protection from competing TCP > > > applications. I know that the first time I heard someone > > make a similar > > > suggestion I was horrified, but as I developed the issues > > it seemed to be > > > necessary. Reactions to this will be appreciated. > > > > > > Tom P. > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.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 exim@www1.ietf.org Thu Nov 20 11:49:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13089 for ; Thu, 20 Nov 2003 11:49:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrzQ-0007WS-Er for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 11:49:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGn8R0028879 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 11:49:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrzK-0007TK-1x; Thu, 20 Nov 2003 11:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrys-0007SJ-GH for avt@optimus.ietf.org; Thu, 20 Nov 2003 11:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13032; Thu, 20 Nov 2003 11:48:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMryq-00062Z-00; Thu, 20 Nov 2003 11:48:32 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMryq-00062A-00; Thu, 20 Nov 2003 11:48:32 -0500 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 hAKGm2lf025590; Thu, 20 Nov 2003 11:48:02 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 11:47:49 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 11:47:49 -0500 Message-ID: From: "Phelan, Tom" To: "'Rosen, Brian'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 11:47:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Brian, Thanks for the comments. See inline ... Tom P. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, November 20, 2003 11:05 AM > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > To me, this is just nonsense. > I can't imagine anyone deploying such a solution. > > This is forcing the problem to fit the solution, and it's not > the right way to go. If you want it to work, the protocol > has to take the characteristics of the flows as they are, and not > as you would like them to be. Real time media, streaming or realtime, > is either constant bit rate, or pretty close to it. That's how it > works. Our challenge is to make the protocols work with this data, > not change the data, especially silly ideas like doubling the > bandwidth. > > We make video telephones. They nominally send 4 megabits. Would > you like us to double that, under any circumstances? > > I thought not. Would you prefer to be forced unnecessarily into packet loss and a lower encoding rate by greedy TCP applications? Or do you have another solution? I don't think I'm forcing the problem to fit the solution, just perhaps that the problem I'm trying to solve is different than you perceive. The problem that I'm trying to solve is how can an application that is content with a maximum bandwidth compete with TCP applications that are insatiably greedy, in a way that satisfies some concept of fairness in all directions? The solution that I see is to provide a buffer against TCP probing. This would involve sending more data than is nominally necessary. If the network has capacity for more than 4M bps, then why shouldn't a media app make use of it? A TCP app would. I must admit that my initial reactions to suggestions like this were very similar to yours. I encourage you to look at the draft for more detail on the issues that convinced me otherwise. > > Brian > > > -----Original Message----- > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > Sent: Thursday, November 20, 2003 10:36 AM > > To: 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Hi Jonathan, > > > > Thanks for the comments. The actual proposal is to send up > > to double the > > nominal transmit rate when there's available bandwidth, and > > to reduce the > > rate as necessary if there isn't enough bandwidth. This > > doubling is to > > allow fair sharing of the chokepoint bandwidth (between DCCP > > media apps and > > TCP apps), and to avoid what appears to me to be the > > potential for bullying > > from TCP applications that want to suck up all the bandwidth > > they can. It > > doesn't preclude using low-rate codecs, or mean that the > > access link must > > support the double rate for the connection to function well. > > > > This recommendation was meant for best-effort environments, > > where the voice > > traffic receives no special treatment, and must compete with > > TCP apps for > > network resources. I can see how this would require a > > network that gave > > special treatment to voice packets to provision double the > > capacity, though. > > > > This fairness problem is difficult. All of the research I'm > > familiar with > > approaches it from the direction of other apps being fair to > > TCP. I'm not > > aware of any other methods for ensuring that non-TCP apps get > > their fair > > share when competing with TCP. If you (or anyone else) knows > > of something > > I'd appreciate the pointer. > > > > Tom P. > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, November 20, 2003 2:32 AM > > > To: Phelan, Tom > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > Tom, > > > > > > I don't think this solution will be acceptable to many of > > the network > > > providers of interactive voip services. Many of them are > > insistent on > > > using low rate codecs, like g.723, in order to reduce the > costs of > > > capacity in their networks. Doubling the rate would defeat > > > the purpose > > > of using these low rate codecs in the first place. > > > > > > -Jonathan R. > > > > > > Phelan, Tom wrote: > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > suggestion that > > > > media apps should transmit at up to twice their nominal > > > maximum rate, when > > > > DCCP allows it, in order to provide protection from > competing TCP > > > > applications. I know that the first time I heard someone > > > make a similar > > > > suggestion I was horrified, but as I developed the issues > > > it seemed to be > > > > necessary. Reactions to this will be appreciated. > > > > > > > > Tom P. > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.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 exim@www1.ietf.org Thu Nov 20 12:26:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14578 for ; Thu, 20 Nov 2003 12:26:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsZD-0002A3-Vf for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 12:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHQ7Gd008301 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 12:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsZ8-000279-75; Thu, 20 Nov 2003 12:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsYY-00024k-Rc for avt@optimus.ietf.org; Thu, 20 Nov 2003 12:25:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14498; Thu, 20 Nov 2003 12:25:12 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsYX-0006f9-00; Thu, 20 Nov 2003 12:25:25 -0500 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 1AMsYW-0006f6-00; Thu, 20 Nov 2003 12:25:24 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id C907D2B4A2; Thu, 20 Nov 2003 18:25:23 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 5D10019C49; Thu, 20 Nov 2003 18:25:23 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 0899619C48; Thu, 20 Nov 2003 18:25:22 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id SAA03974; Thu, 20 Nov 2003 18:25:22 +0100 (MET) Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide To: "Phelan, Tom" , "'Rosen, Brian'" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 20 Nov 2003 18:22:39 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 20/11/2003 18:26:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Brian, all, It may provide some help in understanding the situation to describe your exemple as follows: * you send video at 4 Mb/s, good. * it happens that you are competing with (a lot of ) TCP AND that you want to be fair to it: * so when that happens you decrease your rate to 2 Mb/s for "a while" because otherwise you are not fair. * but at some moment you will want to come back up to 4 Mb/s right ? => the point is that the **only way** to know if you "can" do that, is to try it.... regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com To: "'Rosen, Brian'" cc: "'dccp@ietf.org'" "'avt@ietf.org'" "'mmusic@ietf.org'" "Phelan, Tom" (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Sent by: Classification: mmusic-admin@ietf.org 20/11/2003 17:47 Hi Brian, Thanks for the comments. See inline ... Tom P. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, November 20, 2003 11:05 AM > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > To me, this is just nonsense. > I can't imagine anyone deploying such a solution. > > This is forcing the problem to fit the solution, and it's not > the right way to go. If you want it to work, the protocol > has to take the characteristics of the flows as they are, and not > as you would like them to be. Real time media, streaming or realtime, > is either constant bit rate, or pretty close to it. That's how it > works. Our challenge is to make the protocols work with this data, > not change the data, especially silly ideas like doubling the > bandwidth. > > We make video telephones. They nominally send 4 megabits. Would > you like us to double that, under any circumstances? > > I thought not. Would you prefer to be forced unnecessarily into packet loss and a lower encoding rate by greedy TCP applications? Or do you have another solution? I don't think I'm forcing the problem to fit the solution, just perhaps that the problem I'm trying to solve is different than you perceive. The problem that I'm trying to solve is how can an application that is content with a maximum bandwidth compete with TCP applications that are insatiably greedy, in a way that satisfies some concept of fairness in all directions? The solution that I see is to provide a buffer against TCP probing. This would involve sending more data than is nominally necessary. If the network has capacity for more than 4M bps, then why shouldn't a media app make use of it? A TCP app would. I must admit that my initial reactions to suggestions like this were very similar to yours. I encourage you to look at the draft for more detail on the issues that convinced me otherwise. > > Brian > > > -----Original Message----- > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > Sent: Thursday, November 20, 2003 10:36 AM > > To: 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Hi Jonathan, > > > > Thanks for the comments. The actual proposal is to send up > > to double the > > nominal transmit rate when there's available bandwidth, and > > to reduce the > > rate as necessary if there isn't enough bandwidth. This > > doubling is to > > allow fair sharing of the chokepoint bandwidth (between DCCP > > media apps and > > TCP apps), and to avoid what appears to me to be the > > potential for bullying > > from TCP applications that want to suck up all the bandwidth > > they can. It > > doesn't preclude using low-rate codecs, or mean that the > > access link must > > support the double rate for the connection to function well. > > > > This recommendation was meant for best-effort environments, > > where the voice > > traffic receives no special treatment, and must compete with > > TCP apps for > > network resources. I can see how this would require a > > network that gave > > special treatment to voice packets to provision double the > > capacity, though. > > > > This fairness problem is difficult. All of the research I'm > > familiar with > > approaches it from the direction of other apps being fair to > > TCP. I'm not > > aware of any other methods for ensuring that non-TCP apps get > > their fair > > share when competing with TCP. If you (or anyone else) knows > > of something > > I'd appreciate the pointer. > > > > Tom P. > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, November 20, 2003 2:32 AM > > > To: Phelan, Tom > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > Tom, > > > > > > I don't think this solution will be acceptable to many of > > the network > > > providers of interactive voip services. Many of them are > > insistent on > > > using low rate codecs, like g.723, in order to reduce the > costs of > > > capacity in their networks. Doubling the rate would defeat > > > the purpose > > > of using these low rate codecs in the first place. > > > > > > -Jonathan R. > > > > > > Phelan, Tom wrote: > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > suggestion that > > > > media apps should transmit at up to twice their nominal > > > maximum rate, when > > > > DCCP allows it, in order to provide protection from > competing TCP > > > > applications. I know that the first time I heard someone > > > make a similar > > > > suggestion I was horrified, but as I developed the issues > > > it seemed to be > > > > necessary. Reactions to this will be appreciated. > > > > > > > > Tom P. > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 12:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14942 for ; Thu, 20 Nov 2003 12:36:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsiq-0002nO-Ma for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 12:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHa4Yf010699 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 12:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsio-0002lY-QZ; Thu, 20 Nov 2003 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMsiK-0002kO-2o for avt@optimus.ietf.org; Thu, 20 Nov 2003 12:35:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14901; Thu, 20 Nov 2003 12:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMsiI-0006oT-00; Thu, 20 Nov 2003 12:35:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMsiH-0006oK-00; Thu, 20 Nov 2003 12:35:29 -0500 Received: from dynamicsoft.com ([63.113.46.99]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAKHZ1ca019902; Thu, 20 Nov 2003 12:35:02 -0500 (EST) Message-ID: <3FBCFB41.8030908@dynamicsoft.com> Date: Thu, 20 Nov 2003 12:34:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: [MMUSIC] DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Phelan, Tom wrote: > Hi Jonathan, > > Thanks for the comments. The actual proposal is to send up to double the > nominal transmit rate when there's available bandwidth, and to reduce the > rate as necessary if there isn't enough bandwidth. This doubling is to > allow fair sharing of the chokepoint bandwidth (between DCCP media apps and > TCP apps), and to avoid what appears to me to be the potential for bullying > from TCP applications that want to suck up all the bandwidth they can. It > doesn't preclude using low-rate codecs, or mean that the access link must > support the double rate for the connection to function well. > > This recommendation was meant for best-effort environments, where the voice > traffic receives no special treatment, and must compete with TCP apps for > network resources. I can see how this would require a network that gave > special treatment to voice packets to provision double the capacity, though. What about networks where there is also a lot of UDP traffic? For example, these same networks providing voip traffic today. If I incrementally add dccp support, it seems like I will need to increase the provisioned capacity so I dont push out the UDP, no? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 12:59:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15976 for ; Thu, 20 Nov 2003 12:59:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt57-0004lR-Cq for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 12:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHx5Ml018307 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 12:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt54-0004jD-BF; Thu, 20 Nov 2003 12:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt4I-0004ee-Aq for avt@optimus.ietf.org; Thu, 20 Nov 2003 12:58:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15895; Thu, 20 Nov 2003 12:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMt4G-0007Cf-00; Thu, 20 Nov 2003 12:58:12 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMt4F-0007Bm-00; Thu, 20 Nov 2003 12:58:11 -0500 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 hAKHvflf029685; Thu, 20 Nov 2003 12:57:41 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 12:57:36 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 12:57:36 -0500 Message-ID: From: "Phelan, Tom" To: "'Jonathan Rosenberg'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" Date: Thu, 20 Nov 2003 12:57:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [MMUSIC] DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Jonathan, See inline ... Tom P. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, November 20, 2003 12:35 PM > To: Phelan, Tom > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > Phelan, Tom wrote: > > > Hi Jonathan, > > > > Thanks for the comments. The actual proposal is to send up > to double the > > nominal transmit rate when there's available bandwidth, and > to reduce the > > rate as necessary if there isn't enough bandwidth. This > doubling is to > > allow fair sharing of the chokepoint bandwidth (between > DCCP media apps and > > TCP apps), and to avoid what appears to me to be the > potential for bullying > > from TCP applications that want to suck up all the > bandwidth they can. It > > doesn't preclude using low-rate codecs, or mean that the > access link must > > support the double rate for the connection to function well. > > > > This recommendation was meant for best-effort environments, > where the voice > > traffic receives no special treatment, and must compete > with TCP apps for > > network resources. I can see how this would require a > network that gave > > special treatment to voice packets to provision double the > capacity, though. > > What about networks where there is also a lot of UDP traffic? For > example, these same networks providing voip traffic today. If I > incrementally add dccp support, it seems like I will need to increase > the provisioned capacity so I dont push out the UDP, no? Yes, DCCP will behave towards UDP (and vice versa) pretty much the same as TCP behaves toward UDP. For streaming media apps following the guidelines in the DCCP Media Guide, it actually can be a little better than TCP versus UDP, because there is a maximum transmit rate. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 13:06:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16327 for ; Thu, 20 Nov 2003 13:06:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtBr-0005LX-G3 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 13:06:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKI637x020470 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 13:06:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtBp-0005JB-Rf; Thu, 20 Nov 2003 13:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtB0-0005EJ-SO for avt@optimus.ietf.org; Thu, 20 Nov 2003 13:05:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16230; Thu, 20 Nov 2003 13:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtAy-0007LF-00; Thu, 20 Nov 2003 13:05:08 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMtAy-0007KR-00; Thu, 20 Nov 2003 13:05:08 -0500 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 hAKI4clf000069; Thu, 20 Nov 2003 13:04:38 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 13:04:32 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 13:04:32 -0500 Message-ID: From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" , "Phelan, Tom" , "'Rosen, Brian'" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 13:04:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Phillipe, The situation I'm worried about is a little different than you describe. Say you have a 10M bps link, over which there's a 4M bps video stream and a long-lived TCP app. The TCP app will take the remaining 6M bps, and then push for more, which might cause the video stream to lose packets. The video stream then drops to 2M bps, and the TCP app expands to 8M bps. This hardly seems fair. The video app can protect itself from this by transmitting enough more than 4M bps to buffer itself against the TCP probes. In this case we'd come to a relatively steady state where both apps are sending roughly 5M bps. This seems reasonably fair to me, since the TCP app gets what it would get if it were competing with other TCP apps, and the video app gets to send at its full rate. Tom P. > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, November 20, 2003 12:23 PM > To: Phelan, Tom; 'Rosen, Brian' > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Brian, all, > > It may provide some help in understanding the situation > to describe your exemple as follows: > > * you send video at 4 Mb/s, good. > > * it happens that you are competing with (a lot of ) TCP > > AND that you want to be fair to it: > > * so when that happens you decrease your rate to 2 Mb/s for "a while" > because otherwise you are not fair. > > * but at some moment you will want to come back up to 4 Mb/s right ? > > => the point is that the **only way** to know if you "can" > do that, is to try it.... > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > > > > > > To: > "'Rosen, Brian'" > > cc: > "'dccp@ietf.org'" > > > "'avt@ietf.org'" > > > "'mmusic@ietf.org'" > > "Phelan, Tom" (bcc: > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > Subject: > RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > Sent by: > Classification: > > mmusic-admin@ietf.org > > > > > > 20/11/2003 17:47 > > > > > > > > > > > > > Hi Brian, > > Thanks for the comments. See inline ... > > Tom P. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, November 20, 2003 11:05 AM > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > To me, this is just nonsense. > > I can't imagine anyone deploying such a solution. > > > > This is forcing the problem to fit the solution, and it's not > > the right way to go. If you want it to work, the protocol > > has to take the characteristics of the flows as they are, and not > > as you would like them to be. Real time media, streaming > or realtime, > > is either constant bit rate, or pretty close to it. That's how it > > works. Our challenge is to make the protocols work with this data, > > not change the data, especially silly ideas like doubling the > > bandwidth. > > > > We make video telephones. They nominally send 4 megabits. Would > > you like us to double that, under any circumstances? > > > > I thought not. > > Would you prefer to be forced unnecessarily into packet loss > and a lower > encoding rate by greedy TCP applications? Or do you have > another solution? > > I don't think I'm forcing the problem to fit the solution, > just perhaps that > the problem I'm trying to solve is different than you > perceive. The problem > that I'm trying to solve is how can an application that is > content with a > maximum bandwidth compete with TCP applications that are > insatiably greedy, > in a way that satisfies some concept of fairness in all directions? > > The solution that I see is to provide a buffer against TCP > probing. This > would involve sending more data than is nominally necessary. > If the network > has capacity for more than 4M bps, then why shouldn't a media > app make use > of it? A TCP app would. > > I must admit that my initial reactions to suggestions like > this were very > similar to yours. I encourage you to look at the draft for > more detail on > the issues that convinced me otherwise. > > > > > Brian > > > > > -----Original Message----- > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > Sent: Thursday, November 20, 2003 10:36 AM > > > To: 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > Hi Jonathan, > > > > > > Thanks for the comments. The actual proposal is to send up > > > to double the > > > nominal transmit rate when there's available bandwidth, and > > > to reduce the > > > rate as necessary if there isn't enough bandwidth. This > > > doubling is to > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > media apps and > > > TCP apps), and to avoid what appears to me to be the > > > potential for bullying > > > from TCP applications that want to suck up all the bandwidth > > > they can. It > > > doesn't preclude using low-rate codecs, or mean that the > > > access link must > > > support the double rate for the connection to function well. > > > > > > This recommendation was meant for best-effort environments, > > > where the voice > > > traffic receives no special treatment, and must compete with > > > TCP apps for > > > network resources. I can see how this would require a > > > network that gave > > > special treatment to voice packets to provision double the > > > capacity, though. > > > > > > This fairness problem is difficult. All of the research I'm > > > familiar with > > > approaches it from the direction of other apps being fair to > > > TCP. I'm not > > > aware of any other methods for ensuring that non-TCP apps get > > > their fair > > > share when competing with TCP. If you (or anyone else) knows > > > of something > > > I'd appreciate the pointer. > > > > > > Tom P. > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > To: Phelan, Tom > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Tom, > > > > > > > > I don't think this solution will be acceptable to many of > > > the network > > > > providers of interactive voip services. Many of them are > > > insistent on > > > > using low rate codecs, like g.723, in order to reduce the > > costs of > > > > capacity in their networks. Doubling the rate would defeat > > > > the purpose > > > > of using these low rate codecs in the first place. > > > > > > > > -Jonathan R. > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > suggestion that > > > > > media apps should transmit at up to twice their nominal > > > > maximum rate, when > > > > > DCCP allows it, in order to provide protection from > > competing TCP > > > > > applications. I know that the first time I heard someone > > > > make a similar > > > > > suggestion I was horrified, but as I developed the issues > > > > it seemed to be > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > Tom P. > > > > > > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, NJ > > > 07054-2711 > > > > dynamicsoft > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 13:25:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17191 for ; Thu, 20 Nov 2003 13:25:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtUU-0007H7-Rf for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 13:25:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKIPIoV027964 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 13:25:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtUH-0007DS-Qg; Thu, 20 Nov 2003 13:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtTT-00071u-5E for avt@optimus.ietf.org; Thu, 20 Nov 2003 13:24:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17155; Thu, 20 Nov 2003 13:24:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtTQ-0007gD-00; Thu, 20 Nov 2003 13:24:12 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMtTQ-0007fj-00; Thu, 20 Nov 2003 13:24:12 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA01823; Thu, 20 Nov 2003 13:23:39 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07827; Thu, 20 Nov 2003 13:23:39 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 13:23:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B60FC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 13:23:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I have looked carefully at the drafts. I think I understand what the proposal is, and how it works. I'll even agree that it might do what you think it will do, but I suspect that my device will cause a heck of a lot more congestion to the network if I run the video streams on DCCP than if I leave it on UDP. I think the solution will be much worse than the problem. The solution is just plain broken, in my opinion. The real, hard, problem is that there probably is no good solution, short of fixing TCP, or treating real time data differently (ie QoS) in the router. Like it or not, RTP is not appropriate for what we usually call "best effort", but the problem with that statement is that it's not really true that we need something more than for the network to use its' best effort to deliver the traffic. What is true is that other streams have to deal better with CBR data than they do. It is TCP that is broken. I don't think there is any way around that. TCP makes an assumption that is invalid when real time media is part of the traffic mix. There are so many problems with DCCP applied to real time media (this one, slow start,...), that I think we should just stop believing that DCCP is appropriate for RTP. A specific comment to your message below is that if we send more data than 4Mbit, it is just filler. We cannot "make use of it". We can just congest the network more than we do. As you might realize, we already have problems putting 4M into the network. More is not better in this case. Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Thursday, November 20, 2003 11:48 AM > To: 'Rosen, Brian' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Hi Brian, > > Thanks for the comments. See inline ... > > Tom P. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, November 20, 2003 11:05 AM > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > To me, this is just nonsense. > > I can't imagine anyone deploying such a solution. > > > > This is forcing the problem to fit the solution, and it's not > > the right way to go. If you want it to work, the protocol > > has to take the characteristics of the flows as they are, and not > > as you would like them to be. Real time media, streaming > or realtime, > > is either constant bit rate, or pretty close to it. That's how it > > works. Our challenge is to make the protocols work with this data, > > not change the data, especially silly ideas like doubling the > > bandwidth. > > > > We make video telephones. They nominally send 4 megabits. Would > > you like us to double that, under any circumstances? > > > > I thought not. > > Would you prefer to be forced unnecessarily into packet loss > and a lower > encoding rate by greedy TCP applications? Or do you have > another solution? > > I don't think I'm forcing the problem to fit the solution, > just perhaps that > the problem I'm trying to solve is different than you > perceive. The problem > that I'm trying to solve is how can an application that is > content with a > maximum bandwidth compete with TCP applications that are > insatiably greedy, > in a way that satisfies some concept of fairness in all directions? > > The solution that I see is to provide a buffer against TCP > probing. This > would involve sending more data than is nominally necessary. > If the network > has capacity for more than 4M bps, then why shouldn't a media > app make use > of it? A TCP app would. > > I must admit that my initial reactions to suggestions like > this were very > similar to yours. I encourage you to look at the draft for > more detail on > the issues that convinced me otherwise. > > > > > Brian > > > > > -----Original Message----- > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > Sent: Thursday, November 20, 2003 10:36 AM > > > To: 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > Hi Jonathan, > > > > > > Thanks for the comments. The actual proposal is to send up > > > to double the > > > nominal transmit rate when there's available bandwidth, and > > > to reduce the > > > rate as necessary if there isn't enough bandwidth. This > > > doubling is to > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > media apps and > > > TCP apps), and to avoid what appears to me to be the > > > potential for bullying > > > from TCP applications that want to suck up all the bandwidth > > > they can. It > > > doesn't preclude using low-rate codecs, or mean that the > > > access link must > > > support the double rate for the connection to function well. > > > > > > This recommendation was meant for best-effort environments, > > > where the voice > > > traffic receives no special treatment, and must compete with > > > TCP apps for > > > network resources. I can see how this would require a > > > network that gave > > > special treatment to voice packets to provision double the > > > capacity, though. > > > > > > This fairness problem is difficult. All of the research I'm > > > familiar with > > > approaches it from the direction of other apps being fair to > > > TCP. I'm not > > > aware of any other methods for ensuring that non-TCP apps get > > > their fair > > > share when competing with TCP. If you (or anyone else) knows > > > of something > > > I'd appreciate the pointer. > > > > > > Tom P. > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > To: Phelan, Tom > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Tom, > > > > > > > > I don't think this solution will be acceptable to many of > > > the network > > > > providers of interactive voip services. Many of them are > > > insistent on > > > > using low rate codecs, like g.723, in order to reduce the > > costs of > > > > capacity in their networks. Doubling the rate would defeat > > > > the purpose > > > > of using these low rate codecs in the first place. > > > > > > > > -Jonathan R. > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > suggestion that > > > > > media apps should transmit at up to twice their nominal > > > > maximum rate, when > > > > > DCCP allows it, in order to provide protection from > > competing TCP > > > > > applications. I know that the first time I heard someone > > > > make a similar > > > > > suggestion I was horrified, but as I developed the issues > > > > it seemed to be > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > Tom P. > > > > > > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, NJ > > > 07054-2711 > > > > dynamicsoft > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.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 > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 13:46:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18052 for ; Thu, 20 Nov 2003 13:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtol-0000LI-HD for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 13:46:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKIkF85001269 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 13:46:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtoZ-0000HN-46; Thu, 20 Nov 2003 13:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMto8-0000Dw-ON for avt@optimus.ietf.org; Thu, 20 Nov 2003 13:45:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17972; Thu, 20 Nov 2003 13:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMto6-0000CU-00; Thu, 20 Nov 2003 13:45:34 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AMto5-0000C8-00; Thu, 20 Nov 2003 13:45:33 -0500 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 hAKIj3lf002630; Thu, 20 Nov 2003 13:45:03 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 20 Nov 2003 13:44:57 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 13:44:57 -0500 Message-ID: From: "Phelan, Tom" To: "'Rosen, Brian'" , "Phelan, Tom" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 13:44:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Brian, I have sympathy for your opinion. I despair about the possibilities of changing TCP or getting widespread deployment of suitable QoS mechanisms, though, so I'm not quite ready to give up on DCCP yet ... Tom P. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, November 20, 2003 1:24 PM > To: 'Phelan, Tom' > Cc: 'dccp@ietf.org'; 'avt@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > I have looked carefully at the drafts. I think I understand what > the proposal is, and how it works. I'll even agree that it might > do what you think it will do, but I suspect that my device will > cause a heck of a lot more congestion to the network if I run the > video streams on DCCP than if I leave it on UDP. I think the > solution will be much worse than the problem. > > The solution is just plain broken, in my opinion. The real, hard, > problem is that there probably is no good solution, short of fixing > TCP, or treating real time data differently (ie QoS) in the router. > Like it or not, RTP is not appropriate for what we usually call > "best effort", but the problem with that statement is that it's not > really true that we need something more than for the network to use > its' best effort to deliver the traffic. What is true is that other > streams have to deal better with CBR data than they do. It is TCP > that is broken. I don't think there is any way around that. > TCP makes an assumption that is invalid when real time media is part > of the traffic mix. > > There are so many problems with DCCP applied to real time media (this > one, slow start,...), that I think we should just stop believing that > DCCP is appropriate for RTP. > > A specific comment to your message below is that if we send more data > than 4Mbit, it is just filler. We cannot "make use of it". We can > just congest the network more than we do. As you might realize, > we already have problems putting 4M into the network. More is not > better in this case. > > Brian > > > -----Original Message----- > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > Sent: Thursday, November 20, 2003 11:48 AM > > To: 'Rosen, Brian' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Hi Brian, > > > > Thanks for the comments. See inline ... > > > > Tom P. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Thursday, November 20, 2003 11:05 AM > > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > To me, this is just nonsense. > > > I can't imagine anyone deploying such a solution. > > > > > > This is forcing the problem to fit the solution, and it's not > > > the right way to go. If you want it to work, the protocol > > > has to take the characteristics of the flows as they are, and not > > > as you would like them to be. Real time media, streaming > > or realtime, > > > is either constant bit rate, or pretty close to it. > That's how it > > > works. Our challenge is to make the protocols work with > this data, > > > not change the data, especially silly ideas like doubling the > > > bandwidth. > > > > > > We make video telephones. They nominally send 4 megabits. Would > > > you like us to double that, under any circumstances? > > > > > > I thought not. > > > > Would you prefer to be forced unnecessarily into packet loss > > and a lower > > encoding rate by greedy TCP applications? Or do you have > > another solution? > > > > I don't think I'm forcing the problem to fit the solution, > > just perhaps that > > the problem I'm trying to solve is different than you > > perceive. The problem > > that I'm trying to solve is how can an application that is > > content with a > > maximum bandwidth compete with TCP applications that are > > insatiably greedy, > > in a way that satisfies some concept of fairness in all directions? > > > > The solution that I see is to provide a buffer against TCP > > probing. This > > would involve sending more data than is nominally necessary. > > If the network > > has capacity for more than 4M bps, then why shouldn't a media > > app make use > > of it? A TCP app would. > > > > I must admit that my initial reactions to suggestions like > > this were very > > similar to yours. I encourage you to look at the draft for > > more detail on > > the issues that convinced me otherwise. > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > > Sent: Thursday, November 20, 2003 10:36 AM > > > > To: 'Jonathan Rosenberg' > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Hi Jonathan, > > > > > > > > Thanks for the comments. The actual proposal is to send up > > > > to double the > > > > nominal transmit rate when there's available bandwidth, and > > > > to reduce the > > > > rate as necessary if there isn't enough bandwidth. This > > > > doubling is to > > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > > media apps and > > > > TCP apps), and to avoid what appears to me to be the > > > > potential for bullying > > > > from TCP applications that want to suck up all the bandwidth > > > > they can. It > > > > doesn't preclude using low-rate codecs, or mean that the > > > > access link must > > > > support the double rate for the connection to function well. > > > > > > > > This recommendation was meant for best-effort environments, > > > > where the voice > > > > traffic receives no special treatment, and must compete with > > > > TCP apps for > > > > network resources. I can see how this would require a > > > > network that gave > > > > special treatment to voice packets to provision double the > > > > capacity, though. > > > > > > > > This fairness problem is difficult. All of the research I'm > > > > familiar with > > > > approaches it from the direction of other apps being fair to > > > > TCP. I'm not > > > > aware of any other methods for ensuring that non-TCP apps get > > > > their fair > > > > share when competing with TCP. If you (or anyone else) knows > > > > of something > > > > I'd appreciate the pointer. > > > > > > > > Tom P. > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > > To: Phelan, Tom > > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > > > > Tom, > > > > > > > > > > I don't think this solution will be acceptable to many of > > > > the network > > > > > providers of interactive voip services. Many of them are > > > > insistent on > > > > > using low rate codecs, like g.723, in order to reduce the > > > costs of > > > > > capacity in their networks. Doubling the rate would defeat > > > > > the purpose > > > > > of using these low rate codecs in the first place. > > > > > > > > > > -Jonathan R. > > > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > > suggestion that > > > > > > media apps should transmit at up to twice their nominal > > > > > maximum rate, when > > > > > > DCCP allows it, in order to provide protection from > > > competing TCP > > > > > > applications. I know that the first time I heard someone > > > > > make a similar > > > > > > suggestion I was horrified, but as I developed the issues > > > > > it seemed to be > > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > > > Tom P. > > > > > > > > > > > > _______________________________________________ > > > > > > mmusic mailing list > > > > > > mmusic@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > > Chief Technology Officer Parsippany, NJ > > > > 07054-2711 > > > > > dynamicsoft > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > http://www.jdrosen.net PHONE: > > (973) 952-5000 > > > > > http://www.dynamicsoft.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 > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 14:31:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19935 for ; Thu, 20 Nov 2003 14:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuWL-00036L-Dj for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 14:31:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJVHRo011920 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 14:31:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuW6-000305-94; Thu, 20 Nov 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuVX-0002xs-5u for avt@optimus.ietf.org; Thu, 20 Nov 2003 14:30:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19784; Thu, 20 Nov 2003 14:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuVU-0000nJ-00; Thu, 20 Nov 2003 14:30:24 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMuVT-0000nG-00; Thu, 20 Nov 2003 14:30:23 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAKJU8LL005206; Thu, 20 Nov 2003 12:30:12 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hAKJLxF7031929; Thu, 20 Nov 2003 13:21:59 -0600 Message-ID: <3FBD1558.C10047DF@motorola.com> Date: Thu, 20 Nov 2003 13:26:16 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Phelan, Tom" CC: philippe.gentric@philips.com, "'Rosen, Brian'" , avt@ietf.org, dccp@ietf.org, mmusic@ietf.org, TSV WG list Subject: Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Tom, It seems to me that you are basically: 1) questioning the fairness of TCP itself and, 2) you want to do something in the app level to outmaneuver TCP so as to achieve your term of fairness. I am not convinced this is the right thing to do with DCCP. I remember similar issue was discussed on tsvwg list (I am cc'ing it). Maybe people in tsvwg can share their thoughts on this as well. regards, -Qiaobing "Phelan, Tom" wrote: > Hi Phillipe, > > The situation I'm worried about is a little different than you describe. > Say you have a 10M bps link, over which there's a 4M bps video stream and a > long-lived TCP app. The TCP app will take the remaining 6M bps, and then > push for more, which might cause the video stream to lose packets. The > video stream then drops to 2M bps, and the TCP app expands to 8M bps. This > hardly seems fair. > > The video app can protect itself from this by transmitting enough more than > 4M bps to buffer itself against the TCP probes. In this case we'd come to a > relatively steady state where both apps are sending roughly 5M bps. This > seems reasonably fair to me, since the TCP app gets what it would get if it > were competing with other TCP apps, and the video app gets to send at its > full rate. > > Tom P. > > > -----Original Message----- > > From: philippe.gentric@philips.com > > [mailto:philippe.gentric@philips.com] > > Sent: Thursday, November 20, 2003 12:23 PM > > To: Phelan, Tom; 'Rosen, Brian' > > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Brian, all, > > > > It may provide some help in understanding the situation > > to describe your exemple as follows: > > > > * you send video at 4 Mb/s, good. > > > > * it happens that you are competing with (a lot of ) TCP > > > > AND that you want to be fair to it: > > > > * so when that happens you decrease your rate to 2 Mb/s for "a while" > > because otherwise you are not fair. > > > > * but at some moment you will want to come back up to 4 Mb/s right ? > > > > => the point is that the **only way** to know if you "can" > > do that, is to try it.... > > > > regards, > > > > > > Philippe Gentric > > Chief Architect > > Philips Software > > philippe.gentric@philips.com > > http://www.software.philips.com > > > > > > > > > > > > > > > > > > To: > > "'Rosen, Brian'" > > > > cc: > > "'dccp@ietf.org'" > > > > > > "'avt@ietf.org'" > > > > > > "'mmusic@ietf.org'" > > > > "Phelan, Tom" (bcc: > > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > > > Subject: > > RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > Sent by: > > Classification: > > > > mmusic-admin@ietf.org > > > > > > > > > > > > 20/11/2003 17:47 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Brian, > > > > Thanks for the comments. See inline ... > > > > Tom P. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Thursday, November 20, 2003 11:05 AM > > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > To me, this is just nonsense. > > > I can't imagine anyone deploying such a solution. > > > > > > This is forcing the problem to fit the solution, and it's not > > > the right way to go. If you want it to work, the protocol > > > has to take the characteristics of the flows as they are, and not > > > as you would like them to be. Real time media, streaming > > or realtime, > > > is either constant bit rate, or pretty close to it. That's how it > > > works. Our challenge is to make the protocols work with this data, > > > not change the data, especially silly ideas like doubling the > > > bandwidth. > > > > > > We make video telephones. They nominally send 4 megabits. Would > > > you like us to double that, under any circumstances? > > > > > > I thought not. > > > > Would you prefer to be forced unnecessarily into packet loss > > and a lower > > encoding rate by greedy TCP applications? Or do you have > > another solution? > > > > I don't think I'm forcing the problem to fit the solution, > > just perhaps that > > the problem I'm trying to solve is different than you > > perceive. The problem > > that I'm trying to solve is how can an application that is > > content with a > > maximum bandwidth compete with TCP applications that are > > insatiably greedy, > > in a way that satisfies some concept of fairness in all directions? > > > > The solution that I see is to provide a buffer against TCP > > probing. This > > would involve sending more data than is nominally necessary. > > If the network > > has capacity for more than 4M bps, then why shouldn't a media > > app make use > > of it? A TCP app would. > > > > I must admit that my initial reactions to suggestions like > > this were very > > similar to yours. I encourage you to look at the draft for > > more detail on > > the issues that convinced me otherwise. > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > > Sent: Thursday, November 20, 2003 10:36 AM > > > > To: 'Jonathan Rosenberg' > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Hi Jonathan, > > > > > > > > Thanks for the comments. The actual proposal is to send up > > > > to double the > > > > nominal transmit rate when there's available bandwidth, and > > > > to reduce the > > > > rate as necessary if there isn't enough bandwidth. This > > > > doubling is to > > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > > media apps and > > > > TCP apps), and to avoid what appears to me to be the > > > > potential for bullying > > > > from TCP applications that want to suck up all the bandwidth > > > > they can. It > > > > doesn't preclude using low-rate codecs, or mean that the > > > > access link must > > > > support the double rate for the connection to function well. > > > > > > > > This recommendation was meant for best-effort environments, > > > > where the voice > > > > traffic receives no special treatment, and must compete with > > > > TCP apps for > > > > network resources. I can see how this would require a > > > > network that gave > > > > special treatment to voice packets to provision double the > > > > capacity, though. > > > > > > > > This fairness problem is difficult. All of the research I'm > > > > familiar with > > > > approaches it from the direction of other apps being fair to > > > > TCP. I'm not > > > > aware of any other methods for ensuring that non-TCP apps get > > > > their fair > > > > share when competing with TCP. If you (or anyone else) knows > > > > of something > > > > I'd appreciate the pointer. > > > > > > > > Tom P. > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > > To: Phelan, Tom > > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > > > > Tom, > > > > > > > > > > I don't think this solution will be acceptable to many of > > > > the network > > > > > providers of interactive voip services. Many of them are > > > > insistent on > > > > > using low rate codecs, like g.723, in order to reduce the > > > costs of > > > > > capacity in their networks. Doubling the rate would defeat > > > > > the purpose > > > > > of using these low rate codecs in the first place. > > > > > > > > > > -Jonathan R. > > > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > > suggestion that > > > > > > media apps should transmit at up to twice their nominal > > > > > maximum rate, when > > > > > > DCCP allows it, in order to provide protection from > > > competing TCP > > > > > > applications. I know that the first time I heard someone > > > > > make a similar > > > > > > suggestion I was horrified, but as I developed the issues > > > > > it seemed to be > > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > > > Tom P. > > > > > > > > > > > > _______________________________________________ > > > > > > mmusic mailing list > > > > > > mmusic@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > > Chief Technology Officer Parsippany, NJ > > > > 07054-2711 > > > > > dynamicsoft > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > http://www.jdrosen.net PHONE: > > (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group > > > > avt@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 15:28:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23977 for ; Thu, 20 Nov 2003 15:28:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvPK-0007l5-Vs for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 15:28:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKS6lC029819 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 15:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvPG-0007iE-0c; Thu, 20 Nov 2003 15:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvOu-0007fy-5R for avt@optimus.ietf.org; Thu, 20 Nov 2003 15:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23799; Thu, 20 Nov 2003 15:27:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvOs-0001md-00; Thu, 20 Nov 2003 15:27:38 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMvOs-0001m2-00; Thu, 20 Nov 2003 15:27:38 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06215; Thu, 20 Nov 2003 15:27:05 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25801; Thu, 20 Nov 2003 15:27:06 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 15:27:06 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6100@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'philippe.gentric@philips.com'" , "Phelan, Tom" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 15:27:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Phillipe You have made invalid assumptions: 1. That audio/video media data rates will be changed dynamically as network traffic changes. This is very unlikely. It may be that you get so much loss that you drop to a lower data rate, although I suspect that will be rare. When you do, you will never revert to the higher rate. This is because humans hate to see the change, and minimizing changes is more desirable than keeping average quality higher. 2. Real Time apps have no interest in being "fair". They are all or nothing. If you admit them to the network, you expect the streams to be maintained. If you can't maintain them, don't start them. They don't want to be fair to TCP, and they don't want to be fair to other RTP. They just want to send data at the rate they were advised to do by signalling. They can tolerate some loss. Misordering=loss. Duplicates= wasted bandwith. That's a whole lot different from TCP traffic. I can imagine working on protocols which allowed CBR and "best effort" traffic to better coexist, but I think it's only possible if the best effort traffic recognized the presence of the CBR traffic and reacted appropriately. Otherwise, you need to use QoS mechanisms to separate the traffic. Brian > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, November 20, 2003 12:23 PM > To: Phelan, Tom; 'Rosen, Brian' > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Brian, all, > > It may provide some help in understanding the situation > to describe your exemple as follows: > > * you send video at 4 Mb/s, good. > > * it happens that you are competing with (a lot of ) TCP > > AND that you want to be fair to it: > > * so when that happens you decrease your rate to 2 Mb/s for "a while" > because otherwise you are not fair. > > * but at some moment you will want to come back up to 4 Mb/s right ? > > => the point is that the **only way** to know if you "can" > do that, is to try it.... > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > > > > > > To: > "'Rosen, Brian'" > > cc: > "'dccp@ietf.org'" > > > "'avt@ietf.org'" > > > "'mmusic@ietf.org'" > > "Phelan, Tom" (bcc: > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > Subject: > RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > Sent by: > Classification: > > mmusic-admin@ietf.org > > > > > > 20/11/2003 17:47 > > > > > > > > > > > > > Hi Brian, > > Thanks for the comments. See inline ... > > Tom P. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, November 20, 2003 11:05 AM > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > To me, this is just nonsense. > > I can't imagine anyone deploying such a solution. > > > > This is forcing the problem to fit the solution, and it's not > > the right way to go. If you want it to work, the protocol > > has to take the characteristics of the flows as they are, and not > > as you would like them to be. Real time media, streaming > or realtime, > > is either constant bit rate, or pretty close to it. That's how it > > works. Our challenge is to make the protocols work with this data, > > not change the data, especially silly ideas like doubling the > > bandwidth. > > > > We make video telephones. They nominally send 4 megabits. Would > > you like us to double that, under any circumstances? > > > > I thought not. > > Would you prefer to be forced unnecessarily into packet loss > and a lower > encoding rate by greedy TCP applications? Or do you have > another solution? > > I don't think I'm forcing the problem to fit the solution, > just perhaps that > the problem I'm trying to solve is different than you > perceive. The problem > that I'm trying to solve is how can an application that is > content with a > maximum bandwidth compete with TCP applications that are > insatiably greedy, > in a way that satisfies some concept of fairness in all directions? > > The solution that I see is to provide a buffer against TCP > probing. This > would involve sending more data than is nominally necessary. > If the network > has capacity for more than 4M bps, then why shouldn't a media > app make use > of it? A TCP app would. > > I must admit that my initial reactions to suggestions like > this were very > similar to yours. I encourage you to look at the draft for > more detail on > the issues that convinced me otherwise. > > > > > Brian > > > > > -----Original Message----- > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > Sent: Thursday, November 20, 2003 10:36 AM > > > To: 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > Hi Jonathan, > > > > > > Thanks for the comments. The actual proposal is to send up > > > to double the > > > nominal transmit rate when there's available bandwidth, and > > > to reduce the > > > rate as necessary if there isn't enough bandwidth. This > > > doubling is to > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > media apps and > > > TCP apps), and to avoid what appears to me to be the > > > potential for bullying > > > from TCP applications that want to suck up all the bandwidth > > > they can. It > > > doesn't preclude using low-rate codecs, or mean that the > > > access link must > > > support the double rate for the connection to function well. > > > > > > This recommendation was meant for best-effort environments, > > > where the voice > > > traffic receives no special treatment, and must compete with > > > TCP apps for > > > network resources. I can see how this would require a > > > network that gave > > > special treatment to voice packets to provision double the > > > capacity, though. > > > > > > This fairness problem is difficult. All of the research I'm > > > familiar with > > > approaches it from the direction of other apps being fair to > > > TCP. I'm not > > > aware of any other methods for ensuring that non-TCP apps get > > > their fair > > > share when competing with TCP. If you (or anyone else) knows > > > of something > > > I'd appreciate the pointer. > > > > > > Tom P. > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > To: Phelan, Tom > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Tom, > > > > > > > > I don't think this solution will be acceptable to many of > > > the network > > > > providers of interactive voip services. Many of them are > > > insistent on > > > > using low rate codecs, like g.723, in order to reduce the > > costs of > > > > capacity in their networks. Doubling the rate would defeat > > > > the purpose > > > > of using these low rate codecs in the first place. > > > > > > > > -Jonathan R. > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > suggestion that > > > > > media apps should transmit at up to twice their nominal > > > > maximum rate, when > > > > > DCCP allows it, in order to provide protection from > > competing TCP > > > > > applications. I know that the first time I heard someone > > > > make a similar > > > > > suggestion I was horrified, but as I developed the issues > > > > it seemed to be > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > Tom P. > > > > > > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, NJ > > > 07054-2711 > > > > dynamicsoft > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 17:16:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03041 for ; Thu, 20 Nov 2003 17:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx5z-0000xR-Ol for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 17:16:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMGFDW003677 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 17:16:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx5n-0000rY-C7; Thu, 20 Nov 2003 17:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx4o-0000nV-PF for avt@optimus.ietf.org; Thu, 20 Nov 2003 17:15:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02892; Thu, 20 Nov 2003 17:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMx4k-00058N-00; Thu, 20 Nov 2003 17:14:58 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMx4j-00057U-00; Thu, 20 Nov 2003 17:14:58 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09118; Thu, 20 Nov 2003 17:14:24 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13114; Thu, 20 Nov 2003 17:14:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 17:14:24 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6102@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Caitlin Bestler'" , Qiaobing Xie Cc: mmusic@ietf.org, TSV WG list , "Phelan, Tom" , avt@ietf.org, dccp@ietf.org, philippe.gentric@philips.com Subject: RE: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 17:14:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The reason to "avoid" TCP friendly rate control is, at least so far, because there is no way yet proposed to do it without destroying the usability of the RTP flow. Part of the problem is that the only "rate control" that works is to negotiate an acceptable rate in the signalling before the stream starts. There really isn't any other way to change the rate, at least for interactive streams. For non-interactive streams, you can always buffer more, which allows you some short term variation. I don't think that any of the proposed mechanisms would actually work even in that case, but maybe there is a way to do something. Non interactive streams need CBR averaged over the buffer time. That can be up to seconds in some cases, hundreds of milliseconds in other cases, but over that interval, your goodput must equate to the transmit offer rate times the interval (some small loss rate acceptable). It would be nice if there was a way. I haven't seen one yet. Brian > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, November 20, 2003 5:02 PM > To: Qiaobing Xie > Cc: mmusic@ietf.org; 'Rosen, Brian'; TSV WG list; Phelan, Tom; > avt@ietf.org; dccp@ietf.org; philippe.gentric@philips.com > Subject: Re: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP > Media Guide > > > > On Nov 20, 2003, at 1:26 PM, Qiaobing Xie wrote: > > > Hi, Tom, > > > > It seems to me that you are basically: 1) questioning the > fairness of > > TCP itself > > and, 2) you want to do something in the app level to > outmaneuver TCP > > so as to > > achieve your term of fairness. > > > > I am not convinced this is the right thing to do with DCCP. > > > > I remember similar issue was discussed on tsvwg list (I am > cc'ing it). > > Maybe > > people in tsvwg can share their thoughts on this as well. > > > The fairness of TCP itself could use some questioning -- but I do not > believe that is a reason to evade TCP friendly rate control. > > Eventually, there should be a solution for proper support of > predictably > variable rate flows that have fixed delivery requirements. But that > solution > should be developed considering TCP, SCTP and DCCP as a whole. > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 17:49:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04454 for ; Thu, 20 Nov 2003 17:49:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxbk-00031K-UK for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 17:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMn4DB011609 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 17:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxbg-00030h-TI; Thu, 20 Nov 2003 17:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxba-00030O-8w for avt@optimus.ietf.org; Thu, 20 Nov 2003 17:48:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04442 for ; Thu, 20 Nov 2003 17:48:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMxbX-0005pC-00 for avt@ietf.org; Thu, 20 Nov 2003 17:48:51 -0500 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 1AMxbW-0005p9-00 for avt@ietf.org; Thu, 20 Nov 2003 17:48:51 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id hAKMmnb30365; Thu, 20 Nov 2003 23:48:49 +0100 (CET) From: "Gunnar Hellstrom" To: , "Tom Taylor" Cc: "Toip list" Subject: RE: [AVT] VBD vs. RFC 2833 vs. V.150.1 for V.21 Date: Thu, 20 Nov 2003 23:48:48 +0100 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.2910.0) Importance: Normal In-Reply-To: <3FBCD0BF.7060201@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, If you know that the V.21 is for text telephony, you would be even better off using RFC2793 for its transport, because it is textphone type independant, and can be converted to IP text telephony or any other kind of text telephony. But if you are in a big general borderline gateway between PSTN and IP, it may be hard to tell if V.21 signals are for text telephony or some kind of data communication. If the origin or destination is a SIP terminal UA, you may assume text telephony, and use RFC2793. But for gateway to gateway traffic it may be impossible to distinguish between the applications. For that case, the digital transports you mention may be used, and it seems that your conclusions are right. If there is a slightest risk ( >0.5%) of loosing packets when transmitting audio coded modem signals in G.711, redundancy must be used on G.711, and that is even more bandwidth consuming. There are textphones based on V.23 as well. They transmit at 1200 bits/s. I think that including V.23 bit events in RFC2833 would not be good bit-economy. Issues like this are studied in ITU-T Q.11/16 and Q.H/16. So, I think the question should be treated there, to find out if there is any benefit of RFC2833-code text telephony. The idea was touched last spring, but abandoned because of bad bit-economy and too tight coupling between the ends. If any such coding would be of interest, there could be a reason to study the carrierless modes separately: Baudot(1400/1800Hz FSK), EDT (=V.21 110 bits/s half duplex ) and DTMF. The carrier based V.21 (full duplex 300 bits/s), V.23, Bell 103, and Native V.18( based on V.21 full duplex ) may better be transported by some byte coded mechanism, like RFC2793 or some other relay coding. It is the intention of RFC2793bis to offer a transport for all these modes. So, I think that, after considering the alternatives, we would like to stick with that code for text transport. Agree? Regards Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom Taylor Sent: Thursday, November 20, 2003 3:34 PM To: avt@ietf.org Subject: [AVT] VBD vs. RFC 2833 vs. V.150.1 for V.21 I don't know if this is the right place to ask this question, or whether I should go to Study Group 16. During my rewrite of RFC 2833 I'm trying to add a few words of advice about the encoding of V.21 used to carry the conversation, as opposed to control signalling. This comes up with respect to text telephones. V.21 is a frequency shift modem operating at up to 300 bits/s, one pure tone for "0", another for "1". By my rough calculations, using G.711 for carrying the tones takes more bandwidth than RFC 2833, assuming similar packetization intervals. I see it as: G.711 = 64000 bits/s. RFC 2833 events = 300 bit events/s x 16 bits/event report x 4 repetition factor = 19200 bits/s. There's more for redundancy headers, but this is the right order of magnitude. V.150.1 modem relay would be more compact still, since it reports octets rather than bits per sample. So the advice would be to carry V.21 as RFC 2833 events or use V.150.1 modem relay in preference to G.711. Do I have it right, or was I too careless with my calculations? Tom Taylor _______________________________________________ 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 exim@www1.ietf.org Thu Nov 20 18:03:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05192 for ; Thu, 20 Nov 2003 18:03:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxpH-0003aA-PT for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 18:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKN33VK013747 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 18:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMxpE-0003Z8-VT; Thu, 20 Nov 2003 18:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwsh-00005g-Nv for avt@optimus.ietf.org; Thu, 20 Nov 2003 17:02:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02091; Thu, 20 Nov 2003 17:02:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwsf-0004qI-00; Thu, 20 Nov 2003 17:02:29 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1AMwse-0004pe-00; Thu, 20 Nov 2003 17:02:28 -0500 Received: from [192.168.0.101] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6A1D2246142; Thu, 20 Nov 2003 17:02:31 -0500 (EST) In-Reply-To: <3FBD1558.C10047DF@motorola.com> References: <3FBD1558.C10047DF@motorola.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, "'Rosen, Brian'" , TSV WG list , "Phelan, Tom" , avt@ietf.org, dccp@ietf.org, philippe.gentric@philips.com From: Caitlin Bestler Subject: Re: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 16:01:47 -0600 To: Qiaobing Xie X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 20, 2003, at 1:26 PM, Qiaobing Xie wrote: > Hi, Tom, > > It seems to me that you are basically: 1) questioning the fairness of > TCP itself > and, 2) you want to do something in the app level to outmaneuver TCP > so as to > achieve your term of fairness. > > I am not convinced this is the right thing to do with DCCP. > > I remember similar issue was discussed on tsvwg list (I am cc'ing it). > Maybe > people in tsvwg can share their thoughts on this as well. The fairness of TCP itself could use some questioning -- but I do not believe that is a reason to evade TCP friendly rate control. Eventually, there should be a solution for proper support of predictably variable rate flows that have fixed delivery requirements. But that solution should be developed considering TCP, SCTP and DCCP as a whole. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 20 19:07:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09466 for ; Thu, 20 Nov 2003 19:07:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMypI-0007ws-2I for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 19:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL078u8030545 for avt-archive@odin.ietf.org; Thu, 20 Nov 2003 19:07:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMypB-0007ue-48; Thu, 20 Nov 2003 19:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyor-0007u6-Ij for avt@optimus.ietf.org; Thu, 20 Nov 2003 19:06:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09449 for ; Thu, 20 Nov 2003 19:06:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyoo-0007NB-00 for avt@ietf.org; Thu, 20 Nov 2003 19:06:38 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AMyon-0007Mj-00 for avt@ietf.org; Thu, 20 Nov 2003 19:06:37 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAL063D00526; Thu, 20 Nov 2003 19:06:04 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W3H9AXZS; Thu, 20 Nov 2003 19:06:04 -0500 Received: from nortelnetworks.com (acart1cn.ca.nortel.com [47.129.129.64]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NPMG; Thu, 20 Nov 2003 19:06:04 -0500 Message-ID: <3FBD56EB.6090904@nortelnetworks.com> Date: Thu, 20 Nov 2003 19:06:03 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gunnar Hellstrom CC: avt@ietf.org, Toip list Subject: Re: [AVT] VBD vs. RFC 2833 vs. V.150.1 for V.21 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I forgot about RFC2793. I'll have a look, then add it to my words of advice. I'll be sending my draft out shortly to selected readers, once Henning gives the basic OK. I'll make sure you're on the list -- there seemed to be a few oversights in the definition of V.18-related events, and perhaps with my new words you'll spot the gaps or else suggest changes. Gunnar Hellstrom wrote: > Tom, > If you know that the V.21 is for text telephony, you would be even better > off using RFC2793 for its transport, because it is textphone type > independant, and can be converted to IP text telephony or any other kind of > text telephony. > > But if you are in a big general borderline gateway between PSTN and IP, it > may be hard to tell if V.21 signals are for text telephony or some kind of > data communication. If the origin or destination is a SIP terminal UA, you > may assume text telephony, and use RFC2793. > > But for gateway to gateway traffic it may be impossible to distinguish > between the applications. > For that case, the digital transports you mention may be used, and it seems > that your conclusions are right. > > If there is a slightest risk ( >0.5%) of loosing packets when transmitting > audio coded modem signals in G.711, redundancy must be used on G.711, and > that is even more bandwidth consuming. > > There are textphones based on V.23 as well. They transmit at 1200 bits/s. I > think that including V.23 bit events in RFC2833 would not be good > bit-economy. > > Issues like this are studied in ITU-T Q.11/16 and Q.H/16. So, I think the > question should be treated there, to find out if there is any benefit of > RFC2833-code text telephony. The idea was touched last spring, but abandoned > because of bad bit-economy and too tight coupling between the ends. > > If any such coding would be of interest, there could be a reason to study > the carrierless modes separately: Baudot(1400/1800Hz FSK), EDT (=V.21 110 > bits/s half duplex ) and DTMF. > The carrier based V.21 (full duplex 300 bits/s), V.23, Bell 103, and Native > V.18( based on V.21 full duplex ) may better be transported by some byte > coded mechanism, like RFC2793 or some other relay coding. > > It is the intention of RFC2793bis to offer a transport for all these modes. > So, I think that, after considering the alternatives, we would like to stick > with that code for text transport. > > Agree? > > Regards > > Gunnar > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom > Taylor > Sent: Thursday, November 20, 2003 3:34 PM > To: avt@ietf.org > Subject: [AVT] VBD vs. RFC 2833 vs. V.150.1 for V.21 > > > I don't know if this is the right place to ask this question, or whether > I should go to Study Group 16. During my rewrite of RFC 2833 I'm trying > to add a few words of advice about the encoding of V.21 used to carry > the conversation, as opposed to control signalling. This comes up with > respect to text telephones. > > V.21 is a frequency shift modem operating at up to 300 bits/s, one pure > tone for "0", another for "1". By my rough calculations, using G.711 > for carrying the tones takes more bandwidth than RFC 2833, assuming > similar packetization intervals. I see it as: > > G.711 = 64000 bits/s. > > RFC 2833 events = 300 bit events/s x 16 bits/event report x 4 repetition > factor = 19200 bits/s. There's more for redundancy headers, but this is > the right order of magnitude. > > V.150.1 modem relay would be more compact still, since it reports octets > rather than bits per sample. > > So the advice would be to carry V.21 as RFC 2833 events or use V.150.1 > modem relay in preference to G.711. Do I have it right, or was I too > careless with my calculations? > > Tom Taylor > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 21 02:13:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02431 for ; Fri, 21 Nov 2003 02:13:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN5Tb-0008Ma-LC for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 02:13:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL7DBse032149 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 02:13:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN5TR-0008Lg-Cl; Fri, 21 Nov 2003 02:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN5SW-0008HF-4w for avt@optimus.ietf.org; Fri, 21 Nov 2003 02:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01958 for ; Fri, 21 Nov 2003 02:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN5SS-0004yy-00 for avt@ietf.org; Fri, 21 Nov 2003 02:12:00 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AN5SS-0004yq-00 for avt@ietf.org; Fri, 21 Nov 2003 02:12:00 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hAL7C0BQ004561 for ; Fri, 21 Nov 2003 02:12:00 -0500 Message-ID: <034d01c3affe$c1c5de30$0401a8c0@berlin> From: "Paul E. Jones" To: References: <200311192026.PAA09590@ietf.org> Date: Fri, 21 Nov 2003 02:12:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] Re: I-D ACTION:draft-jones-avt-text-red-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I just wanted to bring this particular document to your attention. During the review of RFC 2793bis, it was proposed by several folks that we extract the text/red MIME sub-type registration from that document and publish it as a separate document. Thus, I've put for this individual contribution honor those requests. You'll note that I made reference to RFC 2793. The rationale is that this registration should have already been done and we do not necessarily want the publication of the revisions RFC 2793 to hinder the registration of this MIME sub-type. In any case, I'm open to changing the references, especially if they're both published at about the same time. Please review this document and provide any comments. Thanks, Paul ----- Original Message ----- From: To: Cc: Sent: Wednesday, November 19, 2003 3:26 PM Subject: I-D ACTION:draft-jones-avt-text-red-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Registration of the text/red MIME Sub-Type > Author(s) : P. Jones > Filename : draft-jones-avt-text-red-00.txt > Pages : 5 > Date : 2003-11-19 > > This document defines the text/red MIME sub-type. The packetization > and usage of this MIME type, which is intended for use within SDP, is > specified within RFC 2198 and RFC 2793, respectively. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-avt-text-red-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-jones-avt-text-red-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-jones-avt-text-red-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 From exim@www1.ietf.org Fri Nov 21 05:27:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08419 for ; Fri, 21 Nov 2003 05:27:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8VJ-0005ZT-Eq for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 05:27:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALAR92j021415 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 05:27:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8VC-0005Yp-Fq; Fri, 21 Nov 2003 05:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8Ua-0005Y8-Af for avt@optimus.ietf.org; Fri, 21 Nov 2003 05:26:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08402 for ; Fri, 21 Nov 2003 05:26:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8UW-0007hA-00 for avt@ietf.org; Fri, 21 Nov 2003 05:26:20 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AN8UW-0007gp-00 for avt@ietf.org; Fri, 21 Nov 2003 05:26:20 -0500 Received: from oroluk ([130.209.244.201]:49210 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AN8U2-0000Sk-00; Fri, 21 Nov 2003 10:25:50 +0000 Date: Fri, 21 Nov 2003 10:25:47 +0000 Subject: Re: [avt] SV: RFC2793bis and byte orders and other details Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: "avt IETF" , , "Frank Shearar" To: "Gunnar Hellstrom" From: Colin Perkins In-Reply-To: Message-Id: <126DA03F-1C0D-11D8-BB4A-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday, Nov 14, 2003, at 03:44 Europe/London, Gunnar Hellstrom wrote: > In the avt meeting, the RFC2793bis RTP Payload for Text Conversation > was > accepted as an avt workgroup item. > I promised to produce draft-avt-rfc2793bis-00 out of > draft-hellstrom-avt-rfc2793bis-02 > The current version is found at: > http://www.ietf.org/internet-drafts/draft-hellstrom-avt-rfc2793bis- > 02.txt > > When I do that, I want to include actions on the comments so far. > > Therefore, I want to check the reaction on some suggestions. > > 1. Specify byte-order for the new T140block counter. ( motivation > below from > Frank Shearar ) > I doubt that it is advicable to specify byte order for one little > piece > of the packet. > I assume that byte order issues are enough covered centrally in RTP. > I would like to get comments on that assumption. You need to specify the byte order for the payload header, the RTP spec only defines the byte order for the standard RTP header. > 2. Open for other redundancy schemes than RFC2198, at least for the > audio/t140 format > Especially for the audio intermixed packetization audio/t140, there > might > be of interest to use any of the > FEC mechanisms to gain reliability. It may for example be desirable > to > use the same FEC mechanism for the > audio stream as for the interleaved text. The requirement to use > the same > clock frequency for text and audio in the audio/t140 medium may also > make it > hard to use RFC2198, because the maximum offset will not be long > enough to > cater for transmission only every 300 ms, when the clock frequency of > the > audio packetisation is used. ( for text/t140 it is 1000 Hz, and that > is a > suitable frequency to allow for redundancy. ) > I recommend that I insert wording that for audio/t140 , any suitable > FEC > packetisation can be used. Yes. > 3. IANA considerations > The following IANA registrations shall be included in the draft: > > register media types for MIME and SDP usage: > > text/t140 - already done > text/red > audio/t140 > > register the main media type for sdp usage > text > > register the attribute parameter > cps= > > Register the capability for capability registration. > text > > Anything more? The "text/red" registration is now a separate draft, otherwise these look appropriate. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 05:35:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08782 for ; Fri, 21 Nov 2003 05:35:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8cy-0006BG-1r for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 05:35:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALAZ3PW023710 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 05:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8cu-00069B-O8; Fri, 21 Nov 2003 05:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8cC-00060q-OB for avt@optimus.ietf.org; Fri, 21 Nov 2003 05:34:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08652 for ; Fri, 21 Nov 2003 05:34:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8c9-00001G-00 for avt@ietf.org; Fri, 21 Nov 2003 05:34:13 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AN8c8-0007nm-00 for avt@ietf.org; Fri, 21 Nov 2003 05:34:12 -0500 Received: from oroluk ([130.209.244.201]:49212 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AN8bf-0000W7-00; Fri, 21 Nov 2003 10:33:43 +0000 Date: Fri, 21 Nov 2003 10:33:40 +0000 Subject: Re: [AVT] HC over multihop / MPLS Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: avt@ietf.org To: "Lars-Erik Jonsson (LU/EAB)" From: Colin Perkins In-Reply-To: Message-Id: <2C68811E-1C0E-11D8-BB4A-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, Nov 12, 2003, at 19:45 Europe/London, Lars-Erik Jonsson (LU/EAB) wrote: > As I promised in the WG session, I'll try to share my thoughts on > the HC over multihop/MPLS issue. ... > However, the current draft refers to "VoIP Header Compression over > Multi-Hop > Paths", which is not the same thing. The draft clearly shows that > compression > over multihop paths is one thing, and compression over MPLS another. > Further, > the draft takes a wider scope, and talks about header compression > generally, > not only ECRTP as the charter says. > > The following observations can be made: > * If work is to done for header compression over multihop and/or MPLS, > it > might make sense to not only address ECRTP. Certainly a header compression draft for MPLS should allow the negotiation of ROHC as an alternative to ECRTP. > * The only work in this that naturally could belong in the AVT WG > would be > to make sure ECRTP would work in these scenarios. In my > understanding, > this should already be the case with ECRTP (as well as some ROHC > profiles), > which is also indicated by the multihop req draft. I believe ECRTP would work, but one of the main purposes of the requirements capture process is to confirm this by getting MPLS and ECRTP folks in the same room and comparing the environments and assumptions. > * Header compression over multihop paths [ described by the multihop > req > draft as where one wants to avoid decompression/compression steps at > intermediate routers if the same compression scheme is supported at > both > incoming and outgoing interfaces ] is fully possible also without > any new > standards, as it would only be an implementation issue for each > intermediate > router to bind an incoming compressed stream to its corresponding > outgoing > compressed stream. In a path A->B->C, where B is the intermediate > router > negotiating use of e.g. CRTP with both A and C, it is fully up to the > implementation of B to avoid unnecessary decompression/compression > and > just forward compressed packets as-is ("CID routing"). Agreed, but it may be worthwhile writing a brief draft explaining the process, perhaps targeted at BCP or Informational? > * The only significant standardization work I can see is to define how > to > do header compression (e.g. IPHC, CRTP/ECRTP, ROHC) over MPLS, which > is > probably a work that would require some coordination with AVT and > ROHC > individuals, but the core of that work does not naturally belong to > ROHC or AVT. Would not the MPLS WG be a more proper place? Probably. The purpose of the requirements work is to understand the issues, and to decide if this is the right approach, or if we need to do something more. Cheers, -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 05:48:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09339 for ; Fri, 21 Nov 2003 05:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8pY-0006oU-Iy for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 05:48:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALAm4qF026189 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 05:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8pV-0006nj-FH; Fri, 21 Nov 2003 05:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8pI-0006nJ-Bl for avt@optimus.ietf.org; Fri, 21 Nov 2003 05:47:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09311 for ; Fri, 21 Nov 2003 05:47:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8pE-0000Ix-00 for avt@ietf.org; Fri, 21 Nov 2003 05:47:44 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AN8pE-0000Ia-00 for avt@ietf.org; Fri, 21 Nov 2003 05:47:44 -0500 Received: from oroluk ([130.209.244.201]:49285 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AN8ok-0000YW-00; Fri, 21 Nov 2003 10:47:14 +0000 Date: Fri, 21 Nov 2003 10:47:11 +0000 Subject: Re: [AVT] RTP MIB Extensions Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: , , "Bert Wijnen (E-mail)" To: "Romascanu, Dan (Dan)" From: Colin Perkins In-Reply-To: Message-Id: <0F795F73-1C10-11D8-BB4A-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, Nov 12, 2003, at 19:39 Europe/London, Romascanu, Dan (Dan) wrote: > Please allow me to make more clear my points expressed in the final > minutes of the AVT WG meeting today related to > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-clark-avt- > rtpmibv2-00.txt > > 1. This MIB includes extensions to the RTP MIB (RFC 2959) related to > RTCP-XR (RFC 3611). At the same time, there seems to be a need to > update RFC 2959 as result of the evolution of the Real Time Protocol > from RFC 1889 to RFC 3550. I strongly suggest to do this in two > separate MIBs separate documents: > > - a new RTP MIB, updating to RFC 2959 > > - a supplementary RTCP-XR MIB, with the MIB objects relevant for hosts > or monitors running RTCP-XR. > > This more modular and scalable structure would allow the two different > MIBs to be progressed separately, without creating a tight dependency > among them, and would allow adding other modules in the future. Yes, I think this is a good idea. > 2. There is a need for a better coordination, and possibly some > consolidation between the RTCP-XR MIB and work being done in other WGs > in the IETF - especially the RMON MIB WG > (http://www.ietf.cnri.reston.va.us/html.charters/rmonmib-charter.html) > work on Application Performance Monitoring and Real-Time Application > Monitoring to create a consistent framework for performance > monitoring, and avoid duplication. While RTCP-XR covers an important > aspect of media monitoring when RTP is used, it does not cover the > whole application space where RTP streams can be used. I would be glad > to provide more information, or work with the authors of the different > proposals in AVT to try to reach this goal. Thanks for the information - I'll look into it. If you would be willing to work with Alan Clark as the RTCP-XR MIB is developed, that would be helpful. Thanks! -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 06:53:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10811 for ; Fri, 21 Nov 2003 06:53:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9qS-0001lR-A6 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 06:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALBr4KM006748 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 06:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9qP-0001j3-CQ; Fri, 21 Nov 2003 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9pX-0001iP-Ku for avt@optimus.ietf.org; Fri, 21 Nov 2003 06:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10763; Fri, 21 Nov 2003 06:51:52 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9pT-00012S-00; Fri, 21 Nov 2003 06:52:03 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AN9pS-00012P-00; Fri, 21 Nov 2003 06:52:02 -0500 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 1586661363; Fri, 21 Nov 2003 12:51:56 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 4FF7819C52; Fri, 21 Nov 2003 12:51:55 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id D869019C4D; Fri, 21 Nov 2003 12:51:54 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id MAA23374; Fri, 21 Nov 2003 12:51:54 +0100 (MET) Subject: RE: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide To: "Rosen, Brian" Cc: avt@ietf.org, dccp@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 21 Nov 2003 12:49:14 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 21/11/2003 12:53:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Brian, you wrote: >The reason to "avoid" TCP friendly rate control is, at least so far, >because there is no way yet proposed to do it without destroying the >usability of the RTP flow. I aggree this is a chalenge and especially I think that the availability of codecs for which the rate can be rapidly changed over wide ranges is key. >Part of the problem is that the only "rate control" that works is to >negotiate an acceptable rate in the signalling before the stream starts. >There really isn't any other way to change the rate, at least for >interactive streams. This is where progress must be done: there is a need for signaling that the rate must change, during the streaming. >For non-interactive streams, you can always buffer more, which allows >you some short term variation. I don't think that any of the proposed >mechanisms would actually work even in that case, but maybe there is >a way to do something. Stream switching is a solution. regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 08:20:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12761 for ; Fri, 21 Nov 2003 08:20:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBCj-0005tF-8s for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 08:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALDK8Y6022589 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 08:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBCc-0005q1-1L; Fri, 21 Nov 2003 08:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBCX-0005pY-Fp for avt@optimus.ietf.org; Fri, 21 Nov 2003 08:19:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12754 for ; Fri, 21 Nov 2003 08:19:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBCW-00026k-00 for avt@ietf.org; Fri, 21 Nov 2003 08:19:56 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANBCV-00026h-00 for avt@ietf.org; Fri, 21 Nov 2003 08:19:55 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALDJL5m024565 for ; Fri, 21 Nov 2003 08:19:21 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALDJJ5m024521 for ; Fri, 21 Nov 2003 08:19:20 -0500 (EST) 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 Subject: RE: [AVT] RTP MIB Extensions Date: Fri, 21 Nov 2003 15:19:51 +0200 Message-ID: Thread-Topic: [AVT] RTP MIB Extensions Thread-Index: AcOwHNpwBwgRrvrZR9uvgn29vNvFSgAFIMFQ From: "Romascanu, Dan (Dan)" To: "Colin Perkins" Cc: , , "Bert Wijnen (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 1. From the point of view of the AVT WG, it looks to me that updating = the RTP MIB to reflect changes in RTC from RFC 1889 to RFC 3550 has = higher priority. 2. I met with Alan in Minneapolis, and made quite good progress. One = possible way to formalize the progress we made in the hallway is to work = together on a framework document for VoIP performance monitoring. = Hopefully we will have the time and resources to make this happen. Regards, Dan > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: 21 November, 2003 12:47 PM > To: Romascanu, Dan (Dan) > Cc: avt@ietf.org; mankin@psg.com; Bert Wijnen (E-mail) > Subject: Re: [AVT] RTP MIB Extensions >=20 >=20 > On Wednesday, Nov 12, 2003, at 19:39 Europe/London, Romascanu, Dan =20 > (Dan) wrote: > > Please allow me to make more clear my points expressed in=20 > the final =20 > > minutes of the AVT WG meeting today related to =20 > > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-clark-avt-=20 > > rtpmibv2-00.txt > > > > 1. This MIB includes extensions to the RTP MIB (RFC 2959)=20 > related to =20 > > RTCP-XR (RFC 3611). At the same time, there seems to be a need to =20 > > update RFC 2959 as result of the evolution of the Real Time=20 > Protocol =20 > > from RFC 1889 to RFC 3550. I strongly suggest to do this in two =20 > > separate MIBs separate documents: > > > > - a new RTP MIB, updating to RFC 2959 > > > > - a supplementary RTCP-XR MIB, with the MIB objects=20 > relevant for hosts =20 > > or monitors running RTCP-XR. > > > > This more modular and scalable structure would allow the=20 > two different =20 > > MIBs to be progressed separately, without creating a tight=20 > dependency =20 > > among them, and would allow adding other modules in the future. >=20 > Yes, I think this is a good idea. >=20 > > 2. There is a need for a better coordination, and possibly some =20 > > consolidation between the RTCP-XR MIB and work being done=20 > in other WGs =20 > > in the IETF - especially the RMON MIB WG =20 > >=20 > (http://www.ietf.cnri.reston.va.us/html.charters/rmonmib-chart er.html) =20 > work on Application Performance Monitoring and Real-Time Application =20 > Monitoring to create a consistent framework for performance =20 > monitoring, and avoid duplication. While RTCP-XR covers an important =20 > aspect of media monitoring when RTP is used, it does not cover the =20 > whole application space where RTP streams can be used. I would be glad = =20 > to provide more information, or work with the authors of the different = =20 > proposals in AVT to try to reach this goal. Thanks for the information - I'll look into it. If you would be willing = to work with Alan Clark as the RTCP-XR MIB is developed, that would be =20 helpful. Thanks! --=20 Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 08:44:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13330 for ; Fri, 21 Nov 2003 08:44:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBZq-0007Df-BT for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 08:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALDi2to027721 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 08:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBZp-0007CZ-0T; Fri, 21 Nov 2003 08:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBZj-0007C8-BJ for avt@optimus.ietf.org; Fri, 21 Nov 2003 08:43:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13307 for ; Fri, 21 Nov 2003 08:43:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBZi-0002Kl-00 for avt@ietf.org; Fri, 21 Nov 2003 08:43:54 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ANBZh-0002KW-00 for avt@ietf.org; Fri, 21 Nov 2003 08:43:53 -0500 Received: from pohnpei ([130.209.244.205]:49649 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ANBZC-00011d-00; Fri, 21 Nov 2003 13:43:22 +0000 Date: Fri, 21 Nov 2003 13:43:20 +0000 Subject: Re: [AVT] RTP MIB Extensions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: , , "Bert Wijnen (E-mail)" To: "Romascanu, Dan (Dan)" From: Colin Perkins In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday, Nov 21, 2003, at 13:19 Europe/London, Romascanu, Dan (Dan) wrote: > 1. From the point of view of the AVT WG, it looks to me that updating > the RTP MIB to reflect changes in RTC from RFC 1889 to RFC 3550 has > higher priority. If the MIB is used, then this certainly needs to be done. Maybe anyone on the list who uses the MIB would like to comment? > 2. I met with Alan in Minneapolis, and made quite good progress. One > possible way to formalize the progress we made in the hallway is to > work together on a framework document for VoIP performance monitoring. > Hopefully we will have the time and resources to make this happen. Good to hear, I look forward to seeing the result. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 10:11:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16705 for ; Fri, 21 Nov 2003 10:11:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCw8-0004dj-UE for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 10:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFB8wW017832 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 10:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCw4-0004cV-8m; Fri, 21 Nov 2003 10:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANCvh-0004bg-Bl for avt@optimus.ietf.org; Fri, 21 Nov 2003 10:10:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16615; Fri, 21 Nov 2003 10:10:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANCve-0003SL-00; Fri, 21 Nov 2003 10:10:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ANCve-0003S5-00; Fri, 21 Nov 2003 10:10:38 -0500 Received: from mramalho-w2k.cisco.com (dhcp-wtn-161-44-35-83.cisco.com [161.44.35.83]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALFA2xh026311; Fri, 21 Nov 2003 10:10:03 -0500 (EST) Message-Id: <4.3.2.7.2.20031121093326.00b6e458@mira-sjc5-e.cisco.com> X-Sender: mramalho@mira-sjc5-e.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Nov 2003 10:10:02 -0500 To: "Phelan, Tom" From: "Michael A. Ramalho" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Cc: "'Rosen, Brian'" , "'dccp@ietf.org'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 11:47 AM 11/20/2003 -0500, Phelan, Tom wrote: >I don't think I'm forcing the problem to fit the solution, just perhaps that >the problem I'm trying to solve is different than you perceive. The problem >that I'm trying to solve is how can an application that is content with a >maximum bandwidth compete with TCP applications that are insatiably greedy, >in a way that satisfies some concept of fairness in all directions? > >The solution that I see is to provide a buffer against TCP probing. This >would involve sending more data than is nominally necessary. If the network >has capacity for more than 4M bps, then why shouldn't a media app make use >of it? A TCP app would. I think this snippet captures the essence of the argument. An "insatiably greedy" TCP application has an infinite amount of data to send. And "fairness" in "TCP-land" is ONLY FAIRNESS IN INSTANTANEOUS BANDWIDTH ALLOCATION (across TCP/DCCP/SCTP connections/associations). This is historically how TCP has been viewed. But wait ... if you delay the "infinite amount of data" in the TCP socket .... what bad happens? Nothing, it just takes longer (from a "work conservation viewpoint") to send the data. Did TCP suffer? Well ... it got less work per unit time ... but nothing really bad occurred for the "insatiable TCP" case. Most real-time data is DELAY SENSITIVE. To real-time data ... it would be "fair" to delay some of the TCP data during it's bursts (like some video codecs have when a high-entropy scene change occurs). That is because TCP can afford to "wait a little longer" to get it's data across. The bursts are usually bounded in time (a talkspurt, a scene change, etc.) ... and TCP can usually afford to wait through these bursts. From the real-time application's perspective they are being "good citizens" by not using bandwidth when they don't need to (during VAD/silence or no video scene changes). Can't the TCP apps step aside for a moment and acknowledge their good citizenship? To be fair ... we really need to re-evaluate the issue of "fairness" capturing more than just an INSTANTANEOUS BANDWIDTH ALLOCATION dimension. Is it "fair" to slow down TCP more than present mechanisms allow? For a "insatiably greedy" TCP connection the answer may be yes. For a TCP session with a reasonably bounded amount of data the answer maybe no - because there is a linear relationship with how long the data will take to get to the other side and the slowdown rate. This is a really tough problem. Why this post? Simply because I'd desire each camp to widen their vision of what is "fair/right/best" from their own myopic point of view. TCP'ers should try to capture the spirit of Brian's comment ... that "forcing the problem to fit [TCP's view of] a solution" is not appropriate. And that is, in fact, what I perceive all the well-intentioned "TCP rate control" crowd to be doing here. Please widen your perspective of the problem. Then comment. Don't expect people like Brian to be happy with the "you must fit in to TCPs view of the world" when most of their real-time applications are already being good citizens (by not sending "all they can" when they don't have to). Do you like being further punished because you weren't greedy when you could have been? Michael Ramalho _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 10:41:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18352 for ; Fri, 21 Nov 2003 10:41:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDP9-0006Ck-Mc for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 10:41:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFf7RQ023847 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 10:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDP6-0006BO-Dn; Fri, 21 Nov 2003 10:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDOH-00069q-NJ for avt@optimus.ietf.org; Fri, 21 Nov 2003 10:40:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18215 for ; Fri, 21 Nov 2003 10:39:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDOF-0003pX-00 for avt@ietf.org; Fri, 21 Nov 2003 10:40:11 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ANDOE-0003pS-00 for avt@ietf.org; Fri, 21 Nov 2003 10:40:10 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALFe8Ss002737; Fri, 21 Nov 2003 16:40:09 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XF17HBR0; Fri, 21 Nov 2003 16:40:16 +0100 Message-ID: <3FBE31D6.2010602@ericsson.com> Date: Fri, 21 Nov 2003 16:40:06 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "Phelan, Tom" , "'avt@ietf.org'" Subject: Re: [AVT] RE: [MMUSIC] DCCP Media Guide References: <313680C9A886D511A06000204840E1CF070B6100@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B6100@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Brian, I don't think that the people working with stability of the network are sharing you view due to the implications that your claims results in. First, if a multi-media application transmitting data over a best-effort IP network, i.e. without any QoS guarantees across the whole net that its traffic will fit, it can definitely cause congestion collapse if the mix becomes most, media, little TCP. Please read draft-iab-congestion-01.txt for some discussion on this. Some comments to your assertions. Rosen, Brian wrote: > Phillipe > > You have made invalid assumptions: > 1. That audio/video media data rates will be changed dynamically > as network traffic changes. This is very unlikely. It may > be that you get so much loss that you drop to a lower data > rate, although I suspect that will be rare. When you do, > you will never revert to the higher rate. This is because > humans hate to see the change, and minimizing changes is > more desirable than keeping average quality higher. First you agree that it is possible to change the rate. Secondly I understand that the there are implications on switching rate, i.e. quality to often, however there are reasons for switching up when the quality gain of a switch if being possible to keep the new rate is clear. > > 2. Real Time apps have no interest in being "fair". They are all > or nothing. If you admit them to the network, you expect > the streams to be maintained. If you can't maintain them, > don't start them. They don't want to be fair to TCP, and > they > don't want to be fair to other RTP. They just want to send > data at the rate they were advised to do by signalling. > They can tolerate some loss. Misordering=loss. Duplicates= > wasted bandwith. That's a whole lot different from TCP > traffic. > Yes, I agree that the application has no interest in being fair. However using best effort networks requires one to being reasonably fair. If one are not, the combination of several of media application can totally destroy things for them self. > I can imagine working on protocols which allowed CBR and "best effort" > traffic to better coexist, but I think it's only possible if the best > effort traffic recognized the presence of the CBR traffic and reacted > appropriately. Otherwise, you need to use QoS mechanisms to separate > the traffic. What says that the media traffic is more important that the traffic going over TCP? 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 exim@www1.ietf.org Fri Nov 21 10:45:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18518 for ; Fri, 21 Nov 2003 10:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDSw-0006X7-CG for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 10:45:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFj2se025061 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 10:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDSu-0006VX-Gl; Fri, 21 Nov 2003 10:45:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDSl-0006V3-5Z for avt@optimus.ietf.org; Fri, 21 Nov 2003 10:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18480; Fri, 21 Nov 2003 10:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDSi-0003vC-00; Fri, 21 Nov 2003 10:44:48 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ANDSh-0003v9-00; Fri, 21 Nov 2003 10:44:48 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALFilSs004253; Fri, 21 Nov 2003 16:44:47 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XFF6ZG50; Fri, 21 Nov 2003 16:44:46 +0100 Message-ID: <3FBE32EC.5000400@ericsson.com> Date: Fri, 21 Nov 2003 16:44:44 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org, TSV WG list , avt@ietf.org, dccp@ietf.org CC: "Phelan, Tom" References: <3FBD1558.C10047DF@motorola.com> <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> In-Reply-To: <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] DCCP Media Guide - STOP crossposting Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Please don't crosspost to all these lists. It creates problems for the list managers and will fragment the discussion. As long as we are discussing issues related to media and DCCP please keep these topics on the AVT mailing list. Other DCCP related issues goes on the DCCP list. Best Regards 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 exim@www1.ietf.org Fri Nov 21 11:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20420 for ; Fri, 21 Nov 2003 11:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEGK-00014V-DM for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 11:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGa4Vm004113 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 11:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEGH-00013d-Lp; Fri, 21 Nov 2003 11:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEFW-000131-Bf for avt@optimus.ietf.org; Fri, 21 Nov 2003 11:35:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20384 for ; Fri, 21 Nov 2003 11:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEFV-0004bp-00 for avt@ietf.org; Fri, 21 Nov 2003 11:35:13 -0500 Received: from via-smtp3.imconline.net ([66.155.127.53]) by ietf-mx with esmtp (Exim 4.12) id 1ANEFU-0004bg-00 for avt@ietf.org; Fri, 21 Nov 2003 11:35:12 -0500 Received: from telchemy.com ([66.155.69.251]) by via-smtp3.imconline.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Nov 2003 11:34:31 -0500 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-8.03) id AF654002F2; Fri, 21 Nov 2003 11:37:57 -0500 Reply-To: From: "Alan Clark" To: "'Colin Perkins'" , "'Romascanu, Dan \(Dan\)'" Cc: , , "'Bert Wijnen \(E-mail\)'" Subject: RE: [AVT] RTP MIB Extensions Date: Fri, 21 Nov 2003 11:34:38 -0500 Message-ID: <004d01c3b04d$5c153550$6801a8c0@telchemy.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 21 Nov 2003 16:34:31.0371 (UTC) FILETIME=[56EAE1B0:01C3B04D] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin It looks as if there are three action items:- (i) General RTP MIB update - I'd be happy to contribute to this work but may not be the best one to lead it. (ii) RTCP XR MIB - I will trim down the draft submitted to the Minneapolis meeting and resubmit as an RTCP XR MIB draft within the next two weeks. Any offers of help/ input would be very welcome. (iii) VoIP fault/performance monitoring framework - as Dan mentioned, we did have some offline discussion on this and agreed to look at this jointly. I've already submitted a VoIP fault/performance management draft to TIA, we could start by refining that and then see if/ where in IETF would be the most appropriate place to introduce it. The document currently addresses the requirements for VoIP endpoints and sets out the range of possible functionality and QoS reporting mechanisms - basically proposing that VoIP endpoints should provide this type of functionality but not mandating any particular protocol. It could certainly be an informational draft to AVT. >From Dan's comments > 1. From the point of view of the AVT WG, it looks to me that updating > the RTP MIB to reflect changes in RTC from RFC 1889 to RFC 3550 has > higher priority. With regard to the relative priorities of (i) and (ii), I recall that there seemed to be no disagreement that the RTP MIB update was important but there was no suggestion that this was more or less important than progressing an RTCP XR based draft. There is considerable interest in using RTCP XR for VoIP fault/performance management and some definite expressed interest in seeing a MIB based on the RTCP XR metrics. Alan Clark -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin Perkins Sent: Friday, November 21, 2003 8:43 AM To: Romascanu, Dan (Dan) Cc: avt@ietf.org; mankin@psg.com; Bert Wijnen (E-mail) Subject: Re: [AVT] RTP MIB Extensions On Friday, Nov 21, 2003, at 13:19 Europe/London, Romascanu, Dan (Dan) wrote: > 1. From the point of view of the AVT WG, it looks to me that updating > the RTP MIB to reflect changes in RTC from RFC 1889 to RFC 3550 has > higher priority. If the MIB is used, then this certainly needs to be done. Maybe anyone on the list who uses the MIB would like to comment? > 2. I met with Alan in Minneapolis, and made quite good progress. One > possible way to formalize the progress we made in the hallway is to > work together on a framework document for VoIP performance monitoring. > Hopefully we will have the time and resources to make this happen. Good to hear, I look forward to seeing the result. Colin _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 11:52:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21483 for ; Fri, 21 Nov 2003 11:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEVo-0002fE-PN for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 11:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGq44I010209 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 11:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEVm-0002dt-3D; Fri, 21 Nov 2003 11:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEVS-0002cU-7E for avt@optimus.ietf.org; Fri, 21 Nov 2003 11:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21391 for ; Fri, 21 Nov 2003 11:51:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEVR-0004yY-00 for avt@ietf.org; Fri, 21 Nov 2003 11:51:41 -0500 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1ANEVQ-0004y8-00 for avt@ietf.org; Fri, 21 Nov 2003 11:51:40 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hALGkfYs031920 for ; Fri, 21 Nov 2003 11:51:10 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3FBBC62E000DB27C; Fri, 21 Nov 2003 11:50:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] HC over multihop / MPLS Date: Fri, 21 Nov 2003 10:51:10 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA367C@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [AVT] HC over multihop / MPLS Thread-Index: AcOpVdFXmaUPhLrrQVeq0TEP4tcv9QG8VkBQ From: "Ash, Gerald R (Jerry), ALABS" To: "Lars-Erik Jonsson (LU/EAB)" , Cc: "Ash, Gerald R (Jerry), ALABS" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Lars-Erik, I very much appreciate your taking the time to read the draft and = comment. A lot of the questions raised at the AVT meeting are addressed in the = draft, so it helps when people do read the draft. Allison, Colin, Magnus, and I met after the meeting and agreed on the = following approach for next steps: 1. split the current document = http://ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt = into 2 requirements documents: a. 'requirements for hop-by-hop ECRTP over MPLS' (RSVP-TE protocol = extension oriented) b. 'requirements for hop-by-hop ECRTP over IP' (SCID switching oriented) (note that Colin suggests 'hop-by-hop' versus 'multi-hop' terminology; = 'multi-hop was meant to clarify 'end-to-end' in the OO version, but = still may have led to some confusion). 2. eliminate MPLS jargon such as CE, PE, etc., just talk about routers = R1, R2, etc. 3. eliminate absolute performance objectives and simply state goal to = 'minimize delta degradation' (for delay, jitter, pkt loss, etc.). This = includes performance degradation due to too much resync. 4. eliminate absolute scalability requirement for # of flows, and simply = state goal to improve scalability of the number of compressed flows that = can be handled. 5. use already standard protocols for compression, signaling, etc. It was agreed that requirements 1a should lead to an RSVP-TE protocol = extension effort and be worked in conjunction with the MPLS SG, and that = requirements 1b could lead to an Informational RFC out of AVT. Please let me know of any comments or suggestions on this plan. I've made a few other brief comments below on your email.=20 Thanks, Jerry > The AVT charter states the following as a WG task:=20 > "to review the applicability of Compressed RTP operation on > MPLS networks, developing extensions as necessary" >=20 > With the following milestones: > Nov 03 Initial draft requirements for ECRTP over MPLS;=20 > discuss with MPLS WG > Nov 03 Initial draft requirements for ECRTP over MPLS;=20 > discuss with MPLS WG >=20 > However, the current draft refers to "VoIP Header Compression=20 > over Multi-Hop Paths", which is not the same thing. The draft > clearly shows that compression over multihop paths is one thing,=20 > and compression over MPLS another. Further, the draft takes a=20 > wider scope, and talks about header compression generally, > not only ECRTP as the charter says. >=20 > The following observations can be made: > * If work is to done for header compression over multihop=20 > and/or MPLS, it might make sense to not only address ECRTP. Agreed. The plan to split the requirements draft into 2 separate = requirements drafts (ECRTP over MPLS, ECRTP over IP) addresses this, as = outlined above. > * The only work in this that naturally could belong in the=20 > AVT WG would be to make sure ECRTP would work in these=20 > scenarios. In my understanding, this should already be=20 > the case with ECRTP (as well as some ROHC profiles), which=20 > is also indicated by the multihop req draft. Agreed. > * Header compression over multihop paths [ described by the=20 > multihop req draft as where one wants to avoid=20 > decompression/compression steps at intermediate routers if=20 > the same compression scheme is supported at both incoming=20 > and outgoing interfaces ] is fully possible also without any=20 > new standards, as it would only be an implementation issue for=20 > each intermediate router to bind an incoming compressed stream > to its corresponding outgoing compressed stream. In a path=20 > A->B->C, where B is the intermediate router > negotiating use of e.g. CRTP with both A and C, it is fully=20 > up to the implementation of B to avoid unnecessary=20 > decompression/compression and just forward compressed packets > as-is ("CID routing"). Agreed (requirements draft 1b, as outlined above, leading to an = Informational RFC). > * The only significant standardization work I can see is to=20 > define how to do header compression (e.g. IPHC, CRTP/ECRTP,=20 > ROHC) over MPLS, which is probably a work that would require=20 > some coordination with AVT and ROHC individuals, but the core > of that work does not naturally belong to ROHC or AVT. Would > not the MPLS WG be a more proper place? I think the plan is to complete the requirements 1a and the follow-on = protocol work in conjunction with the MPLS WG. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 12:46:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24111 for ; Fri, 21 Nov 2003 12:46:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFM3-0007XR-Qh for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 12:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALHk3rf028971 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 12:46:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFM1-0007WZ-Ec; Fri, 21 Nov 2003 12:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFLV-0007Ve-FK for avt@optimus.ietf.org; Fri, 21 Nov 2003 12:45:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24054 for ; Fri, 21 Nov 2003 12:45:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFLT-0005yF-00 for avt@ietf.org; Fri, 21 Nov 2003 12:45:27 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANFLT-0005yC-00 for avt@ietf.org; Fri, 21 Nov 2003 12:45:27 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALHiq2Y022833 for ; Fri, 21 Nov 2003 12:44:52 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALHio2Y022797 for ; Fri, 21 Nov 2003 12:44:51 -0500 (EST) 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 Subject: RE: [AVT] RTP MIB Extensions Date: Fri, 21 Nov 2003 19:45:24 +0200 Message-ID: Thread-Topic: [AVT] RTP MIB Extensions Thread-Index: AcOwTWAW54yx8C6bQ7mK8C9S+C75UgACRKIw From: "Romascanu, Dan (Dan)" To: , "Colin Perkins" Cc: , , "Bert Wijnen (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > With regard to the relative priorities of (i) and (ii), I=20 > recall that there > seemed to be no disagreement that the RTP MIB update was=20 > important but there > was no suggestion that this was more or less important than=20 > progressing an > RTCP XR based draft. There is considerable interest in using=20 > RTCP XR for > VoIP fault/performance management and some definite expressed=20 > interest in > seeing a MIB based on the RTCP XR metrics. >=20 > Alan Clark >=20 >=20 >=20 Alan, RTCP XR is an extension of RTP/RTCP. Subsequently, the RTCP XR MIB is an = extension of the RTP MIB. At this point in the evolution of RTP, as RFC = 3550 obsoletes RFC 1889, it looks imperative that the necessary changes = are being made to the RTP MIB first, so that any extension work (like = the proposed work on RTCP XR MIB) is based on an updated version of the = MIB and standard.=20 Regards, Dan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 13:09:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24961 for ; Fri, 21 Nov 2003 13:09:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFiJ-0000al-Rm for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALI93u1002252 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFiG-0000ZS-NQ; Fri, 21 Nov 2003 13:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFhu-0000Y9-SA for avt@optimus.ietf.org; Fri, 21 Nov 2003 13:08:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24932 for ; Fri, 21 Nov 2003 13:08:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFht-0006K0-00 for avt@ietf.org; Fri, 21 Nov 2003 13:08:37 -0500 Received: from via-smtp2.imconline.net ([66.155.127.62]) by ietf-mx with esmtp (Exim 4.12) id 1ANFhr-0006Jl-00 for avt@ietf.org; Fri, 21 Nov 2003 13:08:35 -0500 Received: from telchemy.com ([66.155.69.251]) by via-smtp2.imconline.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 13:07:52 -0500 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-8.03) id A54750F0364; Fri, 21 Nov 2003 13:11:19 -0500 Reply-To: From: "Alan Clark" To: "'Romascanu, Dan \(Dan\)'" , "'Colin Perkins'" Cc: , , "'Bert Wijnen \(E-mail\)'" Subject: RE: [AVT] RTP MIB Extensions Date: Fri, 21 Nov 2003 13:08:01 -0500 Message-ID: <006401c3b05a$670ac490$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0065_01C3B030.7E34BC90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MS-TNEF-Correlator: 000000009988B8DB99EF5848818B736CCB599E21843BD800 X-OriginalArrivalTime: 21 Nov 2003 18:07:52.0946 (UTC) FILETIME=[61B76520:01C3B05A] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C3B030.7E34BC90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [Dan R] RTCP XR is an extension of RTP/RTCP. Subsequently, the RTCP XR MIB is an extension of the RTP MIB. At this point in the evolution of RTP, as RFC 3550 obsoletes RFC 1889, it looks imperative that the necessary changes are being made to the RTP MIB first, so that any extension work (like the proposed work on RTCP XR MIB) is based on an updated version of the MIB and standard. Dan I have to disagree with you. There is minimal overlap between the two other than a need to put the RTCP XR MIB/Group under the RTP MIB OID and hence they can be progressed in parallel. At this moment there are no proposed specific changes to the RTP MIB other than the draft discussed in Minneapolis and hence making these serial activities would delay the progress of the RTCP XR MIB work for an indefinite period, which I'm sure you would not want. There is strong interest in the use of RTCP XR for VoIP fault/ performance management - I am prepared to do the work needed to progress the draft and would welcome your input and comments. Regards Alan ------=_NextPart_000_0065_01C3B030.7E34BC90 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgESAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHCwAVAA0ACAAAAAUAFAEB A5AGAKQHAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAZAAAAW0FWVF0gUlRQIE1JQiBFeHRlbnNpb25zAAAAAAIBcQABAAAAFgAAAAHD sFpmtg1RBve+Ak3jun4QSunVQoIAAAIBHQwBAAAAFwAAAFNNVFA6QUxBTkBURUxDSEVNWS5DT00A AAsAAQ4AAAAAQAAGDgDA62VasMMBAgEKDgEAAAAYAAAAAAAAAJmIuNuZ71hIgYtzbMtZniHCgAAA AwAUDgEAAAALAB8OAQAAAAIBCRABAAAAZgMAAGIDAABfBQAATFpGdfh0u8gDAAoAcmNwZzEyNeIy A0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2 MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUPMLCQFkMzYWUAumCuMKgCRbRAORUl0H8FRDoFAg WFIgBAAgA5GPDsEJ8ACQAiAgb2YdwZRQLx3SLgYAdWIUEAZxClACMGx5LCB0xGhlHcdNSUIeTx9R 7yEEHgAhwSAAQQVAIQAiATxwbwuABUALgCDzZXZZBvB1dB8YIOBhBCBSsEZDIDMaYBZQbyBADwbw FCAHkSaiMTg4Oc0g4GkFQBewb2sEIAdw6nAEkGEloHYhICEAKVAtIPNuBZAHkHMKwHkgORPRbmcH kQrAISBiZbkLgGcgAMABACDwbyMq6CBmaRQAdCDgJ1AppBcAcCrAHrh3BbBrICjYbGlrKZIhIHAD YCSAXRQQZC8EHyEhSSkh8mKPJnAwYR8hA5F1cGQpUP8wYSmAFAAiySHCAHAwcC1wfzSBCxEgABz0 HPQdYTVqSa4gE+ApgixgZAQAYQnCYy8AKHBoIHkIYCAAIO5UIRArcSIBbQuAB3AHQJcfQDNRC2Bw K5F0dwnh9yDzOqAsYG8hAQXAKbEygTcqMTBhLFFwJZAg/i9HPwNgMtAywDSQO7MsqE9J9kQ0cyEQ bipgIPIqwQOR/yugL/IJwQQQMGEk4QqxB0D9J3BsNUwkBgRgB4AksTuSWyEgK2JuPLEwFnMpIGO/ BpAN4CrXLF07iSECZClA0wGAN6JjdUGWTQuAKkDfOlAG8CIDP/YAwGsrwiEB/xQQLaAGcTnRANAp YShwCJDzBCAvEHVsMHABAAtgKsD/L8VBYyL4IWgvEwIQBcADkf8LgAEBOZEOsCRwBnEEcCDghnck QBPQIEknbS2gvwhwISA4kU0lRQAFQHcAcP50OMotcANgK9EkoTkRLXA/JNZJUCEgH1Md9FBCVm+S SR4AZmFNUHQvUVJXUEEDgUsTbjfgZUQTLW9SMCIgUmAwAGUKsTx0ZP8sZC8TPFI8dU5GSHg0gk00 /TqwbAWgB4A4ggXAC4A80ic0gl4RRBJzLjVqUmW6ZwsRc0K7C2A2S31i4AAAHgBCEAEAAABJAAAA PEFBQjRCM0QzQ0YwRjQ1NEY5ODI3MkNCRTE4N0ZERTJGMDQyNTk3NTJAaXMwMDA0YXZleHUxLmds b2JhbC5hdmF5YS5jb20+AAAAAAMACVkBAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAA AAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAA AFKFAAB9bgEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAEYAIIAYA AAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwASgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAAL ABuACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAHIAIIAYAAAAAAMAAAAAAAABGAAAAABGF AAAAAAAAAwAegAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAfgPAQAAABAAAACZiLjbme9Y SIGLc2zLWZ4hAgH6DwEAAAAQAAAAmYi425nvWEiBi3Nsy1meIQIB+w8BAAAAkgAAAAAAAAA4obsQ BeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRz IGFuZCBTZXR0aW5nc1xhbGFuXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9z b2Z0XE91dGxvb2tcbWFpbGJveC5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAw MDAwMDA5OTg4QjhEQjk5RUY1ODQ4ODE4QjczNkNDQjU5OUUyMTg0M0JEODAwAAAAAAMABhBxssRw AwAHEEUDAAADABAQAQAAAAMAERAAAAAAHgAIEAEAAABlAAAAREFOUlJUQ1BYUklTQU5FWFRFTlNJ T05PRlJUUC9SVENQU1VCU0VRVUVOVExZLFRIRVJUQ1BYUk1JQklTQU5FWFRFTlNJT05PRlRIRVJU UE1JQkFUVEhJU1BPSU5USU5USEVFVgAAAAAM4A== ------=_NextPart_000_0065_01C3B030.7E34BC90-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 13:16:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25149 for ; Fri, 21 Nov 2003 13:16:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFp6-00017D-8U for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALIG4Pv004281 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFp4-00016O-FL; Fri, 21 Nov 2003 13:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFon-0000zr-Rm for avt@optimus.ietf.org; Fri, 21 Nov 2003 13:15:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25083 for ; Fri, 21 Nov 2003 13:15:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFol-0006Ng-00 for avt@ietf.org; Fri, 21 Nov 2003 13:15:43 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1ANFol-0006NK-00 for avt@ietf.org; Fri, 21 Nov 2003 13:15:43 -0500 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hALIEti18715; Fri, 21 Nov 2003 13:14:56 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XCDCW4N2; Fri, 21 Nov 2003 13:14:56 -0500 Received: from nortelnetworks.com (acart1cn.ca.nortel.com [47.129.129.64]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NPTZ; Fri, 21 Nov 2003 13:14:56 -0500 Message-ID: <3FBE561F.4050809@nortelnetworks.com> Date: Fri, 21 Nov 2003 13:14:55 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: alan@telchemy.com, Colin Perkins , avt@ietf.org, mankin@psg.com, "Bert Wijnen (E-mail)" Subject: Re: [AVT] RTP MIB Extensions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I see no reason why the two can't be developed in parallel. Yes, the RTCP XR MIB will be an extension, but I would think the updates to the RTP MIB would stabilize pretty quickly. Romascanu, Dan (Dan) wrote: >>With regard to the relative priorities of (i) and (ii), I >>recall that there >>seemed to be no disagreement that the RTP MIB update was >>important but there >>was no suggestion that this was more or less important than >>progressing an >>RTCP XR based draft. There is considerable interest in using >>RTCP XR for >>VoIP fault/performance management and some definite expressed >>interest in >>seeing a MIB based on the RTCP XR metrics. >> >>Alan Clark >> >> >> > > > Alan, > > RTCP XR is an extension of RTP/RTCP. Subsequently, the RTCP XR MIB is an extension of the RTP MIB. At this point in the evolution of RTP, as RFC 3550 obsoletes RFC 1889, it looks imperative that the necessary changes are being made to the RTP MIB first, so that any extension work (like the proposed work on RTCP XR MIB) is based on an updated version of the MIB and standard. > > Regards, > > Dan > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 21 13:22:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25341 for ; Fri, 21 Nov 2003 13:22:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFus-0001eK-Gl for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALIM2nn006323 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFur-0001dQ-Sb; Fri, 21 Nov 2003 13:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFu1-0001bD-P3 for avt@optimus.ietf.org; Fri, 21 Nov 2003 13:21:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25315 for ; Fri, 21 Nov 2003 13:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFtz-0006Ut-00 for avt@ietf.org; Fri, 21 Nov 2003 13:21:07 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANFtz-0006Uq-00 for avt@ietf.org; Fri, 21 Nov 2003 13:21:07 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALIKX2Y028914 for ; Fri, 21 Nov 2003 13:20:33 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALIKU2Y028861 for ; Fri, 21 Nov 2003 13:20:31 -0500 (EST) 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="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] RTP MIB Extensions Date: Fri, 21 Nov 2003 20:21:04 +0200 Message-ID: Thread-Topic: [AVT] RTP MIB Extensions Thread-Index: AcOwWma2DVEG974CTeO6fhBK6dVCggAADnpQ From: "Romascanu, Dan (Dan)" To: , "Colin Perkins" Cc: , , "Bert Wijnen (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alan Clark [mailto:alan@telchemy.com] > Sent: 21 November, 2003 8:08 PM > To: Romascanu, Dan (Dan); 'Colin Perkins' > Cc: avt@ietf.org; mankin@psg.com; 'Bert Wijnen (E-mail)' > Subject: RE: [AVT] RTP MIB Extensions >=20 >=20 >=20 > [Dan R] RTCP XR is an extension of RTP/RTCP. Subsequently,=20 > the RTCP XR MIB is an extension of the RTP MIB. At this point=20 > in the evolution of RTP, as RFC 3550 obsoletes RFC 1889, it=20 > looks imperative that the necessary changes are being made to=20 > the RTP MIB first, so that any extension work (like the=20 > proposed work on RTCP XR MIB) is based on an updated version=20 > of the MIB and standard.=20 >=20 > Dan >=20 > I have to disagree with you. There is minimal overlap=20 > between the two other than a need to put the RTCP XR=20 > MIB/Group under the RTP MIB OID and hence they can be=20 > progressed in parallel.=20 >=20 > At this moment there are no proposed specific changes to the=20 > RTP MIB other than the draft discussed in Minneapolis and=20 > hence making these serial activities would delay the progress=20 > of the RTCP XR MIB work for an indefinite period, which I'm=20 > sure you would not want. There is strong interest in the use=20 > of RTCP XR for VoIP fault/ performance management - I am=20 > prepared to do the work needed to progress the draft and=20 > would welcome your input and comments. >=20 > Regards >=20 > Alan >=20 Alan, We need to agree to disagree:-)=20 As a user of the technology, and as a MIB advisor I think that the = proper way is to have the core RTP MIB updated first. I understand your = wish to make progress on your specific work on RTCP XR, but the RTP MIB = is the main item for this WG. Everybody implementing RTCP-XR need to = implement RTP as well, and better do its management based on an updated = MIB. I hope that the RTP MIB authors will do the necessary changes soon. = Maybe you can do them. The work needs not be serialized, but I think = that an RTCP XR MIB should not be approved on the standards track before = the RTP MIB is updated for eventual changes caused by RFC 1889 being = obsolete by RFC 3550. Regards, Dan =20 >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 13:24:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25447 for ; Fri, 21 Nov 2003 13:24:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFwn-0001xw-G0 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:24:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALIO1I3007488 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 13:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFwm-0001vR-Kz; Fri, 21 Nov 2003 13:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFw7-0001ut-K2 for avt@optimus.ietf.org; Fri, 21 Nov 2003 13:23:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25394 for ; Fri, 21 Nov 2003 13:23:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFw5-0006Wr-00 for avt@ietf.org; Fri, 21 Nov 2003 13:23:17 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ANFw5-0006Wm-00 for avt@ietf.org; Fri, 21 Nov 2003 13:23:17 -0500 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 hALIKj5C013951 for ; Fri, 21 Nov 2003 13:20:45 -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 hALIKg5C013917 for ; Fri, 21 Nov 2003 13:20:43 -0500 (EST) 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 Subject: RE: [AVT] RTP MIB Extensions Date: Fri, 21 Nov 2003 20:23:13 +0200 Message-ID: Thread-Topic: [AVT] RTP MIB Extensions Thread-Index: AcOwW2WcMN7QL9JsRLaf7d5Ve26ByAAAN/FQ From: "Romascanu, Dan (Dan)" To: "Tom Taylor" Cc: , "Colin Perkins" , , , "Bert Wijnen (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Agreed. There is no for serialization. We just need to make sure that by = the time extensions MIB modules are to enter the standards track, an = updated RTP MIB is already available. Dan > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: 21 November, 2003 8:15 PM > To: Romascanu, Dan (Dan) > Cc: alan@telchemy.com; Colin Perkins; avt@ietf.org;=20 > mankin@psg.com; Bert Wijnen (E-mail) > Subject: Re: [AVT] RTP MIB Extensions >=20 >=20 > I see no reason why the two can't be developed in parallel. Yes, the=20 > RTCP XR MIB will be an extension, but I would think the=20 > updates to the=20 > RTP MIB would stabilize pretty quickly. >=20 > Romascanu, Dan (Dan) wrote: >=20 > >>With regard to the relative priorities of (i) and (ii), I=20 > >>recall that there > >>seemed to be no disagreement that the RTP MIB update was=20 > >>important but there > >>was no suggestion that this was more or less important than=20 > >>progressing an > >>RTCP XR based draft. There is considerable interest in using=20 > >>RTCP XR for > >>VoIP fault/performance management and some definite expressed=20 > >>interest in > >>seeing a MIB based on the RTCP XR metrics. > >> > >>Alan Clark > >> > >> > >> > >=20 > >=20 > > Alan, > >=20 > > RTCP XR is an extension of RTP/RTCP. Subsequently, the RTCP=20 > XR MIB is an extension of the RTP MIB. At this point in the=20 > evolution of RTP, as RFC 3550 obsoletes RFC 1889, it looks=20 > imperative that the necessary changes are being made to the=20 > RTP MIB first, so that any extension work (like the proposed=20 > work on RTCP XR MIB) is based on an updated version of the=20 > MIB and standard.=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > >=20 >=20 >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 21 19:10:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13166 for ; Fri, 21 Nov 2003 19:10:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLLk-0000nJ-4u for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 19:10:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM0A8aX003049 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 19:10:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLLe-0000ma-AX; Fri, 21 Nov 2003 19:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLLM-0000m9-9S for avt@optimus.ietf.org; Fri, 21 Nov 2003 19:09:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13146 for ; Fri, 21 Nov 2003 19:09:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANLLI-0004SC-00 for avt@ietf.org; Fri, 21 Nov 2003 19:09:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ANLLI-0004Rt-00 for avt@ietf.org; Fri, 21 Nov 2003 19:09:40 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2003 16:09:38 -0800 Received: from mbaugher-w2k07.cisco.com (sjc-vpn1-788.cisco.com [10.21.99.20]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAM097iO014964; Fri, 21 Nov 2003 16:09:07 -0800 (PST) Message-Id: <6.0.0.22.2.20031121160316.03bdfc50@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 21 Nov 2003 16:09:06 -0800 To: Colin Perkins From: Mark Baugher Subject: Re: [AVT] RTP MIB Extensions Cc: "Romascanu, Dan (Dan)" , , , "Bert Wijnen (E-mail)" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 05:43 AM 11/21/2003, Colin Perkins wrote: >On Friday, Nov 21, 2003, at 13:19 Europe/London, Romascanu, Dan (Dan) wrote: >>1. From the point of view of the AVT WG, it looks to me that updating the >>RTP MIB to reflect changes in RTC from RFC 1889 to RFC 3550 has higher >>priority. > >If the MIB is used, then this certainly needs to be done. Maybe anyone on >the list who uses the MIB would like to comment? The last I heard is that it was deployed in the H.323 MIB and that was the end of it. All the folks I worked on it with seem to be no longer involved with H.323 products. I don't know of any companies shipping the RTP MIB. That being said, I don't understand why anyone would go to the trouble of implementing a piece of the RTP MIB. Perhaps it would make sense to do only the multicast objects or only the unicast objects. I can't fathom why anyone would go to the trouble of developing only a piece of the MIB without implementing the session objects, etc., i.e. for little incremental effort, the entire RTP system could be monitored and/or configured. Mark >>2. I met with Alan in Minneapolis, and made quite good progress. One >>possible way to formalize the progress we made in the hallway is to work >>together on a framework document for VoIP performance monitoring. >>Hopefully we will have the time and resources to make this happen. > >Good to hear, I look forward to seeing the result. > >Colin > > >_______________________________________________ >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 exim@www1.ietf.org Fri Nov 21 19:52:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14218 for ; Fri, 21 Nov 2003 19:52:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANM0L-0003Y9-NM for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 19:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM0q5WU013639 for avt-archive@odin.ietf.org; Fri, 21 Nov 2003 19:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANM0G-0003XQ-VX; Fri, 21 Nov 2003 19:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLzU-0003Wg-6r for avt@optimus.ietf.org; Fri, 21 Nov 2003 19:51:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14203 for ; Fri, 21 Nov 2003 19:51:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANLzS-0004x3-00 for avt@ietf.org; Fri, 21 Nov 2003 19:51:10 -0500 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 1ANLzR-0004wz-00 for avt@ietf.org; Fri, 21 Nov 2003 19:51:09 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 21 Nov 2003 16:51:00 -0800 X-Server-Uuid: 8D569F9F-42CF-4602-970D-AACC4BD5D310 Received: from pcirvarchen (dhcp-2-138-183.broadcom.com [10.2.138.183]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA19537 for ; Fri, 21 Nov 2003 16:50:30 -0800 (PST) From: "Raymond Chen" To: avt@ietf.org Date: Fri, 21 Nov 2003 16:50:59 -0800 Message-ID: <04f001c3b092$b23298c0$b78a020a@pcirvarchen> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-WSS-ID: 13A06D790QS2015363-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] FW: I-D ACTION:draft-chen-rtp-bv-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear AVT members, Your feedback on the following Internet Draft draft-chen-rtp-bv-02.txt would be appreciated. I believe this version has addressed all outstanding issues the AVT chairs had on this Internet Draft. Your support in accepting this draft as an official AVT work item would also be greatly appreciated. Thanks. Raymond -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, November 21, 2003 1:04 PM To: IETF-Announce: Subject: I-D ACTION:draft-chen-rtp-bv-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Payload Format for BroadVoice Speech Codecs Author(s) : J. Chen Filename : draft-chen-rtp-bv-02.txt Pages : 13 Date : 2003-11-21 This document describes the RTP payload format for the BroadVoice(TM) narrowband and wideband speech codecs developed by Broadcom Corporation. The document also provides specifications for the use of BroadVoice with MIME and SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rtp-bv-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-chen-rtp-bv-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-chen-rtp-bv-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. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Nov 22 03:29:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06568 for ; Sat, 22 Nov 2003 03:29:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANT8p-0003i7-GG for avt-archive@odin.ietf.org; Sat, 22 Nov 2003 03:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM8TJ8n014262 for avt-archive@odin.ietf.org; Sat, 22 Nov 2003 03:29:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANT8Y-0003gt-5H; Sat, 22 Nov 2003 03:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANT7z-0003gP-5t for avt@optimus.ietf.org; Sat, 22 Nov 2003 03:28:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06544 for ; Sat, 22 Nov 2003 03:28:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANT7w-00026k-00 for avt@ietf.org; Sat, 22 Nov 2003 03:28:24 -0500 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 1ANT7w-00026g-00 for avt@ietf.org; Sat, 22 Nov 2003 03:28:24 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id hAM8SOp04717; Sat, 22 Nov 2003 09:28:24 +0100 (CET) From: "Gunnar Hellstrom" To: "avt IETF" , "AG 9 ITS" , "Wisdom-Cds" , "Text Telephone Forum" , "Toip list" Subject: [avt] Refined specification for text over IP FW: I-D ACTION:draft-ietf-avt-rfc2793bis-00.txt Date: Sat, 22 Nov 2003 09:28:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C3B0DA.F9B71430" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C3B0DA.F9B71430 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id hAM8SOp04717 Content-Transfer-Encoding: quoted-printable A new IETF draft is available related to real time interactive text conversation. An RTP transport for real time character by character transmission of tex= t was defined and approved a couple of years ago in IETF RFC2793. It is now successfully used in conversational applications, usually combi= ned with voice and/or video to enable the participants in the session to communicate in any preferred medium. One important user group is deaf and hard-of-hearing people, but the feature is of course of value for all. In the past, most multimedia implementors have been eager to create interoperability in video and audio, while the text part has been left behind and implemented as manufacturer specific message-oriented "chat"-additions. It is time for a change, to raise all the three media o= f video, text and audio to the same status of interoperability and deployme= nt. That will give multimedia based conversational services a real benefit. The text transport according to the new draft "RFC2793 bis" is compatible with the current RFC2793. It clarifies use of SDP for setting up sessions including text, and introduces a new format specifically intended for text transit between gateways that can be merge= d into the audio stream. We(the authors) hope for rapid handling of this draft, so that it can be used in further work in establishing interoperable accessible multimedia implementations with all media needed= in human conversation, and in the ongoing work with text-aware gateways, text-over-ip and transcoding services in various groups. Please direct comments to the IETF avt list. Regards Gunnar Hellstr=F6m -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Friday, November 21, 2003 10:04 PM To: IETF-Announce: Subject: I-D ACTION:draft-ietf-avt-rfc2793bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rfc2793bis-00.txt Pages : 19 Date : 2003-11-21 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the messag= e. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2793bis-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-rfc2793bis-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_000_0004_01C3B0DA.F9B71430 Content-Type: Message/External-body; name="ATT00125.dat" Content-Disposition: attachment; filename="ATT00125.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-11-21162126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc2793bis-00.txt ------=_NextPart_000_0004_01C3B0DA.F9B71430 Content-Type: Message/External-body; name="draft-ietf-avt-rfc2793bis-00.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rfc2793bis-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-11-21162126.I-D@ietf.org> ------=_NextPart_000_0004_01C3B0DA.F9B71430-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Nov 23 07:49:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20189 for ; Sun, 23 Nov 2003 07:49:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANtfm-0003Tq-5i for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 07:49:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANCn6mk013372 for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 07:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANtfh-0003TM-Gr; Sun, 23 Nov 2003 07:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDbZ-0007Or-Lc for avt@optimus.ietf.org; Fri, 21 Nov 2003 10:53:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18865; Fri, 21 Nov 2003 10:53:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDbW-00045f-00; Fri, 21 Nov 2003 10:53:54 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1ANDbV-00045c-00; Fri, 21 Nov 2003 10:53:54 -0500 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 16:53:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] RE: [MMUSIC] DCCP Media Guide Date: Fri, 21 Nov 2003 16:53:37 +0100 Message-ID: <6F704D0B4CD23044990B4F8999F463DD40B414@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [AVT] RE: [MMUSIC] DCCP Media Guide Thread-Index: AcOvk9QY7fErcwuYRI2/oFuzWzxiXQAdmRLw From: =?iso-8859-1?Q?BABONNEAU_G=E9rard_FTRD/DMI/REN?= To: "Rosen, Brian" , "Phelan, Tom" Cc: , X-OriginalArrivalTime: 21 Nov 2003 15:53:41.0023 (UTC) FILETIME=[A26572F0:01C3B047] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I had a carefull look at the draft. In my opinion, coding with two or more rates is only TCP compliant, and = it does'nt improve the video quality because the network losses have = disastrous effects (30% pictures loss for 3% packet loss). We (France = Telecom R&D) have developped a test bed with MPEG4/RTP/UDP hierarchical = codec with 2 or more layers for the video. A DSCP marking allows = diffserv routers to choose packets to be lost when a congestion occurs. = We have a better quality than other codecs in a lossy environment and it = also works in multicast sessions. Diffserv routers can also share the = bandwidth between UDP and TCP flows, to guarantee a good throughput for = all the flows on the network.=20 G=E9rard BABONNEAU -----Message d'origine----- De : Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 Envoy=E9 : jeudi 20 novembre 2003 19:24 =C0 : 'Phelan, Tom' Cc : 'dccp@ietf.org'; 'avt@ietf.org' Objet : RE: [AVT] RE: [MMUSIC] DCCP Media Guide I have looked carefully at the drafts. I think I understand what=20 the proposal is, and how it works. I'll even agree that it might=20 do what you think it will do, but I suspect that my device will=20 cause a heck of a lot more congestion to the network if I run the=20 video streams on DCCP than if I leave it on UDP. I think the=20 solution will be much worse than the problem. The solution is just plain broken, in my opinion. The real, hard,=20 problem is that there probably is no good solution, short of fixing=20 TCP, or treating real time data differently (ie QoS) in the router. =20 Like it or not, RTP is not appropriate for what we usually call=20 "best effort", but the problem with that statement is that it's not=20 really true that we need something more than for the network to use=20 its' best effort to deliver the traffic. What is true is that other=20 streams have to deal better with CBR data than they do. It is TCP=20 that is broken. I don't think there is any way around that. =20 TCP makes an assumption that is invalid when real time media is part=20 of the traffic mix. There are so many problems with DCCP applied to real time media (this=20 one, slow start,...), that I think we should just stop believing that=20 DCCP is appropriate for RTP. A specific comment to your message below is that if we send more data = than 4Mbit, it is just filler. We cannot "make use of it". We can just = congest the network more than we do. As you might realize, we already = have problems putting 4M into the network. More is not better in this = case. Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Thursday, November 20, 2003 11:48 AM > To: 'Rosen, Brian' > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide >=20 >=20 > Hi Brian, >=20 > Thanks for the comments. See inline ... >=20 > Tom P. >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, November 20, 2003 11:05 AM > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > >=20 > >=20 > > To me, this is just nonsense. > > I can't imagine anyone deploying such a solution. > >=20 > > This is forcing the problem to fit the solution, and it's not the > > right way to go. If you want it to work, the protocol has to take=20 > > the characteristics of the flows as they are, and not as you would=20 > > like them to be. Real time media, streaming > or realtime, > > is either constant bit rate, or pretty close to it. That's how it=20 > > works. Our challenge is to make the protocols work with this data,=20 > > not change the data, especially silly ideas like doubling the=20 > > bandwidth. > >=20 > > We make video telephones. They nominally send 4 megabits. Would > > you like us to double that, under any circumstances? > >=20 > > I thought not. >=20 > Would you prefer to be forced unnecessarily into packet loss and a=20 > lower encoding rate by greedy TCP applications? Or do you have > another solution? >=20 > I don't think I'm forcing the problem to fit the solution, just=20 > perhaps that the problem I'm trying to solve is different than you > perceive. The problem > that I'm trying to solve is how can an application that is=20 > content with a > maximum bandwidth compete with TCP applications that are=20 > insatiably greedy, > in a way that satisfies some concept of fairness in all directions? >=20 > The solution that I see is to provide a buffer against TCP probing. =20 > This would involve sending more data than is nominally necessary. > If the network > has capacity for more than 4M bps, then why shouldn't a media=20 > app make use > of it? A TCP app would. >=20 > I must admit that my initial reactions to suggestions like this were=20 > very similar to yours. I encourage you to look at the draft for > more detail on > the issues that convinced me otherwise. >=20 > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > Sent: Thursday, November 20, 2003 10:36 AM > > > To: 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > >=20 > > >=20 > > > Hi Jonathan, > > >=20 > > > Thanks for the comments. The actual proposal is to send up to=20 > > > double the nominal transmit rate when there's available bandwidth, = > > > and to reduce the > > > rate as necessary if there isn't enough bandwidth. This=20 > > > doubling is to > > > allow fair sharing of the chokepoint bandwidth (between DCCP=20 > > > media apps and > > > TCP apps), and to avoid what appears to me to be the=20 > > > potential for bullying > > > from TCP applications that want to suck up all the bandwidth=20 > > > they can. It > > > doesn't preclude using low-rate codecs, or mean that the=20 > > > access link must > > > support the double rate for the connection to function well. > > >=20 > > > This recommendation was meant for best-effort environments, where=20 > > > the voice traffic receives no special treatment, and must compete=20 > > > with TCP apps for > > > network resources. I can see how this would require a=20 > > > network that gave > > > special treatment to voice packets to provision double the=20 > > > capacity, though. > > >=20 > > > This fairness problem is difficult. All of the research I'm=20 > > > familiar with approaches it from the direction of other apps being = > > > fair to TCP. I'm not > > > aware of any other methods for ensuring that non-TCP apps get=20 > > > their fair > > > share when competing with TCP. If you (or anyone else) knows=20 > > > of something > > > I'd appreciate the pointer. > > >=20 > > > Tom P. > > >=20 > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > To: Phelan, Tom > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > >=20 > > > >=20 > > > > Tom, > > > >=20 > > > > I don't think this solution will be acceptable to many of > > > the network > > > > providers of interactive voip services. Many of them are > > > insistent on > > > > using low rate codecs, like g.723, in order to reduce the > > costs of > > > > capacity in their networks. Doubling the rate would defeat the=20 > > > > purpose of using these low rate codecs in the first place. > > > >=20 > > > > -Jonathan R. > > > >=20 > > > > Phelan, Tom wrote: > > > >=20 > > > >=20 > > > > > Comments will be appreciated. In particular, I make the > > > > suggestion that > > > > > media apps should transmit at up to twice their nominal > > > > maximum rate, when > > > > > DCCP allows it, in order to provide protection from > > competing TCP > > > > > applications. I know that the first time I heard someone > > > > make a similar > > > > > suggestion I was horrified, but as I developed the issues > > > > it seemed to be > > > > > necessary. Reactions to this will be appreciated. > > > > >=20 > > > > > Tom P. > > > > >=20 > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic > > > > >=20 > > > >=20 > > > > --=20 > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Chief Technology Officer Parsippany, NJ=20 > > > 07054-2711 > > > > dynamicsoft > > > > jdrosen@dynamicsoft.com FAX: =20 > (973) 952-5050 > > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > >=20 > > >=20 > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > >=20 > >=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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Nov 23 09:10:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21289 for ; Sun, 23 Nov 2003 09:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANuwG-0006Ai-8O for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 09:10:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANEACCU023677 for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 09:10:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANuw6-00069c-Nr; Sun, 23 Nov 2003 09:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANuve-00065U-7t for avt@optimus.ietf.org; Sun, 23 Nov 2003 09:09:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21265 for ; Sun, 23 Nov 2003 09:09:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANuvc-0003BM-00 for avt@ietf.org; Sun, 23 Nov 2003 09:09:32 -0500 Received: from ms-smtp-01-qfe0.socal.rr.com ([66.75.162.133] helo=ms-smtp-01-eri0.socal.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1ANuvc-0003BJ-00 for avt@ietf.org; Sun, 23 Nov 2003 09:09:32 -0500 Received: from vsathe (dt0410n5e.san.rr.com [204.210.30.94]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id hANE9NKn012833; Sun, 23 Nov 2003 06:09:27 -0800 (PST) Message-Id: <200311231409.hANE9NKn012833@ms-smtp-01-eri0.socal.rr.com> From: "Vinay Sathe" To: "=?iso-8859-1?Q?'BABONNEAU_G=E9rard_FTRD/DMI/REN'?=" Cc: Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Sun, 23 Nov 2003 06:11:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-index: AcOvk9QY7fErcwuYRI2/oFuzWzxiXQAdmRLwAG/+hyA= In-Reply-To: <6F704D0B4CD23044990B4F8999F463DD40B414@ftrdmel1.rd.francetelecom.fr> X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Gerard Your results sound very interesting. Is there a reference/ web site you = can quote to read more about your work?=20 Thank you, Vinay -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of = BABONNEAU G=E9rard FTRD/DMI/REN Sent: Friday, November 21, 2003 7:54 AM To: Rosen, Brian; Phelan, Tom Cc: dccp@ietf.org; avt@ietf.org Subject: RE : [AVT] RE: [MMUSIC] DCCP Media Guide I had a carefull look at the draft. In my opinion, coding with two or more rates is only TCP compliant, and = it does'nt improve the video quality because the network losses have = disastrous effects (30% pictures loss for 3% packet loss). We (France Telecom R&D) = have developped a test bed with MPEG4/RTP/UDP hierarchical codec with 2 or = more layers for the video. A DSCP marking allows diffserv routers to choose packets to be lost when a congestion occurs. We have a better quality = than other codecs in a lossy environment and it also works in multicast = sessions. Diffserv routers can also share the bandwidth between UDP and TCP flows, = to guarantee a good throughput for all the flows on the network.=20 G=E9rard BABONNEAU _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Nov 23 13:30:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26178 for ; Sun, 23 Nov 2003 13:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANyzo-0006AX-NC for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 13:30:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hANIU8Nt023709 for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 13:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANyzi-00069j-L3; Sun, 23 Nov 2003 13:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANyz6-00069C-Fj for avt@optimus.ietf.org; Sun, 23 Nov 2003 13:29:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26162 for ; Sun, 23 Nov 2003 13:29:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANyz4-0005sl-00 for avt@ietf.org; Sun, 23 Nov 2003 13:29:22 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ANyz3-0005si-00 for avt@ietf.org; Sun, 23 Nov 2003 13:29:22 -0500 Received: from [68.100.124.243] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 2060057; Sun, 23 Nov 2003 13:28:46 -0500 From: "Marshall Eubanks" Subject: Re: [AVT] RE: [MMUSIC] DCCP Media Guide To: Magnus Westerlund , "Rosen, Brian" Cc: "Phelan, Tom" , "'avt@ietf.org'" X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Sun, 23 Nov 2003 13:28:46 -0500 Message-ID: In-Reply-To: <3FBE31D6.2010602@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Fri, 21 Nov 2003 16:40:06 +0100 Magnus Westerlund wrote: > Hi Brian, > > I don't think that the people working with stability of the network are > sharing you view due to the implications that your claims results in. > > First, if a multi-media application transmitting data over a best-effort > IP network, i.e. without any QoS guarantees across the whole net that > its traffic will fit, it can definitely cause congestion collapse if the > mix becomes most, media, little TCP. Please read > draft-iab-congestion-01.txt for some discussion on this. Dear Magnus; Yes, I have read this. I also operate networks that are mostly UDP - typically 90%+ of the traffic. I have never seen true congestive collapse on these networks. Never. The typical paper that I have seen that deals with post 1987 congestion collapse hypotheses a UDP flow that is too large to fit in a end to end "pipe" that is subject to several bottlenecks, with the second being smaller than the first. The UDP packets clog up the first bottleneck, and are then dropped on the second. Since the packets dropped on the second bottleneck are wasted, this lowers the goodput of the first bottleneck, in principle to as near zero as you want. Note that this is very different from the 1987 congestive collapse where congestion causes the number of retrials and control packets to increase, until they dominate the available bandwidth - and this "auto-congestion" causes the link goodput to vanish. This UDP congestion collapse is _not_ a run-away situation like the original case. From RFC896 : ------- Even with the better adaptive host retransmission algorithms, though, a sudden load on the net can cause the round-trip time to rise faster than the sending hosts measurements of round-trip time can be updated. Such a load occurs when a new bulk transfer, such a file transfer, begins and starts filling a large window. Should the round-trip time exceed the maximum retransmission interval for any host, that host will begin to introduce more and more copies of the same datagrams into the net. The network is now in seri- ous trouble. Eventually all available buffers in the switching nodes will be full and packets must be dropped. The round-trip time for packets that are delivered is now at its maximum. Hosts are sending each packet several times, and eventually some copy of each packet arrives at its destination. This is congestion collapse. This condition is stable. Once the saturation point has been reached, if the algorithm for selecting packets to be dropped is fair, the network will continue to operate in a degraded condi- tion. In this condition every packet is being transmitted several times and throughput is reduced to a small fraction of normal. We have pushed our network into this condition experi- mentally and observed its stability. It is possible for round- trip time to become so large that connections are broken because the hosts involved time out. ------- This run-away collapse was what TCP Reno was introduced to fix. I have never seen a claim that excess UDP could cause this type of behavior in the TCP + UDP system using modern TCP algorithms, and frankly regard use of the term congestion collapse in the present context as being misleading. Again, I have never seen anything like this on a network I operate or monitor. There can, of course, be "congestion events", where the TCP + UDP is overfilling the available bandwidth. These stop immediately when the offending flows do. Why is this not a problem in practice ? 1.) For sources : Because the throughput / goodput definition is arbitrary - it is a global metric, when a local one would be more appropriate. Suppose I am running a source network. I can easily arrange for the sum of all of my sources to be < my link bandwidth. So, my network is always happy, at least outbound. Let's say that I am sourcing high bit rate video. Let's say that for some reason every viewer is trying to get these video's through a dial up modem. Now, they will not be happy, and the vast majority of the outbound packets will be dropped at the user side. By definitions such as http://www.ietf.org/internet-drafts/draft-iab-congestion-01.txt Section 3.1 my network is experiencing congestion collapse (most packets going out my links are wasted), even though locally I can see no signs of it. (My clients may not be happy, and I may want to give preference to non-dial-up users, but that is a different matter and I would argue out of scope.) 2.) For Sinks : Because UDP flows (except for DOS attacks) are self regulating. If I try and put 10 Mbps of UDP through a 30 kbps link, I will stop quickly. I in fact see this all of the time - and I bet many people on this list have tried to watch a video through a connection at home or over a T1 only to realize that the packet losses are just too high and stopped the process. This is clearly not a run-away situation and I would again argue that the use of the term congestion collapse to describe it is inappropriate. I of course, fully support the recommendations of draft-iab-congestion-01.txt and elsewhere to drop UDP sessions or layers in the case of excessive loss, which tends to be set very high (30% packet loss in the case of draft-iab-congestion-01.txt, which is long past the point where most media players will time out and users will leave in my experience). Since we are not talking about a run-away collapse, then any problems that are not self regulating can be dealt with administratively - which is common practice, especially on college campus networks. So we have - Something that is not a run-away situation, despite the re-use of terms that may give that impression and - Something that exists on real networks and is dealt with routinely already without causing undue problems. > > Some comments to your assertions. > > Rosen, Brian wrote: > > Phillipe > > > > You have made invalid assumptions: > > 1. That audio/video media data rates will be changed dynamically > > as network traffic changes. This is very unlikely. It may > > be that you get so much loss that you drop to a lower data > > rate, although I suspect that will be rare. When you do, > > you will never revert to the higher rate. This is because > > humans hate to see the change, and minimizing changes is > > more desirable than keeping average quality higher. > > First you agree that it is possible to change the rate. Secondly I May be possible. There can be real costs in doing this, and it may not be practical in many cases. > understand that the there are implications on switching rate, i.e. > quality to often, however there are reasons for switching up when the > quality gain of a switch if being possible to keep the new rate is clear. > > > > > 2. Real Time apps have no interest in being "fair". They are all > > or nothing. If you admit them to the network, you expect > > the streams to be maintained. If you can't maintain them, > > don't start them. They don't want to be fair to TCP, and > > they > > don't want to be fair to other RTP. They just want to send > > data at the rate they were advised to do by signalling. > > They can tolerate some loss. Misordering=loss. Duplicates= > > wasted bandwith. That's a whole lot different from TCP > > traffic. > > > > Yes, I agree that the application has no interest in being fair. However > using best effort networks requires one to being reasonably fair. If one > are not, the combination of several of media application can totally > destroy things for them self. > This is commonly said, but I would argue is routinely shown to be not true in practice. > > I can imagine working on protocols which allowed CBR and "best effort" > > traffic to better coexist, but I think it's only possible if the best > > effort traffic recognized the presence of the CBR traffic and reacted > > appropriately. Otherwise, you need to use QoS mechanisms to separate > > the traffic. > > What says that the media traffic is more important that the traffic > going over TCP? > The network administrator decides this yeah or nay. Since there is no danger of a run-away collapse, this is the appropriate level for this decision. Even for TCP flows, there are all sorts of ways that network admins can and do show preference, so fairness is something of an illusion there as well. It may well be that there are networks (say, mobile IP), where excessive use of UDP could cause a true congestive collapse (i.e., a run-away of useless traffic). If so, then I would argue that should be demonstrated clearly, and then be addressed for those networks specifically. In the absence of this I would be very careful to impose apparently innocent conditions which, if actually followed, would kill most real time media distribution over the Internet. As I hate to complain without offering alternatives, here is my definition of UDP fairness and how to achieve it : UDP flows should not significantly increase the packet loss rate on any link that they transverse. A UDP flow or flows from an application that do significantly increase the packet loss rate on a link MUST either be dropped or reduced in bandwidth on that link until the excess packet loss rate on the link is reduced to an acceptable level. Of course, averaging times and acceptable loss changes have to be defined - I would suggest 5 RTT's and 1%. > > Cheers > > Magnus Westerlund Regards Marshall Eubanks > > 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 exim@www1.ietf.org Sun Nov 23 19:38:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05942 for ; Sun, 23 Nov 2003 19:38:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4jy-0002oM-34 for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 19:38:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO0cAbi010759 for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 19:38:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4jp-0002lu-CK; Sun, 23 Nov 2003 19:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4jG-0002d2-8V for avt@optimus.ietf.org; Sun, 23 Nov 2003 19:37:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05920 for ; Sun, 23 Nov 2003 19:37:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4jE-00022K-00 for avt@ietf.org; Sun, 23 Nov 2003 19:37:24 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AO4jE-000229-00 for avt@ietf.org; Sun, 23 Nov 2003 19:37:24 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61392 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AO4ij-0004yg-00; Mon, 24 Nov 2003 00:36:53 +0000 Date: Mon, 24 Nov 2003 00:36:58 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com Message-Id: <20031124003658.7c89050c.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Last call for review: draft-jones-avt-audio-t38-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is to announce a last call for comments on the audio/t38 MIME type registration. Please send comments to the mailing list by Friday 28th November 2003. If no substantive comments are received by this time we shall recommend the IESG publish this draft as a Proposed standard RFC, conditional on the publication of the amended version of T.38 by the ITU. Colin ------- Forwarded message: >Date: Wed, 19 Nov 2003 15:25:59 -0500 >From: Internet-Drafts@ietf.org >To: IETF-Announce: >Cc: avt@ietf.org >Subject: [AVT] I-D ACTION:draft-jones-avt-audio-t38-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Real-Time Facsimile (T.38) - audio/t38 MIME > Sub-type Registration > Author(s) : P. Jones > Filename : draft-jones-avt-audio-t38-02.txt > Pages : 6 > Date : 2003-11-19 > > This document defines the MIME sub-type audio/t38. The packetization > and usage of this MIME type, which is intended for use within SDP, is > specified within ITU-T Recommendation T.38. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-02.txt ... ------- End of Forwarded Message -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Nov 23 20:02:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06346 for ; Sun, 23 Nov 2003 20:02:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO577-0003Qf-2H for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 20:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO125pK013178 for avt-archive@odin.ietf.org; Sun, 23 Nov 2003 20:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO572-0003Pz-Ss; Sun, 23 Nov 2003 20:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO56d-0003Pi-NE for avt@optimus.ietf.org; Sun, 23 Nov 2003 20:01:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06324 for ; Sun, 23 Nov 2003 20:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO56b-0002Eb-00 for avt@ietf.org; Sun, 23 Nov 2003 20:01:33 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AO56b-0002D9-00 for avt@ietf.org; Sun, 23 Nov 2003 20:01:33 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61416 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AO567-00050K-00; Mon, 24 Nov 2003 01:01:03 +0000 Date: Mon, 24 Nov 2003 01:01:08 +0000 From: Colin Perkins To: "Paul E. Jones" Cc: avt@ietf.org, magnus.westerlund@ericsson.com Subject: Re: [AVT] Re: I-D ACTION:draft-jones-avt-text-red-00.txt Message-Id: <20031124010108.41dbc28e.csp@csperkins.org> In-Reply-To: <034d01c3affe$c1c5de30$0401a8c0@berlin> References: <200311192026.PAA09590@ietf.org> <034d01c3affe$c1c5de30$0401a8c0@berlin> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul, all, Looks good -- I noticed two minor nits: reference [2] is not actually referenced anywhere in the draft, and there is a Microsoft smart quote in Reference 1. I suggest we take this as an AVT work item, and progress it quickly. If any group member objects to this becoming a work item, please send your comment to this list. If there are no objections, I suggest this is submitted as draft-ietf-avt-text-red-00.txt at the end of the week, with my comments above corrected. Colin --> "Paul E. Jones" writes: > Folks, > > I just wanted to bring this particular document to your attention. > During the review of RFC 2793bis, it was proposed by several folks that > we extract the text/red MIME sub-type registration from that document and > publish it as a separate document. Thus, I've put for this individual > contribution honor those requests. > > You'll note that I made reference to RFC 2793. The rationale is that > this registration should have already been done and we do not necessarily > want the publication of the revisions RFC 2793 to hinder the registration > of this MIME sub-type. In any case, I'm open to changing the references, > especially if they're both published at about the same time. > > Please review this document and provide any comments. > > Thanks, > Paul > > ----- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, November 19, 2003 3:26 PM > Subject: I-D ACTION:draft-jones-avt-text-red-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Registration of the text/red MIME Sub-Type > > Author(s) : P. Jones > > Filename : draft-jones-avt-text-red-00.txt > > Pages : 5 > > Date : 2003-11-19 > > > > This document defines the text/red MIME sub-type. The packetization > > and usage of this MIME type, which is intended for use within SDP, is > > specified within RFC 2198 and RFC 2793, respectively. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jones-avt-text-red-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > 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-jones-avt-text-red-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-jones-avt-text-red-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 -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 24 09:50:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10049 for ; Mon, 24 Nov 2003 09:50:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI2U-0006Sj-Sr for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 09:50:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOEoAKh024837 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 09:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI2M-0006Rg-3c; Mon, 24 Nov 2003 09:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOI21-0006QE-1n for avt@optimus.ietf.org; Mon, 24 Nov 2003 09:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10035 for ; Mon, 24 Nov 2003 09:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOI1z-0006GS-00 for avt@ietf.org; Mon, 24 Nov 2003 09:49:39 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AOI1y-0006Fz-00 for avt@ietf.org; Mon, 24 Nov 2003 09:49:38 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12849; Mon, 24 Nov 2003 09:49:06 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06309; Mon, 24 Nov 2003 09:49:07 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Nov 2003 09:49:06 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6106@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Magnus Westerlund'" Cc: "Phelan, Tom" , "'avt@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Mon, 24 Nov 2003 09:49:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Magnus I don't think the people working on the stability of the network understand what they are proposing, or they wouldn't be proposing it, except for Tom, who probably understands what the effect of 2X bandwidth (when congestion was not occurring), and figures if that's the only knob he's got, then he turns it far enough to make his app work, and since he doesn't violate any rules, all is well. I don't agree. I think that, as Marshall observes, RTP media flows tend to be self policing, and in any event, following the IAB recommendation of dropping the flow if excessive packet loss is observed will have the same effect - congestion collapse will not occur. I think that we should stop thinking that we need anything else to prevent congestion collapse. I think the real question this thread is addressing is whether DCCP is at all suitable for real time flows. I think the answer is no. I think we should try see if we can reach consensus on this. Given what has been said on this thread, is there anyone left who thinks DCCP is suitable for RTP flows? This leaves us in a quandary, which, I think, is what Tom was trying to avoid. If DCCP is not suitable, is there any way to hold off the greedy TCP? This is the question Mike raises. It's not an issue of congestion collapse, it is the issue of "fairness". My own feeling is that fairness to RTP is let the flow go through or don't. There exists a variety of ways to vary the rate, but none of them are useful. Have you ever actually listened (or watched) a media stream with varying rate? I have, several times, several different algorithms. It sucks, to put it mildly. Unless you have some evidence that there exists an algorithm which does not annoy a user when the rate changes, I suspect our experience will be the common one - you will go down, once, and never go back up. I expect even this will be very rare. Much more common is that you will try one rate, and if you don't get good results, the call/stream will be dropped and tried again. There are lots of algorithms to vary rates. There are no ways I know to vary quality, how ever it is done, and not be very distracting to a user. Unless there is some kind of concealment mechanism I am not aware of, it just won't be used, regardless of how clever the algorithm is, and how bandwidth efficient it is. So, to me, the idea that RTP reacts to whatever else is happening in any way other than dropping the entire stream is not credible. That means there is no real rate control for RTP, TCP friendly or otherwise. (I'll just use RTP vs TCP, even though we all understand that RTP is carried on some other transport at the same level as TCP). So what does it mean to be "fair"? For RTP, being fair to TCP (or other best effort traffic) is to not get started, or get dropped if congestion is excessive For TCP, being fair to RTP (or other constant rate traffic) is to not be greedy. This is why QoS mechanisms work. If you put RTP ahead of TCP, and use admission control to limit the amount of RTP, everything works. If you don't have a QoS mechanism, you can still perform admission control to the RTP flows to enforce RTP fairness on TCP, but you need to put some kind of mechanism to allow TCP to be fair to RTP. I'm happy to work on mechanisms that would afford effective admission control in reaction to best effort traffic, but only if there is a commitment to fix TCP. Brian > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, November 21, 2003 10:40 AM > To: Rosen, Brian > Cc: Phelan, Tom; 'avt@ietf.org' > Subject: Re: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Hi Brian, > > I don't think that the people working with stability of the > network are > sharing you view due to the implications that your claims results in. > > First, if a multi-media application transmitting data over a > best-effort > IP network, i.e. without any QoS guarantees across the whole net that > its traffic will fit, it can definitely cause congestion > collapse if the > mix becomes most, media, little TCP. Please read > draft-iab-congestion-01.txt for some discussion on this. > > Some comments to your assertions. > > Rosen, Brian wrote: > > Phillipe > > > > You have made invalid assumptions: > > 1. That audio/video media data rates will be changed dynamically > > as network traffic changes. This is very > unlikely. It may > > be that you get so much loss that you drop to a > lower data > > rate, although I suspect that will be rare. > When you do, > > you will never revert to the higher rate. This > is because > > humans hate to see the change, and minimizing > changes is > > more desirable than keeping average quality higher. > > First you agree that it is possible to change the rate. Secondly I > understand that the there are implications on switching rate, i.e. > quality to often, however there are reasons for switching up when the > quality gain of a switch if being possible to keep the new > rate is clear. > > > > > 2. Real Time apps have no interest in being "fair". > They are all > > or nothing. If you admit them to the network, you expect > > the streams to be maintained. If you can't > maintain them, > > don't start them. They don't want to be fair > to TCP, and > > they > > don't want to be fair to other RTP. They just > want to send > > data at the rate they were advised to do by signalling. > > They can tolerate some loss. Misordering=loss. > Duplicates= > > wasted bandwith. That's a whole lot different from TCP > > traffic. > > > > Yes, I agree that the application has no interest in being > fair. However > using best effort networks requires one to being reasonably > fair. If one > are not, the combination of several of media application can totally > destroy things for them self. > > > I can imagine working on protocols which allowed CBR and > "best effort" > > traffic to better coexist, but I think it's only possible > if the best > > effort traffic recognized the presence of the CBR traffic > and reacted > > appropriately. Otherwise, you need to use QoS mechanisms > to separate > > the traffic. > > What says that the media traffic is more important that the traffic > going over TCP? > > > 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 exim@www1.ietf.org Mon Nov 24 10:36:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13036 for ; Mon, 24 Nov 2003 10:36:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIlX-0002cz-9j for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 10:36:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOFahIQ010100 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 10:36:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIkr-0002VB-D7; Mon, 24 Nov 2003 10:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIkB-0002QQ-Ns for avt@optimus.ietf.org; Mon, 24 Nov 2003 10:35:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12895 for ; Mon, 24 Nov 2003 10:35:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOIk9-0006wl-00 for avt@ietf.org; Mon, 24 Nov 2003 10:35:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOIk8-0006vZ-00 for avt@ietf.org; Mon, 24 Nov 2003 10:35:16 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2003 07:35:30 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAOFY6At008945; Mon, 24 Nov 2003 07:34:07 -0800 (PST) Received: from [10.32.245.146] (stealth-10-32-245-146.cisco.com [10.32.245.146]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AKF10144; Mon, 24 Nov 2003 07:34:05 -0800 (PST) Date: Mon, 24 Nov 2003 10:34:01 -0500 From: "David R. Oran" To: "Rosen, Brian" , "'Magnus Westerlund'" cc: "Phelan, Tom" , "'avt@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Message-ID: <693027781.1069670041@[10.32.245.146]> In-Reply-To: <313680C9A886D511A06000204840E1CF070B6106@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B6106@whq-msgusr-02.pit.comm s.marconi.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========9BE30690F4BA0F61594B==========" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --==========9BE30690F4BA0F61594B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Been watching this thread. Throwing caution to the wind and jumping in... --On Monday, November 24, 2003 9:49 AM -0500 "Rosen, Brian"=20 wrote: > Magnus > > I don't think the people working on the stability of the network > understand what they are proposing, or they wouldn't be proposing it, > except for Tom, who probably understands what the effect of 2X > bandwidth (when congestion was not occurring), and figures if that's > the only knob he's got, then he turns it far enough to make his app work, > and since he doesn't violate any rules, all is well. > A factor of two of breathing room for a single low-rate audio session is=20 one thing. A factor of two on a multi-megabit video flow is quite another.=20 I think we need to take some factors into account: a) nearly all the deployed coders, both audio and video, are CBR. More=20 importantly, they have extremely limited dynamic range on packetization=20 period, and hence on PPS generated by a transmitter. Schemes which switch=20 coders based on feedback are possible, but don't help much with the PPS=20 part and run into the human factors problems Brian mentioned in an earlier=20 post. I'm not enough of an expert in this aspect to have a useful opinion,=20 except to say that if the results of switching coders is less annoying than = dropping lots of packets or dropping the whole flow, then it may still be=20 worthwhile. b) VBR coders are a possibility, but it is not clear that they have enough=20 dynamic range (2x for audio, maybe 3x for video) to make a significant dent = in congestion events. There is also the problem of whether they can adapt=20 quickly enough (i.e. 1 RTT) to play nice in a world with greedy TCPs that=20 go over the edge rather than throttle back gracefully using ECN. c) I suspect Tom's 2x bandwidth scheme would not be "necessary" if all the=20 TCPs did ECN. True or false? > I don't agree. I think that, as Marshall observes, RTP media flows > tend to be self policing, and in any event, following the IAB > recommendation of dropping the flow if excessive packet loss is observed > will have the same effect - congestion collapse will not occur. > I think that we should stop thinking that we need anything else to > prevent congestion collapse. > I agree with this, and this seems to cut to the fundamental architectural=20 fact-of-life - realtime media streams have very limited ability to adapt to = congestion. > I think the real question this thread is addressing is whether DCCP > is at all suitable for real time flows. I think the answer is no. > I think we should try see if we can reach consensus on this. > Given what has been said on this thread, is there anyone left who > thinks DCCP is suitable for RTP flows? > I suspect that DCCP will be of very limited utility for *interactive*=20 realtime flows, where end-to-end delay has to fit within human interaction=20 timescales (1/4 second or less). However, there's a baby in the bath water, = which is realtime media streaming/distribution, where DCCP may be a big win = compared to either UDP or TCP encapsulation for RTP. > This leaves us in a quandary, which, I think, is what Tom was trying to > avoid. If DCCP is not suitable, is there any way to hold off the greedy > TCP? This is the question Mike raises. It's not an issue of congestion > collapse, it is the issue of "fairness". > > My own feeling is that fairness to RTP is let the flow go through or > don't. There exists a variety of ways to vary the rate, but none of them > are useful. I mostly agree with this. > Have you ever actually listened (or watched) a media stream with varying > rate? I have, several times, several different algorithms. It sucks, to > put it mildly. The question is whether it sucks worse than persistent x% loss or sucks=20 worse than denial of service. At some loss/delay level it is in fact better = to drop the flow than try to adapt. I think we need to think in terms of=20 which impairment is worse rather than trying to convince people that=20 adaptation will be good enough so people don't notice. > Unless you have some evidence that there exists an > algorithm which does not annoy a user when the rate changes, I suspect > our experience will be the common one - you will go down, once, and > never go back up. I expect even this will be very rare. Much more > common is that you will try one rate, and if you don't get good results, > the call/stream will be dropped and tried again. There are lots of > algorithms to vary rates. There are no ways I know to vary quality, how > ever it is done, > and not be very distracting to a user. Unless there is some kind of > concealment mechanism I am not aware of, it just won't be used, = regardless > of how clever the algorithm is, and how bandwidth efficient it is. > > So, to me, the idea that RTP reacts to whatever else is happening in any > way other than dropping the entire stream is not credible. That means > there is no real rate control for RTP, TCP friendly or otherwise. > (I'll just use RTP vs TCP, even though we all understand that RTP is > carried on some other transport at the same level as TCP). > I'm not quite as pessimistic as Brian but I believe the onus is on those=20 who propose congestion adaptation schemes to show that they work from a=20 human-factors perspective rather than on the media folks to put up with=20 whatever loss and delay behavior congestion adaptation forces upon them. > So what does it mean to be "fair"? > For RTP, being fair to TCP (or other best effort traffic) is to > not get started, or get dropped if congestion is excessive > For TCP, being fair to RTP (or other constant rate traffic) is > to not be greedy. > > This is why QoS mechanisms work. If you put RTP ahead of TCP, > and use admission control to limit the amount of RTP, everything works. Yes...but...we'd like to have less state-heavy admission control schemes=20 which do measurement-based admission control, which puts us to some extent=20 right back where we started. > If you don't have a QoS mechanism, you can still perform admission > control to the RTP flows to enforce RTP fairness on TCP, but you need > to put some kind of mechanism to allow TCP to be fair to RTP. I'm happy > to work on mechanisms that would afford effective admission control > in reaction to best effort traffic, but only if there is a commitment > to fix TCP. > I'd like to understand why ECN won't bring the TCPs down enough in=20 greediness to avoid badly increasing the delay/loss behavior of the RTP=20 flows. Dave. > Brian > > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Friday, November 21, 2003 10:40 AM >> To: Rosen, Brian >> Cc: Phelan, Tom; 'avt@ietf.org' >> Subject: Re: [AVT] RE: [MMUSIC] DCCP Media Guide >> >> >> Hi Brian, >> >> I don't think that the people working with stability of the >> network are >> sharing you view due to the implications that your claims results in. >> >> First, if a multi-media application transmitting data over a >> best-effort >> IP network, i.e. without any QoS guarantees across the whole net that >> its traffic will fit, it can definitely cause congestion >> collapse if the >> mix becomes most, media, little TCP. Please read >> draft-iab-congestion-01.txt for some discussion on this. >> >> Some comments to your assertions. >> >> Rosen, Brian wrote: >> > Phillipe >> > >> > You have made invalid assumptions: >> > 1. That audio/video media data rates will be changed dynamically >> > as network traffic changes. This is very >> unlikely. It may >> > be that you get so much loss that you drop to a >> lower data >> > rate, although I suspect that will be rare. >> When you do, >> > you will never revert to the higher rate. This >> is because >> > humans hate to see the change, and minimizing >> changes is >> > more desirable than keeping average quality higher. >> >> First you agree that it is possible to change the rate. Secondly I >> understand that the there are implications on switching rate, i.e. >> quality to often, however there are reasons for switching up when the >> quality gain of a switch if being possible to keep the new >> rate is clear. >> >> > >> > 2. Real Time apps have no interest in being "fair". >> They are all >> > or nothing. If you admit them to the network, you expect >> > the streams to be maintained. If you can't >> maintain them, >> > don't start them. They don't want to be fair >> to TCP, and >> > they >> > don't want to be fair to other RTP. They just >> want to send >> > data at the rate they were advised to do by signalling. >> > They can tolerate some loss. Misordering=3Dloss. >> Duplicates=3D >> > wasted bandwith. That's a whole lot different from TCP >> > traffic. >> > >> >> Yes, I agree that the application has no interest in being >> fair. However >> using best effort networks requires one to being reasonably >> fair. If one >> are not, the combination of several of media application can totally >> destroy things for them self. >> >> > I can imagine working on protocols which allowed CBR and >> "best effort" >> > traffic to better coexist, but I think it's only possible >> if the best >> > effort traffic recognized the presence of the CBR traffic >> and reacted >> > appropriately. Otherwise, you need to use QoS mechanisms >> to separate >> > the traffic. >> >> What says that the media traffic is more important that the traffic >> going over TCP? >> >> >> 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 ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com --==========9BE30690F4BA0F61594B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP8Ik6o1mhLZU3SrmEQIh2QCghZTOgY3QAQKWSo3Hv9AQ0zLu3KYAmgPB qoc5UvOsAMd2LYLXcj+uyFUv =S1IP -----END PGP SIGNATURE----- --==========9BE30690F4BA0F61594B==========-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 24 11:02:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14243 for ; Mon, 24 Nov 2003 11:02:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJA6-0004xk-3P for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 11:02:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOG255H019008 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 11:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJA1-0004uo-D8; Mon, 24 Nov 2003 11:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJ9C-0004rI-15 for avt@optimus.ietf.org; Mon, 24 Nov 2003 11:01:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14064 for ; Mon, 24 Nov 2003 11:00:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJ99-0007LP-00 for avt@ietf.org; Mon, 24 Nov 2003 11:01:07 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOJ98-0007LK-00 for avt@ietf.org; Mon, 24 Nov 2003 11:01:06 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAOG11I2029368; Mon, 24 Nov 2003 17:01:01 +0100 (MET) Received: from ericsson.com (sealwp02-147.sw.ericsson.se [153.88.142.147]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XRB1QV81; Mon, 24 Nov 2003 17:01:00 +0100 Message-ID: <3FC1BB64.4000806@ericsson.com> Date: Mon, 24 Nov 2003 09:03:48 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: alan@telchemy.com CC: "'Romascanu, Dan (Dan)'" , avt@ietf.org, "'Bert Wijnen (E-mail)'" Subject: Re: [AVT] RTP MIB Extensions References: <006401c3b05a$670ac490$6801a8c0@telchemy.com> In-Reply-To: <006401c3b05a$670ac490$6801a8c0@telchemy.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Alan, Based on the discussion in this thread, and the dependency that the XR MIB extension will have on the core (as I see it), it seems necessary to make the extension dependent on a updated core. This means that the work can be performed in parallel, but the XR MIB extension can't go forward until the updated core is also available. Cheers Magnus Westerlund _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 24 11:02:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14242 for ; Mon, 24 Nov 2003 11:02:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJA6-0004y0-4I for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 11:02:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOG26TO019011 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 11:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJA0-0004ug-Ql; Mon, 24 Nov 2003 11:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJ9A-0004rC-CD for avt@optimus.ietf.org; Mon, 24 Nov 2003 11:01:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14061 for ; Mon, 24 Nov 2003 11:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJ97-0007LJ-00 for avt@ietf.org; Mon, 24 Nov 2003 11:01:05 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOJ96-0007LG-00 for avt@ietf.org; Mon, 24 Nov 2003 11:01:05 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAOG12Ss008670; Mon, 24 Nov 2003 17:01:02 +0100 (MET) Received: from ericsson.com (sealwp02-147.sw.ericsson.se [153.88.142.147]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XRGXHRVM; Mon, 24 Nov 2003 17:01:03 +0100 Message-ID: <3FC1D887.4050400@ericsson.com> Date: Mon, 24 Nov 2003 11:08:07 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: paulej@packetizer.com CC: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-jones-avt-text-red-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Paul, I have a few comments and question. 1. In a WG document version you need to include the short copyright statement on the first page. 2. The abstract and first chapter: Is really usage of this mime type specified in RFC 2793? I thought this was only one possible usage of this MIME type. Technically this mime type could be used with any other format using the text and fulfilling any other requirement. 3. Shouldn't there be a chapter on mapping to SDP? As there are some tricks in relation to the defined MIME parameter "pt" and SDP. I think this is in line with the current explicit declaration of SDP usage. Cheers Magnus _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 24 12:08:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16547 for ; Mon, 24 Nov 2003 12:08:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKBy-0001hW-6v for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 12:08:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOH854x006483 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 12:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKBt-0001ei-HF; Mon, 24 Nov 2003 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKBI-0001Wn-5M for avt@optimus.ietf.org; Mon, 24 Nov 2003 12:07:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16502 for ; Mon, 24 Nov 2003 12:07:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKBG-0000WS-00 for avt@ietf.org; Mon, 24 Nov 2003 12:07:22 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AOKBF-0000W7-00 for avt@ietf.org; Mon, 24 Nov 2003 12:07:21 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA19393; Mon, 24 Nov 2003 12:06:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02347; Mon, 24 Nov 2003 12:06:50 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Nov 2003 12:06:50 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6111@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'David R. Oran'" , "'Magnus Westerlund'" Cc: "Phelan, Tom" , "'avt@ietf.org'" Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Mon, 24 Nov 2003 12:06:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , My experience is that changing rate more than once is much more annoying than changing it several times. In our system, a percentage of errors is less annoying than a single rate change. Go over that percentage (which of course is somewhat variable from human to human), and you would prefer to drop the rate. YCMV (C=codec). Neither is "acceptable", in the sense of what you want to see, and what you expect to see. If that's the expectation we create for VoIP or VideoOverIP, then we had better be prepared for disappointing usage except in the case where free trumps quality. I don't see why DCCP is of significant value to a real time, non interactive stream. Why is it better than UDP or TCP? I think that TRFC is still a killer that extra buffering won't fix. Brian > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Monday, November 24, 2003 10:34 AM > To: Rosen, Brian; 'Magnus Westerlund' > Cc: Phelan, Tom; 'avt@ietf.org' > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Been watching this thread. Throwing caution to the wind and > jumping in... > > --On Monday, November 24, 2003 9:49 AM -0500 "Rosen, Brian" > wrote: > > > Magnus > > > > I don't think the people working on the stability of the network > > understand what they are proposing, or they wouldn't be > proposing it, > > except for Tom, who probably understands what the effect of 2X > > bandwidth (when congestion was not occurring), and figures if that's > > the only knob he's got, then he turns it far enough to make > his app work, > > and since he doesn't violate any rules, all is well. > > > A factor of two of breathing room for a single low-rate audio > session is > one thing. A factor of two on a multi-megabit video flow is > quite another. > I think we need to take some factors into account: > > a) nearly all the deployed coders, both audio and video, are > CBR. More > importantly, they have extremely limited dynamic range on > packetization > period, and hence on PPS generated by a transmitter. Schemes > which switch > coders based on feedback are possible, but don't help much > with the PPS > part and run into the human factors problems Brian mentioned > in an earlier > post. I'm not enough of an expert in this aspect to have a > useful opinion, > except to say that if the results of switching coders is less > annoying than > dropping lots of packets or dropping the whole flow, then it > may still be > worthwhile. > > b) VBR coders are a possibility, but it is not clear that > they have enough > dynamic range (2x for audio, maybe 3x for video) to make a > significant dent > in congestion events. There is also the problem of whether > they can adapt > quickly enough (i.e. 1 RTT) to play nice in a world with > greedy TCPs that > go over the edge rather than throttle back gracefully using ECN. > > c) I suspect Tom's 2x bandwidth scheme would not be > "necessary" if all the > TCPs did ECN. True or false? > > > I don't agree. I think that, as Marshall observes, RTP media flows > > tend to be self policing, and in any event, following the IAB > > recommendation of dropping the flow if excessive packet > loss is observed > > will have the same effect - congestion collapse will not occur. > > I think that we should stop thinking that we need anything else to > > prevent congestion collapse. > > > I agree with this, and this seems to cut to the fundamental > architectural > fact-of-life - realtime media streams have very limited > ability to adapt to > congestion. > > > I think the real question this thread is addressing is whether DCCP > > is at all suitable for real time flows. I think the answer is no. > > I think we should try see if we can reach consensus on this. > > Given what has been said on this thread, is there anyone left who > > thinks DCCP is suitable for RTP flows? > > > I suspect that DCCP will be of very limited utility for *interactive* > realtime flows, where end-to-end delay has to fit within > human interaction > timescales (1/4 second or less). However, there's a baby in > the bath water, > which is realtime media streaming/distribution, where DCCP > may be a big win > compared to either UDP or TCP encapsulation for RTP. > > > This leaves us in a quandary, which, I think, is what Tom > was trying to > > avoid. If DCCP is not suitable, is there any way to hold > off the greedy > > TCP? This is the question Mike raises. It's not an issue > of congestion > > collapse, it is the issue of "fairness". > > > > My own feeling is that fairness to RTP is let the flow go through or > > don't. There exists a variety of ways to vary the rate, but > none of them > > are useful. > I mostly agree with this. > > > Have you ever actually listened (or watched) a media stream > with varying > > rate? I have, several times, several different algorithms. > It sucks, to > > put it mildly. > The question is whether it sucks worse than persistent x% > loss or sucks > worse than denial of service. At some loss/delay level it is > in fact better > to drop the flow than try to adapt. I think we need to think > in terms of > which impairment is worse rather than trying to convince people that > adaptation will be good enough so people don't notice. > > > Unless you have some evidence that there exists an > > algorithm which does not annoy a user when the rate > changes, I suspect > > our experience will be the common one - you will go down, once, and > > never go back up. I expect even this will be very rare. Much more > > common is that you will try one rate, and if you don't get > good results, > > the call/stream will be dropped and tried again. There are lots of > > algorithms to vary rates. There are no ways I know to vary > quality, how > > ever it is done, > > and not be very distracting to a user. Unless there is some kind of > > concealment mechanism I am not aware of, it just won't be > used, regardless > > of how clever the algorithm is, and how bandwidth efficient it is. > > > > So, to me, the idea that RTP reacts to whatever else is > happening in any > > way other than dropping the entire stream is not credible. > That means > > there is no real rate control for RTP, TCP friendly or otherwise. > > (I'll just use RTP vs TCP, even though we all understand that RTP is > > carried on some other transport at the same level as TCP). > > > I'm not quite as pessimistic as Brian but I believe the onus > is on those > who propose congestion adaptation schemes to show that they > work from a > human-factors perspective rather than on the media folks to > put up with > whatever loss and delay behavior congestion adaptation forces > upon them. > > > So what does it mean to be "fair"? > > For RTP, being fair to TCP (or other best effort traffic) is to > > not get started, or get dropped if congestion > is excessive > > For TCP, being fair to RTP (or other constant rate traffic) is > > to not be greedy. > > > > This is why QoS mechanisms work. If you put RTP ahead of TCP, > > and use admission control to limit the amount of RTP, > everything works. > Yes...but...we'd like to have less state-heavy admission > control schemes > which do measurement-based admission control, which puts us > to some extent > right back where we started. > > > If you don't have a QoS mechanism, you can still perform admission > > control to the RTP flows to enforce RTP fairness on TCP, > but you need > > to put some kind of mechanism to allow TCP to be fair to > RTP. I'm happy > > to work on mechanisms that would afford effective admission control > > in reaction to best effort traffic, but only if there is a > commitment > > to fix TCP. > > > I'd like to understand why ECN won't bring the TCPs down enough in > greediness to avoid badly increasing the delay/loss behavior > of the RTP > flows. > > Dave. > > > Brian > > > > > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Friday, November 21, 2003 10:40 AM > >> To: Rosen, Brian > >> Cc: Phelan, Tom; 'avt@ietf.org' > >> Subject: Re: [AVT] RE: [MMUSIC] DCCP Media Guide > >> > >> > >> Hi Brian, > >> > >> I don't think that the people working with stability of the > >> network are > >> sharing you view due to the implications that your claims > results in. > >> > >> First, if a multi-media application transmitting data over a > >> best-effort > >> IP network, i.e. without any QoS guarantees across the > whole net that > >> its traffic will fit, it can definitely cause congestion > >> collapse if the > >> mix becomes most, media, little TCP. Please read > >> draft-iab-congestion-01.txt for some discussion on this. > >> > >> Some comments to your assertions. > >> > >> Rosen, Brian wrote: > >> > Phillipe > >> > > >> > You have made invalid assumptions: > >> > 1. That audio/video media data rates will be changed dynamically > >> > as network traffic changes. This is very > >> unlikely. It may > >> > be that you get so much loss that you drop to a > >> lower data > >> > rate, although I suspect that will be rare. > >> When you do, > >> > you will never revert to the higher rate. This > >> is because > >> > humans hate to see the change, and minimizing > >> changes is > >> > more desirable than keeping average quality higher. > >> > >> First you agree that it is possible to change the rate. Secondly I > >> understand that the there are implications on switching rate, i.e. > >> quality to often, however there are reasons for switching > up when the > >> quality gain of a switch if being possible to keep the new > >> rate is clear. > >> > >> > > >> > 2. Real Time apps have no interest in being "fair". > >> They are all > >> > or nothing. If you admit them to the network, you expect > >> > the streams to be maintained. If you can't > >> maintain them, > >> > don't start them. They don't want to be fair > >> to TCP, and > >> > they > >> > don't want to be fair to other RTP. They just > >> want to send > >> > data at the rate they were advised to do by signalling. > >> > They can tolerate some loss. Misordering=loss. > >> Duplicates= > >> > wasted bandwith. That's a whole lot different from TCP > >> > traffic. > >> > > >> > >> Yes, I agree that the application has no interest in being > >> fair. However > >> using best effort networks requires one to being reasonably > >> fair. If one > >> are not, the combination of several of media application > can totally > >> destroy things for them self. > >> > >> > I can imagine working on protocols which allowed CBR and > >> "best effort" > >> > traffic to better coexist, but I think it's only possible > >> if the best > >> > effort traffic recognized the presence of the CBR traffic > >> and reacted > >> > appropriately. Otherwise, you need to use QoS mechanisms > >> to separate > >> > the traffic. > >> > >> What says that the media traffic is more important that the traffic > >> going over TCP? > >> > >> > >> 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 > > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 24 12:29:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17569 for ; Mon, 24 Nov 2003 12:29:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKWD-0002b6-Lk for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 12:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHT1jV009952 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 12:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKWC-0002Zf-Lh; Mon, 24 Nov 2003 12:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKVN-0002Gj-AK for avt@optimus.ietf.org; Mon, 24 Nov 2003 12:28:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17457 for ; Mon, 24 Nov 2003 12:27:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKVL-0000t8-00 for avt@ietf.org; Mon, 24 Nov 2003 12:28:07 -0500 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1AOKVL-0000sf-00 for avt@ietf.org; Mon, 24 Nov 2003 12:28:07 -0500 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hAOHRPHW056327; Mon, 24 Nov 2003 09:27:25 -0800 (PST) (envelope-from casner@acm.org) Date: Mon, 24 Nov 2003 09:27:25 -0800 (PST) From: Stephen Casner To: "Phelan, Tom" cc: AVT WG Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide In-Reply-To: <693027781.1069670041@[10.32.245.146]> Message-ID: <20031124082020.P30994@oak.packetdesign.com> References: <313680C9A886D511A06000204840E1CF070B6106@whq-msgusr-02.pit.comm s.marconi.com> <693027781.1069670041@[10.32.245.146]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I think Tom's description of the problem as enabling DCCP to get its fair share vs. TCP has misdirected the thinking. The problem he identified was that TCP's bandwidth probing will cause some loss in the DCCP stream as well. Here is the key: that probing will cause exactly the same loss in an RTP/UDP stream. It is only DCCP's reaction to the loss that is a design question. For interactive (delay-sensitive) media, FEC may be an option for protecting against the isolated packet losses induced by TCP probing. This can be achieved with less than 2X bandwidth. But other than removing the FEC, and possibly shifting encodings, there is not much room for the media to accommodate any direction from DCCP to back off. As I've said more than once in DCCP WG meetings, these applications don't want to be congestion controlled. Unless there is policing in the network that causes performance with UDP to be worse than with DCCP, there is no motivation to change protocols. On the other hand, for streaming media to clients with significant buffer capacity, then the approach of sending at 2X rate (if the bottleneck allows) until the buffer is filled is a fine idea. During the 2X period, if DCCP says to back off by half, the application is still getting its necessary throughput. After the buffer is full, the rate will have to be 1X, but if DCCP says to back off from that as a result of TCP probing, the buffer will cover the period until the rate ramps back up. The rate can go over 1x again to refill the buffer, then back to 1X. This isn't a new idea. DCCP would just legitimize and standardize it. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 24 18:02:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08547 for ; Mon, 24 Nov 2003 18:02:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPia-0000ac-Oo for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 18:02:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAON28ZO002265 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 18:02:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPiT-0000Zv-Nz; Mon, 24 Nov 2003 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPho-0000ZH-CA for avt@optimus.ietf.org; Mon, 24 Nov 2003 18:01:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08486 for ; Mon, 24 Nov 2003 18:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOPhl-00005z-00 for avt@ietf.org; Mon, 24 Nov 2003 18:01:17 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AOPhl-00005w-00 for avt@ietf.org; Mon, 24 Nov 2003 18:01:17 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hAON1FBQ026482; Mon, 24 Nov 2003 18:01:15 -0500 Message-ID: <026501c3b2de$dcaa2d90$0401a8c0@berlin> From: "Paul E. Jones" To: "Colin Perkins" Cc: , References: <200311192026.PAA09590@ietf.org><034d01c3affe$c1c5de30$0401a8c0@berlin> <20031124010108.41dbc28e.csp@csperkins.org> Subject: Re: [AVT] Re: I-D ACTION:draft-jones-avt-text-red-00.txt Date: Mon, 24 Nov 2003 18:01:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin, Thanks. I've corrected both of those. I'll wait for advise on whether this should be re-published as an AVT working group item. Paul ----- Original Message ----- From: "Colin Perkins" To: "Paul E. Jones" Cc: ; Sent: Sunday, November 23, 2003 8:01 PM Subject: Re: [AVT] Re: I-D ACTION:draft-jones-avt-text-red-00.txt > Paul, all, > > Looks good -- I noticed two minor nits: reference [2] is not actually > referenced anywhere in the draft, and there is a Microsoft smart quote > in Reference 1. > > I suggest we take this as an AVT work item, and progress it quickly. > If any group member objects to this becoming a work item, please send > your comment to this list. If there are no objections, I suggest this > is submitted as draft-ietf-avt-text-red-00.txt at the end of the week, > with my comments above corrected. > > Colin > > > > > --> "Paul E. Jones" writes: > > Folks, > > > > I just wanted to bring this particular document to your attention. > > During the review of RFC 2793bis, it was proposed by several folks that > > we extract the text/red MIME sub-type registration from that document and > > publish it as a separate document. Thus, I've put for this individual > > contribution honor those requests. > > > > You'll note that I made reference to RFC 2793. The rationale is that > > this registration should have already been done and we do not necessarily > > want the publication of the revisions RFC 2793 to hinder the registration > > of this MIME sub-type. In any case, I'm open to changing the references, > > especially if they're both published at about the same time. > > > > Please review this document and provide any comments. > > > > Thanks, > > Paul > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Wednesday, November 19, 2003 3:26 PM > > Subject: I-D ACTION:draft-jones-avt-text-red-00.txt > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > Title : Registration of the text/red MIME Sub-Type > > > Author(s) : P. Jones > > > Filename : draft-jones-avt-text-red-00.txt > > > Pages : 5 > > > Date : 2003-11-19 > > > > > > This document defines the text/red MIME sub-type. The packetization > > > and usage of this MIME type, which is intended for use within SDP, is > > > specified within RFC 2198 and RFC 2793, respectively. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jones-avt-text-red-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > > > 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-jones-avt-text-red-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-jones-avt-text-red-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 > > > -- > Colin Perkins > csp@csperkins.org > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Nov 24 18:37:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11231 for ; Mon, 24 Nov 2003 18:37:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQFT-0002wt-0W for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 18:36:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAONa6Y6011319 for avt-archive@odin.ietf.org; Mon, 24 Nov 2003 18:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQFN-0002w1-QW; Mon, 24 Nov 2003 18:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQEb-0002vD-Uf for avt@optimus.ietf.org; Mon, 24 Nov 2003 18:35:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11155 for ; Mon, 24 Nov 2003 18:34:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQEY-0000ig-00 for avt@ietf.org; Mon, 24 Nov 2003 18:35:10 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AOQEY-0000id-00 for avt@ietf.org; Mon, 24 Nov 2003 18:35:10 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hAONZ7BQ028512; Mon, 24 Nov 2003 18:35:07 -0500 Message-ID: <027d01c3b2e3$98ca7030$0401a8c0@berlin> From: "Paul E. Jones" To: "Magnus Westerlund" Cc: References: <3FC1D887.4050400@ericsson.com> Date: Mon, 24 Nov 2003 18:31:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Comments on draft-jones-avt-text-red-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Magnus, > 1. In a WG document version you need to include the short copyright > statement on the first page. Can you point to a sample document and section? I tried to copy the text I found in other WG documents, though it would surprise me that I left something out. > 2. The abstract and first chapter: Is really usage of this mime type > specified in RFC 2793? I thought this was only one possible usage of > this MIME type. Technically this mime type could be used with any other > format using the text and fulfilling any other requirement. Your point is valid, as RFC 2793 might be just one of several documents that might specify the use of this. However, if I think of audio/red, I think of RFC 2198. I think what you're saying is that for use with SDP, 2198/2793 are apropos, but necessarily other applications that might use this mime sub-type. Since I have no other example, should I just say something along those lines? > 3. Shouldn't there be a chapter on mapping to SDP? As there are some > tricks in relation to the defined MIME parameter "pt" and SDP. I think > this is in line with the current explicit declaration of SDP usage. Yes, you're right. Essentially, it would follow chapter 3 of RFC 3555. I will create a chapter and simply refer to that text, if that's acceptable. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 02:50:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07212 for ; Tue, 25 Nov 2003 02:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOXxe-000204-AA for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 02:50:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP7oEAd007685 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 02:50:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOXxR-0001xo-TV; Tue, 25 Nov 2003 02:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOXwX-0001wU-BB for avt@optimus.ietf.org; Tue, 25 Nov 2003 02:49:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07175 for ; Tue, 25 Nov 2003 02:48:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOXwT-0007Mj-00 for avt@ietf.org; Tue, 25 Nov 2003 02:49:01 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOXwS-0007MV-00 for avt@ietf.org; Tue, 25 Nov 2003 02:49:00 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAP7mPI2026488; Tue, 25 Nov 2003 08:48:32 +0100 (MET) Received: from ericsson.com (sealwp02-136.sw.ericsson.se [153.88.142.136]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSSLQT3F; Tue, 25 Nov 2003 08:47:43 +0100 Message-ID: <3FC2819A.8020006@ericsson.com> Date: Mon, 24 Nov 2003 23:09:30 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: liebl@lnt.e-technik.tu-muenchen.de, marcel.wagner@mchp.siemens.de, juergen.pandel@mchp.siemens.de, wenrong.weng@mchp.siemens.de CC: avt@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-avt-uxp-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Sorry for being so late with my comments. I think the concept is good enough however there is quite a lot of work left until this is a good protocol specification. 1. I think of a lot of the background material on how Reed Salomon codes work should be moved to the introduction. In other word section 3,4,5 can be put into the a common chapter, possibly with subsections, however I think one should be clearer about they being introductionary. 2. Then there is need to start writing some real payload specification chapter. Of the present chapter I think the largest hole is how one goes from a unprotected stream into a protected one. As I see it one will take a series of complete RTP packets and then put them into payloads of new RTP packets. 3. There is need to be much clearer on how one fills in the protection matrix and then can on the receiver side understand how one has written the bytes from different packets into the matrix to correctly recover it. 4. I think you authors should consider to include some more blank lines, or in certain cases do a page break between section to improve the readability of the text. For example the TOC should be moved into a separate page. Please do also put in a blank line between each paragraph. 5. You are missing the short copyright statement after status of this memo and the abstract. See ID-nits http://www.ietf.org/ID-nits.html 6. Chapter 2 is very hard to read. I would suggest that instead of using numbered bullets, you use the definition being left justified and then put the definition more right justified. You may also consider of all these definitions really make sense to be defined in conventions or if they more belong in there respective chapter. 7. The H.26L is now H.264, 8. In section 4. The following sentence exist: "Furthermore, if channel conditions get worse during transmission, only more and more enhancement layers are lost, i.e. a graceful degradation in application quality at the receiver is achieved [6]." This sentence can be rather dangerous in IETF. The general channel you are talking about is the IP channel which normally only losses packets due to congestion. Therefore this sentence can be interpreted as by simply adding more protection one can avoid most effects of congestion. So if you are talking about the very special case for links that loses packet of other reasons I think you need to be very explicit. 9. Figure 3 should be moved into the introduction when you discuss Reed Salomon codes. 10. Page 11, bullet 2. How does on determine the expected number of TSB rows? 11. What RTP timestamp rate should be used for this format? Does it really need one? or could one simply transmission time stamp the packets? 12. Please use more normative wording when defining how the marker bit should be set. 13. Section 6.1: "All other fields in the RTP header are set to those values proposed for regular multimedia transmission using the RTP-format of the media stream which is protected by UXP, e.g. for MPEG-4 Visual as specified in RFC 3016." Normal there are no more fields then RTP TS and Marker bit that the payload format defines, the rest is set in accordance with the RTP specification and the profile in use. 14. What is the gain of having the protected media's PT available in the UXP header? As I understand it you will need to decode the minimal number packets possible to reconstruct the stream to use it at all. 15. How does one treat packets where one is able to recover parts of the packets? 16. The proposed RTP Timestamp assignment mechanism will make the RTCP jitter unusable, if this is deemed acceptable, then at least it should be noted. 17. I would recommend that the description of the processing becomes much less media oriented and much more common RTP and its payload specific. 18. I would also like that the specification is more explicit how can give different protection levels to different packets or parts of a packet. There need to be more information about this topic making it possible for a implementor of UXP for a certain purpose being able to determine how they should behave. 19. This payload format need to register a MIME subtype for all the main media types that uses RTP at all. 20. Then one can write a chapter on how to map this to SDP. 21. In the security section the following text is present: " The overall ratio between parity and info octets MUST NOT be higher than 1:1, i.e. the absolute bitrate spent for redundancy must not be larger than the bitrate required for transmission of multimedia data itself." This statement I understand is intended to address congestion control. This isn't very useful, as the transmission rate in the face of loss in a best effort network shall not be higher than what a TCP flow would achieve over the same path. However the mix between protection and real data can be any and should be controlled only in regards to the paths error characteristics. This results in a the trade-off between protection and media. 22. You are missing the IETF standard IPR statement, see ID-nits for references to the sections from RFC 2026 you need. 23. I think you can write an separate address for each of the authors. I hope this will provide you with input in writing the next version. Cheers Magnus Westerlund _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 04:41:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10112 for ; Tue, 25 Nov 2003 04:41:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZhL-0006b5-6o for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 04:41:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP9fVGI025360 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 04:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZgw-0006a9-Qn; Tue, 25 Nov 2003 04:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZgX-0006ZC-8h for avt@optimus.ietf.org; Tue, 25 Nov 2003 04:40:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10049 for ; Tue, 25 Nov 2003 04:40:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZgP-0000vJ-00 for avt@ietf.org; Tue, 25 Nov 2003 04:40:33 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOZgP-0000vG-00 for avt@ietf.org; Tue, 25 Nov 2003 04:40:33 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAP9eXI2009363; Tue, 25 Nov 2003 10:40:33 +0100 (MET) Received: from ericsson.com (sealwp02-136.sw.ericsson.se [153.88.142.136]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSYJV9G0; Tue, 25 Nov 2003 10:40:06 +0100 Message-ID: <3FC3236C.8060900@ericsson.com> Date: Tue, 25 Nov 2003 10:39:56 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: avt@ietf.org References: <3FC1D887.4050400@ericsson.com> <027d01c3b2e3$98ca7030$0401a8c0@berlin> In-Reply-To: <027d01c3b2e3$98ca7030$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Comments on draft-jones-avt-text-red-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Paul, Paul E. Jones wrote: >Magnus, > > > >>1. In a WG document version you need to include the short copyright >>statement on the first page. >> >> > >Can you point to a sample document and section? I tried to copy the text I >found in other WG documents, though it would surprise me that I left >something out. > > The copyright statement people has been using is the first line of the section 10.3. (C) of RFC 2026. However it seems that the ID-nits are no longer required that it is included. So I withdraw my comment. > > >>2. The abstract and first chapter: Is really usage of this mime type >>specified in RFC 2793? I thought this was only one possible usage of >>this MIME type. Technically this mime type could be used with any other >>format using the text and fulfilling any other requirement. >> >> > >Your point is valid, as RFC 2793 might be just one of several documents that >might specify the use of this. However, if I think of audio/red, I think of >RFC 2198. I think what you're saying is that for use with SDP, 2198/2793 >are apropos, but necessarily other applications that might use this mime >sub-type. Since I have no other example, should I just say something along >those lines? > Yes, the MIME type can be used by any current or future text payload format that fulfil the requirement imposed by RFC 2198. > > > >>3. Shouldn't there be a chapter on mapping to SDP? As there are some >>tricks in relation to the defined MIME parameter "pt" and SDP. I think >>this is in line with the current explicit declaration of SDP usage. >> >> > >Yes, you're right. Essentially, it would follow chapter 3 of RFC 3555. I >will create a chapter and simply refer to that text, if that's acceptable. > > It has been usually to actually include a copy and provide the details of how things are included. Especially you need to make it clear how the mapping of PT is done to the FMTP line. Cheers Magnus _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 08:41:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17089 for ; Tue, 25 Nov 2003 08:41:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdRG-0000EQ-1S for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 08:41:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPDf9RT000890 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 08:41:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdR7-0000DH-4l; Tue, 25 Nov 2003 08:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdQP-0000CR-8M for avt@optimus.ietf.org; Tue, 25 Nov 2003 08:40:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17049 for ; Tue, 25 Nov 2003 08:40:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdQO-00057f-00 for avt@ietf.org; Tue, 25 Nov 2003 08:40:16 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOdQN-00057b-00 for avt@ietf.org; Tue, 25 Nov 2003 08:40:15 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPDe4IW018485; Tue, 25 Nov 2003 14:40:13 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 14:40:01 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Ash, Gerald R (Jerry), ALABS'" , avt@ietf.org Subject: RE: [AVT] HC over multihop / MPLS Date: Tue, 25 Nov 2003 12:39:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Jerry, This seems like a reasonable work plan! Rgds, /L-E > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: den 21 november 2003 17:51 > To: Lars-Erik Jonsson (LU/EAB); avt@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [AVT] HC over multihop / MPLS > > > Lars-Erik, > > I very much appreciate your taking the time to read the draft > and comment. > > A lot of the questions raised at the AVT meeting are > addressed in the draft, so it helps when people do read the draft. > > Allison, Colin, Magnus, and I met after the meeting and > agreed on the following approach for next steps: > > 1. split the current document > http://ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rq > mts-01.txt into 2 requirements documents: > a. 'requirements for hop-by-hop ECRTP over MPLS' (RSVP-TE > protocol extension oriented) > b. 'requirements for hop-by-hop ECRTP over IP' (SCID > switching oriented) > (note that Colin suggests 'hop-by-hop' versus 'multi-hop' > terminology; 'multi-hop was meant to clarify 'end-to-end' in > the OO version, but still may have led to some confusion). > 2. eliminate MPLS jargon such as CE, PE, etc., just talk > about routers R1, R2, etc. > 3. eliminate absolute performance objectives and simply state > goal to 'minimize delta degradation' (for delay, jitter, pkt > loss, etc.). This includes performance degradation due to > too much resync. > 4. eliminate absolute scalability requirement for # of flows, > and simply state goal to improve scalability of the number of > compressed flows that can be handled. > 5. use already standard protocols for compression, signaling, etc. > > It was agreed that requirements 1a should lead to an RSVP-TE > protocol extension effort and be worked in conjunction with > the MPLS SG, and that requirements 1b could lead to an > Informational RFC out of AVT. > > Please let me know of any comments or suggestions on this plan. > > I've made a few other brief comments below on your email. > > Thanks, > Jerry > > > The AVT charter states the following as a WG task: > > "to review the applicability of Compressed RTP operation on > > MPLS networks, developing extensions as necessary" > > > > With the following milestones: > > Nov 03 Initial draft requirements for ECRTP over MPLS; > > discuss with MPLS WG > > Nov 03 Initial draft requirements for ECRTP over MPLS; > > discuss with MPLS WG > > > > However, the current draft refers to "VoIP Header Compression > > over Multi-Hop Paths", which is not the same thing. The draft > > clearly shows that compression over multihop paths is one thing, > > and compression over MPLS another. Further, the draft takes a > > wider scope, and talks about header compression generally, > > not only ECRTP as the charter says. > > > > The following observations can be made: > > * If work is to done for header compression over multihop > > and/or MPLS, it might make sense to not only address ECRTP. > > Agreed. The plan to split the requirements draft into 2 > separate requirements drafts (ECRTP over MPLS, ECRTP over IP) > addresses this, as outlined above. > > > * The only work in this that naturally could belong in the > > AVT WG would be to make sure ECRTP would work in these > > scenarios. In my understanding, this should already be > > the case with ECRTP (as well as some ROHC profiles), which > > is also indicated by the multihop req draft. > > Agreed. > > > * Header compression over multihop paths [ described by the > > multihop req draft as where one wants to avoid > > decompression/compression steps at intermediate routers if > > the same compression scheme is supported at both incoming > > and outgoing interfaces ] is fully possible also without any > > new standards, as it would only be an implementation issue for > > each intermediate router to bind an incoming compressed stream > > to its corresponding outgoing compressed stream. In a path > > A->B->C, where B is the intermediate router > > negotiating use of e.g. CRTP with both A and C, it is fully > > up to the implementation of B to avoid unnecessary > > decompression/compression and just forward compressed packets > > as-is ("CID routing"). > > Agreed (requirements draft 1b, as outlined above, leading to > an Informational RFC). > > > * The only significant standardization work I can see is to > > define how to do header compression (e.g. IPHC, CRTP/ECRTP, > > ROHC) over MPLS, which is probably a work that would require > > some coordination with AVT and ROHC individuals, but the core > > of that work does not naturally belong to ROHC or AVT. Would > > not the MPLS WG be a more proper place? > > I think the plan is to complete the requirements 1a and the > follow-on protocol work in conjunction with the MPLS WG. > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 08:42:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17120 for ; Tue, 25 Nov 2003 08:42:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdS7-0000Pt-Mv for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 08:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPDg3Vp001488 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 08:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdS6-0000MV-CS; Tue, 25 Nov 2003 08:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdRG-0000EX-9u for avt@optimus.ietf.org; Tue, 25 Nov 2003 08:41:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17082; Tue, 25 Nov 2003 08:40:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdRE-00058i-00; Tue, 25 Nov 2003 08:41:08 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOdRE-00058f-00; Tue, 25 Nov 2003 08:41:08 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPDegIp019150; Tue, 25 Nov 2003 14:41:07 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 14:40:38 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Phelan, Tom'" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Tue, 25 Nov 2003 12:52:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Tom, We do not just have to find ways to get some kind of "fairness" between applications, but we actually have two main goals: 1) Avoid congestion 2) Improve network utilization By probing the network, TCP strive for 2), and that is a good think. When there is available bandwidth, it is a good thing that this resource gets used for actual application data. However, sending data just to keep network resources degrades goal 2). To me, this seems to be a tricky problem as TCP has not at all been designed to interact with real-time streams. /L-E > -----Original Message----- > From: dccp-admin@ietf.org [mailto:dccp-admin@ietf.org]On Behalf Of > Phelan, Tom > Sent: den 20 november 2003 19:04 > To: 'philippe.gentric@philips.com'; Phelan, Tom; 'Rosen, Brian' > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > Subject: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Hi Phillipe, > > The situation I'm worried about is a little different than > you describe. Say you have a 10M bps link, over which there's > a 4M bps video stream and a long-lived TCP app. The TCP app > will take the remaining 6M bps, and then push for more, > which might cause the video stream to lose packets. The > video stream then drops to 2M bps, and the TCP app expands to > 8M bps. This hardly seems fair. > > The video app can protect itself from this by transmitting > enough more than 4M bps to buffer itself against the TCP > probes. In this case we'd come to a relatively steady state > where both apps are sending roughly 5M bps. This seems > reasonably fair to me, since the TCP app gets what it would > get if it were competing with other TCP apps, and the video > app gets to send at its full rate. > > Tom P. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 08:42:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17135 for ; Tue, 25 Nov 2003 08:42:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdS9-0000UU-I0 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 08:42:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPDg5Md001839 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 08:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdS7-0000QN-Rq; Tue, 25 Nov 2003 08:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdRl-0000IN-LW for avt@optimus.ietf.org; Tue, 25 Nov 2003 08:41:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17106; Tue, 25 Nov 2003 08:41:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdRk-00058s-00; Tue, 25 Nov 2003 08:41:40 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOdRj-00058p-00; Tue, 25 Nov 2003 08:41:39 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPDegJN019150; Tue, 25 Nov 2003 14:41:37 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 14:40:41 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Rosen, Brian'" Cc: "'dccp@ietf.org'" , "'avt@ietf.org'" Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Tue, 25 Nov 2003 12:53:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > I have looked carefully at the drafts. I think I understand what > the proposal is, and how it works. I'll even agree that it might > do what you think it will do, but I suspect that my device will > cause a heck of a lot more congestion to the network if I run the > video streams on DCCP than if I leave it on UDP. I think the > solution will be much worse than the problem. > > The solution is just plain broken, in my opinion. The real, hard, > problem is that there probably is no good solution, short of fixing > TCP, or treating real time data differently (ie QoS) in the router. > Like it or not, RTP is not appropriate for what we usually call > "best effort", but the problem with that statement is that it's not > really true that we need something more than for the network to use > its' best effort to deliver the traffic. What is true is that other > streams have to deal better with CBR data than they do. It is TCP > that is broken. I don't think there is any way around that. > TCP makes an assumption that is invalid when real time media is part > of the traffic mix. > > There are so many problems with DCCP applied to real time media (this > one, slow start,...), that I think we should just stop believing that > DCCP is appropriate for RTP. Unfortunately, I think this analysis is rather correct. If so, I wonder if it really makes sense to continue with the DCCP work, if it can not solve the problem it is supposed to address. At least we should slow down a bit and give it more time, hopefully we can activate more people and get them involved in the work. More specifically, I think it is totally wrong to postpone the actual work as "future CC work" if DCCP with current CC's do not solve the problems it was chartered to solve and claims to address. /L-E _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 10:30:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22889 for ; Tue, 25 Nov 2003 10:30:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf98-0000wd-FQ for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 10:30:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFUYQj003630 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 10:30:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8c-0000lW-Sr; Tue, 25 Nov 2003 10:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf7z-0000gj-AX for avt@optimus.ietf.org; Tue, 25 Nov 2003 10:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22684 for ; Tue, 25 Nov 2003 10:29:08 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf7w-0006ua-00 for avt@ietf.org; Tue, 25 Nov 2003 10:29:20 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AOf7w-0006uS-00 for avt@ietf.org; Tue, 25 Nov 2003 10:29:20 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 95EF255D27; Tue, 25 Nov 2003 16:29:07 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 18A7A19C49; Tue, 25 Nov 2003 16:29:07 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id A5D5219C46; Tue, 25 Nov 2003 16:29:06 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id QAA00751; Tue, 25 Nov 2003 16:29:05 +0100 (MET) Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide To: Stephen Casner Cc: AVT WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 25 Nov 2003 16:25:18 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/11/2003 16:30:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Stephen, Unfortunately filling the client buffer at a rate faster than the media rate and "when you can" which introduces substancial amounts of time (many seconds) of delay is a technique for media distribution for which DCCP is not needed: It is called "progressive" download, it uses HTTP and it is deployed ... regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com To: "Phelan, Tom" cc: AVT WG (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Stephen Casner Classification: Sent by: avt-admin@ietf.org 24/11/2003 18:27 I think Tom's description of the problem as enabling DCCP to get its fair share vs. TCP has misdirected the thinking. The problem he identified was that TCP's bandwidth probing will cause some loss in the DCCP stream as well. Here is the key: that probing will cause exactly the same loss in an RTP/UDP stream. It is only DCCP's reaction to the loss that is a design question. For interactive (delay-sensitive) media, FEC may be an option for protecting against the isolated packet losses induced by TCP probing. This can be achieved with less than 2X bandwidth. But other than removing the FEC, and possibly shifting encodings, there is not much room for the media to accommodate any direction from DCCP to back off. As I've said more than once in DCCP WG meetings, these applications don't want to be congestion controlled. Unless there is policing in the network that causes performance with UDP to be worse than with DCCP, there is no motivation to change protocols. On the other hand, for streaming media to clients with significant buffer capacity, then the approach of sending at 2X rate (if the bottleneck allows) until the buffer is filled is a fine idea. During the 2X period, if DCCP says to back off by half, the application is still getting its necessary throughput. After the buffer is full, the rate will have to be 1X, but if DCCP says to back off from that as a result of TCP probing, the buffer will cover the period until the rate ramps back up. The rate can go over 1x again to refill the buffer, then back to 1X. This isn't a new idea. DCCP would just legitimize and standardize it. -- Steve _______________________________________________ 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 exim@www1.ietf.org Tue Nov 25 10:44:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23817 for ; Tue, 25 Nov 2003 10:44:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfMC-0002Oa-SM for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 10:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFi4op009183 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 10:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfM9-0002MW-NZ; Tue, 25 Nov 2003 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfLs-0002M0-Ak for avt@optimus.ietf.org; Tue, 25 Nov 2003 10:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23732; Tue, 25 Nov 2003 10:43:28 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfLp-0007C1-00; Tue, 25 Nov 2003 10:43:41 -0500 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 1AOfLo-0007BT-00; Tue, 25 Nov 2003 10:43:41 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl4.philips.com (Postfix) with ESMTP id 987452C137; Tue, 25 Nov 2003 16:43:07 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 39C7419C4F; Tue, 25 Nov 2003 16:43:07 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 7363C19C5F; Tue, 25 Nov 2003 16:43:02 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id QAA09960; Tue, 25 Nov 2003 16:43:00 +0100 (MET) Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide To: "Lars-Erik Jonsson (LU/EAB)" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 25 Nov 2003 16:40:08 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 25/11/2003 16:44:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Lars-Erik, I share your concern about "sending garbage" to "keep the pipe open". I understand now that "probing" is required to achieve (2) in fairness to TCP i.e. a traffic that is competing with TCP has to use the same "weapon". My idea would be that if the TCP traffic is allowed to push the DCCP-born media traffic down in rate I expect "probing" to be performed in order for the media traffic to discover that it can increase its rate, **after a decrease**, if/when it can, i.e. when some/all of the TCP traffic is finished (which would be fair). In short for media traffic via DCCP "probing" would be a continuous activity in order to push against the TCP traffic,(the amount of pressure/resistance being tunable ?) I am expecting a TCP-well-behaved media application to lower its rate (but not systematically by half ?) if more TCP traffic happens and I also assume that all media applications should be prepared/defined to either stop reducing their rate AND/OR cut off below a certain rate, i.e. this should be tunable by marketing/policy/management. I agree with Stephen that in all case probing means losses on both sides but I expect error resiliency to cover that. I think that the sensible way to "probe" is to send "more media/packets" periodically (in bursts) (instead of sending garbage as a shield of some sort). In all cases I beleive the key is to understand the minimum rate of change of the data/packet rates and minimum amplitude of the rate changes, the periodicty of the "probes" etc that are required for maintaining a tunable level of "resistance" against TCP traffic. So far it seems that only the "factor of 2" has been considered, this may seem quite large (too large for a lot of apps and codecs) and could make the future of DCCP pretty bleak. Let me express my optimistic view as a metaphor: To me it looks like the discussion has been a bit like discussing the usage of tires on cars and there would be 2 sides, one that is against it and defends that raw steel is good enough (with FEC cushions on the seats !) and the other extreme opinion that 2 meters thick balloon tires are what is required for good confort. Could the truth be somewhere in the middle ?-) Regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com To: "'Phelan, Tom'" cc: "'avt@ietf.org'" "'dccp@ietf.org'" (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) "Lars-Erik Jonsson (LU/EAB)" Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Classification: Sent by: avt-admin@ietf.org 25/11/2003 12:52 Tom, We do not just have to find ways to get some kind of "fairness" between applications, but we actually have two main goals: 1) Avoid congestion 2) Improve network utilization By probing the network, TCP strive for 2), and that is a good think. When there is available bandwidth, it is a good thing that this resource gets used for actual application data. However, sending data just to keep network resources degrades goal 2). To me, this seems to be a tricky problem as TCP has not at all been designed to interact with real-time streams. /L-E > -----Original Message----- > From: dccp-admin@ietf.org [mailto:dccp-admin@ietf.org]On Behalf Of > Phelan, Tom > Sent: den 20 november 2003 19:04 > To: 'philippe.gentric@philips.com'; Phelan, Tom; 'Rosen, Brian' > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > Subject: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Hi Phillipe, > > The situation I'm worried about is a little different than > you describe. Say you have a 10M bps link, over which there's > a 4M bps video stream and a long-lived TCP app. The TCP app > will take the remaining 6M bps, and then push for more, > which might cause the video stream to lose packets. The > video stream then drops to 2M bps, and the TCP app expands to > 8M bps. This hardly seems fair. > > The video app can protect itself from this by transmitting > enough more than 4M bps to buffer itself against the TCP > probes. In this case we'd come to a relatively steady state > where both apps are sending roughly 5M bps. This seems > reasonably fair to me, since the TCP app gets what it would > get if it were competing with other TCP apps, and the video > app gets to send at its full rate. > > Tom P. _______________________________________________ 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 exim@www1.ietf.org Tue Nov 25 11:38:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25979 for ; Tue, 25 Nov 2003 11:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgCV-0006XB-I9 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 11:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPGc6um025065 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 11:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgCQ-0006U9-9Z; Tue, 25 Nov 2003 11:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgBW-0006J5-Uu for avt@optimus.ietf.org; Tue, 25 Nov 2003 11:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25869 for ; Tue, 25 Nov 2003 11:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgBS-0000Zc-00 for avt@ietf.org; Tue, 25 Nov 2003 11:37:02 -0500 Received: from mail0.rawbw.com ([198.144.192.41]) by ietf-mx with esmtp (Exim 4.12) id 1AOgBS-0000Z0-00 for avt@ietf.org; Tue, 25 Nov 2003 11:37:02 -0500 Received: from io.herlein.com (m205-238.dsl.tsoft.com [198.144.205.238]) by mail0.rawbw.com (8.11.6p2/8.11.6) with ESMTP id hAPGato77925 for ; Tue, 25 Nov 2003 08:36:55 -0800 (PST) Date: Tue, 25 Nov 2003 08:36:53 -0800 (PST) From: Greg Herlein X-X-Sender: gregh@io.herlein.com To: AVT WG Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Unfortunately filling the client buffer at a rate faster than > the media rate and "when you can" which introduces substancial > amounts of time (many seconds) of delay is a technique for > media distribution for which DCCP is not needed: > > It is called "progressive" download, it uses HTTP and it is deployed ... That's somewhat simplistic, really. Progressive download has a similar effect but it's not controlled, and it's TCP only of course. For unicast scenarios this kind of thing makes total sense if the source is non-real time (ie, streaming from disk). It's not much more than an enhanced jitter buffer, really - you are just adding some extra buffer for times when the normal real-time flow is impaired, and a mechanism to allow the client to tell the source to "fill me up" and "back it off." There need not be any extra delay at startup, though not doing so creates a window of vulnerability. I'd very much like to see some standardization effort on a protocol to support this kind of thing - perhaps an RTCP extension? Perhaps soemthing that can apply to TCP as well? I'm willing to help on such an effort. Greg Herlein VP Engineering Arkstream, Inc. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 14:08:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02777 for ; Tue, 25 Nov 2003 14:08:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiXh-0000YV-Lj for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 14:08:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJ89wE002088 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 14:08:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiXZ-0000UM-Eo; Tue, 25 Nov 2003 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiWt-0000Kc-Hl for avt@optimus.ietf.org; Tue, 25 Nov 2003 14:07:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02695; Tue, 25 Nov 2003 14:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiWq-0003DU-00; Tue, 25 Nov 2003 14:07:16 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AOiWq-0003Ck-00; Tue, 25 Nov 2003 14:07:16 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02126; Tue, 25 Nov 2003 14:06:43 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04714; Tue, 25 Nov 2003 14:06:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 14:06:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6123@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'philippe.gentric@philips.com'" , "Lars-Erik Jonsson (LU/EAB)" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Tue, 25 Nov 2003 14:06:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This would seem to only apply to a non-interactive stream, where several seconds of buffering is acceptable, correct? You also, in this case, would not actually change the encoding rate, but merely change the instantaneous transmit rate. I'm not clear on how this is better than just using TCP. Brian > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Tuesday, November 25, 2003 10:40 AM > To: Lars-Erik Jonsson (LU/EAB) > Cc: 'avt@ietf.org'; 'dccp@ietf.org' > Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Lars-Erik, > > I share your concern about "sending garbage" to "keep the pipe open". > > I understand now that "probing" is required to achieve (2) in > fairness to TCP > i.e. a traffic that is competing with TCP has to use the same > "weapon". > > My idea would be that if the TCP traffic is allowed to push > the DCCP-born media traffic down in rate > I expect "probing" to be performed in order for the media > traffic to discover that it can increase its rate, > **after a decrease**, if/when it can, i.e. when some/all of > the TCP traffic is finished (which would be fair). > > In short for media traffic via DCCP "probing" would be a > continuous activity in order to push against > the TCP traffic,(the amount of pressure/resistance being tunable ?) > > I am expecting a TCP-well-behaved media application to lower > its rate (but not systematically by half ?) > if more TCP traffic happens and I also assume that all media > applications should be > prepared/defined to either stop reducing their rate AND/OR > cut off below a certain rate, > i.e. this should be tunable by marketing/policy/management. > > I agree with Stephen that in all case probing means losses on > both sides but > I expect error resiliency to cover that. > > I think that the sensible way to "probe" is to send "more > media/packets" periodically (in bursts) > (instead of sending garbage as a shield of some sort). > > In all cases I beleive the key is to understand the minimum > rate of change of the data/packet rates > and minimum amplitude of the rate changes, the periodicty of > the "probes" etc > that are required for maintaining a tunable level of > "resistance" against TCP traffic. > > So far it seems that only the "factor of 2" has been considered, > this may seem quite large (too large for a lot of apps and codecs) > and could make the future of DCCP pretty bleak. > > Let me express my optimistic view as a metaphor: > > To me it looks like the discussion has been a bit like > discussing the usage of tires on cars and there would be 2 sides, > one that is against it and defends that raw steel is good > enough (with FEC cushions on the seats !) > and the other extreme opinion that 2 meters thick balloon > tires are what is required for good confort. > > Could the truth be somewhere in the middle ?-) > > > Regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > > > > > > To: > "'Phelan, Tom'" > > cc: > "'avt@ietf.org'" > > > "'dccp@ietf.org'" > > (bcc: > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > "Lars-Erik Jonsson (LU/EAB)" > Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media > Guide > > > com> > Classification: > > > > > Sent by: > > > avt-admin@ietf.org > > > > > > 25/11/2003 12:52 > > > > > > > > > > > > > Tom, > > We do not just have to find ways to get some kind of "fairness" > between applications, but we actually have two main goals: > 1) Avoid congestion > 2) Improve network utilization > > By probing the network, TCP strive for 2), and that is a good > think. When there is available bandwidth, it is a good thing > that this resource gets used for actual application data. > However, sending data just to keep network resources degrades > goal 2). To me, this seems to be a tricky problem as TCP has > not at all been designed to interact with real-time streams. > > /L-E > > > -----Original Message----- > > From: dccp-admin@ietf.org [mailto:dccp-admin@ietf.org]On Behalf Of > > Phelan, Tom > > Sent: den 20 november 2003 19:04 > > To: 'philippe.gentric@philips.com'; Phelan, Tom; 'Rosen, Brian' > > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > > Subject: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Hi Phillipe, > > > > The situation I'm worried about is a little different than > > you describe. Say you have a 10M bps link, over which there's > > a 4M bps video stream and a long-lived TCP app. The TCP app > > will take the remaining 6M bps, and then push for more, > > which might cause the video stream to lose packets. The > > video stream then drops to 2M bps, and the TCP app expands to > > 8M bps. This hardly seems fair. > > > > The video app can protect itself from this by transmitting > > enough more than 4M bps to buffer itself against the TCP > > probes. In this case we'd come to a relatively steady state > > where both apps are sending roughly 5M bps. This seems > > reasonably fair to me, since the TCP app gets what it would > > get if it were competing with other TCP apps, and the video > > app gets to send at its full rate. > > > > Tom P. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 15:22:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07376 for ; Tue, 25 Nov 2003 15:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjhH-0005cq-Rq for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 15:22:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKM7pO021623 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 15:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjhC-0005bx-9a; Tue, 25 Nov 2003 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjgC-0005aT-BP for avt@optimus.ietf.org; Tue, 25 Nov 2003 15:21:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07343; Tue, 25 Nov 2003 15:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjg6-0004qe-00; Tue, 25 Nov 2003 15:20:54 -0500 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1AOjg6-0004qB-00; Tue, 25 Nov 2003 15:20:54 -0500 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hAPKK0HW022418; Tue, 25 Nov 2003 12:20:01 -0800 (PST) (envelope-from casner@packetdesign.com) Date: Tue, 25 Nov 2003 12:20:00 -0800 (PST) From: Stephen Casner To: Greg Herlein , "Rosen, Brian" cc: AVT WG , dccp@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B6123@whq-msgusr-02.pit.comms.marconi.com> Message-ID: <20031125121045.W10837@ash.packetdesign.com> References: <313680C9A886D511A06000204840E1CF070B6123@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Replies to a couple of related messages, edited: On Tue, 25 Nov 2003, Greg Herlein wrote: > > Unfortunately filling the client buffer at a rate faster than > > the media rate and "when you can" which introduces substancial > > amounts of time (many seconds) of delay is a technique for > > media distribution for which DCCP is not needed: > > > > It is called "progressive" download, it uses HTTP and it is deployed ... > > That's somewhat simplistic, really. Progressive download has a > similar effect but it's not controlled, and it's TCP only of > course. Yes. More on the TCP point below. > For unicast scenarios this kind of thing makes total sense if the > source is non-real time (ie, streaming from disk). It's not much > more than an enhanced jitter buffer, really - you are just adding > some extra buffer for times when the normal real-time flow is > impaired, and a mechanism to allow the client to tell the source > to "fill me up" and "back it off." There need not be any extra > delay at startup, though not doing so creates a window of > vulnerability. Exactly right. Thanks for saving me having to write this. The point about no additional delay is important: the vulnerability at startup is no worse than and in fact increasingly less than the vulnerability for a stream sent constantly at rate 1. > I'd very much like to see some standardization effort on a > protocol to support this kind of thing - perhaps an RTCP > extension? Perhaps soemthing that can apply to TCP as well? We talked about doing something like this in RTP itself a few times, but deferred to congestion control work in other groups. So DCCP is now the proposed standardization effort. On Tue, 25 Nov 2003, Rosen, Brian wrote: > This would seem to only apply to a non-interactive stream, where > several seconds of buffering is acceptable, correct? Yes. > You also, in this case, would not actually change the encoding > rate, but merely change the instantaneous transmit rate. Yes. As I said earlier, you might use FEC to protect against the probing initially here, same as you could use it to protect an RTP/UDP stream, but once some buffer is built up for the non-interactive case, then retransmission is more efficient. > I'm not clear on how this is better than just using TCP. The key difference is that TCP insists on 100% reliability. It must retransmit a lost packet before any subsequent data can be delivered. For these media applications, retransmission may still be useful, but you want the application to have control over the decision to retransmit or to give up and continue on. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Nov 25 15:41:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08612 for ; Tue, 25 Nov 2003 15:41:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjzd-00082n-Ji for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 15:41:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKf573030913 for avt-archive@odin.ietf.org; Tue, 25 Nov 2003 15:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjza-000817-Rn; Tue, 25 Nov 2003 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjyu-0007zd-Gn for avt@optimus.ietf.org; Tue, 25 Nov 2003 15:40:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08561; Tue, 25 Nov 2003 15:40:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjys-0005Or-00; Tue, 25 Nov 2003 15:40:18 -0500 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1AOjyr-0005Nr-00; Tue, 25 Nov 2003 15:40:18 -0500 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hAPKdeHW023636; Tue, 25 Nov 2003 12:39:40 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 25 Nov 2003 12:39:40 -0800 (PST) From: Stephen Casner To: Greg Herlein , "Rosen, Brian" cc: AVT WG , dccp@ietf.org Message-ID: <20031125123834.C10837@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Replies to a couple of related messages, edited: On Tue, 25 Nov 2003, Greg Herlein wrote: > > Unfortunately filling the client buffer at a rate faster than > > the media rate and "when you can" which introduces substancial > > amounts of time (many seconds) of delay is a technique for > > media distribution for which DCCP is not needed: > > > > It is called "progressive" download, it uses HTTP and it is deployed ... > > That's somewhat simplistic, really. Progressive download has a > similar effect but it's not controlled, and it's TCP only of > course. Yes. More on the TCP point below. > For unicast scenarios this kind of thing makes total sense if the > source is non-real time (ie, streaming from disk). It's not much > more than an enhanced jitter buffer, really - you are just adding > some extra buffer for times when the normal real-time flow is > impaired, and a mechanism to allow the client to tell the source > to "fill me up" and "back it off." There need not be any extra > delay at startup, though not doing so creates a window of > vulnerability. Exactly right. Thanks for saving me having to write this. The point about no additional delay is important: the vulnerability at startup is no worse than and in fact increasingly less than the vulnerability for a stream sent constantly at rate 1. > I'd very much like to see some standardization effort on a > protocol to support this kind of thing - perhaps an RTCP > extension? Perhaps soemthing that can apply to TCP as well? We talked about doing something like this in RTP itself a few times, but deferred to congestion control work in other groups. So DCCP is now the proposed standardization effort. On Tue, 25 Nov 2003, Rosen, Brian wrote: > This would seem to only apply to a non-interactive stream, where > several seconds of buffering is acceptable, correct? Yes. > You also, in this case, would not actually change the encoding > rate, but merely change the instantaneous transmit rate. Yes. As I said earlier, you might use FEC to protect against the probing initially here, same as you could use it to protect an RTP/UDP stream, but once some buffer is built up for the non-interactive case, then retransmission is more efficient. > I'm not clear on how this is better than just using TCP. The key difference is that TCP insists on 100% reliability. It must retransmit a lost packet before any subsequent data can be delivered. For these media applications, retransmission may still be useful, but you want the application to have control over the decision to retransmit or to give up and continue on. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 03:40:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27532 for ; Wed, 26 Nov 2003 03:40:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvDi-00044e-13 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 03:40:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ8eJCn015609 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 03:40:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvDQ-00041n-0l; Wed, 26 Nov 2003 03:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvD0-00040e-T2 for avt@optimus.ietf.org; Wed, 26 Nov 2003 03:39:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27487; Wed, 26 Nov 2003 03:39:25 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOvCy-0001Vv-00; Wed, 26 Nov 2003 03:39:36 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AOvCx-0001Vs-00; Wed, 26 Nov 2003 03:39:35 -0500 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 164B655F1F; Wed, 26 Nov 2003 09:39:36 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id EE3F219C66; Wed, 26 Nov 2003 09:39:33 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 6C0A619C4D; Wed, 26 Nov 2003 09:39:27 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id JAA08958; Wed, 26 Nov 2003 09:39:26 +0100 (MET) To: Stephen Casner Cc: avt@ietf.org, dccp@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Nov 2003 09:36:40 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/11/2003 09:41:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [AVT] Re: [dccp] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Stephen, you wrote: >> > Unfortunately filling the client buffer at a rate faster than >> > the media rate and "when you can" which introduces substancial >> > amounts of time (many seconds) of delay is a technique for >> > media distribution for which DCCP is not needed: >> > >> > It is called "progressive" download, it uses HTTP and it is deployed ... >> >> That's somewhat simplistic, really. Progressive download has a >> similar effect but it's not controlled, and it's TCP only of >> course. > >Yes. > I am concerned that since the barrier for DCCP is very high (implementing a new protocol at IP level is not something the industry will go for without a strong incentive) the added value must be equally high. My point was that Progressive download (although different of course ;-) has pretty similar performances compared to the solution/application you describe, i.e. media delivery with large buffers/delays.... But progressive download has *zero* hurdle(e.g. NAT/FW traversal ;-)... so if we conclude that DCCP is good only for that application there is the clear risk that this will not help promote DCCP... >The key difference is that TCP insists on 100% reliability. It must >retransmit a lost packet before any subsequent data can be delivered. >For these media applications, retransmission may still be useful, but >you want the application to have control over the decision to >retransmit or to give up and continue on. I fully agree this is the fundamental reason why another protocol than TCP is a good idea: media does not need 100% reliability. The other idea I have been trying to advocate for a while because I believe it is another key to the problem is that media does not need to be constant bit rate, nor constant packet rate, nor constant packet size. These 3 things (delay, reliability, variable rate/packaging) should give some slack for the design of a solution with added value no? regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 08:26:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06094 for ; Wed, 26 Nov 2003 08:26:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzgH-0001fb-03 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 08:26:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQDQ8ri006413 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 08:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzgA-0001dP-96; Wed, 26 Nov 2003 08:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzfd-0001bB-J6 for avt@optimus.ietf.org; Wed, 26 Nov 2003 08:25:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06058; Wed, 26 Nov 2003 08:25:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOzfc-0005Qf-00; Wed, 26 Nov 2003 08:25:28 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AOzfb-0005QM-00; Wed, 26 Nov 2003 08:25:27 -0500 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 hAQDOvlf006109; Wed, 26 Nov 2003 08:24:57 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 26 Nov 2003 08:24:50 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Nov 2003 08:24:50 -0500 Message-ID: From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" Cc: avt@ietf.org, dccp@ietf.org Date: Wed, 26 Nov 2003 08:24:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [dccp] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Phillipe, [snipped] > The other idea I have been trying to advocate for a while > because I believe it is another key to the problem > is that media does not need to be constant bit rate, nor > constant packet rate, nor constant packet size. I'm glad you brought this up. There have been a lot of comments on this thread about the difficulties in the human perception of rate-shifting, and, in general, I'd have to say the comments are pretty accurate, especially given the current state of the art in codec design. However, I can think of at least two instances where rate shifting is either workable or better than the current practice. One case involves audio codecs such as G.711 and changing the packetization interval. G.711 with 10ms packetization is about 96K IP bps on the wire. 40ms packetization gives about 72K bps. I think that changing between these two rates is often close to imperceptible. A similar thing can be done with G.729A (although I'm not sure the standard allows it), giving more variation in the bit rate - 10ms packetization is about 38.4K bps and 40ms is 14.4K. Another case involves video transmission. As you change between a high and low encoding rate the image the user sees is likely to change back and forth between clear and grainy, and this is likely to be annoying. But I imagine it's less annoying than the current practice of freezing the video (and continuing the audio) when there's insufficient bandwidth for the high-res video. I imagine that layered encoding techniques like Gerard Babonneua mentioned can fit this mode of operation nicely. Given that there are these low-hanging-fruit stream shifting methods, I wonder what others are available if we put our minds to it? Tom Phelan > These 3 things (delay, reliability, variable rate/packaging) > should give some slack > for the design of a solution with added value no? > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 09:00:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07013 for ; Wed, 26 Nov 2003 09:00:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0D9-0003K0-CQ for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:00:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQE07og012720 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0D5-0003IP-DR; Wed, 26 Nov 2003 09:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0Cb-0003HD-HM for avt@optimus.ietf.org; Wed, 26 Nov 2003 08:59:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06953; Wed, 26 Nov 2003 08:59:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0CZ-0005o9-00; Wed, 26 Nov 2003 08:59:31 -0500 Received: from brazilnut.cc.columbia.edu ([128.59.59.203] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1AP0CZ-0005o5-00; Wed, 26 Nov 2003 08:59:31 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hAQDxN2d015970 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Nov 2003 08:59:23 -0500 (EST) Message-ID: <3FC4B1BB.7000601@cs.columbia.edu> Date: Wed, 26 Nov 2003 08:59:23 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: Stephen Casner , avt@ietf.org, dccp@ietf.org Subject: Re: [AVT] Re: [dccp] Re: DCCP Media Guide References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I fully agree this is the fundamental reason why another protocol than TCP > is a good idea: media does not need 100% reliability. The only reason not to get 100% reliability is that relaxing reliability constraints reduces delay, as even modest loss rates, if unfortuitously placed, can wreak havoc with user experience. For the higher-latency streaming application contemplated here, it is unclear that removing reliability adds any significant value, particularly given that you end up having to add some protection (FEC) to deal with losses, thus increasing the overall average bit rate or reducing the quality. (Obviously, FEC doesn't deal well with loss spurts, so quality will be rather poor if losses are indeed bursty, even with aggressive FEC.) Typical FEC overhead for useful error resiliency is usually in excess of 20%, so the bandwidth penalty is substantial. Thus, before accepting that DCCP is the right thing for streaming media, a bit more human-factors and measurement evidence seems called for. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 09:19:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07593 for ; Wed, 26 Nov 2003 09:19:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0VT-0004Ov-Lw for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEJ3VM016893 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0VR-0004NU-Cg; Wed, 26 Nov 2003 09:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0V5-0004M7-84 for avt@optimus.ietf.org; Wed, 26 Nov 2003 09:18:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07564; Wed, 26 Nov 2003 09:18:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0V3-00065a-00; Wed, 26 Nov 2003 09:18:37 -0500 Received: from mail0.rawbw.com ([198.144.192.41]) by ietf-mx with esmtp (Exim 4.12) id 1AP0V2-00065W-00; Wed, 26 Nov 2003 09:18:36 -0500 Received: from io.herlein.com (m205-238.dsl.tsoft.com [198.144.205.238]) by mail0.rawbw.com (8.11.6p2/8.11.6) with ESMTP id hAQEIUo72722; Wed, 26 Nov 2003 06:18:30 -0800 (PST) Date: Wed, 26 Nov 2003 06:18:28 -0800 (PST) From: Greg Herlein X-X-Sender: gregh@io.herlein.com To: avt@ietf.org, Subject: Re: [AVT] Re: [dccp] Re: DCCP Media Guide In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > I fully agree this is the fundamental reason why another > protocol than TCP is a good idea: media does not need 100% > reliability. I don't agree. *Some* media does not need 100% reliability. But many video codecs have pathetic performance in the face of packet loss - and FEC is not always a good solution (impact on bandwidth is one reason - complexity is another). Audio is often a lot more tolerant (at least in VoIP) - a loss spurt in video is radically painful for the viewer in most cases. While TCP does have it's own problems for video delivery (and some advantages too) it's not the ideal solution, clearly. I most wholeheartedly agree that delay, reliability, variable rate/packaging are the three elements that *can* be adjusted to modify the performance of a video stream. To that I would add dynamic buffering at the endpoints (goes with rate, I guess). I'd like to see a protocol (or extension) that can implement this into apps that can use it to good measure, as opposed to generating YAP (yet another protocol) that addresses only one aspect of the problem (and in only one way). Greg Herlein VP Engineering Arkstream, Inc. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 09:27:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07847 for ; Wed, 26 Nov 2003 09:27:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0dC-0004zd-Tf for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:27:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQER2Gk019183 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0dB-0004yD-4L; Wed, 26 Nov 2003 09:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0cp-0004uD-JJ for avt@optimus.ietf.org; Wed, 26 Nov 2003 09:26:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07810; Wed, 26 Nov 2003 09:26:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0cn-0006B1-00; Wed, 26 Nov 2003 09:26:37 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AP0cn-0006Af-00; Wed, 26 Nov 2003 09:26:37 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27465; Wed, 26 Nov 2003 09:26:04 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA26977; Wed, 26 Nov 2003 09:26:05 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Nov 2003 09:26:04 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B612D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" , "'philippe.gentric@philips.com'" Cc: avt@ietf.org, dccp@ietf.org Date: Wed, 26 Nov 2003 09:26:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [dccp] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Again, I think the most acceptable response to congestion for video is to rate shift down once, or if necessary, twice to get to an "acceptable" level of errors. So, it's not freeze frame vs rapid rate shift, it's rate shift down vs rapid rate shift. We have a different error result than freeze, and it seems to work better (less objectionable), but it doesn't change the equation. If you get too many errors, you lower the rate until you don't get "too many". It would be interesting to look at the voice response to changing packetization period. Clearly, the effect of the loss of one large packet is worse than the effect of a small packet. Small packets have more bit rate, so, you would presumably be sending larger packets when you have congestion. What does that do to the perceived quality? It's going to get worse as congestion gets worse, which in some sense is "good", but is it actually worse than a higher packet loss rate, but less problem for each loss? Probably depends on the loss pattern. If it were random, than the smaller problem, larger percentage is probably better, but it's not random. There are people who know a lot about such things. I'm not one of them. Do we have some of that expertise around on the list? Has that idea been tried? I do think we need to split this thread, or at least mark replies with "Applies to interactive real time" vs "applies to non-interactive real time". I appreciate several comments on the thread that DCCP may have more applicability to non-interactive streams. While many of the effects are similar (rate shift to non-interactive is just as objectionable to non-interactive as it is to interactive), some things are clearly different (slow start, for example). Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Wednesday, November 26, 2003 8:25 AM > To: 'philippe.gentric@philips.com' > Cc: avt@ietf.org; dccp@ietf.org > Subject: RE: [dccp] Re: DCCP Media Guide > > > Hi Phillipe, > > [snipped] > > The other idea I have been trying to advocate for a while > > because I believe it is another key to the problem > > is that media does not need to be constant bit rate, nor > > constant packet rate, nor constant packet size. > > I'm glad you brought this up. There have been a lot of > comments on this > thread about the difficulties in the human perception of > rate-shifting, and, > in general, I'd have to say the comments are pretty accurate, > especially > given the current state of the art in codec design. However, > I can think of > at least two instances where rate shifting is either workable > or better than > the current practice. > > One case involves audio codecs such as G.711 and changing the > packetization > interval. G.711 with 10ms packetization is about 96K IP bps > on the wire. > 40ms packetization gives about 72K bps. I think that > changing between these > two rates is often close to imperceptible. A similar thing > can be done with > G.729A (although I'm not sure the standard allows it), giving > more variation > in the bit rate - 10ms packetization is about 38.4K bps and > 40ms is 14.4K. > > Another case involves video transmission. As you change > between a high and > low encoding rate the image the user sees is likely to change > back and forth > between clear and grainy, and this is likely to be annoying. > But I imagine > it's less annoying than the current practice of freezing the > video (and > continuing the audio) when there's insufficient bandwidth for > the high-res > video. I imagine that layered encoding techniques like > Gerard Babonneua > mentioned can fit this mode of operation nicely. > > Given that there are these low-hanging-fruit stream shifting > methods, I > wonder what others are available if we put our minds to it? > > Tom Phelan > > > These 3 things (delay, reliability, variable rate/packaging) > > should give some slack > > for the design of a solution with added value no? > > > > regards, > > > > > > Philippe Gentric > > Chief Architect > > Philips Software > > philippe.gentric@philips.com > > http://www.software.philips.com > > > > > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 09:30:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07967 for ; Wed, 26 Nov 2003 09:30:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0g7-0005In-P4 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEU3gW020363 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0g7-0005IG-3y; Wed, 26 Nov 2003 09:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0fI-0005GH-JV for avt@optimus.ietf.org; Wed, 26 Nov 2003 09:29:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07925; Wed, 26 Nov 2003 09:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0fG-0006DR-00; Wed, 26 Nov 2003 09:29:10 -0500 Received: from ms-smtp-02-qfe0.socal.rr.com ([66.75.162.134] helo=ms-smtp-02-eri0.socal.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1AP0fG-0006DE-00; Wed, 26 Nov 2003 09:29:10 -0500 Received: from vsathe (dt0410n5e.san.rr.com [204.210.30.94]) by ms-smtp-02-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id hAQESuiG012168; Wed, 26 Nov 2003 06:29:03 -0800 (PST) Message-Id: <200311261429.hAQESuiG012168@ms-smtp-02-eri0.socal.rr.com> From: "Vinay Sathe" To: "'Phelan, Tom'" , Cc: , Subject: RE: [AVT] RE: [dccp] Re: DCCP Media Guide Date: Wed, 26 Nov 2003 06:31:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Thread-index: AcO0IRB8XXeZQuShS1ahc040FPom/QACFGUg Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This comment is not really related to DCCP. However, the issue of rate variability of video has been brought up during the discussions. I concur with the comments regarding video rates below. While it may be true that "traditional" video codec (MPEG-1 MPEG-2) may have undesirable artifacts due to transport rate changes (that were unknown to the rate control loop when the video was encoded), several standards-based and proprietary video codec exist that minimize visual degradation through severe video rate changes/dropouts. (M-JPEG2000 is one example). Best regards, Vinay -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Phelan, Tom Sent: Wednesday, November 26, 2003 5:25 AM To: 'philippe.gentric@philips.com' Cc: avt@ietf.org; dccp@ietf.org Subject: [AVT] RE: [dccp] Re: DCCP Media Guide Hi Phillipe, [snipped] > The other idea I have been trying to advocate for a while > because I believe it is another key to the problem > is that media does not need to be constant bit rate, nor > constant packet rate, nor constant packet size. I'm glad you brought this up. There have been a lot of comments on this thread about the difficulties in the human perception of rate-shifting, and, in general, I'd have to say the comments are pretty accurate, especially given the current state of the art in codec design. However, I can think of at least two instances where rate shifting is either workable or better than the current practice. One case involves audio codecs such as G.711 and changing the packetization interval. G.711 with 10ms packetization is about 96K IP bps on the wire. 40ms packetization gives about 72K bps. I think that changing between these two rates is often close to imperceptible. A similar thing can be done with G.729A (although I'm not sure the standard allows it), giving more variation in the bit rate - 10ms packetization is about 38.4K bps and 40ms is 14.4K. Another case involves video transmission. As you change between a high and low encoding rate the image the user sees is likely to change back and forth between clear and grainy, and this is likely to be annoying. But I imagine it's less annoying than the current practice of freezing the video (and continuing the audio) when there's insufficient bandwidth for the high-res video. I imagine that layered encoding techniques like Gerard Babonneua mentioned can fit this mode of operation nicely. Given that there are these low-hanging-fruit stream shifting methods, I wonder what others are available if we put our minds to it? Tom Phelan > These 3 things (delay, reliability, variable rate/packaging) > should give some slack > for the design of a solution with added value no? > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ 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 exim@www1.ietf.org Wed Nov 26 09:42:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08420 for ; Wed, 26 Nov 2003 09:42:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rj-0006Tm-Ds for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEg3w9024877 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rh-0006RN-M3; Wed, 26 Nov 2003 09:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rW-0006Og-5l for avt@optimus.ietf.org; Wed, 26 Nov 2003 09:41:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08375; Wed, 26 Nov 2003 09:41:35 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rU-0006NV-00; Wed, 26 Nov 2003 09:41:48 -0500 Received: from gw-nl4.philips.com ([212.153.190.6]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rI-0006NO-00; Wed, 26 Nov 2003 09:41:36 -0500 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id 1C3152B45A; Wed, 26 Nov 2003 15:41:30 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 73E1A19C4D; Wed, 26 Nov 2003 15:41:29 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id DD3A619C48; Wed, 26 Nov 2003 15:41:28 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id PAA23636; Wed, 26 Nov 2003 15:41:28 +0100 (MET) Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide To: "Rosen, Brian" Cc: "'avt@ietf.org'" , "'dccp@ietf.org'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Nov 2003 15:38:39 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/11/2003 15:43:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Brian, you wrote >This would seem to only apply to a non-interactive stream, where >several seconds of buffering is acceptable, correct? When you play with the transmit rate the larger the buffer/delay the easier ... . And if you dont have delay then you really need to be able to change the media rate ! >You also, in this case, would not actually change the encoding >rate, but merely change the instantaneous transmit rate. in all cases when the temporary bandwidth reduction lasts longer than your buffer ...then you need to change the media rate, there is just no other way. Actually for interactive (conferencing) case changing the rate of the codec (media rate) is actually "easier" (in theory): you just tell the codec(s) to produce less bits (!) (it is "easier" in the sense that with pre-encoded media delivery you have to do stream switching instead) >I'm not clear on how this is better than just using TCP. If you only consider the case where the buffers/delays are really large then yes, I tend to agree, (see other mail about progressive download)... regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 09:48:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08648 for ; Wed, 26 Nov 2003 09:48:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0xW-0006zK-I9 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:48:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEm2LP026839 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0xV-0006wS-HF; Wed, 26 Nov 2003 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0xM-0006v6-9d for avt@optimus.ietf.org; Wed, 26 Nov 2003 09:47:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08609; Wed, 26 Nov 2003 09:47:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0xK-0006TM-00; Wed, 26 Nov 2003 09:47:50 -0500 Received: from pecan.cc.columbia.edu ([128.59.59.178] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1AP0xJ-0006TJ-00; Wed, 26 Nov 2003 09:47:49 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hAQE9ji8005398 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Nov 2003 09:09:45 -0500 (EST) Message-ID: <3FC4B428.5020806@cs.columbia.edu> Date: Wed, 26 Nov 2003 09:09:44 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'philippe.gentric@philips.com'" , avt@ietf.org, dccp@ietf.org Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > One case involves audio codecs such as G.711 and changing the packetization > interval. G.711 with 10ms packetization is about 96K IP bps on the wire. > 40ms packetization gives about 72K bps. I think that changing between these > two rates is often close to imperceptible. A similar thing can be done with > G.729A (although I'm not sure the standard allows it), giving more variation > in the bit rate - 10ms packetization is about 38.4K bps and 40ms is 14.4K. While this is numerically accurate, it seems largely pointless. If I'm below the perceptible delay threshold (say 150 ms one-way), there is no reason to transmit at 10 ms packetization interval since the user experience will not improve noticeably. Indeed, very few systems transmit at 10 ms packetization today. In addition, at the access links where congestion is most likely, IP/UDP/RTP header compression reduces the difference in bit rates to much smaller values, further reducing the utility of doing variable packetization. (From our experiments, a packetization interval of roughly 30-40 ms also appears to work best with FEC.) > > Another case involves video transmission. As you change between a high and > low encoding rate the image the user sees is likely to change back and forth > between clear and grainy, and this is likely to be annoying. But I imagine > it's less annoying than the current practice of freezing the video (and > continuing the audio) when there's insufficient bandwidth for the high-res > video. I imagine that layered encoding techniques like Gerard Babonneua > mentioned can fit this mode of operation nicely. Again, like Brian pointed out, this assumes that you're aiming for a low-quality hey-it's-free experience. > > Given that there are these low-hanging-fruit stream shifting methods, I > wonder what others are available if we put our minds to it? Unfortunately, the first is unlikely to be productive and the second has very limited applicability. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 09:54:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08981 for ; Wed, 26 Nov 2003 09:54:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP13L-0007eN-6h for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEs3wR029360 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 09:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP13K-0007cv-A0; Wed, 26 Nov 2003 09:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP12i-0007ar-9L for avt@optimus.ietf.org; Wed, 26 Nov 2003 09:53:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08952; Wed, 26 Nov 2003 09:53:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP12g-0006Zn-00; Wed, 26 Nov 2003 09:53:22 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1AP12f-0006Zk-00; Wed, 26 Nov 2003 09:53:21 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hAQErH4R021257 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Nov 2003 09:53:19 -0500 (EST) Message-ID: <3FC4BE5D.2000809@cs.columbia.edu> Date: Wed, 26 Nov 2003 09:53:17 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Phelan, Tom'" , "'philippe.gentric@philips.com'" , avt@ietf.org, dccp@ietf.org Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide References: <313680C9A886D511A06000204840E1CF070B612D@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B612D@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > It would be interesting to look at the voice response to changing > packetization period. Clearly, the effect of the loss of one large > packet is worse than the effect of a small packet. Small packets have > more bit rate, so, you would presumably be sending larger packets > when you have congestion. What does that do to the perceived quality? > It's going to get worse as congestion gets worse, which in some sense > is "good", but is it actually worse than a higher packet loss rate, > but less problem for each loss? Probably depends on the loss pattern. > If it were random, than the smaller problem, larger percentage is > probably better, but it's not random. We have looked at this systematically, varying the packetization threshold. See the papers by Wenyu Jiang and myself at http://netbib.info and http://www1.cs.columbia.edu/~wenyu/ > > There are people who know a lot about such things. I'm not one of them. > Do we have some of that expertise around on the list? Has that idea > been tried? See above and references therein. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 10:19:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11490 for ; Wed, 26 Nov 2003 10:19:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1RW-0001hm-Fr for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 10:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQFJ2CT006553 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 10:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1RV-0001gW-AK; Wed, 26 Nov 2003 10:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1Qh-0001ca-2p for avt@optimus.ietf.org; Wed, 26 Nov 2003 10:18:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11429 for ; Wed, 26 Nov 2003 10:17:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1Qe-00072P-00 for avt@ietf.org; Wed, 26 Nov 2003 10:18:08 -0500 Received: from english-breakfast.cloud9.net ([168.100.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1AP1Qd-00072L-00 for avt@ietf.org; Wed, 26 Nov 2003 10:18:08 -0500 Received: from localhost (localhost [127.0.0.1]) by english-breakfast.cloud9.net (Postfix) with ESMTP id CB9E8ABA7; Wed, 26 Nov 2003 10:18:07 -0500 (EST) Received: from english-breakfast.cloud9.net (localhost [127.0.0.1]) by localhost (VaMailArmor-2.0.1.7) id 59609-5F1AB4C4; Wed, 26 Nov 2003 10:18:07 -0500 Received: from COLLICULUS (248-223.customer.cloud9.net [168.100.248.223]) by english-breakfast.cloud9.net (Postfix) with ESMTP id 49013AB3F; Wed, 26 Nov 2003 10:18:07 -0500 (EST) Reply-To: From: "Qiong Li" To: "'Rosen, Brian'" , Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Wed, 26 Nov 2003 10:18:04 -0500 Organization: BrainMedia Message-ID: <86C0B7B413918E45A4B0A97F95657A0A15364A@ceruleus.brainmediaco.com> 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, Build 10.0.2627 In-Reply-To: <86C0B7B413918E45A4B0A97F95657A0A1709EB@ceruleus.brainmediaco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.7; VAE: 6.22.0.1; VDF: 6.22.0.49; host: english-breakfast.cloud9.net) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Everyone, Here is some of my thought related to this topic. It may be arguable whether layered audio and video are needed for wired sections of the Internet, However, it seems that scalable coded media contents may still be necessary for wireless delivery, especially in mobile environments, or in cases where the end-to-end paths have wireless link segments. The bandwidth variations on wireless links could be due to completely different reasons from congestion, such as fading, interference, mobility, etc. It seems that when wireless link degradation happens, there are no known QoS mechanisms that can still provide previously negotiated services. To deal with this problem, many research works proposed to deploy so-called soft QoS in which service quality can vary in a range, or to encourage application repeatedly renegotiate a different QoS level with the network. Once any of these happens, adaptation on content bit rate seems unavoidable. Also from a user perspective (I don't have experiments to support this), assuming the case where a person who listens to music (may be companied with low bit rate video). He may from time to time experience the degradation of sound and picture qualities whenever he walks under a construction or enter a new cellar domain, etc. this degradation would be understandable and acceptable to the user. However, if the sound completely stopped and the picture frozen, he would have no clue whether this problem is because he just got a broken phone or else. Therefore, if the digitized media can be delivered as resilient as analog format, that may be the direction we want to pursue. Of course, layered media contents are not necessary to be delivered by DCCP-like protocols. Thanks, -qiong -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Rosen, Brian Sent: Monday, November 24, 2003 9:49 AM To: 'Magnus Westerlund' Cc: Phelan, Tom; 'avt@ietf.org' Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide Magnus I don't think the people working on the stability of the network understand what they are proposing, or they wouldn't be proposing it, except for Tom, who probably understands what the effect of 2X bandwidth (when congestion was not occurring), and figures if that's the only knob he's got, then he turns it far enough to make his app work, and since he doesn't violate any rules, all is well. I don't agree. I think that, as Marshall observes, RTP media flows tend to be self policing, and in any event, following the IAB recommendation of dropping the flow if excessive packet loss is observed will have the same effect - congestion collapse will not occur. I think that we should stop thinking that we need anything else to prevent congestion collapse. I think the real question this thread is addressing is whether DCCP is at all suitable for real time flows. I think the answer is no. I think we should try see if we can reach consensus on this. Given what has been said on this thread, is there anyone left who thinks DCCP is suitable for RTP flows? This leaves us in a quandary, which, I think, is what Tom was trying to avoid. If DCCP is not suitable, is there any way to hold off the greedy TCP? This is the question Mike raises. It's not an issue of congestion collapse, it is the issue of "fairness". My own feeling is that fairness to RTP is let the flow go through or don't. There exists a variety of ways to vary the rate, but none of them are useful. Have you ever actually listened (or watched) a media stream with varying rate? I have, several times, several different algorithms. It sucks, to put it mildly. Unless you have some evidence that there exists an algorithm which does not annoy a user when the rate changes, I suspect our experience will be the common one - you will go down, once, and never go back up. I expect even this will be very rare. Much more common is that you will try one rate, and if you don't get good results, the call/stream will be dropped and tried again. There are lots of algorithms to vary rates. There are no ways I know to vary quality, how ever it is done, and not be very distracting to a user. Unless there is some kind of concealment mechanism I am not aware of, it just won't be used, regardless of how clever the algorithm is, and how bandwidth efficient it is. So, to me, the idea that RTP reacts to whatever else is happening in any way other than dropping the entire stream is not credible. That means there is no real rate control for RTP, TCP friendly or otherwise. (I'll just use RTP vs TCP, even though we all understand that RTP is carried on some other transport at the same level as TCP). So what does it mean to be "fair"? For RTP, being fair to TCP (or other best effort traffic) is to not get started, or get dropped if congestion is excessive For TCP, being fair to RTP (or other constant rate traffic) is to not be greedy. This is why QoS mechanisms work. If you put RTP ahead of TCP, and use admission control to limit the amount of RTP, everything works. If you don't have a QoS mechanism, you can still perform admission control to the RTP flows to enforce RTP fairness on TCP, but you need to put some kind of mechanism to allow TCP to be fair to RTP. I'm happy to work on mechanisms that would afford effective admission control in reaction to best effort traffic, but only if there is a commitment to fix TCP. Brian > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, November 21, 2003 10:40 AM > To: Rosen, Brian > Cc: Phelan, Tom; 'avt@ietf.org' > Subject: Re: [AVT] RE: [MMUSIC] DCCP Media Guide > > > Hi Brian, > > I don't think that the people working with stability of the > network are > sharing you view due to the implications that your claims results in. > > First, if a multi-media application transmitting data over a > best-effort > IP network, i.e. without any QoS guarantees across the whole net that > its traffic will fit, it can definitely cause congestion > collapse if the > mix becomes most, media, little TCP. Please read > draft-iab-congestion-01.txt for some discussion on this. > > Some comments to your assertions. > > Rosen, Brian wrote: > > Phillipe > > > > You have made invalid assumptions: > > 1. That audio/video media data rates will be changed dynamically > > as network traffic changes. This is very > unlikely. It may > > be that you get so much loss that you drop to a > lower data > > rate, although I suspect that will be rare. > When you do, > > you will never revert to the higher rate. This > is because > > humans hate to see the change, and minimizing > changes is > > more desirable than keeping average quality higher. > > First you agree that it is possible to change the rate. Secondly I > understand that the there are implications on switching rate, i.e. > quality to often, however there are reasons for switching up when the > quality gain of a switch if being possible to keep the new > rate is clear. > > > > > 2. Real Time apps have no interest in being "fair". > They are all > > or nothing. If you admit them to the network, you expect > > the streams to be maintained. If you can't > maintain them, > > don't start them. They don't want to be fair > to TCP, and > > they > > don't want to be fair to other RTP. They just > want to send > > data at the rate they were advised to do by signalling. > > They can tolerate some loss. Misordering=loss. > Duplicates= > > wasted bandwith. That's a whole lot different from TCP > > traffic. > > > > Yes, I agree that the application has no interest in being > fair. However > using best effort networks requires one to being reasonably > fair. If one > are not, the combination of several of media application can totally > destroy things for them self. > > > I can imagine working on protocols which allowed CBR and > "best effort" > > traffic to better coexist, but I think it's only possible > if the best > > effort traffic recognized the presence of the CBR traffic > and reacted > > appropriately. Otherwise, you need to use QoS mechanisms > to separate > > the traffic. > > What says that the media traffic is more important that the traffic > going over TCP? > > > 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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 11:34:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16247 for ; Wed, 26 Nov 2003 11:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2cJ-0006kW-P0 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 11:34:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQGYFJR025898 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 11:34:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2c5-0006gK-IO; Wed, 26 Nov 2003 11:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2bv-0006fo-Ia for avt@optimus.ietf.org; Wed, 26 Nov 2003 11:33:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16186; Wed, 26 Nov 2003 11:33:37 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP2bu-0000wG-00; Wed, 26 Nov 2003 11:33:50 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AP2bt-0000wC-00; Wed, 26 Nov 2003 11:33:50 -0500 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id F246D6EE6F; Wed, 26 Nov 2003 17:33:43 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 7229119C48; Wed, 26 Nov 2003 17:33:43 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 9DCA319C56; Wed, 26 Nov 2003 17:33:41 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id RAA08559; Wed, 26 Nov 2003 17:33:40 +0100 (MET) Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide To: Henning Schulzrinne Cc: avt@ietf.org, dccp@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Nov 2003 17:30:54 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/11/2003 17:35:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Henning, TFRC experts, >> It would be interesting to look at the voice response to changing >> packetization period. ... > >We have looked at this systematically, varying the packetization >threshold. See the papers by Wenyu Jiang and myself at >http://netbib.info and http://www1.cs.columbia.edu/~wenyu/ > Does anyone have a clue of how changing the packetization impacts the behavior of TFRC in presence of TCP traffic ? For example if an application increases its packet rate (same media rate, higher transmit rate due to packet headers contribution increasing) is that added "pressure" against competing TCP traffic ? regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 11:50:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16808 for ; Wed, 26 Nov 2003 11:50:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2re-0007m7-96 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 11:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQGo6QH029878 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 11:50:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2rZ-0007lB-Vz; Wed, 26 Nov 2003 11:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2qb-0007jp-9M for avt@optimus.ietf.org; Wed, 26 Nov 2003 11:49:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16772; Wed, 26 Nov 2003 11:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP2qa-00019E-00; Wed, 26 Nov 2003 11:49:00 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AP2qZ-00018x-00; Wed, 26 Nov 2003 11:48:59 -0500 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 hAQGmTlf019080; Wed, 26 Nov 2003 11:48:29 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 26 Nov 2003 11:48:22 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Nov 2003 11:48:22 -0500 Message-ID: From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" Cc: avt@ietf.org, dccp@ietf.org Subject: RE: [AVT] RE: [dccp] Re: DCCP Media Guide Date: Wed, 26 Nov 2003 11:48:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Phillipe, TFRC is packet rate based, not bit rate. If TFRC cut your allowed packet rate in half, it'd be OK (at least as far as TFRC is concerned) if you cut your packet rate in half, but doubled the packet size. Of course in many circumstances this action would be unlikely to alleviate the network congestion, and some of these new big packets would probably be lost, causing TFRC to cut the allowed rate even more. TCP, on the other hand, is bit (or byte) rate based. Network congestion is both bit and packet rate based (others things too, I suppose), although I think the packet rate problems are diminishing (Moore's law helping us there). If going to smaller packets gets you a higher bits-on-the-wire rate, then you'd get some of the buffering I was talking about. On the other hand, if the chokepoint was packet-limited rather than bit-limited ... Tom Phelan > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Wednesday, November 26, 2003 11:31 AM > To: Henning Schulzrinne > Cc: avt@ietf.org; dccp@ietf.org > Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide > > > > Henning, TFRC experts, > > > >> It would be interesting to look at the voice response to changing > >> packetization period. > > ... > > > > >We have looked at this systematically, varying the packetization > >threshold. See the papers by Wenyu Jiang and myself at > >http://netbib.info and http://www1.cs.columbia.edu/~wenyu/ > > > > Does anyone have a clue of how changing the packetization > impacts the behavior of TFRC in presence of TCP traffic ? > > For example if an application increases its packet rate > (same media rate, higher transmit rate due to packet headers > contribution increasing) > is that added "pressure" against competing TCP traffic ? > > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 12:37:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18567 for ; Wed, 26 Nov 2003 12:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3bB-0003EH-8o for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 12:37:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHb9be012368 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 12:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3b3-0003Aq-5U; Wed, 26 Nov 2003 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3aX-00039i-GN for avt@optimus.ietf.org; Wed, 26 Nov 2003 12:36:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18481; Wed, 26 Nov 2003 12:36:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3aV-0001kZ-00; Wed, 26 Nov 2003 12:36:27 -0500 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1AP3aV-0001kD-00; Wed, 26 Nov 2003 12:36:27 -0500 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hAQHZpHW064170; Wed, 26 Nov 2003 09:35:52 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 26 Nov 2003 09:35:51 -0800 (PST) From: Stephen Casner To: "Rosen, Brian" cc: AVT WG , dccp@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B612D@whq-msgusr-02.pit.comms.marconi.com> Message-ID: <20031126093252.F18048@ash.packetdesign.com> References: <313680C9A886D511A06000204840E1CF070B612D@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RE: [dccp] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Wed, 26 Nov 2003, Rosen, Brian wrote: > Again, I think the most acceptable response to congestion for > video is to rate shift down once, or if necessary, twice to > get to an "acceptable" level of errors. So, it's not freeze > frame vs rapid rate shift, it's rate shift down vs rapid rate shift. > > We have a different error result than freeze, and it seems to work > better (less objectionable), but it doesn't change the equation. > If you get too many errors, you lower the rate until you don't > get "too many". One quick point, relating back to the start of the thread: If you are competing with one or more TCP streams and the total traffic is filling the available bottleneck bandwidth, then if you back off the video rate as a result of the loss induced by TCP rate probing, the TCP streams will expand to fill the bandwidth you freed and then probe for more until you stop. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 12:53:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19546 for ; Wed, 26 Nov 2003 12:53:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3qY-0004xP-Ny for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 12:53:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHr20o019030 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 12:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3qX-0004vJ-9r; Wed, 26 Nov 2003 12:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3q2-0004ue-Kd for avt@optimus.ietf.org; Wed, 26 Nov 2003 12:52:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19464; Wed, 26 Nov 2003 12:52:15 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3q0-00021q-00; Wed, 26 Nov 2003 12:52:28 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AP3q0-00021n-00; Wed, 26 Nov 2003 12:52:28 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 9A27E5789C; Wed, 26 Nov 2003 18:52:27 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id EF3D319C45; Wed, 26 Nov 2003 18:52:26 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 6EC0E19C48; Wed, 26 Nov 2003 18:52:26 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id SAA12334; Wed, 26 Nov 2003 18:52:26 +0100 (MET) To: "Phelan, Tom" Cc: avt@ietf.org, dccp@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Nov 2003 18:49:39 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/11/2003 18:54:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [AVT] RE: [dccp] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Tom, you wrote: >There have been a lot of comments on this >thread about the difficulties in the human perception of rate-shifting, and, >in general, I'd have to say the comments are pretty accurate, especially >given the current state of the art in codec design. Recent/hi-end digital TV (mpeg-2) codecs change their rate *all the time*. They do that to assign different bit rates to different channels based on the program/time (you put more bit rate on channel 12 when the movie or baseball match starts) and/or based on statistical multiplexing (i.e. the rate change several times per picture). This is deployed all over the face of the planet. Of course if you change from 4 Mb/s to 1 Mb/s the users may see the difference, but less drastic changes are hardly noticed but by experts (did you notice it ?) ... My group has products that dynamically change the rate of (MPEG-4) video (even down to very low bit rates e.g. the GPRS range at 20 to 50 kb/s) We do the same for speech in the 5-24 kb/s range. (BTW: AMR stands for Adaptive Multi Rate !) So I am really surprised with all this negative feedback about codecs and this notion that it is impossible/bad to change rates ? regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 13:01:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19792 for ; Wed, 26 Nov 2003 13:01:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3yM-0005KM-1A for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 13:01:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQI15cq020448 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 13:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3yI-0005Ha-M6; Wed, 26 Nov 2003 13:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP3xz-0005GY-4K for avt@optimus.ietf.org; Wed, 26 Nov 2003 13:00:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19751; Wed, 26 Nov 2003 13:00:27 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP3xx-00025x-00; Wed, 26 Nov 2003 13:00:41 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AP3xw-00025u-00; Wed, 26 Nov 2003 13:00:40 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 39FF96EDD8; Wed, 26 Nov 2003 19:00:40 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id BFE3919C4B; Wed, 26 Nov 2003 19:00:39 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 72DE119C48; Wed, 26 Nov 2003 19:00:39 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id TAA14858; Wed, 26 Nov 2003 19:00:38 +0100 (MET) Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide To: Stephen Casner Cc: AVT WG , dccp@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Nov 2003 18:57:52 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/11/2003 19:02:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Stephen, you wrote: >One quick point, relating back to the start of the thread: If you are >competing with one or more TCP streams and the total traffic is >filling the available bottleneck bandwidth, then if you back off the >video rate as a result of the loss induced by TCP rate probing, the >TCP streams will expand to fill the bandwidth you freed and then probe >for more until you stop. right, so it proves the need for "probing" (in the limit allowed by TFRC of course ;-) i.e. the media stream must "put some pressure" on the TCP traffic. Now when you try to find out how to do that you find the following possibilities: * increase the instantaneous transmit rate = works only within buffers/delay limits * increase the instantaneous media rate = works always (assuming the right codecs) regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com To: "Rosen, Brian" cc: AVT WG dccp@ietf.org (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Stephen Casner Subject: [AVT] RE: [dccp] Re: DCCP Media Guide Classification: Sent by: avt-admin@ietf.org 26/11/2003 18:35 On Wed, 26 Nov 2003, Rosen, Brian wrote: > Again, I think the most acceptable response to congestion for > video is to rate shift down once, or if necessary, twice to > get to an "acceptable" level of errors. So, it's not freeze > frame vs rapid rate shift, it's rate shift down vs rapid rate shift. > > We have a different error result than freeze, and it seems to work > better (less objectionable), but it doesn't change the equation. > If you get too many errors, you lower the rate until you don't > get "too many". One quick point, relating back to the start of the thread: If you are competing with one or more TCP streams and the total traffic is filling the available bottleneck bandwidth, then if you back off the video rate as a result of the loss induced by TCP rate probing, the TCP streams will expand to fill the bandwidth you freed and then probe for more until you stop. -- Steve _______________________________________________ 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 exim@www1.ietf.org Wed Nov 26 13:21:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20431 for ; Wed, 26 Nov 2003 13:21:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4He-0006n4-KA for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 13:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQIL2rV026085 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 13:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4Hc-0006l3-SR; Wed, 26 Nov 2003 13:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4HH-0006kY-Ix for avt@optimus.ietf.org; Wed, 26 Nov 2003 13:20:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20413; Wed, 26 Nov 2003 13:20:23 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4HF-0002NC-00; Wed, 26 Nov 2003 13:20:37 -0500 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 1AP4HE-0002N9-00; Wed, 26 Nov 2003 13:20:37 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id D20992BBD0; Wed, 26 Nov 2003 19:20:35 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 5EE7B19C45; Wed, 26 Nov 2003 19:20:35 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id BD27C19C4A; Wed, 26 Nov 2003 19:20:34 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id TAA20204; Wed, 26 Nov 2003 19:20:34 +0100 (MET) Subject: Re: [AVT] Re: [dccp] Re: DCCP Media Guide To: Greg Herlein Cc: avt@ietf.org, dccp@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Nov 2003 19:17:27 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/11/2003 19:22:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , greg you wrote: >> I fully agree this is the fundamental reason why another >> protocol than TCP is a good idea: media does not need 100% >> reliability. > >I don't agree. *Some* media does not need 100% reliability. >But many video codecs have pathetic performance in the face of >packet loss - and FEC is not always a good solution the bad news is probably that if you have to use such codecs then DCCP is not for you ? BTW the more recent/advanced codecs have error resilience features designed-in for that reason: people were horrified when they found out how the lack of resistance to even a small error rate was generating additional cost in deployments e.g. in DTV the additional bandwidth cost of the required FEC plus bill-of-material cost of FEC decoders on the STB is quite substancial... regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Nov 26 15:16:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26140 for ; Wed, 26 Nov 2003 15:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP650-0006GI-S5 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 15:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQKG6nN024046 for avt-archive@odin.ietf.org; Wed, 26 Nov 2003 15:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP64w-0006F2-Gq; Wed, 26 Nov 2003 15:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP64Q-0006DP-KM for avt@optimus.ietf.org; Wed, 26 Nov 2003 15:15:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25961 for ; Wed, 26 Nov 2003 15:15:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP64O-00044O-00 for avt@ietf.org; Wed, 26 Nov 2003 15:15:28 -0500 Received: from ribbit.cs.berkeley.edu ([128.32.112.203]) by ietf-mx with esmtp (Exim 4.12) id 1AP64O-00044J-00 for avt@ietf.org; Wed, 26 Nov 2003 15:15:28 -0500 Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1]) by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id hAQKFRTA011923 for ; Wed, 26 Nov 2003 12:15:27 -0800 (PST) Received: (from lazzaro@localhost) by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id hAQKFQ3W011922 for avt@ietf.org; Wed, 26 Nov 2003 12:15:26 -0800 (PST) Date: Wed, 26 Nov 2003 12:15:26 -0800 (PST) From: John Lazzaro Message-Id: <200311262015.hAQKFQ3W011922@ribbit.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] RE: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > philippe.gentric@philips.com writes: > > The other idea I have been trying to advocate for a while because I > believe it i s another key to the problem is that media does not need > to be constant bit rate, nor constant packet rate, n or constant > packet size. As an existence proof, RTP MIDI is potentially non-constant in all of these ways. And, with the appropriate choice of renderer, the RTP MIDI stream could be just as normative a codec as AAC -- the SDP machinery in Appendix C.5 of the RTP MIDI format I-D is designed to support this. This was Eric's motivation for doing Structured Audio, and my original motivation for writing an SA compiler (although the emphasis switched to network musical performance a few years into the project ...). --------------------------------------------------- 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 exim@www1.ietf.org Thu Nov 27 02:31:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28197 for ; Thu, 27 Nov 2003 02:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APGcF-000151-5N for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 02:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR7V73R004148 for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 02:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APGbZ-000116-3W; Thu, 27 Nov 2003 02:30:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOxlk-0003w1-0O for avt@optimus.ietf.org; Wed, 26 Nov 2003 06:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02554 for ; Wed, 26 Nov 2003 06:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOxlf-0003rG-00 for avt@ietf.org; Wed, 26 Nov 2003 06:23:35 -0500 Received: from mail01.svc.cra.dublin.eircom.net ([159.134.118.17]) by ietf-mx with smtp (Exim 4.12) id 1AOxlf-0003qu-00 for avt@ietf.org; Wed, 26 Nov 2003 06:23:35 -0500 Received: (qmail 26843 messnum 3378305 invoked from network[159.134.216.218/p216-218.as2.chf.cork.eircom.net]); 26 Nov 2003 11:21:36 -0000 Received: from p216-218.as2.chf.cork.eircom.net (HELO cs.ucc.ie) (159.134.216.218) by mail01.svc.cra.dublin.eircom.net (qp 26843) with SMTP; 26 Nov 2003 11:21:36 -0000 Message-ID: <3FC48CCA.3030808@cs.ucc.ie> Date: Wed, 26 Nov 2003 11:21:46 +0000 From: "Cormac J. Sreenan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] CFP: NOSSDAV 2004 (Cork, Ireland) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ------------------- CALL FOR PAPERS The 14th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2004) June 16-18, 2004 --- Kinsale, County Cork, Ireland http://www.nossdav.org/2004/ NOSSDAV 2004 will take place in Kinsale on the exceptionally scenic southern coast of Ireland. Kinsale is approximately a 20 minute drive outside Cork city, which is within easy reach of major European capitals and the east coast of the US. The workshop is sponsored by ACM SIG Multimedia (preliminary approval), Microsoft Research and Science Foundation Ireland, and is in cooperation with ACM SIGCOMM (preliminary approval). NOSSDAV invites submissions on all areas of multimedia, but strongly encourages submissions in newly emerging specialized areas such as networked games and peer-to-peer streaming. NOSSDAV 2004 will be run very much as a workshop with an emphasis on cutting-edge research and lively discussion. Papers grounded in high-quality experimental research based on prototype or real systems, including innovative experimental commercial designs and prototypes, as well as papers proposing new research directions for the community or calling into question existing conventional wisdom are particularly welcome. ***Student participation is strongly encouraged*** - supported by several student travel grants and registration fee rebates. Submissions should be no longer than 6 pages. The expectation is that papers accepted at the workshop will eventually lead to full-length papers at high-quality conferences or journals. The topics of interest include, but are not limited to: * Networked games * Peer-to-peer multimedia * Broadband streaming media content distribution * 3D multimedia and (networked) immersive environments * Wireless and ad-hoc network multimedia systems * Embedded multimedia devices (e.g., PVRs) * Multimedia security * Internet telephony * Sensory interactive applications * Digital rights management Deadlines: Paper registration deadline - February 23, 2004, (5pm EST) (*firm*) Paper submission deadline - March 1, 2004, (5pm EST) (*firm*) Program Co-Chairs: Venkat Padmanabhan, Microsoft Research (USA) Cormac Sreenan, University College Cork (Ireland) Email: nossdav2004-pcchairs@cs.ucc.ie Program Committee: Kevin Almeroth, UC Santa Barbara (USA) Ernst Biersack, Institut Eurecom (France) Phil Chou, Microsoft Research (USA) Christophe Diot, Intel Research (UK) Kevin Jeffay, UNC Chapel Hill (USA) Srinivasan Keshav, University of Waterloo (Canada) Sue Moon, KAIST (Korea) Reza Rejaie, University of Oregon (USA) Henning Schulzrinne, Columbia University (USA) Srinivasan Seshan, CMU (USA) Anees Shaikh, IBM Research (USA) Lars Wolf, TU Braunsch ----------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 27 05:54:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03015 for ; Thu, 27 Nov 2003 05:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APJmi-0003Jt-3e for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 05:54:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARAs8N0012761 for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 05:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APJma-0003JF-SP; Thu, 27 Nov 2003 05:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APJmI-0003J2-SZ for avt@optimus.ietf.org; Thu, 27 Nov 2003 05:53:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAB03004 for ; Thu, 27 Nov 2003 05:53:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APJmF-0006RL-00 for avt@ietf.org; Thu, 27 Nov 2003 05:53:39 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1APJmD-0006RI-00 for avt@ietf.org; Thu, 27 Nov 2003 05:53:38 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hARArbI2005972; Thu, 27 Nov 2003 11:53:37 +0100 (MET) Received: from ericsson.com (sealwp01-21.sw.ericsson.se [153.88.142.21]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW6V0CRD; Thu, 27 Nov 2003 11:53:33 +0100 Message-ID: <3FC5D79F.8070403@ericsson.com> Date: Thu, 27 Nov 2003 11:53:19 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul E. Jones" , =?UTF-8?B?R3VubmFyIEhlbGxzdHI=?= =?UTF-8?B?w7Zt?= CC: avt@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-avt-rfc2793bis-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have some comments on the draft. 1. The abstract should probably be rewritten, I think the second paragraph is not relevant enough for this, while the RTP payload format for gateways are not mentioned at all. 2. I think the TOC is long enough to have it alone on the second page, i.e. I would propose that one start the introduction chapter on page 3. 3. The third last paragraph in chapter 1 seems to be a clear motivation for using TCP to transport text. I think there need to be some further elaboration on the reasons for using RTP, because the second last paragraph is not a obvious result of the previous one. 4. Chapter 1, last paragraph, last sentence "and introduces a means of transporting text interleaved with voice within the same RTP session.". Is " a means" correct english? 5. In section 2, a reference to the complete information for RFC 2119 would be nice. 6. Section 3: "When transport of T.140 text session data in RTP is desired, the payloads as described in this specification SHOULD be used." This sentence seems a bit strange. I don't think using normative words about using this payload format real has any meaning. 7. Section 3.1, "This format is primarily used when text is transmitted on a separate RTP session dedicated for the transmission of text and not shared with other media, such as audio, DTMF, etc. IP textphone devices most commonly use this format." I think the restriction this payload format imposes on the media stream should be clearly documented in this section. 8. Section 3.2: "This T140block counter may be utilized to detect lost characters." I think one should clearly indicate that the counter if for detecting not lost characters but lost T140 blocks. I also think the comments made in the WG session in Minneapolis that the last block before a switch to another audio format can't be detected. 9. Section 3.6, "Note, also, that incoming text from a PSTN circuit might be at a higher bit-rate than can be played out on an egress PSTN circuit." The scenario and what is meant in this sentence is not clear. 10. Section 3.7; "For profiles that use dynamic payload type number assignment, this payload format is identified by the name "T140" (see section 8). If redundancy is used per RFC 2198, the Payload Type MUST indicate that payload format ("RED")." I think that one should be clearer. We are using MIME type according to the definition in chapter 8, and also RED has its MIME type that can be used to identify the name. Therefore I would reformulate the sentences to: "For profiles that use dynamic payload type number assignment, this payload format can be identified by the MIME types "text/T140" and "audio/T140" (see section 8). If redundancy is used per RFC 2198, another payload type number needs to be provided for the redundancy format. MIME types for identifying RFC 2198 are available in RFC 3555 and RFC YYYY." Where RFC YYYY is the RFC number for the text/RED registration. 11. Section 3.7, The RTP sequence number: redefining the RTP sequence number through normative text is not good. Please provide a reference to RFC 3550 and then you can have the informative text. 12. Section 3.7: "Timestamp: The RTP Timestamp encodes the approximate instance of entry of the primary text in the packet. A clock frequency of 1000 Hz MUST be used for text/t140. The clock frequency may be specified for audio/t140 and is generally set to be 8000 Hz, as that is most common for audio." In the last sentence above, it says: The clock frequency may be ... This is unclear, it needs normative language, making it clear that the rate MAY be set to any value, if not specified by out of band mechanism a RTP TS rate value of 8000 SHALL be used. 12.5. Section 3.7, why is the marker bit not defined? 13. Section 3.8: What is the following text doing in this chapter? "When redundant transmission of the data according to RFC 2198 is desired, the RTP header is followed by one or more redundant data block headers, one for each redundant data block to be included. Each of these headers provides the timestamp offset and length of the corresponding data block plus a payload type number indicating this payload format ("T140"). Redundant data older than 16383 divided by the clock frequency MUST not be transmitted." It would seem to belong in section describing the usage of RED. I think there are more things in regards to usage of RED, like section 3.9, that can be collected in a separate chapter clarifying that it concerns the usage of RED for t140. 14. Section 4.1 "A maximum buffering time of 500 ms is specified." Where is it specified? 15. Section 5: Another comment from the WG meeting in Minneapolis, was the need to make it clear that although the MIME parameter CPS the instantaneous reception rate might be higher due to jitter. 16. Section 8.1, as text/t140 in RFC 2793 does not have rate, and it is not need (due to fixed rate), I would remove it. The mapping to SDP chapter can simply explain that one simply puts in the rate. 17. There should also be an interoperability consideration regarding CPS parameter. Cheers Magnus _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Nov 27 10:26:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10112 for ; Thu, 27 Nov 2003 10:26:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APO1t-0005r1-6K for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 10:26:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARFQ5Fl022483 for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 10:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APO1o-0005pg-Nw; Thu, 27 Nov 2003 10:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APO1i-0005pK-Vs for avt@optimus.ietf.org; Thu, 27 Nov 2003 10:25:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10094; Thu, 27 Nov 2003 10:25:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APO1g-0001WA-00; Thu, 27 Nov 2003 10:25:52 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1APO1g-0001W4-00; Thu, 27 Nov 2003 10:25:52 -0500 Received: from [68.100.124.243] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 2062169; Thu, 27 Nov 2003 10:25:18 -0500 From: "Marshall Eubanks" Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide To: Stephen Casner , "Rosen, Brian" Cc: AVT WG , dccp@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Thu, 27 Nov 2003 10:25:18 -0500 Message-ID: In-Reply-To: <20031126093252.F18048@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Wed, 26 Nov 2003 09:35:51 -0800 (PST) Stephen Casner wrote: > On Wed, 26 Nov 2003, Rosen, Brian wrote: > > > Again, I think the most acceptable response to congestion for > > video is to rate shift down once, or if necessary, twice to > > get to an "acceptable" level of errors. So, it's not freeze > > frame vs rapid rate shift, it's rate shift down vs rapid rate shift. > > > > We have a different error result than freeze, and it seems to work > > better (less objectionable), but it doesn't change the equation. > > If you get too many errors, you lower the rate until you don't > > get "too many". > > One quick point, relating back to the start of the thread: If you are > competing with one or more TCP streams and the total traffic is > filling the available bottleneck bandwidth, then if you back off the > video rate as a result of the loss induced by TCP rate probing, the > TCP streams will expand to fill the bandwidth you freed and then probe > for more until you stop. Dear Stephen; Tue in theory, but maybe not in practice. See, e.g., Stanislav Shalunov's work on tcp tuning. According to http://www.internet2.edu/~shalunov/writing/tcp-perf.html most TCP implementations are badly tuned for broadband and don't actually deliver much more than 500 kbps at best. I notice empirically that UDP flat rate audio and video can co-exist with tcp in practice, and wonder if poor tcp performance might be one of the reasons why. Maybe if the ideas in http://www.internet2.edu/~shalunov/tcpar/ were adopted it would become much harder to send video over the Internet. Regards Marshall > > -- Steve > > _______________________________________________ > 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 exim@www1.ietf.org Thu Nov 27 14:11:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15507 for ; Thu, 27 Nov 2003 14:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APRXs-0007W1-Gc for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 14:11:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARJBKJ5028842 for avt-archive@odin.ietf.org; Thu, 27 Nov 2003 14:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APRXa-0007SG-Uv; Thu, 27 Nov 2003 14:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APRXM-0007Rj-Uu for avt@optimus.ietf.org; Thu, 27 Nov 2003 14:10:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15458; Thu, 27 Nov 2003 14:10:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APRXK-00041V-00; Thu, 27 Nov 2003 14:10:46 -0500 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1APRXJ-00041M-00; Thu, 27 Nov 2003 14:10:45 -0500 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hARJAAHW012794; Thu, 27 Nov 2003 11:10:11 -0800 (PST) (envelope-from casner@acm.org) Date: Thu, 27 Nov 2003 11:10:10 -0800 (PST) From: Stephen Casner To: Marshall Eubanks cc: AVT WG , dccp@ietf.org Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide In-Reply-To: Message-ID: <20031127105852.V32289@oak.packetdesign.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Marshall, > most TCP implementations are badly tuned for broadband > and don't actually deliver much more than 500 kbps at best. Banking on that for a media protocol design would be unwise. > I notice empirically that UDP flat rate audio and video can co-exist > with tcp in practice, and wonder if poor tcp performance might be > one of the reasons why. Sure. Flat-rate is the key. If the UDP traffic does not back off in response to TCP's probing, then TCP stays within the bandwidth that is left. The root of this whole discussion is that if you have ever more flat-rate UDP traffic, it will push all the TCP out of the way until the network is saturated with UDP traffic, then the UDP streams will experience loss. The TCP folks say that UDP traffic is unfair; DCCP is being developed as a response. Now in this conversation, we're discussing how to keep TCP from pushing DCCP out of the way. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 28 04:48:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19992 for ; Fri, 28 Nov 2003 04:48:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfEe-0004gZ-Ng for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 04:48:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAS9mOKp018012 for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 04:48:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfEK-0004e5-Ak; Fri, 28 Nov 2003 04:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfDU-0004cw-N9 for avt@optimus.ietf.org; Fri, 28 Nov 2003 04:47:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19869; Fri, 28 Nov 2003 04:46:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APfDN-0005x9-00; Fri, 28 Nov 2003 04:47:05 -0500 Received: from [217.32.166.20] (helo=relhubc02-ukbr.tcrelay.net) by ietf-mx with esmtp (Exim 4.12) id 1APfDM-0005uL-00; Fri, 28 Nov 2003 04:47:04 -0500 Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:40:47 +0000 Received: from optimus.ietf.org ([132.151.6.22]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 16:49:30 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2vQ-0008Od-7e; Wed, 26 Nov 2003 11:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP2qb-0007jp-CS for dccp@optimus.ietf.org; Wed, 26 Nov 2003 11:49:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16772; Wed, 26 Nov 2003 11:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP2qa-00019E-00; Wed, 26 Nov 2003 11:49:00 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1AP2qZ-00018x-00; Wed, 26 Nov 2003 11:48:59 -0500 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 hAQGmTlf019080; Wed, 26 Nov 2003 11:48:29 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 26 Nov 2003 11:48:22 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Nov 2003 11:48:22 -0500 Message-ID: From: "Phelan, Tom" To: "'philippe.gentric@philips.com'" Cc: avt@ietf.org, dccp@ietf.org Subject: RE: [AVT] RE: [dccp] Re: DCCP Media Guide Date: Wed, 26 Nov 2003 11:48:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: dccp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-OriginalArrivalTime: 26 Nov 2003 16:50:05.0785 (UTC) FILETIME=[57EFE490:01C3B43D] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Phillipe, TFRC is packet rate based, not bit rate. If TFRC cut your allowed packet rate in half, it'd be OK (at least as far as TFRC is concerned) if you cut your packet rate in half, but doubled the packet size. Of course in many circumstances this action would be unlikely to alleviate the network congestion, and some of these new big packets would probably be lost, causing TFRC to cut the allowed rate even more. TCP, on the other hand, is bit (or byte) rate based. Network congestion is both bit and packet rate based (others things too, I suppose), although I think the packet rate problems are diminishing (Moore's law helping us there). If going to smaller packets gets you a higher bits-on-the-wire rate, then you'd get some of the buffering I was talking about. On the other hand, if the chokepoint was packet-limited rather than bit-limited ... Tom Phelan > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Wednesday, November 26, 2003 11:31 AM > To: Henning Schulzrinne > Cc: avt@ietf.org; dccp@ietf.org > Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide > > > > Henning, TFRC experts, > > > >> It would be interesting to look at the voice response to changing > >> packetization period. > > ... > > > > >We have looked at this systematically, varying the packetization > >threshold. See the papers by Wenyu Jiang and myself at > >http://netbib.info and http://www1.cs.columbia.edu/~wenyu/ > > > > Does anyone have a clue of how changing the packetization > impacts the behavior of TFRC in presence of TCP traffic ? > > For example if an application increases its packet rate > (same media rate, higher transmit rate due to packet headers > contribution increasing) > is that added "pressure" against competing TCP traffic ? > > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ dccp IETF mailing list: dccp@ietf.org list info: https://www1.ietf.org/mailman/listinfo/dccp wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 28 04:54:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20541 for ; Fri, 28 Nov 2003 04:54:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfKA-0005GR-Fm for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 04:54:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAS9s5sV020167 for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 04:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfJ0-0005B2-EA; Fri, 28 Nov 2003 04:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfHP-000566-35 for avt@optimus.ietf.org; Fri, 28 Nov 2003 04:51:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20333; Fri, 28 Nov 2003 04:50:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APfHB-00067Q-00; Fri, 28 Nov 2003 04:51:01 -0500 Received: from [217.32.166.20] (helo=relhubc02-ukbr.tcrelay.net) by ietf-mx with esmtp (Exim 4.12) id 1APfHB-000664-00; Fri, 28 Nov 2003 04:51:01 -0500 Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:44:42 +0000 Received: from optimus.ietf.org ([132.151.6.22]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 14:21:18 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0dB-0004yH-BZ; Wed, 26 Nov 2003 09:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0cp-0004uD-Pc for dccp@optimus.ietf.org; Wed, 26 Nov 2003 09:26:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07810; Wed, 26 Nov 2003 09:26:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0cn-0006B1-00; Wed, 26 Nov 2003 09:26:37 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AP0cn-0006Af-00; Wed, 26 Nov 2003 09:26:37 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27465; Wed, 26 Nov 2003 09:26:04 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA26977; Wed, 26 Nov 2003 09:26:05 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Nov 2003 09:26:04 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B612D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" , "'philippe.gentric@philips.com'" Cc: avt@ietf.org, dccp@ietf.org Date: Wed, 26 Nov 2003 09:26:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: dccp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-OriginalArrivalTime: 26 Nov 2003 14:21:19.0445 (UTC) FILETIME=[8F6C8050:01C3B428] Subject: [AVT] RE: [dccp] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Again, I think the most acceptable response to congestion for video is to rate shift down once, or if necessary, twice to get to an "acceptable" level of errors. So, it's not freeze frame vs rapid rate shift, it's rate shift down vs rapid rate shift. We have a different error result than freeze, and it seems to work better (less objectionable), but it doesn't change the equation. If you get too many errors, you lower the rate until you don't get "too many". It would be interesting to look at the voice response to changing packetization period. Clearly, the effect of the loss of one large packet is worse than the effect of a small packet. Small packets have more bit rate, so, you would presumably be sending larger packets when you have congestion. What does that do to the perceived quality? It's going to get worse as congestion gets worse, which in some sense is "good", but is it actually worse than a higher packet loss rate, but less problem for each loss? Probably depends on the loss pattern. If it were random, than the smaller problem, larger percentage is probably better, but it's not random. There are people who know a lot about such things. I'm not one of them. Do we have some of that expertise around on the list? Has that idea been tried? I do think we need to split this thread, or at least mark replies with "Applies to interactive real time" vs "applies to non-interactive real time". I appreciate several comments on the thread that DCCP may have more applicability to non-interactive streams. While many of the effects are similar (rate shift to non-interactive is just as objectionable to non-interactive as it is to interactive), some things are clearly different (slow start, for example). Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Wednesday, November 26, 2003 8:25 AM > To: 'philippe.gentric@philips.com' > Cc: avt@ietf.org; dccp@ietf.org > Subject: RE: [dccp] Re: DCCP Media Guide > > > Hi Phillipe, > > [snipped] > > The other idea I have been trying to advocate for a while > > because I believe it is another key to the problem > > is that media does not need to be constant bit rate, nor > > constant packet rate, nor constant packet size. > > I'm glad you brought this up. There have been a lot of > comments on this > thread about the difficulties in the human perception of > rate-shifting, and, > in general, I'd have to say the comments are pretty accurate, > especially > given the current state of the art in codec design. However, > I can think of > at least two instances where rate shifting is either workable > or better than > the current practice. > > One case involves audio codecs such as G.711 and changing the > packetization > interval. G.711 with 10ms packetization is about 96K IP bps > on the wire. > 40ms packetization gives about 72K bps. I think that > changing between these > two rates is often close to imperceptible. A similar thing > can be done with > G.729A (although I'm not sure the standard allows it), giving > more variation > in the bit rate - 10ms packetization is about 38.4K bps and > 40ms is 14.4K. > > Another case involves video transmission. As you change > between a high and > low encoding rate the image the user sees is likely to change > back and forth > between clear and grainy, and this is likely to be annoying. > But I imagine > it's less annoying than the current practice of freezing the > video (and > continuing the audio) when there's insufficient bandwidth for > the high-res > video. I imagine that layered encoding techniques like > Gerard Babonneua > mentioned can fit this mode of operation nicely. > > Given that there are these low-hanging-fruit stream shifting > methods, I > wonder what others are available if we put our minds to it? > > Tom Phelan > > > These 3 things (delay, reliability, variable rate/packaging) > > should give some slack > > for the design of a solution with added value no? > > > > regards, > > > > > > Philippe Gentric > > Chief Architect > > Philips Software > > philippe.gentric@philips.com > > http://www.software.philips.com > > > > > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ dccp IETF mailing list: dccp@ietf.org list info: https://www1.ietf.org/mailman/listinfo/dccp wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 28 05:02:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20997 for ; Fri, 28 Nov 2003 05:02:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfRx-0005rn-VX for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 05:02:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASA299k022530 for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 05:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfLf-0005aF-PF; Fri, 28 Nov 2003 04:55:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfK3-0005DY-LN for avt@optimus.ietf.org; Fri, 28 Nov 2003 04:53:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20484; Fri, 28 Nov 2003 04:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APfJz-00069x-00; Fri, 28 Nov 2003 04:53:56 -0500 Received: from [217.32.166.20] (helo=relhubc02-ukbr.tcrelay.net) by ietf-mx with esmtp (Exim 4.12) id 1APfJz-00069K-00; Fri, 28 Nov 2003 04:53:55 -0500 Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:48:05 +0000 Received: from optimus.ietf.org ([132.151.6.22]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:55:20 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4uL-0000I1-Va; Wed, 26 Nov 2003 14:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0V5-0004M7-6P for dccp@optimus.ietf.org; Wed, 26 Nov 2003 09:18:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07564; Wed, 26 Nov 2003 09:18:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0V3-00065a-00; Wed, 26 Nov 2003 09:18:37 -0500 Received: from mail0.rawbw.com ([198.144.192.41]) by ietf-mx with esmtp (Exim 4.12) id 1AP0V2-00065W-00; Wed, 26 Nov 2003 09:18:36 -0500 Received: from io.herlein.com (m205-238.dsl.tsoft.com [198.144.205.238]) by mail0.rawbw.com (8.11.6p2/8.11.6) with ESMTP id hAQEIUo72722; Wed, 26 Nov 2003 06:18:30 -0800 (PST) Date: Wed, 26 Nov 2003 06:18:28 -0800 (PST) From: Greg Herlein X-X-Sender: gregh@io.herlein.com To: avt@ietf.org, Subject: Re: [AVT] Re: [dccp] Re: DCCP Media Guide In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: dccp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-OriginalArrivalTime: 26 Nov 2003 18:55:24.0257 (UTC) FILETIME=[D94BAD10:01C3B44E] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > I fully agree this is the fundamental reason why another > protocol than TCP is a good idea: media does not need 100% > reliability. I don't agree. *Some* media does not need 100% reliability. But many video codecs have pathetic performance in the face of packet loss - and FEC is not always a good solution (impact on bandwidth is one reason - complexity is another). Audio is often a lot more tolerant (at least in VoIP) - a loss spurt in video is radically painful for the viewer in most cases. While TCP does have it's own problems for video delivery (and some advantages too) it's not the ideal solution, clearly. I most wholeheartedly agree that delay, reliability, variable rate/packaging are the three elements that *can* be adjusted to modify the performance of a video stream. To that I would add dynamic buffering at the endpoints (goes with rate, I guess). I'd like to see a protocol (or extension) that can implement this into apps that can use it to good measure, as opposed to generating YAP (yet another protocol) that addresses only one aspect of the problem (and in only one way). Greg Herlein VP Engineering Arkstream, Inc. _______________________________________________ dccp IETF mailing list: dccp@ietf.org list info: https://www1.ietf.org/mailman/listinfo/dccp wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Nov 28 05:02:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20999 for ; Fri, 28 Nov 2003 05:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfRy-0005tX-Lz for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 05:02:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASA2AwB022610 for avt-archive@odin.ietf.org; Fri, 28 Nov 2003 05:02:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfNR-0005fs-NF; Fri, 28 Nov 2003 04:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfK5-0005E0-Fl for avt@optimus.ietf.org; Fri, 28 Nov 2003 04:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20488; Fri, 28 Nov 2003 04:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APfK2-0006A2-00; Fri, 28 Nov 2003 04:53:58 -0500 Received: from [217.32.166.20] (helo=relhubc02-ukbr.tcrelay.net) by ietf-mx with esmtp (Exim 4.12) id 1APfK1-00069K-00; Fri, 28 Nov 2003 04:53:57 -0500 Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC; Fri, 28 Nov 2003 09:48:06 +0000 Received: from optimus.ietf.org ([132.151.6.22]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 18:55:20 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4uM-0000IQ-W8; Wed, 26 Nov 2003 14:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0xM-0006v6-Dy for dccp@optimus.ietf.org; Wed, 26 Nov 2003 09:47:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08609; Wed, 26 Nov 2003 09:47:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0xK-0006TM-00; Wed, 26 Nov 2003 09:47:50 -0500 Received: from pecan.cc.columbia.edu ([128.59.59.178] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1AP0xJ-0006TJ-00; Wed, 26 Nov 2003 09:47:49 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hAQE9ji8005398 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Nov 2003 09:09:45 -0500 (EST) Message-ID: <3FC4B428.5020806@cs.columbia.edu> Date: Wed, 26 Nov 2003 09:09:44 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'philippe.gentric@philips.com'" , avt@ietf.org, dccp@ietf.org Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit X-BeenThere: dccp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-OriginalArrivalTime: 26 Nov 2003 18:55:28.0757 (UTC) FILETIME=[DBFA5250:01C3B44E] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > One case involves audio codecs such as G.711 and changing the packetization > interval. G.711 with 10ms packetization is about 96K IP bps on the wire. > 40ms packetization gives about 72K bps. I think that changing between these > two rates is often close to imperceptible. A similar thing can be done with > G.729A (although I'm not sure the standard allows it), giving more variation > in the bit rate - 10ms packetization is about 38.4K bps and 40ms is 14.4K. While this is numerically accurate, it seems largely pointless. If I'm below the perceptible delay threshold (say 150 ms one-way), there is no reason to transmit at 10 ms packetization interval since the user experience will not improve noticeably. Indeed, very few systems transmit at 10 ms packetization today. In addition, at the access links where congestion is most likely, IP/UDP/RTP header compression reduces the difference in bit rates to much smaller values, further reducing the utility of doing variable packetization. (From our experiments, a packetization interval of roughly 30-40 ms also appears to work best with FEC.) > > Another case involves video transmission. As you change between a high and > low encoding rate the image the user sees is likely to change back and forth > between clear and grainy, and this is likely to be annoying. But I imagine > it's less annoying than the current practice of freezing the video (and > continuing the audio) when there's insufficient bandwidth for the high-res > video. I imagine that layered encoding techniques like Gerard Babonneua > mentioned can fit this mode of operation nicely. Again, like Brian pointed out, this assumes that you're aiming for a low-quality hey-it's-free experience. > > Given that there are these low-hanging-fruit stream shifting methods, I > wonder what others are available if we put our minds to it? Unfortunately, the first is unlikely to be productive and the second has very limited applicability. _______________________________________________ dccp IETF mailing list: dccp@ietf.org list info: https://www1.ietf.org/mailman/listinfo/dccp wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Nov 29 17:21:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28639 for ; Sat, 29 Nov 2003 17:21:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQDSr-0004lc-IW for avt-archive@odin.ietf.org; Sat, 29 Nov 2003 17:21:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATMLL42018312 for avt-archive@odin.ietf.org; Sat, 29 Nov 2003 17:21:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQDSX-0004h4-Sg; Sat, 29 Nov 2003 17:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APgY1-00017E-N9 for avt@optimus.ietf.org; Fri, 28 Nov 2003 06:12:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23473; Fri, 28 Nov 2003 06:12:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APgXx-0007fz-00; Fri, 28 Nov 2003 06:12:25 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1APgXw-0007fv-00; Fri, 28 Nov 2003 06:12:24 -0500 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 12:12:15 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : [AVT] RE: [dccp] Re: DCCP Media Guide Date: Fri, 28 Nov 2003 12:12:15 +0100 Message-ID: <6F704D0B4CD23044990B4F8999F463DD4B72A1@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [AVT] RE: [dccp] Re: DCCP Media Guide Thread-Index: AcO0Pi1TX4n3Vy85QW2D5xAU4aMn5ABWfEyQ From: =?iso-8859-1?Q?BABONNEAU_G=E9rard_FTRD/DMI/REN?= To: "Phelan, Tom" , Cc: , X-OriginalArrivalTime: 28 Nov 2003 11:12:15.0902 (UTC) FILETIME=[7AF8B3E0:01C3B5A0] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Tom, I think it is important to highlight the lack of performances of most = codecs to a few losses in a network. Today, without losses, = hierarchicals codecs give a little bit less quality than state of the = art as MPEG4-AVC. Works are in progress to obtain the same quality with = multilayers codecs than monolayer (ie: MPEG SVC, MPEG-21 Part 13). = Hierarchical codecs allow an easy differentiation of data in network and = in transport layer, and they can help in the objective that a minimum of = data reach the decoder for a minimal quality, instead of nothing or = something out of tune. Best regards, G=E9rard =20 -----Message d'origine----- De : Phelan, Tom [mailto:tphelan@sonusnet.com]=20 Envoy=E9 : mercredi 26 novembre 2003 14:25 =C0 : 'philippe.gentric@philips.com' Cc : avt@ietf.org; dccp@ietf.org Objet : [AVT] RE: [dccp] Re: DCCP Media Guide Hi Phillipe, [snipped] > The other idea I have been trying to advocate for a while because I=20 > believe it is another key to the problem is that media does not need=20 > to be constant bit rate, nor constant packet rate, nor constant packet = > size. I'm glad you brought this up. There have been a lot of comments on this = thread about the difficulties in the human perception of rate-shifting, = and, in general, I'd have to say the comments are pretty accurate, = especially given the current state of the art in codec design. However, = I can think of at least two instances where rate shifting is either = workable or better than the current practice. One case involves audio codecs such as G.711 and changing the = packetization interval. G.711 with 10ms packetization is about 96K IP = bps on the wire. 40ms packetization gives about 72K bps. I think that = changing between these two rates is often close to imperceptible. A = similar thing can be done with G.729A (although I'm not sure the = standard allows it), giving more variation in the bit rate - 10ms = packetization is about 38.4K bps and 40ms is 14.4K. Another case involves video transmission. As you change between a high = and low encoding rate the image the user sees is likely to change back = and forth between clear and grainy, and this is likely to be annoying. = But I imagine it's less annoying than the current practice of freezing = the video (and continuing the audio) when there's insufficient bandwidth = for the high-res video. I imagine that layered encoding techniques like = Gerard Babonneua mentioned can fit this mode of operation nicely. Given that there are these low-hanging-fruit stream shifting methods, I = wonder what others are available if we put our minds to it? Tom Phelan > These 3 things (delay, reliability, variable rate/packaging) should=20 > give some slack for the design of a solution with added value no? >=20 > regards, >=20 >=20 > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com >=20 >=20 >=20 > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html >=20 _______________________________________________ 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 exim@www1.ietf.org Sat Nov 29 17:21:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28654 for ; Sat, 29 Nov 2003 17:21:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQDSr-0004mI-Ka for avt-archive@odin.ietf.org; Sat, 29 Nov 2003 17:21:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATMLLkP018313 for avt-archive@odin.ietf.org; Sat, 29 Nov 2003 17:21:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQDSY-0004hG-Ij; Sat, 29 Nov 2003 17:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APjxb-00014Q-UW for avt@optimus.ietf.org; Fri, 28 Nov 2003 09:51:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29631 for ; Fri, 28 Nov 2003 09:50:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APjxZ-0003Mz-00 for avt@ietf.org; Fri, 28 Nov 2003 09:51:05 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1APjxZ-0003Mw-00 for avt@ietf.org; Fri, 28 Nov 2003 09:51:05 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hASEp4S05675; Fri, 28 Nov 2003 15:51:04 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hASEp3P06703; Fri, 28 Nov 2003 15:51:04 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 28 Nov 2003 15:50:45 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F040689C0@mchp905a.mch.sbs.de> From: Wagner Marcel To: "'Magnus Westerlund'" , liebl@lnt.e-technik.tu-muenchen.de, Pandel Juergen , Weng Wenrong Cc: avt@ietf.org Date: Fri, 28 Nov 2003 15:50:54 +0100 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 Content-Transfer-Encoding: quoted-printable Subject: [AVT] AW: Comments on draft-ietf-avt-uxp-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Magnus, thank you very much for your helpful comments. We will consider them in = the next revision of the UXP draft.=20 Regards, Marcel > -----Urspr=FCngliche Nachricht----- > Von: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Gesendet: Montag, 24. November 2003 23:10 > An: liebl@lnt.e-technik.tu-muenchen.de; Wagner Marcel; Pandel=20 > Juergen; Weng Wenrong > Cc: avt@ietf.org > Betreff: Comments on draft-ietf-avt-uxp-06.txt >=20 >=20 > Hi, >=20 > Sorry for being so late with my comments. I think the concept is good > enough however there is quite a lot of work left until this is a good = > protocol specification. >=20 > 1. I think of a lot of the background material on how Reed > Salomon codes=20 > work should be moved to the introduction. In other word section 3,4,5 = > can be put into the a common chapter, possibly with=20 > subsections, however=20 > I think one should be clearer about they being introductionary. >=20 > 2. Then there is need to start writing some real payload > specification=20 > chapter. Of the present chapter I think the largest hole is=20 > how one goes=20 > from a unprotected stream into a protected one. As I see it one will=20 > take a series of complete RTP packets and then put them into=20 > payloads of=20 > new RTP packets. >=20 > 3. There is need to be much clearer on how one fills in the > protection=20 > matrix and then can on the receiver side understand how one=20 > has written=20 > the bytes from different packets into the matrix to correctly=20 > recover it. >=20 > 4. I think you authors should consider to include some more > blank lines,=20 > or in certain cases do a page break between section to improve the=20 > readability of the text. For example the TOC should be moved into a=20 > separate page. Please do also put in a blank line between=20 > each paragraph. >=20 > 5. You are missing the short copyright statement after status of this > memo and the abstract. See ID-nits http://www.ietf.org/ID-nits.html >=20 > 6. Chapter 2 is very hard to read. I would suggest that > instead of using=20 > numbered bullets, you use the definition being left justified=20 > and then=20 > put the definition more right justified. You may also consider of all = > these definitions really make sense to be defined in=20 > conventions or if=20 > they more belong in there respective chapter. >=20 > 7. The H.26L is now H.264, >=20 > 8. In section 4. The following sentence exist: > "Furthermore, if channel > conditions get worse during transmission, only more and more > enhancement layers are lost, i.e. a graceful degradation in > application quality at the receiver is achieved [6]." >=20 > This sentence can be rather dangerous in IETF. The general > channel you=20 > are talking about is the IP channel which normally only=20 > losses packets=20 > due to congestion. Therefore this sentence can be interpreted as by=20 > simply adding more protection one can avoid most effects of=20 > congestion.=20 > So if you are talking about the very special case for links=20 > that loses=20 > packet of other reasons I think you need to be very explicit. >=20 > 9. Figure 3 should be moved into the introduction when you > discuss Reed=20 > Salomon codes. >=20 > 10. Page 11, bullet 2. How does on determine the expected > number of TSB=20 > rows? >=20 > 11. What RTP timestamp rate should be used for this format? Does it > really need one? or could one simply transmission time stamp=20 > the packets? >=20 > 12. Please use more normative wording when defining how the > marker bit=20 > should be set. >=20 > 13. Section 6.1: "All other fields in the RTP header are set to those > values > proposed for regular multimedia transmission using the RTP-format > of the media stream which is protected by UXP, e.g. for MPEG-4 > Visual as specified in RFC 3016." > Normal there are no more fields then RTP TS and Marker bit that the=20 > payload format defines, the rest is set in accordance with the RTP=20 > specification and the profile in use. >=20 > 14. What is the gain of having the protected media's PT > available in the=20 > UXP header? As I understand it you will need to decode the minimal=20 > number packets possible to reconstruct the stream to use it at all. >=20 > 15. How does one treat packets where one is able to recover > parts of the=20 > packets? >=20 > 16. The proposed RTP Timestamp assignment mechanism will make > the RTCP=20 > jitter unusable, if this is deemed acceptable, then at least=20 > it should=20 > be noted. >=20 > 17. I would recommend that the description of the processing becomes > much less media oriented and much more common RTP and its=20 > payload specific. >=20 > 18. I would also like that the specification is more explicit how can > give different protection levels to different packets or parts of a=20 > packet. There need to be more information about this topic making it=20 > possible for a implementor of UXP for a certain purpose being able to = > determine how they should behave. >=20 > 19. This payload format need to register a MIME subtype for > all the main=20 > media types that uses RTP at all. >=20 > 20. Then one can write a chapter on how to map this to SDP. >=20 > 21. In the security section the following text is present: > " The overall ratio between parity and info octets MUST NOT be > higher than 1:1, i.e. the absolute bitrate spent for redundancy > must not be larger than the bitrate required for transmission of > multimedia data itself." > =20 > This statement I understand is intended to address congestion > control.=20 > This isn't very useful, as the transmission rate in the face=20 > of loss in=20 > a best effort network shall not be higher than what a TCP flow would=20 > achieve over the same path. However the mix between=20 > protection and real=20 > data can be any and should be controlled only in regards to the paths = > error characteristics. This results in a the trade-off between=20 > protection and media. >=20 > 22. You are missing the IETF standard IPR statement, see ID-nits for > references to the sections from RFC 2026 you need. >=20 > 23. I think you can write an separate address for each of the = authors. >=20 > I hope this will provide you with input in writing the next version. >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 >=20 >=20 > =20 >=20 >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt