From mailnull@www1.ietf.org Sat Mar 1 19:20:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21219 for ; Sat, 1 Mar 2003 19:20:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h220U5Y11749 for avt-archive@odin.ietf.org; Sat, 1 Mar 2003 19:30:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h220Tjp11691; Sat, 1 Mar 2003 19:29:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h220Sdp11656 for ; Sat, 1 Mar 2003 19:28:39 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21165 for ; Sat, 1 Mar 2003 19:18:53 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h220KXRT000311; Sat, 1 Mar 2003 19:20:38 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200303020020.h220KXRT000311@purple.nge.isi.edu> To: "Hager, Todd" cc: avt@ietf.org Subject: Re: [AVT] question: mapping dynamic RTP formats using SDP In-Reply-To: Your message of "Fri, 28 Feb 2003 17:17:54 PST." <5FCCC03CAF7C5C4C8E2F995E3D72E1334BBB5C@platinum.dolby.net> Date: Sat, 01 Mar 2003 19:20:33 -0500 From: Colin Perkins 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: , --> "Hager, Todd" writes: >What is the best method to define a valid encoding name for a new >encoding format? > >Regarding , I'm trying to determine the >best method of choosing a value for the payload type for AC-3 in the RTP >header. > >I am proceeding under the assumption that the best course is to randomly >choose a value from the dynamic range (96-127) described in for Audio and Video Conferences with Minimal Control.txt> (RFC 1890), >and use SDP to somehow map this value to the AC-3 encoding type. I have >questions regarding the SDP mapping process. Each application using the AC-3 payload format picks a payload type number from the dynamic range each time it starts. The chosen value is exchanged in SDP, as part of the call setup signalling (e.g. using SIP or RTSP). >Pages 21 and 22 in the SDP specification (RFC 2327) indicate the >following mechanism to map a dynamic format ID : > >m= / > >and > >a=rtpmap: /[/parameters>] > >Therefore, an SDP description ought to be able to incorporate the >following two lines: > >m=audio 49232 RTP/AVP 98 >a=rtpmap:98 /48000 Correct. The actual payload type number that is assigned will be different each time an application is started, and the "a=rtpmap:" line is used to convey the mapping from the fixed encoding name to the ephemeral payload type number. >How does the AVT group suggest I define ? Should I >submit a new Internet Draft describing a full profile specifically for >this format, or can I simply use the AC-3 RTP Payload document itself as >the vehicle that registers a valid AV Profile encoding name? > >Alternatively, though the current AC-3 RTP Payload draft document does >not currrently define an AV RTP Profile encoding name, it does define a >MIME type description for AC-3. The SDP spec allows MIME types to >describe media encodings, but the wording of the SDP spec (page 22) >implies that this is only intended to be used for non-RTP streams. RTP originally used a separate namespace for payload format names, but now uses the MIME namespace. The registration procedure is defined in draft-ietf-avt-rtp-mime-06.txt. >Which is the most appropriate course of action: > >1) Define a new RTP profile, >2) Use the AC-3 RTP payload document to define a valid encoding name for >the AC-3 format, or >3) Use the defined MIME type to map a dynamic AV Profile payload type to >AC-3? The third option is correct. The MIME type defined in the AC-3 payload format is used as the SDP encoding name (The MIME type registration in Section 4 of draft-flaks-avt-rtp-ac3-03.txt looks good, I don't think you need to add anything). Cheers, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Mar 1 22:06:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23582 for ; Sat, 1 Mar 2003 22:06:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h223FS922259 for avt-archive@odin.ietf.org; Sat, 1 Mar 2003 22:15:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h223Elp22223; Sat, 1 Mar 2003 22:14:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h223DIp22166 for ; Sat, 1 Mar 2003 22:13:18 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23570 for ; Sat, 1 Mar 2003 22:03:31 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id TAA09706 for avt@ietf.org; Sat, 1 Mar 2003 19:05:12 -0800 Date: Sat, 1 Mar 2003 19:05:12 -0800 From: John Lazzaro Message-Id: <200303020305.TAA09706@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] MWPP I-Ds ... 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 everyone, Sent the San Francisco versions of the MWPP normative and guidelines documents off to internet-drafts today, you can pick up early copies at: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt The heavy-duty work was done on the normative document (another 3-page change log), the guidelines document changes are a refresh to keep it in sync with the normative document. The original hope was that the normative document would be a "candidate Last Call", but alas, it was not meant to be. The original "open issues" list is actually (mostly) addressed by the new document -- the problem is that the "open issues" list is growing again ... On the bright side, the list is growing for a good reason; the MMA (the MIDI Manufacturers Association, ), which works together with the AMEI ( ), has been passing along MWPP concerns to me, via Jim Wright. Jim and I have worked out a set of MMA requirements for MWPP, and I'm going to spend March doing design work to meet them. If those changes are non-controversial for AVT folks, then we may finally be near Last Call in early April. ------------------------------------------------------------------------- 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 mailnull@www1.ietf.org Sun Mar 2 01:09:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25535 for ; Sun, 2 Mar 2003 01:09:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h226IxS32187 for avt-archive@odin.ietf.org; Sun, 2 Mar 2003 01:18:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h226Icp32169; Sun, 2 Mar 2003 01:18:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h226Hdp32128 for ; Sun, 2 Mar 2003 01:17:39 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25523 for ; Sun, 2 Mar 2003 01:07:47 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h22696Vl085371; Sat, 1 Mar 2003 22:09:07 -0800 (PST) (envelope-from casner@acm.org) Date: Sat, 1 Mar 2003 22:11:05 -0800 (PST) From: Stephen Casner To: Jonathan Rosenberg cc: AVT WG Subject: Re: [AVT] RTP: SSRC multiplexing for same medium In-Reply-To: <3E26E241.7060302@dynamicsoft.com> Message-ID: <20030301220331.Q67226-100000@oak.packetdesign.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: , Delayed response as I finally get to finishing the editing: On Thu, 16 Jan 2003, Jonathan Rosenberg wrote: > Stephen Casner wrote: > >>2. Does this text imply that an RTP receiver MUST be prepared to receive > >>multiple multiplexed streams on a single session? I expect most > >>implementations today using unicast are not prepared for that (although > >>I believe they should be) > > > > No, it would be inappropriate to make that a MUST. We do say, in > > Section 6: > > > > RTP application designers SHOULD avoid mechanisms that can only > > work in unicast mode and will not scale to larger numbers. > > I have a hard time seeing how this implies that receiving multiple > streams on a single session is not a MUST. Certainly it is a good idea, but as you can see, the word in the sentence I quoted from Section 6 is SHOULD, not MUST. > Indeed, receiving many > streams on a single session is how multicast works, so one would imagine > that the direct translation of this to unicast, receiving multiple > streams on a single port for multi-unicast, would be the recommended > approach. Yes, I agree. > If RTP does not mandate that a user be prepared to receive multiple > streams on a single session for unicast (even though it does for > multicast), I think it needs to say that its up to signaling mechanisms > to indicate such a limitation. Of course, SDP has no such mechanism.... I've added the following sentence in the definition of "RTP session" to address that: The RTP framework allows the variations defined here, but a particular control protocol or application design will usually impose constraints on these variations. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 2 17:11:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19282 for ; Sun, 2 Mar 2003 17:11:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h22MKhw03536 for avt-archive@odin.ietf.org; Sun, 2 Mar 2003 17:20:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22MJop03436; Sun, 2 Mar 2003 17:19:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22L7Ap31156 for ; Sun, 2 Mar 2003 16:07:10 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18273 for ; Sun, 2 Mar 2003 15:56:49 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h22KwXVR027865 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Sun, 2 Mar 2003 21:58:33 +0100 X-pt: isis.lip6.fr Received: from doris (doris.ipv6.lip6.fr [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h22KwX316806; Sun, 2 Mar 2003 21:58:33 +0100 (MET) From: Timur Friedman To: avt@ietf.org Date: Sun, 2 Mar 2003 22:58:44 +0100 User-Agent: KMail/1.4.3 Cc: Ramon Caceres , Alan Clark , Kevin Almeroth , Kamil Sarac , Robert Cole , Kaynam Hedayat , Nick Duffield References: <200301242135.31937.timur.friedman@lip6.fr> <200301242156.03464.timur.friedman@lip6.fr> In-Reply-To: <200301242156.03464.timur.friedman@lip6.fr> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_WD65OVMBFJDCRLLQ6Y7F" Message-Id: <200303022258.44719.timur.friedman@lip6.fr> X-Scanned-By: isis.lip6.fr Subject: [AVT] draft-ietf-avt-rtcp-report-extns-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: , --------------Boundary-00=_WD65OVMBFJDCRLLQ6Y7F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Please find attached the latest version of the RTP Extended Reports (RTP XR) draft, draft-ietf-avt-rtcp-report-extns-03.txt, which ha= s=20 just been sent to internet-drafts@ietf.org. We request that this draft be advanced to working group final call at thi= s=20 stage, on the proposed standard RFC track. Here are the changes since the previous version: * The 02 draft specified signal and noise levels in terms of dBm0 with respect to overload conditions - this has been changed to dBm, while retaining the definitions for talkspurts vs silence periods. The signal and noise level fields are now adjacent to each other. * In Section 4, changed the text "An implementation MAY ignore incoming blocks with types either not relevant or unknown" to be "An implementation SHOULD ignore...". Thank you Colin for spotting this. * Reverted the definition of reserved fields to the way it was in the 01 draft. A receiver that does not know of a definition for the field simply ignores the field, not the entire block or report. * Changed CODEC to codec. This term appears in Webster's New World Dictionary, Third College Edition as a common noun. Corrected some spelling errors. A PDF version of this draft can be found at the following location: http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repor= t-extns-03.pdf Regards, Timur Friedman --------------Boundary-00=_WD65OVMBFJDCRLLQ6Y7F Content-Type: text/plain; charset="iso-8859-1"; name="draft-ietf-avt-rtcp-report-extns-03.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtcp-report-extns-03.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT 2 March 2003 Internet Engineering Task Force Expires: 2 September 2003 Audio/Video Transport Working Group Timur Friedman, Paris 6 Ramon Caceres, ShieldIP Alan Clark, Telchemy Editors RTP Extended Reports (RTP XR) draft-ietf-avt-rtcp-report-extns-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the extended report (XR) packet type for the RTP control protocol (RTCP). 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 Friedman, Caceres, and Clark, eds. [Page 1] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 (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. Table of Contents 1. Introduction .............................................. 2 1.1 Terminology ............................................... 3 2. XR Packet Format .......................................... 4 3. Extended Report Block Framework ........................... 5 4. Extended Report Blocks .................................... 6 4.1 Loss RLE Report Block ..................................... 6 4.1.1 Run Length Chunk .......................................... 12 4.1.2 Bit Vector Chunk .......................................... 12 4.1.3 Terminating Null Chunk .................................... 12 4.2 Duplicate RLE Report Block ................................ 13 4.3 Timestamp Report Block .................................... 14 4.4 Statistics Summary Report Block ........................... 16 4.5 Receiver Timestamp Report Block ........................... 19 4.6 DLRR Report Block ......................................... 20 4.7 VoIP Metrics Report Block ................................. 21 4.7.1 Packet Loss and Discard Metrics ........................... 22 4.7.2 Burst Metrics ............................................. 23 4.7.3 Delay Metrics ............................................. 25 4.7.4 Signal Related Metrics .................................... 26 4.7.5 Call Quality or Transmission Quality Metrics .............. 29 4.7.6 Configuration Parameters .................................. 30 4.7.7 Jitter Buffer Parameters .................................. 31 5. IANA Considerations ....................................... 32 5.1 XR Packet Type ............................................ 32 5.2 RTP XR Block Type Registry ................................ 32 6. Security Considerations ................................... 33 A. Algorithms ................................................ 34 A.1 Sequence Number Interpretation ............................ 34 A.2 Example Burst Packet Loss Calculation ..................... 35 Intellectual Property ..................................... 37 Full Copyright Statement .................................. 37 Acknowledgments ........................................... 38 Contributors .............................................. 38 Authors' Addresses ........................................ 39 References ................................................ 40 Normative References ...................................... 40 Non-Normative References .................................. 41 1. Introduction This document defines the extended report (XR) packet type for the Friedman, Caceres, and Clark, eds. [Page 2] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 RTP control protocol (RTCP) [7]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or receiver report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance. The definition is broken out over the three following sections of this document, starting with a general framework and finishing with the specific information conveyed. The framework defined by Section 2 contains common header information followed by a series of components called report blocks. Section 3 defines the format common to such blocks. Section 4 defines seven block types. Seven report block formats are defined by this document: - Loss RLE Report Block (Section 4.1): Run length encoding of RTP packet loss reports. - Duplicate RLE Report Block (Section 4.2): Run length encoding of reports of RTP packet duplicates. - Timestamp Report Block (Section 4.3): A list of timestamps of received RTP packets. - Statistics Summary Report Block (Section 4.4): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL values. - Receiver Timestamp Report Block (Section 4.5): Receiver-end timestamps that complement the sender-end timestamps already defined for RTCP. - DLRR Report Block (Section 4.6): The delay since the last Receiver Timestamp Report Block was received, allowing non-senders to calculate round-trip times. - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls. These blocks are defined within a minimal framework: a type field and a length field are common to all XR blocks. The purpose is to maintain flexibility and to keep overhead low. Other block formats, beyond the seven defined here, may be defined within this framework as the need arises. 1.1 Terminology Friedman, Caceres, and Clark, eds. [Page 3] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliance with this specification. 2. XR Packet Format The XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|reserved | PT=3DXP=3D207 | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two. padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification. reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. packet type (PT): 8 bits Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 5.1. length: 16 bits As described for the RTP sender report (SR) packet (see Section 6.3.1 of the RTP specification [7]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding. Friedman, Caceres, and Clark, eds. [Page 4] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 SSRC: 32 bits The synchronization source identifier for the originator of this XR packet. report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words. 3. Extended Report Block Framework Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks. Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize. An extended report block has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Section 5.2. type-specific: 8 bits The use of these bits is determined by the block type definition. block length: 16 bits The length of this report block including the header, in 32-bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only Friedman, Caceres, and Clark, eds. [Page 5] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 the BT, type-specific, and block length fields, with a null type-specific data field. type-specific data: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long. 4. Extended Report Blocks This section defines seven extended report blocks: block types for losses, duplicates, packet reception timestamps, detailed reception statistics, receiver timestamps, receiver inter-report delays, and voice over IP (VoIP) metrics. An implementation SHOULD ignore incoming blocks with types either not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [5], as described in Section 5.2. 4.1 Loss RLE Report Block This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [8]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree. Or they could be used to provide raw data to a network management application. Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [9]. A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [7] in the following two areas: per-sender accounting and per-packet accounting. In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This accounting technique differs from the technique described in Section Friedman, Caceres, and Clark, eds. [Page 6] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid. In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accounting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets. Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application. One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets. The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique. Each block reports on a single source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet. Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report. Friedman, Caceres, and Clark, eds. [Page 7] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 Note that because of sequence number wraparound the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means to identify multiple wraparounds. The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wraparound of sequence numbers (or since the beginning of the RTP session if no wraparound has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number. The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to round out the block to a 32 bit word boundary. The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 One way to encode this would be: bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk Another way to encode this would be: Friedman, Caceres, and Clark, eds. [Page 8] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence were lost: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 This could be encoded as: run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero. All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver. A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context. Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes. A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero then every packet in the sequence number space is reported upon. If T is fifteen then one in Friedman, Caceres, and Clark, eds. [Page 9] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 every 32,768 packets is reported upon. Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=3D2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows: 1 1 1 1 1 0 1 1 1 1 0 This could be encoded as follows: bit vector 1111 1011 1100 000 null chunk The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word. Choice of the thinning value is left to the application. The Loss RLE Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 10] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D1 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). block length: 16 bits Defined in Section 3. begin_seq: 16 bits The first sequence number that this block reports on. end_seq: 16 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null, defined in the following sections. If the chunk is all zeroes then it is a terminating null chunk. Otherwise, the leftmost bit of the chunk determines its type: 0 for run length and 1 for bit vector. Friedman, Caceres, and Clark, eds. [Page 11] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 4.1.1 Run Length Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| run length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A zero identifies this as a run length chunk. run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s. run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. 4.1.2 Bit Vector Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| bit vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A one identifies this as a bit vector chunk. bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wraparound). 4.1.3 Terminating Null Chunk This chunk is all zeroes. Friedman, Caceres, and Clark, eds. [Page 12] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Duplicate RLE Report Block This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference. The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received. The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space. No distinction is made between the existence of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block. The Duplicate RLE Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 13] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D2 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. chunk i: 16 bits As defined in Section 4.1. 4.3 Timestamp Report Block This block type permits per-sequence-number reports on packet receipt timestamps for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial path characteristics and to model distributions for packet jitter. Friedman, Caceres, and Clark, eds. [Page 14] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report timestamps for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receiver timestamps, any timestamp other than the earliest MUST NOT be reported. This is to ensure consistency among reports. Timestamps consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Timestamp Report Blocks. The Timestamp Report Block has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Timestamp Report Block is identified by the constant 3. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. Friedman, Caceres, and Clark, eds. [Page 15] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. RTP timestamp i: 32 bits The timestamp reflects the packet arrival time at the receiver. It is preferable for the timestamp to be established at the link layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receiver timestamps should reflect the actual time as closely as possible. The initial value of the timestamp is random, and subsequent timestamps are offset from this value. 4.4 Statistics Summary Report Block This block reports statistics beyond the information carried in the standard RTCP packet format, but not as fine grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL values (TTL values being taken from the TTL field of IPv4 packets, if the data packets are carried over IPv4). Such information can be useful for network management. The report block contents are dependent upon a bit vector carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported. The Statistics Summary Report Block has the following format: Friedman, Caceres, and Clark, eds. [Page 16] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D4 |L|D|J|T| rsvd. | block length =3D 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lost_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | max_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | avg_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_ttl | max_ttl | avg_ttl | dev_ttl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 4. loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise. duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise. jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, avg_jitter, and dev_jitter fields all contain reports, 0 if none of them do. TTL flag (T): 1 bit Bit set to 1 if the min_ttl, max_ttl, avg_ttl, and dev_ttl fields all contain reports, 0 if none of them do. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and Friedman, Caceres, and Clark, eds. [Page 17] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 MUST be ignored by the receiver. block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. lost_packets: 32 bits Number of lost packets in the above sequence number interval. dup_packets: 32 bits Number of duplicate packets in the above sequence number interval. min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units. max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval. avg_jitter: 32 bits The average relative transit time between each two packet series in the above sequence number interval. dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval. min_ttl: 8 bits The minimum TTL value of data packets in sequence number range. max_ttl: 8 bits The maximum TTL value of data packets in sequence number range. avg_ttl: 8 bits The average TTL value of data packets in sequence number range. dev_ttl: 8 bits Friedman, Caceres, and Clark, eds. [Page 18] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 The standard deviation of TTL values of data packets in sequence number range. 4.5 Receiver Timestamp Report Block This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate its RTT to other participants, as proposed in [11], by sending this report block and receiving DLRR Report Blocks (see next section) in reply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D5 | reserved | block length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Receiver Timestamp Report Block is identified by the constant 5. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3. NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed Friedman, Caceres, and Clark, eds. [Page 19] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero. 4.6 DLRR Report Block This block extends RTCP's delay since last sender report (DLSR) mechanism [7, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [11]. It is termed DLRR for delay since last receiver report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondent. The report consists of one or more 3 word sub-blocks: one sub-block per receiver report. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D6 | reserved | block length | +=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+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=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+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k : ... : 2 +=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+ block type (BT): 8 bits A DLRR Report Block is identified by the constant 6. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits Defined in Section 3. last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section) received as part of a Receiver Friedman, Caceres, and Clark, eds. [Page 20] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 Timestamp Report Block from participant SSRC_n. If no such block has been received, the field is set to zero. delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Timestamp Report Block from participant SSRC_n and sending this DLRR Report Block. If no Receiver Timestamp Report Block has been received yet from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as A-LSR-DLSR. This is illustrated in [7, Fig. 2]. 4.7 VoIP Metrics Report Block The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality. In order to properly assess the quality of a Voice over IP call it is desirable to consider the degree of burstiness of packet loss [10]. Following a Gilbert-Elliott model [2], a period of time, bounded by lost and/or discarded packets, with a high rate of losses and/or discards is a "burst," and a period of time between two bursts is a "gap." Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTCP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [2]) and mean opinion scores (MOS scores). An implementation that sends these blocks SHOULD send at least one every ten seconds for the duration of the call, SHOULD send one whenever a codec type change or other significant change occurs, SHOULD send one when significant call quality degradation is detected Friedman, Caceres, and Clark, eds. [Page 21] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 and SHOULD send one upon call termination. Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided. The block is encoded as seven 32-bit words: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D7 | reserved | block length =3D 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss rate | discard rate | burst density | gap density | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burst duration | gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | round trip delay | end system delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signal level | noise level | RERL | Gmin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R factor | ext. R factor | MOS-LQ | MOS-CQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX config | JB nominal | JB maximum | JB abs max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 6, in accordance with the definition of this field in Section 3. The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters. 4.7.1 Packet Loss and Discard Metrics It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the Friedman, Caceres, and Clark, eds. [Page 22] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 quality of the voice stream however having separate counts helps identify the source of quality degradation. These fields MUST be populated. loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard. discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. 4.7.2 Burst Metrics A burst, informally, is a period of high packet losses and/or discards. Formally, a burst is defined as a longest sequence of packets bounded by lost or discarded packets with the constraint that within a burst any sequence of successive packets that were received, and not discarded due to delay variation, is of length less than a value Gmin. A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts. Friedman, Caceres, and Clark, eds. [Page 23] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets. A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard density within a gap of: 1 / (Gmin + 1). A Gmin value of 16 is RECOMMENDED as it results in gap characteristics that correspond to good quality (i.e. low packet loss rate, a minimum distance of 16 received packets between lost packets) and hence differentiates nicely between good and poor quality periods. For example, a 1 denotes a received, 0 a lost, and X a discarded packet in the following pattern covering 64 packets: 11110111111111111111111X111X1011110111111111111111111X111111111 |---------gap----------|--burst---|------------gap------------| The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report. If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04. This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated): loss density 12, which corresponds to 5% discard density 12, which corresponds to 5% burst density 84, which corresponds to 33% gap density 10, which corresponds to 4% burst duration 120, value in milliseconds gap duration 520, value in milliseconds burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point Friedman, Caceres, and Clark, eds. [Page 24] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero. gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet is replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero. 4.7.3 Delay Metrics Friedman, Caceres, and Clark, eds. [Page 25] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered to be part of the voice application or end-system delay whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements. round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (sender report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is REQUIRED in order to calculate round trip delay. A value of 0 is permissible during the first two or three RTCP exchanges as insufficient data may be available to determine delay however MUST be populated as soon as a delay estimate is available. end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the total encoding, decoding and jitter buffer delay determined at the reporting endpoint. This is the time required for an RTP frame to be buffered, decoded, converted to analog form, looped back at the local analog interface, encoded, and made available for transmission as an RTP frame. The manner in which this value is estimated is implementation dependent. This parameter MUST be provided in all VoIP metrics reports. Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays as follows. If the round trip delay is denoted RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay =3D ( RTD + ESD(A) + ESD(B) ) / 2 4.7.4 Signal Related Metrics The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio signal. The information required to populate these fields may not be Friedman, Caceres, and Clark, eds. [Page 26] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis. signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. signal level =3D 10 log 10 ( rms talkspurt power (mW) ) A value of 127 indicates that this parameter is unavailable. Typical values should be generally in the -15 to -20 dBm range. noise level: 8 bits The noise level is defined as the ratio of the silent period background noise level to a reference digital milliwatt, expressed in decibels as a signed integer in two's complement form. noise level =3D 10 log10 ( rms silence power (mW) ) A value of 127 indicates that this parameter is unavailable. residual echo return loss (RERL): 8 bits The residual echo return loss is defined as the sum of the measured echo return loss (ERL) and the echo return loss enhancement (ERLE) expressed in dB as a signed integer in two's complement form. It defines the ratio of a transmitted voice signal that is reflected back to the talker. A low level of echo return loss (say less than 20 dB) in conjunction with some delay can lead to hollowness or audible echo. A high level of echo return loss (say over 40 dB) is preferable. The ERL and ERLE parameters are often available directly from the echo canceler contained within the VoIP end system. They relate to the echo on the external network attached to the end point. In the case of a VoIP gateway this would be line echo that typically occurs at 2-4 wire conversion points in the network. Echo return loss from typical 2-4 wire conversions can be in the 8-12 dB range. A line echo canceler can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone this could be residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset Friedman, Caceres, and Clark, eds. [Page 27] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 would result in 40-50 dB of echo due to acoustic feedback. Typical values for RERL are as follows: (i) IP gateway connected to circuit switched network with 2 wire loop Without echo cancellation, typical 2-4 wire converter ERL of 12 dB RERL =3D ERL + ERLE =3D 12 + 0 =3D 12 dB (ii) IP gateway connected to circuit switched network with 2 wire loop With echo canceler that improves echo by 30 dB RERL =3D ERL + ERLE =3D 12 + 30 =3D 42 dB (iii) IP phone with conventional handset Acoustic coupling from handset speaker to microphone 40 dB Residual echo return loss =3D TCL =3D 40 dB If we denote the "local" end of the VoIP path as A and the remote end as B and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by: TELR(A) =3D SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(B) =3D SRL(B) + ERL(A) + ERLE(A) + RLR(B) Hence in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection it is desirable to send the ERL + ERLE value from B to A. For an IP phone with handset this metric MUST be set to the designed or measured terminal coupling loss, which would typically be 40-50 dB. For a PC softphone or speakerphone this metric MUST be set to either the value reported by the acoustic echo canceler or to 127 to indicate an undefined value. For an IP gateway with ERL and ERLE measurements this metric MUST be reported as ERL + ERLE. For an IP gateway without ERL and ERLE measurement capability then this metric MUST be reported as 12 dB if line echo cancellation is disabled and 40 dB if line echo cancellation is enabled. Gmin See Configuration Parameters (Section 4.7.6, below). Friedman, Caceres, and Clark, eds. [Page 28] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 4.7.5 Call Quality or Transmission Quality Metrics The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of codec type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems however SHOULD be provided in order to support problem diagnosis. R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 [2]. A value of 127 indicates that this parameter is unavailable. ext. R factor: 8 bits The external R factor is a voice quality metric describing the segment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [4] and ETSI TS 101 329-5 [2], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies. A value of 127 indicates that this parameter is unavailable. Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows: R total =3D RTP R factor + ext. R factor - 94 MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5. A value of 127 indicates that this parameter is unavailable. Friedman, Caceres, and Clark, eds. [Page 29] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [4] or ETSI TS 101 329-5 [2] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ. A value of 127 indicates that this parameter is unavailable. 4.7.6 Configuration Parameters Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or discard occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as being part of a burst or gap in later reports. ETSI TS 101 329-5 [2] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero and MUST be provided. receiver configuration byte (RX config): 8 bits This byte consists of the following fields: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PLC|JBA|JB rate| +-+-+-+-+-+-+-+-+ packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC =3D 11 then a simple replay or interpolation algorithm is being used to fill-in the missing packet. This is typically able to conceal isolated lost packets with loss rates under 3%. When PLC =3D 10 then an enhanced interpolation algorithm is being used. This would Friedman, Caceres, and Clark, eds. [Page 30] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 typically be able to conceal lost packets for loss rates of 10% or more. When PLC =3D 01 then silence is inserted in place of lost packets. When PLC =3D 00 then no information is available concerning the use of PLC however for some codecs this may be inferred. jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non- adaptive modes are specified then the jitter buffer size parameters below MUST be specified. jitter buffer rate (JB rate): 4 bits J =3D adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that: adjustment time =3D 2 * J * frame size (ms) This parameter is intended only to provide a guide to the degree of "aggressiveness" of a an adaptive jitter buffer and may be estimated. A value of 0 indicates that the adjustment time is unknown for this implementation. 4.7.7 Jitter Buffer Parameters jitter buffer nominal size in frames (JB nominal): 8 bits This is the current nominal fill point within the jitter buffer, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer maximum size in frames (JB maximum): 8 bits This is the current maximum jitter buffer level corresponding to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal size. In adaptive jitter buffer implementations this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer absolute maximum size in frames (JB abs max): 8 bits This is the absolute maximum size that the adaptive jitter Friedman, Caceres, and Clark, eds. [Page 31] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 buffer can reach under worst case jitter conditions. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations. 5. IANA Considerations This document defines a new RTP packet type, the extended report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. 5.1 XR Packet Type The IANA SHALL register the RTP extended report (XR) packet defined by this document as packet type 207 in the registry of RTP RTCP Control Packet types (PT). 5.2 RTP XR Block Type Registry The IANA SHALL create the RTP XR Block Type Registry to cover the name space of the extended report block type (BT) field specified in Section 3 of this document. The BT field contains eight bits, allowing 256 values. The IANA SHALL manage the RTP XR Block Type Registry according to the Specification Required policy of RFC 2434 [6]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Timestamp Report Block 4 Statistics Summary Report Block 5 Receiver Timestamp Report Block 6 DLRR Report Block 7 VoIP Metrics Report Block Furthermore, future specifications SHOULD avoid the values 0 and 255. Doing so facilitates packet validity checking, since all-zeros and all-ones are values that might commonly be found in ill-formed packets. Friedman, Caceres, and Clark, eds. [Page 32] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 6. Security Considerations This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports also apply to XR reports. This section details the additional security considerations that apply to the extensions. The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per- packet information contained in Loss RLE, Duplicate RLE, and Timestamp Report Blocks facilitates MINC inference of multicast distribution trees for RTP data packets, and inference of link characteristics such as loss and delay. This inference reveals information that might otherwise be considered confidential to autonomous system administrators. The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. No new mechanisms are introduced in this document to ensure confidentiality. Standard encryption procedures can be used when confidentiality is a concern to end hosts. Autonomous system administrators concerned about the loss of confidentiality regarding their networks can encrypt traffic, or filter it to exclude RTCP packets containing the XR report blocks concerned. Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets SHOULD NOT be encrypted or filtered. The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD limit the size of XR report blocks and employ the Friedman, Caceres, and Clark, eds. [Page 33] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 thinning techniques described in this document in order to fit reports into the space available. A. Algorithms A.1 Sequence Number Interpretation This the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks. This algorithm keeps track of 16 bit sequence numbers by translating them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number). // The reference sequence number is an extended sequence number // that serves as the basis for determining whether a new 16 bit // sequence number comes earlier or later in the 32 bit sequence // space. u_int32 _src_ref_seq; bool _uninitialized_src_ref_seq; // Place seq into a 32-bit sequence number space based upon a // heuristic for its most likely location. u_int32 extend_seq(const u_int16 seq) { u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; if(_uninitialized_src_ref_seq) { // This is the first sequence number received. Place // it in the middle of the extended sequence number // space. _src_ref_seq =3D seq | 0x80000000u; _uninitialized_src_ref_seq =3D false; extended_seq =3D _src_ref_seq; } else { // Prior sequence numbers have been received. // Propose two candidates for the extended sequence // number: seq_a is without wraparound, seq_b with // wraparound. seq_a =3D seq | (_src_ref_seq & 0xFFFF0000u); if(_src_ref_seq < seq_a) { Friedman, Caceres, and Clark, eds. [Page 34] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 seq_b =3D seq_a - 0x00010000u; diff_a =3D seq_a - _src_ref_seq; diff_b =3D _src_ref_seq - seq_b; } else { seq_b =3D seq_a + 0x00010000u; diff_a =3D _src_ref_seq - seq_a; diff_b =3D seq_b - _src_ref_seq; } // Choose the closer candidate. If they are equally // close, the choice is somewhat arbitrary: we choose // the candidate for which no rollover is necessary. if(diff_a < diff_b) { extended_seq =3D seq_a; } else { extended_seq =3D seq_b; } // Set the reference sequence number to be this most // recently-received sequence number. _src_ref_seq =3D extended_seq; } // Return our best guess for a 32-bit sequence number that // corresponds to the 16-bit number we were given. return extended_seq; } A.2 Example Burst Packet Loss Calculation. This is an algorithm for measuring the burst characteristics for the VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI TS 101 329-5 [2]. The algorithm is event driven and hence extremely computationally efficient. Given the following definition of states: state 1 =3D received a packet during a gap state 2 =3D received a packet during a burst state 3 =3D lost a packet during a burst state 4 =3D lost an isolated packet during a gap The "c" variables below correspond to state transition counts, i.e. c14 is the transition from state 1 to state 4. It is possible to Friedman, Caceres, and Clark, eds. [Page 35] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application. "pkt" is the count of packets received since the last packet was declared lost or discarded and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are Boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet. if(packet_lost) { loss_count++; } if(packet_discarded) { discard_count++; } if(!packet_lost && !packet_discarded) { pkt++; } else { if(pkt >=3D gmin) { if(lost =3D=3D 1) { c14++; } else { c13++; } lost =3D 1; c11 +=3D pkt; } else { lost++; if(pkt =3D=3D 0) { c33++; } else { c23++; c22 +=3D (pkt - 1); } } pkt =3D 0; } At each reporting interval the burst and gap metrics can be calculated as follows. // Calculate additional transition counts. c31 =3D c13; c32 =3D c23; Friedman, Caceres, and Clark, eds. [Page 36] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 ctotal =3D c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; // Calculate burst and densities. p32 =3D c32 / (c31 + c32 + c33); if((c22 + c23) < 1) { p23 =3D 1; } else { p23 =3D 1 - c22/(c22 + c23); } burst_density =3D 256 * p23 / (p23 + p32); gap_density =3D 256 * c14 / (c11 + c14); // Calculate burst and gap durations in ms m =3D frameDuration_in_ms * framesPerRTPPkt; gap_length =3D (c11 + c14 + c13) * m / c13; burst_length =3D ctotal * m / c13 - lgap; /* calculate loss and discard densities */ loss_density =3D 256 * loss_count / ctotal; discard_density =3D 256 * discard_count / ctotal; Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [3]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. Friedman, Caceres, and Clark, eds. [Page 37] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgments We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Magnus Westerlund for his detailed comments; Mounir Benzaid for drawing our attention to the reporting needs of MLDA; and Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types. Contributors The following people are the authors of this document: Kevin Almeroth, UCSB Ramon Caceres, ShieldIP Alan Clark, Telchemy Robert Cole, AT&T Labs Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas The principal people to contact regarding the individual report blocks described in this document are as follows: Friedman, Caceres, and Clark, eds. [Page 38] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 sec. report block principal contributors ---- ------------ ---------------------- 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.3 Timestamp Report Block Friedman, Caceres, Duffield 4.4 Statistics Summary Report Block Almeroth, Sarac 4.5 Receiver Timestamp Report Block Friedman 4.6 DLRR Report Block Friedman 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat Authors' Addresses Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA Ramon Caceres ShieldIP, Inc. 11 West 42nd Street, 31st Floor New York, NY 10036 USA Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA Tel: +1 770 614 6944 Fax: +1 770 614 3951 Robert Cole AT&T Labs 330 Saint Johns Street, 2nd Floor Havre de Grace, MD 21078 USA Tel: +1 410 939 8732 Fax: +1 410 939 8732 Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA Tel: +1 973 360 8726 Fax: +1 973 360 8050 Friedman, Caceres, and Clark, eds. [Page 39] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France Tel: +33 1 44 27 71 06 Fax: +33 1 44 27 74 95 Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA Tel: +1 978 367 5600 Fax: +1 978 367 5700 Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA Tel: +1 972 883 2337 Fax: +1 972 883 2349 References The references are divided into normative references and non- normative references. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000. [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," best current practice BCP 11, RFC 2028, IETF, October 1996. [4] ITU-T, "The E-Model, a computational model for use in transmission planning," Recommendation G.107 (05/00), May 2000. [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, RFC 1700, IETF, October 1994. [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," best current practice BCP 26, RFC Friedman, Caceres, and Clark, eds. [Page 40] =0C draft-ietf-avt-rtcp-report-extns-03.txt 2 March 2003 2434, IETF, October 1998. [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. Non-Normative References [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior," IEEE Communications Magazine, May 2000. [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu measurement infrastructures using RTP," Proc. IEEE Infocom 2002. [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2001. [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000. Friedman, Caceres, and Clark, eds. [Page 41] =0C --------------Boundary-00=_WD65OVMBFJDCRLLQ6Y7F-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 3 05:53:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16491 for ; Mon, 3 Mar 2003 05:53:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23B3KL04003 for avt-archive@odin.ietf.org; Mon, 3 Mar 2003 06:03:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23B2qp03975; Mon, 3 Mar 2003 06:02:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23B1gp03942 for ; Mon, 3 Mar 2003 06:01:42 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16428 for ; Mon, 3 Mar 2003 05:51:16 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HB600HLZ66PBM@panasonic.de> for avt@ietf.org; Mon, 3 Mar 2003 11:52:02 +0100 (MET) Date: Mon, 03 Mar 2003 11:52:02 +0100 From: Jose Rey To: "Avt@Ietf. Org" Cc: "Akihiro@Isl. Mei. Co. Jp" , Carsten Burmeister , Rolf Hakenberg , Colin Perkins , "Casner@Acm. Org" , "Fukunaga444@Oki. Com" , Noriyuki Sato , Joerg Ott Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [AVT] draft-ietf-avt-rtcp-feedback-sim-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 [ Mail was delivered through VPN PEL->MEI/AVCDC! ] Hi all, I just submitted the newest revision of the AVPF timing rules simulations draft. This document shall be regarded as a companion document to AVPF (currently draft-ietf-avt-rtcp-feedback-05.txt). Until publication, the draft can be reached under: http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtcp-feedback-sim-0 1.txt Thanks, Jose Rey Mobile Multimedia Team - MCOM Group Panasonic European Laboratories GmbH Langen, Germany - rey@panasonic.de www.pel.panasonic.de - Tel: +49(0)6103-766-134 Fax: +49(0)6103-766-166 -- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 3 07:11:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19407 for ; Mon, 3 Mar 2003 07:11:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23CLs410829 for avt-archive@odin.ietf.org; Mon, 3 Mar 2003 07:21:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23CLYp10798; Mon, 3 Mar 2003 07:21:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23CKap10747 for ; Mon, 3 Mar 2003 07:20:36 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19303 for ; Mon, 3 Mar 2003 07:10:08 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h23CC86N011462; Mon, 3 Mar 2003 04:12:08 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (che-vpn-cluster-2-13.cisco.com [10.86.242.13]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABX53907; Mon, 3 Mar 2003 04:12:07 -0800 (PST) Message-Id: <4.3.2.7.2.20030303070518.016590e0@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Mar 2003 07:12:05 -0500 To: avt@ietf.org From: "Michael A. Ramalho" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Updated RGL Codec 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: , Dear all, Updated RGL codec and RGL RTP Payload format drafts will soon be available via the internet-drafts directory. Until they appear there, you may view them at the following URLs. http://www.winlab.rutgers.edu/~ramalho/rgl_codec_01.txt http://www.winlab.rutgers.edu/~ramalho/rgl_codec_01.html http://www.winlab.rutgers.edu/~ramalho/rgl_rtp_01.txt http://www.winlab.rutgers.edu/~ramalho/rgl_rtp_01.html Comments and feedback welcomed. See you in San Francisco, Michael Ramalho Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 3 09:37:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26972 for ; Mon, 3 Mar 2003 09:37:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23ElEt22326 for avt-archive@odin.ietf.org; Mon, 3 Mar 2003 09:47:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Ekbp22283; Mon, 3 Mar 2003 09:46:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Ejrp22224 for ; Mon, 3 Mar 2003 09:45:53 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26906 for ; Mon, 3 Mar 2003 09:35:20 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h23EbDRT056295; Mon, 3 Mar 2003 09:37:13 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200303031437.h23EbDRT056295@purple.nge.isi.edu> To: Jose Rey cc: "Avt@Ietf. Org" , "Akihiro@Isl. Mei. Co. Jp" , Carsten Burmeister , Rolf Hakenberg , "Casner@Acm. Org" , "Fukunaga444@Oki. Com" , Noriyuki Sato , Joerg Ott In-Reply-To: Your message of "Mon, 03 Mar 2003 11:52:02 +0100." Date: Mon, 03 Mar 2003 09:37:13 -0500 From: Colin Perkins Subject: [AVT] Re: draft-ietf-avt-rtcp-feedback-sim-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: , Thanks. Is there a need to discuss AVPF at the meeting, or should we just consider the last call? Colin --> Jose Rey writes: >[ Mail was delivered through VPN PEL->MEI/AVCDC! ] > >Hi all, > >I just submitted the newest revision of the AVPF timing rules >simulations draft. This document shall be regarded as a companion >document to AVPF (currently draft-ietf-avt-rtcp-feedback-05.txt). > >Until publication, the draft can be reached under: > >http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtcp-feedback-sim-0 >1.txt > >Thanks, > > >Jose Rey >Mobile Multimedia Team - MCOM Group >Panasonic European Laboratories GmbH >Langen, Germany >- >rey@panasonic.de >www.pel.panasonic.de >- >Tel: +49(0)6103-766-134 >Fax: +49(0)6103-766-166 >-- > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 3 10:02:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27916 for ; Mon, 3 Mar 2003 10:02:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23FCWA24709 for avt-archive@odin.ietf.org; Mon, 3 Mar 2003 10:12:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FCEp24690; Mon, 3 Mar 2003 10:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23FBQp24628 for ; Mon, 3 Mar 2003 10:11:26 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27849 for ; Mon, 3 Mar 2003 10:00:52 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HB600IT6HQRXY@panasonic.de> for avt@ietf.org; Mon, 3 Mar 2003 16:01:40 +0100 (MET) Date: Mon, 03 Mar 2003 16:01:41 +0100 From: Jose Rey Subject: RE: [AVT] Re: draft-ietf-avt-rtcp-feedback-sim-01.txt In-reply-to: <200303031437.h23EbDRT056295@purple.nge.isi.edu> To: Colin Perkins Cc: "Avt@Ietf. Org" , "Akihiro@Isl. Mei. Co. Jp" , Carsten Burmeister , Rolf Hakenberg , "Casner@Acm. Org" , "Fukunaga444@Oki. Com" , Noriyuki Sato , Joerg Ott Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 [ Mail was delivered through VPN PEL->MEI/AVCDC! ] I think both drafts are ready for last call. José > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin > Perkins > Sent: Monday, March 03, 2003 3:37 PM > To: Jose Rey > Cc: Avt@Ietf. Org; Akihiro@Isl. Mei. Co. Jp; Carsten Burmeister; Rolf > Hakenberg; Casner@Acm. Org; Fukunaga444@Oki. Com; Noriyuki Sato; Joerg > Ott > Subject: [AVT] Re: draft-ietf-avt-rtcp-feedback-sim-01.txt > > > Thanks. Is there a need to discuss AVPF at the meeting, or > should we just > consider the last call? > > Colin > > > > --> Jose Rey writes: > >[ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > >Hi all, > > > >I just submitted the newest revision of the AVPF timing rules > >simulations draft. This document shall be regarded as a companion > >document to AVPF (currently draft-ietf-avt-rtcp-feedback-05.txt). > > > >Until publication, the draft can be reached under: > > > >http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtcp-fee > dback-sim-0 > >1.txt > > > >Thanks, > > > > > >Jose Rey > >Mobile Multimedia Team - MCOM Group > >Panasonic European Laboratories GmbH > >Langen, Germany > >- > >rey@panasonic.de > >www.pel.panasonic.de > >- > >Tel: +49(0)6103-766-134 > >Fax: +49(0)6103-766-166 > >-- > > > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Mar 3 18:01:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16507 for ; Mon, 3 Mar 2003 18:01:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23NC7P03512 for avt-archive@odin.ietf.org; Mon, 3 Mar 2003 18:12:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23NBcp03450; Mon, 3 Mar 2003 18:11:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23N7jp03307 for ; Mon, 3 Mar 2003 18:07:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16300; Mon, 3 Mar 2003 17:56:59 -0500 (EST) Message-Id: <200303032256.RAA16300@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , avt@ietf.org From: The IESG Date: Mon, 03 Mar 2003 17:56:59 -0500 Subject: [AVT] REVISED: Protocol Action: RTP Payload Format for ETSI ES 201 108 Distributed Speech Recognition Encoding 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 the Internet-Draft 'RTP Payload Format for ETSI ES 201 108 Distributed Speech Recognition Encoding' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document specifies an RTP payload format for encapsulating ETSI Standard ES 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. The use of RTP enables the distributed systems scenarios to be broader. The payload consists of concatenated Frame Pairs (FP) of the ETSI-defined inputs, and guidance is provided on the size and timing issues of placing the voice recognition signals in the RTP payloads. Besides defining the payload, the document specifies and registers the MIME subtype audio/dsr-es201108. Working Group Summary The Audio-Video Transport Working Group supported advancement of this specification. In addition, there has been coordination with respect to the Speech Services Control Working Group. Protocol Quality The protocol was reviewed for the IESG by Allison Mankin. RFC Editor Note: RFC Editor, please add after the References a section titled "Copyright Notice," containing RFC 2026, Section 10.4 (C), followed by a section titled "IPR Notices", containing RFC 2026, Sections 10.4 (A) and 10.4(B) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 07:31:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15123 for ; Tue, 4 Mar 2003 07:31:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24CfTD32048 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 07:41:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cf6p32034; Tue, 4 Mar 2003 07:41:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cbjp31844 for ; Tue, 4 Mar 2003 07:37:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14182; Tue, 4 Mar 2003 07:26:47 -0500 (EST) Message-Id: <200303041226.HAA14182@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: Tue, 04 Mar 2003 07:26:47 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-crtp-enhance-07.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 : Enhanced Compressed RTP (CRTP) for links with high delay,packet loss and reordering Author(s) : T. Koren, S. Casner et al. Filename : draft-ietf-avt-crtp-enhance-07.txt Pages : 0 Date : 2003-3-3 This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-07.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-crtp-enhance-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-crtp-enhance-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-3144444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-crtp-enhance-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-crtp-enhance-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144444.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 11:03:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28520 for ; Tue, 4 Mar 2003 11:03:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GDr316582 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 11:13:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GDVp16549; Tue, 4 Mar 2003 11:13:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GAQp16416 for ; Tue, 4 Mar 2003 11:10:26 -0500 Received: from mail.utstar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28309 for ; Tue, 4 Mar 2003 10:59:23 -0500 (EST) Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h24G1dp17307 for ; Tue, 4 Mar 2003 11:01:40 -0500 (EST) Reply-To: From: "Balasubramanian Pitchandi" To: Date: Tue, 4 Mar 2003 11:01:50 -0500 Organization: UTStarcom Inc Message-ID: <003501c2e267$5ecda700$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C2E23D.75F79F00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [AVT] Status of draft-ietf-avt-profile-new-12.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_000_0036_01C2E23D.75F79F00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, The AVT Profile draft draft-ietf-avt-profile-new-12.txt has expired on May 2002. Is there a plan to come out with a new draft replacing this? Thanks, Bala ______________________ Bala Pitchandi UTStarcom Inc. ------=_NextPart_000_0036_01C2E23D.75F79F00 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello,

 

The AVT Profile draft = draft-ietf-avt-profile-new-12.txt has expired on May 2002. Is there a plan to come out with a new draft = replacing this?

 

Thanks,

Bala

______________________

Bala Pitchandi

UTStarcom = Inc.

------=_NextPart_000_0036_01C2E23D.75F79F00-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 11:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28832 for ; Tue, 4 Mar 2003 11:11:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GLY017122 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 11:21:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GL7p17103; Tue, 4 Mar 2003 11:21:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GIZp16954 for ; Tue, 4 Mar 2003 11:18:35 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28741 for ; Tue, 4 Mar 2003 11:07:31 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by alaska.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h24G9V0i027691; Tue, 4 Mar 2003 17:09:31 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XHL9KW; Tue, 4 Mar 2003 17:09:30 +0100 Message-ID: <3E64CFBB.2040009@era.ericsson.se> Date: Tue, 04 Mar 2003 17:09:31 +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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bs@utstar.com CC: avt@ietf.org Subject: Re: [AVT] Status of draft-ietf-avt-profile-new-12.txt References: <003501c2e267$5ecda700$2b2810ac@balanew> 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, draft-ietf-avt-profile-new-12.txt is not expired as it is tentatively approved by IESG. It awaits a few small clarifications on draft-ietf-avt-rtp-new-11.txt. When these are performed the both of them will go to publication, if IESG approves these changes. Cheers Magnus Balasubramanian Pitchandi wrote: > Hello, > > > > The AVT Profile draft draft-ietf-avt-profile-new-12.txt has expired on > May 2002. Is there a plan to come out with a new draft replacing this? > > > > Thanks, > > Bala > > ______________________ > > Bala Pitchandi > > UTStarcom Inc. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 11:13:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28910 for ; Tue, 4 Mar 2003 11:13:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GOWC17273 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 11:24:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GO3p17229; Tue, 4 Mar 2003 11:24:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h245Elp24725 for ; Tue, 4 Mar 2003 00:14:47 -0500 Received: from kansai.kansai.oki.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24073 for ; Tue, 4 Mar 2003 00:03:55 -0500 (EST) Received: from DOTEYAKI (localhost [127.0.0.1]) by kansai.kansai.oki.co.jp (8.12.6/8.12.6) with SMTP id h2455jsk058456; Tue, 4 Mar 2003 14:05:46 +0900 (JST) (envelope-from sato652@oki.com) Reply-To: From: "Noriyuki SATO" To: "Jose Rey" , "Colin Perkins" Cc: "Avt@Ietf. Org" , "Akihiro@Isl. Mei. Co. Jp" , "Carsten Burmeister" , "Rolf Hakenberg" , "Casner@Acm. Org" , "Fukunaga444@Oki. Com" , "Noriyuki Sato" , "Joerg Ott" Subject: RE: [AVT] Re: draft-ietf-avt-rtcp-feedback-sim-01.txt Date: Tue, 4 Mar 2003 14:04:31 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: Importance: Normal 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 Dear Colin, I agree with Jose. It would be appreciated if you would start the procedure of WGLC. Best regards, Noriyuki Sato > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Jose Rey > Sent: Tuesday, March 04, 2003 12:02 AM > To: Colin Perkins > Cc: Avt@Ietf. Org; Akihiro@Isl. Mei. Co. Jp; Carsten Burmeister; Rolf Hakenberg; Casner@Acm. Org; Fukunaga444@Oki. Com; > Noriyuki Sato; Joerg Ott > Subject: RE: [AVT] Re: draft-ietf-avt-rtcp-feedback-sim-01.txt > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > José > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin > > Perkins > > Sent: Monday, March 03, 2003 3:37 PM > > To: Jose Rey > > Cc: Avt@Ietf. Org; Akihiro@Isl. Mei. Co. Jp; Carsten Burmeister; Rolf > > Hakenberg; Casner@Acm. Org; Fukunaga444@Oki. Com; Noriyuki Sato; Joerg > > Ott > > Subject: [AVT] Re: draft-ietf-avt-rtcp-feedback-sim-01.txt > > > > > > Thanks. Is there a need to discuss AVPF at the meeting, or > > should we just > > consider the last call? > > > > Colin > > > > > > > > --> Jose Rey writes: > > >[ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > > > >Hi all, > > > > > >I just submitted the newest revision of the AVPF timing rules > > >simulations draft. This document shall be regarded as a companion > > >document to AVPF (currently draft-ietf-avt-rtcp-feedback-05.txt). > > > > > >Until publication, the draft can be reached under: > > > > > >http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtcp-fee > > dback-sim-0 > > >1.txt > > > > > >Thanks, > > > > > > > > >Jose Rey > > >Mobile Multimedia Team - MCOM Group > > >Panasonic European Laboratories GmbH > > >Langen, Germany > > >- > > >rey@panasonic.de > > >www.pel.panasonic.de > > >- > > >Tel: +49(0)6103-766-134 > > >Fax: +49(0)6103-766-166 > > >-- > > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Tue Mar 4 11:16:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28976 for ; Tue, 4 Mar 2003 11:16:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GQbD17348 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 11:26:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GQ6p17323; Tue, 4 Mar 2003 11:26:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GF3p16752 for ; Tue, 4 Mar 2003 11:15:03 -0500 Received: from wisbech.cl.cam.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28585 for ; Tue, 4 Mar 2003 11:03:59 -0500 (EST) Received: from annan.cl.cam.ac.uk ([128.232.8.178] helo=cl.cam.ac.uk ident=[/LUXk+aM18s7jrKpaVRYn7krR0HdgyV4]) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 18qEva-0006Qh-00; Tue, 04 Mar 2003 16:06:02 +0000 X-Mailer: exmh version 2.5+CL 07/13/2001 with nmh-1.0.4 To: avt@ietf.org cc: jo@Informatik.Uni-Bremen.DE, schooler@research.att.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Mar 2003 16:06:02 +0000 From: Julian Chesterfield Message-Id: Subject: [AVT] New version of draft-ietf-avt-rtcpssm-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: , An updated version of draft-ietf-avt-rtcpssm was submitted on monday. While it is in the draft submission queue, you can download a copy from: http://irg.attlabs.net/rtcp_ssm/draft-ietf-avt-rtcpssm-03.txt Main features of the latest draft: - Packet formats aligned with the Reporting Extensions draft. - More concise rules for application of reflection vs summarisation and SDP syntax for initial signalling of parameters. - IANA considerations - Example applicability of security requirements to RTSP and SIP sessions. We've requested a slot to discuss progress with the working group in San Francisco. Thanks, Julian Chesterfield _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 11:45:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00130 for ; Tue, 4 Mar 2003 11:45:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GuFi19874 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 11:56:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GtWp19672; Tue, 4 Mar 2003 11:55:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Gldp19124 for ; Tue, 4 Mar 2003 11:47:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29684; Tue, 4 Mar 2003 11:36:35 -0500 (EST) Message-Id: <200303041636.LAA29684@ietf.org> To: IETF-Announce: ; Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 04 Mar 2003 11:36:35 -0500 Subject: [AVT] Last Call: Enhanced Compressed RTP (CRTP) for links with high delay, packet loss and reordering 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 received a request from the Audio/Video Transport Working Group to consider Enhanced Compressed RTP (CRTP) for links with high delay, packet loss and reordering as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-3-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-07.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 13:56:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05433 for ; Tue, 4 Mar 2003 13:56:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24J7Wm04927 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 14:07:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24J71504177; Tue, 4 Mar 2003 14:07:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24J4t504055 for ; Tue, 4 Mar 2003 14:04:55 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05322 for ; Tue, 4 Mar 2003 13:53:48 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h24ItWvv069192; Tue, 4 Mar 2003 10:55:32 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 4 Mar 2003 10:55:32 -0800 (PST) From: Stephen Casner To: Magnus Westerlund cc: bs@utstar.com, Subject: Re: [AVT] Status of draft-ietf-avt-profile-new-12.txt In-Reply-To: <3E64CFBB.2040009@era.ericsson.se> Message-ID: <20030304103942.A23146-100000@ash.packetdesign.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 Tue, 4 Mar 2003, Magnus Westerlund wrote: > draft-ietf-avt-profile-new-12.txt is not expired as it is tentatively > approved by IESG. It awaits a few small clarifications on > draft-ietf-avt-rtp-new-11.txt. When these are performed the both of them > will go to publication, if IESG approves these changes. What Magnus says is true. But in addition, I have submitted updated drafts rtp-new-12 and profile-new-13 as the means to convey the clarifications to the IESG and the RFC Editor. I did this after receiving permission from our AD, Allison Mankin, since normally a draft should not be updated after it is reviewed and approved by the IESG. The clarifications we have discussed are substantial enough, especially when combined with the things I fixed to comply with the ID-nits requirements (like fixing two spaces at the end of sentences, and changing the order of some of the sections) that I decided trying to convey all of that to the RFC Editor in the form of edit notes to be applied to the previous drafts would not be efficient, effective, or pleasant. I am preparing a set of files for the IESG to explain the significant clarifications and to make it easy to verify that the other changes are insignificant. Having refreshed expiration dates should also help folks like Bala who have been concerned and asked about it. The new drafts will work their way through the I-D administrator's queue. In the meantime, you can get them at: ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.txt -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 15:06:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07954 for ; Tue, 4 Mar 2003 15:06:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24KGnF09832 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 15:16:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KFi509732; Tue, 4 Mar 2003 15:15:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24KE9509657 for ; Tue, 4 Mar 2003 15:14:09 -0500 Received: from mail.utstar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07565 for ; Tue, 4 Mar 2003 15:03:01 -0500 (EST) Received: from balanew ([172.16.40.43]) by mail.utstar.com (8.11.3/8.11.3) with ESMTP id h24K5Gp16972; Tue, 4 Mar 2003 15:05:17 -0500 (EST) Reply-To: From: "Balasubramanian Pitchandi" To: "'Stephen Casner'" , "'Magnus Westerlund'" Cc: Subject: RE: [AVT] Status of draft-ietf-avt-profile-new-12.txt Date: Tue, 4 Mar 2003 15:05:27 -0500 Organization: UTStarcom Inc Message-ID: <007501c2e289$6736d980$2b2810ac@balanew> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030304103942.A23146-100000@ash.packetdesign.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h24KE9509658 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 Thanks Magnus and Steve. Updating the expiration date and issuing a new draft would be the ideal solution that would help folks who may not be subscribing to this mailing list but use the document as a reference. -- Bala -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Stephen Casner Sent: Tuesday, March 04, 2003 1:56 PM To: Magnus Westerlund Cc: bs@utstar.com; avt@ietf.org Subject: Re: [AVT] Status of draft-ietf-avt-profile-new-12.txt On Tue, 4 Mar 2003, Magnus Westerlund wrote: > draft-ietf-avt-profile-new-12.txt is not expired as it is tentatively > approved by IESG. It awaits a few small clarifications on > draft-ietf-avt-rtp-new-11.txt. When these are performed the both of them > will go to publication, if IESG approves these changes. What Magnus says is true. But in addition, I have submitted updated drafts rtp-new-12 and profile-new-13 as the means to convey the clarifications to the IESG and the RFC Editor. I did this after receiving permission from our AD, Allison Mankin, since normally a draft should not be updated after it is reviewed and approved by the IESG. The clarifications we have discussed are substantial enough, especially when combined with the things I fixed to comply with the ID-nits requirements (like fixing two spaces at the end of sentences, and changing the order of some of the sections) that I decided trying to convey all of that to the RFC Editor in the form of edit notes to be applied to the previous drafts would not be efficient, effective, or pleasant. I am preparing a set of files for the IESG to explain the significant clarifications and to make it easy to verify that the other changes are insignificant. Having refreshed expiration dates should also help folks like Bala who have been concerned and asked about it. The new drafts will work their way through the I-D administrator's queue. In the meantime, you can get them at: ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.txt -- 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 mailnull@www1.ietf.org Tue Mar 4 16:03:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10399 for ; Tue, 4 Mar 2003 16:03:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24LEb714363 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 16:14:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24LE8514333; Tue, 4 Mar 2003 16:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24LDf514300 for ; Tue, 4 Mar 2003 16:13:41 -0500 Received: from c015.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10364 for ; Tue, 4 Mar 2003 16:02:31 -0500 (EST) Received: (cpmta 14956 invoked from network); 4 Mar 2003 13:04:11 -0800 Received: from 81.225.8.111 (HELO EmanuelMohr) by smtp.globalipsound.com (209.228.35.121) with SMTP; 4 Mar 2003 13:04:11 -0800 X-Sent: 4 Mar 2003 21:04:11 GMT Reply-To: From: "Alan Duric" To: "'Stephen Casner'" Cc: , Subject: RE: [AVT] Status of draft-ietf-avt-profile-new-12.txt Date: Tue, 4 Mar 2003 22:03:45 +0100 Message-ID: <000001c2e291$99793cf0$0802a8c0@EmanuelMohr> 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 Importance: Normal In-Reply-To: <20030304103942.A23146-100000@ash.packetdesign.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Steve, one further comment, in section 4.5.9: "4.5.9 GSM-EFR ... The packing is specified in ETSI Technical Specification TS 101 318." packing is referring to document that is made historical (since Dec-2001, see http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=5874), and I'm not sure how good practice is to use historical document as reference. Regards, Alan > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On > Behalf Of Stephen Casner > Sent: Tuesday, March 04, 2003 7:56 PM > To: Magnus Westerlund > Cc: bs@utstar.com; avt@ietf.org > Subject: Re: [AVT] Status of draft-ietf-avt-profile-new-12.txt > > > On Tue, 4 Mar 2003, Magnus Westerlund wrote: > > > draft-ietf-avt-profile-new-12.txt is not expired as it is > tentatively > > approved by IESG. It awaits a few small clarifications on > > draft-ietf-avt-rtp-new-11.txt. When these are performed the both of > > them will go to publication, if IESG approves these changes. > > What Magnus says is true. But in addition, I have submitted > updated drafts rtp-new-12 and profile-new-13 as the means to > convey the clarifications to the IESG and the RFC Editor. I > did this after receiving permission from our AD, Allison > Mankin, since normally a draft should not be updated after it > is reviewed and approved by the IESG. The clarifications we > have discussed are substantial enough, especially when > combined with the things I fixed to comply with the ID-nits > requirements (like fixing two spaces at the end of sentences, > and changing the order of some of the sections) that I > decided trying to convey all of that to the RFC Editor in the > form of edit notes to be applied to the previous drafts would > not be efficient, effective, or pleasant. I am preparing a > set of files for the IESG to explain the significant > clarifications and to make it easy to verify that the other > changes are insignificant. > > Having refreshed expiration dates should also help folks like > Bala who have been concerned and asked about it. > > The new drafts will work their way through the I-D > administrator's queue. In the meantime, you can get them at: > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13 .ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13 .txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.txt -- 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 mailnull@www1.ietf.org Tue Mar 4 16:04:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10450 for ; Tue, 4 Mar 2003 16:04:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24LFL214420 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 16:15:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24LF2514398; Tue, 4 Mar 2003 16:15:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24LEC514344 for ; Tue, 4 Mar 2003 16:14:12 -0500 Received: from c015.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10386 for ; Tue, 4 Mar 2003 16:03:02 -0500 (EST) Received: (cpmta 3432 invoked from network); 4 Mar 2003 13:05:03 -0800 Received: from 81.225.8.111 (HELO EmanuelMohr) by smtp.globalipsound.com (209.228.35.126) with SMTP; 4 Mar 2003 13:05:03 -0800 X-Sent: 4 Mar 2003 21:05:03 GMT Reply-To: From: "Alan Duric" To: "'Stephen Casner'" Cc: , Subject: RE: [AVT] Status of draft-ietf-avt-profile-new-12.txt Date: Tue, 4 Mar 2003 22:04:57 +0100 Message-ID: <000101c2e291$b8e9a390$0802a8c0@EmanuelMohr> 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 Importance: Normal In-Reply-To: <20030304103942.A23146-100000@ash.packetdesign.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 yHi Steve, one further comment, in section 4.5.9: "4.5.9 GSM-EFR ... The packing is specified in ETSI Technical Specification TS 101 318." packing is referring to document that is made historical (since Dec-2001, see http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=5874), and I'm not sure how good practice is to use historical document as reference. Regards, Alan > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On > Behalf Of Stephen Casner > Sent: Tuesday, March 04, 2003 7:56 PM > To: Magnus Westerlund > Cc: bs@utstar.com; avt@ietf.org > Subject: Re: [AVT] Status of draft-ietf-avt-profile-new-12.txt > > > On Tue, 4 Mar 2003, Magnus Westerlund wrote: > > > draft-ietf-avt-profile-new-12.txt is not expired as it is > tentatively > > approved by IESG. It awaits a few small clarifications on > > draft-ietf-avt-rtp-new-11.txt. When these are performed the both of > > them will go to publication, if IESG approves these changes. > > What Magnus says is true. But in addition, I have submitted > updated drafts rtp-new-12 and profile-new-13 as the means to > convey the clarifications to the IESG and the RFC Editor. I > did this after receiving permission from our AD, Allison > Mankin, since normally a draft should not be updated after it > is reviewed and approved by the IESG. The clarifications we > have discussed are substantial enough, especially when > combined with the things I fixed to comply with the ID-nits > requirements (like fixing two spaces at the end of sentences, > and changing the order of some of the sections) that I > decided trying to convey all of that to the RFC Editor in the > form of edit notes to be applied to the previous drafts would > not be efficient, effective, or pleasant. I am preparing a > set of files for the IESG to explain the significant > clarifications and to make it easy to verify that the other > changes are insignificant. > > Having refreshed expiration dates should also help folks like > Bala who have been concerned and asked about it. > > The new drafts will work their way through the I-D > administrator's queue. In the meantime, you can get them at: > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13 .ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-13 .txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-12.txt -- 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 mailnull@www1.ietf.org Tue Mar 4 17:24:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12589 for ; Tue, 4 Mar 2003 17:24:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24MYnW19417 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 17:34:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24MYG519396; Tue, 4 Mar 2003 17:34:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24MWR519351 for ; Tue, 4 Mar 2003 17:32:27 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12518 for ; Tue, 4 Mar 2003 17:21:16 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.6/8.12.3) with ESMTP id h24MN8vv077761; Tue, 4 Mar 2003 14:23:08 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 4 Mar 2003 14:23:08 -0800 (PST) From: Stephen Casner To: Alan Duric cc: AVT WG Subject: RE: [AVT] Status of draft-ietf-avt-profile-new-12.txt In-Reply-To: <000001c2e291$99793cf0$0802a8c0@EmanuelMohr> Message-ID: <20030304142118.M23146-100000@ash.packetdesign.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: , Alan, > "4.5.9 GSM-EFR > > ... The packing is specified in ETSI Technical Specification TS 101 > 318." > > packing is referring to document that is made historical (since > Dec-2001, see > http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=5874), and > I'm not sure how good practice is to use historical document as > reference. Does that mean GSM-EFR encoding is also historic? Or just the packing? -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 18:05:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13978 for ; Tue, 4 Mar 2003 18:05:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24NFmW22590 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 18:15:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NFI522575; Tue, 4 Mar 2003 18:15:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24NEm522543 for ; Tue, 4 Mar 2003 18:14:48 -0500 Received: from c015.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13827 for ; Tue, 4 Mar 2003 18:03:36 -0500 (EST) Received: (cpmta 24943 invoked from network); 4 Mar 2003 15:05:38 -0800 Received: from 81.225.8.33 (HELO EmanuelMohr) by smtp.globalipsound.com (209.228.35.126) with SMTP; 4 Mar 2003 15:05:38 -0800 X-Sent: 4 Mar 2003 23:05:38 GMT Reply-To: From: "Alan Duric" To: "'Stephen Casner'" Cc: "'AVT WG'" Subject: RE: [AVT] Status of draft-ietf-avt-profile-new-12.txt Date: Wed, 5 Mar 2003 00:05:34 +0100 Message-ID: <000201c2e2a2$90c78790$0802a8c0@EmanuelMohr> 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 Importance: Normal In-Reply-To: <20030304142118.M23146-100000@ash.packetdesign.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Steve, > Does that mean GSM-EFR encoding is also historic? Or just > the packing? ETSI Technical Specification TS 101 318 refers just to packing of GSM EFR (as well as for packing of GSM FR - 06.10 and GSM HR - 06.20). Possible "work around" could be if packing for GSM EFR is explained in a same way as packing for GSM FR in section 4.5.8 Regards, Alan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 19:01:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16121 for ; Tue, 4 Mar 2003 19:01:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h250BlR26600 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 19:11:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250BS526579; Tue, 4 Mar 2003 19:11:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250AC526550 for ; Tue, 4 Mar 2003 19:10:12 -0500 Received: from smtp01.mrf.mail.rcn.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16065 for ; Tue, 4 Mar 2003 18:58:58 -0500 (EST) X-Info: This message was accepted for relay by smtp01.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVaVasEX2jLS2ygveB2Y4LLrVtVyuyR9hkk/lAFj/tsqpLcpdOk6FhuM Received: from sense-sea-focal-dynamic-9-1.oz.net ([216.39.143.1] helo=erols.com) by smtp01.mrf.mail.rcn.net with asmtp (Exim 3.35 #4) id 18qMLE-0007Uc-00 for avt@ietf.org; Tue, 04 Mar 2003 19:01:01 -0500 Message-ID: <3E653DE2.DB32572C@erols.com> Date: Tue, 04 Mar 2003 15:59:30 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "'AVT WG'" References: <000201c2e2a2$90c78790$0802a8c0@EmanuelMohr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Gibson Magic over RTP? 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, Does anyone know of a plan to map Gibson Magic, which is a layer-2 Ethernet audio/video LAN protocol, into RTP for extension into the WAN environment? http://www.gibsonmagic.com/specification.html Cheers, Chuck Harrison Far Field Associates, LLC _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 19:59:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17547 for ; Tue, 4 Mar 2003 19:59:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2519o930509 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 20:09:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2519K530490; Tue, 4 Mar 2003 20:09:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2518d530460 for ; Tue, 4 Mar 2003 20:08:39 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17503 for ; Tue, 4 Mar 2003 19:57:25 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h250xR011387; Tue, 4 Mar 2003 19:59:27 -0500 Message-Id: <200303050059.h250xR011387@chiron.nge.isi.edu> To: avt@ietf.org cc: casner@acm.org Date: Tue, 04 Mar 2003 19:59:27 -0500 From: Colin Perkins Subject: [AVT] Agenda for San Francisco meeting 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: , Folks, Enclosed is the agenda for the AVT meeting in San Francisco. Please send any comments or corrections to the chairs. Those who have agenda time scheduled are requested to prepare a summary of the issues they wish to discuss, and to send this to the mailing list ahead of the meeting. This gives those who won't be attending the opportunity to post their comments and concerns, and potentially even reach some consensus, before the meeting time is consumed. It also gives other participants the opportunity to consider the issue in more depth. Summary messages SHOULD be sent to the mailing list by Monday 10th March. We also request that all presenters send us their slides ahead of time, preferably in PDF format. This has multiple purposes: - It streamlines the presentation process by having the presentations on a single laptop. - It avoids the delay that sometimes occurs in getting the presentations sent to us after the meeting, for inclusion in the minutes. - It allows us to preview the presentations to see if they are following the guidelines for what should be covered during the meeting. Presentations SHOULD be submitted before 12 noon EST (GMT -05:00) on Friday 14th March, so we can include them on the IETF website for online viewing during the session. Agenda time is conditional on sending both a summary of open issues and a copy of your slides ahead of the meeting, and 5 minutes ahead doesn't count! Those presenting new drafts: briefly describe the basic problem and your proposed solution, discuss known issues, limitations and problems, outline where you want input from the working group, and how you wish us to proceed. When presenting work which has been previously discussed: describe only the changes from the previous draft, highlight unresolved problems, and propose future directions. Presenters are reminded of the requirements for disclosure of intellectual property relating to contributions, in section 10 of RFC 2026. We strongly encourage all participants to read all relevent drafts before the meeting, and to comment on the open issues raised on the mailing list. Thanks for your assistance to try to conduct an effective meeting. Colin & Steve =============================================================================== Audio/Video Transport Working Group CHAIRS: Steve Casner Colin Perkins Wednesday, 19th March at 13:00-15:00 ==================================== Introduction and status update (Casner/Perkins) 15 draft-ietf-avt-rtp-new-12.txt draft-ietf-avt-profile-new-13.txt draft-ietf-avt-uxp-05.txt draft-ietf-avt-ulp-07.txt (Under revision) draft-ietf-avt-tcrtp-07.txt draft-ietf-avt-rtcp-feedback-05.txt draft-ietf-avt-rtcp-feedback-sim-01.txt draft-ietf-avt-crtp-enhance-07.txt (IETF last call) draft-ietf-avt-rtcp-bw-05.txt (RFC Editor) draft-ietf-avt-rtp-mime-06.txt (RFC Editor) draft-ietf-avt-dsr-05.txt (RFC Editor) draft-ietf-avt-evrc-smv-03.txt (RFC Editor) See also draft-garudadri-qcp-00.txt RFC 3497 The Secure Real-time Transport Protocol 15 draft-ietf-avt-srtp-05.txt Framing RTP over Connection-Oriented Transport (Lazzaro) 15 draft-lazzaro-avt-rtp-framing-contrans-00.txt RTP Extended Reports (RTP XR) (Friedman/Clark) 15 draft-ietf-avt-rtcp-report-extns-03.txt RTCP Extensions for SSM with unicast feedback (Chesterfield) 15 draft-ietf-avt-rtcpssm-03.txt RTP Payload Format for JVT Video (Wenger) 15 draft-ietf-avt-rtp-h264-01.txt RTP Payload Format for uncompressed video (Gharai) 15 draft-ietf-avt-uncomp-video-02.txt Thursday, 20th March at 09:00-11:30 =================================== RTP Payload Format for a 64 kbit/s transparent call (Kreuter) 15 draft-kreuter-avt-rtp-clearmode-01.txt See also the TDM emulation work in the PWE3 working group The MIDI Wire Protocol Packetization (MWPP) (Lazzaro) 15 draft-ietf-avt-mwpp-midi-rtp-06.txt draft-lazzaro-avt-mwpp-coding-guidelines-02.txt RTP Payload Format for ATRAC-X (Romaine) 15 draft-hatanaka-avt-rtp-atracx-01.txt RTP Payload Format for iLBC Speech (Duric) 15 draft-ietf-avt-rtp-ilbc-01.txt draft-ietf-avt-ilbc-codec-01.txt RTP Payload Format for the Speex Codec (Herlein) 15 draft-herlein-speex-rtp-profile-00.txt RTP Payload Format for RGL Codec (Ramalho) 15 draft-ramalho-rgl-desc-01.txt draft-ramalho-rgl-rtpformat-01.txt RTP Payload Format for ETSI ES 202 050 DSR (Xie) 15 draft-xie-avt-dsr-es202050-00.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 4 21:28:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19385 for ; Tue, 4 Mar 2003 21:28:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h252d8003678 for avt-archive@odin.ietf.org; Tue, 4 Mar 2003 21:39:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h252ce503635; Tue, 4 Mar 2003 21:38:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h252a8502805 for ; Tue, 4 Mar 2003 21:36:08 -0500 Received: from ns6.sony.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19290 for ; Tue, 4 Mar 2003 21:24:52 -0500 (EST) Received: from mail7.sony.co.jp (mail7.sony.co.jp [43.0.1.209]) by ns6.sony.co.jp (R8/Sony) with ESMTP id h252Qrs24186 for ; Wed, 5 Mar 2003 11:26:53 +0900 (JST) Received: from mail7.sony.co.jp (localhost [127.0.0.1]) by mail7.sony.co.jp (R8/Sony) with ESMTP id h252QqP07194 for ; Wed, 5 Mar 2003 11:26:52 +0900 (JST) Received: from sjp01051.meis.sony.co.jp (sjp01051.meis.sony.co.jp [43.15.126.60]) by mail7.sony.co.jp (R8/Sony) with ESMTP id h252QpJ07177 for ; Wed, 5 Mar 2003 11:26:52 +0900 (JST) Received: from jp.sony.com (43.27.168.161 [43.27.168.161]) by sjp01051.meis.sony.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FNHBK75M; Wed, 5 Mar 2003 11:26:51 +0900 Date: Wed, 5 Mar 2003 11:26:46 +0900 Subject: [AVT] ATRAC-X pre-presentation summary Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Matthew Romaine To: avt@ietf.org From: Matthew Romaine Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) 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 (apologies for those who already received this; mistyped initial address) Hello all, Summary of issues that will be covered during my ATRAC-X presentation update: Clarifications and Additions: - Timestamp and sample rate clarification - Redundant data framework modified - New method for multi-channel data decomposition introduced - Multiplexing/QoS reasoning solidified Time Stamp - corresponds to presentation time in milliseconds Sample Rate - all ATRAC-X streams during single session must be identical Revision of Redundant Data Framework - Comment from Atlanta session : "For redundancy to be useful the redundant copy may need to be separated further than one slot." - TimeStampeOffset added: 14bit unsigned offset value - What's wrong with RFC 2198? - RFC 2198 requires payload headers for primary and redundant data; creates unnecessary overhead - Block length field defined at 10bits; insufficient for ATRAC-X's high bit-rate data - Creates complexity in managing ATRAC-X's fragmentation data framework Multi-channel decomposition - Introduction of Block Coupling Pattern (BCP); 5bits - Introduction of Total Channel Configuration (TCC); 3 bits (table/figure to be presented; also in draft) Further examples and and figures to be presented. Looking forward to it. Matt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 00:29:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23036 for ; Wed, 5 Mar 2003 00:29:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h255eP814774 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 00:40:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h255bV514615; Wed, 5 Mar 2003 00:37:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h255aT513822 for ; Wed, 5 Mar 2003 00:36:29 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22960 for ; Wed, 5 Mar 2003 00:25:08 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id QAA16194; Wed, 5 Mar 2003 16:27:03 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa003ws; Wed Mar 5 16:26:51 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Mar 2003 16:26:52 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FKXXY4GW; Wed, 5 Mar 2003 16:25:08 +1100 To: mankin@psg.com Cc: avt@ietf.org, casner@acm.org, csp@isi.edu, harald@alvestrand.no, triad@df.lth.se Message-ID: <3E658A89.5070000@csiro.au> Date: Wed, 05 Mar 2003 16:26:33 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) 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 Allison, all, thank you very much for getting the application/ogg MIME type on its way. The accompanying I-D still needed some work and after extensive discussions in the Xiph/Ogg community, we have now submitted an updated version. It should become available soon at http://www.ietf.org/internet-drafts/draft-pfeiffer-ogg-fileformat-02.txt and may be put in front of the IESG again to be moved to an informational RFC. Best Regards, Silvia Pfeiffer. Here's the list of major changes: 1) The paragraph of trouble changed to (Section 4): Each Ogg page contains only one type of data as it belongs to one logical bitstream only. Pages are of variable size and have a page header containing encapsulation and error recovery information. Each logical bitstream in a physical Ogg bitstream starts with a special start page (bos=beginning of stream) and ends with a special page (eos=end of stream). The bos page contains information to uniquely identify the codec type and MAY contain information to set up the decoding process. The bos page SHOULD also contain information about the encoded media - for example, for audio, it should contain sample rate and number of channels. By convention, the first bytes of the bos page contain magic data that uniquely identify the required codec. It is the responsibility of anyone fielding a new codec to make sure it is possible to reliably distinguish his/her codec from all other codecs in use. There is no fixed way to detect the end of the codec-identifying marker. The format of the bos page is dependent on the codec and therefore MUST be given in the encapsulation specification of that logical bitstream type. An example for such a media mapping is "Ogg Vorbis", which provides the name and revision of the Vorbis codec, the audio rate and the audio quality on the Ogg Vorbis bos page. The vorbis bos page starts with the byte 0x01, followed by "vorbis" (a total of 7 bytes of identifier). 2) Another major change was made to the paragraph on "Theora", the video codec (Section 4): Another example is the upcoming "Ogg Theora" specification which encapsulates Theora-encoded video data and usually comes multiplexed with a Vorbis stream for an Ogg containing synchronised audio and video. As Ogg does not specify temporal relationships between the encapsulated concurrently multiplexed bitstreams, the temporal synchronisation between the audio and video stream will be specified in this media mapping. 3) All the other changes were minor editorial ones. Allison Mankin wrote: > Silvia, AVT WG, Chairs, > > We IESG passed draft-walleij-ogg-mediatype-08.txt as a Proposed > Standard today. It had had a four week Last Call some time back and > was not changed, other than now having the internet-draft available to > document the fileformat. Congratulations! > > The accompanying i-d, draft-pfeiffer-ogg-fileformat, was on the agenda > as well and Harald Alvestrand raised a technical question that needs > to be resolved before we can progress it as Informational. Harald's > written question: > > Technical omission (I think): The document says that the BOS page > "contains information to identify the codec type and any additional > information to set up the decoding process. The format of that page > is therefore dependent on the codec and therefore MUST be given in > the encoding specification of that logical bitstream type." > > It's pretty clear that OGG players can identify which codec is being > used. But this document does not say which bytes of the BOS page can > be used to identify the codec. (first 4 bytes? first 16 bytes? up to > the first NUL?) > > Thanks, > > Allison > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 01:15:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24046 for ; Wed, 5 Mar 2003 01:15:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h256QSS17390 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 01:26:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h256Km517097; Wed, 5 Mar 2003 01:20:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h256Js517044 for ; Wed, 5 Mar 2003 01:19:54 -0500 Received: from eikenes.alvestrand.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23768 for ; Wed, 5 Mar 2003 01:08:31 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 738006257E; Wed, 5 Mar 2003 07:10:34 +0100 (CET) Date: Wed, 05 Mar 2003 07:10:34 +0100 From: Harald Tveit Alvestrand To: Silvia.Pfeiffer@csiro.au, mankin@psg.com Cc: avt@ietf.org, casner@acm.org, csp@isi.edu, triad@df.lth.se Message-ID: <774620000.1046844634@askvoll.hjemme.alvestrand.no> In-Reply-To: <3E658A89.5070000@csiro.au> References: <3E658A89.5070000@csiro.au> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) 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 Thank you, and thanks for taking the time to understand my worry and addressing it! Based on the info below, I should have no problems letting this progress! --On onsdag, mars 05, 2003 16:26:33 +1100 Silvia.Pfeiffer@csiro.au wrote: > Dear Allison, all, > > thank you very much for getting the application/ogg MIME type on its way. > The accompanying I-D still needed some work and after extensive > discussions in the Xiph/Ogg community, we have now submitted an updated > version. It should become available soon at > http://www.ietf.org/internet-drafts/draft-pfeiffer-ogg-fileformat-02.txt > and may be put in front of the IESG again to be moved to an informational > RFC. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 04:26:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22589 for ; Wed, 5 Mar 2003 04:26:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h259asq07840 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 04:36:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259ZL507747; Wed, 5 Mar 2003 04:35:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h259XY507675 for ; Wed, 5 Mar 2003 04:33:34 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22488 for ; Wed, 5 Mar 2003 04:22:10 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HB900E6ERE8UG@panasonic.de> for avt@ietf.org; Wed, 5 Mar 2003 10:22:57 +0100 (MET) Date: Wed, 05 Mar 2003 10:22:57 +0100 From: Jose Rey Subject: RE: [AVT] draft-ietf-avt-rtp-retransmission-06.txt In-reply-to: To: "Avt@Ietf. Org" Cc: Colin Perkins , "Casner@Acm. Org" , David Leon Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Hi Steve & Colin, I haven't seen the retransmission draft in the status update. We would like you to consider it for WGLC as solicited below. thanks, José > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Jose > Rey > Sent: Friday, February 28, 2003 2:41 PM > To: Avt@Ietf. Org > Cc: Colin Perkins; Casner@Acm. Org > Subject: [AVT] draft-ietf-avt-rtp-retransmission-06.txt > > > Hi all, > > we just submitted the hopefully final revision of the retransmission > draft. Since the -05 draft there are only minor editorial changes, as > commented on the list. > > We would like to ask the WG chairs to consider it for WGLC and you all > to give it a final check, > > Until publication, the draft can be reached under: > > http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtp-retra > nsmission- > 06.txt > > Thanks, > > > Jose Rey > Mobile Multimedia Team - MCOM Group > Panasonic European Laboratories GmbH > Langen, Germany > - > rey@panasonic.de > www.pel.panasonic.de > - > Tel: +49(0)6103-766-134 > Fax: +49(0)6103-766-166 > -- > > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Mar 5 06:30:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26105 for ; Wed, 5 Mar 2003 06:30:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BfmB17136 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 06:41:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BfC516946; Wed, 5 Mar 2003 06:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BdD516827 for ; Wed, 5 Mar 2003 06:39: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 GAA25323; Wed, 5 Mar 2003 06:27:45 -0500 (EST) Message-Id: <200303051127.GAA25323@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, 05 Mar 2003 06:27:44 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-feedback-05.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 : Extended RTP Profile for RTCP-based Feedback(RTP/AVPF) Author(s) : J. Ott, S. Wenger, N. Sato Filename : draft-ietf-avt-rtcp-feedback-05.txt Pages : 50 Date : 2003-3-4 Real-time media streams that use RTP are not resilient against packet losses. Receivers may use the base mechanisms of RTCP to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term as sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allow for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-05.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-rtcp-feedback-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-feedback-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-4173644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-feedback-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-feedback-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4173644.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 06:30:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26146 for ; Wed, 5 Mar 2003 06:30:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Bfrn17150 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 06:41:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bfb517063; Wed, 5 Mar 2003 06:41:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BdK516831 for ; Wed, 5 Mar 2003 06:39:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25342; Wed, 5 Mar 2003 06:27:51 -0500 (EST) Message-Id: <200303051127.GAA25342@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, 05 Mar 2003 06:27:50 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-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. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Uncompressed Video Author(s) : L. Gharai, C. Perkins Filename : draft-ietf-avt-uncomp-video-02.txt Pages : 17 Date : 2003-3-4 This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, SMPTE 274M and SMPTE 296M. The format is designed to be extensible as new video formats are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-uncomp-video-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-ietf-avt-uncomp-video-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-uncomp-video-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-3-4173659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-uncomp-video-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-uncomp-video-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4173659.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 06:31:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26189 for ; Wed, 5 Mar 2003 06:31:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BfwJ17170 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 06:41:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bfk517101; Wed, 5 Mar 2003 06:41:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BdN516835 for ; Wed, 5 Mar 2003 06:39:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25361; Wed, 5 Mar 2003 06:27:55 -0500 (EST) Message-Id: <200303051127.GAA25361@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, 05 Mar 2003 06:27:55 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-retransmission-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Retransmission Payload Format Author(s) : J. Rey et al. Filename : draft-ietf-avt-rtp-retransmission-06.txt Pages : 27 Date : 2003-3-4 RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that RTCP feedback as defined in the extended RTP profile for RTCP-based feedback [1] ( denoted AVPF ), is available in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-06.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-retransmission-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-4173710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-retransmission-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4173710.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 13:28:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20267 for ; Wed, 5 Mar 2003 13:28:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25IdFs06993 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 13:39:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IbxO06900; Wed, 5 Mar 2003 13:37:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IW8O05447 for ; Wed, 5 Mar 2003 13:32:08 -0500 Received: from smtp01.mrf.mail.rcn.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19251 for ; Wed, 5 Mar 2003 13:20:58 -0500 (EST) X-Info: This message was accepted for relay by smtp01.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVZ/0DX42yahzUVligamrbpSztbYWk4AzHusDLYTMN1+uyZlfSobOtmP Received: from sense-sea-focal-dynamic-9-1.oz.net ([216.39.143.1] helo=erols.com) by smtp01.mrf.mail.rcn.net with asmtp (Exim 3.35 #4) id 18qdXg-0005NP-00; Wed, 05 Mar 2003 13:23:01 -0500 Message-ID: <3E663FB8.BC127026@erols.com> Date: Wed, 05 Mar 2003 10:19:36 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: avt@ietf.org, Ladan Gharai Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt References: <200303051127.GAA25342@ietf.org> 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, all, A few comments on this draft, which is looking very good so far. --- In uncomp-video-02 we have: 4.3. Payload Data Depending on the video format, each RTP packet can include either a single complete scan line, a single fragment of a scan line, or one (or more) complete scan lines plus a fragment of a scan line. [...] I think there are additional logical possibilities allowed by the document as it stands: a packet may begin with the tail fragment of a line, then continue with 0 or more full lines, and possibly the head fragment of another line. If the intent is to exclude these possibilities, we need normative language to say so. If these operational modes are permitted, the quoted text above is misleading and should be amended. --- On page 3 of the draft, we have [...] This payload format requires that applications using such synchronized ancillary data MUST deliver it in separate RTP sessions which operate concurrently with the video session. The normal RTP mechanisms SHOULD be used to synchronize the media. I believe the MUST is inappropriate and SHOULD is preferable. The idea that frame-accurate timecode will be carried as a parallel RTP session is a laudable but forward-looking conjecture. IMHO reliable use of this payload format in the near future will depend on carriage of vertical interval timecode (VITC) in an unused scan line which is part of the vertical blanking interval. (This is normal video operational practice, as mentioned in RFC 2431.) At the top of page 2 of the draft, we have "...the contents of horizontal and vertical blanking SHOULD NOT be transported." This does not bother me as SHOULD NOT language does not prevent me from carrying VITC when I need it, until the multisession RTP sync issues get ironed out. On the other hand the MUST language of page 3 is burdensome. --- A minor MUST/SHOULD nit at sec. 4.3 regarding filling to a pgroup boundary: since a receiver MUST ignore the fill data, it seems unneccessary that the sender MUST fill with zeroes, specifically. The sender MUST fill, and SHOULD fill with zeroes. --- The MIME and SDP parameters do not include the video frame rate. There are many plausible scenarios in which it is important to distinguish alternative frame rates. For example, choosing the right VOD stream during RTSP setup would need something like this. --- Cheers, Chuck Harrison Far Field Associates, LLC _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 16:48:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01328 for ; Wed, 5 Mar 2003 16:48:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Lxcw25366 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 16:59:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LwrO25315; Wed, 5 Mar 2003 16:58:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KBnO16070 for ; Wed, 5 Mar 2003 15:11:49 -0500 Received: from trinity.divxnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25597 for ; Wed, 5 Mar 2003 15:00:34 -0500 (EST) Received: (qmail 18226 invoked from network); 5 Mar 2003 20:02:33 -0000 Received: from unknown (HELO WIND) (192.168.0.69) by 192.168.0.8 with SMTP; 5 Mar 2003 20:02:33 -0000 From: "Adam Li" To: "Ietf-Avt" , "3GPP2 TSG-C" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , "'Colin Perkins'" Date: Wed, 5 Mar 2003 11:58:44 -0800 Organization: DivXNetworks, Inc. Message-ID: <008a01c2e351$a0af89f0$4500a8c0@divxnetworks.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.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [AVT] File format for EVRC/SMV vocoder 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 folks, One issue just recently been raised about the file format for EVRC and SMV data, which is specified the MIME registration for them. We very much would like to hear your ideas and comments on this issue. As you may have known, we are working the IETF specification on the RTP Payload Format for EVRC/SMV. It specifies how the EVRC/SMV payload is carried in RTP sessions, and it also registered the MIME format for the EVRC and SMV vocoders. The draft (draft-ietf-avt-evrc-smv) is currently at the final editing stage at the IETF FRC Editor's queue. There has been a file format defined in the draft-ietf-avt-evrc-smv at the MIME registration for EVRC/SMV. The file format specified there hasn't been changed much since the first version of the draft in 2000. There is a new Internet Draft, draft-garudadri-qcp-00.txt, specifies a different way of storage using the QCP file format, which has been used for QCEPL-13K and EVRC by some applications. Currently, it has been proposed to remove the file format specification in the draft-ietf-avt-evrc-smv, and to expand the draft-garudadri-qcp to be the only formal specification for the file format for EVRC/SMV. On the other hand, there are also suggestions to keep the file format at it is specified in the draft-ietf-avt-evrc-smv. We would like to hear your suggestions, and hear from you how you think would be the best way to proceed. Your comments are very much appreciated. Adam _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 16:49:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01387 for ; Wed, 5 Mar 2003 16:49:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Lxk425383 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 16:59:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Lx7O25350; Wed, 5 Mar 2003 16:59:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KQ4O16884 for ; Wed, 5 Mar 2003 15:26:04 -0500 Received: from trinity.divxnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26899 for ; Wed, 5 Mar 2003 15:14:53 -0500 (EST) Received: (qmail 18640 invoked from network); 5 Mar 2003 20:16:52 -0000 Received: from unknown (HELO WIND) (192.168.0.69) by 192.168.0.8 with SMTP; 5 Mar 2003 20:16:52 -0000 From: "Adam Li" To: "Ietf-Avt" , "3GPP2 TSG-C" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , "'Colin Perkins'" Date: Wed, 5 Mar 2003 12:13:02 -0800 Organization: UCLA Message-ID: <008d01c2e353$a044cf50$4500a8c0@divxnetworks.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.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [AVT] File format for EVRC/SMV vocoder 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 folks, One issue just recently been raised about the file format for EVRC and SMV data, which is specified the MIME registration for them. We very much would like to hear your ideas and comments on this issue. As you may have known, we are working the IETF specification on the RTP Payload Format for EVRC/SMV. It specifies how the EVRC/SMV payload is carried in RTP sessions, and it also registered the MIME format for the EVRC and SMV vocoders. The draft (draft-ietf-avt-evrc-smv) is currently at the final editing stage at the IETF FRC Editor's queue. There has been a file format defined in the draft-ietf-avt-evrc-smv at the MIME registration for EVRC/SMV. The file format specified there hasn't been changed much since the first version of the draft in 2000. There is a new Internet Draft, draft-garudadri-qcp-00.txt, specifies a different way of storage using the QCP file format, which has been used for QCEPL-13K and EVRC by some applications. Currently, it has been proposed to remove the file format specification in the draft-ietf-avt-evrc-smv, and to expand the draft-garudadri-qcp to be the only formal specification for the file format for EVRC/SMV. On the other hand, there are also suggestions to keep the file format at it is specified in the draft-ietf-avt-evrc-smv. We would like to hear your suggestions, and hear from you how you think would be the best way to proceed. Your comments are very much appreciated. Adam _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 16:49:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01414 for ; Wed, 5 Mar 2003 16:49:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Lxo925396 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 16:59:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Lx5O25335; Wed, 5 Mar 2003 16:59:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KJuO16473 for ; Wed, 5 Mar 2003 15:19:56 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26370 for ; Wed, 5 Mar 2003 15:08:45 -0500 (EST) From: keith.miller@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25KAl826615 for ; Wed, 5 Mar 2003 14:10:47 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Mar 2003 14:10:46 -0600 Received: from daebe003.NOE.Nokia.com ([172.18.242.199]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Mar 2003 14:10:28 -0600 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" Date: Wed, 5 Mar 2003 14:10:27 -0600 Message-ID: <8146199999A6384A8231B07B6E51D0BB024B82D5@daebe003.americas.nokia.com> Thread-Topic: File format for EVRC/SMV vocoder Thread-Index: AcLjUjF8fbcxu8vnSym8R/tzuj4RbwAAHB8w To: , , Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , X-OriginalArrivalTime: 05 Mar 2003 20:10:28.0976 (UTC) FILETIME=[446FBF00:01C2E353] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h25KK1O16493 Subject: [AVT] RE: File format for EVRC/SMV vocoder 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 Adam, Please include Jae-Yong Lee and Shigeyuki Sakazawa to this discussion. The are co-editors of the 3GPP2 file format specification along with Hari and myself. regards, Keith -----Original Message----- From: ext Adam Li [mailto:adamli@divx.com] Sent: 05 March, 2003 1:59 PM To: Ietf-Avt; 3GPP2 TSG-C Cc: Miller Keith (NRC/Dallas); randy@qualcomm.com; mccap@lucent.com; mdturner@lucent.com; smathai@lucent.com; lioy@qualcomm.com; zeng@packetvideo.com; sherwood@packetvideo.com; villa@icsl.ucla.edu; yllee@samsung.com; jeonghoon@samsung.com; tom.hiller@lucent.com; Leon David (NRC/Dallas); nleung@qualcomm.com; dgal@lucent.com; ajayrajkumar@lucent.com; Lars-Erik.Jonsson@epl.ericsson.se; magnus.westerlund@era-t.ericsson.se; vbharga@cisco.com; Greer Craig (Nokia/Dallas); magda@qualcomm.com; casner@acm.org; ned.freed@mrochek.com; mankin@psg.com; hgarudad@qualcomm.com; 'Colin Perkins' Subject: File format for EVRC/SMV vocoder Hi folks, One issue just recently been raised about the file format for EVRC and SMV data, which is specified the MIME registration for them. We very much would like to hear your ideas and comments on this issue. As you may have known, we are working the IETF specification on the RTP Payload Format for EVRC/SMV. It specifies how the EVRC/SMV payload is carried in RTP sessions, and it also registered the MIME format for the EVRC and SMV vocoders. The draft (draft-ietf-avt-evrc-smv) is currently at the final editing stage at the IETF FRC Editor's queue. There has been a file format defined in the draft-ietf-avt-evrc-smv at the MIME registration for EVRC/SMV. The file format specified there hasn't been changed much since the first version of the draft in 2000. There is a new Internet Draft, draft-garudadri-qcp-00.txt, specifies a different way of storage using the QCP file format, which has been used for QCEPL-13K and EVRC by some applications. Currently, it has been proposed to remove the file format specification in the draft-ietf-avt-evrc-smv, and to expand the draft-garudadri-qcp to be the only formal specification for the file format for EVRC/SMV. On the other hand, there are also suggestions to keep the file format at it is specified in the draft-ietf-avt-evrc-smv. We would like to hear your suggestions, and hear from you how you think would be the best way to proceed. Your comments are very much appreciated. Adam _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 17:04:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02167 for ; Wed, 5 Mar 2003 17:04:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25MFMT27681 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 17:15:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MEPO27612; Wed, 5 Mar 2003 17:14:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MDsO27535 for ; Wed, 5 Mar 2003 17:13:54 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02102; Wed, 5 Mar 2003 17:02:38 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h25M4WE06163; Wed, 5 Mar 2003 14:04:32 -0800 Date: Wed, 5 Mar 2003 14:04:32 -0800 From: John Lazzaro Message-Id: <200303052204.h25M4WE06163@snap.CS.Berkeley.EDU> To: avt@ietf.org Cc: mmusic@ietf.org Subject: [AVT] SF Issue Summary: draft-lazzaro-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: , Hi everyone, This is the summary message for the Wednesday, 19th March AVT WG presentation: Framing RTP over Connection-Oriented Transport (Lazzaro) 15 draft-lazzaro-avt-rtp-framing-contrans-00.txt I'm CC'ing this to MMUSIC, given the topical overlap of the I-D. This summary is somewhat long, because I describe the decisions that will move the document forward, so that WG members who won't be in San Francisco can voice their views on the lists by responding to this post. My presentation in San Francisco will put the 3 open issues described below up on the screen, to see if at least within the room a consensus can be found. --- This I-D began with an extended discussion on the WG: http://www1.ietf.org/mail-archive/working-groups/avt/current/msg01847.html Three requirements arose from this discussion: [1] A memo was needed to document the "classical" framing of RTP over TCP, to facilitate interoperability with applications that use it (several are mentioned in the linked WG thread). [2] There was an MMUSIC I-D that defined SDP conventions for setting up a TCP media session (draft-ietf-mmusic-sdp-comedia-04.txt, soon to be draft-ietf-mmusic-sdp-comedia-05.txt), but comedia defines neither the SDP fmt token to specify an RTP/AVP stream, nor the TCP framing such a stream should use. [3] RTSP has support for interleaving RTP and RTCP media streams into the TCP stream used for RTSP control method traffic. However, although RTSP also has the syntactic power to specify non-interleaved TCP session in the SETUP method, there is (apparently) no semantics in common use for this syntax. Requirement [1] is simple to address: write a new I-D to document classical RTP TCP framing. Sections 2-3 of draft-lazzaro-avt-rtp-framing-contrans-00.txt attempt to do this. #####> Open Issue #1 Does draft-lazzaro-avt-rtp-framing-contrans-00.txt accurately capture classical TCP framing, as used in practice? In specific, are the details in Section 3 correct? ---- The second requirement is more controversial. Given that we try to avoid "there's more than one way to do it", it would be best if there was one RTP/AVP TCP framing method for use with draft-ietf-mmusic-sdp-comedia-05.txt. The discussion in the WG thread linked above did not reach consensus, but instead ended with two different options: A. Define classical TCP framing as the framing method for RTP/AVP to use with draft-ietf-mmusic-sdp-comedia-05.txt. B. Write an AVT I-D that describes RTSP interleaved-mode RTP/AVP framing, as run over a stand-alone TCP stream. Define this framing method as the framing method to use with draft-ietf-mmusic-sdp-comedia-05.txt. Section 4 of draft-lazzaro-avt-rtp-framing-contrans-00.txt implements "A". Two more open issues: #####> Open Issue #2 Is A or B above the right path to take? Or, should we define SDP fmt codes for both A and B? ---- and #####> Open Issue #3 If A is the right option to take, are the SDP details in Section 4 of the draft-lazzaro-avt-rtp-framing-contrans-00.txt acceptable to everyone? ---- The final requirement involves RTSP support for non-interleaved TCP. Section 5 of draft-lazzaro-avt-rtp-framing-contrans-00.txt defines candidate RTSP semantics to use the classical TCP framing in RTSP. However, recent discussions in the Rtspspec-bugs transcripts seem to indicate that the editors of the core RTSP draft would prefer to handle this issue as a part of the RTSP draft document. So, unless I hear otherwise, I would think that deleting Section 5, and all mentions of RTSP, from draft-lazzaro-avt-rtp-framing-contrans-00.txt, is appropriate. ------------------------------------------------------------------------- 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 mailnull@www1.ietf.org Wed Mar 5 21:04:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10097 for ; Wed, 5 Mar 2003 21:04:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h262FF212447 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 21:15:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h262ETO12410; Wed, 5 Mar 2003 21:14:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h262CLO12352 for ; Wed, 5 Mar 2003 21:12:21 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10038 for ; Wed, 5 Mar 2003 21:01:02 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.8/8.12.8) with ESMTP id h261lbdk005611; Wed, 5 Mar 2003 20:47:37 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200303060147.h261lbdk005611@purple.nge.isi.edu> To: Chuck Harrison cc: avt@ietf.org, Ladan Gharai Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt In-Reply-To: Your message of "Wed, 05 Mar 2003 10:19:36 PST." <3E663FB8.BC127026@erols.com> Date: Wed, 05 Mar 2003 20:47:37 -0500 From: Colin Perkins 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, Thanks for the comments. A couple of replies inline. --> Chuck Harrison writes: > >A few comments on this draft, which is looking very good so far. > >--- >In uncomp-video-02 we have: > >4.3. Payload Data > >Depending on the video format, each RTP packet can include either a >single complete scan line, a single fragment of a scan line, or one >(or >more) complete scan lines plus a fragment of a scan line. [...] > > >I think there are additional logical possibilities allowed by >the document as it stands: a packet may begin with the tail >fragment of a line, then continue with 0 or more full lines, and >possibly the head fragment of another line. > >If the intent is to exclude these possibilities, we need normative >language to say so. If these operational modes are permitted, the >quoted text above is misleading and should be amended. Those modes are permitted, so I guess we need to clarify the text. Can you suggest some wording? >--- >On page 3 of the draft, we have > >[...] This payload format >requires that applications using such synchronized ancillary data MUST >deliver it in separate RTP sessions which operate concurrently with >the >video session. The normal RTP mechanisms SHOULD be used to >synchronize >the media. > >I believe the MUST is inappropriate and SHOULD is preferable. > >The idea that frame-accurate timecode will be carried as a >parallel RTP session is a laudable but forward-looking conjecture. >IMHO reliable use of this payload format in the near future >will depend on carriage of vertical interval timecode (VITC) >in an unused scan line which is part of the vertical blanking >interval. (This is normal video operational practice, as >mentioned in RFC 2431.) > >At the top of page 2 of the draft, we have "...the contents of >horizontal and vertical blanking SHOULD NOT be transported." This >does not bother me as SHOULD NOT language does not prevent me from >carrying VITC when I need it, until the multisession RTP sync >issues get ironed out. On the other hand the MUST language of >page 3 is burdensome. I'm still not convinced that an additional timecode is necessary: it should be derivable from the RTP timestamp and RTCP SR packets. Accordingly if you wish to synchronize the video to another source, you should use the normal RTCP method, rather than sending an additional timecode stream (indeed, if you use RTSP, I _think_ there is already a mapping function between the RTP timestamp and SMPTE timecode). >--- > >A minor MUST/SHOULD nit at sec. 4.3 regarding filling to a pgroup >boundary: since a receiver MUST ignore the fill data, it seems >unneccessary that the sender MUST fill with zeroes, specifically. >The sender MUST fill, and SHOULD fill with zeroes. > Okay. Is there a reason why zero fill doesn't work? >--- > >The MIME and SDP parameters do not include the video frame rate. >There are many plausible scenarios in which it is important >to distinguish alternative frame rates. For example, choosing >the right VOD stream during RTSP setup would need something like >this. You can use the SDP "a=framerate:" attribute, defined in RFC 2327. Cheers, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 5 21:16:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10297 for ; Wed, 5 Mar 2003 21:16:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h262QvG12829 for avt-archive@odin.ietf.org; Wed, 5 Mar 2003 21:26:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h262P8O12754; Wed, 5 Mar 2003 21:25:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h262OPO12708 for ; Wed, 5 Mar 2003 21:24:25 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10210; Wed, 5 Mar 2003 21:13:05 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id NAA16021; Thu, 6 Mar 2003 13:15:07 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa003uG; Thu Mar 6 13:15:03 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 13:15:03 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FKXXYV3Y; Thu, 6 Mar 2003 13:14:50 +1100 To: avt@ietf.org, mmusic@ietf.org Message-ID: <3E66AF6D.7040106@csiro.au> Date: Thu, 06 Mar 2003 13:16:13 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] new I-D on temporal URI addresses 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, we have submitted a proposal to specify temporal URI fragments on time-continuous Web resources (such as audio and video files/streams). I would like to ask for your brains on whether this is a problem that you've stumbled across, too, and whether you like the solution that we are proposing. http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00.txt THE PROBLEM: ------------ We can see a need for the direct specification of points of interest in a URI for a/v. There are several uses for it: 1) Representation of search results: When typing a search term into your favourite search engine, you would like it to search on a/v and bring up the link to an offset in a video where the search term matches. e.g. goal in last week's soccer matches 2) Favourite links: When sending a link to a video to a friend, you'd really like to be able to specify the main part of your interest in it. e.g. look at my new cool sunglasses in my friend's wedding video THE SOLUTION: ------------- What we want is to address fragment offsets into videos. Therefore, the "#fragment" part of a URI naturally lends itself for including this address specification. For specification of the time points, we were inspired by the timestamp specification in RTSP. Therefore, we are proposing the following pattern: #@npt=14.5 -> the "#" part signifies a fragment specification -> the "@" tells us to look "at" that time specification -> the "npt=" part is a time scheme just like in RTSP and we are also proposing npt, smpte, smpte-30-drop, smpte-25, and clock -> the time format itself depends on the time scheme, this one signifying a 14.5 seconds offset [for more details refer to the I-D] THE USE: -------- Here are examples for temporal URI fragment offsets: http://foo/bar.mov#@smpte=00:00:14:15 (start downloading at 14 seconds and 15 frames into bar.mov) rtsp://foo/bar.avi#@utc=20030308T143000.00Z (start streaming at 8th March 2003 at half past 2pm) http://foo/bar.mpg#@start (start downloading from the start) rtsp://foo/bar.rm#@now (start streaming now) --- We wanted to make it simple, intuitive and human readable and have therefore come up with this solution. Please let me know what you think. Cheers, Silvia. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 05:16:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00671 for ; Thu, 6 Mar 2003 05:16:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26ARdW21367 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 05:27:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ARFO21344; Thu, 6 Mar 2003 05:27:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26AOSO21214 for ; Thu, 6 Mar 2003 05:24:28 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00504; Thu, 6 Mar 2003 05:12:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26AEuB3009603; Thu, 6 Mar 2003 11:14:56 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JGN5G; Thu, 6 Mar 2003 11:14:56 +0100 Message-ID: <3E671F9E.7080706@era.ericsson.se> Date: Thu, 06 Mar 2003 11:14:54 +0100 X-Sybari-Trust: 8d2942c6 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvia.Pfeiffer@csiro.au CC: avt@ietf.org, mmusic@ietf.org Subject: Re: [AVT] new I-D on temporal URI addresses References: <3E66AF6D.7040106@csiro.au> 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, Silvia. I see the possibility of this proposal. However I have a number of comments on this proposal. First is the possibility to specify this as a general mechanism. It seems that you want to have this to apply to all URI schemes. Is that really possible? How do you know that the use of @ will not collide with any usage? For example the rtsp scheme does not define how to interpret the fragment. So this is up to the server responding to a request. So this can potentially already be used by some implementations. Also does it make sense to be defined for all schemes. As this is currently related to media it seems that for the moment it applies to HTTP(S) and RTSP(U|S). So a general question, what is the actually possibilities to standardize such a solution? Second, is the usage of the fragment identifier. It seems that you tries to redefine the meaning of the fragment identifier. See below. From RFC 2396: "When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. fragment = *uric The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. The character restrictions described in Section 2 for URI also apply to the fragment in a URI-reference. Individual media types may define additional restrictions or structure within the fragment for specifying different types of "partial views" that can be identified within that media type." Two things strikes me as not being taken into account by your draft in relation to this quote. The first is from the first paragraph of the quote. The fragment identifier is interpreted by the user agent. While in chapter 4 of your draft you clearly specifies that the server shall interpret the fragment. This redefines the behavior of the fragment identifier. Secondly the interpretation of the fragment identifier is in relation to the data resulting in the request. So in fact it seems that you need to define the behavior on per media basis. I think the use of fragment to specify where in a media resource is appropriate in some case. For example an RTSP URL that has a fragment of the proposed type is useful. However as RTSP works the server shall not interpret the fragment as this is pointless. Only the client needs to do this and use that to determine the range to include in the PLAY request. So again the usage rules in chapter 4 seems to be wrong. It seems that the time specification should be complemented to allow specifying ranges. The result of a search or the part of your friends wedding video that you want to point out would in most cases only be a part of the video. Therefore both a start and stop time seems useful. Then it is also a very short step to having multiple ranges allow one to point out multiple parts of the same resource that are interesting. Also I think you have a few strange thing in the definition. First you specify an attribute "start" that I think are pointless. Either you totally skip the fragment or you can use "npt=0". Secondly it the defaulting to "npt". This clashed with the general parameters. If you use start then you have actually wrote "npt=start" which isn't defined. "now" works as long as this is based on the RTSP definitions of NPT, however from your BNF definitions this is evidently not the case. So my proposal is to skip having any default time scheme if you are going to have general attributes that does not belong to a time scheme. If you would like the server to take the range into account would not the use of query (?) be better? However I hope that somebody that are more will versed in URIs can give further suggestions. I can see the usefulness of this proposal, however there is need to resolve a number of issues: - A general standardization or target certain URI schemes? - Applicability on different media types and protocols needs to better understood. - Use of fragment or other URI syntax element, like parameter or query? - Need for having ranges? - The actual need for general parameters? Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 05:53:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01459 for ; Thu, 6 Mar 2003 05:53:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26B44t23637 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 06:04:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26B3DO23605; Thu, 6 Mar 2003 06:03:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26B2FO23584 for ; Thu, 6 Mar 2003 06:02:15 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01396 for ; Thu, 6 Mar 2003 05:50:44 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id B086FA4F52; Thu, 6 Mar 2003 11:52:47 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA04470; Thu, 6 Mar 2003 11:52:44 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA05774; Thu, 6 Mar 2003 11:52:37 +0100 (MET) Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt To: Chuck Harrison Cc: avt@ietf.org, Ladan Gharai X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 6 Mar 2003 11:45:54 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 06/03/2003 11:53:39 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: , Hi all, I concur with chuck, this is looking very good indeed. Just a few remarks ***************************** I am not sure I always understand the "pixels" and "#words" second and third column in the tables ? For exemple for monochrome 10 bits pixels is "4" so that would hint it means "number of pixels per Pgroup" But then the next line is "4" for 4:1:1 while there are 8 pixels per Pgroup? Also the #words is 6x10, but these are actually "bits" rather than "words"? I think these tables would benefit a few sentences giving the exact definition of each column. ***************************** The 8 bit words tables probably contains a typo for the "octet alignement" of Interlaced 4:2:0 which should be "4x8/8 = 4" no? ***************************** in section 4.3 it says "For RGB format video, samples are packed in order Red-Green-Blue. All samples are the same bit size, which may be 8, 10, 12, or 16 bits. If 8 bit samples are used, the pgroup is 3 octets. If 10 bit samples are used, samples from adjacent pixels are packed with no padding, and the pgroup is 15 octets (4 pixels). Refer to Tables 1 thru 4. For RGBA format video, samples are packed in order Red-Green-Blue-Alpha. All samples are the same bit size, which may be 8, 10, 12, or 16 bits. For pgroups refer to Tables 1 thru 4." Unfortunately the tables 1 thru 4 do not explicitely mention any RGB or RGBA format(!) I think it would be useful to add them, here are the tables (not sure the notation R:G:B is appropriate, anyway "RGB" is what is declared in the mime type ...) 8 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+---------------+ | R:G:B | 1 | P | | 3x8 | 3x8/8 = 3 | 3 | 3 | +-----------+------+---+ +------+---------------+---------------+ | R:G:B:A | 1 | P | | 4x8 | 4x8/8 = 4 | 4 | 4 | +-----------+------+---+ +------+---------------+---------------+ 10 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+---------------+ | R:G:B | 1 | P | | 3x10 | 4x30/8 = 15 | 12 | 15 | +-----------+------+---+ +------+---------------+---------------+ | R:G:B:A | 1 | P | | 4x10 | 40/8 = 5 | 4 | 5 | +-----------+------+---+ +------+---------------+---------------+ 12 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+---------------+ | R:G:B | 1 | P | | 6x12 | 2x36/8 = 9 | 6 | 9 | +-----------+------+---+ +------+---------------+---------------+ | R:G:B:A | 1 | P | | 4x12 | 48/8 = 6 | 4 | 6 | +-----------+------+---+ +------+---------------+---------------+ 16 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+-------+-------+ | R:G:B | 1 | P | | 3x16 | 3x16/8 = 6 | 3 | 6 | +-----------+------+---+ +------+---------------+-------+-------+ | R:G:B:A | 1 | P | | 4x16 | 4x16/8 = 8 | 4 | 8 | +-----------+------+---+ +------+---------------+-------+-------+ ***************************** Since we have 4:4:4:4, one thing that should be added is 4:4:2:0 which is 4:2:0 (the most common raw video format since it is the raw format of most codecs) plus a transparency plane with one transparency word per pixel i.e. same amount of transparency as luminance This can be *very* useful for studio applications and is also directly compressable using the profiles and levels of MPEG-4 video that support the "shape" tool. It simply needs to add 4:4:2:0 in the valid value list (section 6.1) and in section 3 the relevant tables would be: 8 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | P | | 10x8 | 80/8 = 10 | 10 | 10 | +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | I | | 8x8 | 64/8 = 8 | 8 | 8 | +-----------+------+---+ +------+---------------+---------------+ 10 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | P | | 10x10| 2x100/8 = 25 | 20 | 25 | +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | I | | 8x10 | 80/8 = 10 | 8 | 10 | +-----------+------+---+ +------+---------------+---------------+ 12 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | P | | 10x12| 120/8 = 15 | 10 | 15 | +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | I | | 8x12 | 96/8 = 12 | 8 | 12 | +-----------+------+---+ +------+---------------+---------------+ 16 bit words Color -------------------------------------- Subsampling Pixels #words octet alignment samples pgroup octets +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | P | | 10x16| 160/8 = 20 | 10 | 20 | +-----------+------+---+ +------+---------------+---------------+ | 4:4:2:0 | 4 | I | | 8x16 | 128/8 = 16 | 8 | 16 | +-----------+------+---+ +------+---------------+---------------+ regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: avt@ietf.org Ladan Gharai cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt Chuck Harrison Classification: Sent by: avt-admin@ietf.org 05/03/2003 19:19 Hi, all, A few comments on this draft, which is looking very good so far. --- In uncomp-video-02 we have: 4.3. Payload Data Depending on the video format, each RTP packet can include either a single complete scan line, a single fragment of a scan line, or one (or more) complete scan lines plus a fragment of a scan line. [...] I think there are additional logical possibilities allowed by the document as it stands: a packet may begin with the tail fragment of a line, then continue with 0 or more full lines, and possibly the head fragment of another line. If the intent is to exclude these possibilities, we need normative language to say so. If these operational modes are permitted, the quoted text above is misleading and should be amended. --- On page 3 of the draft, we have [...] This payload format requires that applications using such synchronized ancillary data MUST deliver it in separate RTP sessions which operate concurrently with the video session. The normal RTP mechanisms SHOULD be used to synchronize the media. I believe the MUST is inappropriate and SHOULD is preferable. The idea that frame-accurate timecode will be carried as a parallel RTP session is a laudable but forward-looking conjecture. IMHO reliable use of this payload format in the near future will depend on carriage of vertical interval timecode (VITC) in an unused scan line which is part of the vertical blanking interval. (This is normal video operational practice, as mentioned in RFC 2431.) At the top of page 2 of the draft, we have "...the contents of horizontal and vertical blanking SHOULD NOT be transported." This does not bother me as SHOULD NOT language does not prevent me from carrying VITC when I need it, until the multisession RTP sync issues get ironed out. On the other hand the MUST language of page 3 is burdensome. --- A minor MUST/SHOULD nit at sec. 4.3 regarding filling to a pgroup boundary: since a receiver MUST ignore the fill data, it seems unneccessary that the sender MUST fill with zeroes, specifically. The sender MUST fill, and SHOULD fill with zeroes. --- The MIME and SDP parameters do not include the video frame rate. There are many plausible scenarios in which it is important to distinguish alternative frame rates. For example, choosing the right VOD stream during RTSP setup would need something like this. --- Cheers, Chuck Harrison Far Field Associates, LLC _______________________________________________ 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 mailnull@www1.ietf.org Thu Mar 6 06:26:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02710 for ; Thu, 6 Mar 2003 06:26:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Bbbv26354 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 06:37:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BbEO26004; Thu, 6 Mar 2003 06:37:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BZrO25501 for ; Thu, 6 Mar 2003 06:35:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02201; Thu, 6 Mar 2003 06:24:23 -0500 (EST) Message-Id: <200303061124.GAA02201@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: Thu, 06 Mar 2003 06:24:23 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-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: , --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 : The MIDI Wire Protocol Packetization (MWPP) Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-mwpp-midi-rtp-06.txt Pages : 100 Date : 2003-3-5 The MIDI Wire Protocol Packetization (MWPP) is a general-purpose RTP packetization for the MIDI command language. MWPP is suitable for use in both interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as MIDI file streaming). MWPP is suitable for use over unicast and multicast UDP, and defines tools that support the graceful recovery from packet loss. MWPP may also be used over reliable transport such as TCP. The SDP parameters defined for MWPP support the customization of stream behavior (including the MIDI rendering method) during session setup. MWPP is compatible with the MPEG-4 generic RTP payload format, to support the MPEG 4 Audio object types for General MIDI, DLS2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-06.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-mwpp-midi-rtp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5140135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mwpp-midi-rtp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140135.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 06:26:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02732 for ; Thu, 6 Mar 2003 06:26:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26BbdE26367 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 06:37:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BapO25551; Thu, 6 Mar 2003 06:36:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BZnO25496 for ; Thu, 6 Mar 2003 06:35: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 GAA02179; Thu, 6 Mar 2003 06:24:19 -0500 (EST) Message-Id: <200303061124.GAA02179@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: Thu, 06 Mar 2003 06:24:18 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload Format for JVT Video Author(s) : S. Wenger et al. Filename : draft-ietf-avt-rtp-h264-01.txt Pages : 27 Date : 2003-3-5 This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec. The most up-to-date draft of the video codec was specified in February 2003, is due for final approval at the committee level late March 2003, and is available for public review [1]. This codec was designed as a joint project of the Video Coding Experts Group (VCEG) of ITU-T and the Moving Picture Experts Group (MPEG) of ISO/IEC. ISO/IEC International Standard 14496-10 will be technically identical to ITU-T Recommendation H.264. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-01.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-h264-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-h264-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5140115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-h264-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h264-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140115.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 08:01:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10890 for ; Thu, 6 Mar 2003 08:01:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26DC7802150 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 08:12:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DBgO02092; Thu, 6 Mar 2003 08:11:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DATO02035 for ; Thu, 6 Mar 2003 08:10:29 -0500 Received: from syd-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10628 for ; Thu, 6 Mar 2003 07:58:55 -0500 (EST) Received: from cscoamera13263.cisco.com (localhost [127.0.0.1]) by syd-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h26CtmPp016337; Thu, 6 Mar 2003 23:55:52 +1100 (EST) Message-Id: <5.1.1.5.2.20030306043913.06c676b8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 06 Mar 2003 04:46:05 -0800 To: "Adam Li" From: Mark Baugher Subject: Re: [AVT] File format for EVRC/SMV vocoder Cc: "Ietf-Avt" , "3GPP2 TSG-C" In-Reply-To: <008d01c2e353$a044cf50$4500a8c0@divxnetworks.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: , Adam I have a question: Why take a file format specification through the IETF? Best regards, Mark At 12:13 PM 3/5/2003 -0800, Adam Li wrote: >Hi folks, > >One issue just recently been raised about the file format for EVRC and >SMV data, which is specified the MIME registration for them. We very >much would like to hear your ideas and comments on this issue. > >As you may have known, we are working the IETF specification on the RTP >Payload Format for EVRC/SMV. It specifies how the EVRC/SMV payload is >carried in RTP sessions, and it also registered the MIME format for the >EVRC and SMV vocoders. The draft (draft-ietf-avt-evrc-smv) is currently >at the final editing stage at the IETF FRC Editor's queue. > >There has been a file format defined in the draft-ietf-avt-evrc-smv at >the MIME registration for EVRC/SMV. The file format specified there >hasn't been changed much since the first version of the draft in 2000. > >There is a new Internet Draft, draft-garudadri-qcp-00.txt, specifies a >different way of storage using the QCP file format, which has been used >for QCEPL-13K and EVRC by some applications. > >Currently, it has been proposed to remove the file format specification >in the draft-ietf-avt-evrc-smv, and to expand the draft-garudadri-qcp to >be the only formal specification for the file format for EVRC/SMV. On >the other hand, there are also suggestions to keep the file format at it >is specified in the draft-ietf-avt-evrc-smv. > >We would like to hear your suggestions, and hear from you how you think >would be the best way to proceed. Your comments are very much >appreciated. > >Adam > > >_______________________________________________ >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 mailnull@www1.ietf.org Thu Mar 6 09:11:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15439 for ; Thu, 6 Mar 2003 09:11:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26EMYD07377 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 09:22:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ELYO07329; Thu, 6 Mar 2003 09:21:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EK7O07262 for ; Thu, 6 Mar 2003 09:20:07 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15347 for ; Thu, 6 Mar 2003 09:08:34 -0500 (EST) Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA23888; Thu, 6 Mar 2003 15:10:34 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA04461; Thu, 6 Mar 2003 15:09:59 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 15:10:19 +0100 Message-ID: From: Kreuter Ruediger To: "'Colin Perkins'" , avt@ietf.org Cc: casner@acm.org Subject: AW: [AVT] Agenda for San Francisco meeting - Clearmode Date: Thu, 6 Mar 2003 15:10:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h26EK7O07263 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 > -----Ursprüngliche Nachricht----- > Von: Colin Perkins [mailto:csp@isi.edu] > Gesendet: Mittwoch, 5. März 2003 01:59 > An: avt@ietf.org > Cc: casner@acm.org > Betreff: [AVT] Agenda for San Francisco meeting > > > Folks, > > Enclosed is the agenda for the AVT meeting in San Francisco. > Please send > any comments or corrections to the chairs. > > Those who have agenda time scheduled are requested to prepare > a summary of > the issues they wish to discuss, and to send this to the > mailing list ahead > of the meeting. This gives those who won't be attending the > opportunity to > post their comments and concerns, and potentially even reach > some consensus, > before the meeting time is consumed. It also gives other > participants the > opportunity to consider the issue in more depth. Summary > messages SHOULD be > sent to the mailing list by Monday 10th March. > ... > > Thursday, 20th March at 09:00-11:30 > =================================== > > RTP Payload Format for a 64 kbit/s transparent call > (Kreuter) 15 > draft-kreuter-avt-rtp-clearmode-01.txt > See also the TDM emulation work in the PWE3 working group > Last friday I've submitted draft-kreuter-avt-rtp-clearmode-02.txt to internet-drafts@ietf.org. This is still in the queue ... Basically I removed Nx64 kbit/s from my draft and fixed some typos. After discussion with A. Vainshtein, one of the author's of draft-vainshtein-cesopsn-05.txt (PWE3), Tom Johnson, who is working on a similar topic, and Colin Perkins we agreed that it makes sense to split the Clearmode handling in two drafts, where my draft focuses on 1x64 kbit/s and an according MIME type registration, and the PWE3 draft focuses on Nx64 kbit, T1/E1 and up for CES services. So according draft-kreuter-avt-rtp-clearmode-xx.txt, IMHO the only open item now is the content type. In discussion is "audio" or "application". My intention for the IETF presentation is to get an agreement on that topic, so that this draft can be advanced for IESG approval. Regards, Ruediger _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 10:29:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20392 for ; Thu, 6 Mar 2003 10:29:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Ff1L14727 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 10:41:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FeJO14616; Thu, 6 Mar 2003 10:40:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FbgO14409 for ; Thu, 6 Mar 2003 10:37:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20204 for ; Thu, 6 Mar 2003 10:26:07 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h26FSAwv013473; Thu, 6 Mar 2003 16:28:10 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4JJW8L; Thu, 6 Mar 2003 16:28:08 +0100 Message-ID: <3E676906.7060903@era.ericsson.se> Date: Thu, 06 Mar 2003 16:28:06 +0100 X-Sybari-Trust: cede3e9b 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kreuter Ruediger CC: "'avt@ietf.org'" Subject: Re: [AVT] updated "Clearmode" (64kbit/s unrestricted) Internet-draft References: 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, I have some comments on this draft. 1. Chapter 2: First sentence seems strange it looks like it lacks context. "The profile .." refers to something which I don't know what it is. 2. Maybe a little more text on how data is put in the payload format. Especially around the number of samples you are allowed to put into each packet. 3. End of chapter 2: "The timestamp SHALL be set according [5]" Shouldn't this be "The timestamp SHALL be set according to [5]." 4. Chapter 3: Optional parameters. I think "maxptime" is a valid one to use. The existing RFC with this parameter is RFC 3267 but the updated SDP draft also contains a definition of it. 5. Chapter 3 is missing rules on how you apply the mime parameters to SDP. Please see draft-ietf-avt-rtp-mime-06.txt for such a chapter. 6. Reference list in chapter 5. Shouldn't there be nice [] around the numbers? 7. Time to read the ID nits. You are lacking a couple of necessary sections, like Copyright statement and IPR statement. See http://www.ietf.org/ID-nits.html 8. When you don't transport ISDN 7 kHz voice in this and actually carry some other type of data. Isn't of interest to mention RTP relevant mechanisms to protect the stream against packet loss. There should be significant considerations of this problem. 9. Please look at the formatting also. There are certain parts that would look nicer if they are done as bullet list instead of one sentence paragraphs. Best Regards Magnus Kreuter Ruediger wrote: >FYI, >I have submitted an update of the CLEARMODE Internet draft. You find it at >http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clearmode-01.txt > >The major update, due to comments according the support of Nx64kbit/s >and similar standardization activities in ITU's SG 11, is the introduction of >Nx64kbit/s support. Two remarks to this issue: >1) 1x64kbit/s is used in current VoIP products and supported by most DSP > Providers. Therefore I would like to keep Nx64kbit/s with N>1 as an option. >2) We currently do not have a VoIP product supporting Nx64kbit/s, therefore > I introduced this merely as a discussion input. > So if anybody has a working Nx64kbit/s solution I would like to get some > comments on the packatization method in that case. If nobody has a > solution I will delete this feature from the next version of this draft. > >Besides, the first draft initiated a controverse discussion, if this should be >"audio/CLEARMODE" or e.g. "application/CLEARMODE". >IMHO none of the existing IANA content types really fits for CLEARMODE. >Since 1x64kbit/s is also used for 7kHz voice (despite G.722) I kept "audio" >in this draft. > >Regards > Ruediger >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 10:39:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21014 for ; Thu, 6 Mar 2003 10:39:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Foml15469 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 10:50:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fo6O15425; Thu, 6 Mar 2003 10:50:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FNSO12883 for ; Thu, 6 Mar 2003 10:23:28 -0500 Received: from go4.ext.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19313 for ; Thu, 6 Mar 2003 10:11:54 -0500 (EST) Received: from dlep51.itg.ti.com ([157.170.141.75]) by go4.ext.ti.com (8.12.8/8.12.8) with ESMTP id h26FCfbE028575; Thu, 6 Mar 2003 09:12:41 -0600 (CST) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.6/8.12.6) with ESMTP id h26FCehO008843; Thu, 6 Mar 2003 09:12:40 -0600 (CST) Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA11487; Thu, 6 Mar 2003 09:12:40 -0600 (CST) Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19) id <15JYXDZ8>; Thu, 6 Mar 2003 09:10:48 -0600 Message-ID: From: "Jarrett, David" To: "'avt@ietf.org'" Cc: "'mcgrew@cisco.com'" Date: Thu, 6 Mar 2003 09:12:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E3F2.CC0169A3" Subject: [AVT] Status of SRTP 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2E3F2.CC0169A3 Content-Type: text/plain AVT group: What's the status of SRTP? It expired at the end of '02. Are there any plans for a new draft? DWJ --- David W. Jarrett Senior Technical Staff Broadband Solutions Texas Instruments djarrett@ti.com (408) 468-0830 ------_=_NextPart_001_01C2E3F2.CC0169A3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Status of SRTP

AVT group:

What's the status of = SRTP?  It expired at the end of '02.  Are there any plans for = a new draft?

DWJ

---

David W. = Jarrett        Senior Technical = Staff

Broadband = Solutions     Texas Instruments

djarrett@ti.com         = (408) 468-0830

------_=_NextPart_001_01C2E3F2.CC0169A3-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 10:45:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21532 for ; Thu, 6 Mar 2003 10:45:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Fudo15865 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 10:56:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fu5O15786; Thu, 6 Mar 2003 10:56:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fs1O15632 for ; Thu, 6 Mar 2003 10:54:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21142; Thu, 6 Mar 2003 10:42:26 -0500 (EST) Message-Id: <200303061542.KAA21142@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: Thu, 06 Mar 2003 10:42:26 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Extended Reports (RTP XR) Author(s) : T. Friedman et. al. Filename : draft-ietf-avt-rtcp-report-extns-03.txt Pages : 41 Date : 2003-3-5 This document defines the extended report (XR) packet type for the RTP control protocol (RTCP). 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 adhereing to the framework that this document provides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-03.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-rtcp-report-extns-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5171727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-report-extns-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5171727.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 10:46:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21586 for ; Thu, 6 Mar 2003 10:46:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FvVX15959 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 10:57:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fv1O15909; Thu, 6 Mar 2003 10:57:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FuKO15826 for ; Thu, 6 Mar 2003 10:56:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21389; Thu, 6 Mar 2003 10:44:46 -0500 (EST) Message-Id: <200303061544.KAA21389@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: Thu, 06 Mar 2003 10:44:46 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback Author(s) : J. Chesterfield, E. Schooler, J. Ott Filename : draft-ietf-avt-rtcpssm-03.txt Pages : 37 Date : 2003-3-5 This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-03.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-rtcpssm-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcpssm-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5183100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcpssm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcpssm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5183100.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 10:46:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21601 for ; Thu, 6 Mar 2003 10:46:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26FvcL15973 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 10:57:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Fv3O15926; Thu, 6 Mar 2003 10:57:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FuRO15830 for ; Thu, 6 Mar 2003 10:56:27 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21404 for ; Thu, 6 Mar 2003 10:44:51 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26Fkr0N017702; Thu, 6 Mar 2003 07:46:53 -0800 (PST) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AES88576; Thu, 6 Mar 2003 07:41:40 -0800 (PST) From: "David A. Mcgrew" To: "Jarrett, David" Cc: Date: Thu, 6 Mar 2003 07:46:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_18C7_01C2E3B4.8C82DC80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Subject: [AVT] RE: Status of SRTP 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_18C7_01C2E3B4.8C82DC80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Status of SRTPDavid, a new version will be coming out shortly, reflecting some discussion with the IESG. Thanks for pointing out that the current draft actually expired last December. It's been in IESG review for a while, and it has taken some time to settle on changes to the draft. We unintentionally let the document lapse. David M. -----Original Message----- From: Jarrett, David [mailto:djarrett@ti.com] Sent: Thursday, March 06, 2003 7:13 AM To: 'avt@ietf.org' Cc: 'mcgrew@cisco.com' Subject: Status of SRTP AVT group: What's the status of SRTP? It expired at the end of '02. Are there any plans for a new draft? DWJ --- David W. Jarrett Senior Technical Staff Broadband Solutions Texas Instruments djarrett@ti.com (408) 468-0830 ------=_NextPart_000_18C7_01C2E3B4.8C82DC80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status of SRTP
David,
 
a new=20 version will be coming out shortly, reflecting some discussion with the=20 IESG.  Thanks for pointing out that the current draft = actually=20 expired last December.  It's been in IESG review for a while, and = it has=20 taken some time to settle on changes to the draft.  We = unintentionally let=20 the document lapse.
 
David=20 M.
 
-----Original Message-----
From: Jarrett, David=20 [mailto:djarrett@ti.com]
Sent: Thursday, March 06, 2003 7:13 = AM
To: 'avt@ietf.org'
Cc:=20 'mcgrew@cisco.com'
Subject: Status of = SRTP

AVT group:

What's the status of = SRTP?  It=20 expired at the end of '02.  Are there any plans for a new=20 draft?

DWJ

---

David W.=20 Jarrett        Senior Technical=20 Staff

Broadband=20 Solutions     Texas Instruments

djarrett@ti.com         = (408)=20 468-0830

------=_NextPart_000_18C7_01C2E3B4.8C82DC80-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 11:01:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22571 for ; Thu, 6 Mar 2003 11:01:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26GCjI17950 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 11:12:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GC8O17919; Thu, 6 Mar 2003 11:12:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GBMO17873 for ; Thu, 6 Mar 2003 11:11:22 -0500 Received: from [209.116.240.194] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22440; Thu, 6 Mar 2003 10:59:44 -0500 (EST) Received: from mail.nab.org by [209.116.240.194] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 6 Mar 2003 11:01:48 -0500 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF1011351FC@mail.NAB.ORG> From: "Allison, Art" To: "'Internet-Drafts@ietf.org'" Cc: avt@ietf.org Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-03.txt Date: Thu, 6 Mar 2003 11:01: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: , Perhaps this post is not the most appropriate; but for some time I have been considering informing the experts here about the work done by the ATSC to address the problem of multicast when no return path is available. See http://www.atsc.org/standards/a_92.pdf Art ::{) Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 06, 2003 10:45 AM Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback Author(s) : J. Chesterfield, E. Schooler, J. Ott Filename : draft-ietf-avt-rtcpssm-03.txt Pages : 37 Date : 2003-3-5 This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-03.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-rtcpssm-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcpssm-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 12:14:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29642 for ; Thu, 6 Mar 2003 12:14:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HPtm25894 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 12:25:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HPDO25555; Thu, 6 Mar 2003 12:25:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HGlO24443 for ; Thu, 6 Mar 2003 12:16:47 -0500 Received: from multicasttech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28841; Thu, 6 Mar 2003 12:05:07 -0500 (EST) Received: from [68.100.8.94] (account marshall_eubanks HELO localhost) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1619220; Thu, 06 Mar 2003 12:07:00 -0500 Date: Thu, 6 Mar 2003 11:52:30 -0500 Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Internet-Drafts@ietf.org'" , avt@ietf.org To: "Allison, Art" From: Marshall Eubanks In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF1011351FC@mail.NAB.ORG> Message-Id: <053F05E3-4FF4-11D7-B81E-003065BA697E@multicasttech.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) 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 Dear Art; There is a working group for no-return path transport, UDLR http://www.ietf.org/html.charters/udlr-charter.html which includes multicast. How do these approaches compare ? How different is the ATSC work from the DVB standards ? There was I think a ip-dvb BOF in Atlanta, but I do not know if this will become a working group. Regards Marshall Eubanks On Thursday, March 6, 2003, at 11:01 AM, Allison, Art wrote: > Perhaps this post is not the most appropriate; but for some time I have > been > considering informing the experts here about the work done by the ATSC > to > address the problem of multicast when no return path is available. See > http://www.atsc.org/standards/a_92.pdf > > > Art > ::{) > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, March 06, 2003 10:45 AM > Cc: avt@ietf.org > Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working Group of > the > IETF. > > Title : RTCP Extensions for Single-Source Multicast > Sessions > with Unicase Feedback > Author(s) : J. Chesterfield, E. Schooler, J. Ott > Filename : draft-ietf-avt-rtcpssm-03.txt > Pages : 37 > Date : 2003-3-5 > > This document specifies a modification to the Real-time Transport > Control Protocol (RTCP) to use unicast feedback. The proposed > extension is useful for single source multicast sessions such as > Source Specific Multicast (SSM) communication where the traditional > model of many-to-many group communication is either not possible or > not preferred. In addition, it can be applied to any group that > might benefit from a sender controlled summarised reporting > mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-03.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-rtcpssm-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-avt-rtcpssm-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > T.M. Eubanks Multicast Technologies, Inc. Phone : 703-293-9601 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Our New Multicast Workshop : http://www.multicasttech.com/workshop Test your network for multicast : http://www.multicasttech.com/mt/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 12:15:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29933 for ; Thu, 6 Mar 2003 12:15:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HQrE26308 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 12:26:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HQMO26093; Thu, 6 Mar 2003 12:26:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26H31O22472 for ; Thu, 6 Mar 2003 12:03:01 -0500 Received: from multicasttech.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27694; Thu, 6 Mar 2003 11:51:21 -0500 (EST) Received: from [68.100.8.94] (account marshall_eubanks HELO localhost) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1619205; Thu, 06 Mar 2003 11:52:35 -0500 Date: Thu, 6 Mar 2003 11:52:30 -0500 Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Internet-Drafts@ietf.org'" , avt@ietf.org To: "Allison, Art" From: Marshall Eubanks In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF1011351FC@mail.NAB.ORG> Message-Id: <053F05E3-4FF4-11D7-B81E-003065BA697E@multicasttech.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) 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 Dear Art; There is a working group for no-return path transport, UDLR http://www.ietf.org/html.charters/udlr-charter.html which includes multicast. How do these approaches compare ? How different is the ATSC work from the DVB standards ? There was I think a ip-dvb BOF in Atlanta, but I do not know if this will become a working group. Regards Marshall Eubanks On Thursday, March 6, 2003, at 11:01 AM, Allison, Art wrote: > Perhaps this post is not the most appropriate; but for some time I have > been > considering informing the experts here about the work done by the ATSC > to > address the problem of multicast when no return path is available. See > http://www.atsc.org/standards/a_92.pdf > > > Art > ::{) > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, March 06, 2003 10:45 AM > Cc: avt@ietf.org > Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working Group of > the > IETF. > > Title : RTCP Extensions for Single-Source Multicast > Sessions > with Unicase Feedback > Author(s) : J. Chesterfield, E. Schooler, J. Ott > Filename : draft-ietf-avt-rtcpssm-03.txt > Pages : 37 > Date : 2003-3-5 > > This document specifies a modification to the Real-time Transport > Control Protocol (RTCP) to use unicast feedback. The proposed > extension is useful for single source multicast sessions such as > Source Specific Multicast (SSM) communication where the traditional > model of many-to-many group communication is either not possible or > not preferred. In addition, it can be applied to any group that > might benefit from a sender controlled summarised reporting > mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-03.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-rtcpssm-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-avt-rtcpssm-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > T.M. Eubanks Multicast Technologies, Inc. Phone : 703-293-9601 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Our New Multicast Workshop : http://www.multicasttech.com/workshop Test your network for multicast : http://www.multicasttech.com/mt/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 13:06:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03730 for ; Thu, 6 Mar 2003 13:06:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IHSJ31791 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 13:17:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IDlO31464; Thu, 6 Mar 2003 13:13:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HKhO24790 for ; Thu, 6 Mar 2003 12:20:43 -0500 Received: from go4.ext.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29105 for ; Thu, 6 Mar 2003 12:09:05 -0500 (EST) Received: from dlep52.itg.ti.com ([157.170.134.103]) by go4.ext.ti.com (8.12.8/8.12.8) with ESMTP id h26H9jbE000656; Thu, 6 Mar 2003 11:09:45 -0600 (CST) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep52.itg.ti.com (8.12.6/8.12.6) with ESMTP id h26H9ivC026276; Thu, 6 Mar 2003 11:09:45 -0600 (CST) Received: from dlee70.itg.ti.com (dlee70.itg.ti.com [157.170.135.145]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA06242; Thu, 6 Mar 2003 11:09:44 -0600 (CST) Received: by dlee70.itg.ti.com with Internet Mail Service (5.5.2653.19) id <15JYXNMX>; Thu, 6 Mar 2003 11:07:53 -0600 Message-ID: From: "Jarrett, David" To: "'David A. Mcgrew'" Cc: avt@ietf.org Date: Thu, 6 Mar 2003 11:09:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E402.E13D7970" Subject: [AVT] RE: Status of SRTP 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2E402.E13D7970 Content-Type: text/plain David: Thanks for the info! I'll be looking forward to seeing the new draft. Can you comment on the sorts of changes under discussion? DWJ -----Original Message----- From: David A. Mcgrew [mailto:mcgrew@cisco.com] Sent: Thursday, March 06, 2003 10:47 AM To: Jarrett, David Cc: avt@ietf.org Subject: RE: Status of SRTP David, a new version will be coming out shortly, reflecting some discussion with the IESG. Thanks for pointing out that the current draft actually expired last December. It's been in IESG review for a while, and it has taken some time to settle on changes to the draft. We unintentionally let the document lapse. David M. -----Original Message----- From: Jarrett, David [mailto:djarrett@ti.com] Sent: Thursday, March 06, 2003 7:13 AM To: 'avt@ietf.org' Cc: 'mcgrew@cisco.com' Subject: Status of SRTP AVT group: What's the status of SRTP? It expired at the end of '02. Are there any plans for a new draft? DWJ --- David W. Jarrett Senior Technical Staff Broadband Solutions Texas Instruments djarrett@ti.com (408) 468-0830 ------_=_NextPart_001_01C2E402.E13D7970 Content-Type: text/html Status of SRTP

David:

 

Thanks for the info!  I'll be looking forward to seeing the new draft.  Can you comment on the sorts of changes under discussion? 

 

DWJ

 

-----Original Message-----
From: David A. Mcgrew [mailto:mcgrew@cisco.com]
Sent: Thursday, March 06, 2003 10:47 AM
To: Jarrett, David
Cc: avt@ietf.org
Subject: RE: Status of SRTP

 

David,

 

a new version will be coming out shortly, reflecting some discussion with the IESG.  Thanks for pointing out that the current draft actually expired last December.  It's been in IESG review for a while, and it has taken some time to settle on changes to the draft.  We unintentionally let the document lapse.

 

David M.

 

-----Original Message-----
From: Jarrett, David [mailto:djarrett@ti.com]
Sent: Thursday, March 06, 2003 7:13 AM
To: 'avt@ietf.org'
Cc: 'mcgrew@cisco.com'
Subject: Status of SRTP

AVT group:

What's the status of SRTP?  It expired at the end of '02.  Are there any plans for a new draft?

DWJ

---

David W. Jarrett        Senior Technical Staff

Broadband Solutions     Texas Instruments

djarrett@ti.com         (408) 468-0830

------_=_NextPart_001_01C2E402.E13D7970-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 13:06:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03745 for ; Thu, 6 Mar 2003 13:06:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26IHU831806 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 13:17:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IDtO31479; Thu, 6 Mar 2003 13:13:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HUgO27018 for ; Thu, 6 Mar 2003 12:30:42 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00312 for ; Thu, 6 Mar 2003 12:19:04 -0500 (EST) Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zcars04e.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26HKt324830; Thu, 6 Mar 2003 12:20:55 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26HKpX00339; Thu, 6 Mar 2003 17:20:51 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FS3MYMW7; Thu, 6 Mar 2003 17:20:51 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 17:20:46 -0000 Message-ID: <6B78F2524CD7D5118A0402204840075B01B1EFE9@zhard0jc.europe.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Dominic Walker" To: "'schulzrinne@cs.columbia.edu'" , "'scott.petrack@edial.com'" Cc: "'avt@ietf.org'" , "'Stephen Casner'" , "'csp@isi.edu'" Date: Thu, 6 Mar 2003 17:20:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E404.B996EE96" Subject: [AVT] When will draft-ietf-avt-rfc2833bis be re-published 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2E404.B996EE96 Content-Type: text/plain; charset="iso-8859-1" Dear Mr. Shulzrinne and Mr. Petrack, I understand that your submitted draft document "draft-ietf-avt-rfc2833bis-02 " was discussed at the IETF meeting in Atlanta, resulting in some changes to be made. I am interested in finding out when do you plan in resubmitting an ubdated version to be discussed in the next IETF meeting. Regards, Dominic Walker Nortel Networks Tel: +44 (0)1279 403379 ------_=_NextPart_001_01C2E404.B996EE96 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When will draft-ietf-avt-rfc2833bis be re-published

Dear Mr. Shulzrinne and Mr. = Petrack,

I understand that your submitted draft = document "draft-ietf-avt-rfc2833bis-02 " was = discussed  at the IETF = meeting in Atlanta, resulting in some changes to be made. I am = interested in finding out when do you plan in resubmitting an ubdated = version to be discussed in the next IETF meeting.

Regards,
Dominic Walker
Nortel Networks
Tel: +44 (0)1279 403379

 

------_=_NextPart_001_01C2E404.B996EE96-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 13:24:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04773 for ; Thu, 6 Mar 2003 13:24:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Ia7P00708 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 13:36:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IVvO00437; Thu, 6 Mar 2003 13:31:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IUGO00331 for ; Thu, 6 Mar 2003 13:30:16 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04496 for ; Thu, 6 Mar 2003 13:18:36 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26IKcPS017341; Thu, 6 Mar 2003 10:20:38 -0800 (PST) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AET02143; Thu, 6 Mar 2003 10:15:24 -0800 (PST) From: "David A. Mcgrew" To: "Jarrett, David" Cc: Date: Thu, 6 Mar 2003 10:20:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1935_01C2E3CA.070285E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Subject: [AVT] RE: Status of SRTP 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_1935_01C2E3CA.070285E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Status of SRTPDavid, -----Original Message----- From: Jarrett, David [mailto:djarrett@ti.com] Sent: Thursday, March 06, 2003 9:10 AM To: 'David A. Mcgrew' Cc: avt@ietf.org Subject: RE: Status of SRTP David: Thanks for the info! I'll be looking forward to seeing the new draft. Can you comment on the sorts of changes under discussion? I'll send out a detailed list of changes to the AVT list shortly. The changes are mostly to strengthen the defaults and to make more clear the circumstances under which null authentication is acceptable. DAM DWJ -----Original Message----- From: David A. Mcgrew [mailto:mcgrew@cisco.com] Sent: Thursday, March 06, 2003 10:47 AM To: Jarrett, David Cc: avt@ietf.org Subject: RE: Status of SRTP David, a new version will be coming out shortly, reflecting some discussion with the IESG. Thanks for pointing out that the current draft actually expired last December. It's been in IESG review for a while, and it has taken some time to settle on changes to the draft. We unintentionally let the document lapse. David M. -----Original Message----- From: Jarrett, David [mailto:djarrett@ti.com] Sent: Thursday, March 06, 2003 7:13 AM To: 'avt@ietf.org' Cc: 'mcgrew@cisco.com' Subject: Status of SRTP AVT group: What's the status of SRTP? It expired at the end of '02. Are there any plans for a new draft? DWJ --- David W. Jarrett Senior Technical Staff Broadband Solutions Texas Instruments djarrett@ti.com (408) 468-0830 ------=_NextPart_000_1935_01C2E3CA.070285E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status of SRTP
David,
-----Original Message-----
From: Jarrett, David=20 [mailto:djarrett@ti.com]
Sent: Thursday, March 06, 2003 9:10 = AM
To: 'David A. Mcgrew'
Cc:=20 avt@ietf.org
Subject: RE: Status of = SRTP

David:

 

Thanks for = the=20 info!  I'll be looking forward to seeing the new draft.  Can = you=20 comment on the sorts of changes under discussion?   

 

I'll send out a = detailed list of=20 changes to the AVT list shortly.  The changes are = mostly to=20 strengthen the defaults and to make more clear the circumstances under = which=20 null authentication is acceptable.  =

 

DAM

 

DWJ

 

-----Original=20 Message-----
From: = David A.=20 Mcgrew [mailto:mcgrew@cisco.com]
Sent: Thursday, March 06, 2003 = 10:47=20 AM
To: Jarrett,=20 David
Cc:=20 avt@ietf.org
Subject: RE:=20 Status of SRTP

 

David,

 

a new=20 version will be coming out shortly, reflecting some discussion with = the=20 IESG.  Thanks for pointing out that the current draft actually = expired=20 last December.  It's been in IESG review for a while, and it has = taken=20 some time to settle on changes to the draft.  We unintentionally = let the=20 document lapse.

 

David=20 M.

 

-----Original=20 Message-----
From: Jarrett,=20 David [mailto:djarrett@ti.com]
Sent: Thursday, March 06, = 2003 7:13=20 AM
To:=20 'avt@ietf.org'
Cc:=20 'mcgrew@cisco.com'
Subject:=20 Status of SRTP

AVT = group:

What's the status of = SRTP? =20 It expired at the end of '02.  Are there any plans for a new=20 draft?

DWJ

---

David W.=20 Jarrett        Senior Technical=20 Staff

Broadband=20 Solutions     Texas = Instruments

djarrett@ti.com        =20 (408) = 468-0830

------=_NextPart_000_1935_01C2E3CA.070285E0-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 6 13:37:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05285 for ; Thu, 6 Mar 2003 13:37:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26ImJV02220 for avt-archive@odin.ietf.org; Thu, 6 Mar 2003 13:48:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IlmO02120; Thu, 6 Mar 2003 13:47:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Ie5O01717 for ; Thu, 6 Mar 2003 13:40:05 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04915 for ; Thu, 6 Mar 2003 13:28:26 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h26IUFNq012077 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Mar 2003 13:30:17 -0500 (EST) Message-ID: <3E6793C2.1010503@cs.columbia.edu> Date: Thu, 06 Mar 2003 13:30:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dominic Walker CC: "'schulzrinne@cs.columbia.edu'" , "'scott.petrack@edial.com'" , "'avt@ietf.org'" , "'Stephen Casner'" , "'csp@isi.edu'" References: <6B78F2524CD7D5118A0402204840075B01B1EFE9@zhard0jc.europe.nortel.com> In-Reply-To: <6B78F2524CD7D5118A0402204840075B01B1EFE9@zhard0jc.europe.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: When will draft-ietf-avt-rfc2833bis be re-published 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 Unfortunately, I didn't quite get around to issuing a revised version before the deadline. I hope to do this shortly after the IETF. There have been no major changes, just minor edits. I'm also still looking for people that can disentangle the in-band-signaling-tone mess (CAS/MF), as I'm pretty sure that the current text is neither correct nor complete, but I don't have the right resources to fix them. Dominic Walker wrote: > Dear Mr. Shulzrinne and Mr. Petrack, > > I understand that your submitted draft document > "draft-ietf-avt-rfc2833bis-02 " was discussed at the IETF meeting in > Atlanta, resulting in some changes to be made. I am interested in > finding out when do you plan in resubmitting an ubdated version to be > discussed in the next IETF meeting. > > Regards, > Dominic Walker > Nortel Networks > Tel: +44 (0)1279 403379 > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 01:05:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00864 for ; Fri, 7 Mar 2003 01:05:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h276H9X07780 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 01:17:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h276FTO07648; Fri, 7 Mar 2003 01:15:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h276DjO07530 for ; Fri, 7 Mar 2003 01:13:45 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00759 for ; Fri, 7 Mar 2003 01:01:52 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.3) with ESMTP id h2763s65000383; Thu, 6 Mar 2003 22:03:55 -0800 (PST) (envelope-from casner@acm.org) Date: Thu, 6 Mar 2003 22:06:42 -0800 (PST) From: Stephen Casner To: "Jarrett, David" cc: "'avt@ietf.org'" , "'mcgrew@cisco.com'" Subject: Re: [AVT] Status of SRTP In-Reply-To: Message-ID: <20030306220554.V70312-100000@oak.packetdesign.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 Thu, 6 Mar 2003, Jarrett, David wrote: > AVT group: > > What's the status of SRTP? It expired at the end of '02. Are there any > plans for a new draft? Documents under IESG review do not expire, even if the expiration date on the title page passes. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 07:24:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25118 for ; Fri, 7 Mar 2003 07:24:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Ca8E18760 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 07:36:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CXdO18584; Fri, 7 Mar 2003 07:33:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CChO17153 for ; Fri, 7 Mar 2003 07:12:43 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22793 for ; Fri, 7 Mar 2003 07:00:42 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27C2Twx001896; Fri, 7 Mar 2003 13:02:30 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 7 Mar 2003 13:02:29 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Adam Li Cc: Ietf-Avt Subject: RE: [AVT] File format for EVRC/SMV vocoder Date: Fri, 7 Mar 2003 12:58:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: , Adam and others, I thought the reason for defining also the file format in the IETF was to make it in line with the transport format, and also because you would get it almost "for free" when you define the transport format. The proposed new approach seems to take away those motives, and then I do not understand why we should do it in the IETF. Further, I wonder what would be the rationales for using this new QCP format instead of the file format defined in the EVRC/SMV draft? If we are to standardize a file format in this body, I can not see why we should not stick to the format that is already finalized and has been taken through our standards process. /L-E > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > > Adam > I have a question: Why take a file format specification > through the IETF? > > Best regards, Mark _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 09:59:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07678 for ; Fri, 7 Mar 2003 09:58:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FAXJ01629 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 10:10:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F7WO01284; Fri, 7 Mar 2003 10:07:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F3YO32650 for ; Fri, 7 Mar 2003 10:03:34 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06683 for ; Fri, 7 Mar 2003 09:51:28 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h27ErTB3016135 for ; Fri, 7 Mar 2003 15:53:29 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPHZW6ZS; Fri, 7 Mar 2003 15:53:29 +0100 Message-ID: <3E68B269.7010506@era.ericsson.se> Date: Fri, 07 Mar 2003 15:53:29 +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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-01.txt References: <200303061124.GAA02179@ietf.org> 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. I have a number of comments on this draft. Most are structure and clarification request comments. 1. The short copyright statement is missing from the first page. See ID-Nits http://www.ietf.org/ID-nits.html. 2. The two first pages length is not of the appropriate length. 3. The footer and header is very crowed as the running text uses the lines directly after and before. To make this more readable and separate page header and footer from text please leave on empty line between them and the running text on all pages. 4. I would recommend that you move the changes chapter to last in the draft and do not include it in the table of contents. That way you can include it with a note to the RFC editor to remove this section and keep it being used until the draft is approved. 5. All figures and table are missing number and all references are either xxxx or xxx for figures respectively tables. 6. Chapter 6.1: The extension bit in the RTP header, shouldn't that also be used according to RFC 1889 and profile definitions instead of only the profile? 7. Chapter 6.1: Payload Type. I think that one can use a better language in this explanation. I especially object to the use of the word expected. In accordance with today's understanding the text could read: "The assignment of a payload type needs to be performed either through the profile used or in a dynamic way.". 8. Chapter 6.2 I think one can clarify the language in the first paragraph. I would also like to rename it simple payload as this format are after all only a RTP payload. Old text: The RTP payload of a Simple Packet according to this specification consists of one NALU as depicted in Figure xxxx. The type of the NALU MUST be specified in [1], i.e., the NALU MUST NOT be an aggregation packet or a fragmentation unit. A NAL unit stream composed by decapsulating Simple Packets in RTP sequence number order MUST conform to the NAL unit decoding order. New text proposal: The simple payload defined here MUST contain one and only one NALU of the types defined in [1]. This means that neither an aggregation payload or a fragmentation payload can be used. A NAL unit stream composed by decapsulating Simple Packets in RTP sequence number order MUST conform to the NAL unit decoding order. The simple payload is shown in figure xxxx. 9. Figure in 6.2: For clarification would it not be better to to show a RTP header before it: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Single NALU | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure xxxx. RTP payload format for Simple Packet. 10. Chapter 6.3 I have some concerns about the figure structure in this and the following sub chapters. Combined with the text the complete picture is not clear. Either you rename the text that says NALU payload to something clearer or you change the headings of the following sub chapters to include NALU payload instead of packet in their titles. 11. Chapter 6.3 The use of the F bit for aggregated units. Is it really wise to set this bit as bad as soon as any of the NALUs part of the aggregate is bad. This is useless information because you still needs to go into the packet an look at each NALU to determine which is actually useful. A cheap implementation that just throws away NALUs which is damaged can't use this flag anyway. It could be useful it the flag is instead defined as: "The F bit MUST only be set if all NALUs part of the aggregate has their F bit set". That way the cheap implementation can throw the whole packet as soon as it looks at the first bit. 12. Chapter 6.3.1: The DON text paragraph. First it is a very heavy section of text please look if you could break it into more paragraphs. A empty line before the numbered list would also be good. Secondly there is a strange thing in the text that determine if D1 is before D2 or not. " or if D1 > D2 and D1 . D2 >= 32768, then NAL unit ..." the "D1 . D2" should probably be "D1 - D2" or? 13. To clarify how a complete STAP RTP payload looks a example of this should be provided. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAP NAL HDR | DON | NALU 1 Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU 1 Size | NALU 1 HDR | NALU DATA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NALU 2 SIZE | NALU 2 HDR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU Data | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This would be a nice figure in the end of chapter 6.3.1 with a simple text declaring it to be STAP RTP packet with two NALU. 14. Chapter 6.3.2: Second paragraph. There is missing text about the use of modular arithmetic. The text says: "DON of the following NALU is equal to DONB + DOND and MUST NOT be larger than 65535." Shouldn't this text say that the DON of the NALU is (DONB+DOND) mod 65535. 15. Chapter 6.3.2: Second paragraph at the end. I think the text declaring how the timestamp shall be calculated is written to informative. The text should be more normative and clearly state how it shall be calculated. 16. At the end of the chapter 6.3.2 I think a complete example should be shown containing all fields from RTP header to the end. You can never have to many examples as long as they are correct. 17. Chapter 6.4: I think this chapter is missing some text on the considerations to make in regards to using FU payloads. What is the advantage over IP fragmentation? What is the drawbacks? I am also missing the packetization rules for this format. Even if I later found them in the next chapter. I think that the rules directly applicable to FU should be part of this chapter. Otherwise it is hard to understand that this works. The rules I am talking about is: "Fragments of the same NALU MUST be sent in consecutive order with no other RTP packets sent between the first and last fragment" and "Fragments SHALL be reassembled in RTP sequence number order." 18. Chapter 7.1: Is the rules for how simple packets shall relate to aggregated packets necessary? Isn't this already covered by bullet number 2? 19. Chapter 71. The bullet that start with "An Aggregation Packet MUST succeed a Fragmentation Unit in transmission order if the NAL units in the Simple Packet precede the NAL unit conveyed in the Fragmentation Unit in NAL unit decoding order. " Halfway through this sentence there is a simple packet, shouldn't that be fragment packet. 20. Chapter 8. These depacketization rules seems to not to take possible packet losses into account. For example: "If the receiver buffer contains at least N VCL NAL units, NAL units are removed from the receiver buffer and passed to the decoder in the order specified below until the buffer contains N-1 VCL NAL units." The quoted sentence clearly does not take packet loss resulting in lost NAL units. 21. Chapter 9.1."Profile-interoperability". These parameters are they often set in either direction. If that is the case I would see that declaring a default value and then spilt out each capability into its own parameter. Also the name is a bit long. 22. Chapter 9.1: "num-reorder-vcl-NAL-units". First why not rename it to "interleaving-depth" because this is what this parameter is about. Secondly the language about the default is strange. The sentence "If the parameter is not present, num-reorder-VCL-NAL-units equal to 0 MUST be implied." it seems very unsure even though a MUST is used. I would formulate it more like "If the parameter is not present the the value of num-reorder-vcl-NAL-units MUST be set to 0". 23. Chapter 9.1: "aggregation-mode" I would rename this parameter to what it really represents namely the use of unrestricted mode. Aggregation is still possible in restricted mode and therefore the present parameter name is not good. My proposal is "unrestricted". If value is 1 the unrestricted mode MAY be used. If not present the value MUST be set to 0. A value of 0 MUST only use restricted mode functionality. 24. Chapter 9.1 Required parameter. The RTP timestamp rate parameter is missing. I think it is a required parameter unless it is possible to hard code it to a single value. 25. Chapter 9.2: The second bullet about encoding name. It is missing text that the RTP timestamp rate shall also be part of the "a=rtpmap" line 26. Chapter 10: One standard thing that usually is part of the security consideration is if the codec shows any non-linear behavior. If one knows that switching a single bit in a NALU will result in that the processing requirements becomes the double or more this should be expressed. 27. Chapter 14. The correct IETF IPR text is not present. See ID nits: From RFC 2026 sec 10.4 (A) and 10.4(B) and possibly 10.4(D) Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 10:05:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08336 for ; Fri, 7 Mar 2003 10:05:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FH9W02454 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 10:17:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FElO02058; Fri, 7 Mar 2003 10:14:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27F6nO00552 for ; Fri, 7 Mar 2003 10:06: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 JAA07327; Fri, 7 Mar 2003 09:54:44 -0500 (EST) Message-Id: <200303071454.JAA07327@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: Fri, 07 Mar 2003 09:54:44 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-uxp-05.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 : An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams Author(s) : G. Liebl et. al. Filename : draft-ietf-avt-uxp-05.txt Pages : 25 Date : 2003-3-6 This document specifies an efficient way to ensure erasure- resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon (RS) codes together with interleaving. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Nevertheless, backward compatibility to currently standardized non-progressive multimedia codecs is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By applying interleaving and RS codes a payload format is defined, which can be easily integrated into the existing framework for RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-uxp-05.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-uxp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-uxp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6180139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-uxp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-uxp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6180139.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 11:05:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12576 for ; Fri, 7 Mar 2003 11:05:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27GHFF08241 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 11:17:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GEvO08157; Fri, 7 Mar 2003 11:14:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27GDKO08098 for ; Fri, 7 Mar 2003 11:13:20 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12511 for ; Fri, 7 Mar 2003 11:01:16 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h27G3Kk28042; Fri, 7 Mar 2003 11:03:20 -0500 Message-Id: <200303071603.h27G3Kk28042@chiron.nge.isi.edu> To: avt@ietf.org cc: casner@acm.org Date: Fri, 07 Mar 2003 11:03:20 -0500 From: Colin Perkins Subject: [AVT] Updated agenda for San Francisco meeting 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: , A couple of minor updates, mostly fixing draft version numbers. Once again, please send any comments and corrections to the chairs. Colin ------------------------------------------------------------------------------- Audio/Video Transport Working Group CHAIRS: Steve Casner Colin Perkins Wednesday, 19th March at 13:00-15:00 ==================================== Introduction and status update (Casner/Perkins) 15 draft-ietf-avt-rtp-new-12.txt draft-ietf-avt-profile-new-13.txt draft-ietf-avt-uxp-05.txt draft-ietf-avt-ulp-07.txt (Under revision) draft-ietf-avt-tcrtp-07.txt draft-ietf-avt-rtp-retransmission-06.txt draft-ietf-avt-rtcp-feedback-05.txt draft-ietf-avt-rtcp-feedback-sim-01.txt draft-ietf-avt-crtp-enhance-07.txt (IETF last call) draft-ietf-avt-rtcp-bw-05.txt (RFC Editor) draft-ietf-avt-rtp-mime-06.txt (RFC Editor) draft-ietf-avt-dsr-05.txt (RFC Editor) draft-ietf-avt-evrc-smv-03.txt (RFC Editor) See also draft-garudadri-qcp-00.txt RFC 3497 The Secure Real-time Transport Protocol 15 draft-ietf-avt-srtp-05.txt Framing RTP over Connection-Oriented Transport (Lazzaro) 15 draft-lazzaro-avt-rtp-framing-contrans-00.txt RTP Extended Reports (RTP XR) (Friedman/Clark) 15 draft-ietf-avt-rtcp-report-extns-03.txt RTCP Extensions for SSM with unicast feedback (Chesterfield) 15 draft-ietf-avt-rtcpssm-03.txt RTP Payload Format for JVT Video (Wenger) 15 draft-ietf-avt-rtp-h264-01.txt RTP Payload Format for uncompressed video (Gharai) 15 draft-ietf-avt-uncomp-video-02.txt Thursday, 20th March at 09:00-11:30 =================================== RTP Payload Format for a 64 kbit/s transparent call (Kreuter) 15 draft-kreuter-avt-rtp-clearmode-02.txt See also the TDM emulation work in the PWE3 working group The MIDI Wire Protocol Packetization (MWPP) (Lazzaro) 15 draft-ietf-avt-mwpp-midi-rtp-06.txt draft-lazzaro-avt-mwpp-coding-guidelines-02.txt RTP Payload Format for ATRAC-X (Romaine) 15 draft-hatanaka-avt-rtp-atracx-01.txt RTP Payload Format for iLBC Speech (Duric) 15 draft-ietf-avt-rtp-ilbc-01.txt draft-ietf-avt-ilbc-codec-01.txt RTP Payload Format for the Speex Codec (Herlein) 15 draft-herlein-speex-rtp-profile-00.txt RTP Payload Format for RGL Codec (Ramalho) 15 draft-ramalho-rgl-desc-01.txt draft-ramalho-rgl-rtpformat-01.txt RTP Payload Format for ETSI ES 202 050 DSR (Xie) 15 draft-xie-avt-dsr-es202050-00.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 11:29:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14651 for ; Fri, 7 Mar 2003 11:29:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27GepG10734 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 11:40:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Gb6O09610; Fri, 7 Mar 2003 11:37:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Ga6O09493 for ; Fri, 7 Mar 2003 11:36:06 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14203 for ; Fri, 7 Mar 2003 11:24:01 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id C4A6E4CFF0; Fri, 7 Mar 2003 11:26:00 -0500 (EST) Received: from research.att.com ([135.207.253.87]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA12142; Fri, 7 Mar 2003 11:25:43 -0500 (EST) Message-ID: <3E68C817.4030303@research.att.com> Date: Fri, 07 Mar 2003 11:25:59 -0500 From: Eric Cheung Organization: AT&T Labs Research User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Cheung Cc: schulzrinne@cs.columbia.edu, scott.petrack@edial.com, avt@ietf.org Subject: Re: [AVT] Question on RTP sequence number in RFC2833 and bis-02 References: <3E5CB17B.2010805@research.att.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, I am still hoping that I can get some clarification from the WG on this question. Apologies if this was discussed before, but I could not find anything by searching on the archive. Thanks Eric Eric Cheung wrote: > Hi Henning, Scott > > Want to clarify a fine point. > > In RFC2833: > > If there has been no new event > in the last interval, the event SHOULD be retransmitted three times > or until the next event is recognized. > > Q1: For a device conforming to RFC2833, should the RTP sequence number > in the 3 packets be incremented, or should they be the same? > > > In RFC2833bis-02, this seems to be clarified: > > If an event has ended and > there has been no new event in the last interval, the event SHOULD be > retransmitted three times at the interval used by the source for > updates. > > In all cases, the RTP sequence number MUST be incremented by one in > each RTP packet. > > Q2: Can you confirm that if a device conforms to bis-02, the sequence > number in the 3 packets will be monotonically increasing? > > Q3: In writing this, I realize that I am not sure whether there should > be 4 packets (1 original transmission + 3 retransmission) or 3 packets. > Can you clarify this? > > > Sorry for the nit-picking, but when testing it seems many devices do > many different things when it comes to 2833. > > Thanks > Eric _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 12:10:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17306 for ; Fri, 7 Mar 2003 12:10:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HMUk15245 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 12:22:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HJhO14757; Fri, 7 Mar 2003 12:19:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HD3O13772 for ; Fri, 7 Mar 2003 12:13:03 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16638 for ; Fri, 7 Mar 2003 12:00:57 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h27H32628763; Fri, 7 Mar 2003 12:03:02 -0500 Message-Id: <200303071703.h27H32628763@chiron.nge.isi.edu> To: avt@ietf.org cc: casner@acm.org Date: Fri, 07 Mar 2003 12:03:02 -0500 From: Colin Perkins Subject: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) 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 to announce a working group last call on the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) (draft-ietf-avt-rtcp-feedback-05.txt), and simulation results (draft-burmeister-avt-rtcp-feedback-sim-01.txt). Please send any final comments on this work to the mailing list by 19th March 2003. If no substantive technical comments are received by this time, we propose to submit the profile to the IESG for publication as a Proposed Standard RFC, and the simulation results for publication as an Informational RFC. Thanks, Steve and Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 12:14:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17599 for ; Fri, 7 Mar 2003 12:14:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HPsY15725 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 12:25:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HN9O15381; Fri, 7 Mar 2003 12:23:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HLnO14923 for ; Fri, 7 Mar 2003 12:21:49 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17149 for ; Fri, 7 Mar 2003 12:09:43 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h27HCeqR007223 for ; Fri, 7 Mar 2003 10:12:40 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA24903 for ; Fri, 7 Mar 2003 10:09:53 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id WD6NXGYN; Fri, 7 Mar 2003 11:11:46 -0600 Message-ID: <3E68D2E0.794A5341@motorola.com> Date: Fri, 07 Mar 2003 11:12:00 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] Agenda for San Francisco meeting References: <200303050059.h250xR011387@chiron.nge.isi.edu> 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 > RTP Payload Format for ETSI ES 202 050 DSR (Xie) 15 > draft-xie-avt-dsr-es202050-00.txt > Hi, all, This draft is a follow-up to draft-ietf-avt-dsr-05.txt (which has passed IESG and currently in the RFC Editor's queue for an RFC #). The difference is that this new draft specifies a 2nd front-end encoding scheme published by ETSI in its ES202050 (the previous DSR draft defines RTP payload format for ES201108). I'd appreciate your comments on this new draft. -Qiaobing _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 15:22:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27480 for ; Fri, 7 Mar 2003 15:22:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KYBw03838 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 15:34:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KV3O03615; Fri, 7 Mar 2003 15:31:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KSqO03419 for ; Fri, 7 Mar 2003 15:28:52 -0500 Received: from smtp01.mrf.mail.rcn.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27204 for ; Fri, 7 Mar 2003 15:16:41 -0500 (EST) X-Info: This message was accepted for relay by smtp01.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVZ+pEmxfU0C7NqqtBJfbI8y/u+pTlW9k7TxMSvQeohTcbNmWbcuRvuA Received: from sense-sea-focal-dynamic-10-16.oz.net ([216.39.143.80] helo=erols.com) by smtp01.mrf.mail.rcn.net with asmtp (Exim 3.35 #4) id 18rOIn-0003IC-00; Fri, 07 Mar 2003 15:18:45 -0500 Message-ID: <3E68FE81.909D2CF1@erols.com> Date: Fri, 07 Mar 2003 12:18:09 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: avt@ietf.org, Ladan Gharai Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt 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 Philippe, all, philippe.gentric@philips.com wrote: > > Hi all, > > I concur with chuck, this is looking very good indeed. > [...] > > Unfortunately the tables 1 thru 4 do not explicitely mention any RGB or RGBA format(!) > > I think it would be useful to add them, here are the tables > (not sure the notation R:G:B is appropriate, anyway "RGB" is > what is declared in the mime type ...) [...] I had assumed that the conjunction of color-mode = RGB and sub-sampling = 4:4:4 would describe this. Thus the tables 1 thru 4 would not require additional entries distinguishing one color- mode from another. As you say, the tables could use a legend/explanation. I think this could be clarified there. While we're on color specs, how about this, to encourage *complete* color specifications: ---- 6.2. Parameter Registration New values of the "colorimetry" parameter MAY be registered with the IANA provided they reference an RFC or other permanent and readily available specification (the Specification Required policy of RFC 2434 [2434]). New registrations SHOULD define all parameters of a color image encoding as described in [22028]. ---- Note: ISO 22028-1 is still in ballot with TC42 for another few days but I am hopeful that it will be adopted by the time this internet- draft reaches IESG. If anyone is interested in the contents of 22028-1 please contact me off list. Cheers, Chuck Harrison Far Field Associates, LLC _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 15:35:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29394 for ; Fri, 7 Mar 2003 15:35:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Kl9Z05784 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 15:47:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KieO05637; Fri, 7 Mar 2003 15:44:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KhbO05496 for ; Fri, 7 Mar 2003 15:43:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27965; Fri, 7 Mar 2003 15:31:25 -0500 (EST) Message-Id: <200303072031.PAA27965@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: Fri, 07 Mar 2003 15:31:25 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-ilbc-codec-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: , --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 : Internet Low Bit Rate Codec Author(s) : S. Andersen et al. Filename : draft-ietf-avt-ilbc-codec-01.txt Pages : 175 Date : 2003-3-7 This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ilbc-codec-01.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-ilbc-codec-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-ilbc-codec-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-ilbc-codec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-ilbc-codec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143347.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 15:37:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29734 for ; Fri, 7 Mar 2003 15:37:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KnCk05924 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 15:49:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KkoO05758; Fri, 7 Mar 2003 15:46:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KhfO05500 for ; Fri, 7 Mar 2003 15:43:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27983; Fri, 7 Mar 2003 15:31:30 -0500 (EST) Message-Id: <200303072031.PAA27983@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: Fri, 07 Mar 2003 15:31:30 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ilbc-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for iLBC Speech Author(s) : A. Duric, S. Andersen Filename : draft-ietf-avt-rtp-ilbc-01.txt Pages : 10 Date : 2003-3-7 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-01.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-ilbc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-ilbc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7143403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-ilbc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-ilbc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143403.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 15:39:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00099 for ; Fri, 7 Mar 2003 15:39:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KpSC06104 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 15:51:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KmrO05915; Fri, 7 Mar 2003 15:48:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KhkO05505 for ; Fri, 7 Mar 2003 15:43:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28001; Fri, 7 Mar 2003 15:31:35 -0500 (EST) Message-Id: <200303072031.PAA28001@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: Fri, 07 Mar 2003 15:31:35 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-new-13.txt,.ps 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 : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne, S. Casner Filename : draft-ietf-avt-profile-new-13.txt,.ps Pages : 45 Date : 2003-3-7 This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards- compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-13.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-profile-new-13.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-profile-new-13.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-3-7151243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7151243.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 15:41:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00262 for ; Fri, 7 Mar 2003 15:41:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KrGW06265 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 15:53:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KovO06075; Fri, 7 Mar 2003 15:50:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KhoO05543 for ; Fri, 7 Mar 2003 15:43:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28022; Fri, 7 Mar 2003 15:31:39 -0500 (EST) Message-Id: <200303072031.PAA28022@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: Fri, 07 Mar 2003 15:31:39 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-new-12.txt,.ps 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 : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-new-12.txt,.ps Pages : 107 Date : 2003-3-7 This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-12.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-new-12.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-new-12.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-3-7143423.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7143423.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 17:13:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09418 for ; Fri, 7 Mar 2003 17:13:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27MPUv19061 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 17:25:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MMpO18879; Fri, 7 Mar 2003 17:22:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27ML1O18770 for ; Fri, 7 Mar 2003 17:21:01 -0500 Received: from hafez.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08884 for ; Fri, 7 Mar 2003 17:08:49 -0500 (EST) Received: from hafez (ladan@localhost) by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h27MAqn07757; Fri, 7 Mar 2003 17:10:52 -0500 Message-Id: <200303072210.h27MAqn07757@hafez.nge.isi.edu> To: Colin Perkins , avt@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt In-Reply-To: Your message of "Wed, 05 Mar 2003 20:47:37 EST." <200303060147.h261lbdk005611@purple.nge.isi.edu> Date: Fri, 07 Mar 2003 17:10:52 -0500 From: Ladan Gharai 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: , Hello Chuck, please see some additional comments in line: thanx, L. > Hi, > > Thanks for the comments. A couple of replies inline. > > --> Chuck Harrison writes: > > > >A few comments on this draft, which is looking very good so far. > > > >--- > >In uncomp-video-02 we have: > > > >4.3. Payload Data > > > >Depending on the video format, each RTP packet can include either a > >single complete scan line, a single fragment of a scan line, or one > >(or > >more) complete scan lines plus a fragment of a scan line. [...] > > > > > >I think there are additional logical possibilities allowed by > >the document as it stands: a packet may begin with the tail > >fragment of a line, then continue with 0 or more full lines, and > >possibly the head fragment of another line. > > > >If the intent is to exclude these possibilities, we need normative > >language to say so. If these operational modes are permitted, the > >quoted text above is misleading and should be amended. > > Those modes are permitted, so I guess we need to clarify the text. Can you > suggest some wording? Yes - the draft does not mean to list all possible combinations. Basically anything goes, as long the information in the payload header (offset and scan lines#) can be used to place the data in its frame. Perhaps the wording can be changed to: Depending on the video format, each RTP packet can include multiple scan lines and fragments of scan lines. > > >--- > >On page 3 of the draft, we have > > > >[...] This payload format > >requires that applications using such synchronized ancillary data MUST > >deliver it in separate RTP sessions which operate concurrently with > >the > >video session. The normal RTP mechanisms SHOULD be used to > >synchronize > >the media. > > > >I believe the MUST is inappropriate and SHOULD is preferable. > > > >The idea that frame-accurate timecode will be carried as a > >parallel RTP session is a laudable but forward-looking conjecture. > >IMHO reliable use of this payload format in the near future > >will depend on carriage of vertical interval timecode (VITC) > >in an unused scan line which is part of the vertical blanking > >interval. (This is normal video operational practice, as > >mentioned in RFC 2431.) > > > >At the top of page 2 of the draft, we have "...the contents of > >horizontal and vertical blanking SHOULD NOT be transported." This > >does not bother me as SHOULD NOT language does not prevent me from > >carrying VITC when I need it, until the multisession RTP sync > >issues get ironed out. On the other hand the MUST language of > >page 3 is burdensome. > > I'm still not convinced that an additional timecode is necessary: it should > be derivable from the RTP timestamp and RTCP SR packets. Accordingly if you > wish to synchronize the video to another source, you should use the normal > RTCP method, rather than sending an additional timecode stream (indeed, if > you use RTSP, I _think_ there is already a mapping function between the RTP > timestamp and SMPTE timecode). I guess the big questions in this regard is can the timecode be derived from RTP timestamp and RTCP SR packets without any loss of information? and how will this impact the interval for sending RTCP SR packets? > > >--- > > > >A minor MUST/SHOULD nit at sec. 4.3 regarding filling to a pgroup > >boundary: since a receiver MUST ignore the fill data, it seems > >unneccessary that the sender MUST fill with zeroes, specifically. > >The sender MUST fill, and SHOULD fill with zeroes. > > > > Okay. Is there a reason why zero fill doesn't work? > > >--- > > > >The MIME and SDP parametersdo not include the video frame rate. > >There are many plausible scenarios in which it is important > >to distinguish alternative frame rates. For example, choosing > >the right VOD stream during RTSP setup would need something like > >this. > > You can use the SDP "a=framerate:" attribute, defined in RFC 2327. > > Cheers, > Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 17:15:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09524 for ; Fri, 7 Mar 2003 17:15:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27MRTN19149 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 17:27:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MP3O19045; Fri, 7 Mar 2003 17:25:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MLUO18777 for ; Fri, 7 Mar 2003 17:21:30 -0500 Received: from hafez.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08917 for ; Fri, 7 Mar 2003 17:09:17 -0500 (EST) Received: from hafez (ladan@localhost) by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h27MBKT07767; Fri, 7 Mar 2003 17:11:20 -0500 Message-Id: <200303072211.h27MBKT07767@hafez.nge.isi.edu> To: philippe.gentric@philips.com, avt@ietf.org, cfharr@erols.com Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt In-Reply-To: Your message of "Thu, 06 Mar 2003 11:45:54 +0100." Date: Fri, 07 Mar 2003 17:11:20 -0500 From: Ladan Gharai 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: , Hello Philippe - thank you for your comments. Please see reponses inline. Ladan > Hi all, > > I concur with chuck, this is looking very good indeed. > > Just a few remarks > > ***************************** > I am not sure I always understand the "pixels" and "#words" second and third column in the tables ? Pixels refer to the smallest number of pixels a related of subsamples represent, so for example for 4:4:4 Cb-Y-Cr cover 1 pixel whereas for 4:2:2 Cb0-Y0-Cr0-Y1 covers 2 pixels. #words, on the other hand expresses the number of words used to represent those pixels: so for 4:4:4 requires 3 words Cb-Y-Cr and 4:2:2 needs 4 words Cb0-Y0-Cr0-Y1 > For exemple for monochrome 10 bits pixels is "4" so that would hint it means "number of pixels per Pgroup" It seems to me now that "number of pixels per Pgroup" would be a more intuitive way to look at pgroup - however pgroup is actually the number of bytes need to represent the least number of pixels, while being both byte aligned and observing ALF. thats why, for the 10bit and 12bit tables, the two last columns #samples and pgroup, dont agree, whereas they agree for the 8bit table. > But then the next line is "4" for 4:1:1 while there are 8 pixels per Pgroup? so what that means is that the smallest group of related samples for a 4:1:1 subsampling is 4 pixels p0 p1 p4 p3 represented as Cb0-Y0-Y1-Cr0-Y2-Y3, this is 6 samples, which with 10bit words, align after 12 samples, or 15 octets - which is representing 8 pixels. > Also the #words is 6x10, but these are actually "bits" rather than "words"? true - its 6 words of 10 bits each. > I think these tables would benefit a few sentences giving the exact definition of each column. I couldn't agree more. The tables have acquired a life of their own. I hope my explanations have helped to clarify somewhat. > > ***************************** > The 8 bit words tables probably contains a typo for the "octet alignement" of Interlaced 4:2:0 which should be "4 x8/8 = 4" > no? yes - thank you :) > > ***************************** > > in section 4.3 it says > > "For RGB format video, samples are packed in order Red-Green-Blue. All > samples are the same bit size, which may be 8, 10, 12, or 16 bits. If 8 > bit samples are used, the pgroup is 3 octets. If 10 bit samples are > used, samples from adjacent pixels are packed with no padding, and the > pgroup is 15 octets (4 pixels). Refer to Tables 1 thru 4. > > For RGBA format video, samples are packed in order Red-Green-Blue-Alpha. > All samples are the same bit size, which may be 8, 10, 12, or 16 bits. > For pgroups refer to Tables 1 thru 4." > > Unfortunately the tables 1 thru 4 do not explicitely mention any RGB or RGBA format(!) True. I guess I was assuming that it is obvious that RGB and RGBA would act the same as 4:4:4 and 4:4:4:4 subsampling. I wonder if it would be best to expand the tables, with the rows you have supplied, or add a reference in the text to the effect that RGB and RGBA pgroups are like 4:4:4 and 4:4:4:4 pgroups? > > I think it would be useful to add them, here are the tables > (not sure the notation R:G:B is appropriate, anyway "RGB" is > what is declared in the mime type ...) > > > 8 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+---------------+ > | R:G:B | 1 | P | | 3x8 | 3x8/8 = 3 | 3 | 3 | > +-----------+------+---+ +------+---------------+---------------+ > | R:G:B:A | 1 | P | | 4x8 | 4x8/8 = 4 | 4 | 4 | > +-----------+------+---+ +------+---------------+---------------+ > > > 10 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+---------------+ > | R:G:B | 1 | P | | 3x10 | 4x30/8 = 15 | 12 | 15 | > +-----------+------+---+ +------+---------------+---------------+ > | R:G:B:A | 1 | P | | 4x10 | 40/8 = 5 | 4 | 5 | > +-----------+------+---+ +------+---------------+---------------+ > > 12 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+---------------+ > | R:G:B | 1 | P | | 6x12 | 2x36/8 = 9 | 6 | 9 | > +-----------+------+---+ +------+---------------+---------------+ > | R:G:B:A | 1 | P | | 4x12 | 48/8 = 6 | 4 | 6 | > +-----------+------+---+ +------+---------------+---------------+ > > 16 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+-------+-------+ > | R:G:B | 1 | P | | 3x16 | 3x16/8 = 6 | 3 | 6 | > +-----------+------+---+ +------+---------------+-------+-------+ > | R:G:B:A | 1 | P | | 4x16 | 4x16/8 = 8 | 4 | 8 | > +-----------+------+---+ +------+---------------+-------+-------+ > > > > ***************************** Yes. I shall add in values for 4:4:2:0. Thank you. > > Since we have 4:4:4:4, one thing that should be added is 4:4:2:0 > which is 4:2:0 (the most common raw video format > since it is the raw format of most codecs) plus > a transparency plane with one transparency word > per pixel i.e. same amount of transparency as luminance > > This can be *very* useful for studio applications and is also > directly compressable using the profiles and levels of > MPEG-4 video that support the "shape" tool. > > It simply needs to add 4:4:2:0 in the valid value list (section 6.1) > and in section 3 the relevant tables would be: > > > 8 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | P | | 10x8 | 80/8 = 10 | 10 | 10 | > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | I | | 8x8 | 64/8 = 8 | 8 | 8 | > +-----------+------+---+ +------+---------------+---------------+ > > > > 10 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | P | | 10x10| 2x100/8 = 25 | 20 | 25 | > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | I | | 8x10 | 80/8 = 10 | 8 | 10 | > +-----------+------+---+ +------+---------------+---------------+ > > > 12 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | P | | 10x12| 120/8 = 15 | 10 | 15 | > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | I | | 8x12 | 96/8 = 12 | 8 | 12 | > +-----------+------+---+ +------+---------------+---------------+ > > 16 bit words > Color -------------------------------------- > Subsampling Pixels #words octet alignment samples pgroup > octets > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | P | | 10x16| 160/8 = 20 | 10 | 20 | > +-----------+------+---+ +------+---------------+---------------+ > | 4:4:2:0 | 4 | I | | 8x16 | 128/8 = 16 | 8 | 16 | > +-----------+------+---+ +------+---------------+---------------+ > > > > > regards, > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > To: avt@ietf.org > Ladan Gharai > cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) > Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt > Chuck Harrison > Classification: > > Sent by: > avt-admin@ietf.org > > 05/03/2003 19:19 > > > > > > > Hi, all, > > A few comments on this draft, which is looking very good so far. > > --- > In uncomp-video-02 we have: > > 4.3. Payload Data > > Depending on the video format, each RTP packet can include either a > single complete scan line, a single fragment of a scan line, or one > (or > more) complete scan lines plus a fragment of a scan line. [...] > > > I think there are additional logical possibilities allowed by > the document as it stands: a packet may begin with the tail > fragment of a line, then continue with 0 or more full lines, and > possibly the head fragment of another line. > > If the intent is to exclude these possibilities, we need normative > language to say so. If these operational modes are permitted, the > quoted text above is misleading and should be amended. > > --- > On page 3 of the draft, we have > > [...] This payload format > requires that applications using such synchronized ancillary data MUST > deliver it in separate RTP sessions which operate concurrently with > the > video session. The normal RTP mechanisms SHOULD be used to > synchronize > the media. > > I believe the MUST is inappropriate and SHOULD is preferable. > > The idea that frame-accurate timecode will be carried as a > parallel RTP session is a laudable but forward-looking conjecture. > IMHO reliable use of this payload format in the near future > will depend on carriage of vertical interval timecode (VITC) > in an unused scan line which is part of the vertical blanking > interval. (This is normal video operational practice, as > mentioned in RFC 2431.) > > At the top of page 2 of the draft, we have "...the contents of > horizontal and vertical blanking SHOULD NOT be transported." This > does not bother me as SHOULD NOT language does not prevent me from > carrying VITC when I need it, until the multisession RTP sync > issues get ironed out. On the other hand the MUST language of > page 3 is burdensome. > > --- > > A minor MUST/SHOULD nit at sec. 4.3 regarding filling to a pgroup > boundary: since a receiver MUST ignore the fill data, it seems > unneccessary that the sender MUST fill with zeroes, specifically. > The sender MUST fill, and SHOULD fill with zeroes. > > > --- > > The MIME and SDP parameters do not include the video frame rate. > There are many plausible scenarios in which it is important > to distinguish alternative frame rates. For example, choosing > the right VOD stream during RTSP setup would need something like > this. > > --- > > Cheers, > Chuck Harrison > Far Field Associates, LLC > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Mar 7 17:19:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09643 for ; Fri, 7 Mar 2003 17:19:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27MUnw19376 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 17:30:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MSIO19256; Fri, 7 Mar 2003 17:28:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MNTO18914 for ; Fri, 7 Mar 2003 17:23:29 -0500 Received: from hafez.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09149 for ; Fri, 7 Mar 2003 17:11:17 -0500 (EST) Received: from hafez (ladan@localhost) by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h27MDML07865; Fri, 7 Mar 2003 17:13:22 -0500 Message-Id: <200303072213.h27MDML07865@hafez.nge.isi.edu> To: avt@ietf.org, cfharr@erols.com Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt Date: Fri, 07 Mar 2003 17:13:21 -0500 From: Ladan Gharai 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: , Chuck: I think what would be interesting and what would really add value to the draft, is having a solution for carrying timecodes that is accepted and understood by both worlds. If RTP and RTCP SR packtes are to be used, the draft should be explicit about it and discuss the conversion process. Likewise, if VITC is to transported on the video signals, what happens in instances of discrepancy with the RTP timestamps? However, as you wisely point out, a good start would be to get in touch with the real users. Ladan > Hi, Colin > > Colin Perkins wrote: > > > > > > I'm still not convinced that an additional timecode is necessary: > > it should be derivable from the RTP timestamp and RTCP SR packets. > > Please understand I am not saying that systems will not work > without VITC. In fact, even in an editorial environment where > VITC may be carrying user bits and there are jump cuts in code > I am sure that something could be lashed together with enough > c hackers on the job. I look forward to seeing these things > work the way they should, as totally flexible RTP-synchronized > metadata streams (are you monitoring the MXF work at > http://www.g-fors.com/ , http://www.ist-nuggets.tv/mxf/ ?) > > In the mean time we need to connect with actual users, of which > I am not one. Let's see what people are or aren't doing with > RFC2431. Let's find a few people who are interested in applying > draft-avt-uncomp-video to a real-world application. > > My intuition is that anyone who says "don't worry about VITC, > we can always simulate it" has never been seriously involved > in video production. However I do not speak authoritatively. > > Meanwhile, just what is the major threat to humanity that > comes from allowing a few poor slobs to put VITC on our video > signals if it makes us feel warm and fuzzy? Is it the extra > 0.5% in bandwidth? > > Cheers, > Chuck _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 17:35:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10537 for ; Fri, 7 Mar 2003 17:35:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Mknm21562 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 17:46:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Mh8O21283; Fri, 7 Mar 2003 17:43:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MgQO21074 for ; Fri, 7 Mar 2003 17:42:26 -0500 Received: from hafez.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10206 for ; Fri, 7 Mar 2003 17:30:14 -0500 (EST) Received: from hafez (ladan@localhost) by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h27MVqc07954; Fri, 7 Mar 2003 17:31:52 -0500 Message-Id: <200303072231.h27MVqc07954@hafez.nge.isi.edu> To: Chuck Harrison , avt@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-02.txt In-Reply-To: Your message of "Fri, 07 Mar 2003 12:18:09 PST." <3E68FE81.909D2CF1@erols.com> Date: Fri, 07 Mar 2003 17:31:52 -0500 From: Ladan Gharai 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, all, > > philippe.gentric@philips.com wrote: > > > > Hi all, > > > > I concur with chuck, this is looking very good indeed. > > > [...] > > > > Unfortunately the tables 1 thru 4 do not explicitely mention any RGB or RGBA format(!) > > > > I think it would be useful to add them, here are the tables > > (not sure the notation R:G:B is appropriate, anyway "RGB" is > > what is declared in the mime type ...) [...] > > I had assumed that the conjunction of color-mode = RGB and > sub-sampling = 4:4:4 would describe this. Thus the tables 1 thru > 4 would not require additional entries distinguishing one color- > mode from another. Well, the problem is that section 4.3 refers back to the tables, when discussing RGB and RGBA. A solution would be to eliminate the reference and instead add some text that clarifies how RGB and RGBA are packetized. > As you say, the tables could use a legend/explanation. I think > this could be clarified there. true. > > While we're on color specs, how about this, to encourage *complete* > color specifications: > > ---- > 6.2. Parameter Registration > > New values of the "colorimetry" parameter MAY be registered with the > IANA provided they reference an RFC or other permanent and readily > available specification (the Specification Required policy of RFC 2434 > [2434]). New registrations SHOULD define all parameters > of a color image encoding as described in [22028]. > ---- > > Note: ISO 22028-1 is still in ballot with TC42 for another few days > but I am hopeful that it will be adopted by the time this internet- > draft reaches IESG. > > If anyone is interested in the contents of 22028-1 please contact > me off list. > > Cheers, > Chuck Harrison > Far Field Associates, LLC _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 7 20:04:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22203 for ; Fri, 7 Mar 2003 20:04:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h281GAq03661 for avt-archive@odin.ietf.org; Fri, 7 Mar 2003 20:16:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281DbO03390; Fri, 7 Mar 2003 20:13:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281CxO03335 for ; Fri, 7 Mar 2003 20:12:59 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21825; Fri, 7 Mar 2003 20:00:41 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h2812kZ16740; Fri, 7 Mar 2003 17:02:46 -0800 (PST) Message-Id: <200303080102.h2812kZ16740@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: Fri, 07 Mar 2003 17:02:46 -0800 Subject: [AVT] RFC 3497 on RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video 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 3497 Title: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video Author(s): L. Gharai, C. Perkins, G. Goncher, A. Mankin Status: Standards Track Date: March 2003 Mailbox: ladan@isi.edu, csp@isi.edu, mankin@psg.com, Gary.Goncher@tek.com Pages: 12 Characters: 26094 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-smpte292-video-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3497.txt This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. 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: <030307170029.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3497 --OtherAccess Content-Type: Message/External-body; name="rfc3497.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030307170029.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Mar 8 20:58:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03323 for ; Sat, 8 Mar 2003 20:58:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h292Anj23223 for avt-archive@odin.ietf.org; Sat, 8 Mar 2003 21:10:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2929pO23188; Sat, 8 Mar 2003 21:09:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2921jO22240 for ; Sat, 8 Mar 2003 21:01:45 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01524 for ; Sat, 8 Mar 2003 20:48:57 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h291og412467 for avt@ietf.org; Sat, 8 Mar 2003 17:50:42 -0800 Date: Sat, 8 Mar 2003 17:50:42 -0800 From: John Lazzaro Message-Id: <200303090150.h291og412467@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] SF Issue Summary: MWPP 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 everyone, Here is the combined status report for the MWPP normative (draft-ietf-avt-mwpp-midi-rtp-06.txt) and informative (draft-lazzaro-avt-mwpp-coding-guidelines-02.txt) I-D's, also at: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt The normative document went through one revision (-06.txt), fixing up many small details (see change log for the list). The informative document was completed (-01.txt) and then touched up to conform to the normative -06.txt (-02.txt). I'm assuming there is no reason for the informative document to be a WG item, let me know if there is a wish for the document to be relabeled as a WG item and I will retitle and resubmit. The Road to Last Call ... ------------------------- Since Atlanta, many hours has been spent in e-dialogue with MMA (MIDI Manufacturers Association) folks. The MMA has taken a more active interest in MWPP recently, Jim Wright is the transport-expert MMA contact. We have an informal list of open issues of potential interest to the MMA (mixed in with a few from other sources sent in recently), and I'm doing design work point-by-point off this list. Once the design is complete, and consensus occurs on the result, we may be only an ID-nit-check away from Last Call. Most of these items are better discussed after I release an I-D with a proposed solution, since they are much more about MIDI than RTP issues. However, below I bring up two points that would benefit from pre-design discussion (on list, and at the meeting if there is interest). Both are timing-related, and concern MWPP on the LAN (or well-behaved WAN) in a stage or studio context. Both describe cases where the natural MWPP interpretation of the default AVP audio timing semantics do not completely address the needs of the application domain. [1] Sending-time proxies ------------------------ One issue concerns "operating at the underlying latency of the network, on a network known to have low jitter". This is of particular interest with musicians who play a (soundless) keyboard controller that generates MWPP, which is received by a separate box that makes noise. As network latency is in the human feedback loop, low latency is essential. In these environments, it may be desirable to set up a timing mode where a sender takes on responsibility to transmit, at a precise time interval relative to the MIDI source timing, RTP MWPP packets that (usually) encode a single MIDI command. The receiver, aware that the timing mode is in use (via an SDP parameter), uses this "time of flight" timing together with the timestamp of the packet, as inputs into whatever algorithm it chooses to use for playback. One potential playback algorithm assumes zero network jitter, ignores the timestamp, and executes the command on receipt. Other algorithms incorporate RTP timestamps into the algorithm. Aside from the new SDP fmtp parameter to code that the sender is communicating timing information in its sending dynamics, a few other MWPP additions are helpful for this mode: -- Defining the timestamp of the last MIDI command in the MIDI command section as the proxy for the sending time. This definition is particularly useful when combined with MIDI command section syntax (in the current I-D) that permits the last MIDI command in this section to be the "null" command. -- Defining the ptime and maxptime SDP values as originally intended in SDP -- the length of time encoded by the payload. A second set of MWPP fmtp parameters should be introduced to take over current MWPP use of ptime/maxptime (the delta of the RTP timestamps of two successive packets). [2] Multi-format sync --------------------- A second LAN timing issue concerns multi-format sync. Consider this block diagram (fixed-font recommended): ------------- -------- | Digital | Digital Audio (ADAT, AES/EBU, S/PDIF) | Digital| | Audio |----------->----------------------->-----| Mixer | | Workstation | | With |-->out ------------- | Word | | | Clock | | -------- | RTP/MWPP | | | | ^ ------------- | | | Digital Audio (ADAT, AES/EBU, S/PDIF) | | SoftSynth |----------->--------------------------->------- | | ------------- The Digital Audio Workstation (DAW) generates two pre-recorded streams: digital audio, sent out over one of the standard digital I/O wire/fiber formats (ADAT, AES/EBU, S/PDIF, TDM, etc), and RTP/MWPP over a LAN. The RTP/MWPP stream goes to a separate box running a synth, that also has standard digital I/O format out. A digital mixer, with word-clock to get frame-accurate audio, does the final mix (sent to studio monitors, a mastering rig, etc). The DAW is playing back pre-recorded data here (overdubs are a separate issue, but I believe solving the playback-only issue also solves overdubs). DAWs normally let you time-shift all of the tracks (MIDI and audio), to compensate for delays on the way to the final out. But, how does one compensate for a softsynth with an RTP receiver, whose receiver-buffer latency may be variable? I can imagine two approaches: [A] Assuming the softsynth and the DAW have NTP clocks that are kept in near-frame-accurate sync, you want SDP semantics that request a time differential between the RTCP NTP of the sender and the synced NTP clock of the receiver. [B] You want the ability to specify a fixed receiver latency, perhaps with options that break apart packet buffering latency from post-RTP synth latency (or maybe not). [A] is potentially "calibration free", while [B] merely gives a studio engineer a shot at manually calibrating the rig. So, the question for the WG is, how do you feel about [A] and [B] as design paths to pursue? [A], [B], both, neither? As always, an option is to declare the problem domain "out of scope of RTP." But it would be good to include this "anti-recommendation" in the memo. ------------------------------------------------------------------------- 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 mailnull@www1.ietf.org Mon Mar 10 12:10:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03679 for ; Mon, 10 Mar 2003 12:10:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHNfs29475 for avt-archive@odin.ietf.org; Mon, 10 Mar 2003 12:23:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHGuO28725; Mon, 10 Mar 2003 12:16:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KYRO03859 for ; Fri, 7 Mar 2003 15:34:27 -0500 Received: from ithilien.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27469 for ; Fri, 7 Mar 2003 15:22:15 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h27KK5lb003892; Fri, 7 Mar 2003 12:20:07 -0800 (PST) Received: from HGARUDAD.qualcomm.com (hgarudad.qualcomm.com [129.46.74.119]) by sabrina.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h27KJxOM002426; Fri, 7 Mar 2003 12:20:01 -0800 (PST) Message-Id: <5.1.0.14.2.20030307095821.01e8bcf8@mail1.qualcomm.com> X-Sender: hgarudad@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 10:23:48 -0800 To: "Lars-Erik Jonsson (EAB)" , Adam Li From: Harinath Garudadri Subject: RE: [AVT] File format for EVRC/SMV vocoder Cc: Ietf-Avt In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9754085==_.ALT" 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: , --=====================_9754085==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:58 PM 3/7/2003 +0100, Lars-Erik Jonsson (EAB) wrote: >Adam and others, > >I thought the reason for defining also the file format in the IETF >was to make it in line with the transport format, and also because >you would get it almost "for free" when you define the transport >format. In RFC2658, the payload format for PureVoice, the fileformat for storing data was not specified. We wanted rectify this and hence the draft-garudadri-qcp-00.txt. >The proposed new approach seems to take away those motives, >and then I do not understand why we should do it in the IETF. > >Further, I wonder what would be the rationales for using this new >QCP format instead of the file format defined in the EVRC/SMV draft? It turns out that there have been multiple, independent implementations of the qcp format for quite some. Our understanding is that the qcp format is quite mature and many applications use this format to exchange PureVoice and EVRC data. It is also widely used in many CDMA handsets. draft-garudadri-qcp-00.txt did not propose storage format for SMV, but there have been suggestions to include SMV in the next revision. >If we are to standardize a file format in this body, I can not see >why we should not stick to the format that is already finalized and >has been taken through our standards process. I think it would be useful to understand the extent to which the format defined in EVRC/SMV draft has been implemented, tested and being used. We proposed MIME type audio/qcp with qcelp and evrc as parameters, but we were advised that a better technical solution was to reuse audio/evrc andaudio/qcelp. Thanks, hari. >/L-E > > > > -----Original Message----- > > From: Mark Baugher [mailto:mbaugher@cisco.com] > > > > Adam > > I have a question: Why take a file format specification > > through the IETF? > > > > Best regards, Mark >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt Dr. Hari Garudadri phone : 858-651-6383 mobile : 858-229-2801 pager : 858-653-0963 or hgarudadri@pager.qualcomm.com --=====================_9754085==_.ALT Content-Type: text/html; charset="us-ascii" At 12:58 PM 3/7/2003 +0100, Lars-Erik Jonsson (EAB) wrote:
Adam and others,

I thought the reason for defining also the file format in the IETF
was to make it in line with the transport format, and also because
you would get it almost "for free" when you define the transport
format.

In RFC2658, the payload format for PureVoice, the fileformat for storing data was not specified. We wanted rectify this and hence the draft-garudadri-qcp-00.txt.

The proposed new approach seems to take away those motives,
and then I do not understand why we should do it in the IETF.

Further, I wonder what would be the rationales for using this new
QCP format instead of the file format defined in the EVRC/SMV draft?

It turns out that there have been multiple, independent implementations of the qcp format for quite some. Our understanding is that the qcp format is quite mature and many applications use this format to exchange PureVoice and EVRC data. It is also widely used in many CDMA handsets. draft-garudadri-qcp-00.txt did not propose storage format for SMV, but there have been suggestions to include SMV in the next revision.


If we are to standardize a file format in this body, I can not see
why we should not stick to the format that is already finalized and
has been taken through our standards process.

I think it would be useful to understand the extent to which the format defined in EVRC/SMV draft has been implemented, tested and being used. We proposed MIME type audio/qcp with qcelp and evrc as parameters, but we were advised that a better technical solution was to reuse audio/evrc andaudio/qcelp. Thanks,

hari.


/L-E


> -----Original Message-----
> From: Mark Baugher [mailto:mbaugher@cisco.com]
>
> Adam
>    I have a question:  Why take a file format specification
> through the IETF?
>
> Best regards, Mark
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Dr. Hari Garudadri
phone : 858-651-6383
mobile : 858-229-2801
pager  : 858-653-0963 or hgarudadri@pager.qualcomm.com --=====================_9754085==_.ALT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 10 12:10:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03692 for ; Mon, 10 Mar 2003 12:10:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHNgD29488 for avt-archive@odin.ietf.org; Mon, 10 Mar 2003 12:23:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHGiO28698; Mon, 10 Mar 2003 12:16:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27ICiO21516 for ; Fri, 7 Mar 2003 13:12:44 -0500 Received: from numenor.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20262 for ; Fri, 7 Mar 2003 13:00:35 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h27HvdKn016644; Fri, 7 Mar 2003 09:57:39 -0800 (PST) Received: from HGARUDAD.qualcomm.com (hgarudad.qualcomm.com [129.46.74.119]) by crowley.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h27HvaZJ004667; Fri, 7 Mar 2003 09:57:37 -0800 (PST) Message-Id: <5.1.0.14.2.20030307094345.01de9ed8@mail1.qualcomm.com> X-Sender: hgarudad@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 09:57:36 -0800 To: Mark Baugher , "Adam Li" From: Harinath Garudadri Subject: Re: [AVT] File format for EVRC/SMV vocoder Cc: "Ietf-Avt" , "3GPP2 TSG-C" In-Reply-To: <5.1.1.5.2.20030306043913.06c676b8@mira-sjc5-6.cisco.com> References: <008d01c2e353$a044cf50$4500a8c0@divxnetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1210941==_.ALT" 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: , --=====================_1210941==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:46 AM 3/6/2003 -0800, Mark Baugher wrote: >Adam > I have a question: Why take a file format specification through the IETF? Hi Mark, did you mean AVT above? We were not sure if draft-garudadri-qcp-00.txt should go in to AVT or as an independent submission. I do not think this has been resolved yet. If you meant IETF, our motivation was if a multimedia object (message?) was delivered over some mechanism other than RTP/UDP, (e.g. http, ftp, etc.) the receiver should be able to render the multimedia content appropriately. One example is if you create a voice attachment in Eudora email client, it is stored as a qcp file described in draft-garudadri-qcp-00.txt. If you send this email to someone who uses a different email client, that person could play the attachment in the QuickTime player, as QuickTime supports the above format. Thanks, hari. >Best regards, Mark >At 12:13 PM 3/5/2003 -0800, Adam Li wrote: >>Hi folks, >> >>One issue just recently been raised about the file format for EVRC and >>SMV data, which is specified the MIME registration for them. We very >>much would like to hear your ideas and comments on this issue. >> >>As you may have known, we are working the IETF specification on the RTP >>Payload Format for EVRC/SMV. It specifies how the EVRC/SMV payload is >>carried in RTP sessions, and it also registered the MIME format for the >>EVRC and SMV vocoders. The draft (draft-ietf-avt-evrc-smv) is currently >>at the final editing stage at the IETF FRC Editor's queue. >> >>There has been a file format defined in the draft-ietf-avt-evrc-smv at >>the MIME registration for EVRC/SMV. The file format specified there >>hasn't been changed much since the first version of the draft in 2000. >> >>There is a new Internet Draft, draft-garudadri-qcp-00.txt, specifies a >>different way of storage using the QCP file format, which has been used >>for QCEPL-13K and EVRC by some applications. >> >>Currently, it has been proposed to remove the file format specification >>in the draft-ietf-avt-evrc-smv, and to expand the draft-garudadri-qcp to >>be the only formal specification for the file format for EVRC/SMV. On >>the other hand, there are also suggestions to keep the file format at it >>is specified in the draft-ietf-avt-evrc-smv. >> >>We would like to hear your suggestions, and hear from you how you think >>would be the best way to proceed. Your comments are very much >>appreciated. >> >>Adam >> >> >>_______________________________________________ >>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 Dr. Hari Garudadri phone : 858-651-6383 mobile : 858-229-2801 pager : 858-653-0963 or hgarudadri@pager.qualcomm.com --=====================_1210941==_.ALT Content-Type: text/html; charset="us-ascii" At 04:46 AM 3/6/2003 -0800, Mark Baugher wrote:

Adam
  I have a question:  Why take a file format specification through the IETF?

Hi Mark,
did you mean AVT above? We were not sure if draft-garudadri-qcp-00.txt should go in to AVT or as an independent submission. I do not think this has been resolved yet.

If you meant IETF, our motivation was if a multimedia object (message?) was delivered over some mechanism other than RTP/UDP, (e.g. http, ftp, etc.) the receiver should be able to render the multimedia content appropriately. One example is if you create a voice attachment in Eudora email client, it is stored as a qcp file described in draft-garudadri-qcp-00.txt. If you send this email to someone who uses a different email client, that person could play the attachment in the QuickTime player, as QuickTime supports the above format.

Thanks,
hari.


Best regards, Mark
At 12:13 PM 3/5/2003 -0800, Adam Li wrote:
Hi folks,

One issue just recently been raised about the file format for EVRC and
SMV data, which is specified the MIME registration for them. We very
much would like to hear your ideas and comments on this issue.

As you may have known, we are working the IETF specification on the RTP
Payload Format for EVRC/SMV. It specifies how the EVRC/SMV payload is
carried in RTP sessions, and it also registered the MIME format for the
EVRC and SMV vocoders. The draft (draft-ietf-avt-evrc-smv) is currently
at the final editing stage at the IETF FRC Editor's queue.

There has been a file format defined in the draft-ietf-avt-evrc-smv at
the MIME registration for EVRC/SMV. The file format specified there
hasn't been changed much since the first version of the draft in 2000.

There is a new Internet Draft, draft-garudadri-qcp-00.txt, specifies a
different way of storage using the QCP file format, which has been used
for QCEPL-13K and EVRC by some applications.

Currently, it has been proposed to remove the file format specification
in the draft-ietf-avt-evrc-smv, and to expand the draft-garudadri-qcp to
be the only formal specification for the file format for EVRC/SMV. On
the other hand, there are also suggestions to keep the file format at it
is specified in the draft-ietf-avt-evrc-smv.

We would like to hear your suggestions, and hear from you how you think
would be the best way to proceed. Your comments are very much
appreciated.

Adam


_______________________________________________
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

Dr. Hari Garudadri
phone : 858-651-6383
mobile : 858-229-2801
pager  : 858-653-0963 or hgarudadri@pager.qualcomm.com --=====================_1210941==_.ALT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 10 12:35:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04809 for ; Mon, 10 Mar 2003 12:35:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHmW731954 for avt-archive@odin.ietf.org; Mon, 10 Mar 2003 12:48:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHfdO31614; Mon, 10 Mar 2003 12:41:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHeeO31527 for ; Mon, 10 Mar 2003 12:40:40 -0500 Received: from syd-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04463 for ; Mon, 10 Mar 2003 12:27:04 -0500 (EST) Received: from cscoamera13263.cisco.com (localhost [127.0.0.1]) by syd-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2AHOwPj015721; Tue, 11 Mar 2003 04:25:01 +1100 (EST) Message-Id: <5.1.1.5.2.20030310092026.04c98f10@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 10 Mar 2003 09:25:00 -0800 To: Harinath Garudadri From: Mark Baugher Subject: Re: [AVT] File format for EVRC/SMV vocoder Cc: "Adam Li" , "Ietf-Avt" , "3GPP2 TSG-C" In-Reply-To: <5.1.0.14.2.20030307094345.01de9ed8@mail1.qualcomm.com> References: <5.1.1.5.2.20030306043913.06c676b8@mira-sjc5-6.cisco.com> <008d01c2e353$a044cf50$4500a8c0@divxnetworks.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: , Hari, At 09:57 AM 3/7/2003 -0800, Harinath Garudadri wrote: >At 04:46 AM 3/6/2003 -0800, Mark Baugher wrote: >>Adam >> I have a question: Why take a file format specification through the IETF? > >Hi Mark, >did you mean AVT above? No, I meant the IETF. I asked the question because I don't think of the IETF as having a lot of file-format expertise so it's not the obvious place to develop file-format technology. >We were not sure if draft-garudadri-qcp-00.txt should go in to AVT or as >an independent submission. I do not think this has been resolved yet. > >If you meant IETF, our motivation was if a multimedia object (message?) >was delivered over some mechanism other than RTP/UDP, (e.g. http, ftp, >etc.) the receiver should be able to render the multimedia content >appropriately. One example is if you create a voice attachment in Eudora >email client, it is stored as a qcp file described in >draft-garudadri-qcp-00.txt. If you send this email to someone who uses a >different email client, that person could play the attachment in the >QuickTime player, as QuickTime supports the above format. Is it related to MP4, then? Best Regards, Mark >Thanks, >hari. > > >>Best regards, Mark >>At 12:13 PM 3/5/2003 -0800, Adam Li wrote: >>>Hi folks, >>> >>>One issue just recently been raised about the file format for EVRC and >>>SMV data, which is specified the MIME registration for them. We very >>>much would like to hear your ideas and comments on this issue. >>> >>>As you may have known, we are working the IETF specification on the RTP >>>Payload Format for EVRC/SMV. It specifies how the EVRC/SMV payload is >>>carried in RTP sessions, and it also registered the MIME format for the >>>EVRC and SMV vocoders. The draft (draft-ietf-avt-evrc-smv) is currently >>>at the final editing stage at the IETF FRC Editor's queue. >>> >>>There has been a file format defined in the draft-ietf-avt-evrc-smv at >>>the MIME registration for EVRC/SMV. The file format specified there >>>hasn't been changed much since the first version of the draft in 2000. >>> >>>There is a new Internet Draft, draft-garudadri-qcp-00.txt, specifies a >>>different way of storage using the QCP file format, which has been used >>>for QCEPL-13K and EVRC by some applications. >>> >>>Currently, it has been proposed to remove the file format specification >>>in the draft-ietf-avt-evrc-smv, and to expand the draft-garudadri-qcp to >>>be the only formal specification for the file format for EVRC/SMV. On >>>the other hand, there are also suggestions to keep the file format at it >>>is specified in the draft-ietf-avt-evrc-smv. >>> >>>We would like to hear your suggestions, and hear from you how you think >>>would be the best way to proceed. Your comments are very much >>>appreciated. >>> >>>Adam >>> >>> >>>_______________________________________________ >>>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 > >Dr. Hari Garudadri >phone : 858-651-6383 >mobile : 858-229-2801 >pager : 858-653-0963 or hgarudadri@pager.qualcomm.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 10 22:13:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25485 for ; Mon, 10 Mar 2003 22:13:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B3QFe12126 for avt-archive@odin.ietf.org; Mon, 10 Mar 2003 22:26:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B3OPO11875; Mon, 10 Mar 2003 22:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B3JMO11668 for ; Mon, 10 Mar 2003 22:19:22 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25338 for ; Mon, 10 Mar 2003 22:05:36 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.3) with ESMTP id h2B37e65003382; Mon, 10 Mar 2003 19:07:40 -0800 (PST) (envelope-from casner@acm.org) Date: Mon, 10 Mar 2003 19:07:36 -0800 (PST) From: Stephen Casner To: AVT WG Message-ID: <20030310185508.G59879-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Changes in response to IESG review of RTP 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 main topic for discussion in the "Introduction and document status" item at the top of the AVT agenda is the set of changes to the RTP spec and RTP/AVP profile resulting from the exchange of email on the set of issues I sent out as separate messages in January. The results are in http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-12.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-12.ps http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-13.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-13.ps Actually, I hope that everyone finds the changes I have made to be a satisfactory exposition of the results of the email exchange. If not, please speak up in email or at the meeting. I have written up a detailed accounting of these changes to facilitate the IESG's review and (I hope) acceptance of them. I sent the following message to the IESG. You are welcome to look at the package of files I mention at the end. -- Steve ---------- Forwarded message ---------- Date: Mon, 10 Mar 2003 18:41:17 -0800 (PST) From: Stephen Casner To: iesg@ietf.org Cc: Allison Mankin Subject: Changes in response to IESG review of RTP Dear IESG members: You may have observed that the following updated drafts have been posted: draft-ietf-avt-rtp-new-12 draft-ietf-avt-profile-new-13 These drafts update -11 and -12, respectively, which have already been "tentatively approved" by the IESG for publication as Draft Standards. I realize that the IESG normally does not allow drafts to be updated after they have been reviewed and approved because you do not want to have to review the revised drafts. However, in this case I received permission from our responsible AD, Allison, to submit revised drafts because the set of changes that I believe should be made is large enough that trying to pass them to the RFC Editor as "RFC Editor notes" is not appropriate. There are three reasons for this: - There were several changes that the IESG requested. - The drafts have been under review for more than a year (this is not a complaint -- some of that time is mine) and during that period there have been several questions from implementers that pointed out places where clarification of the text was needed. I'd like to have the document be the best it can as it goes to Draft Standard. - There are changes in several places where I have tried to carefully scrub down these documents according to ID-nits and rfc2223bis. There are two examples that I think will let you see why I wanted to handle these revisions through new I-D's: - I have changed the order of a few end-sections. By doing that in the source, all the refereces are correctly updated. - I have fixed all the places where there were not two spaces after the end of a sentence. Marking all of these in RFC-Editor-note format would not be pleasant or efficient for me, the IESG, or the RFC Editor. It would be unreasonable, I think, to have a long list of RFC-Editor-notes in the message announcing approval to the ietf list and the RFC Editor. To minimize the effort required for you to review these changes, I am providing a package of files to allow you to easily satisfy yourselves that the changes are appropriate: - For the differences of substance, I am providing a description and motivation in RFC-Editor-note format. This should be all that the IESG as a whole needs to consider. - To let you verify that I have not tried to sneak in any changes of substance other than those I describe, I have separated the changes into a series of "layers" (in the Photoshop sense) so that it is easy to see the differences between each successive pair of layers using diff or wdiff. I have provided the diff or wdiff output as well, but you may also run those programs for yourself. I assume it would be sufficient for just one IESG member to perform this verification. I know there is at least one wdiff aficionado on the IESG. This package of files is available in a tarball at ftp://ftp.packetdesign.com/outgoing/casner/rtp-diffs.tgz Since this tarball contains multiple copies of each draft, it is 1.1MB. Please see the files README-rtp.txt and README-profile.txt for a listing of the layers and the changes they contain. I would be happy to answer any questions you may have. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 10 22:21:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25614 for ; Mon, 10 Mar 2003 22:21:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B3YLb12422 for avt-archive@odin.ietf.org; Mon, 10 Mar 2003 22:34:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B3WoO12363; Mon, 10 Mar 2003 22:32:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B3TUO12255 for ; Mon, 10 Mar 2003 22:29:30 -0500 Received: from mail.cs.tu-berlin.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25547 for ; Mon, 10 Mar 2003 22:15:43 -0500 (EST) Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id EAA14152 for ; Tue, 11 Mar 2003 04:17:34 +0100 (MET) Message-Id: <5.2.0.9.2.20030311093948.029ec2d0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 11 Mar 2003 09:57:27 +0700 To: avt@ietf.org From: Stephan Wenger Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Issues to discuss -- draft-ietf-avt-rtp-h264-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: , Folks, here are the issues re the H.264/JVT packetization: 1. Status of JVT -- should be out for the final ballot by the time of the meeting. 2. Fragmentation -- we decided on adding application layer fragmentation of NALUs to support some exotic scenarios. I plan to describe the pros and cons of the fragmentation, and hope for more giudance from the meeting re these feature. We had discussed this briefly in Atlanta already, but it has turned out that I forgot some applications where fragmentation is useful. 3. MIME/SDP sections: are they ok? 4. Interaction with MPEG-4 simple packetization (since H.264 is also ISO/IEC 14496-10). Miska and I are currently in Pattaya at the JVT/MPEG meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim (and other knowledgeable people). We will have some discussions about the interaction of the two drafts, and report probably to the mailing list, but certainly orally at the meeting, about the outcome of these discussions. 5. I currently believe that the problem mentioned in section 12 of the draft doesn't exist, but we will discuss this here in Pattaya as well and take action as necessary. 6. Security section seems to need more work, but this is not reflected in the draft yet. We plan to present a summary of the problems and proposed solution if there is time left. Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 10 23:32:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26722 for ; Mon, 10 Mar 2003 23:32:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B4jmM17082 for avt-archive@odin.ietf.org; Mon, 10 Mar 2003 23:45:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B4imO17044; Mon, 10 Mar 2003 23:44:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B4dAO16699 for ; Mon, 10 Mar 2003 23:39:10 -0500 Received: from ithilien.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26583 for ; Mon, 10 Mar 2003 23:25:22 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2B4N8lb010189; Mon, 10 Mar 2003 20:23:08 -0800 (PST) Received: from [129.46.74.134] (vpn-10-50-0-2.qualcomm.com [10.50.0.2]) by magus.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2B4N59X022312; Mon, 10 Mar 2003 20:23:06 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v6.0a Date: Mon, 10 Mar 2003 20:12:41 -0800 To: "Lars-Erik Jonsson (EAB)" , Adam Li From: Randall Gellens Subject: RE: [AVT] File format for EVRC/SMV vocoder Cc: Ietf-Avt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 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 12:58 PM +0100 3/7/03, Lars-Erik Jonsson (EAB) wrote: > If we are to standardize a file format in this body, I can not see > why we should not stick to the format that is already finalized and > has been taken through our standards process. Given that there are a number of deployed implementations which have been using the qcp format to exchange qcelp-13k and evrc, what is the advantage of having the audio/evrc media type specify a different format? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Despite an abundance of devoted followers, the production of great leaders been discontinued. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 00:43:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28260 for ; Tue, 11 Mar 2003 00:43:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B5ui121088 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 00:56:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B5tnO21043; Tue, 11 Mar 2003 00:55:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B5sVO20976 for ; Tue, 11 Mar 2003 00:54:31 -0500 Received: from mail.cs.tu-berlin.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28204 for ; Tue, 11 Mar 2003 00:40:41 -0500 (EST) Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id GAA24627 for ; Tue, 11 Mar 2003 06:39:00 +0100 (MET) Message-Id: <5.2.0.9.2.20030311123242.029ec2d0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 11 Mar 2003 12:38:43 +0700 To: avt@ietf.org From: Stephan Wenger Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] H.264 payload spec: a question 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: , Folks, first of all I need to thank Magnus for his careful review. Most of his points will be part of a -02 submission of the draft. However, there are a few points that need more discussion, and one where I would like to get an opinion from the group: Magnus: >11. Chapter 6.3 The use of the F bit for aggregated units. Is it really >wise to set this bit as bad as soon as any of the NALUs part of the >aggregate is bad. This is useless information because you still needs to >go into the packet an look at each NALU to determine which is actually >useful. A cheap implementation that just throws away NALUs which is >damaged can't use this flag anyway. It could be useful it the flag is >instead defined as: "The F bit MUST only be set if all NALUs part of the >aggregate has their F bit set". That way the cheap implementation can >throw the whole packet as soon as it looks at the first bit. To make it short: how do you set an error bit for an aggregation packet based on the error bits of the carried sub-packets. Two options: You logically AND the sub-packet error bits: this is what is in the draft You logically OR the sub-packet error bits: this is what Magnus proposed It's IMHO a minor issue, there are good arguments for going both ways, and I would be fine either way. Opinions? Thanks, Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 04:16:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13855 for ; Tue, 11 Mar 2003 04:16:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B9TnR13793 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 04:29:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B9SuO13747; Tue, 11 Mar 2003 04:28:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B9RKO13711 for ; Tue, 11 Mar 2003 04:27:20 -0500 Received: from c015.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13820 for ; Tue, 11 Mar 2003 04:13:26 -0500 (EST) Received: (cpmta 7007 invoked from network); 11 Mar 2003 01:15:33 -0800 Received: from 195.242.54.251 (HELO pavarotti) by smtp.globalipsound.com (209.228.35.119) with SMTP; 11 Mar 2003 01:15:33 -0800 X-Sent: 11 Mar 2003 09:15:33 GMT Reply-To: From: "Alan Duric" To: "'Colin Perkins'" , , Date: Tue, 11 Mar 2003 10:09:48 +0100 Message-ID: <002b01c2e7ad$fb5f7210$fb36f2c3@pavarotti> 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [AVT] Agenda item RTP Payload Format for iLBC Speech 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, here is some info about the agenda item: RTP Payload Format for iLBC Speech (Duric) 15 min draft-ietf-avt-rtp-ilbc-01.txt draft-ietf-avt-ilbc-codec-01.txt and the issues that will be addressed/discussed at the meeting on Thursday, March the 20th: - details about the changes made from 00 versions (introduction of 20 ms frame size mode, improvements on PLC, ...) - implications of 20 ms frame size mode on the RTP Payload Format draft - feedback from SIPit 12, where beside SIP interop tests were conducted interop tests of the running iLBC implementations - next steps - time slot for Q&A Drafts are available under the following links: http://www.ietf.org/internet-drafts/draft-ietf-avt-ilbc-codec-01.txt - iLBC codec spec http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ilbc-01.txt - RTP payload profile for iLBC Best regards, Alan ----------------------------------------------------------------------- | www.ilbcfreeware.org - For the Internet World, Royalty Free for all | ----------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 06:35:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16261 for ; Tue, 11 Mar 2003 06:35:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BBnFg22901 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 06:49:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BBmCO22879; Tue, 11 Mar 2003 06:48:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BBkuO22836 for ; Tue, 11 Mar 2003 06:46:56 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16208 for ; Tue, 11 Mar 2003 06:32:58 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BBZ4B3004446; Tue, 11 Mar 2003 12:35:04 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVNTMH1; Tue, 11 Mar 2003 12:35:03 +0100 Message-ID: <3E6DC9E7.30605@era.ericsson.se> Date: Tue, 11 Mar 2003 12:35:03 +0100 X-Sybari-Trust: d81651cf 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: avt@ietf.org, casner@acm.org Subject: Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) References: <200303071703.h27H32628763@chiron.nge.isi.edu> 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, Here is my comments on the latest version of the AVPF draft. I am glad that we are coming very near a finished specification for AVPF. However I still have some things that we might need to discuss a little bit, see point 14-17. I hope this will not delay the progressing to much. I would very much hope that we can see a updated version just weeks after meeting. Best Regards Magnus 1. Before Abstract: The short copyright is missing. 2. Section 1.1: Early RTCP packet definition. It might be good in this definition to explain what [1] is by including the word "RTP/RTCP" before the reference. 3. The documents page lengths seem to be highly variable. It is not pretty when the footer jumps up and down the different pages. 4. Section 2, RTCP Report interval: The second sentence in the explanation says: " In Regular RTCP mode, all rules from [1] apply." This is not true as the minimal 5 second rules is removed in this case. Also the following sentence makes it clear that the five second rules is only removed for immediate and early RTCP modes. 5. Isn't usually that the page header has the document title centered on the line? 6. Section 3.2 Third paragraph: A sentence beginning with "Hence" is missing space before it. 7. Section 3.2 Fourth paragraph: The first sentence is a bit unclear. The use of following lacks a clear context. I understand that one may send a earlier then what the normal rules would allow. However this sentence may also be interpreted that scheduling earlier is done by following the previous normal rule. 8. Section 3.2 Fourth paragraph. In the middle of the section there is a number of spaces missing and a double ".". See sentence: "The receiver waits for a (short)random dithering intervalto checkwhether it sees a corresponding FB message from any other receiver reporting the same event.." 9. Section 3.2 Fourth paragraph, last sentence: "The permission to send Early feedback is derived from the time Early feedback was sent." I think this is a bit unclear. I think that one must better clarify that it depend on if early feedback has been sent or not in the last interval. A proposal could be :" The permission to send Early feedback is dependent if an Early feedback has been sent since the last regular RTCP packet." 10. Section 3.4 bullet d: I think the word "deterministic" should be added to the first sentence to clarify the impact Tmin has. 11. Section 3.4 bullet g: I think one could include text to clarify what the value will be if in a multicast session. 12. Section 3.4 Bullet m: The following sentence should be reformulated to become more clear and precise: "If T_rr_interval!= 0 then Regular RTCP packets will not be scheduled T_rr after the last Regular RTCP transmission (at tp+T_rr) but at least T_rr_interval after the last Regular RTCP transmission, i.e. later than or at tp+T_rr_interval." Mostly I think that "but" is the wrong word here. 13. Section 3.4 Bullet o: Prior to this section there is a stray occurrence of "Regular". 14. Before section 3.5: I think that there should be a section describing Immediate Feedback mode also. This mode is a bit under explained. One get some general impression of the mode in section 3.3. I think that this section could clarify that in immediate more one can send FB messages anytime. Also how one connects immediate packets to regular reports. However one MUST track the number of reports that are sent to determine when one passes the FB threshold. 15. Section 3.5.3 bullet 2C: I think this paragraph is not specified enough on what to do. In all other cases one always determines what to do next. Here one simple says that it will not be sent. I think there are two ways forward: A) As currently specify that one does not send and then included which variables that needs to be updated so that a new scheduling calculation is performed. Otherwise the RTCP sending simple stops here. B) Specify that one shall in this case schedule the next regular packet for t_rr_last+T_rr_current_interval. As this is a random value, it meats the criteria for a value possible to schedule. 16. Section 4: The SDP attribute: I have problems with the current definitions of the values. I don't understand why the payload specific FB messages must be signaled in either ack or nack. What if you do not want to use generic NACK or ACK and only a payload format specific type like RPSI. Wouldn't it be better to create this as a flat structure. Having a attribute definition like the following one: rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF rtcp-fb-pt = "*" ; wildcard: applies to all formats / fmt ; as defined in SDP spec rtcp-fb-val = "ack" / "nack" / "app" [SP byte-string] / "rpsi" / "sli" / "pli" / "trr-int" SP 1*DIGIT / rtcp-fb-id [SP byte-string] rtcp-fb-id = 1*(alpha-numeric | "-" | "_") I can accept the choice to only have one parameter per attribute line. The gain is of course that extension types are easier to write and parse. 17. Section 5. bullet for AVPF receivers. Similar to the note in AVP enties that AVP receivers may timeout AVPF sources that run with T_rr_interval larger than 5 seconds, a problem for AVPF exist. A AVPF receiver setting T_rr_interval smaller than 5 seconds may actually time out AVP entities. So unless only AVPF senders are present T_rr_interval SHOULD NOT be set smaller than 5 seconds. 18. Section 6.3.3.2 Native RPSI bit string: Shouldn't it be good to put some references here to codes that has RPSI and have RTP payload formats? 19. Section 8, Second paragraph: "Group members of the associated RTP session (possibly pretending to represent a large number of entities) may disturb the operation of RTCP by sending large numbers of RTCP packets thereby reducing the RTCP bandwidth available for Regular RTCP reporting as well as for Early FB messages." This section covers one case. When a attacker sends with different SSRC every time to make the number of participants large. There is another case that effect RTCP reporting interval that might also be mentioned. May however not be as potent. This is to send very large RTCP packets. This increase the avg_rtcp_size variable and also results in lower reporting interval. 20. Section 9: The registration of Application Layer Feedback claims that it will use value "1" instead of "15" which the earlier tables indicate. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 07:53:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17818 for ; Tue, 11 Mar 2003 07:53:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BD78Q27478 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 08:07:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BD6OO27207; Tue, 11 Mar 2003 08:06:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BD4jO27128 for ; Tue, 11 Mar 2003 08:04:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17792 for ; Tue, 11 Mar 2003 07:50:45 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BCqeB3027716; Tue, 11 Mar 2003 13:52:41 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Mar 2003 13:52:40 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Randall Gellens'" , Adam Li Cc: Ietf-Avt Subject: RE: [AVT] File format for EVRC/SMV vocoder Date: Tue, 11 Mar 2003 13:52:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: , > > If we are to standardize a file format in this body, I can not see > > why we should not stick to the format that is already finalized and > > has been taken through our standards process. > > Given that there are a number of deployed implementations which have > been using the qcp format to exchange qcelp-13k and evrc, what is the > advantage of having the audio/evrc media type specify a different > format? OK, but why has not this issue been brought up earlier? The EVRC/SMV format work in AVT has been going on for a long time, and therefore one can question whether it is correct (from a procedural point of view) to suddenly not use what has been developed in this WG, but use something defined elsewhere. IETF standardization is usually an engineering process, not rubber-stamping of already deployed technical solutions. Note that I am not aware of all the details in this matter, but what has been communicated on the list does not provide enough material for motivating what has been proposed. "We have already deployed this alternative format while you were trying to agree on a standard, and now we think you should use our format instead since it is more widely deployed" is a rather strange way of arguing in standards development, I think. Once again, note that I am not addressing the technical aspects, and the above analysis is of course a little bit extreme. However, I hope it clarified my point. Personally, I have no strong opinions in favor of either of the proposals, my concern is more about encouraging active participation in our standards work, instead of encouraging people to work in parallel with our standards efforts. It is a process concern. Cheers, /L-E _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 08:16:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18476 for ; Tue, 11 Mar 2003 08:16:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BDTZa29253 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 08:29:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDTBO29239; Tue, 11 Mar 2003 08:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDSLO29214 for ; Tue, 11 Mar 2003 08:28:21 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18442 for ; Tue, 11 Mar 2003 08:14:20 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 761CDA4B1C for ; Tue, 11 Mar 2003 14:16:07 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA11094 for ; Tue, 11 Mar 2003 14:16:06 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA17626 for ; Tue, 11 Mar 2003 14:16:05 +0100 (MET) Subject: [AVT] H.264 payload spec: a few remarks To: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 11 Mar 2003 14:09:20 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 11/03/2003 14:17:05 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, all, a few remarks on H264 RTP payload: ******************** General remarks: The title(!) and the text keeps on using "JVT" while the file name, the abtract and introduction use the term H.264. (and introduction explains why H.264 is the correct name!) I think a global find-and-replace(JVT->H.264) is needed! The term "NALU" is defined but after that "NAL unit" is also used, consistency could help. There are quite a few reference problems i.e. * figures and table numbers * "above" used for things that are below and vice versa * wrong internal section references Some acronyms are not explained: SEI, IDC (also "Idc"?), DPA, DPB, DPC (even FEC etc), (could be more I did not check), also I am always fascinated by recursivity in acronyms: "NRI: NAL Reference IDC" (this one is superb!-) Detailed remarks: Section 1.1 I suspect the sentence "Neither VCL nor NAL are claimed to be media or network independent" should be removed because it is not logically correlated to the rest of the paragraph. About the paragraph: "Also, there are NAL units that are affecting many pictures and are, hence, inherently time-less. For this reason, the handling of the RTP timestamp requires some special considerations for those NALUs for which the sampling or presentation time is not defined, or, at transmission time, unknown." Describing these NALU as being "time-less" and of having "presentation time [] not defined" could cause some mis- understanding, another formulation could be: "Some NALU transport information that affect the decoding process over a period of time corresponding to many video frames; For these units, the handling of the RTP timestamp requires some special considerations especially in cases where this duration is unknown at transmission time." BTW the same remark applies in section 6.1 for "If the NALU has no own timing properties". You should also elaborate i.e. start to present _how_ the "special considerations" are implemented in the spec ... About the sentence: "The combination of the higher level parameters is called a Parameter Set". It would be useful to add: "which is a data structure akin to what is described as "decoder configuration" in MPEG-4 specifications." since this concept is quite specific to MPEG-4 codecs and H.264 (e.g. most speech or "older" codecs do not have this etc). About the sentence: "Although, conceptually, the Parameter Set updates are not designed to be sent in the synchronous packet stream, this memo contains means to convey them in the RTP packet stream." It is strange (actually potentially contradictory: if they are not "designed" to be sent in packets you would need to document how to map them into NALU but then why the draft does not do that?), perhaps you should replace "designed" with "intended"? in any case it could benefit a little explanation of the "why". The sentence: "The JVT specification declares a value of 1 as a syntax violation" I like this old joke ... ah syntax violation ... is it a disgusting crime or something one might indulge oneself in?-) but at first it _really_ reads as "it is forbiden to set this bit to 1" so your reader will start scratching his (her) head... what about: "The F bit when set to 1 signals that the NALU or header contains a syntax error, in the context of this specification it may have been set by a network device upon detection that a transmission error has affected the corresponding data. A prudent reaction of decoders that are incapable of handling bit errors is to discard such packets. " In the "4. scope" section one finds: "Likely, the first applications of a Standard Track RFC resulting from this draft will be in the conversational multimedia field, video telephone or video conference" This is all very good but something is missing there. I think the problem is not what will be the "first" application but rather what is the _intention_ and _suitability_. This section does not say anything about the suitability of the specification for say broadcast or video on demand, which is at minimum extremely surprising since in the introduction the reader was entertained about "a very broad application range" and how good H264 is to transport satellite quality at 1.5 Mb/s! In section 6.3.1 I could not find _how_ DON is computed except "The DON of the first NALU in transmission order MAY be set to any value", if you dont mandate anything it should be explicit for example "It is not required that DON are monotonously incremented" in the figure "NALU payload format for STAP." (same for the next 2 figures) what are the first 8 bits ? Sometimes one finds "NALU type octet" some other times "|F|NRI| type |"; consistency would help. By "D1 . D2 >= 32768" you probably mean "D1 - D2 >= 32768" ? It says: "NAL units associated with different primary coded pictures according to subclause 7.4.1.2 of [1] MUST NOT have the same value of DON." Is it possible to have an accidental collision? Then what could be the consequence? In section 6.3.2 "DON of the following NALU is equal to DONB + DOND and MUST NOT be larger than 65535" You mean that DON=DONB+DOND MUST NOT roll over inside a packet, right? It would help to add if DONB roll over can occur at any value (also see above "not monotonously incremented" rule?) for the next packet... In Section 6.4. "Fragmentation Units " I could not find the indication that there cannot be more than one FU per RTP packet? I think it is the case? if it is it should be more explicit. (and also, why then call it a "unit" rather than a "packet" ?) "R: 1 bit The Reserved bit MUST be 0." sheer curiosity: what is the purpose of a reserved bit with a _forever_ fixed value ? "A FU payload can have any number of octets and can be empty" why (what for?) can it be empty? In Section 7.1 about the sentence: "Some receivers MAY NOT support a transmission order that does not conform to the NAL unit decoding order. " By what mean the sender can find out about that? In Section 10. Security Considerations: What about crashing a decoder by sending a lethal Parameter Set ? References: for [14] I found it online at: http://www.diee.unica.it/pv2000/proceedings/papers/30.pdf The link http://www.pv2002.org is broken(?) but I found that paper at: http://www-video.eecs.berkeley.edu/papers/sangk7/pv2002.doc ************************************************************ regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 08:22:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18656 for ; Tue, 11 Mar 2003 08:22:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BDaSe29624 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 08:36:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDa6O29604; Tue, 11 Mar 2003 08:36:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDZPO29562 for ; Tue, 11 Mar 2003 08:35:25 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18626 for ; Tue, 11 Mar 2003 08:21:25 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl6.philips.com (Postfix) with ESMTP id D3FFCA431C; Tue, 11 Mar 2003 14:23:32 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA14771; Tue, 11 Mar 2003 14:23:31 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA24546; Tue, 11 Mar 2003 14:23:31 +0100 (MET) Subject: Re: [AVT] H.264 payload spec: a question To: Stephan Wenger Cc: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 11 Mar 2003 14:16:50 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 11/03/2003 14:24: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: , Magnus, I see your point but such a rule could make the F bit almost never used i.e. if all the packets are corrupted you are in bad trouble to start with (!) and otherwise the F bit will "almost always" be zero, No? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: avt@ietf.org cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: [AVT] H.264 payload spec: a question Stephan Wenger Classification: Sent by: avt-admin@ietf.org 11/03/2003 06:38 Folks, first of all I need to thank Magnus for his careful review. Most of his points will be part of a -02 submission of the draft. However, there are a few points that need more discussion, and one where I would like to get an opinion from the group: Magnus: >11. Chapter 6.3 The use of the F bit for aggregated units. Is it really >wise to set this bit as bad as soon as any of the NALUs part of the >aggregate is bad. This is useless information because you still needs to >go into the packet an look at each NALU to determine which is actually >useful. A cheap implementation that just throws away NALUs which is >damaged can't use this flag anyway. It could be useful it the flag is >instead defined as: "The F bit MUST only be set if all NALUs part of the >aggregate has their F bit set". That way the cheap implementation can >throw the whole packet as soon as it looks at the first bit. To make it short: how do you set an error bit for an aggregation packet based on the error bits of the carried sub-packets. Two options: You logically AND the sub-packet error bits: this is what is in the draft You logically OR the sub-packet error bits: this is what Magnus proposed It's IMHO a minor issue, there are good arguments for going both ways, and I would be fine either way. Opinions? Thanks, Stephan _______________________________________________ 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 mailnull@www1.ietf.org Tue Mar 11 08:43:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19070 for ; Tue, 11 Mar 2003 08:43:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BDuq131187 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 08:56:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDuHO31151; Tue, 11 Mar 2003 08:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDtdO31120 for ; Tue, 11 Mar 2003 08:55:39 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19016 for ; Tue, 11 Mar 2003 08:41:38 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BDhkwv019720; Tue, 11 Mar 2003 14:43:46 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPH5RDCC; Tue, 11 Mar 2003 14:43:45 +0100 Message-ID: <3E6DE811.7070103@era.ericsson.se> Date: Tue, 11 Mar 2003 14:43:45 +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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org CC: Stephan Wenger Subject: Re: [AVT] H.264 payload spec: a question References: 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 Phillipe and Stephan, philippe.gentric@philips.com wrote: >Magnus, > >I see your point but such a rule could make the F bit almost never used >i.e. if all the packets are corrupted you are in bad trouble to start with (!) >and otherwise the F bit will "almost always" be zero, No? > > > Yes, however my point is that this field is useless unless it provides any advantage over looking at each NALU. The F bit in STAP and MTAPs are a redundant field. The information is available for in each NALU header. So with the current definition of the F in STAP, MTAP what advantage does it give? To my understanding the only knowledge it gives is: At least one NALU is damaged. However you will still need to look at which they are. So I don't see any advantage of reading the F bit in the STAP, MTAP header. However if you redefine it as I propose it is a little bit less redundant, now the F bit gives the following information: All NALUs are damaged, unless I can repair them I can throw away them. This means that simple implementations (not trying any repair) can throw away the whole packet with less processing. Of course it is correct that the bit will be set much less often. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 08:59:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19544 for ; Tue, 11 Mar 2003 08:59:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BED2i32613 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 09:13:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BECaO32592; Tue, 11 Mar 2003 09:12:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEB1O32548 for ; Tue, 11 Mar 2003 09:11:01 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19485 for ; Tue, 11 Mar 2003 08:57:02 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id 5007BA44B6; Tue, 11 Mar 2003 14:59:06 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA25870; Tue, 11 Mar 2003 14:59:05 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA01461; Tue, 11 Mar 2003 14:59:04 +0100 (MET) Subject: Re: [AVT] H.264 payload spec: a question To: Magnus Westerlund Cc: avt@ietf.org, Stephan Wenger X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 11 Mar 2003 14:52:20 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 11/03/2003 15:00:05 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: , Hi Magnus, stephan, I agree this bit is not extremely useful ... and it is a better idea then to set it if all are discardable... regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: avt@ietf.org cc: Stephan Wenger (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: Re: [AVT] H.264 payload spec: a question Magnus Westerlund Sent by: avt-admin@ietf.org 11/03/2003 14:43 Hi Phillipe and Stephan, philippe.gentric@philips.com wrote: >Magnus, > >I see your point but such a rule could make the F bit almost never used >i.e. if all the packets are corrupted you are in bad trouble to start with (!) >and otherwise the F bit will "almost always" be zero, No? > > > Yes, however my point is that this field is useless unless it provides any advantage over looking at each NALU. The F bit in STAP and MTAPs are a redundant field. The information is available for in each NALU header. So with the current definition of the F in STAP, MTAP what advantage does it give? To my understanding the only knowledge it gives is: At least one NALU is damaged. However you will still need to look at which they are. So I don't see any advantage of reading the F bit in the STAP, MTAP header. However if you redefine it as I propose it is a little bit less redundant, now the F bit gives the following information: All NALUs are damaged, unless I can repair them I can throw away them. This means that simple implementations (not trying any repair) can throw away the whole packet with less processing. Of course it is correct that the bit will be set much less often. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ 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 mailnull@www1.ietf.org Tue Mar 11 09:38:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20746 for ; Tue, 11 Mar 2003 09:38:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BEpdO02766 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 09:51:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEpEO02719; Tue, 11 Mar 2003 09:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEoPO02684 for ; Tue, 11 Mar 2003 09:50:25 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20693 for ; Tue, 11 Mar 2003 09:36:24 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2BEcUwv005055 for ; Tue, 11 Mar 2003 15:38:30 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPH5RTK3; Tue, 11 Mar 2003 15:38:29 +0100 Message-ID: <3E6DF4E6.3080106@era.ericsson.se> Date: Tue, 11 Mar 2003 15:38: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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF AVT WG References: <200303061542.KAA21142@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-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, I have some comments on the latest version of the draft. It starts to look good, and I hope for quick addressing of the problems. 1. The title: I don't like the title, I think it is a bit miss leading. This is not a only RTP extended reports. Some of the things only are related to RTCP functionality. So maybe "RTP/RTCP Extended Reports" would be a better title. 2. The page length of the first page is different from the others. Maybe not that important as the RFC-Editor will change this page to be 1 line longer than all other pages in the draft. 3. Section 1: Should be page break to a new page for readability. 4. The page header is not the normal one. See draft-rfc-editor-rfc2223bis-04.txt section 3.3. In drafts that results in the following example from above draft: Internet-Draft Instructions to RFC Authors 10 Feb 2003 5. Section 1, bullet list with report blocks: All bullets with second lines should be indented to look nicer and be more readable. 6. Section 2, Figure: The "PT=XP=207" shouldn't that be PT=XR=207? 7. Section 4.1, listing for format figure: The bullet for "SSRC of Source" is missing in the list. 8. Section 4.3, The RTP Timestamp i, bullet after format figure: I still think that this format should be reduced. I also think there is a problem of using the RTP timestamp clock to stamp arrival time. First it is unnecessary as there is no connection between used RTP TS in the packet and the arrival sampling. Secondly, this section does not describe how you handle changes of RTP TS rates due to change of PT in the incoming data. It is also possible that different sources uses different RTP TS rates due to usage of different PTs. All these problems go away if one defines a single clock rate to use in this format. One can also then consider that the number of bits per report can be reduced significantly. 9. Section 4.4 first paragraph. Why is not the TTL fields defined for the IPv6 Hop Limit field which is identical to TTL? 10. Section 4.4, The statistics summary format: I have earlier had the misconception that this format would actually be a bit smarter and having variable fields present. However I know understand that even if only a single part of the report is used the whole 40 bytes must be sent. I would be more efficient to remove the parts of the format that are not being reported on. I don't see the little complexity of such an operation as having much significance. If for example only a single part, e.g. TTL, of the block is of interest the overhead could be reduced with up to 24 bytes. 24 bytes may be as much as 20 % increase in packet size, i.e. the reporting interval could be reduced with the same amount. 11. Section 4.4, The definition of standard deviation fields. All fields seems to be defined as they are integer fields why standard deviation calculations normal generate a real value. I think one needs to mention what type of operation is used to produce the integer value, rounding, ceiling, flooring? 12. Section 4.5 First sentence: Please include NTP in this sentence so that it reads: "This block extends RTCP's timestamp reporting so that non-senders may also send NTP timestamps.". This makes it clears directly what type of timestamp is used. 13. Section 4.5 Last sentence of NTP timestamp definition: If a sender has no notion of time it shall not send this format at all. It is very unnecessary for other entities to waste bits on something no one can use. So I would suggest that the last sentence is changes to: "A report sender that has no notion of wallclock or elapsed time SHALL NOT send this report block.". 14. Section 4.6, block length definition: I think one should clarify that the length is used to derive the number of sources that are reported on in the reporting block. The formula seems to be as simple as taking "block length / 3". 15. Section 4.6, Format definition: For completeness please include the SSRC_i in the fields explained. 16. Section 4.6, DLRR definition: I think that senders of this block SHALL only send reports on sources sending the NTP Timestamp report. It is useless to spend bits on source that has not asked for this information. It is a total waste as the SSRC being reported has nothing to calculate the RTT unless it has sent a NTP Timestamp reporting block. I would also make a an addition to this paragraph that a reporter may stop reporting on a source after sending three times on the same LRR. A proposed text: "A Sender of DLRR reports MAY stop sending them for any given source when it has reported three times on the same LRR for that source. It MUST resume the reporting when it receives a new LRR in the form of a Receiver Timestamp Report block from that source." 17. Section 4.7.4: The signal level calculations are not clear as Log10 has been separated into "log 10". 18. Section 4.7.7: How does one use the jitter buffer sizes when one has a sample based codec and have no defined frame size, or for that matter if the frame size is variable? 19. Section 5: The first sentence, replace RTP with RTCP. 20. Section 5.1: I don't think one can order IANA to give one a certain number. So I think changing SHALL to request is better. However this the chairs may answer better. 21. Section 5.2: I think this format should register 255 as reserved for future extending of the number space. 22. Section 5.2, last paragraph: I don't see much reason for the recommendation that 0 and 255 should not be used. There are several ways of checking integrity of the different reports. The simplest is to check the XR report block length against the different report blocks length field. This is simply a continuation of what should be performed at RTCP packet types level. I would in fact recommend that a new section containing decoding considerations is written to explain these method. 23. Section 6: Second and third paragraph: Can we actually write something about the AS's right to keep network topology and characteristics confidential? 24. Section A.1: Why is the extended sequence number initiated to the middle of the space? Normally one would start with an extended sequence number of 0. Shouldn't one try to be consistent with extended highest sequence number received in the receiver reporting. 25. A SDP section. I still think that a SDP section should be included in this document. However if the authors of XR format draft are not willing to include it in their document, I volunteer myself to write and drive a separate SDP draft towards and RFC. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 10:01:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21476 for ; Tue, 11 Mar 2003 10:01:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BFF2304678 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 10:15:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFEKO04628; Tue, 11 Mar 2003 10:14:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFDvO04586 for ; Tue, 11 Mar 2003 10:13:57 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21379 for ; Tue, 11 Mar 2003 09:59:56 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA22799; Tue, 11 Mar 2003 16:02:02 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA01576; Tue, 11 Mar 2003 16:02:02 +0100 (MET) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Mar 2003 16:01:46 +0100 Message-ID: From: Kreuter Ruediger To: "'Magnus Westerlund'" Cc: "'avt@ietf.org'" Subject: AW: [AVT] updated "Clearmode" (64kbit/s unrestricted) Internet-dr aft Date: Tue, 11 Mar 2003 16:01:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2BFDwO04589 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 Hi Magnus, thanks for your indepth review and the according comments. They are still true for version 02, so the updates will come in version 03 after the upcoming IETF Meeting. See more detailed answers below. Regards, Rüdiger Kreuter Siemens AG ICN CP Systems Engineering D-81359 München Tel +49 89 722 62553 Fax +49 89 722 130 62553 ruediger.kreuter@siemens.com > -----Ursprüngliche Nachricht----- > Von: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] > Gesendet: Donnerstag, 6. März 2003 16:28 > ... > > 1. Chapter 2: First sentence seems strange it looks like it lacks > context. "The profile .." refers to something which I don't > know what it > is. This will be changed to "This document .." in version 03. > > 2. Maybe a little more text on how data is put in the payload format. > Especially around the number of samples you are allowed to > put into each > packet. Well, this chapter was copied and adapted from the PCMA/PCMU section of draft-ietf-avt-profile-new-12.txt, because the CLEARMODE handling is similar (simple). I will add some of the generic payload handling descriptions of draft-ietf-avt-profile-new-13.txt, which are relevant for CLEARMODE too. As PCMA/PCMU the number of samples just depends on the supported packet sizes, since CLEARMODE is sample oriented. > > 3. End of chapter 2: "The timestamp SHALL be set according [5]" > Shouldn't this be "The timestamp SHALL be set according to [5]." O.k. this will be changed in version 03 > > 4. Chapter 3: Optional parameters. I think "maxptime" is a > valid one to > use. The existing RFC with this parameter is RFC 3267 but the updated > SDP draft also contains a definition of it. Accepted, this will be added in version 03: ******************************************* Optional parameters: ptime, maxptime "ptime" gives the length of time in milliseconds represented by the media in a packet [7]. "maxptime" represents the maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds [10]. ******************************************* ... where [10] is a new reference to: M. Handley, V. Jacobson and C. Perkins, "SDP: Session Description Protocol", revision of 2327, work in progress. > > 5. Chapter 3 is missing rules on how you apply the mime parameters to > SDP. Please see draft-ietf-avt-rtp-mime-06.txt for such a chapter. A new chapter will be added in version 03: ****************************************** 4. Mapping to SDP parameters Parameters are mapped to SDP [7] in a standard way. o The MIME type (audio) goes in SDP "m=" as the media name. o The MIME subtype (CLEARMODE) goes in SDP "a=rtpmap" as the encoding name. o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively. An example mapping is as follows: audio/CLEARMODE; ptime=10 m=audio 12345 RTP/AVP 97 a=rtpmap:97 CLEARMODE/8000 a=ptime:10 Note that the payload format (encoding) names defined in the RTP Profile are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case- insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute. ****************************************** > > 6. Reference list in chapter 5. Shouldn't there be nice [] around the > numbers? They will be added in version 03 :-) > > 7. Time to read the ID nits. You are lacking a couple of necessary > sections, like Copyright statement and IPR statement. See > http://www.ietf.org/ID-nits.html Copyright and IPR statement will be added in version 03. I didn't find other missing chapters. > > 8. When you don't transport ISDN 7 kHz voice in this and > actually carry > some other type of data. Isn't of interest to mention RTP relevant > mechanisms to protect the stream against packet loss. There should be > significant considerations of this problem. Since the application that uses Clearmode is unknown, it is hard to require an adequate method for packet loss concealment. So IMHO this is application dependent and therefore must be dealt with by methods outside the scope of this document. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 11:41:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26707 for ; Tue, 11 Mar 2003 11:41:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BGt7012012 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 11:55:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGsfO11984; Tue, 11 Mar 2003 11:54:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BGrBO11921 for ; Tue, 11 Mar 2003 11:53:11 -0500 Received: from lists.herlein.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26582 for ; Tue, 11 Mar 2003 11:39:08 -0500 (EST) Received: from tux.herlein.com (tux.herlein.com [192.168.70.50]) by lists.herlein.com (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id h2BGOmu21429; Tue, 11 Mar 2003 08:24:48 -0800 Date: Tue, 11 Mar 2003 08:41:07 -0800 (PST) From: Greg Herlein To: "'Colin Perkins'" , avt@ietf.org, casner@acm.org cc: Jean-Marc Valin , Roger Hardiman , Simon Morlat Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Summary of Speex RTP Profile Issues 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: , Regarding: RTP Payload Format for the Speex Codec (Herlein) 15 scheduled for the San Francisco meeting on Thursday, 20th March at 09:00-11:30. This will essentially be an introduction of Speex and the draft profile to the WG. I'll cover: - a short introduction to Speex - a summary of what an RTP profile must provide to Speex for use in an RTP stream - a very short discussion of the things that Speex does in-band that are not required to be handled in the RTP profile - a brief introduction to the draft profile itself - a summary of issues we already know are outstanding Please review the draft profile at: http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-00.txt The complete manual regarding the Speex codec is available at: http://www.speex.org/docs.html Thank you, Greg Herlein _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 11:59:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27530 for ; Tue, 11 Mar 2003 11:59:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BHCdU14214 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 12:12:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BHC3O14202; Tue, 11 Mar 2003 12:12:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BH9pO14089 for ; Tue, 11 Mar 2003 12:09:51 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27363 for ; Tue, 11 Mar 2003 11:55:48 -0500 (EST) 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.6/8.12.6) with ESMTP id h2BGvr0E022048; Tue, 11 Mar 2003 08:57:53 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-213.cisco.com [64.100.135.213]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACE27801; Tue, 11 Mar 2003 08:57:51 -0800 (PST) Message-Id: <4.3.2.7.2.20030311112911.016f4df8@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Mar 2003 11:57:51 -0500 To: "'Colin Perkins'" , , From: "Michael A. Ramalho" Subject: [AVT] Agenda item RTP Payload Format for RGL Codec Cc: fluffy@cisco.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: , Greetings, Below is a summary of the issues I will be discussing at the Thursday, 20th March at 09:00-11:30 AVT time slot concerning the following agenda item: RTP Payload Format for RGL Codec (Ramalho) 15 min draft-ramalho-rgl-desc-01.txt draft-ramalho-rgl-rtpformat-01.txt The text versions of these drafts can be found at: http://www.ietf.org/internet-drafts/draft-ramalho-rgl-desc-01.txt http://www.ietf.org/internet-drafts/draft-ramalho-rgl-rtpformat-01.txt and html versions (easier to view) may be found at: http://www.winlab.rutgers.edu/~ramalho/rgl_codec_01.html http://www.winlab.rutgers.edu/~ramalho/rgl_rtp_01.html 1) RGL Codec draft (~5 min): *The new RGL codec draft describes a revision to the previous version of the RGL codec. The reason the RGL codec was revised was to accommodate a simple RTP payload format for it. * To create a Table of Contents (TOC) required for some of the packetization formats proposed in the RTP payload draft, the RGL codec was revised to create seven "reserved first RGL bytes" that are never produced as the first byte of a RGL frame. * The revision was made backwardly compatible; that is, an RGL frame produced by the revised encoder will be successfully decoded by the previous version decoder. 2) The RGL RTP payload format draft (~10 min): This draft proposes several RTP payload formats for RGL encoded frames. When more than one RGL frame is placed in a RTP payload, a TOC is created at the beginning of the RTP payload. This draft proposes a few specialized TOCs and one generic one to determine the boundaries and necessary parameters of the RGL frame(s) contained in the RTP payload. 3) Next Steps and Q&A Regards, Michael Ramalho Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 13:05:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29935 for ; Tue, 11 Mar 2003 13:05:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BIJIk18966 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 13:19:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIInO18893; Tue, 11 Mar 2003 13:18:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIGhO18794 for ; Tue, 11 Mar 2003 13:16:43 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29851 for ; Tue, 11 Mar 2003 13:02:38 -0500 (EST) Received: from RKUMAR-W2K.cisco.com ([128.107.170.120]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2BI4dht012861; Tue, 11 Mar 2003 10:04:40 -0800 (PST) Message-Id: <4.3.2.7.2.20030311095004.0160ffd8@mira-sjc5-8.cisco.com> X-Sender: rkumar@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Mar 2003 10:04:39 -0800 To: avt@ietf.org, gunnar.hellstrom@omnitor.se, casner@acm.org From: Rajesh Kumar Cc: mario Garakani , paulej@packetizer.com, bfoster@cisco.com, rmahy@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1367241299==_.ALT" Subject: [AVT] Need clarification on protocol type for RFC 2793 text media 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: , --=====================_1367241299==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Gunnar and Steve, While RFC 2793 defines an RTP encapsulation for the text media, it does not clearly state that the SDP protocol name associated with the MIME text/t140 is RTP/AVP. Can one assume that? Of the five protocol names (SDP proto parameter values) listed by the IANA at http://www.iana.org/assignments/sdp-parameters, RTP/AVP does seem to be the most suitable. The other ones are rtp (historic), vat (historic), udptl and tcp. One may, of course, define a new protocol name/profile that includes RTP encapsulations of text, but I would advise against doing that. TTY devices often interleave voice and text, and it would be simpler to keep text/t140 under the RTP/AVP umbrella. It would be nice if RFC 2793 has SDP examples just as RFC 2198, RFC 2733, RFC 2833 etc. do. But there are none. Here is a possible example. Please let us know if this is what you had in mind when you registered the MIME type text/t140. If an IP endpoint/gateway dedicates a UDP port to RFC 2793 text relay, the media line for the text relay stream is as follows: m=text RTP/AVP a=rtpmap: t140 This is consistent with the text/t140 MIME definition in RFC 2793. It maps an RTP payload type to the MIME text/t140. For example, m=text 49232 RTP/AVP 100 a=rtpmap:100 t140 indicates that the IP endpoint or gateway is willing to receive an RFC 2793-based RTP packet stream with a payload type of 100 on port 49232. Thanks for your guidance in thismatter. Rajesh --=====================_1367241299==_.ALT Content-Type: text/html; charset="us-ascii" Gunnar and Steve,
While RFC 2793 defines an RTP encapsulation for the text media, it does not clearly state that the SDP protocol name associated with the MIME text/t140 is RTP/AVP. Can one assume that?

Of the five protocol names (SDP proto parameter values) listed by the IANA at http://www.iana.org/assignments/sdp-parameters, RTP/AVP does seem to be the most suitable. The other ones are rtp (historic), vat (historic), udptl and tcp. One may, of course, define a new protocol name/profile that includes RTP encapsulations of text, but I would advise against doing that. TTY devices often interleave voice and text, and it would be simpler to keep text/t140 under the RTP/AVP umbrella.

It would be nice if RFC 2793 has SDP examples just as RFC 2198, RFC 2733, RFC 2833 etc. do. But there are none.  Here is a possible example. Please let us know if this is what you had in mind when you registered the MIME type text/t140.

If an IP endpoint/gateway dedicates a UDP port to RFC 2793 text relay, the media line for the text relay stream is as follows:
m=text <port #> RTP/AVP <payload type>
a=rtpmap:<payload type> t140

This is consistent with the text/t140 MIME definition in RFC 2793. It maps an RTP payload type to the MIME text/t140.   For example,
 
m=text 49232 RTP/AVP 100
a=rtpmap:100 t140

indicates that the IP endpoint or gateway is willing to receive an RFC 2793-based RTP packet stream with a payload type of 100 on port  49232.

Thanks for your guidance in thismatter.

Rajesh   
--=====================_1367241299==_.ALT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 13:18:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00368 for ; Tue, 11 Mar 2003 13:18:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BIVir19564 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 13:31:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIVNO19550; Tue, 11 Mar 2003 13:31:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIUfO19512 for ; Tue, 11 Mar 2003 13:30:41 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00338 for ; Tue, 11 Mar 2003 13:16:35 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h2BIHab16130; Tue, 11 Mar 2003 13:17:36 -0500 Message-Id: <200303111817.h2BIHab16130@chiron.nge.isi.edu> To: Rajesh Kumar cc: avt@ietf.org, gunnar.hellstrom@omnitor.se, casner@acm.org, mario Garakani , paulej@packetizer.com, bfoster@cisco.com, rmahy@cisco.com Subject: Re: [AVT] Need clarification on protocol type for RFC 2793 text media In-Reply-To: Your message of "Tue, 11 Mar 2003 10:04:39 PST." <4.3.2.7.2.20030311095004.0160ffd8@mira-sjc5-8.cisco.com> Date: Tue, 11 Mar 2003 13:17:36 -0500 From: Colin Perkins 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: , Rajesh, --> Rajesh Kumar writes: > >Gunnar and Steve, >While RFC 2793 defines an RTP encapsulation for the text media, it does not >clearly state that the SDP protocol name associated with the MIME text/t140 >is RTP/AVP. Can one assume that? An RTP payload format can be used under multiple RTP profiles. To date, there is only one profile [RFC 1890] and that is denoted by RTP/AVP. You almost certainly want to use this. In the future, we have two more profiles in development: RTP/SAVP draft-ietf-avt-srtp-05.txt RTP/AVPF draft-ietf-avt-rtcp-feedback-05.txt If you use either of those profiles, you would use the appropriate name to identify them. >Of the five protocol names (SDP proto parameter values) listed by the IANA >at http://www.iana.org/assignments/sdp-parameters, RTP/AVP does seem to be >the most suitable. The other ones are rtp (historic), vat (historic), udptl >and tcp. One may, of course, define a new protocol name/profile that >includes RTP encapsulations of text, but I would advise against doing that. >TTY devices often interleave voice and text, and it would be simpler to >keep text/t140 under the RTP/AVP umbrella. > >It would be nice if RFC 2793 has SDP examples just as RFC 2198, RFC 2733, >RFC 2833 etc. do. But there are none. Here is a possible example. Please >let us know if this is what you had in mind when you registered the MIME >type text/t140. > >If an IP endpoint/gateway dedicates a UDP port to RFC 2793 text relay, the >media line for the text relay stream is as follows: >m=text RTP/AVP >a=rtpmap: t140 > >This is consistent with the text/t140 MIME definition in RFC 2793. It maps >an RTP payload type to the MIME text/t140. For example, > >m=text 49232 RTP/AVP 100 >a=rtpmap:100 t140 > >indicates that the IP endpoint or gateway is willing to receive an RFC >2793-based RTP packet stream with a payload type of 100 on port 49232. This is the standard mapping, provided you are operating under the RTP profile defined in RFC 1890. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 13:28:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00812 for ; Tue, 11 Mar 2003 13:28:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BIg6020901 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 13:42:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIfTO20873; Tue, 11 Mar 2003 13:41:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BIewO20828 for ; Tue, 11 Mar 2003 13:40:58 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00754 for ; Tue, 11 Mar 2003 13:26:51 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.3) with ESMTP id h2BIQg65019557; Tue, 11 Mar 2003 10:26:42 -0800 (PST) (envelope-from casner@acm.org) Date: Tue, 11 Mar 2003 10:26:42 -0800 (PST) From: Stephen Casner To: Rajesh Kumar cc: avt@ietf.org, , mario Garakani , , , In-Reply-To: <4.3.2.7.2.20030311095004.0160ffd8@mira-sjc5-8.cisco.com> Message-ID: <20030311101618.R61871-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: Need clarification on protocol type for RFC 2793 text media 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: , Rajesh, > While RFC 2793 defines an RTP encapsulation for the text media, it does not > clearly state that the SDP protocol name associated with the MIME text/t140 > is RTP/AVP. Can one assume that? It is intentional that the payload format does not specify the RTP profile under which it may be used because it may be used under different profiles for different applications if needed. At this moment, RTP/AVP is the only profile that has been published as an RFC, but two more (RTP/SRTP and RTP/AVPF) are very close. > Of the five protocol names (SDP proto parameter values) listed by the IANA > at http://www.iana.org/assignments/sdp-parameters, RTP/AVP does seem to be > the most suitable. The other ones are rtp (historic), vat (historic), udptl > and tcp. One may, of course, define a new protocol name/profile that > includes RTP encapsulations of text, but I would advise against doing that. > TTY devices often interleave voice and text, and it would be simpler to > keep text/t140 under the RTP/AVP umbrella. Yes, it is appropriate to use text/t140 under rtp/avp. > It would be nice if RFC 2793 has SDP examples just as RFC 2198, RFC 2733, > RFC 2833 etc. do. But there are none. Here is a possible example. Please > let us know if this is what you had in mind when you registered the MIME > type text/t140. Yes, having SDP examples is handy, although not required (since using SDP is not required). > If an IP endpoint/gateway dedicates a UDP port to RFC 2793 text relay, the > media line for the text relay stream is as follows: > m=text RTP/AVP > a=rtpmap: t140 > > This is consistent with the text/t140 MIME definition in RFC 2793. It maps > an RTP payload type to the MIME text/t140. For example, > > m=text 49232 RTP/AVP 100 > a=rtpmap:100 t140 > > indicates that the IP endpoint or gateway is willing to receive an RFC > 2793-based RTP packet stream with a payload type of 100 on port 49232. The mapping you have shown is valid. It follows the established rules in draft-ietf-mmusic-sdp-new-12.txt and draft-ietf-avt-rtp-mime-06.txt. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 19:27:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20479 for ; Tue, 11 Mar 2003 19:27:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C0fCl16275 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 19:41:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0eOO16199; Tue, 11 Mar 2003 19:40:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0c4O16036 for ; Tue, 11 Mar 2003 19:38:04 -0500 Received: from mail.cs.tu-berlin.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20220 for ; Tue, 11 Mar 2003 19:23:50 -0500 (EST) Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id BAA03209; Wed, 12 Mar 2003 01:24:22 +0100 (MET) Message-Id: <5.2.0.9.2.20030312045408.02187de8@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Mar 2003 05:45:53 +0700 To: philippe.gentric@philips.com From: Stephan Wenger Subject: Re: [AVT] H.264 payload spec: a few remarks Cc: avt@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: , Folks, At 02:09 PM 3/11/2003 +0100, philippe.gentric@philips.com wrote: >[...] > The title(!) and the text keeps on using "JVT" while the file name, > the abtract and introduction use the term H.264. [...]. I think a > global find-and-replace(JVT->H.264) is needed! or a change back to JVT, if MPEG endorses this draft as a way to transport this new video bit stream. The inconsistency will be fixed, but IMHO it was not worth to spend the time before the I-D deadline. > The term "NALU" is defined but after that "NAL unit" is also used, > consistency could help. Agreed, will fix >There are quite a few reference problems i.e. > * figures and table numbers > * "above" used for things that are below and vice versa > * wrong internal section references Agreed, will fix >Some acronyms are not explained: SEI, IDC (also "Idc"?), DPA, DPB, DPC >(even FEC etc), (could be more I did not check), also I am always >fascinated by recursivity in acronyms: "NRI: NAL Reference IDC" (this one >is superb!-) All these are either taken verbatim from the definitions section or from the syntax/semantic description of the H.264 spec. Clearly, the payload format will not make much sense to anyone who doesn't have the payload spec itself in his/her hands, but isn't this true for all payload formats? Nevertheless, we may add some non-normative, explanatory text (don't know yet how much -- is a minor issue). With respect to the rest of this Email: A few points can be answered directly, without much discussions between the authors. On others I need to consult first. I removed the latter from the EMail to save space and reading time, and replaced them by [...]. [...] > Section 1.1 >[...] Describing these NALU as being "time-less" and of having > "presentation time [] not defined" could cause some mis- > understanding, another formulation could be: > > "Some NALU transport information that affect the decoding process > over a period of time corresponding to many video frames; For > these units, the handling of the RTP timestamp requires some > special considerations especially in cases where this duration is > unknown at transmission time." BTW the same remark applies in section > 6.1 for "If the NALU has > no own timing properties". You should also elaborate i.e. start > to present _how_ the "special considerations" are implemented in > the spec ... Here in Pattaya we decided a few hours ago that, for the purpose of the video buffer management (compliance tests and such, has nothing to do with RTP), all NAL units have a picture associated with and hence carry time. I heard that the MPEG systems folk use the same type of definition. Following this course would be the easy way out. However, there are NALU types which -- I continue to believe -- still inherently timeless. The two parameter set NALU types, for example, are, once they are transmitted and unless they are overwritten, valid for the lifetime of the session. We will try to add clarifying remarks to this section. > "The combination of the higher level parameters is called a Parameter > Set". > "which is a data structure akin to what is described as "decoder > configuration" in MPEG-4 specifications." Not sure whether they are really "akin" (I tend to believe they are not, but I will talk to people here and check whether such a comparison is valid. I also tend to believe that the MPEG-4 specs are not that well known that this remark would benefit a large user community, while it could guide others on the wrong path. Finally, I would like to avoid normatively referencing other MPEG documents but 14496 Part 10 (as I try to avoid mentioning ITU Recs such as H.245, which could be used to carry Parameter Sets as well and has a similar concept). >[...] "Although, conceptually, the Parameter Set updates are not >designed to be sent in the synchronous packet stream, this memo contains >means to convey them in the RTP packet stream." It is strange (actually >potentially contradictory: if they are not "designed" to be sent in >packets you would need to document how to map them into NALU but then why >the draft does not do that?) [...] Agreed to fix. Don't know how, yet, but this language is strange, indeed. >[...] >"The F bit when set to 1 signals that the NALU or header contains a syntax >error, in the context of this specification it may have been set by a >network device upon detection that a transmission error has affected the >corresponding data. A prudent reaction of decoders that are incapable of >handling bit errors is to discard such packets. " This language, while technically correct, is politically incorrect (at least for the JVT spec itself). I think what we have is good enough, but we will check whether informative language along the lines of your suggestion are possible. [...] > In section 6.3.1 [...] Miska and I are working on the complete DON and FU sections (6.3 and 6.4) here in Pattaya. I agree that both sections need some serious work. > In Section 7.1 about the sentence: >"Some receivers MAY NOT support a transmission order that does not conform >to the NAL unit decoding order. " >By what mean the sender can find out about that? unspecified control protocol means, or implicit (application dependent). I think this is mentioned, but we will double-check. > In Section 10. Security Considerations: > What about crashing a decoder by sending a lethal Parameter Set ? Or sending a lethal other NAL unit, e.g. an SEI that sets the video buffer size to 1 byte, or, or, or. There are many ways to kill a video codec. But I agree that there is work needed in the security section re asymmetric operation characteristics and user data. I hope to make some progress on that in San Francisco > References: > for [14] I found it online at: > http://www.diee.unica.it/pv2000/proceedings/papers/30.pdf > The link http://www.pv2002.org is broken(?) but I found that paper at: > http://www-video.eecs.berkeley.edu/papers/sangk7/pv2002.doc Thanks, will be added. I want to thank you (and Magnus) again for your careful proof-reading. This helps a lot. Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 19:31:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20600 for ; Tue, 11 Mar 2003 19:31:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C0iqD16476 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 19:44:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0iHO16444; Tue, 11 Mar 2003 19:44:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0h0O16381 for ; Tue, 11 Mar 2003 19:43:00 -0500 Received: from mail.cs.tu-berlin.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20534 for ; Tue, 11 Mar 2003 19:28:47 -0500 (EST) Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id BAA03213; Wed, 12 Mar 2003 01:24:29 +0100 (MET) Message-Id: <5.2.0.9.2.20030312054612.021ac590@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Mar 2003 05:46:57 +0700 To: philippe.gentric@philips.com From: Stephan Wenger Subject: Re: [AVT] H.264 payload spec: a question Cc: Magnus Westerlund , avt@ietf.org, Stephan Wenger 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: , Folks, At 02:52 PM 3/11/2003 +0100, philippe.gentric@philips.com wrote: >I agree this bit is not extremely useful >... and it is a better idea then to set it if all are discardable... Ok, logical OR. We'll change it in the next revision of the draft. Thanks, Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 20:11:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21636 for ; Tue, 11 Mar 2003 20:11:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C1OtL19195 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 20:24:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C1OWO19176; Tue, 11 Mar 2003 20:24:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C1NvO19153 for ; Tue, 11 Mar 2003 20:23:57 -0500 Received: from telchemy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21612 for ; Tue, 11 Mar 2003 20:09:43 -0500 (EST) Date: Tue, 11 Mar 2003 20:11:55 -0500 Message-Id: <200303112011.AA20316710@telchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Alan Clark" Reply-To: To: IETF AVT WG Subject: [AVT] Agenda discussion items on draft-ietf-avt-rtcp-report-extns-03.txt X-Mailer: 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 would like to progress this draft to last call at, or shortly after, this IETF meeting. Discussion items include:- - Title (RTP XR or RTCP Reporting Extensions?) - Have any IANA issues been resolved satistfactorily - Should SDP be included in this draft to permit negotiation or should that be in a separate more general draft - Support for sample based CODECs in VoIP metrics section We do plan to discuss and hopefully resolve some issues on the mailing list prior to the meeting. Alan Clark, Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Mar 11 22:07:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24282 for ; Tue, 11 Mar 2003 22:07:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C3L5R26547 for avt-archive@odin.ietf.org; Tue, 11 Mar 2003 22:21:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C3KdO26504; Tue, 11 Mar 2003 22:20:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C3HdO26272 for ; Tue, 11 Mar 2003 22:17:39 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24136; Tue, 11 Mar 2003 22:03:22 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id OAA17410; Wed, 12 Mar 2003 14:05:22 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa004G0; Wed Mar 12 14:05:12 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 14:05:14 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id GS4QSXT9; Wed, 12 Mar 2003 14:05:02 +1100 To: magnus.westerlund@era.ericsson.se Cc: avt@ietf.org, mmusic@ietf.org, Conrad.Parker@csiro.au Message-ID: <3E6EA41C.3010504@csiro.au> Date: Wed, 12 Mar 2003 14:06:04 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 Subject: Re: [AVT] new I-D on temporal URI addresses References: <3E66AF6D.7040106@csiro.au> <3E671F9E.7080706@era.ericsson.se> In-Reply-To: <3E671F9E.7080706@era.ericsson.se> 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 Magnus, all, You wrote as a summary: > I can see the usefulness of this proposal, however there is need to > resolve a number of issues: > - A general standardization or target certain URI schemes? > - Applicability on different media types and protocols needs to better > understood. > - Use of fragment or other URI syntax element, like parameter or query? > - Need for having ranges? > - The actual need for general parameters? Great to hear you liked the idea. Many thanks for your elaborate answer and well thought through comments, which I am very happy to address. 1) General mechanism questions, applicability to different media types and protocols: > First is the possibility to specify this as a general mechanism. It > seems that you want to have this to apply to all URI schemes. Is that > really possible? The question that you are addressing goes beyond whether our mechanism applies to all URI schemes. In http://www.w3.org/DesignIssues/Fragment.html Tim Berners-Lee states as an axiom that "The fragment ID spec for a new MIME type should be part of the MIME type registration process". This implies that the meaning of a fragment specification depends on the MIME type of the addressed resource. Therefore, the interpretation of a fragment has to be specified for each MIME type, and then probably again for each MIME type on each different scheme. Our I-D can only propose a generic way to specify time-offsets for time-continuous data and we are proposing it for http and rtsp where they make sense. As an example take QuickTime files. Apple registered the MIME type video/quicktime but the documentation does not have a specification of how to interpret fragment parts when the files are used in URIs. Our I-D would not automatically enable timed fragment offsets to be used with QuickTime files - it needs an active move from Apple to change their MIME type specification. The same holds true for RealMedia and WindowsMedia and any other time-continuous MIME type. In fact, I believe that no MIME type registration except for text/html includes a fragment interpretation section. > How do you know that the use of @ will not collide with > any usage? The "@" sign is a reserved character in the URI Generic Syntax (RFC2396). It is allowed as part of a fragment, but its use is reserved for special cases. No special case of the use of "@" is know to us or published with IETF and therefore we asume there will be no collisions. > For example the rtsp scheme does not define how to interpret > the fragment. So this is up to the server responding to a request. So > this can potentially already be used by some implementations. As this has never been suggested before, there won't be any existing implementations that use it. Streaming servers should however find it easy, to support this mechanism as they only have to copy the specification after the "@" sign into the appropriate rtsp timestamp field. > So a general question, what is the actually possibilities to standardize > such a solution? It needs some minor adjustments in the URI standard. As that standard is currently being changed/adapted, this could be the right time to get it adjusted. Then our mechanism can be provided as a Generic Syntax proposal and MIME type specifications for time-continuous data can elect to support it. That's my take. 2) Questions on "fragment" definition, ranges: > Second, is the usage of the fragment identifier. It seems that you tries > to redefine the meaning of the fragment identifier. See below. > > From RFC 2396: > > "When a URI reference is used to perform a retrieval action on the > identified resource, the optional fragment identifier, separated from > the URI by a crosshatch ("#") character, consists of additional > reference information to be interpreted by the user agent after the > retrieval action has been successfully completed. As such, it is not > part of a URI, but is often used in conjunction with a URI. > > fragment = *uric > > The semantics of a fragment identifier is a property of the data > resulting from a retrieval action, regardless of the type of URI used > in the reference. Therefore, the format and interpretation of > fragment identifiers is dependent on the media type [RFC2046] of the > retrieval result. The character restrictions described in Section 2 > for URI also apply to the fragment in a URI-reference. Individual > media types may define additional restrictions or structure within > the fragment for specifying different types of "partial views" that > can be identified within that media type." > > Two things strikes me as not being taken into account by your draft in > relation to this quote. The first is from the first paragraph of the > quote. The fragment identifier is interpreted by the user agent. While > in chapter 4 of your draft you clearly specifies that the server shall > interpret the fragment. This redefines the behavior of the fragment > identifier. We are aware that with the current URI specification, fragments only get interpreted on the user agent side. One way to overcome this problem is to use the Query part of the URI ("?") instead, but this creates other problems, iin the least overloading the meaning of "querying". Inherently, a temporal offset is a specification of a "fragment" in its core meaning and therefore we would prefer to use the "fragment" part. It makes everything much simpler. If there is no burning need to interpret the fragment identifier at the user agent, a change of the standard may be adequate. As the URI standard is currently reworked, we may get a chance to just do that (see URIBOF at next IETF meeting). > Secondly the interpretation of the fragment identifier is in relation to > the data resulting in the request. So in fact it seems that you need to > define the behavior on per media basis. Agreed. > I think the use of fragment to specify where in a media resource is > appropriate in some case. For example an RTSP URL that has a fragment of > the proposed type is useful. However as RTSP works the server shall not > interpret the fragment as this is pointless. Only the client needs to do > this and use that to determine the range to include in the PLAY request. > So again the usage rules in chapter 4 seems to be wrong. Thanks. We'll take that into account when working over it. > It seems that the time specification should be complemented to allow > specifying ranges. The result of a search or the part of your friends > wedding video that you want to point out would in most cases only be a > part of the video. Therefore both a start and stop time seems useful. > Then it is also a very short step to having multiple ranges allow one to > point out multiple parts of the same resource that are interesting. As we've had several requests for that feature, we should probably work that as an option into the next version of the document. > Also I think you have a few strange thing in the definition. First you > specify an attribute "start" that I think are pointless. Either you > totally skip the fragment or you can use "npt=0". Possibly. But sometimes you have a file that does not start at 0 but rather with a time offset (because e.g. it is mirroring a timecode from an analog band from where it got digitized). In this case, "start" makes sense and does not default to "npt=0". > Secondly it the defaulting to "npt". > This clashed with the general parameters. If you > use start then you have actually wrote "npt=start" which isn't defined. That's a matter of parsing sequence and probably adjustment of the BNF that we wrote in the document. The use of "npt" as default came from our experience with using the mechanism and the short form added much usability. > "now" works as long as this is based on the RTSP definitions of NPT, > however from your BNF definitions this is evidently not the case. So my > proposal is to skip having any default time scheme if you are going to > have general attributes that does not belong to a time scheme. I guess, a change of the BNF definition is more appropriate. Also, "start" and "now" seem to be useful for streaming and thus should be covered in URIs, too. Best Regards, Silvia. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 12 06:16:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00048 for ; Wed, 12 Mar 2003 06:16:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CBUSV03808 for avt-archive@odin.ietf.org; Wed, 12 Mar 2003 06:30:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBU7O03798; Wed, 12 Mar 2003 06:30:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBQvO03643 for ; Wed, 12 Mar 2003 06:26:57 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29975; Wed, 12 Mar 2003 06:12:30 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CBEWB3018035; Wed, 12 Mar 2003 12:14:32 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVN7FT9; Wed, 12 Mar 2003 12:14:31 +0100 Message-ID: <3E6F1697.4040607@era.ericsson.se> Date: Wed, 12 Mar 2003 12:14:31 +0100 X-Sybari-Trust: 6248bb2f 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvia.Pfeiffer@csiro.au CC: avt@ietf.org, mmusic@ietf.org, Conrad.Parker@csiro.au Subject: Re: [AVT] new I-D on temporal URI addresses References: <3E66AF6D.7040106@csiro.au> <3E671F9E.7080706@era.ericsson.se> <3E6EA41C.3010504@csiro.au> 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 Silvia, First I have a question on how you are going to go forward in IETF. Are you planning to take this work into any WG or do a individual submission? Then more comments below: Silvia.Pfeiffer@csiro.au wrote: > 1) General mechanism questions, applicability to different media types > and protocols: > >> First is the possibility to specify this as a general mechanism. It >> seems that you want to have this to apply to all URI schemes. Is that >> really possible? > > > The question that you are addressing goes beyond whether our mechanism > applies to all URI schemes. In > http://www.w3.org/DesignIssues/Fragment.html Tim Berners-Lee states as > an axiom that "The fragment ID spec for a new MIME type should be part > of the MIME type registration process". This implies that the meaning > of a fragment specification depends on the MIME type of the addressed > resource. Therefore, the interpretation of a fragment has to be > specified for each MIME type, and then probably again for each MIME > type on each different scheme. Our I-D can only propose a generic way > to specify time-offsets for time-continuous data and we are proposing > it for http and rtsp where they make sense. > > As an example take QuickTime files. Apple registered the MIME type > video/quicktime but the documentation does not have a specification of > how to interpret fragment parts when the files are used in URIs. Our > I-D would not automatically enable timed fragment offsets to be used > with QuickTime files - it needs an active move from Apple to change > their MIME type specification. The same holds true for RealMedia and > WindowsMedia and any other time-continuous MIME type. In fact, I > believe that no MIME type registration except for text/html includes a > fragment interpretation section. Thanks, for the explanation, it greatly clarifies this. However to my understanding the usage of MIME types is actually depending on the URI scheme. One simple example is to compare HTTP and RTSP. In HTTP you: 1) download the object specified by the URI. 2) Look at the MIME type of the downloaded object and sends it to its parser together with the fragment. 3) The parser takes the fragment into account when displaying the content. However for RTSP URI with a fragment one possible interpretation is to setup the presentation indicated by the URI. This setup results in that a media description is retrieved. This description has of course a MIME type. Is it to this description the the fragment applies? Or is it to a the presentation in general which does not have a MIME type, or is it to the media streams which can contain one or more different encodings perhaps identified by MIME types. My point with this example is that the schemes seems to be taken into account. For RTSP it seems in fact that it is time to start defining some fragment identifier behavior. > > > How do you know that the use of @ will not collide with > >> any usage? > > > The "@" sign is a reserved character in the URI Generic Syntax > (RFC2396). It is allowed as part of a fragment, but its use is > reserved for special cases. No special case of the use of "@" is know > to us or published with IETF and therefore we assume there will be no > collisions. Ok. > >> For example the rtsp scheme does not define how to interpret the >> fragment. So this is up to the server responding to a request. So >> this can potentially already be used by some implementations. > > > As this has never been suggested before, there won't be any existing > implementations that use it. Streaming servers should however find it > easy, to support this mechanism as they only have to copy the > specification after the "@" sign into the appropriate rtsp timestamp > field. I don't think we need to consider servers in this case, rather the clients as fragments should have been treated in accordance with the URI specification saying that fragment is a user agent problem. > >> So a general question, what is the actually possibilities to >> standardize such a solution? > > > It needs some minor adjustments in the URI standard. As that standard > is currently being changed/adapted, this could be the right time to > get it adjusted. Then our mechanism can be provided as a Generic > Syntax proposal and MIME type specifications for time-continuous data > can elect to support it. That's my take. I am not fully aware of what is happening with this. However I have seen a draft for making URI generic syntax to standard. Is that what you have in mind? To my knowledge the changes performed on a specification when going from draft to full standard are only clarifications. Technical changes are very limited if allowed at all. I think that any such extension as you are proposing will be a proposed standard. > > > 2) Questions on "fragment" definition, ranges: > >> Second, is the usage of the fragment identifier. It seems that you >> tries to redefine the meaning of the fragment identifier. See below. >> >> From RFC 2396: >> >> "When a URI reference is used to perform a retrieval action on the >> identified resource, the optional fragment identifier, separated from >> the URI by a crosshatch ("#") character, consists of additional >> reference information to be interpreted by the user agent after the >> retrieval action has been successfully completed. As such, it is not >> part of a URI, but is often used in conjunction with a URI. >> >> fragment = *uric >> >> The semantics of a fragment identifier is a property of the data >> resulting from a retrieval action, regardless of the type of URI used >> in the reference. Therefore, the format and interpretation of >> fragment identifiers is dependent on the media type [RFC2046] of the >> retrieval result. The character restrictions described in Section 2 >> for URI also apply to the fragment in a URI-reference. Individual >> media types may define additional restrictions or structure within >> the fragment for specifying different types of "partial views" that >> can be identified within that media type." >> >> Two things strikes me as not being taken into account by your draft >> in relation to this quote. The first is from the first paragraph of >> the quote. The fragment identifier is interpreted by the user agent. >> While in chapter 4 of your draft you clearly specifies that the >> server shall interpret the fragment. This redefines the behavior of >> the fragment identifier. > > > We are aware that with the current URI specification, fragments only > get interpreted on the user agent side. One way to overcome this > problem is to use the Query part of the URI ("?") instead, but this > creates other problems, in the least overloading the meaning of > "querying". Inherently, a temporal offset is a specification of a > "fragment" in its core meaning and therefore we would prefer to use > the "fragment" part. It makes everything much simpler. If there is no > burning need to interpret the fragment identifier at the user agent, a > change of the standard may be adequate. As the URI standard is > currently reworked, we may get a chance to just do that (see URIBOF at > next IETF meeting). For me it seems very bad step to redefine this. I think one should look at both use cases. There will still be plenty of reasons to use fragment on the client side. And as there is a large number of HTTP clients out there using the current definition it seems a bad move to redefine it. However one should also look into how to address this when one wants the server to perform the action. I can clearly understand the use case of having a server reduce large media files to only contain what one is interested of. I looked through the URIBOF agenda: http://www.ietf.org/ietf/03mar/uribof.txt . I could however not see that this issue would be part of the BOF. Are you planning to take up your proposal there? Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 12 08:43:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03253 for ; Wed, 12 Mar 2003 08:43:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CDvAr12978 for avt-archive@odin.ietf.org; Wed, 12 Mar 2003 08:57:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDugO12966; Wed, 12 Mar 2003 08:56:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CDtWO12940 for ; Wed, 12 Mar 2003 08:55:32 -0500 Received: from telchemy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03185 for ; Wed, 12 Mar 2003 08:41:03 -0500 (EST) Date: Wed, 12 Mar 2003 08:43:13 -0500 Message-Id: <200303120843.AA2818638@telchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Alan Clark" Reply-To: To: IETF AVT WG , Magnus Westerlund Subject: RE: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-03.txt X-Mailer: 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 Thanks for the comments. Timur will respond on the non-VoIP issues: >17. Section 4.7.4: The signal level calculations are not clear as Log10 has been separated into "log 10". We will correct to read "Log10" >18. Section 4.7.7: How does one use the jitter buffer sizes when one has a sample based codec and have no defined frame size, or for that matter if the frame size is variable? The goal of these metrics is to indicate the mean and max delays due to the jitter buffer and also provide a means of determining if the cause of excessive discards is an incorrectly configured jitter buffer. This can be achieved by specifying the jitter buffer characteristics in terms of milliseconds rather than packets or frames. If we took this approach then would it be sufficient to have the mean/max jitter buffer delay range from 0 to "255 or greater" mS? Regards Alan Clark Telchemy _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 12 08:51:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03486 for ; Wed, 12 Mar 2003 08:51:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CE5U213307 for avt-archive@odin.ietf.org; Wed, 12 Mar 2003 09:05:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CE56O13284; Wed, 12 Mar 2003 09:05:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CE4XO13243 for ; Wed, 12 Mar 2003 09:04:33 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03455 for ; Wed, 12 Mar 2003 08:50:03 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2CDqBB3011709; Wed, 12 Mar 2003 14:52:12 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVN8XFH; Wed, 12 Mar 2003 14:52:11 +0100 Message-ID: <3E6F3B8B.5040209@era.ericsson.se> Date: Wed, 12 Mar 2003 14:52:11 +0100 X-Sybari-Trust: 55de15ad 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alan@telchemy.com CC: IETF AVT WG Subject: Re: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-03.txt References: <200303120843.AA2818638@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, Alan Clark wrote: >>18. Section 4.7.7: How does one use the jitter buffer sizes when one has a sample based codec and have no defined frame size, or for that matter if the frame size is variable? >> >> > >The goal of these metrics is to indicate the mean and max delays due to the jitter buffer and also provide a means of determining if the cause of excessive discards is an incorrectly configured jitter buffer. This can be achieved by specifying the jitter buffer characteristics in terms of milliseconds rather than packets or frames. If we took this approach then would it be sufficient to have the mean/max jitter buffer delay range from 0 to "255 or greater" mS? > > I would say no. Why not define it as 5 or 10 ms. This would give more substantial range. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 12 09:41:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04640 for ; Wed, 12 Mar 2003 09:41:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CEtgj16614 for avt-archive@odin.ietf.org; Wed, 12 Mar 2003 09:55:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CEtLO16597; Wed, 12 Mar 2003 09:55:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CEsNO16545 for ; Wed, 12 Mar 2003 09:54:23 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04589 for ; Wed, 12 Mar 2003 09:39:52 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA07812 for ; Wed, 12 Mar 2003 15:42:00 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA06875 for ; Wed, 12 Mar 2003 15:42:01 +0100 (MET) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 15:41:45 +0100 Message-ID: From: Kreuter Ruediger To: "'avt@ietf.org'" Date: Wed, 12 Mar 2003 15:41:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2CEsNO16546 Subject: [AVT] Summary for the Clearmode draft presentation 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 Greetings, regarding: Thursday, 20th March at 09:00-11:30 =================================== RTP Payload Format for a 64 kbit/s transparent call (Kreuter) 15 draft-kreuter-avt-rtp-clearmode-02.txt This presentation will - give a motivation for Clearmode - discuss the MIME Media Type for Clearmode (which is the primary intention of this draft) - introduce a new parameter: "maxptime" that will show up in version 03 of this draft - introduce a new SDP parameter chapter that will show up in version 03 of this draft The current version 02 of this draft can be found at http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clearmode-02.txt For preparing the meeting you may also want to check http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-05.txt which deals with TDM Circuit Emulation Service over Packet Switched Network Best regards Rüdiger Kreuter _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 12 10:18:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07314 for ; Wed, 12 Mar 2003 10:18:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CFWJD19431 for avt-archive@odin.ietf.org; Wed, 12 Mar 2003 10:32:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFVqO19341; Wed, 12 Mar 2003 10:31:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFRHO18976 for ; Wed, 12 Mar 2003 10:27:17 -0500 Received: from telchemy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06577 for ; Wed, 12 Mar 2003 10:12:47 -0500 (EST) Date: Wed, 12 Mar 2003 10:14:57 -0500 Message-Id: <200303121014.AA88146516@telchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Alan Clark" Reply-To: To: , Magnus Westerlund CC: IETF AVT WG Subject: Re: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-03.txt X-Mailer: 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: , Proposed updated wording for Section 4.7.7 4.7.7 Jitter Buffer Parameters jitter buffer nominal delay in 5mS increments (JB nominal): 8 bits This is the current nominal delay through the jitter buffer which corresponds to the additional delay for packets that arrive on-time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer maximum delay in 5mS increments (JB Maximum): 8 bits This is the current maximum jitter buffer delay corresponding to the earliest...... jitter buffer absolute maximum delay in 5mS increments (JB abs max): 8 bits This is the absolute maximum delay that an adaptive jitter buffer can reach under.......... Regards Alan Clark Telchemy ---------- Original Message ---------------------------------- From: Magnus Westerlund Date: Wed, 12 Mar 2003 14:52:11 +0100 >Hi Alan, > >Alan Clark wrote: > >>>18. Section 4.7.7: How does one use the jitter buffer sizes when one has a sample based codec and have no defined frame size, or for that matter if the frame size is variable? >>> >>> >> >>The goal of these metrics is to indicate the mean and max delays due to the jitter buffer and also provide a means of determining if the cause of excessive discards is an incorrectly configured jitter buffer. This can be achieved by specifying the jitter buffer characteristics in terms of milliseconds rather than packets or frames. If we took this approach then would it be sufficient to have the mean/max jitter buffer delay range from 0 to "255 or greater" mS? >> >> > >I would say no. Why not define it as 5 or 10 ms. This would give more >substantial range. > >Cheers > >Magnus Westerlund > >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 12 16:15:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23246 for ; Wed, 12 Mar 2003 16:15:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLTpm16006 for avt-archive@odin.ietf.org; Wed, 12 Mar 2003 16:29:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLTBO15976; Wed, 12 Mar 2003 16:29:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLRvO15885 for ; Wed, 12 Mar 2003 16:27:57 -0500 Received: from mailf.telia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23147 for ; Wed, 12 Mar 2003 16:13:17 -0500 (EST) Received: from d1o265.telia.com (d1o265.telia.com [217.208.188.241]) by mailf.telia.com (8.12.8/8.12.8) with ESMTP id h2CLDZfb020633; Wed, 12 Mar 2003 22:13:35 +0100 (CET) Received: from eta (h80n1fls31o265.telia.com [217.208.188.80]) by d1o265.telia.com (8.10.2/8.10.1) with SMTP id h2CLDYt29239; Wed, 12 Mar 2003 22:13:34 +0100 (CET) From: =?us-ascii?Q?Gunnar_Hellstrom?= To: "Stephen Casner" , "Rajesh Kumar" Cc: , "mario Garakani" , , , Subject: SV: [AVT] Re: Need clarification on protocol type for RFC 2793 text media Date: Wed, 12 Mar 2003 22:06:46 +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: <20030311101618.R61871-100000@ash.packetdesign.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Rajesh, Stephen and Colin have already given you good answers. I can only add that it has become a habit to specify RFC2793 under the RTP/AVP model. It is used in 1.the examples in ITU-T H.248.2 2.In RFC 3551 http://www.ietf.org/rfc/rfc3351.txt?number=3351 3. In a transcoding draft http://www.ietf.org/internet-drafts/draft-camarillo-sip-deaf-01.txt Please notice that it would be a good habit to specify some redundancy. That could imply that a suitable m= specification ends up like this: m=text 49232 RTP/AVP 100 102 a=rtpmap:102 red a=fmtp: 102 100/100 a=rtpmap:100 t140 Best 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 -------------------------------------------- > -----Ursprungligt meddelande----- > Fran: avt-admin@ietf.org [mailto:avt-admin@ietf.org]For Stephen Casner > Skickat: den 11 mars 2003 19:27 > Till: Rajesh Kumar > Kopia: avt@ietf.org; gunnar.hellstrom@omnitor.se; mario Garakani; > paulej@packetizer.com; bfoster@cisco.com; rmahy@cisco.com > Amne: [AVT] Re: Need clarification on protocol type for RFC 2793 text > media > > > Rajesh, > > > While RFC 2793 defines an RTP encapsulation for the text media, > it does not > > clearly state that the SDP protocol name associated with the > MIME text/t140 > > is RTP/AVP. Can one assume that? > > It is intentional that the payload format does not specify the RTP > profile under which it may be used because it may be used under > different profiles for different applications if needed. > > At this moment, RTP/AVP is the only profile that has been published as > an RFC, but two more (RTP/SRTP and RTP/AVPF) are very close. > > > Of the five protocol names (SDP proto parameter values) listed > by the IANA > > at http://www.iana.org/assignments/sdp-parameters, RTP/AVP does > seem to be > > the most suitable. The other ones are rtp (historic), vat > (historic), udptl > > and tcp. One may, of course, define a new protocol name/profile that > > includes RTP encapsulations of text, but I would advise against > doing that. > > TTY devices often interleave voice and text, and it would be simpler to > > keep text/t140 under the RTP/AVP umbrella. > > Yes, it is appropriate to use text/t140 under rtp/avp. > > > It would be nice if RFC 2793 has SDP examples just as RFC 2198, > RFC 2733, > > RFC 2833 etc. do. But there are none. Here is a possible > example. Please > > let us know if this is what you had in mind when you registered the MIME > > type text/t140. > > Yes, having SDP examples is handy, although not required (since using > SDP is not required). > > > If an IP endpoint/gateway dedicates a UDP port to RFC 2793 text > relay, the > > media line for the text relay stream is as follows: > > m=text RTP/AVP > > a=rtpmap: t140 > > > > This is consistent with the text/t140 MIME definition in RFC > 2793. It maps > > an RTP payload type to the MIME text/t140. For example, > > > > m=text 49232 RTP/AVP 100 > > a=rtpmap:100 t140 > > > > indicates that the IP endpoint or gateway is willing to receive an RFC > > 2793-based RTP packet stream with a payload type of 100 on port 49232. > > The mapping you have shown is valid. It follows the established rules > in draft-ietf-mmusic-sdp-new-12.txt and draft-ietf-avt-rtp-mime-06.txt. > > -- 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 mailnull@www1.ietf.org Wed Mar 12 21:30:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04450 for ; Wed, 12 Mar 2003 21:30:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D2iHT06181 for avt-archive@odin.ietf.org; Wed, 12 Mar 2003 21:44:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D2htO06118; Wed, 12 Mar 2003 21:43:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D2g4O06040 for ; Wed, 12 Mar 2003 21:42:04 -0500 Received: from rumi.east.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04281 for ; Wed, 12 Mar 2003 21:27:20 -0500 (EST) Received: from rumi.east.isi.edu (localhost.east.isi.edu [127.0.0.1]) by rumi.east.isi.edu (8.12.6/8.12.6) with ESMTP id h2D2TTi0008754 for ; Wed, 12 Mar 2003 21:29:29 -0500 (EST) (envelope-from ladan@rumi.east.isi.edu) Message-Id: <200303130229.h2D2TTi0008754@rumi.east.isi.edu> Reply-to: ladan@isi.edu To: avt@ietf.org Date: Wed, 12 Mar 2003 21:29:29 -0500 From: Ladan Gharai Subject: [AVT] Summary for draft-ietf-avt-uncomp-video-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: , The following is a list of changes made to draft draft-ietf-avt-uncomp-video-02.txt. 1. the standard RTP header has been extended to 32bits. 2. 4:2:0 interlaced and progressive packetization 3. addition of 4:1:1 color coding 4. separate time stamps for interlaced fields (to accommodate reversing 3:2 pulldown) 5. definition of required and optional SDP parameters 6. text on congestion control in the security considerations. In addition to the changes, we would appreciate feedback on the remaining open issues: - should planar video be added to the draft or does it unduly complicate the draft? - is the SDP parameter for colorimetry sufficient? - should time codes have independent representation? or are the RTP timestamps and RTCP SR timestamps sufficient? thank you, Ladan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 04:41:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25347 for ; Thu, 13 Mar 2003 04:41:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D9uIT11248 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 04:56:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D9tuO11219; Thu, 13 Mar 2003 04:55:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D9sXO11154 for ; Thu, 13 Mar 2003 04:54:33 -0500 Received: from mail.cs.tu-berlin.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25283 for ; Thu, 13 Mar 2003 04:39:39 -0500 (EST) Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id KAA24550 for ; Thu, 13 Mar 2003 10:38:49 +0100 (MET) Message-Id: <5.2.0.9.2.20030313162433.022db908@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 16:38:25 +0700 To: avt@ietf.org From: Stephan Wenger Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Updated issues to discuss -- draft-ietf-avt-rtp-h264-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: , Folks, here is an updated list of the issues re the H.264/JVT packetization. It reflects mostly the discussions here in Pattaya, where MPEG and JVT currently meets: Unchanged items: 1. Status of JVT -- should be out for the final ballot by the time of the meeting. 2. Fragmentation -- we decided on adding application layer fragmentation of NALUs to support some exotic scenarios. I plan to describe the pros and cons of the fragmentation, and hope for more guidance from the meeting re these feature. We had discussed this briefly in Atlanta already, but it has turned out that I forgot some applications where fragmentation is useful. 3. MIME/SDP sections: are they ok? 4. Interaction with MPEG-4 simple packetization (since H.264 is also ISO/IEC 14496-10). Miska and I are currently in Pattaya at the JVT/MPEG meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim (and other knowledgeable people). We will have some discussions about the interaction of the two drafts, and report probably to the mailing list, but certainly orally at the meeting, about the outcome of these discussions. 5. I currently believe that the problem mentioned in section 12 of the draft doesn't exist, but we will discuss this here in Pattaya as well and take action as necessary. 6. Security section seems to need more work, but this is not reflected in the draft yet. We plan to present a summary of the problems and proposed solution if there is time left. New items: 7. Interoperability between MPEG-4 simple and H.264 packetization -- as it has turned out, we already have one common operation point. Now that AUs are syntactically defined in MPEG-4, we can add something similar to a STAP that adds another common operation point. Our goal is to make this draft a binary-compatible superset of the MP4-Simple draft when carrying H.264, but it is unclear whether this can be achieved. 8. MIME/SDP codepoints to support out-of-level picture sizes -- the video conferencing industry needs to support extreme picture sizes (e.g. 1500 x 1000 pels) at low frame rates, for example for document cameras. However, they don't want to signal a profile/level combination that allows for this picture size (memory requirements), because that also implies the ability to decode high speed bit streams at high frame rates (computational requirements). Such codepoints are in principle agreed in the ITU-T H.245 protocol, and we are asked to add similar codepoints in the MIME/SDP. 9. I will be prepared to explain DON (why it is there, and it works), but we admit that there is an urgent need for clearer language for both. Regards, Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 05:21:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25882 for ; Thu, 13 Mar 2003 05:21:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DAZiK13605 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 05:35:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DAZLO13586; Thu, 13 Mar 2003 05:35:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DAYWO13544 for ; Thu, 13 Mar 2003 05:34:32 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25833 for ; Thu, 13 Mar 2003 05:19:39 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl6.philips.com (Postfix) with ESMTP id 6D576A6CE7; Thu, 13 Mar 2003 11:21:47 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA18878; Thu, 13 Mar 2003 11:21:47 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA04770; Thu, 13 Mar 2003 11:21:43 +0100 (MET) Subject: Re: [AVT] Summary for draft-ietf-avt-uncomp-video-02.txt To: ladan@isi.edu Cc: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Mar 2003 11:14:32 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/03/2003 11:22: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: , ladan, >In addition to the changes, we would appreciate feedback on the >remaining open issues: > - should planar video be added to the draft or does it unduly > complicate the draft? Since I was the original proposer of this I feel it is my duty to kill it:-) the purpose would have been to optimize the transport in terms of memory management and data locality when processing the format (at both sender and receiver) After analysis, this type of optimization is dependent on the application and probably brings only marginal performance gain. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 05:21:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25902 for ; Thu, 13 Mar 2003 05:21:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DAaH813652 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 05:36:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DAa1O13644; Thu, 13 Mar 2003 05:36:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DAZLO13582 for ; Thu, 13 Mar 2003 05:35:21 -0500 Received: from accord-ntsrv3.polycom.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25846 for ; Thu, 13 Mar 2003 05:20:26 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 12:22:12 +0200 Message-ID: From: "Even, Roni" To: "'Stephan Wenger'" , avt@ietf.org Subject: RE: [AVT] Updated issues to discuss -- draft-ietf-avt-rtp-h264-01 .txt Date: Thu, 13 Mar 2003 12:22:11 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) 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 would like to point out that there are problems with supporting parameters sets in multipoint video conferencing scenarios. When using out of band signalling for the parameter sets if a video switch need to occur then there is a need for a new parameter set for the new video stream and it has to be available to the receiver before the actual stream. The current work at the ITU suggests to use in band parameter sets and to send the parameter sets before the full picture as a response to a fast update request. (available in the RTCP feedback draft) Regards Roni Even > -----Original Message----- > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > Sent: Thursday, March 13, 2003 11:38 AM > To: avt@ietf.org > Subject: [AVT] Updated issues to discuss -- > draft-ietf-avt-rtp-h264-01.txt > > > Folks, > here is an updated list of the issues re the H.264/JVT > packetization. It > reflects mostly the discussions here in Pattaya, where MPEG and JVT > currently meets: > > Unchanged items: > 1. Status of JVT -- should be out for the final ballot by the > time of the > meeting. > 2. Fragmentation -- we decided on adding application layer > fragmentation of > NALUs to support some exotic scenarios. I plan to describe > the pros and > cons of the fragmentation, and hope for more guidance from > the meeting re > these feature. We had discussed this briefly in Atlanta > already, but it > has turned out that I forgot some applications where > fragmentation is useful. > 3. MIME/SDP sections: are they ok? > 4. Interaction with MPEG-4 simple packetization (since H.264 is also > ISO/IEC 14496-10). Miska and I are currently in Pattaya at > the JVT/MPEG > meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim > (and other > knowledgeable people). We will have some discussions about > the interaction > of the two drafts, and report probably to the mailing list, > but certainly > orally at the meeting, about the outcome of these discussions. > 5. I currently believe that the problem mentioned in section > 12 of the > draft doesn't exist, but we will discuss this here in Pattaya > as well and > take action as necessary. > 6. Security section seems to need more work, but this is not > reflected in > the draft yet. We plan to present a summary of the problems > and proposed > solution if there is time left. > > New items: > 7. Interoperability between MPEG-4 simple and H.264 > packetization -- as it > has turned out, we already have one common operation point. > Now that AUs > are syntactically defined in MPEG-4, we can add something > similar to a STAP > that adds another common operation point. Our goal is to > make this draft a > binary-compatible superset of the MP4-Simple draft when > carrying H.264, but > it is unclear whether this can be achieved. > 8. MIME/SDP codepoints to support out-of-level picture sizes > -- the video > conferencing industry needs to support extreme picture sizes > (e.g. 1500 x > 1000 pels) at low frame rates, for example for document > cameras. However, > they don't want to signal a profile/level combination that > allows for this > picture size (memory requirements), because that also implies > the ability > to decode high speed bit streams at high frame rates (computational > requirements). Such codepoints are in principle agreed in > the ITU-T H.245 > protocol, and we are asked to add similar codepoints in the MIME/SDP. > 9. I will be prepared to explain DON (why it is there, and it > works), but > we admit that there is an urgent need for clearer language for both. > > Regards, > Stephan > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Mar 13 06:52:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27568 for ; Thu, 13 Mar 2003 06:52:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DC6uL19491 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 07:06:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DC6aO19475; Thu, 13 Mar 2003 07:06:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DC5dO19436 for ; Thu, 13 Mar 2003 07:05:39 -0500 Received: from mail.cs.tu-berlin.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27542 for ; Thu, 13 Mar 2003 06:50:43 -0500 (EST) Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id MAA14924; Thu, 13 Mar 2003 12:49:29 +0100 (MET) Message-Id: <5.2.0.9.2.20030313183334.01a2f6f8@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 18:49:11 +0700 To: "Even, Roni" From: Stephan Wenger Subject: RE: [AVT] Updated issues to discuss -- draft-ietf-avt-rtp-h264-01 .txt Cc: "'Stephan Wenger'" , avt@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: , Hi Roni, At 12:22 PM 3/13/2003 +0200, Even, Roni wrote: >[...] >I would like to point out that there are problems with supporting >parameters sets in multipoint video conferencing scenarios. >[...] First, please let me point out that Roni's multipoint is not the multipoint most of the AVT'ers would think of. Roni speaks, I believe, primarily about a multipoint scenario where a central Multipoint Control Unit (MCU) is employed. For those who don't know, an MCU is something similar to, but not quite the same as, an RTP Mixer. It also allows for stream switching in the same RTP session, in addition to spatial mixing (actually, there are product that do switching only). Second, I agree that there are issues with parameter sets in these scenarios, and I know that people in the ITU are working on those. I am one of them. If the outcome of the ITU discussions is that they will use in-band parameter sets over IP links, then there is indeed a need to send parameter sets closely aligned to the IDR pictures. Hence, technically, Roni and me are in a perfect technical agreement. However, the question is whether the RTP payload specification is the right place to express the mentioned need. There are many totally valid examples, where RTP-based video, even when using in-band parameter sets, will NOT require the parameter sets being sent with the IDR picture. And I think I could also come up with at least one example where it would actually be harmful to do so. Also, I haven't seen similar statements in RFC2429, where the analog language would be that you have to send the full picture header with all it's extensions with every I picture (or, at least, after every Full Intra Request or something). We may add an informal comment on the close relationship between parameter sets and IDR pictures in H.264, but more seems to be inappropriate. However, I would be more than happy to learn what draft/RFC would be the right place (in the ITU world, IMHO the right place would be the system overview spec, e.g. H.320 or H.323). Regards, Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 06:55:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27646 for ; Thu, 13 Mar 2003 06:55:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DCANA20423 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 07:10:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCA3O20401; Thu, 13 Mar 2003 07:10:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DC9tO20351 for ; Thu, 13 Mar 2003 07:09:55 -0500 Received: from accord-ntsrv3.polycom.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27618 for ; Thu, 13 Mar 2003 06:54:59 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 13:56:45 +0200 Message-ID: From: "Even, Roni" To: "'Stephan Wenger'" , "Even, Roni" Cc: avt@ietf.org Subject: RE: [AVT] Updated issues to discuss -- draft-ietf-avt-rtp-h264-01 .txt Date: Thu, 13 Mar 2003 13:56:45 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Stephan, In the RTP world how will parameter sets work when a mixer is involved. It is the same problem. Roni > -----Original Message----- > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > Sent: Thursday, March 13, 2003 1:49 PM > To: Even, Roni > Cc: 'Stephan Wenger'; avt@ietf.org > Subject: RE: [AVT] Updated issues to discuss -- > draft-ietf-avt-rtp-h264-01 .txt > > > Hi Roni, > > At 12:22 PM 3/13/2003 +0200, Even, Roni wrote: > >[...] > >I would like to point out that there are problems with supporting > >parameters sets in multipoint video conferencing scenarios. > >[...] > > First, please let me point out that Roni's multipoint is not > the multipoint > most of the AVT'ers would think of. Roni speaks, I believe, > primarily > about a multipoint scenario where a central Multipoint > Control Unit (MCU) > is employed. For those who don't know, an MCU is something > similar to, but > not quite the same as, an RTP Mixer. It also allows for > stream switching > in the same RTP session, in addition to spatial mixing > (actually, there are > product that do switching only). > > Second, I agree that there are issues with parameter sets in these > scenarios, and I know that people in the ITU are working on > those. I am > one of them. If the outcome of the ITU discussions is that > they will use > in-band parameter sets over IP links, then there is indeed a > need to send > parameter sets closely aligned to the IDR pictures. Hence, > technically, > Roni and me are in a perfect technical agreement. > > However, the question is whether the RTP payload > specification is the right > place to express the mentioned need. There are many totally valid > examples, where RTP-based video, even when using in-band > parameter sets, > will NOT require the parameter sets being sent with the IDR > picture. And I > think I could also come up with at least one example where it would > actually be harmful to do so. > > Also, I haven't seen similar statements in RFC2429, where the analog > language would be that you have to send the full picture > header with all > it's extensions with every I picture (or, at least, after > every Full Intra > Request or something). > > We may add an informal comment on the close relationship > between parameter > sets and IDR pictures in H.264, but more seems to be > inappropriate. However, I would be more than happy to learn > what draft/RFC > would be the right place (in the ITU world, IMHO the right > place would be > the system overview spec, e.g. H.320 or H.323). > > Regards, > Stephan > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 07:06:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27846 for ; Thu, 13 Mar 2003 07:06:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DCLLI20962 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 07:21:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCL7O20950; Thu, 13 Mar 2003 07:21:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCKhO20903 for ; Thu, 13 Mar 2003 07:20:43 -0500 Received: from accord-ntsrv3.polycom.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27830 for ; Thu, 13 Mar 2003 07:05:47 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 14:07:33 +0200 Message-ID: From: "Even, Roni" To: "'Stephan Wenger'" , "Even, Roni" Cc: "'avt@ietf.org'" Subject: RE: [AVT] Updated issues to discuss -- draft-ietf-avt-rtp-h264-01 .txt Date: Thu, 13 Mar 2003 14:07:33 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Stephan, I do not see how H.264 work through RTP level mixers and transcoders without sending the parameter sets in band Roni Stephan, In the RTP world how will parameter sets work when a mixer is involved. It is the same problem. Roni > -----Original Message----- > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > Sent: Thursday, March 13, 2003 1:49 PM > To: Even, Roni > Cc: 'Stephan Wenger'; avt@ietf.org > Subject: RE: [AVT] Updated issues to discuss -- > draft-ietf-avt-rtp-h264-01 .txt > > > Hi Roni, > > At 12:22 PM 3/13/2003 +0200, Even, Roni wrote: > >[...] > >I would like to point out that there are problems with supporting > >parameters sets in multipoint video conferencing scenarios. > >[...] > > First, please let me point out that Roni's multipoint is not > the multipoint > most of the AVT'ers would think of. Roni speaks, I believe, > primarily > about a multipoint scenario where a central Multipoint > Control Unit (MCU) > is employed. For those who don't know, an MCU is something > similar to, but > not quite the same as, an RTP Mixer. It also allows for > stream switching > in the same RTP session, in addition to spatial mixing > (actually, there are > product that do switching only). > > Second, I agree that there are issues with parameter sets in these > scenarios, and I know that people in the ITU are working on > those. I am > one of them. If the outcome of the ITU discussions is that > they will use > in-band parameter sets over IP links, then there is indeed a > need to send > parameter sets closely aligned to the IDR pictures. Hence, > technically, > Roni and me are in a perfect technical agreement. > > However, the question is whether the RTP payload > specification is the right > place to express the mentioned need. There are many totally valid > examples, where RTP-based video, even when using in-band > parameter sets, > will NOT require the parameter sets being sent with the IDR > picture. And I > think I could also come up with at least one example where it would > actually be harmful to do so. > > Also, I haven't seen similar statements in RFC2429, where the analog > language would be that you have to send the full picture > header with all > it's extensions with every I picture (or, at least, after > every Full Intra > Request or something). > > We may add an informal comment on the close relationship > between parameter > sets and IDR pictures in H.264, but more seems to be > inappropriate. However, I would be more than happy to learn > what draft/RFC > would be the right place (in the ITU world, IMHO the right > place would be > the system overview spec, e.g. H.320 or H.323). > > Regards, > Stephan > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 09:38:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02079 for ; Thu, 13 Mar 2003 09:38:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DEqW500424 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 09:52:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEpjO00340; Thu, 13 Mar 2003 09:51:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEoYO32718 for ; Thu, 13 Mar 2003 09:50:34 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01998 for ; Thu, 13 Mar 2003 09:35:33 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id D046E8F752; Thu, 13 Mar 2003 15:37:42 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA19537; Thu, 13 Mar 2003 15:37:42 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id PAA29177; Thu, 13 Mar 2003 15:37:40 +0100 (MET) Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS To: "Even, Roni" Cc: avt@ietf.org, "'Stephan Wenger'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Mar 2003 15:30:41 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/03/2003 15:38:41 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: , Roni, Thank you for bringing this up. Stephan, After reflexion the sentence in the draft: " Although, conceptually, the Parameter Set updates are not designed to be sent in the synchronous packet stream, this memo contains means to convey them in the RTP packet stream. " looks very dangerous to me. let me explain. ************************************************************************* H.264 has been designed with the capability to change the configuration dynamically and possibly very often (at every frame!) I wish it was clear for everyone that this directly impacts the concept of "Random Access Point", which is very different depending on applications: I assume you want to use the "fast update request" to send the parameter set ID(s) of the missing PS when a client "jumps" into a stream so as to cause the sender to insert the relevant (missing) PS in the stream. I conclude that in your application it is acceptable to have a "black screen" while the decoder waits for the full list of useful PS(s).... BTW I am concerned by the possibility that -since each single frame of the stream may have a different PS and that H264 supports 8k different PS for a stream- you may spend the first minutes sending requests for missing PS(s) and in the meanwhile display either black or a bad slide show! but Ok, this is your application right ? Now thinking about that made me push the reasoning one more step: It looks to me that H264 has pushed the flexibility so far that using "fast update request" to get PS(s) can rapidly become more like resorting to retransmission in case of "vital" packet losses ... a bad idea usually :-( I.e. the problem of random access generalizes to an error resilience issue, and I have to insist that: 1) in band PS is *bad* for error resilience 2) and that this is true for *all applications* using non-reliable transport e.g. RTP *************** The obvious *safe* alternative is to include all the required PS(s) in the initial session setup. *************** Anyway ...let me translate this to the VOD media distribution case. A) a first concern is the conformance of a decoder with regard to the support of PS in band. We need to scope it in the RTP payload because implementing a VOD system that supports PS inband is *much* more difficult and *not desirable* as follows: B) with video on demand you would get in trouble when a media player performs a jump and discovers it cannot decode the video it is receiving because it misses some PS(s) that are embedded in the stream "before" the jump ! there are 3 solutions there * jump on "complete" PS(s) updates only (unefficient and unpractical) * implement a dedicated trick in the streaming server so that it scans the stream and looks up all the required PS(s) (ouch!) to include them in some kind of "primer" in the first RTP packets (and risk to loose them!) * do not use in band PS, put all the required PS(s) in the SDP instead! So you understand the choice is simple: for VOD we dont want in band PS ! *********** Conclusion: I can only marginaly understand you may want to have in band PS but there MUST be a way to make conformant systems that do not need to implement it, therefore that sentence should be: "This memo contains means to convey Parameter Set updates in the RTP packet stream; but since, conceptually, these are not designed to be sent in the synchronous packet stream, supporting in band Parameter Set transmission is OPTIONAL". regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: "'Stephan Wenger'" avt@ietf.org cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: RE: [AVT] Updated issues to discuss -- draft-ietf-avt-rtp-h264-01 "Even, Roni" .txt Classification: Sent by: avt-admin@ietf.org 13/03/2003 11:22 Hi, I would like to point out that there are problems with supporting parameters sets in multipoint video conferencing scenarios. When using out of band signalling for the parameter sets if a video switch need to occur then there is a need for a new parameter set for the new video stream and it has to be available to the receiver before the actual stream. The current work at the ITU suggests to use in band parameter sets and to send the parameter sets before the full picture as a response to a fast update request. (available in the RTCP feedback draft) Regards Roni Even > -----Original Message----- > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > Sent: Thursday, March 13, 2003 11:38 AM > To: avt@ietf.org > Subject: [AVT] Updated issues to discuss -- > draft-ietf-avt-rtp-h264-01.txt > > > Folks, > here is an updated list of the issues re the H.264/JVT > packetization. It > reflects mostly the discussions here in Pattaya, where MPEG and JVT > currently meets: > > Unchanged items: > 1. Status of JVT -- should be out for the final ballot by the > time of the > meeting. > 2. Fragmentation -- we decided on adding application layer > fragmentation of > NALUs to support some exotic scenarios. I plan to describe > the pros and > cons of the fragmentation, and hope for more guidance from > the meeting re > these feature. We had discussed this briefly in Atlanta > already, but it > has turned out that I forgot some applications where > fragmentation is useful. > 3. MIME/SDP sections: are they ok? > 4. Interaction with MPEG-4 simple packetization (since H.264 is also > ISO/IEC 14496-10). Miska and I are currently in Pattaya at > the JVT/MPEG > meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim > (and other > knowledgeable people). We will have some discussions about > the interaction > of the two drafts, and report probably to the mailing list, > but certainly > orally at the meeting, about the outcome of these discussions. > 5. I currently believe that the problem mentioned in section > 12 of the > draft doesn't exist, but we will discuss this here in Pattaya > as well and > take action as necessary. > 6. Security section seems to need more work, but this is not > reflected in > the draft yet. We plan to present a summary of the problems > and proposed > solution if there is time left. > > New items: > 7. Interoperability between MPEG-4 simple and H.264 > packetization -- as it > has turned out, we already have one common operation point. > Now that AUs > are syntactically defined in MPEG-4, we can add something > similar to a STAP > that adds another common operation point. Our goal is to > make this draft a > binary-compatible superset of the MP4-Simple draft when > carrying H.264, but > it is unclear whether this can be achieved. > 8. MIME/SDP codepoints to support out-of-level picture sizes > -- the video > conferencing industry needs to support extreme picture sizes > (e.g. 1500 x > 1000 pels) at low frame rates, for example for document > cameras. However, > they don't want to signal a profile/level combination that > allows for this > picture size (memory requirements), because that also implies > the ability > to decode high speed bit streams at high frame rates (computational > requirements). Such codepoints are in principle agreed in > the ITU-T H.245 > protocol, and we are asked to add similar codepoints in the MIME/SDP. > 9. I will be prepared to explain DON (why it is there, and it > works), but > we admit that there is an urgent need for clearer language for both. > > Regards, > Stephan > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Mar 13 10:16:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04939 for ; Thu, 13 Mar 2003 10:16:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DFV2C03604 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 10:31:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFUKO03523; Thu, 13 Mar 2003 10:30:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFT7O03413 for ; Thu, 13 Mar 2003 10:29:07 -0500 Received: from accord-ntsrv3.polycom.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04586 for ; Thu, 13 Mar 2003 10:14:03 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 17:15:50 +0200 Message-ID: From: "Even, Roni" To: "'philippe.gentric@philips.com'" , "Even, Roni" Cc: avt@ietf.org, "'Stephan Wenger'" Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS Date: Thu, 13 Mar 2003 17:15:47 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) 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 Phillippe, About your VOD example. I do not see the difference between the PS and the full picture. If you skip frames you may need to look for some full frame if you the new frame is not referencing a full frame that is in the decoder buffers. In the case of Parameter Sets it is even simpler since the right way will be to send all the parameter sets you intend to use in the beginning of the connection between the media player client and the server. As for error resilience I am OK with your comment. The number of parameter sets is not the only issue but also if you have for example a multicast group and one end point is transmitting it may have used 3 parameter sets, than a different end point is transmitting using the same parameter sets but their order in the set is different. There is a need to send the new parameter sets. As for the paragraph I would like to have it as "This memo contains means to convey Parameter Set updates in the RTP packet stream; supporting of in band Parameter Set transmission is application dependent. When using in band Parameter Set, the Parameter sets should be sent as part of the response to an RTCP picture loss indication ". Regards Roni Even > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, March 13, 2003 4:31 PM > To: Even, Roni > Cc: avt@ietf.org; 'Stephan Wenger' > Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS > > > Roni, > > Thank you for bringing this up. > > Stephan, > > After reflexion the sentence in the draft: > > " Although, conceptually, the Parameter Set updates are > not designed > to be sent in the synchronous packet stream, this memo contains > means to convey them in the RTP packet stream. " > > looks very dangerous to me. > > let me explain. > > ************************************************************** > *********** > > H.264 has been designed with the capability to change the > configuration > dynamically and possibly very often (at every frame!) I wish > it was clear for > everyone that this directly impacts the concept of "Random > Access Point", > which is very different depending on applications: > > I assume you want to use the "fast update request" to send > the parameter set ID(s) > of the missing PS when a client "jumps" into a stream so as > to cause the sender to insert > the relevant (missing) PS in the stream. > > I conclude that in your application it is acceptable to have > a "black screen" while > the decoder waits for the full list of useful PS(s).... > > BTW I am concerned by the possibility that -since each > single frame of the stream > may have a different PS and that H264 supports 8k different > PS for a stream- > you may spend the first minutes sending requests for missing PS(s) > and in the meanwhile display either black or a bad slide show! > > but Ok, this is your application right ? > > Now thinking about that made me push the reasoning one more step: > It looks to me that H264 has pushed the flexibility so far that using > "fast update request" to get PS(s) can rapidly become > more like resorting to retransmission in case of "vital" packet losses > ... a bad idea usually :-( > > I.e. the problem of random access generalizes to an error > resilience issue, > and I have to insist that: > > 1) in band PS is *bad* for error resilience > > 2) and that this is true for *all applications* using > non-reliable transport e.g. RTP > > *************** > > The obvious *safe* alternative is to include all the > required PS(s) in the initial session setup. > > *************** > > Anyway ...let me translate this to the VOD media distribution case. > > A) a first concern is the conformance of a decoder with > regard to the support of PS in band. > > We need to scope it in the RTP payload because > implementing a VOD system that supports PS inband is > *much* more difficult and *not desirable* as follows: > > B) with video on demand you would get in trouble when a media player > performs a jump and discovers it cannot decode the video > it is receiving because it misses some PS(s) that are > embedded in the stream > "before" the jump ! > > there are 3 solutions there > > * jump on "complete" PS(s) updates only (unefficient and unpractical) > > * implement a dedicated trick in the streaming server so that it scans > the stream and looks up all the required PS(s) (ouch!) to > include them in > some kind of "primer" in the first RTP packets (and risk to > loose them!) > > * do not use in band PS, put all the required PS(s) in the > SDP instead! > > So you understand the choice is simple: for VOD we dont want > in band PS ! > > *********** > > Conclusion: I can only marginaly understand you may want to > have in band PS > but there MUST be a way to make conformant systems that do > not need to implement it, > > therefore that sentence should be: > > "This memo contains means to convey Parameter Set updates in > the RTP packet stream; > but since, conceptually, these are not designed to be sent in > the synchronous packet stream, > supporting in band Parameter Set transmission is OPTIONAL". > > regards, > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > > > > > To: > "'Stephan Wenger'" > > > avt@ietf.org > > cc: > (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) > > Subject: > RE: [AVT] Updated issues to discuss -- > draft-ietf-avt-rtp-h264-01 > "Even, Roni" .txt > > > > > > > Classification: > > > > > Sent by: > > > avt-admin@ietf.org > > > > > > 13/03/2003 11:22 > > > > > > > > > > > > > Hi, > I would like to point out that there are problems with > supporting parameters > sets in multipoint video conferencing scenarios. When using > out of band > signalling for the parameter sets if a video switch need to > occur then there > is a need for a new parameter set for the new video stream > and it has to be > available to the receiver before the actual stream. > The current work at the ITU suggests to use in band parameter > sets and to > send the parameter sets before the full picture as a response > to a fast > update request. (available in the RTCP feedback draft) > Regards > Roni Even > > > -----Original Message----- > > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > > Sent: Thursday, March 13, 2003 11:38 AM > > To: avt@ietf.org > > Subject: [AVT] Updated issues to discuss -- > > draft-ietf-avt-rtp-h264-01.txt > > > > > > Folks, > > here is an updated list of the issues re the H.264/JVT > > packetization. It > > reflects mostly the discussions here in Pattaya, where MPEG and JVT > > currently meets: > > > > Unchanged items: > > 1. Status of JVT -- should be out for the final ballot by the > > time of the > > meeting. > > 2. Fragmentation -- we decided on adding application layer > > fragmentation of > > NALUs to support some exotic scenarios. I plan to describe > > the pros and > > cons of the fragmentation, and hope for more guidance from > > the meeting re > > these feature. We had discussed this briefly in Atlanta > > already, but it > > has turned out that I forgot some applications where > > fragmentation is useful. > > 3. MIME/SDP sections: are they ok? > > 4. Interaction with MPEG-4 simple packetization (since H.264 is also > > ISO/IEC 14496-10). Miska and I are currently in Pattaya at > > the JVT/MPEG > > meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim > > (and other > > knowledgeable people). We will have some discussions about > > the interaction > > of the two drafts, and report probably to the mailing list, > > but certainly > > orally at the meeting, about the outcome of these discussions. > > 5. I currently believe that the problem mentioned in section > > 12 of the > > draft doesn't exist, but we will discuss this here in Pattaya > > as well and > > take action as necessary. > > 6. Security section seems to need more work, but this is not > > reflected in > > the draft yet. We plan to present a summary of the problems > > and proposed > > solution if there is time left. > > > > New items: > > 7. Interoperability between MPEG-4 simple and H.264 > > packetization -- as it > > has turned out, we already have one common operation point. > > Now that AUs > > are syntactically defined in MPEG-4, we can add something > > similar to a STAP > > that adds another common operation point. Our goal is to > > make this draft a > > binary-compatible superset of the MP4-Simple draft when > > carrying H.264, but > > it is unclear whether this can be achieved. > > 8. MIME/SDP codepoints to support out-of-level picture sizes > > -- the video > > conferencing industry needs to support extreme picture sizes > > (e.g. 1500 x > > 1000 pels) at low frame rates, for example for document > > cameras. However, > > they don't want to signal a profile/level combination that > > allows for this > > picture size (memory requirements), because that also implies > > the ability > > to decode high speed bit streams at high frame rates (computational > > requirements). Such codepoints are in principle agreed in > > the ITU-T H.245 > > protocol, and we are asked to add similar codepoints in the > MIME/SDP. > > 9. I will be prepared to explain DON (why it is there, and it > > works), but > > we admit that there is an urgent need for clearer language for both. > > > > Regards, > > Stephan > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Thu Mar 13 10:31:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05530 for ; Thu, 13 Mar 2003 10:31:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DFjgS05294 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 10:45:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFj7O05219; Thu, 13 Mar 2003 10:45:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFifO05162 for ; Thu, 13 Mar 2003 10:44:41 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05418 for ; Thu, 13 Mar 2003 10:29:37 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 402FEA35F8; Thu, 13 Mar 2003 16:31:47 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA06137; Thu, 13 Mar 2003 16:31:46 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA23854; Thu, 13 Mar 2003 16:31:45 +0100 (MET) Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS To: "Even, Roni" Cc: avt@ietf.org, "'Stephan Wenger'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Mar 2003 16:24:55 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/03/2003 16:32:46 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: , Roni, you write: > In the case of Parameter Sets it is even simpler since the right > way will be to send all the parameter sets you intend to use in the > beginning of the connection between the media player client and the server. Ah but that is *exactly* the point ! I know I need to convey all the required parameter sets to my decoder *before* starting to decode My point is that since I have 2 ways to do it: * out of band and reliable (typically SDP on TCP) or * in band and not reliable I prefer to do it out of band and *reliable* of course! All the more so since anyway I have already a session to setup with several round trips and a SDP to exchange etc ... How can it be better to do it in band ? regards Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 "Even, Roni" cc: avt@ietf.org "'Stephan Wenger'" "Even, Roni" Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS Classification: 13/03/2003 16:15 Hi Phillippe, About your VOD example. I do not see the difference between the PS and the full picture. If you skip frames you may need to look for some full frame if you the new frame is not referencing a full frame that is in the decoder buffers. In the case of Parameter Sets it is even simpler since the right way will be to send all the parameter sets you intend to use in the beginning of the connection between the media player client and the server. As for error resilience I am OK with your comment. The number of parameter sets is not the only issue but also if you have for example a multicast group and one end point is transmitting it may have used 3 parameter sets, than a different end point is transmitting using the same parameter sets but their order in the set is different. There is a need to send the new parameter sets. As for the paragraph I would like to have it as "This memo contains means to convey Parameter Set updates in the RTP packet stream; supporting of in band Parameter Set transmission is application dependent. When using in band Parameter Set, the Parameter sets should be sent as part of the response to an RTCP picture loss indication ". Regards Roni Even > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, March 13, 2003 4:31 PM > To: Even, Roni > Cc: avt@ietf.org; 'Stephan Wenger' > Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS > > > Roni, > > Thank you for bringing this up. > > Stephan, > > After reflexion the sentence in the draft: > > " Although, conceptually, the Parameter Set updates are > not designed > to be sent in the synchronous packet stream, this memo contains > means to convey them in the RTP packet stream. " > > looks very dangerous to me. > > let me explain. > > ************************************************************** > *********** > > H.264 has been designed with the capability to change the > configuration > dynamically and possibly very often (at every frame!) I wish > it was clear for > everyone that this directly impacts the concept of "Random > Access Point", > which is very different depending on applications: > > I assume you want to use the "fast update request" to send > the parameter set ID(s) > of the missing PS when a client "jumps" into a stream so as > to cause the sender to insert > the relevant (missing) PS in the stream. > > I conclude that in your application it is acceptable to have > a "black screen" while > the decoder waits for the full list of useful PS(s).... > > BTW I am concerned by the possibility that -since each > single frame of the stream > may have a different PS and that H264 supports 8k different > PS for a stream- > you may spend the first minutes sending requests for missing PS(s) > and in the meanwhile display either black or a bad slide show! > > but Ok, this is your application right ? > > Now thinking about that made me push the reasoning one more step: > It looks to me that H264 has pushed the flexibility so far that using > "fast update request" to get PS(s) can rapidly become > more like resorting to retransmission in case of "vital" packet losses > ... a bad idea usually :-( > > I.e. the problem of random access generalizes to an error > resilience issue, > and I have to insist that: > > 1) in band PS is *bad* for error resilience > > 2) and that this is true for *all applications* using > non-reliable transport e.g. RTP > > *************** > > The obvious *safe* alternative is to include all the > required PS(s) in the initial session setup. > > *************** > > Anyway ...let me translate this to the VOD media distribution case. > > A) a first concern is the conformance of a decoder with > regard to the support of PS in band. > > We need to scope it in the RTP payload because > implementing a VOD system that supports PS inband is > *much* more difficult and *not desirable* as follows: > > B) with video on demand you would get in trouble when a media player > performs a jump and discovers it cannot decode the video > it is receiving because it misses some PS(s) that are > embedded in the stream > "before" the jump ! > > there are 3 solutions there > > * jump on "complete" PS(s) updates only (unefficient and unpractical) > > * implement a dedicated trick in the streaming server so that it scans > the stream and looks up all the required PS(s) (ouch!) to > include them in > some kind of "primer" in the first RTP packets (and risk to > loose them!) > > * do not use in band PS, put all the required PS(s) in the > SDP instead! > > So you understand the choice is simple: for VOD we dont want > in band PS ! > > *********** > > Conclusion: I can only marginaly understand you may want to > have in band PS > but there MUST be a way to make conformant systems that do > not need to implement it, > > therefore that sentence should be: > > "This memo contains means to convey Parameter Set updates in > the RTP packet stream; > but since, conceptually, these are not designed to be sent in > the synchronous packet stream, > supporting in band Parameter Set transmission is OPTIONAL". > > regards, > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > > > > > To: > "'Stephan Wenger'" > > > avt@ietf.org > > cc: > (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) > > Subject: > RE: [AVT] Updated issues to discuss -- > draft-ietf-avt-rtp-h264-01 > "Even, Roni" .txt > > > > > > > Classification: > > > > > Sent by: > > > avt-admin@ietf.org > > > > > > 13/03/2003 11:22 > > > > > > > > > > > > > Hi, > I would like to point out that there are problems with > supporting parameters > sets in multipoint video conferencing scenarios. When using > out of band > signalling for the parameter sets if a video switch need to > occur then there > is a need for a new parameter set for the new video stream > and it has to be > available to the receiver before the actual stream. > The current work at the ITU suggests to use in band parameter > sets and to > send the parameter sets before the full picture as a response > to a fast > update request. (available in the RTCP feedback draft) > Regards > Roni Even > > > -----Original Message----- > > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > > Sent: Thursday, March 13, 2003 11:38 AM > > To: avt@ietf.org > > Subject: [AVT] Updated issues to discuss -- > > draft-ietf-avt-rtp-h264-01.txt > > > > > > Folks, > > here is an updated list of the issues re the H.264/JVT > > packetization. It > > reflects mostly the discussions here in Pattaya, where MPEG and JVT > > currently meets: > > > > Unchanged items: > > 1. Status of JVT -- should be out for the final ballot by the > > time of the > > meeting. > > 2. Fragmentation -- we decided on adding application layer > > fragmentation of > > NALUs to support some exotic scenarios. I plan to describe > > the pros and > > cons of the fragmentation, and hope for more guidance from > > the meeting re > > these feature. We had discussed this briefly in Atlanta > > already, but it > > has turned out that I forgot some applications where > > fragmentation is useful. > > 3. MIME/SDP sections: are they ok? > > 4. Interaction with MPEG-4 simple packetization (since H.264 is also > > ISO/IEC 14496-10). Miska and I are currently in Pattaya at > > the JVT/MPEG > > meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim > > (and other > > knowledgeable people). We will have some discussions about > > the interaction > > of the two drafts, and report probably to the mailing list, > > but certainly > > orally at the meeting, about the outcome of these discussions. > > 5. I currently believe that the problem mentioned in section > > 12 of the > > draft doesn't exist, but we will discuss this here in Pattaya > > as well and > > take action as necessary. > > 6. Security section seems to need more work, but this is not > > reflected in > > the draft yet. We plan to present a summary of the problems > > and proposed > > solution if there is time left. > > > > New items: > > 7. Interoperability between MPEG-4 simple and H.264 > > packetization -- as it > > has turned out, we already have one common operation point. > > Now that AUs > > are syntactically defined in MPEG-4, we can add something > > similar to a STAP > > that adds another common operation point. Our goal is to > > make this draft a > > binary-compatible superset of the MP4-Simple draft when > > carrying H.264, but > > it is unclear whether this can be achieved. > > 8. MIME/SDP codepoints to support out-of-level picture sizes > > -- the video > > conferencing industry needs to support extreme picture sizes > > (e.g. 1500 x > > 1000 pels) at low frame rates, for example for document > > cameras. However, > > they don't want to signal a profile/level combination that > > allows for this > > picture size (memory requirements), because that also implies > > the ability > > to decode high speed bit streams at high frame rates (computational > > requirements). Such codepoints are in principle agreed in > > the ITU-T H.245 > > protocol, and we are asked to add similar codepoints in the > MIME/SDP. > > 9. I will be prepared to explain DON (why it is there, and it > > works), but > > we admit that there is an urgent need for clearer language for both. > > > > Regards, > > Stephan > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Thu Mar 13 10:41:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05916 for ; Thu, 13 Mar 2003 10:41:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DFtck05972 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 10:55:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFsNO05870; Thu, 13 Mar 2003 10:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFrlO05826 for ; Thu, 13 Mar 2003 10:53:47 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05861 for ; Thu, 13 Mar 2003 10:38:44 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id 81BA3A496C; Thu, 13 Mar 2003 16:40:54 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA21462; Thu, 13 Mar 2003 16:40:54 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id QAA02465; Thu, 13 Mar 2003 16:40:52 +0100 (MET) Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS To: "Even, Roni" Cc: avt@ietf.org, "'Stephan Wenger'" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 13 Mar 2003 16:33:50 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/03/2003 16:41:54 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: , Roni, you write: "This memo contains means to convey Parameter Set updates in the RTP packet stream; supporting of in band Parameter Set transmission is application dependent. When using in band Parameter Set, the Parameter sets should be sent as part of the response to an RTCP picture loss indication ". Hum. You imply that the server should send all the "required" Parameters Sets, it would be better if it was explicit. anyway this does not solve my problem which is that I dont want to be forced to implement it in my VOD servers and clients and I prefer some clear normative text for it! regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 "Even, Roni" cc: avt@ietf.org "'Stephan Wenger'" "Even, Roni" Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS Classification: 13/03/2003 16:15 Hi Phillippe, About your VOD example. I do not see the difference between the PS and the full picture. If you skip frames you may need to look for some full frame if you the new frame is not referencing a full frame that is in the decoder buffers. In the case of Parameter Sets it is even simpler since the right way will be to send all the parameter sets you intend to use in the beginning of the connection between the media player client and the server. As for error resilience I am OK with your comment. The number of parameter sets is not the only issue but also if you have for example a multicast group and one end point is transmitting it may have used 3 parameter sets, than a different end point is transmitting using the same parameter sets but their order in the set is different. There is a need to send the new parameter sets. As for the paragraph I would like to have it as "This memo contains means to convey Parameter Set updates in the RTP packet stream; supporting of in band Parameter Set transmission is application dependent. When using in band Parameter Set, the Parameter sets should be sent as part of the response to an RTCP picture loss indication ". Regards Roni Even > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, March 13, 2003 4:31 PM > To: Even, Roni > Cc: avt@ietf.org; 'Stephan Wenger' > Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS > > > Roni, > > Thank you for bringing this up. > > Stephan, > > After reflexion the sentence in the draft: > > " Although, conceptually, the Parameter Set updates are > not designed > to be sent in the synchronous packet stream, this memo contains > means to convey them in the RTP packet stream. " > > looks very dangerous to me. > > let me explain. > > ************************************************************** > *********** > > H.264 has been designed with the capability to change the > configuration > dynamically and possibly very often (at every frame!) I wish > it was clear for > everyone that this directly impacts the concept of "Random > Access Point", > which is very different depending on applications: > > I assume you want to use the "fast update request" to send > the parameter set ID(s) > of the missing PS when a client "jumps" into a stream so as > to cause the sender to insert > the relevant (missing) PS in the stream. > > I conclude that in your application it is acceptable to have > a "black screen" while > the decoder waits for the full list of useful PS(s).... > > BTW I am concerned by the possibility that -since each > single frame of the stream > may have a different PS and that H264 supports 8k different > PS for a stream- > you may spend the first minutes sending requests for missing PS(s) > and in the meanwhile display either black or a bad slide show! > > but Ok, this is your application right ? > > Now thinking about that made me push the reasoning one more step: > It looks to me that H264 has pushed the flexibility so far that using > "fast update request" to get PS(s) can rapidly become > more like resorting to retransmission in case of "vital" packet losses > ... a bad idea usually :-( > > I.e. the problem of random access generalizes to an error > resilience issue, > and I have to insist that: > > 1) in band PS is *bad* for error resilience > > 2) and that this is true for *all applications* using > non-reliable transport e.g. RTP > > *************** > > The obvious *safe* alternative is to include all the > required PS(s) in the initial session setup. > > *************** > > Anyway ...let me translate this to the VOD media distribution case. > > A) a first concern is the conformance of a decoder with > regard to the support of PS in band. > > We need to scope it in the RTP payload because > implementing a VOD system that supports PS inband is > *much* more difficult and *not desirable* as follows: > > B) with video on demand you would get in trouble when a media player > performs a jump and discovers it cannot decode the video > it is receiving because it misses some PS(s) that are > embedded in the stream > "before" the jump ! > > there are 3 solutions there > > * jump on "complete" PS(s) updates only (unefficient and unpractical) > > * implement a dedicated trick in the streaming server so that it scans > the stream and looks up all the required PS(s) (ouch!) to > include them in > some kind of "primer" in the first RTP packets (and risk to > loose them!) > > * do not use in band PS, put all the required PS(s) in the > SDP instead! > > So you understand the choice is simple: for VOD we dont want > in band PS ! > > *********** > > Conclusion: I can only marginaly understand you may want to > have in band PS > but there MUST be a way to make conformant systems that do > not need to implement it, > > therefore that sentence should be: > > "This memo contains means to convey Parameter Set updates in > the RTP packet stream; > but since, conceptually, these are not designed to be sent in > the synchronous packet stream, > supporting in band Parameter Set transmission is OPTIONAL". > > regards, > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > > > > > To: > "'Stephan Wenger'" > > > avt@ietf.org > > cc: > (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) > > Subject: > RE: [AVT] Updated issues to discuss -- > draft-ietf-avt-rtp-h264-01 > "Even, Roni" .txt > > > > > > > Classification: > > > > > Sent by: > > > avt-admin@ietf.org > > > > > > 13/03/2003 11:22 > > > > > > > > > > > > > Hi, > I would like to point out that there are problems with > supporting parameters > sets in multipoint video conferencing scenarios. When using > out of band > signalling for the parameter sets if a video switch need to > occur then there > is a need for a new parameter set for the new video stream > and it has to be > available to the receiver before the actual stream. > The current work at the ITU suggests to use in band parameter > sets and to > send the parameter sets before the full picture as a response > to a fast > update request. (available in the RTCP feedback draft) > Regards > Roni Even > > > -----Original Message----- > > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > > Sent: Thursday, March 13, 2003 11:38 AM > > To: avt@ietf.org > > Subject: [AVT] Updated issues to discuss -- > > draft-ietf-avt-rtp-h264-01.txt > > > > > > Folks, > > here is an updated list of the issues re the H.264/JVT > > packetization. It > > reflects mostly the discussions here in Pattaya, where MPEG and JVT > > currently meets: > > > > Unchanged items: > > 1. Status of JVT -- should be out for the final ballot by the > > time of the > > meeting. > > 2. Fragmentation -- we decided on adding application layer > > fragmentation of > > NALUs to support some exotic scenarios. I plan to describe > > the pros and > > cons of the fragmentation, and hope for more guidance from > > the meeting re > > these feature. We had discussed this briefly in Atlanta > > already, but it > > has turned out that I forgot some applications where > > fragmentation is useful. > > 3. MIME/SDP sections: are they ok? > > 4. Interaction with MPEG-4 simple packetization (since H.264 is also > > ISO/IEC 14496-10). Miska and I are currently in Pattaya at > > the JVT/MPEG > > meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim > > (and other > > knowledgeable people). We will have some discussions about > > the interaction > > of the two drafts, and report probably to the mailing list, > > but certainly > > orally at the meeting, about the outcome of these discussions. > > 5. I currently believe that the problem mentioned in section > > 12 of the > > draft doesn't exist, but we will discuss this here in Pattaya > > as well and > > take action as necessary. > > 6. Security section seems to need more work, but this is not > > reflected in > > the draft yet. We plan to present a summary of the problems > > and proposed > > solution if there is time left. > > > > New items: > > 7. Interoperability between MPEG-4 simple and H.264 > > packetization -- as it > > has turned out, we already have one common operation point. > > Now that AUs > > are syntactically defined in MPEG-4, we can add something > > similar to a STAP > > that adds another common operation point. Our goal is to > > make this draft a > > binary-compatible superset of the MP4-Simple draft when > > carrying H.264, but > > it is unclear whether this can be achieved. > > 8. MIME/SDP codepoints to support out-of-level picture sizes > > -- the video > > conferencing industry needs to support extreme picture sizes > > (e.g. 1500 x > > 1000 pels) at low frame rates, for example for document > > cameras. However, > > they don't want to signal a profile/level combination that > > allows for this > > picture size (memory requirements), because that also implies > > the ability > > to decode high speed bit streams at high frame rates (computational > > requirements). Such codepoints are in principle agreed in > > the ITU-T H.245 > > protocol, and we are asked to add similar codepoints in the > MIME/SDP. > > 9. I will be prepared to explain DON (why it is there, and it > > works), but > > we admit that there is an urgent need for clearer language for both. > > > > Regards, > > Stephan > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Thu Mar 13 10:48:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06157 for ; Thu, 13 Mar 2003 10:48:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DG2Wh06329 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 11:02:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG29O06310; Thu, 13 Mar 2003 11:02:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DG1lO06273 for ; Thu, 13 Mar 2003 11:01:47 -0500 Received: from accord-ntsrv3.polycom.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06128 for ; Thu, 13 Mar 2003 10:46:43 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 17:48:31 +0200 Message-ID: From: "Even, Roni" To: "'philippe.gentric@philips.com'" , "Even, Roni" Cc: avt@ietf.org, "'Stephan Wenger'" Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS Date: Thu, 13 Mar 2003 17:48:30 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) 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, In your case it may be better to use reliable protocol to send the parameter set. The problem is with different applications that may switch the RTP source during the call. Sending all the parameter sets in the beginning may be difficult since each source may want to use the same parameter set numbers with different values so some mechanism to allocate the numbers is needed. The other option is to use out of band signalling with each switch of source. If you use out of band in this case it will be long and you will need to synchronize so that the sender will not send before the receiver arrives. Using in band non reliable has lower latency and losing the PS is the same as losing the full picture that you need from the new source so you need to protect both if error resilience is a concern Roni > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, March 13, 2003 5:25 PM > To: Even, Roni > Cc: avt@ietf.org; 'Stephan Wenger' > Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS > > > > > Roni, you write: > > > In the case of Parameter Sets it is even simpler since the right > > way will be to send all the parameter sets you intend to use in the > > beginning of the connection between the media player client > and the server. > > Ah but that is *exactly* the point ! > > I know I need to convey all the required parameter sets to my > decoder *before* starting to decode > > My point is that since I have 2 ways to do it: > * out of band and reliable (typically SDP on TCP) > or > * in band and not reliable > > I prefer to do it out of band and *reliable* of course! > > All the more so since anyway I have already a session to setup > with several round trips and a SDP to exchange etc ... > > How can it be better to do it in band ? > > regards > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > > > > > To: > Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > > "Even, > Roni" > > cc: > avt@ietf.org > > "'Stephan > Wenger'" > > "Even, Roni" Subject: > RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS > > > > > > Classification: > > > > > 13/03/2003 16:15 > > > > > > > > > > > > > Hi Phillippe, > > About your VOD example. I do not see the difference between > the PS and the > full picture. If you skip frames you may need to look for > some full frame if > you the new frame is not referencing a full frame that is in > the decoder > buffers. In the case of Parameter Sets it is even simpler > since the right > way will be to send all the parameter sets you intend to use in the > beginning of the connection between the media player client > and the server. > > As for error resilience I am OK with your comment. > > The number of parameter sets is not the only issue but also > if you have for > example a multicast group and one end point is transmitting > it may have used > 3 parameter sets, than a different end point is transmitting > using the same > parameter sets but their order in the set is different. There > is a need to > send the new parameter sets. > > As for the paragraph I would like to have it as > > "This memo contains means to convey Parameter Set updates in > the RTP packet > stream; > supporting of in band Parameter Set transmission is > application dependent. > When using in band Parameter Set, the Parameter sets should > be sent as part > of the response to an RTCP picture loss indication ". > > Regards > Roni Even > > > > > -----Original Message----- > > From: philippe.gentric@philips.com > > [mailto:philippe.gentric@philips.com] > > Sent: Thursday, March 13, 2003 4:31 PM > > To: Even, Roni > > Cc: avt@ietf.org; 'Stephan Wenger' > > Subject: RE: [AVT] draft-ietf-avt-rtp-h264-01.txt in band PS > > > > > > Roni, > > > > Thank you for bringing this up. > > > > Stephan, > > > > After reflexion the sentence in the draft: > > > > " Although, conceptually, the Parameter Set updates are > > not designed > > to be sent in the synchronous packet stream, this memo contains > > means to convey them in the RTP packet stream. " > > > > looks very dangerous to me. > > > > let me explain. > > > > ************************************************************** > > *********** > > > > H.264 has been designed with the capability to change the > > configuration > > dynamically and possibly very often (at every frame!) I wish > > it was clear for > > everyone that this directly impacts the concept of "Random > > Access Point", > > which is very different depending on applications: > > > > I assume you want to use the "fast update request" to send > > the parameter set ID(s) > > of the missing PS when a client "jumps" into a stream so as > > to cause the sender to insert > > the relevant (missing) PS in the stream. > > > > I conclude that in your application it is acceptable to have > > a "black screen" while > > the decoder waits for the full list of useful PS(s).... > > > > BTW I am concerned by the possibility that -since each > > single frame of the stream > > may have a different PS and that H264 supports 8k different > > PS for a stream- > > you may spend the first minutes sending requests for missing PS(s) > > and in the meanwhile display either black or a bad slide show! > > > > but Ok, this is your application right ? > > > > Now thinking about that made me push the reasoning one more step: > > It looks to me that H264 has pushed the flexibility so far > that using > > "fast update request" to get PS(s) can rapidly become > > more like resorting to retransmission in case of "vital" > packet losses > > ... a bad idea usually :-( > > > > I.e. the problem of random access generalizes to an error > > resilience issue, > > and I have to insist that: > > > > 1) in band PS is *bad* for error resilience > > > > 2) and that this is true for *all applications* using > > non-reliable transport e.g. RTP > > > > *************** > > > > The obvious *safe* alternative is to include all the > > required PS(s) in the initial session setup. > > > > *************** > > > > Anyway ...let me translate this to the VOD media distribution case. > > > > A) a first concern is the conformance of a decoder with > > regard to the support of PS in band. > > > > We need to scope it in the RTP payload because > > implementing a VOD system that supports PS inband is > > *much* more difficult and *not desirable* as follows: > > > > B) with video on demand you would get in trouble when a media player > > performs a jump and discovers it cannot decode the video > > it is receiving because it misses some PS(s) that are > > embedded in the stream > > "before" the jump ! > > > > there are 3 solutions there > > > > * jump on "complete" PS(s) updates only (unefficient and > unpractical) > > > > * implement a dedicated trick in the streaming server so > that it scans > > the stream and looks up all the required PS(s) (ouch!) to > > include them in > > some kind of "primer" in the first RTP packets (and risk to > > loose them!) > > > > * do not use in band PS, put all the required PS(s) in the > > SDP instead! > > > > So you understand the choice is simple: for VOD we dont want > > in band PS ! > > > > *********** > > > > Conclusion: I can only marginaly understand you may want to > > have in band PS > > but there MUST be a way to make conformant systems that do > > not need to implement it, > > > > therefore that sentence should be: > > > > "This memo contains means to convey Parameter Set updates in > > the RTP packet stream; > > but since, conceptually, these are not designed to be sent in > > the synchronous packet stream, > > supporting in band Parameter Set transmission is OPTIONAL". > > > > regards, > > > > > > Philippe Gentric > > Software Architect > > Philips MP4Net > > philippe.gentric@philips.com > > http://www.platform4.philips.com > > > > > > > > > > > > > > > > > > To: > > "'Stephan Wenger'" > > > > > > avt@ietf.org > > > > cc: > > (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) > > > > Subject: > > RE: [AVT] Updated issues to discuss -- > > draft-ietf-avt-rtp-h264-01 > > "Even, Roni" .txt > > > > > > > > > > > > > > Classification: > > > > > > > > > > Sent by: > > > > > > avt-admin@ietf.org > > > > > > > > > > > > 13/03/2003 11:22 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > I would like to point out that there are problems with > > supporting parameters > > sets in multipoint video conferencing scenarios. When using > > out of band > > signalling for the parameter sets if a video switch need to > > occur then there > > is a need for a new parameter set for the new video stream > > and it has to be > > available to the receiver before the actual stream. > > The current work at the ITU suggests to use in band parameter > > sets and to > > send the parameter sets before the full picture as a response > > to a fast > > update request. (available in the RTCP feedback draft) > > Regards > > Roni Even > > > > > -----Original Message----- > > > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > > > Sent: Thursday, March 13, 2003 11:38 AM > > > To: avt@ietf.org > > > Subject: [AVT] Updated issues to discuss -- > > > draft-ietf-avt-rtp-h264-01.txt > > > > > > > > > Folks, > > > here is an updated list of the issues re the H.264/JVT > > > packetization. It > > > reflects mostly the discussions here in Pattaya, where > MPEG and JVT > > > currently meets: > > > > > > Unchanged items: > > > 1. Status of JVT -- should be out for the final ballot by the > > > time of the > > > meeting. > > > 2. Fragmentation -- we decided on adding application layer > > > fragmentation of > > > NALUs to support some exotic scenarios. I plan to describe > > > the pros and > > > cons of the fragmentation, and hope for more guidance from > > > the meeting re > > > these feature. We had discussed this briefly in Atlanta > > > already, but it > > > has turned out that I forgot some applications where > > > fragmentation is useful. > > > 3. MIME/SDP sections: are they ok? > > > 4. Interaction with MPEG-4 simple packetization (since > H.264 is also > > > ISO/IEC 14496-10). Miska and I are currently in Pattaya at > > > the JVT/MPEG > > > meeting, as are Jan Van-der-Meer, Dave Singer, Young-Kown Lim > > > (and other > > > knowledgeable people). We will have some discussions about > > > the interaction > > > of the two drafts, and report probably to the mailing list, > > > but certainly > > > orally at the meeting, about the outcome of these discussions. > > > 5. I currently believe that the problem mentioned in section > > > 12 of the > > > draft doesn't exist, but we will discuss this here in Pattaya > > > as well and > > > take action as necessary. > > > 6. Security section seems to need more work, but this is not > > > reflected in > > > the draft yet. We plan to present a summary of the problems > > > and proposed > > > solution if there is time left. > > > > > > New items: > > > 7. Interoperability between MPEG-4 simple and H.264 > > > packetization -- as it > > > has turned out, we already have one common operation point. > > > Now that AUs > > > are syntactically defined in MPEG-4, we can add something > > > similar to a STAP > > > that adds another common operation point. Our goal is to > > > make this draft a > > > binary-compatible superset of the MP4-Simple draft when > > > carrying H.264, but > > > it is unclear whether this can be achieved. > > > 8. MIME/SDP codepoints to support out-of-level picture sizes > > > -- the video > > > conferencing industry needs to support extreme picture sizes > > > (e.g. 1500 x > > > 1000 pels) at low frame rates, for example for document > > > cameras. However, > > > they don't want to signal a profile/level combination that > > > allows for this > > > picture size (memory requirements), because that also implies > > > the ability > > > to decode high speed bit streams at high frame rates > (computational > > > requirements). Such codepoints are in principle agreed in > > > the ITU-T H.245 > > > protocol, and we are asked to add similar codepoints in the > > MIME/SDP. > > > 9. I will be prepared to explain DON (why it is there, and it > > > works), but > > > we admit that there is an urgent need for clearer > language for both. > > > > > > Regards, > > > Stephan > > > > > > _______________________________________________ > > > 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 mailnull@www1.ietf.org Thu Mar 13 13:22:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11634 for ; Thu, 13 Mar 2003 13:22:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DIb1R18515 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 13:37:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIahO18428; Thu, 13 Mar 2003 13:36:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIZgO18345 for ; Thu, 13 Mar 2003 13:35:42 -0500 Received: from hafez.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11503; Thu, 13 Mar 2003 13:20:39 -0500 (EST) Received: from hafez (csp@localhost) by hafez.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h2DIMl918530; Thu, 13 Mar 2003 13:22:48 -0500 Message-Id: <200303131822.h2DIMl918530@hafez.nge.isi.edu> To: avt@ietf.org cc: agenda@ietf.org Date: Thu, 13 Mar 2003 13:22:47 -0500 From: Colin Perkins Subject: [AVT] Updated 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: , Audio/Video Transport Working Group CHAIRS: Steve Casner Colin Perkins Wednesday, 19th March at 13:00-15:00 ==================================== Introduction and status update (Casner/Perkins) 15 draft-ietf-avt-rtp-new-12.txt (Approved!) draft-ietf-avt-profile-new-13.txt (Approved!) draft-ietf-avt-uxp-05.txt draft-ietf-avt-ulp-07.txt (Under revision) draft-ietf-avt-tcrtp-07.txt draft-ietf-avt-rtp-retransmission-06.txt draft-ietf-avt-rtcp-feedback-05.txt draft-burmeister-avt-rtcp-feedback-sim-01.txt draft-ietf-avt-mpeg4-simple-07.txt (with IESG) draft-ietf-avt-crtp-enhance-07.txt (IETF last call) draft-ietf-avt-rtcp-bw-05.txt (RFC Editor) draft-ietf-avt-rtp-mime-06.txt (RFC Editor) draft-ietf-avt-dsr-05.txt (RFC Editor) draft-ietf-avt-evrc-smv-03.txt (RFC Editor) See also draft-garudadri-qcp-00.txt RFC 3497 The Secure Real-time Transport Protocol 15 draft-ietf-avt-srtp-05.txt Framing RTP over Connection-Oriented Transport (Lazzaro) 15 draft-lazzaro-avt-rtp-framing-contrans-00.txt RTP Extended Reports (RTP XR) (Friedman/Clark) 15 draft-ietf-avt-rtcp-report-extns-03.txt RTCP Extensions for SSM with unicast feedback (Chesterfield) 15 draft-ietf-avt-rtcpssm-03.txt RTP Payload Format for JVT Video (Wenger) 15 draft-ietf-avt-rtp-h264-01.txt RTP Payload Format for uncompressed video (Gharai) 15 draft-ietf-avt-uncomp-video-02.txt Thursday, 20th March at 09:00-11:30 =================================== RTP Payload Format for a 64 kbit/s transparent call (Kreuter) 15 draft-kreuter-avt-rtp-clearmode-02.txt See also the TDM emulation work in the PWE3 working group The MIDI Wire Protocol Packetization (MWPP) (Lazzaro) 15 draft-ietf-avt-mwpp-midi-rtp-06.txt draft-lazzaro-avt-mwpp-coding-guidelines-02.txt RTP Payload Format for ATRAC-X (Romaine) 15 draft-hatanaka-avt-rtp-atracx-01.txt RTP Payload Format for iLBC Speech (Duric) 15 draft-ietf-avt-rtp-ilbc-01.txt draft-ietf-avt-ilbc-codec-01.txt RTP Payload Format for the Speex Codec (Herlein) 15 draft-herlein-speex-rtp-profile-00.txt RTP Payload Format for RGL Codec (Ramalho) 15 draft-ramalho-rgl-desc-01.txt draft-ramalho-rgl-rtpformat-01.txt RTP Payload Format for ETSI ES 202 050 DSR (Xie) 15 draft-xie-avt-dsr-es202050-00.txt File format for EVRC/SMV vs QCP 15 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 13:54:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12690 for ; Thu, 13 Mar 2003 13:54:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJ8oh21538 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 14:08:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJ8HO21522; Thu, 13 Mar 2003 14:08:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJ7QO21319 for ; Thu, 13 Mar 2003 14:07:26 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12580 for ; Thu, 13 Mar 2003 13:52:21 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2DIsQhs015747; Thu, 13 Mar 2003 10:54:26 -0800 (PST) Received: from MCGREWW2K (stealth-10-34-251-100.cisco.com [10.34.251.100]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEY20045; Thu, 13 Mar 2003 10:49:05 -0800 (PST) From: "David A. Mcgrew" To: "Jose Rey" , "Avt@Ietf. Org" Cc: , , , , Subject: RE: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission Date: Thu, 13 Mar 2003 10:54:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal 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 Jose, > -----Original Message----- > From: Jose Rey [mailto:rey@panasonic.de] > Sent: Monday, February 17, 2003 7:41 AM > To: David A. Mcgrew; Avt@Ietf. Org > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > mats.naslund@era.ericsson.se; karl.norrman@era.ericsson.se; > oran@cisco.com > Subject: RE: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission > > > David, > > thanks for your comments, please see inline. > > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of David > > A. Mcgrew > > Sent: Thursday, February 06, 2003 4:53 PM > > To: Jose Rey; Avt@Ietf. Org > > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > > mats.naslund@era.ericsson.se; karl.norrman@era.ericsson.se; > > oran@cisco.com > > Subject: [AVT] RE: Security for draft-ietf-avt-rtp-retransmission > > > > > > José, > > > > > -----Original Message----- > > > From: Jose Rey [mailto:rey@panasonic.de] > > > Sent: Thursday, January 23, 2003 8:35 AM > > > To: Avt@Ietf. Org > > > Cc: mbaugher@cisco.com; elisabetta.carrara@era.ericsson.se; > > > mcgrew@cisco.com; mats.naslund@era.ericsson.se; > > > karl.norrman@era.ericsson.se; oran@cisco.com > > > Subject: Security for draft-ietf-avt-rtp-retransmission > > > > > > > > > Hi all, > > > > > > we are doing the final edits to the > > draft-ietf-avt-rtp-retransmission. > > > We have considered all your comments until the date, but there's > > > something for which we would like to get some feedback on: security. > > > > > > A couple of questions: > > > > > > 1.-As discussed on the list: > > > ... > > > > -----Original Message----- > > > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On > > Behalf Of Colin > > > > Perkins > > > > Sent: Friday, January 10, 2003 4:39 AM > > > > To: David.Leon@nokia.com > > > > Cc: avt@ietf.org > > > > Subject: Re: [AVT] Comments on > > > > draft-ietf-avt-rtp-retransmission-04.txt > > > > > > > ...snip... > > > > > > > >> - In section 12, how does this draft affect SRTP? Is it > > > > possible to use > > > > >> the two formats together? > > > > > > > > > >We'll try to draft something on that. My understanding > > is that the > > > > >retransmission stream is seen as any other stream by SRTP > > > > and there should > > > > >thus be no problem. > > > > > > > > I was not clear if retransmitting packets caused problems for > > > > SRTP; maybe > > > > one of the SRTP authors can comment on any potential > > security issue? > > > > > > > > > > we don't see any problems (except for SRTCP as below in 2) > > to use SRTP > > > with RTX since the RTP retransmission packets (with a two byte > > > retransmission payload header) are seen by SRTP as 'normal' > > RTP packets. > > > Is our assumption correct? > > > > I think so. Certainly if the retransmission packets are > > treated as a separate > > session or separate stream with its own set of SRTP keys, > > then there's no > > problem. > > Fine. > > > The only potential issue that I see is that the > > SRTP protection for > > the retransmission data will need to get keys (and other > > parameters) somehow. > > Is the plan to signal the retransmission session/stream at > > the same time as the > > original stream, but then only use it if it is needed? In > > that case, I'd expect > > that all the SRTP info for both streams/sessions would be > > provided by the > > signaling, which seems like it would work well. > > > > This is also my understanding. > > > > > > > 2.-The retransmission payload format needs of the AVPF > > profile to enable > > > more frequent feedback and to request packets. This profile defines > > > (besides the new timing rules) some general-purpose messages such as > > > ACKs and NACKs and a new RTCP packet format: the early > > feedback packet, > > > which just contains 1 SR or RR and 1 SDES with just the CNAME. Now, > > > there should be no problem to encrypt/authenticate early packets, > > > according to the SRTP draft: > > > > > > " > > > According to [RFC1889] there is a "recommended" packet format for > > > compound packets. SRTCP MUST be given packets according to that > > > recommendation in the sense that the first part MUST be a sender > > > report or a receiver report. However, the encryption > > prefix (Section > > > 6.1 of [RFC1889]), a random 32-bit quantity intended to > > deter known > > > plaintext attacks, MUST NOT be used (see below). > > > " > > > > > > > > > Also there should be no problem to authenticate/encrypt > > ACKs and NACKs > > > with SRTCP since they are sent in compound RTCP packets > > starting with an > > > RR or SR packet. Let us know if you disagree with this point. > > > > > > > > > 3.- if a new profile needs be defined, something like "SAVPF", where > > > shall this profile "SAVPF" be specified and registered? > > wouldn't it be > > > reasonable to do this in the SRTP draft which already registers the > > > "SAVP" profile given that the feedback draft would > > (presumably) have a > > > similar schedule to the SRTP draft? In this way the > > question 2. could > > > also be anwered there. > > > > The SRTP draft is in IESG review, so at this point it > > wouldn't be appropriate to > > drag it back. > > Yes, I understand. > > > But if the new profile is uncomplicated, it > > shouldn't be hard to > > throw together a new draft that references AVPF and SRTP to > > make SAVPF. Could > > you point me in the right direction as to what differences > > between AVP and AVPF > > would be important w.r.t. SRTP? > > > > AVPF introduces new feedback messages ACKs/NACKs and application layer > messages which, as concluded above, don't represent any problem for > SRTP. This is because the RTCP packets used by AVPF-compliant entities > also use the "recommended" RTCP packet format as in RTP, thus not being > a problem (see point 2 above). > > The other major change is that the AVPF profile abolishes the 5-second > rule; this shouldn't be a problem for SRTP either (?) > > > > > > 4.- the security section in the retransmission draft > > already points out > > > the risks of using the same keys across sessions, e.g. > > two.-time pads > > > and points to the SRTP for solutions. That much is done. > > Are we missing > > > something else? > > > > The draft says that "Applications utilising encryption SHOULD > > encrypt both the > > original and the retransmission stream." IIUC, it might > > be better to state > > that "If cryptography is used to provide security services on > > the original > > stream, then the same services, with equivalent cryptographic > > strength, SHOULD > > be provided on the retransmission stream." Also, I'm > > wondering why you would > > want a SHOULD and not a MUST here! > > > > Right, thanks for the rewording. I like a MUST instead better. > > > Correct me if I'm wrong, but here's my mental picture of how > > the combined > > srtp/retransmission system would work: > > > > sender side > > ----------- > > > > original rtp source -+------------------> srtp encrypter > > (key1) ---> ... > > | > > +-> rexmit buffer -> srtp encrypter > > (key2) ---> ... > > > > Another approach would be to move the retransmission buffer > > to the other side of > > the srtp encrypter, and get rid of key2. This would be > > workable, since the > > original sequence number is provided in the retransmitted > > packet. However, this > > scheme would not provide message authentication on the > > retransmission packet > > flow. Another demerit of this scheme is that it would > > interact badly with the > > SRTP anti-replay window; the recommended size for this window > > is 128, and this > > scheme might require an even larger one. So I like the first > > method (the way I > > think that you're doing it) better! > > > > At any rate, it might be good to describe how you want the > > retransmission > > mechanism to work with SRTP or other crypto mechanisms, to > > avoid confusion down > > the road. > > > The 1st possibility as depicted by you is the one we have in mind. Your > other "option" could be given as an example of what not to do and why. > This would rule out possible questions. > > > > > > > > > > > 5.-It is also pointed out that the Timestamp of the retransmission > > > packets is the same as in the original packets. Since this > > is random it > > > should be no problem for security. Is this assumption correct? > > > > I think that the non-randomness of the initial timestamp of > > the retransmission > > stream is not an issue. The unpredictability of the initial > > RTP timestamp makes > > a DoS attack more difficult for an attacker who is not able > > to observe the RTP > > flow, but who knows the destination address, destination port > > number, and SSRC > > of that flow. The same argument could be made for the > > avt-rtp-retranmission > > mechanism. If the attacker can't see the original flow, she > > can't predict the > > initial timestamp of the retransmission flow. If she can see > > the original flow, > > then there is no protection provided by having random > > timestamp on either flow. > > So there is no disadvantage to the avt-rtp-retransmission > > mechanism's re-use of > > the initial timestamp. > > > OK. > > Now, I got a question: > > as discussed in previous emails (see the email from Elisabetta), in the > case of SSRC-multiplexing the same master key might be used for both > streams since the SSRC is unique among the streams. > > In the original packets the SN is sent in the header, thus accessible. > However in the retransmission packets, the retransmission payload header > (the two bytes containing the original SN, OSN) is sent encrypted and > its location is known: right after the RTP header before the payload. > Since both original and retransmission packets have the same TS, an > attacker could easily identify an original packet and its retransmission > by comparing the TS. Once this is done he could easily see how the > cleartext SN is encrypted. Now, I am not a security expert but, > intuitively, this is not secure. Is it not a security threat? Does SRTP > solve this? In crypto jargon, the SN in the retransmission packet is known-plaintext. The ciphers used in SRTP, like most modern ciphers, provide good protection against known-plaintext attacks, even where there is really great of known plaintext. So the point that you bring up isn't really a security problem. David > > thanks, > > José > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 14:38:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14549 for ; Thu, 13 Mar 2003 14:38:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJqnB25178 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 14:52:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJqMO25162; Thu, 13 Mar 2003 14:52:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJpLO25070 for ; Thu, 13 Mar 2003 14:51:21 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14460 for ; Thu, 13 Mar 2003 14:36:16 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 434C91E206; Thu, 13 Mar 2003 14:38:26 -0500 (EST) Received: from research.att.com (chopin.attlabs.att.com [135.197.15.62]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA03635; Thu, 13 Mar 2003 14:38:23 -0500 (EST) Message-ID: <3E70DE30.F37DDB2B@research.att.com> Date: Thu, 13 Mar 2003 11:38:24 -0800 From: Eve Schooler X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Fiandra Riccardo , Joerg Ott , Julian Chesterfield Cc: avt@ietf.org Subject: Re: [AVT] RTCP unicast feedback for measurement applications? References: <90F3FE1EF972EE4495D6E360A6CD0115170A1F@FWMIMX3.fastwebit.ofc> 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 Fiandra, Finally, here are pointers to the paper that extends the ideas proposed in the I-D, and that I promised below. The paper analyzes the bandwidth savings of summarisation, and presents a couple additional techniques (biasing and hierarchical summarisation) that - combine well with unicast feedback and generic summarisation, - provide further rtcp scalability, and - offer additional application contexts for rtcp. http://www.research.att.com/~schooler/papers/rtcp-summary-paper.techreport.ps http://www.research.att.com/~schooler/papers/rtcp-summary-paper.techreport.pdf A shorter version will appear in the 2nd IEEE International Symposium on Network Computing and Applications, NCA-03, April 16-18, 2003, Cambridge, MA. http://www.research.att.com/~schooler/papers/rtcp-summary-paper.ps http://www.research.att.com/~schooler/papers/rtcp-summary-paper.pdf E. > -----Original Message----- > From: Eve Schooler [mailto:schooler@research.att.com] > Sent: martedì 4 febbraio 2003 2.02 > To: Fiandra Riccardo > Cc: Eve Schooler; Julian Chesterfield; Joerg Ott; avt@ietf.org > Subject: Re: [AVT] RTCP unicast feedback for measurement applications? > > > Fiandra Riccardo wrote: > > >I was interested in the "RTCP Extensions for Single-Source Multicast > >Sessions with Unicast Feedback" draft. > >Actually, I was wondering if it is also targeted to have a very large and > >distribuited network measurement framework. > >Where multicast receivers (thousands) use RTCP to send report to a > >measurement collector about packet loss, jitter, or other. > >I see really many advantages on that for e2e measurements, especially in a > >scenario where thousands of receivers are always connected to the network > >and cannot send multicast (common scenario for an operator, even without > >SSM...). > > > >My questions are: > >-Was this a scenario of application when writing the draft? > > Absolutely, though the primary focus of the draft was to solve > the problem posed by the removal/restriction of the backchannel > caused by SSM and other uni-directional or asymmetric topologies. > Solving the feedback problem for SSM gives us the blueprint for > other unicast-based feedback architectures, including ones for > network measurement in general. > > >-In this case, could I use the RTCP channel multicasted to the receivers to > >control them? > > Yes you could. This is certainly what we envision in the RTCP > context; use the multicast channel in the source-to-receiver > direction, and use the unicast backchannels in the > receiver-to-source direction. > > We also propose to use the multicast channel either: > - to reflect receiver feedback (received on the unicast backchannels) > back out on the multicast channel to reach all receivers, or > - to redistribute to the receivers feedback summaries > (receiver feedback collected at the source and aggregated into > a single mathematical distribution) back out on the multicast channel. > > >-Do you see any extension possible also for ptp rtp connections (forward > >rtcp reports to another device?) > > In section 10 of draft-ietf-avt-rtcpssm-02.txt, we use > an extension to SDP to indicate the device to which the > feedback gets reported. This is done following the proposal > for SDP source filters documented in > draft-ietf-mmusic-sdp-srcfilter-00.txt. > > We also just completed a paper that expands upon the ideas > in the I-D and that should provide further application > scenarios. I'll post it here shortly. > > Eve > > -=-=-=-=- > > Eve M. Schooler Voice: 1-650-330-7913 > AT&T Labs - Research FAX: 1-650-463-7037 > 75 Willow Road E-mail: schooler@research.att.com > Menlo Park, CA, USA 94025 http://www.research.att.com/~schooler _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 17:21:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21837 for ; Thu, 13 Mar 2003 17:21:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DMabL05427 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 17:36:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMaDO05389; Thu, 13 Mar 2003 17:36:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMXdO05199 for ; Thu, 13 Mar 2003 17:33:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21634; Thu, 13 Mar 2003 17:18:29 -0500 (EST) Message-Id: <200303132218.RAA21634@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , avt@ietf.org From: The IESG Date: Thu, 13 Mar 2003 17:18:29 -0500 Subject: [AVT] Protocol Action: RTP: A Transport Protocol for Real-Time Applications to Draft 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 the following Internet-Drafts as Draft Standards: o RTP: A Transport Protocol for Real-Time Applications , obsoleting RFC1889, currently a Proposed Standard. o RTP Profile for Audio and Video Conferences with Minimal Control obsoleting RFC1890, currently a Proposed Standard. These documents are the products of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The first document defines RTP, consisting of two closely-linked parts: o the real-time transport protocol (RTP), to carry data that has real-time properties. o the RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an on-going session. A well-exercised capability for DES encryption of RTP and RTCP packets is part of the document, along with extensive considerations on use of the feature. A new profile of RTP called Secure RTP (SRTP) is under way that will provide encryption with AES since DES is not considered strong, and provide much better security support. However it was deemed that RTP and RTCP should be advanced to Draft Standard with their currently deployed security feature rather than waiting for the future standardization of SRTP (and its eligibility for Draft), because the practical use of DES-encrypted media with RTP has been extensive. This document obsoletes RFC 1889. The second document defines aspects of RTP that complete a profile for the use within audio and video conferences with minimal session control. In particular, no support for the negotiation of parameters or membership control is provided. The profile is useful in sessions where no negotiation or membership control are used (e.g., using the static payload types and the membership indications provided by RTCP), but this profile is also useful in conjunction with a higher-level control protocol, and it is invoked by uses of media managed by Session Description Protocol (RFC2327) as well in frequent practice. This document obsoletes RFC 1890. Working Group Summary The AVT Working Group conducted careful review of the two documents and their clarification. There was a strong effort to ensure the implementation test plan and report had extensive review as well. The differences from the Proposed Standard to the Draft Standards are minor, are well-documented in sections of the two documents, and do not result in any on-the-wire changes to the protocols. There was strong working group support for the advancement to Draft Standard. Protocol Quality RTP and RTCP have been in use on the Internet for many years. As the implementation report shows, there are two independent open source implementations that are very full, as well as many commercial ones. RTP and RTCP and their payloads are used in numerous applications, in conjunction with other established protocols, such as Session Initiation Protocol in telephony applications. The documents were reviewed for the IESG by Allison Mankin. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 13 19:11:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26332 for ; Thu, 13 Mar 2003 19:11:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E0PhZ12771 for avt-archive@odin.ietf.org; Thu, 13 Mar 2003 19:25:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0PMO12757; Thu, 13 Mar 2003 19:25:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0JqO12413 for ; Thu, 13 Mar 2003 19:19:52 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26150; Thu, 13 Mar 2003 19:04:40 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id LAA02410; Fri, 14 Mar 2003 11:06:43 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa000.a; Fri Mar 14 11:06:37 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Mar 2003 11:06:37 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id GY5X4JMS; Fri, 14 Mar 2003 11:06:35 +1100 To: magnus.westerlund@era.ericsson.se Cc: avt@ietf.org, mmusic@ietf.org, Conrad.Parker@csiro.au Message-ID: <3E711D60.4060500@csiro.au> Date: Fri, 14 Mar 2003 11:08:00 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 Subject: Re: [AVT] new I-D on temporal URI addresses References: <3E66AF6D.7040106@csiro.au> <3E671F9E.7080706@era.ericsson.se> <3E6EA41C.3010504@csiro.au> <3E6F1697.4040607@era.ericsson.se> In-Reply-To: <3E6F1697.4040607@era.ericsson.se> 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 Magnus, > First I have a question on how you are going to go forward in IETF. Are > you planning to take this work into any WG or do a individual submission? I am most happy to take it into a WG but am uncertain which one that would be. > Thanks, for the explanation, it greatly clarifies this. However to my > understanding the usage of MIME types is actually depending on the URI > scheme. One simple example is to compare HTTP and RTSP. In HTTP you: 1) > download the object specified by the URI. 2) Look at the MIME type of > the downloaded object and sends it to its parser together with the > fragment. 3) The parser takes the fragment into account when displaying > the content. Not necessarily. That's just the way current browsers work because of the recommendations for the use of the fragment. I know for a fact that the Apache Web server can receive, parse and handle fragment offsets. > However for RTSP URI with a fragment one possible interpretation is to > setup the presentation indicated by the URI. This setup results in that > a media description is retrieved. This description has of course a MIME > type. Is it to this description the the fragment applies? Or is it to a > the presentation in general which does not have a MIME type, or is it to > the media streams which can contain one or more different encodings > perhaps identified by MIME types. That should be discussed, but my take is that it applies to each one of the media streams that are part of the general presentation. > My point with this example is that the schemes seems to be taken into > account. For RTSP it seems in fact that it is time to start defining > some fragment identifier behavior. I agree, we definately need to take the schemes into account when describing the expected behaviour of servers and clients when encountering these temporal offsets in URIs. > I don't think we need to consider servers in this case, rather the > clients as fragments should have been treated in accordance with the URI > specification saying that fragment is a user agent problem. It is important to consider servers, too. I does not make sense to burden the Internet or the user with a huge amount of video data when all that the user requires is a clip 20 minutes into the video. I am aware that the current use of fragments does not conform to this idea and therefore suggested to discuss the possibilities of changing that usage specification. >>> So a general question, what is the actually possibilities to >>> standardize such a solution? >> >> It needs some minor adjustments in the URI standard. As that standard >> is currently being changed/adapted, this could be the right time to >> get it adjusted. Then our mechanism can be provided as a Generic >> Syntax proposal and MIME type specifications for time-continuous data >> can elect to support it. That's my take. > > I am not fully aware of what is happening with this. However I have seen > a draft for making URI generic syntax to standard. Is that what you have > in mind? To my knowledge the changes performed on a specification when > going from draft to full standard are only clarifications. Technical > changes are very limited if allowed at all. As far as I understand it, there are more changes than just clarifications happening to RFC2396. But if you are right, we are probably forced to go with the query "?" solution rather than fragments, which makes it a lot less elegant. Why should we be using a different scheme for addressing offsets in audio/video than in html? Also, the use of query is already overloaded and therefore a sensible use of fragments for media would make sense. > I think that any such extension as you are proposing will be a proposed > standard. I'd be more than happy to have it become that and through an IETF WG. > For me it seems very bad step to redefine this. I think one should look > at both use cases. There will still be plenty of reasons to use fragment > on the client side. Could you please tell me some? I tend to disagree. I believe that as time-continuous media are usually high data rates, fragment addressing of such data only makes sense if we can avoid having to serve out the complete file before we can address the offset. By the way, even with HTML I have often been upset about having to wait (especially on a modem line) for the complete document to download when all I wanted was to read a specific paragraph in it. > And as there is a large number of HTTP clients out > there using the current definition it seems a bad move to redefine it. No. That would not affect them. It is still possible to say that if the user (agent) wishes to interpret the fragment offset locally, he's free to strip off the fragment offset from the URI (as happening today) and not sending that to the server. However, if a server receives a fragment offset request, he requires to send data only from that offset onwards. > However one should also look into how to address this when one wants the > server to perform the action. I can clearly understand the use case of > having a server reduce large media files to only contain what one is > interested of. > I looked through the URIBOF agenda: > http://www.ietf.org/ietf/03mar/uribof.txt . I could however not see that > this issue would be part of the BOF. Are you planning to take up your > proposal there? I only found out about the URIBOF agenda after having submitted the I-D. I have however sent the I-D to the relevant mailing lists and hope to get them to pick it up and discuss the issues. I cannot attend the meeting personally, unfortunately. Best Regards, Silvia. --- Silvia Pfeiffer Research Scientist CSIRO Australia _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 14 14:40:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10313 for ; Fri, 14 Mar 2003 14:40:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJtlf04270 for avt-archive@odin.ietf.org; Fri, 14 Mar 2003 14:55:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJtJO04240; Fri, 14 Mar 2003 14:55:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJrmO04190 for ; Fri, 14 Mar 2003 14:53:48 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10237 for ; Fri, 14 Mar 2003 14:38:14 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h2EJeOT21999 for ; Fri, 14 Mar 2003 14:40:24 -0500 Message-Id: <200303141940.h2EJeOT21999@chiron.nge.isi.edu> To: avt@ietf.org Date: Fri, 14 Mar 2003 14:40:24 -0500 From: Colin Perkins Subject: [AVT] Slides for San Francisco meeting 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: , As slides for the San Francisco AVT meeting are submitted, I'm making copies available at http://www.east.isi.edu/~csp/avt56/ They will eventually migrate to http://www.ietf.org/proceedings/03mar/ Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 16 12:37:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00246 for ; Sun, 16 Mar 2003 12:37:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GHr0f12464 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 12:53:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHqLO12453; Sun, 16 Mar 2003 12:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHnwO12389 for ; Sun, 16 Mar 2003 12:49:58 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00158 for ; Sun, 16 Mar 2003 12:33:26 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2GHZcB3025927 for ; Sun, 16 Mar 2003 18:35:38 +0100 (MET) Received: from era.ericsson.se (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GPH6Z8ZT; Sun, 16 Mar 2003 18:35:37 +0100 Message-ID: <3E747129.8050900@era.ericsson.se> Date: Sun, 16 Mar 2003 13:42:17 +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:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us 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] Comments on draft-ietf-avt-rtp-retransmission-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, Here is a few comments on the RTP retransmission draft I think the draft is in very good state and I propose that it is moved forward with due swiftness. I at least has use of this format and would strongly encourage authors and chairs that this draft is progressed and becomes an Proposed standard RFC before september. My use case would be to include this in the 3GPP Packet-based streaming service (PSS) Release 6. 1. Section 4, last paragraph: "The M, CC and CSRC bit of the original RTP packet MUST be copied "as is" into the RTP header of the retransmission packet." I think one should change the start of the sentence as the use of bit is wrong. I would propose "The marker bit (M), the CSRC count (CC) field and CSRC list of the original packet MUST ..." 2. Section 8.1, Third paragraph: "If multiple payload types are used for the original streams, then multiple "apt" parameters MUST be included to map each original stream payload type to a different retransmission payload type." I think this is a bit unclearly formulated as it can give the wrong impression that multiple apt can be given for a single PT. I would suggest that one changes this to: "Each RTP retransmission payload type MUST be mapped to one and only one original payload type. If there is multiple original payload types, each of them needs to be mapped to its own retransmission payload type." 3. Section 8.1, Fourth paragraph: "An OPTIONAL payload-format-specific parameter, "rtx-time," indicates the maximum time a server will try to retransmit a packet." I think this is wrongly formulated. To my understanding the rtx-time correspond to the time that the sender will keep old packets in their retransmission buffer. This is also formulated on some other place in the draft. The above text also gives the impression that a server will perform retransmission automatically. I would suggest that one reformulates this to something like: "An OPTIONAL payload format specific parameter "rtx-time", indicates the time in milliseconds a sender will keep an original packet available for retransmission since its first transmission." The text needs to be updated also in all MIME registrations. 4. Section 9.1 First paragraph: I would like to add the following sentence to the end of that paragraph. "The SSRC value included in SETUP response's Transport header SHOULD be that of the original stream." This makes it clear on how to use the SSRC field when doing SSRC-multiplexed retransmission. 5 Section 12. With respect to the latest discussion on the aspects of using SRTP and what's written in this section I would recommend that some text is added to this section. I would propose to add to the end of the paragraph that starts "However, since ..". My proposal for text would be: "Still as it is possible to infer a lot of the RTP fields, including the OSN of the retransmission payload format, it is RECOMMENDED that any encryption has good properties against known plain-text attacks." I would like to have some comment on this from our SRTP experts. 6. Section 14.1 Update reference 3 to the new RTP draft. Could one also include [ ] around the reference numbers. I think this is clearer and follows the well used IEEE way of doing reference lists. 7. Please also look over how the page breaks falls out after editing. There are definitely cases when page breaks should not be allowed in the middle. One such example is the author list where Rolf Hakenberg's information is split over two pages. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 16 13:59:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02695 for ; Sun, 16 Mar 2003 13:59:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GJFMf16896 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 14:15:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJEpO16854; Sun, 16 Mar 2003 14:14:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G5brO26934 for ; Sun, 16 Mar 2003 00:37:53 -0500 Received: from co1.dslextreme.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05843 for ; Sun, 16 Mar 2003 00:21:36 -0500 (EST) Received: from WIND (hyervision.com [66.159.193.111]) by co1.dslextreme.com (8.12.8/8.12.6) with ESMTP id h2G5Fnvq002260; Sat, 15 Mar 2003 21:16:09 -0800 From: "Adam Li" To: "'Ietf-Avt'" Cc: , "'Scott Bradner'" , "'Colin Perkins'" , "'Allison Mankin'" , , , , , , , , , , , , , , , , , , , , , , , , , , , , Date: Sat, 15 Mar 2003 21:18:05 -0800 Organization: UCLA Message-ID: <001301c2eb7b$b0cc77d0$6c7ba8c0@divxnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2G5btO26935 Subject: [AVT] Issues for the file format for EVRC/SMV vocoder 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 Hi folks, The topic of the file format for EVRC/SMV vocoders hopefully will be discussed in this meeting at San Francisco. Below is a list of the issues that might be related to this topic. They are listed here as potential issues for you to consider before the discussion at the meeting. (1) Technically differences. Is there much difference in efficiency and performance between the format in draft-ietf-avt-evrc-smv and draft-garudadri-qcp? Are the differences simply on the file syntax? (2) Completeness. For EVRC codec data, formats defined in both document can handle it. For SMV codec data, the format defined in draft-ietf-avt-evrc-smv is currently the only file format that handles SMV data. draft-garudadri-qcp does not handle SMV at this time. (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has its first version submitted to AVT on November 2000. It has been actively worked on all these years, and is co-authored by people from seven companies and universities. It is currently on the RFC editor's queue. draft-garudadri-qcp is submitted in February 2003. Will there be concerns about the maturity of the drafts, particularly the handling of SMV codec hasn't been written in the later draft yet? (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2 for their CDMA networks, formats recognized by them are likely to be the most widely used format for those codecs. Which of the formats, as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has been considered by 3GPP2 for the format for storing EVRC and SMV data? (5) Document organization. Even though this is a rather minor point, but would there be enough reasons to trade-off for the additional complexity for having the MIME registration of EVRC/SMV refering to a separate and yet to be complete draft? Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If we want to consider deleting the file format that is in the draft for almost two years in the last minute before it becomes an RFC and using another yet to be complete new draft instead, we should be providing ourselves with the clear justification for doing so. I will not be there for the discussion unfortunately since I have not made the plan to attend in advance. However, I hope the list of potential issues above might be useful for us to discuss and consider. Wish we have a fruitful meeting in San Francisco. Adam _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 16 13:59:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02734 for ; Sun, 16 Mar 2003 13:59:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GJFRS16909 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 14:15:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJF0O16883; Sun, 16 Mar 2003 14:15:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJ2hO15788 for ; Sun, 16 Mar 2003 14:02:43 -0500 Received: from ithilien.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02372 for ; Sun, 16 Mar 2003 13:46:10 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2GIhVlb004402; Sun, 16 Mar 2003 10:43:31 -0800 (PST) Received: from [66.114.232.124] (vpn-10-50-0-42.qualcomm.com [10.50.0.42]) by magus.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2GIh89X006576; Sun, 16 Mar 2003 10:43:10 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <001301c2eb7b$b0cc77d0$6c7ba8c0@divxnetworks.com> References: <001301c2eb7b$b0cc77d0$6c7ba8c0@divxnetworks.com> X-Mailer: Eudora for Mac OS X v6.0a Date: Sun, 16 Mar 2003 10:42:07 -0800 To: "Adam Li" , "'Ietf-Avt'" From: Randall Gellens Cc: , "'Scott Bradner'" , "'Colin Perkins'" , "'Allison Mankin'" , , , , , , , , , , , , , , , , , , , , , , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 Subject: [AVT] Re: Issues for the file format for EVRC/SMV vocoder 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 9:18 PM -0800 3/15/03, Adam Li wrote: > The topic of the file format for EVRC/SMV vocoders hopefully will be > discussed in this meeting at San Francisco. We may be able to resolve this before the meeting, in email. If not, then I think it may be discussed at the AVT meeting. > Technically differences. While the formats do have some differences, the main difference is that the qcp format is currently used on different hardware and software to interoperably store codec frames. It doesn't appear to me that there is any difference in efficiency. > For EVRC codec data, formats defined in both document > can handle it. For SMV codec data, the format defined in > draft-ietf-avt-evrc-smv is currently the only file format that handles > SMV data. draft-garudadri-qcp does not handle SMV at this time. SMV is being added to the qcp format; it's just a trivial matter of adding a new identifier. > Maturity of the format definition. The format defined in draft-ietf-avt-evrc-smv was specified primarily for completeness of the document. At the time we were working on this draft, I and the other authors were unaware of the qcp file format. (I'm very sorry for this.) It turns out that the qcp format has been widely used on multiple platforms for some time, including Eudora email and Quicktime media player (both on both Mac and Windows), and millions of CDMA handsets I'm not aware of any current interoperable independent implementations of the format specified in draft-ietf-avt-evrc-smv. > Which of the formats, as > defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has been > considered by 3GPP2 for the format for storing EVRC and SMV data? The issue of which format to specify in 3GPP2 is currently being discussed. Most of the discussions to date have been on how to include evrc, smv, and qcelp-13k in an iso-based mp4 file format. The issue of specifying an independent file format for vocoders in 3GPP2 is new. > would there be enough reasons to trade-off for the additional complexity > for having the MIME registration of EVRC/SMV refering to a separate and > yet to be complete draft? This is very minor. However, if the qcp format were something new, and not currently deployed, I'd be the first to say that we should stick with the format in draft-ietf-avt-evrc-smv. It's only because of the existing interoperable use of the qcp format that I agree with making it the file format for the registrations. > Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If we > want to consider deleting the file format that is in the draft for > almost two years in the last minute before it becomes an RFC and using > another yet to be complete new draft instead, we should be providing > ourselves with the clear justification for doing so. I completely agree with you. I have zero desire to delay draft-ietf-avt-evrc-smv. In fact, my initial suggestion, as written in the qcp draft, was to take the easier path of not changing draft-ietf-avt-evrc-smv at all, and instead to have the qcp draft register a new MIME type (audio/qcp) which can be used to store evrc, qcelp (and SMV). I knew this was a kludge (since the qcp format is already in use) but wanted to do what was quickest and easiest. However, I was clearly told that this was not acceptable -- that we should do what is technically correct: allow draft-ietf-avt-evrc-smv to progress but without the file format, and change the qcp draft to modify the MIME registrations. I agree that this is the correct way to proceed. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is so much to be said in favor of modern journalism. By giving us the opinions of the uneducated, it keeps us in touch with the ignorance of the community. --Oscar Wilde _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 16 14:11:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03248 for ; Sun, 16 Mar 2003 14:11:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GJS1V17383 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 14:28:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJRGO17366; Sun, 16 Mar 2003 14:27:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GJFIO16892 for ; Sun, 16 Mar 2003 14:15:18 -0500 Received: from numenor.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02666 for ; Sun, 16 Mar 2003 13:58:44 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2GItnKn019085; Sun, 16 Mar 2003 10:55:49 -0800 (PST) Received: from [66.114.232.124] (vpn-10-50-0-42.qualcomm.com [10.50.0.42]) by magus.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2GIta9X007772; Sun, 16 Mar 2003 10:55:37 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v6.0a Date: Sun, 16 Mar 2003 10:54:48 -0800 To: "Lars-Erik Jonsson (EAB)" , "'Randall Gellens'" , Adam Li From: Randall Gellens Subject: RE: [AVT] File format for EVRC/SMV vocoder Cc: Ietf-Avt , , "'Scott Bradner'" , "'Colin Perkins'" , "'Allison Mankin'" , , , , , , , , , , , , , , , , , , , , , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b25 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 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote: > OK, but why has not this issue been brought up earlier? Because of an unfortunate oversight. Neither myself nor the other authors of the evrc/smv draft were aware of the qcp format. I very much regret this. At the time we were working on the evrc/smv draft, we specified a file format to make the draft complete. Had we been aware of an existing format that was currently being used to interoperably exchange vocoder frames, I'm sure it would have been considered instead of inventing something new. > The EVRC/SMV > format work in AVT has been going on for a long time, and therefore one > can question whether it is correct (from a procedural point of view) to > suddenly not use what has been developed in this WG, but use something > defined elsewhere. IETF standardization is usually an engineering > process, not rubber-stamping of already deployed technical solutions. When I learned of the qcp format, my suggestion for how to proceed was to register a new mime type (audio/qcp) so as to not risk delaying the evrc draft. (As one of the authors of that draft, I have no desire to delay it at all.) This is what the current qcp draft says. However, I was told to do the technically correct thing instead. > Note that I am not aware of all the details in this matter, but what > has been communicated on the list does not provide enough material for > motivating what has been proposed. "We have already deployed this > alternative format while you were trying to agree on a standard, and > now we think you should use our format instead since it is more > widely deployed" is a rather strange way of arguing in standards > development, I think. The QCP format was in deployment when we started working on the evrc/smv draft, but neither I not the other authors were aware of this. It's not the case that the qcp format was deployed afterwards or in parallel, in an attempt to circumvent process. The question now is how best to proceed. As I said, my initial suggestion was to take the easy path of not deleting the file format from the evrc/smv draft, and instead to use a kludge of registering a new mime type for the qcp file format. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Laughter is the closest distance between two people. --Victor Borge _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 16 15:09:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05481 for ; Sun, 16 Mar 2003 15:09:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GKPtf20605 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 15:25:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKPaO20597; Sun, 16 Mar 2003 15:25:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GKOjO20542 for ; Sun, 16 Mar 2003 15:24:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05150 for ; Sun, 16 Mar 2003 15:08:10 -0500 (EST) From: David.Leon@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2GKAQa06733 for ; Sun, 16 Mar 2003 14:10:27 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 16 Mar 2003 14:10:22 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 16 Mar 2003 14:10:22 -0600 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" Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-retransmission-06.txt Date: Sun, 16 Mar 2003 14:10:21 -0600 Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD01668E22@daebe008.americas.nokia.com> Thread-Topic: [AVT] Comments on draft-ietf-avt-rtp-retransmission-06.txt Thread-Index: AcLr4vG0HM2v4zmMTeuSwvH7u4QKzAAFP/CA To: , X-OriginalArrivalTime: 16 Mar 2003 20:10:22.0106 (UTC) FILETIME=[12E2B7A0:01C2EBF8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2GKOjO20543 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 Hi Magnus, Thanks a lot for your detailed review. We will make the changes you recommend to the draft. David. > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] > Sent: Sunday, March 16, 2003 6:42 AM > To: avt@ietf.org > Subject: [AVT] Comments on draft-ietf-avt-rtp-retransmission-06.txt > > > Hi, > > Here is a few comments on the RTP retransmission draft I > think the draft > is in very good state and I propose that it is moved forward with due > swiftness. I at least has use of this format and would strongly > encourage authors and chairs that this draft is progressed > and becomes > an Proposed standard RFC before september. My use case would be to > include this in the 3GPP Packet-based streaming service (PSS) > Release 6. > > 1. Section 4, last paragraph: "The M, CC and CSRC bit of the original > RTP packet MUST be copied "as is" into the RTP header of the > retransmission packet." I think one should change the start of the > sentence as the use of bit is wrong. I would propose "The marker bit > (M), the CSRC count (CC) field and CSRC list of the original > packet MUST > ..." > > 2. Section 8.1, Third paragraph: "If multiple payload types > are used for > the original streams, then multiple "apt" parameters MUST be > included to > map each original stream payload type to a different retransmission > payload type." I think this is a bit unclearly formulated as > it can give > the wrong impression that multiple apt can be given for a > single PT. I > would suggest that one changes this to: "Each RTP > retransmission payload > type MUST be mapped to one and only one original payload > type. If there > is multiple original payload types, each of them needs to be > mapped to > its own retransmission payload type." > > 3. Section 8.1, Fourth paragraph: "An OPTIONAL > payload-format-specific > parameter, "rtx-time," indicates the maximum time a server > will try to > retransmit a packet." I think this is wrongly formulated. To my > understanding the rtx-time correspond to the time that the > sender will > keep old packets in their retransmission buffer. This is also > formulated > on some other place in the draft. The above text also gives the > impression that a server will perform retransmission automatically. I > would suggest that one reformulates this to something like: > "An OPTIONAL > payload format specific parameter "rtx-time", indicates the time in > milliseconds a sender will keep an original packet available for > retransmission since its first transmission." The text needs to be > updated also in all MIME registrations. > > 4. Section 9.1 First paragraph: I would like to add the following > sentence to the end of that paragraph. "The SSRC value > included in SETUP > response's Transport header SHOULD be that of the original > stream." This > makes it clear on how to use the SSRC field when doing > SSRC-multiplexed > retransmission. > > 5 Section 12. With respect to the latest discussion on the aspects of > using SRTP and what's written in this section I would recommend that > some text is added to this section. I would propose to add to > the end of > the paragraph that starts "However, since ..". My proposal for text > would be: > "Still as it is possible to infer a lot of the RTP fields, > including the > OSN of the retransmission payload format, it is RECOMMENDED that any > encryption has good properties against known plain-text attacks." I > would like to have some comment on this from our SRTP experts. > > 6. Section 14.1 Update reference 3 to the new RTP draft. > Could one also > include [ ] around the reference numbers. I think this is clearer and > follows the well used IEEE way of doing reference lists. > > 7. Please also look over how the page breaks falls out after editing. > There are definitely cases when page breaks should not be > allowed in the > middle. One such example is the author list where Rolf Hakenberg's > information is split over two pages. > > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Sun Mar 16 17:03:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09692 for ; Sun, 16 Mar 2003 17:03:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GMJCq29478 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 17:19:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMIdO29456; Sun, 16 Mar 2003 17:18:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMGdO29417 for ; Sun, 16 Mar 2003 17:16:39 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09668 for ; Sun, 16 Mar 2003 17:00:03 -0500 (EST) Received: from mcomlap9 (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HBV00F1L3TC53@panasonic.de> for avt@ietf.org; Sun, 16 Mar 2003 23:00:53 +0100 (MET) Date: Sun, 16 Mar 2003 23:00:50 +0100 From: =?iso-8859-1?Q?Jos=E9_Rey?= Subject: AW: [AVT] Comments on draft-ietf-avt-rtp-retransmission-06.txt In-reply-to: <3E747129.8050900@era.ericsson.se> To: Magnus Westerlund , avt@ietf.org Cc: David Leon Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Hi Magnus, thanks for your comments. I clipped off the comments on editing and wording, which will be taken care of. I only address the following: > 4. Section 9.1 First paragraph: I would like to add the following > sentence to the end of that paragraph. "The SSRC value included in SETUP > response's Transport header SHOULD be that of the original stream." This > makes it clear on how to use the SSRC field when doing SSRC-multiplexed > retransmission. > OK. > 5 Section 12. With respect to the latest discussion on the aspects of > using SRTP and what's written in this section I would recommend that > some text is added to this section. I would propose to add to the end of > the paragraph that starts "However, since ..". My proposal for text > would be: > "Still as it is possible to infer a lot of the RTP fields, including the > OSN of the retransmission payload format, it is RECOMMENDED that any > encryption has good properties against known plain-text attacks." I > would like to have some comment on this from our SRTP experts. > Yeah, a comment on this is needed . Your proposed text above names a lot of "RTP fields", I am not sure what you mean. The only field that is potentially send both as clear tex and encrypted is the (O)SN field. I would limit the text to that. cheers, José _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 16 17:26:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10643 for ; Sun, 16 Mar 2003 17:26:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GMg9v31123 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 17:42:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMfNO31054; Sun, 16 Mar 2003 17:41:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GMeWO31036 for ; Sun, 16 Mar 2003 17:40:32 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10456 for ; Sun, 16 Mar 2003 17:23:56 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2GMQ7wv015340; Sun, 16 Mar 2003 23:26:07 +0100 (MET) Received: from era.ericsson.se (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id GZALBG8K; Sun, 16 Mar 2003 23:26:07 +0100 Message-ID: <3E74F9F8.40605@era.ericsson.se> Date: Sun, 16 Mar 2003 23:26:00 +0100 X-Sybari-Trust: 84f8bfd4 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jos=E9?= Rey CC: avt@ietf.org Subject: Re: AW: [AVT] Comments on draft-ietf-avt-rtp-retransmission-06.txt References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 José Rey wrote: >>5 Section 12. With respect to the latest discussion on the aspects of >>using SRTP and what's written in this section I would recommend that >>some text is added to this section. I would propose to add to the end of >>the paragraph that starts "However, since ..". My proposal for text >>would be: >>"Still as it is possible to infer a lot of the RTP fields, including the >>OSN of the retransmission payload format, it is RECOMMENDED that any >>encryption has good properties against known plain-text attacks." I >>would like to have some comment on this from our SRTP experts. >> >Yeah, a comment on this is needed . Your proposed text above names a lot of >"RTP fields", I am not sure what you mean. The only field that is >potentially send both as clear tex and encrypted is the (O)SN field. I would >limit the text to that. > Actually I was a little bit to restricted in my description. First this does not only apply to SRTP, but also like the DES encryption of the complete RTP packet. Which means that all of RTP header can be known if you know the entry point, for example through RTSP signaling. Then some payload formats has rather lot of known fields. So what I mean with RTP fields are both RTP header fields, and RTP payload. I hope that this clarifies and I understand that improvements of the language seems to be requirement. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 16 23:16:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18700 for ; Sun, 16 Mar 2003 23:16:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H4WE218415 for avt-archive@odin.ietf.org; Sun, 16 Mar 2003 23:32:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4VhO18379; Sun, 16 Mar 2003 23:31:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4TQO18263 for ; Sun, 16 Mar 2003 23:29:26 -0500 Received: from snowy.nsw.cmis.CSIRO.AU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18576 for ; Sun, 16 Mar 2003 23:12:42 -0500 (EST) From: Silvia.Pfeiffer@csiro.au Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id PAA22142; Mon, 17 Mar 2003 15:14:15 +1100 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa005Pv; Mon Mar 17 15:14:09 2003 Received: by coxs-nh.nsw.cmis.csiro.au with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Mar 2003 15:14:08 +1100 Received: from csiro.au (klee.nsw.cmis.csiro.au [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id GY5X4ML0; Mon, 17 Mar 2003 15:14:07 +1100 To: William.C.Miller@abc.com Cc: Conrad.Parker@csiro.au, s22-list@eng.smpte.org, avt@ietf.org Message-ID: <3E754BDA.70307@csiro.au> Date: Mon, 17 Mar 2003 15:15:22 +1100 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Comments, draft-pfeiffer-temporal-fragments-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: 7bit Dear Mr. Miller, I am delighted to get feedback from you and the SMPTE community on our timed URI fragment specification proposal. I would like to thank you very much for your well elaborated comments which we are more than happy to include into our proposal. We will be developing another version of the document over the next few weeks. If I may, I would like to forward you the next version, just to make sure we haven't overlooked anything. Also, in case there are any relevant changes in the new version of SMPTE 12M, I would be very happy if you could make me aware of them. Thank you very much indeed. Best Regards, Silvia Pfeiffer. Miller, William C wrote: > Dear Ms. Pfeiffer and Mr. Parker, > > Your draft was recently passed on to me by a SMPTE colleague. I'd like > to offer a couple of comments. I am not familiar with all of the > practices of the IETF community, so forgive me if I commit a solecism or > two along the way. > > I'm chairman of SMPTE S22, the TV Systems Technology Committee, which > has responsibility for SMPTE time code. I'm writing as an individual > commenter. > > 1. SMPTE has about 400 Standards, Recommended Practices and Engineering > Guidelines, of which SMPTE time code is just one. The reference you > should cite is SMPTE 12M-1999, Time and Control Code. Be aware that we > are in the process of considering revisions to this document. > > 2. The current version of SMPTE 12M defines time code for 24, 25 and 30 > frames per second (fps). Video production standards for all of these > exist and are in use. A drop-frame mode is defined for 30 fps (actually > 30/1.001 fps) to cover 525-line systems (NTSC time-compensated mode). > However, there are now 50, 60 and 60/1.001 fps video production > standards, and practices have evolved to deal with these within the > structure of SMPTE 12M. These practices will be added to 12M as it is > revised. A possibility also exists that there will be 24/1.001 fps video. > > To be safe you should define syntax to handle all 8 of these rates (all > are allowable under MPEG-2, for instance). Recapping them in order: > > 24/1.001 "24-drop" (this algorithm is not defined) > 24 > 25 > 30/1.001 "30-drop" > 30 > 50 > 60/1.001 "60-drop" (same algorithm as 30-drop, but 4 frames dropped > rather than 2) > 60 > > Your draft gives 30 fps (non-drop) as the default; in practice this is > the least likely frame rate to be encountered. I believe it is > preferable to require explicit coding of the frame rate, e. g. > "smpte-30-time". "smpte-time" should be allowed only for those cases > where the user does not know the frame rate; this would serve as a wild > card, with best-effort address resolution (the error would be no more > than one second, typically much less). > > 3. Although not generally understood as such, SMPTE time code is a > label. Its lowest granularity is the frame for progressive-scan and > film material and the field for interlaced material. Fractional frames > (fields) are meaningless for video, and in the case of the /1.001 rates > are ambiguous for audio. I urge you to delete "smpte-sf". > > 4. The first frame of video of a program is normally 01:00:00:00, not > 00:00:00:00. This practice arose from the requirements of program > production and analog videotape recording technology, and it has > subsequently become a uniform, almost ironclad practice worldwide. > Users should be made aware of this in an informative note. > > I hope these comments are of help in refining your draft. I am > attaching a copy of SMPTE 12M for your use. Please do not redistribute > it except to those involved in the development of this RFC. Thanks. > > If I can be of further help please let me know. > > Best regards, > Bill Miller > > > > William C. Miller > ABC-TV > 212-456-4448 > 212-456-2284 fax > william.c.miller@abc.com > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 17 00:19:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20561 for ; Mon, 17 Mar 2003 00:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H5a6p22537 for avt-archive@odin.ietf.org; Mon, 17 Mar 2003 00:36:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5ZeO22453; Mon, 17 Mar 2003 00:35:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H0XCO03982 for ; Sun, 16 Mar 2003 19:33:12 -0500 Received: from numenor.qualcomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13731 for ; Sun, 16 Mar 2003 19:16:33 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2H0DCKn026064; Sun, 16 Mar 2003 16:13:12 -0800 (PST) Received: from HGARUDAD.qualcomm.com (pptp-10-50-65-37.qualcomm.com [10.50.65.37]) by crowley.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2H0CtZJ016862; Sun, 16 Mar 2003 16:12:56 -0800 (PST) Message-Id: <5.1.0.14.2.20030316153321.01e01b08@m3.qualcomm.com> X-Sender: hgarudad@m3.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 16 Mar 2003 16:12:22 -0800 To: "Jae-Yong Lee" , "Pete McCann" , "Randall Gellens" From: Harinath Garudadri Subject: RE: [AVT] File format for EVRC/SMV vocoder Cc: "Lars-Erik Jonsson (EAB)" , "Adam Li" , "Ietf-Avt" , , "Scott Bradner" , "Colin Perkins" , "Allison Mankin" , , , , , , , , , , , , , , , , , , , , , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_172821323==_" 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: , --=====================_172821323==_ Content-Type: multipart/alternative; boundary="=====================_172821323==_.ALT" --=====================_172821323==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:04 AM 3/17/2003 +0900, Jae-Yong Lee wrote: >Hi all, > >To my best knowledge, QT is supporting QCELP "codec" >(in QT file format), not the .qcp file format. I was able to create a qcp file in my Eudora client and send to someone who uses a different email client. When he launched Quicktime for this file, he was able to play the file as is and also convert the file to .mov format. Here is the .mov version of the file for those who have Quicktime. >Jay > > > > > Hi, Randy, > > > > Are there any intellectual property issues with the qcp format? > > > > Also, were the interoperable implementations of the qcp format really > > done independently? My understanding is that Eudora is a Qualcomm > > product and that Apple acted merely as an integrator and distributer > > of the PureVoice technology from Qualcomm. If these implementations > > are not independent it may be misleading for you to talk about > > interoperability. > > > > -Pete > > > > > > Randall Gellens writes: > > > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote: > > > > > > > OK, but why has not this issue been brought up earlier? > > > > > > Because of an unfortunate oversight. Neither myself nor the other > > > authors of the evrc/smv draft were aware of the qcp > > format. I very > > > much regret this. At the time we were working on the > > evrc/smv draft, > > > we specified a file format to make the draft complete. > > Had we been > > > aware of an existing format that was currently being used to > > > interoperably exchange vocoder frames, I'm sure it would have been > > > considered instead of inventing something new. > > > > > > > The EVRC/SMV > > > > format work in AVT has been going on for a long time, > > and therefore one > > > > can question whether it is correct (from a procedural > > point of view) to > > > > suddenly not use what has been developed in this WG, > > but use something > > > > defined elsewhere. IETF standardization is usually an > > engineering > > > > process, not rubber-stamping of already deployed > > technical solutions. > > > > > > When I learned of the qcp format, my suggestion for how to proceed > > > was to register a new mime type (audio/qcp) so as to not risk > > > delaying the evrc draft. (As one of the authors of that draft, I > > > have no desire to delay it at all.) This is what the current qcp > > > draft says. However, I was told to do the technically > > correct thing > > > instead. > > > > > > > Note that I am not aware of all the details in this > > matter, but what > > > > has been communicated on the list does not provide > > enough material for > > > > motivating what has been proposed. "We have already > > deployed this > > > > alternative format while you were trying to agree on a > > standard, and > > > > now we think you should use our format instead since it is more > > > > widely deployed" is a rather strange way of arguing in standards > > > > development, I think. > > > > > > The QCP format was in deployment when we started working on the > > > evrc/smv draft, but neither I not the other authors were aware of > > > this. It's not the case that the qcp format was deployed > > afterwards > > > or in parallel, in an attempt to circumvent process. > > > > > > The question now is how best to proceed. As I said, my initial > > > suggestion was to take the easy path of not deleting the > > file format > > > from the evrc/smv draft, and instead to use a kludge of > > registering a > > > new mime type for the qcp file format. > > > > Hari Garudadri (from Vancouver, B.C.) mobile : 858-229-2801 --=====================_172821323==_.ALT Content-Type: text/html; charset="us-ascii" At 08:04 AM 3/17/2003 +0900, Jae-Yong Lee wrote:

Hi all,

To my best knowledge, QT is supporting QCELP "codec"
(in QT file format), not the .qcp file format.

I was able to create a qcp file in my Eudora client and send to someone who uses a different email client. When he launched Quicktime for this file, he was able to play the file as is and also convert the file to .mov format. Here is the .mov version of the file for those who have Quicktime.


Jay

>
> Hi, Randy,
>
> Are there any intellectual property issues with the qcp format?
>
> Also, were the interoperable implementations of the qcp format really
> done independently?  My understanding is that Eudora is a Qualcomm
> product and that Apple acted merely as an integrator and distributer
> of the PureVoice technology from Qualcomm.  If these implementations
> are not independent it may be misleading for you to talk about
> interoperability.
>
> -Pete
>
>
> Randall Gellens writes:
>  > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote:
>  >
>  > >  OK, but why has not this issue been brought up earlier?
>  >
>  > Because of an unfortunate oversight.  Neither myself nor the other
>  > authors of the evrc/smv draft were aware of the qcp
> format.  I very
>  > much regret this.  At the time we were working on the
> evrc/smv draft,
>  > we specified a file format to make the draft complete. 
> Had we been
>  > aware of an existing format that was currently being used to
>  > interoperably exchange vocoder frames, I'm sure it would have been
>  > considered instead of inventing something new.
>  >
>  > >   The EVRC/SMV
>  > >  format work in AVT has been going on for a long time,
> and therefore one
>  > >  can question whether it is correct (from a procedural
> point of view) to
>  > >  suddenly not use what has been developed in this WG,
> but use something
>  > >  defined elsewhere. IETF standardization is usually an
> engineering
>  > >  process, not rubber-stamping of already deployed
> technical solutions.
>  >
>  > When I learned of the qcp format, my suggestion for how to proceed
>  > was to register a new mime type (audio/qcp) so as to not risk
>  > delaying the evrc draft.  (As one of the authors of that draft, I
>  > have no desire to delay it at all.)  This is what the current qcp
>  > draft says.  However, I was told to do the technically
> correct thing
>  > instead.
>  >
>  > >  Note that I am not aware of all the details in this
> matter, but what
>  > >  has been communicated on the list does not provide
> enough material for
>  > >  motivating what has been proposed. "We have already
> deployed this
>  > >  alternative format while you were trying to agree on a
> standard, and
>  > >  now we think you should use our format instead since it is more
>  > >  widely deployed" is a rather strange way of arguing in standards
>  > >  development, I think.
>  >
>  > The QCP format was in deployment when we started working on the
>  > evrc/smv draft, but neither I not the other authors were aware of
>  > this.  It's not the case that the qcp format was deployed
> afterwards
>  > or in parallel, in an attempt to circumvent process.
>  >
>  > The question now is how best to proceed.  As I said, my initial
>  > suggestion was to take the easy path of not deleting the
> file format
>  > from the evrc/smv draft, and instead to use a kludge of
> registering a
>  > new mime type for the qcp file format.
>
>

Hari Garudadri (from Vancouver, B.C.)
mobile : 858-229-2801
 --=====================_172821323==_.ALT-- --=====================_172821323==_ Content-Type: video/quicktime; name="D3G56126.qcp.mov"; x-mac-type="4D6F6F56"; x-mac-creator="54564F44" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D3G56126.qcp.mov" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 AAAACHdpZGUAACkMbWRhdASIeDfpgADwWSSDAuyCAGDBvq1ZcbGjguICWc4ARpcp7TrAA55uNu6w AJgdGlOL4lY8DkAAAAAAAAAAAAAAAAAAAAAAAAABA2MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAHgCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZN3AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABLHcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFY IQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8aAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAB+J4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHPwwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYPLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABOCcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFYMgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAU6SAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByDIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEKowAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAYC7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABidMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAFLegAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfxr AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB9/MAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAG8zgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAFAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAGADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaiCAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABgIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGMggAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZKCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABLYIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHqgwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAUCPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQR4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS7LrbkKbbS3n6ySKFCs83sttzPs6jqA+kd lO099LSgbSNABPIqbaLFHEyvxM46mE8ZGc+2kU1r1zXVJWnMWTKrKhjVCgAEaCrlZs0CJSL7Tmy+ t1MQ16OH5T7UzZUhkwKTmP1EERUKAATwKh6qxOtcxClKagm3OQTRs1OPPbyk3OSdVhM8AzYcsA2A BHIy5qw+YsRMCrrOWnUTRtEZt080Psz1narN8T5tG5hQL4AEV6omG8TyNJgiyeTg9y7dMdQ00iFO RJP9ehgvYD7iVhAsAATHFrYRSvmkkhbSh5SI4xfzsVvQJUCjG+QRzHL+7uA+jjNABM1yuRHHKWwg EEVG5TE+8fFwyhQMv3tjszTPrHrezzmNBYAEZkE4wTvhw6QLP6tEWM/jLxCkDx1AW/urMkmP9Lzb J64pgAS6OSYcKPLz0wM9CFWWobgN6bIPl7ILTEEA1Uu4yr5DzTWABN8hBxGx0NNAvrAmGTi/26vl kCARsOvL/TfVyDwmygpRAsAEypI16THYEl/QLEcAJt+nTcLI7houYiuQjttvnKa1Ne08gATqKm+g P9cDxK6xXu3JKGLwtQFPIVM8xD/cUO+ery5f9SHABOIy5ifVC/SYx01FOUr0N/PSX9ImTHX06p3H 80oPP2PRC0AEIJJdp8UqMxf0xomQevTr7vPmk53SDcyaXQSRwFEZW/APgARovOTgvTFLiN5M6/4r FO1MQERwmr+Ec+wFidHO5w5TDj0ABMasZuU1SSMaPbU0qXj1DFDia9SRsEtUZrlEr8h41i2sLMAE KronFrFh5HQ6u2sAXLzBDMak64+5wvM4yY2PUDyvQw4cwARqEl+pNTqTrg8/TdWeuwnLJQ9VrDCb TA++QhFIrv0orQsABHgyXq29I3xgmsaT3NLU4C6HoNI4v8SrPNDYtUiDSA4uG8AEYhZvrT0jlHSU QqzVizRlkKFnUyI/BZw705IQTikYezUMQARoFuSsRUK8Exy3L3mjPBnx4mVUt0GURNapURNUpyxA kzbABNy+kpNVUY3+c1loWYE/KHJUrwALRCWU4DkS8ACNAVZOH0AEMpCs4D2BpAOQOsXMZNXyciFi /JG0U2wxDFUP7hD9Fww6wATXEqfltVGSk+apxUXC1OuPCGRVLrfkMw1cTw1Yyt9FsRLABIZSt0G1 SZrWdDdEElb1nslGcFUSr+uSohzVTVJ0hE2KFwAEzH62QalhUxGiLcNIcI96aefaPI4nk4ofTFnp 7ry6du4AwARofYQRKbI7ExCvacn0+K3NdL6e8t6TvkXUGRa3O1wrMC0ABHM5dUlNIHSJRVNi3ZUn LzIikRw2VOXlbp7WNfQbbSUTPUAEdhYmSUrQXhK9WeC9/SUgNuRnPAvRvNSmVpXRTHEWJfQ2QAQy GaSjXP4dTSrLHsiFmZJ7oguOs1wlPkXWytM6aWde1woABMCZpm1M6g4XbsjKnUtTWBNA2Q+k3L5F oTfQtT7PInL4JEAExzJn1NkBE5uOTiTYi5QTMvXTahTXtWvdaUexsFFWcZIlgASQtbYRyPvkhgHX pYwlVCEQclVOnM31BmN5l7BAkQ5/MgTABMc9txNMOPzc7lOHnAVsTxZU/wAAwwU8+XiRMwxpJUtR BsAEhr7Q0ktoHPiQuuSIDSs6c1UtoIm/2xQ5TloQ1Bk3Pi4LgASSnscaN4jkIEbK5tUzL9ax9Dz6 A8rqC0kplLCKGvRZTAkABNiZthMwAAxBcrDnlO791K4iMI8XMKIDDTwmLXrGyX6KNcAE2q5hmz9h 8s2nqefU8rPIDTWm4B+3CqtqiIsMOKLOYE4QwAQvOaO2R1nz8ERCSt3G4DaQlRf48mSk1cVJCDKa qRgd0jrABJNuuMpK8OuwJUEEhcUEOzDCRRABR8S8wVKM8YL7JiOxJ0AEgr77Erjw5I7Gy6G87unv LvRIvYYyg8t5CQ6u5ojGXaoKAATSTpIRMmDbP8+7hpWsyPJOZUT1rEbbG/Iyg4yUjNJKDThABL1d oM6zSGs0FTbHerrm9rH1KhgLOJuUNbjPbl4JEEaOIgAE3DJPUbLRfALlueP9HxgGzSKZzyk+s4uy xVuV66FyES4MgAQiFq5vzNukbaTIECHa9EWzsvFQp0Fsy++h5u9EpQgusQeABLo8hRhNEru+N0DG ZXDaClLlU1InxSwDuDvOj0Rw2EEKKMAEMjw3E1UDtDyWQGb46tT0rDLQ75U+IttCedYtRmSaUk4y QAQqGmZntSMD6ac/ycSw9O+txPTTuL7KVGu8CS3EnutJky+ABPISBUJVNexJpUbN6XL0Ow2XFVQk tayzKOvZE06O/BQNCoAE+iw4TD07K0lMR+gxLxQWjJaDUyhEZNNeV4luvJcOPNEIAATXIjbjvxBr mnWyAc3AwMWw41p4gq7rEuxwEklo2tNMKhgABNKsBBs5MwNwKSsGDTy3mqgLiFAPqZKLVFjjK+Te nBpJKwAETno306WICzVfLXCm/PWkSrGQUq2xEzKxbQ6LTqKfdKsNQAS/fSFGqYl6+UQuqWG+z+Ds 1ySZ/EYD/DhgItBje0I6EgSABLNyYexDIcxJgUUAyIbP6C904JkPMtMEIlzHD2SC/FuQOwAEb3lT BTk586SoQYsQdO7mcdKULijJ9KufOJTQyQsNRXMNQATZvbkBSXvs54DWhyCDI0MzNO2PjdPsrI9l SRaoAS8/kysABGa8NwnJQEzMmUrmvDdEC5EU/xMDTM1s6r7MdUB7MlmwHAAE4LybikzM7KNVycsp /S9bk3BTTy/DFARicE4TQM0yBU8IAATqPIQnPRKkDGJXiM0tNMXPObaSJEckTHDNS3NIhTopUSlA BGiCZey+vFQ9Yk9rWUsUHtXiTVMpt+TjgTbQkk5TNwZPNoAEtrqEGEcBzLV1wWCNVzvBrnnG06TO FJRcEMoTwsb8VA8mwATBgtDTOABMQ9NCAcw04DvwIyekIDHDg6VpDY5EqQJcERaABD9+tzhDoHQv OTmHMG8PBfNkczoHw3T7yWXRMGSlLB7uHUAEO1LWFkH7Q8CtyCMIGxT+bhTYg4HHK1vUFRVwjPEq NY4lQATTbs6qP7hUIjdCwo124BuRE5O2njsLJAkGDXCsHxddkB6ABD588Ws5WHvfWzQGQT7ozC6l 1rSLs3KLsVXLLUCqwFNvDEAE8jywTb/dC/WVP1HFNTMT0oGZTyFJXLsuWBARQIEJUfULAATqLISG tQkL1Fc7RtZ3FO3uwv7RIbDTLMFu0nGssukH8RuABLi8hUQ9IxyVKUqp8arkxnBFrlKcn+oruTXd jciSwj+tMYAEply1TiE6SiSyK8jR9PRm7OWiQpUziwx5d04PRqT8WeYMgASXXDVPNSFTf+WgRDkm vaWuFZxWEyejus5JC8tILsl5izcABN9SNO+t6rK+QJosApae0AkkwNK8uFrqTgbWSV66ozxPLoAE nzI34T9RyvB4q+EodruorbL6kK0gOqKVrZOM6E6cWioCAAQ00rSLLQrjNjWdLk7E4eNMkk4KMT4k W+h01cyu4sVKUScABPCc0ujAOTQdGMiC3XTsJjEymR6QPaRkTBdJMTvK6ADvKoAE8KwzhjTqfSCj 1OygNPklUPlvEaM8TOSRnMWvRvT7MpEEwARwnHlNxrrkN7W7jNx89DrvRRFSKL7DtAlR2y2ycvkn Cz9ABGsQ04s1IkOAVL7LbXbUrmuJSNM9OYMCkfpXrbbnHzjKMIAE7JyjhsbcRM2hNMoI1vQUDIMN cpSxrBxF29qTuMEyFTEyQAT8rGOKxuOUNlY1yc2S5PtxCTCTLrxDG7qJFBO4XzA5DgmABOycdwC2 4vzF4z+qBIEUKU8i9e4VOzvbe4UIcUprFlJuHEAExrqGQT0yZCdvxMztcNsa7mfJUjdBNPzHbFfR VlzeKA8FgAQs/HrjOVAbwUY7K0WtARWPcuMtHMRsZFC8QNJKztwZMBdABJd+UU05YvQTdLvirTE0 Ds90Z5ULM/Mkj0mMLPS1GmLOE0AEwtZ24z1xTDYRxWep9Rw1j9UbMxNFrKQTpxRS9rbkXvAEwASH bjFBQdj0SClJoZDpFNfxVZqPmkhbnD8WTVPg5ulYryeABJsu9do2aV0IHsHhvZbv3g1ZpvcNO/QE bAJIrmoM9ECsFYAEij1ZVLtJW7QGvn/Jx0QTtUB1zVPcRhWkns6VSPdjYrUfAASaPare5TolV4nO 6hnxVEg39NfUMN9MpKLGidNQyzB9MR/ABAo9jDtNSUSiZ8tHBWFlEzdFWTISUYWVfFzP0FQjA2QQ LwAEkJktotch5G9D0Ir57xxJUjG38idPbJyUsxERVC8DVM4GQATeFsyuuVI0rAvLLBL1VT/05mMU lLotorJLGVlQn1E3jhrABGoyLyHNOgxm2FAq5LMFBbPGYZQoQSSc0qQe71CRMFmxP8AEZnqMidb6 TBbq1A3xszU6MRIp8hdWJI08cIlPzuUIUZExgASokvfsSVHUDRZGKHB9NQRRsmPUrEVcU9QRSRFS tv8plCyABNtqBhtFUyvfcEFEKasl2+7BoNUR1BT0H5zA7pBRHSDULgAEzlJ05Tk4vBBiwCddtwXP k3eqVBM6/IxXO8mQUkLhJrMRQASQ4roRuVnr4nA/BFC09QTtAoP6jbbDA7NSFg5SbNFpDx6ABK5W +0S3ScwaPLTFQUjMDdCzr5YAQwsb8HsVTMA22jfOJwAEnzY4GbuYA6n9r6bVNM/nMHRucaczU5ut OB5MeoLXJGw7wASsNkEXr9Dy8m6t6EWItdmsq5hP/rUUzHH9rbTDJSAN8QcABIwZCttFE/OpFdAv jY87FzKzv9OdRK0tJZNFFFLBKjiRJoAEHhkq0TlT/S7GV0sE5vU1cee11SvRg4RKh8wTViN/BVU7 wAQaGTGVTVqTwRjPK1VRPS9Sl2GWJNejdcWwhDVYxw4oMjpABBopB83NYrvRrjuL4YM1TBNjJVYg Pyu8GLZalVj/PD5TJMAEAJmHmL1i1I7wvwYcGR077qU7lq85swQWr9fNWJr2EpUxwAQeFmbdPWMS zQK+Kd23HQVPsQ/WrDFjWylTFWnaTv2RlSSABA8+hNk90MSuQDyK4Jj1yExADpaVsDOCuaQaEFye 3zwOIkAEH3qn1z+wWxOKvWpR6QfeqyeiVhma+4MycFCLqMbCRgo4wAQSrKZeMqF7oWG0D8HtFedv 4AJVMcHii8n3U0xU4raY6j0ABItMzqg5WqLYSynLLTbczqoyoNW9utNK1bYSTlb5FijwJAAEn3qX 5z1SS8lDQGihgKXxL3eCliNHNMNrqk6tWHUKNLMyQARIXkt+viWMagTWfTlLnFwZR7+WnkDUFJK0 TlVaey8TNweABFUOqrVJc2TNE0DOJI9FNzKlTRcpTM09TNTNU1qXNTpTOUAEwy4KcslsVLXJyazw fQU5UacFlrDUhaUE8ATyWplVcjQMQATNPUjXVWNUyxA9q1nbJTLYJZN0ptI9M4SgGTBa3RdLcAdA BEodaL89Y33uWkWv/XElOrEGTfSl1GVlANCKVFgJTAPzNIAEvD1o5NFjbVc4zYm9jOVRcZN9lafW HK13kVvUVoM3XfMxgATMttnSxVnkrQ9SRKnjVWSUkwlVLTmFrR40xnOMWzwBsxzABNwONhBVWJyw Adtj4H8k7y836IAAVqwzpy+IbrwO7yHOAEAERn5SnjlaW9aFvuRwrOUXzSQhFok1y6wOdlIRVJbx HFEqwARfYrYdxVljF+yzQEyer/nt4iZcGb679C0JQ0pWwOiZJSOABNZ50JE1Ugo4AbZTJZTZKe2C wbw2OgMMDp5N0uEjU0TVLQAE3y6k48nCXOQ8UodoMM/tztl2FYKztLuOLUbuhPa6Ba4PgASPDiQa PLmi+FOtR/UWxrXtV3q/hDgLc3RvSgxwPIZfaj0ABNV+Ohu1WkP3j7FCsGCOrAw3UF2ToYOqv2eT De4CyzUsDIADzOIGF60itMt6VKx+fiNcUAAAAAAAAAAAAAAAAAAAAAAAAAPXXrIXKYGxuBgUyubx W/5gAAAAAAAAAAAAAAAAAAAAAAAAA9pe4N2rkslZgdGr5PEgu2AAAAAAAAAAAAAAAAAAAAAAAAAD 2m5inbUpyDBKVSvCfzygYAAAAAAAAAAAAAAAAAAAAAAAAAOablIZs0sRYTFbq27yW/dAAAAAAAAA AAAAAAAAAAAAAAAAAcBXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADrV6TGK/V1vpg 2AtEXCp0UAAAAAAAAAAAAAAAAAAAAAAAAAPJfZMTuxnx4+nQzTpmI8pQAAAAAAAAAAAAAAAAAAAA AAAAAUJCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD1V5g3bcrzlF5lMpWxymKYAAA AAAAAAAAAAAAAAAAAAAAAAGoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZwBAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAHhlQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARhSAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABSIMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGH iQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZLCAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAB7fcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN5YjFBpJ18+1IU KtEQaMFgAAAAAAAAAAAAAAAAAAAAAAAABHJMh9qz96tvkLnZBd0zNzC0B07cUfWc4NuUU7JU6Y/u DcAErIzeLD7xVOPuu2cVPLUdbtmZ9Buw89PgOlWxyCc6D+8yQASejEYhRzg0R0fGzHBo9AQOE33T GDAL2qhwEI1URvg7LR7ABHCMZiG/Gvs4UjZtRezc2pEmxtUgPLPzx1iGj1I0zzwOB4AEzxAHES8h CxOoRGFByNXaKxcsbIO3A9QGtEMNdGTYKEoRAAS2UAVKt5Vbcj06KUQ+9rlqkgzYzrDz63ENS8vb xQY/rzMABOY68+S3ZWR96LEWrebd9hIjStS6xdzcQZ4ZsVIi/Eh0H4AE8ipxSL1ZMrl6R07+TQUF tUCZ1SSu6yw8MlfsADkJW60GgARkoXBBO/lDV+Qqa0Q6+/zUgzxpk7Pbo8Alou2WisE3zxkABL4Z xkQ9eHrelLJS6BUVyI6BknqeNFuDliCU7YLqrS5sI0AEjlpmoTP403jIsuBAWvD4iuRK8qWzcgrS pxnM/gDmXO0TAASwOc5qNgrsFhM+doirHzrxAfHKAkLLusmKic124QaMMSWABJgdULG52vRSSU0w fNMnGDPl5dlFUwzsybgW8WQxRjczMsAE1C5qu0GqK5Y/Vm2I+TYVMFBZWZ5H7C0QusCRZD0IbfA9 gASTPtK6TZnD+wDXZOEtNiQRoeFZI9YEXJ6xFtFitQNe0j6ABJku2rpJmvSizEBN8ecWQ1EZ7diQ wxxE7rxDD2DfNip0HcAEjC4pNF16rMZWycq1j1UudMSLlyS3e0R06VKTXL7pN9M+wASYLpo/xWot bO845FD49R1vNudXplHTzEhDmk9ccP5kTA9ABEMCe7u3iKT9wUeiWCU+pA0kUBecInS7+ihMrV7K qFqtEUAEgkKF2UGCAvGdrg8kEPbdjcZU16S224PgdUJt3hqbFSwHwASVQnYWNXrjbUGs54VuteaI lX7XLK4CWvhuBer4yJhOSjZABKMYBOStcQpaoy/trViVyK4B6BeTmPoSwEUJK1zqW3BsCQAEqFiE 7iWSqeeeqwuyJN7tp6FOejQ2quJ7rF2LZiLCW+orQASqMvZnN3kiA+SuCim0weGuFiphcNVEdVF0 wg1HsydjURFABLoq5Qu9QPvGlDhioZb11YxGZHGUQUQavaeRj1Joy57QDsAEniaEaz1LuoG2M6h4 yrzwL6UmczXP9CPJpSazyv7oQq0AwASuKjanPzNL3Pw2ijH+1ekww4RVq7ebQ76Byc9YZsNScROA BL4iMiVFcYtJp0atSYS1+3EK5vaZRJTLVoUDS9y250KvIkAEjWjVUsgAk9iTL6EYJsTsScUMdJo5 UxxzcEBNWKqxLWsRAASXaDVnJTq6FWcii2YGtdzqJIJXQyjzq+CXzEnkTqY9aDIABMlCJ1O/EYra b63glYrPr8xiNNmVNsJqEgGSLP6Ik0IJNsADrX467q5AhOV/kEph8674UAAAAAAAAAAAAAAAAAAA AAAAAAPffrlBsWHInfvR6WIvYaRwAAAAAAAAAAAAAAAAAAAAAAAAAUiHAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEeKpUhTkqu4PMO7w5KPkcbJf1Tu9JtDxL8ckVPAc3P/QzQARwvGUp zTKt7pjNJkjZVSUVAJlUl0JlW9keSvFW2TcG8wcABNqc5+Y4ULwTpMFjfAk40tLinPwBoLozhkUg S+60smCuEgAE0pC0Fz1I+vU1LuVZJvXB7fN41qKxokNWDYZq/ii6kGgDgAS3PCZOLVFCqeAhwD3K 9bBNgiQ9si4DUx9xj4lU6rY6ax5ABJdiMxKYcLFyOLFlwtZ/4S/wnL4sMBu7LVLUKVhS+iHKBoAD 3mI1a6lq7CxRE6r2tFgUUAAAAAAAAAAAAAAAAAAAAAAAAAGcpQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABNq2uBkjWTmLuSi91AbM7Sz/smLzVHbVEm+HEqfdDlkuMoAEuh4uJMmRZLnY zwq9tSUC70b7EEfWTcSm3Mg2QB0gSxc8AATdHk5VSTvkMLjeJ0DW9k10VzNVGT4lpQskj/XM5uA7 9Q0ABMxSmL5VWm2EGVWHvIklXG8kqZYT39SV21+Us8yhUCPQKMAEyXwZ2U9K1JQUSolBZRUR0mYr lqlGQyzeS9Du1KL5t9ETgASsfI3sxWqEOErejAy3NSPRFU8WkEgM48q3TDFYTSw7sDAABJ5sLkFN aku/DL+rlO8F+OwHBlabsYzDhHfIj9Rk8SOvB4AE3yyvIb1xs7RgOIsttx0PLcbv1js6dCKMR8Gr WMypd44zAATOkGajPWHsYj88hfTGtaNNliDPtL4jSy0ph1HomNxlCgFABAGANxclWdtlFy/u2eq+ w0wFvtaBLnLyWR5Rh2jMrUEsMAAE0Oi1169Q4kA6oMfV5KbfTOVKWqiwS3ruH9Nq5kKgY8k1wATO XDTjr4mSgQ4vJ5z0vtMu9+g/uzPKe9RHgUtYrMQo7SaABJq+sEkz+JL6jx/I3bThzs2mBpalsEOb ZPTWMfMTDz3tGcAEfzhyjr1p/FSbxSuJoMbQU9XwFhU8FAR/OJsQaob8Fm81AAS7ftPoQyGkS1m7 5VWQ98ZOp4a8HkxL4zxnUU76bwROTgIABHCWpyHJytNJkrEdjD8eNXLV39Zx12RUgtQjd9GrEnVy LMAE6DKl4mFR1UiA16o0ruUr8kf5Vim9RKSSRUpuXFdKeBEfgATqIqciVYLU3hnHDglvFllwA33Y I7u79OiS27VgVQgSUj5ABOoiteDXkuvZsENIEOr+MzAii1k6yh10ZcDMcWKzLCNRGsAE6gKxSEei 3A3/Qqpk3R7ucGX62RO5k+N/pxyzZLbFSbEcQAToArIYNZvLV79AakmfFsmRAgDZpUAkm+BlG1Hu BsRbbymABPICsuhFouRsJT2uQq72AG+RX1qstwQ0PffRb2wBGgNPDgAE+CK0R7WyAzqCwecIhPbf 0bnk2yIs00OMv1nvanj1Ja80wARiPsxNPbo0FM0w6q269sRONDBcpC5si9tR3u9whKs7rzbABDI2 T2M10qwILb1IcVDXFfCBt94RRMzjLUkAjyRLAFkvF8AEwJ4l6b3adH5ZwISoPPfucBZg3ru4kwM/ Q9FteoMOXW8KAATAtsalPfLjVie5pxBTB69RAihfmDc7Ep4G0rIAtsZuTQvABNoWN23GAZP/UrSj nE7T181T7GMxPEtrCQiCzcQ291hrPQAEWqI068XRK0d5swTBVxYO0CEn2J8sQ0L5f56tfDC5Koww QAQUvjXbqahLP/CzDp0s9/JtshSykar6M4prz65UGPsn6wTABIZyNkG3MIP/ZqfTADyVt2ym7lIJ rLKixHJR6PrIlEXKMIAEC0IxFxNw2ugfsKb90KiRKDXCv64kqyMcYo4LPq61SqsYwASJftKSpPEh 66cywjmIjb7JQo73gi9SStKeRepm7oNqKhQABN0dNOsl+RozgzYOdV7ewKo2IHEZrHNSiioJKgqk uCNJG8AE0HilQb/Bmsm9sCIgEJzcprT8lAgz6uJxMBCpwjL0QmsVAATCbrdJJshijEYpT9G+oreN JJ4+lDcqK3ADhekMJL8NSzPABMMuxOkp+ZGnoBzkJczsrMti5soEqiqSg4yFaubw6B+oKcADmm63 RyfJ0CZyDQr6ARMLMAAAAAAAAAAAAAAAAAAAAAAAAAHo5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAYsTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABHMsAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHKFwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ASiDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUaoAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEm+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAROPAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB6A4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEUogAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcjCAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAB4tIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHKUwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfP7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAB7NIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNBQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAASECAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB CQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEbGwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQyiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlIUAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAhwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAATCnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABANcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAGEpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZC6AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB6IoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAATIe6ftu9paFUIyqsCma5fLwjyu9D4CFIXKdTbNOWG5+BgABLkthujYcX69KWMAmYtA THWxCwAOPryj5wOasgB3EwvtCQAEym44F6gAa22DMiMIENnGbiLigAswQ3uEXQlMmEyJTugjgATN DnTlN4iysU4aBf3qnqpOs6YMADCxcj5ZVqvkQpQkizdAA8l+h2MyKwiRLRCmlnMSujAAAAAAAAAA AAAAAAAAAAAAAAABYLsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGJgwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ7fAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABYKsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHbAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABIUb9U8vQ4t6ZiFemWbXOg+Nsbl73EWeZR/JNEbJTgi0DYAEmW6G6kgA c8D3SaPkswTybpLWAAczo8MIUckIBPjYRkwIwAAAArttb292AAAAbG12aGQAAAAAuppPwbqaT8EA AAJYAAAOEAABAAAA/wAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAEAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACR3RyYWsAAABcdGtoZAAAAA+6mk/BuppP wQAAAAEAAAAAAAAOEAAAAAAAAAAAAAAAAAEAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAA AAAAAEAAAAAAAAAAAAAAAAAAACRlZHRzAAAAHGVsc3QAAAAAAAAAAQAADhAAAAAAAAEAAAAAAb9t ZGlhAAAAIG1kaGQAAAAAuppPwbqaT8EAAB9AAAC7gAAAAAAAAAA6aGRscgAAAABtaGxyc291bmFw cGwAAAAAAAEAHhlBcHBsZSBTb3VuZCBNZWRpYSBIYW5kbGVyAAABXW1pbmYAAAAQc21oZAAAAAAA AAAAAAAAOWhkbHIAAAAAZGhscmFsaXNhcHBsAAAAAQABACYYQXBwbGUgQWxpYXMgRGF0YSBIYW5k bGVyAAAAJGRpbmYAAAAcZHJlZgAAAAAAAAABAAAADGFsaXMAAAABAAAA6HN0YmwAAAB0c3RzZAAA AAAAAAABAAAAZFFjbHAAAAAAAAAAAQABAAAAAAAAAAEAEAAAAAAfQAAAAAAAoAAAACMAAAAjAAAA AgAAADR3YXZlAAAADGZybWFRY2xwAAAAFFFjbHAAAAAMUWNsZgAAAAAAAAAIAAAAAAAAABhzdHRz AAAAAAAAAAEAALuAAAAAAQAAAChzdHNjAAAAAAAAAAIAAAABAACgAAAAAAEAAAACAAAbgAAAAAEA AAAUc3RzegAAAAAAAAABAAC7gAAAABhzdGNvAAAAAAAAAAIAAAAQAAAjEA== --=====================_172821323==_-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 17 00:20:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20585 for ; Mon, 17 Mar 2003 00:20:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H5aEm22575 for avt-archive@odin.ietf.org; Mon, 17 Mar 2003 00:36:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5ZgO22470; Mon, 17 Mar 2003 00:35:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H1VJO07377 for ; Sun, 16 Mar 2003 20:31:19 -0500 Received: from odin.nextreaming.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14723 for ; Sun, 16 Mar 2003 20:14:36 -0500 (EST) Received: from Orchid (h24-80-20-86.vc.shawcable.net [24.80.20.86]) by odin.nextreaming.com (8.11.0/8.11.0) with ESMTP id h2H17ej08708; Mon, 17 Mar 2003 10:07:41 +0900 Message-ID: <005a01c2ec22$b108eab0$030aa8c0@nextreaming.com> From: "Jae-Yong Lee" To: "Adam Li" , "'Ietf-Avt'" , "Randall Gellens" Cc: , "'Scott Bradner'" , "'Colin Perkins'" , "'Allison Mankin'" , , , , , , , , , , , , , , , , , , , , , , , , , References: <001301c2eb7b$b0cc77d0$6c7ba8c0@divxnetworks.com> Subject: Re: [AVT] Re: Issues for the file format for EVRC/SMV vocoder Date: Mon, 17 Mar 2003 10:14:58 +0900 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Hello all, My comments are inlined. > At 9:18 PM -0800 3/15/03, Adam Li wrote: > > > The topic of the file format for EVRC/SMV vocoders hopefully will be > > discussed in this meeting at San Francisco. > > We may be able to resolve this before the meeting, in email. If not, > then I think it may be discussed at the AVT meeting. > > > Technically differences. > > While the formats do have some differences, the main difference is > that the qcp format is currently used on different hardware and > software to interoperably store codec frames. It doesn't appear to > me that there is any difference in efficiency. > The difference that I see is that the storage format described in draft-ietf-avt-evrc-smv is simple, straightforward and easy to generate from the RTP payloads and vice versa while draft-garudadri-qcp is rather a much more complicated scheme. This would become one of the most important factor if we take mobile devices into account. What would be the technical advantage of draft-garudadri-qcp for storage of EVRC over the current draft-ietf-avt-evrc-smv? > > > For EVRC codec data, formats defined in both document > > can handle it. For SMV codec data, the format defined in > > draft-ietf-avt-evrc-smv is currently the only file format that handles > > SMV data. draft-garudadri-qcp does not handle SMV at this time. > > SMV is being added to the qcp format; it's just a trivial matter of > adding a new identifier. > Would it be necessary if we have draft-ietf-avt-evrc-smv? Would it not be possible to extend RFC 2658 to include its storage format and make it similar to draft-ietf-avt-evrc-smv? > > Maturity of the format definition. > > The format defined in draft-ietf-avt-evrc-smv was specified primarily > for completeness of the document. At the time we were working on > this draft, I and the other authors were unaware of the qcp file > format. (I'm very sorry for this.) It turns out that the qcp format > has been widely used on multiple platforms for some time, including > Eudora email and Quicktime media player (both on both Mac and > Windows), and millions of CDMA handsets I'm not aware of any current > interoperable independent implementations of the format specified in > draft-ietf-avt-evrc-smv. > To the best of my knowledge, Quicktime does not support .qcp file format although it does support QCELP codec in QT file format. I have some comments below (under the next point) regarding interoperable independent implementations of the format in draft-ietf-avt-evrc-smv. > > Which of the formats, as > > defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has been > > considered by 3GPP2 for the format for storing EVRC and SMV data? > > The issue of which format to specify in 3GPP2 is currently being > discussed. Most of the discussions to date have been on how to > include evrc, smv, and qcelp-13k in an iso-based mp4 file format. > The issue of specifying an independent file format for vocoders in > 3GPP2 is new. > The 3GPP2's goal with multimedia file format is to have a single common file format for various applications as stated in its Stage-1 (requirements) document. People in 3GPP2 have agreed to have it based on the ISO base media file format which was already adopted for many other international standards, e.g., 3GPP, MPEG, JPEG. Also the FFMS (file format for multimedia services) baseline text is refering to draft-ietf-avt-evrc-smv for storing EVRC and SMV data in the media track. Many (defintely more than two) handset vendors and solution providers have already implemented this and tested interoperability and operators are preparing services based on that. If wanted, the media data would be easily taken and converted into the format specified in draft-ietf-avt-evrc-smv simply by adding the magic numbers. I believe this sort of simple conversion would be really useful if speech-only formats are also considered for some applications or services. > > would there be enough reasons to trade-off for the additional complexity > > for having the MIME registration of EVRC/SMV refering to a separate and > > yet to be complete draft? > > This is very minor. However, if the qcp format were something new, > and not currently deployed, I'd be the first to say that we should > stick with the format in draft-ietf-avt-evrc-smv. It's only because > of the existing interoperable use of the qcp format that I agree with > making it the file format for the registrations. > > > Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If we > > want to consider deleting the file format that is in the draft for > > almost two years in the last minute before it becomes an RFC and using > > another yet to be complete new draft instead, we should be providing > > ourselves with the clear justification for doing so. > > I completely agree with you. I have zero desire to delay > draft-ietf-avt-evrc-smv. In fact, my initial suggestion, as written > in the qcp draft, was to take the easier path of not changing > draft-ietf-avt-evrc-smv at all, and instead to have the qcp draft > register a new MIME type (audio/qcp) which can be used to store evrc, > qcelp (and SMV). I knew this was a kludge (since the qcp format is > already in use) but wanted to do what was quickest and easiest. > > However, I was clearly told that this was not acceptable -- that we > should do what is technically correct: allow draft-ietf-avt-evrc-smv > to progress but without the file format, and change the qcp draft to > modify the MIME registrations. I agree that this is the correct way > to proceed. > I'm not sure what is the technically correct way. What is the technical benefit of draft-garudadri-qcp? Above all, it would be very much undesirable to make a significant change at the very last minute without sufficient justification. > > -- > Randall Gellens Regards, Jay _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 17 00:20:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20590 for ; Mon, 17 Mar 2003 00:20:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H5aFs22588 for avt-archive@odin.ietf.org; Mon, 17 Mar 2003 00:36:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5ZVO22420; Mon, 17 Mar 2003 00:35:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GM9GO29182 for ; Sun, 16 Mar 2003 17:09:16 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09441 for ; Sun, 16 Mar 2003 16:52:40 -0500 (EST) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2GLrdc06818; Sun, 16 Mar 2003 16:53:39 -0500 (EST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h2GLq7B26090; Sun, 16 Mar 2003 15:52:14 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HBV3ET-0000P0-00; Sun, 16 Mar 2003 16:52:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15988.61955.624612.309236@gargle.gargle.HOWL> Date: Sun, 16 Mar 2003 15:52:03 -0600 From: Pete McCann To: Randall Gellens Cc: "Lars-Erik Jonsson (EAB)" , Adam Li , Ietf-Avt , , "'Scott Bradner'" , "'Colin Perkins'" , "'Allison Mankin'" , , , , , , , , , , , , , , , , , , , , , , Subject: RE: [AVT] File format for EVRC/SMV vocoder In-Reply-To: References: X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid 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, Randy, Are there any intellectual property issues with the qcp format? Also, were the interoperable implementations of the qcp format really done independently? My understanding is that Eudora is a Qualcomm product and that Apple acted merely as an integrator and distributer of the PureVoice technology from Qualcomm. If these implementations are not independent it may be misleading for you to talk about interoperability. -Pete Randall Gellens writes: > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote: > > > OK, but why has not this issue been brought up earlier? > > Because of an unfortunate oversight. Neither myself nor the other > authors of the evrc/smv draft were aware of the qcp format. I very > much regret this. At the time we were working on the evrc/smv draft, > we specified a file format to make the draft complete. Had we been > aware of an existing format that was currently being used to > interoperably exchange vocoder frames, I'm sure it would have been > considered instead of inventing something new. > > > The EVRC/SMV > > format work in AVT has been going on for a long time, and therefore one > > can question whether it is correct (from a procedural point of view) to > > suddenly not use what has been developed in this WG, but use something > > defined elsewhere. IETF standardization is usually an engineering > > process, not rubber-stamping of already deployed technical solutions. > > When I learned of the qcp format, my suggestion for how to proceed > was to register a new mime type (audio/qcp) so as to not risk > delaying the evrc draft. (As one of the authors of that draft, I > have no desire to delay it at all.) This is what the current qcp > draft says. However, I was told to do the technically correct thing > instead. > > > Note that I am not aware of all the details in this matter, but what > > has been communicated on the list does not provide enough material for > > motivating what has been proposed. "We have already deployed this > > alternative format while you were trying to agree on a standard, and > > now we think you should use our format instead since it is more > > widely deployed" is a rather strange way of arguing in standards > > development, I think. > > The QCP format was in deployment when we started working on the > evrc/smv draft, but neither I not the other authors were aware of > this. It's not the case that the qcp format was deployed afterwards > or in parallel, in an attempt to circumvent process. > > The question now is how best to proceed. As I said, my initial > suggestion was to take the easy path of not deleting the file format > from the evrc/smv draft, and instead to use a kludge of registering a > new mime type for the qcp file format. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 17 00:20:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20613 for ; Mon, 17 Mar 2003 00:20:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H5aGV22601 for avt-archive@odin.ietf.org; Mon, 17 Mar 2003 00:36:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5ZdO22437; Mon, 17 Mar 2003 00:35:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNIkO32658 for ; Sun, 16 Mar 2003 18:18:46 -0500 Received: from mail.nextreaming.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11234 for ; Sun, 16 Mar 2003 18:02:08 -0500 (EST) Subject: RE: [AVT] File format for EVRC/SMV vocoder Date: Mon, 17 Mar 2003 08:04:22 +0900 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="ks_c_5601-1987" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [AVT] File format for EVRC/SMV vocoder Thread-Index: AcLsBtLZebgEzm3pSHys6PBoLfyTJwACPczA From: "Jae-Yong Lee" To: "Pete McCann" , "Randall Gellens" Cc: "Lars-Erik Jonsson (EAB)" , "Adam Li" , "Ietf-Avt" , , "Scott Bradner" , "Colin Perkins" , "Allison Mankin" , , , , , , , , , , , , , , , , , , , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2GNIkO32659 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 Hi all, To my best knowledge, QT is supporting QCELP "codec" (in QT file format), not the .qcp file format. Jay > > Hi, Randy, > > Are there any intellectual property issues with the qcp format? > > Also, were the interoperable implementations of the qcp format really > done independently? My understanding is that Eudora is a Qualcomm > product and that Apple acted merely as an integrator and distributer > of the PureVoice technology from Qualcomm. If these implementations > are not independent it may be misleading for you to talk about > interoperability. > > -Pete > > > Randall Gellens writes: > > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote: > > > > > OK, but why has not this issue been brought up earlier? > > > > Because of an unfortunate oversight. Neither myself nor the other > > authors of the evrc/smv draft were aware of the qcp > format. I very > > much regret this. At the time we were working on the > evrc/smv draft, > > we specified a file format to make the draft complete. > Had we been > > aware of an existing format that was currently being used to > > interoperably exchange vocoder frames, I'm sure it would have been > > considered instead of inventing something new. > > > > > The EVRC/SMV > > > format work in AVT has been going on for a long time, > and therefore one > > > can question whether it is correct (from a procedural > point of view) to > > > suddenly not use what has been developed in this WG, > but use something > > > defined elsewhere. IETF standardization is usually an > engineering > > > process, not rubber-stamping of already deployed > technical solutions. > > > > When I learned of the qcp format, my suggestion for how to proceed > > was to register a new mime type (audio/qcp) so as to not risk > > delaying the evrc draft. (As one of the authors of that draft, I > > have no desire to delay it at all.) This is what the current qcp > > draft says. However, I was told to do the technically > correct thing > > instead. > > > > > Note that I am not aware of all the details in this > matter, but what > > > has been communicated on the list does not provide > enough material for > > > motivating what has been proposed. "We have already > deployed this > > > alternative format while you were trying to agree on a > standard, and > > > now we think you should use our format instead since it is more > > > widely deployed" is a rather strange way of arguing in standards > > > development, I think. > > > > The QCP format was in deployment when we started working on the > > evrc/smv draft, but neither I not the other authors were aware of > > this. It's not the case that the qcp format was deployed > afterwards > > or in parallel, in an attempt to circumvent process. > > > > The question now is how best to proceed. As I said, my initial > > suggestion was to take the easy path of not deleting the > file format > > from the evrc/smv draft, and instead to use a kludge of > registering a > > new mime type for the qcp file format. > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 17 00:21:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20638 for ; Mon, 17 Mar 2003 00:21:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H5bMH23184 for avt-archive@odin.ietf.org; Mon, 17 Mar 2003 00:37:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5ZhO22485; Mon, 17 Mar 2003 00:35:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H29pO10133 for ; Sun, 16 Mar 2003 21:09:51 -0500 Received: from mail.nextreaming.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15654 for ; Sun, 16 Mar 2003 20:53:08 -0500 (EST) Subject: RE: [AVT] File format for EVRC/SMV vocoder Date: Mon, 17 Mar 2003 10:55:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC28.413B0D52" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [AVT] File format for EVRC/SMV vocoder Thread-Index: AcLsGxYo0W/iFtcuSZeilHaHP2LTUQACOY/Q From: "Jae-Yong Lee" To: "Harinath Garudadri" , "Pete McCann" , "Randall Gellens" Cc: "Lars-Erik Jonsson (EAB)" , "Adam Li" , "Ietf-Avt" , , "Scott Bradner" , "Colin Perkins" , "Allison Mankin" , , , , , , , , , , , , , , , , , , , , 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_01C2EC28.413B0D52 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Hari and all, =20 Well there is a sort of plug-in for Quicktime for that. But I'm not sure if we can count this in since, with plug-in, virtually = everything is possible. Maybe someone from Apple can clarify hopefully. =20 Jay =20 -----Original Message----- From: Harinath Garudadri [mailto:hgarudad@qualcomm.com] Sent: Monday, March 17, 2003 9:12 AM To: Jae-Yong Lee; Pete McCann; Randall Gellens Cc: Lars-Erik Jonsson (EAB); Adam Li; Ietf-Avt; casner@acm.org; Scott = Bradner; Colin Perkins; Allison Mankin; mdturner@lucent.com; = smathai@lucent.com; lioy@qualcomm.com; zeng@packetvideo.com; = sherwood@packetvideo.com; villa@icsl.ucla.edu; yllee@samsung.com; = jeonghoon@samsung.com; tom.hiller@lucent.com; David.Leon@nokia.com; = nleung@qualcomm.com; dgal@lucent.com; ajayrajkumar@lucent.com; = magnus.westerlund@era-t.ericsson.se; vbharga@cisco.com; = craig.greer@nokia.com; magda@qualcomm.com; ned.freed@mrochek.com; = hgarudad@qualcomm.com; csp@isi.edu; sakazawa@kddilabs.jp Subject: RE: [AVT] File format for EVRC/SMV vocoder At 08:04 AM 3/17/2003 +0900, Jae-Yong Lee wrote: Hi all, To my best knowledge, QT is supporting QCELP "codec"=20 (in QT file format), not the .qcp file format. I was able to create a qcp file in my Eudora client and send to someone = who uses a different email client. When he launched Quicktime for this = file, he was able to play the file as is and also convert the file to = .mov format. Here is the .mov version of the file for those who have = Quicktime. Jay >=20 > Hi, Randy, >=20 > Are there any intellectual property issues with the qcp format? >=20 > Also, were the interoperable implementations of the qcp format really > done independently? My understanding is that Eudora is a Qualcomm > product and that Apple acted merely as an integrator and distributer > of the PureVoice technology from Qualcomm. If these implementations > are not independent it may be misleading for you to talk about > interoperability. >=20 > -Pete >=20 >=20 > Randall Gellens writes: > > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote: > >=20 > > > OK, but why has not this issue been brought up earlier? > >=20 > > Because of an unfortunate oversight. Neither myself nor the other=20 > > authors of the evrc/smv draft were aware of the qcp=20 > format. I very=20 > > much regret this. At the time we were working on the=20 > evrc/smv draft,=20 > > we specified a file format to make the draft complete. =20 > Had we been=20 > > aware of an existing format that was currently being used to=20 > > interoperably exchange vocoder frames, I'm sure it would have been=20 > > considered instead of inventing something new. > >=20 > > > The EVRC/SMV > > > format work in AVT has been going on for a long time,=20 > and therefore one > > > can question whether it is correct (from a procedural=20 > point of view) to > > > suddenly not use what has been developed in this WG,=20 > but use something > > > defined elsewhere. IETF standardization is usually an=20 > engineering > > > process, not rubber-stamping of already deployed=20 > technical solutions. > >=20 > > When I learned of the qcp format, my suggestion for how to proceed=20 > > was to register a new mime type (audio/qcp) so as to not risk=20 > > delaying the evrc draft. (As one of the authors of that draft, I=20 > > have no desire to delay it at all.) This is what the current qcp=20 > > draft says. However, I was told to do the technically=20 > correct thing=20 > > instead. > >=20 > > > Note that I am not aware of all the details in this=20 > matter, but what > > > has been communicated on the list does not provide=20 > enough material for > > > motivating what has been proposed. "We have already=20 > deployed this > > > alternative format while you were trying to agree on a=20 > standard, and > > > now we think you should use our format instead since it is more > > > widely deployed" is a rather strange way of arguing in standards > > > development, I think. > >=20 > > The QCP format was in deployment when we started working on the=20 > > evrc/smv draft, but neither I not the other authors were aware of=20 > > this. It's not the case that the qcp format was deployed=20 > afterwards=20 > > or in parallel, in an attempt to circumvent process. > >=20 > > The question now is how best to proceed. As I said, my initial=20 > > suggestion was to take the easy path of not deleting the=20 > file format=20 > > from the evrc/smv draft, and instead to use a kludge of=20 > registering a=20 > > new mime type for the qcp file format. >=20 >=20 Hari Garudadri (from Vancouver, B.C.) mobile : 858-229-2801 ------_=_NextPart_001_01C2EC28.413B0D52 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello=20 Hari and all,
 
Well=20 there is a sort of plug-in for Quicktime for = that.
But=20 I'm not sure if we can count this in since, with plug-in, virtually = everything=20 is possible.
Maybe=20 someone from Apple can clarify hopefully.
 
Jay
 
-----Original Message-----
From: Harinath Garudadri = [mailto:hgarudad@qualcomm.com]
Sent: Monday, March 17, 2003 = 9:12=20 AM
To: Jae-Yong Lee; Pete McCann; Randall = Gellens
Cc:=20 Lars-Erik Jonsson (EAB); Adam Li; Ietf-Avt; casner@acm.org; Scott = Bradner;=20 Colin Perkins; Allison Mankin; mdturner@lucent.com; = smathai@lucent.com;=20 lioy@qualcomm.com; zeng@packetvideo.com; sherwood@packetvideo.com;=20 villa@icsl.ucla.edu; yllee@samsung.com; jeonghoon@samsung.com;=20 tom.hiller@lucent.com; David.Leon@nokia.com; nleung@qualcomm.com;=20 dgal@lucent.com; ajayrajkumar@lucent.com; = magnus.westerlund@era-t.ericsson.se;=20 vbharga@cisco.com; craig.greer@nokia.com; magda@qualcomm.com;=20 ned.freed@mrochek.com; hgarudad@qualcomm.com; csp@isi.edu;=20 sakazawa@kddilabs.jp
Subject: RE: [AVT] File format for = EVRC/SMV=20 vocoder

At 08:04 AM = 3/17/2003=20 +0900, Jae-Yong Lee wrote:
Hi=20 all,

To my best knowledge, QT is supporting QCELP "codec" =
(in QT=20 file format), not the .qcp file format.

I was able to create a qcp file in my Eudora = client and send=20 to someone who uses a different email client. When he launched = Quicktime for=20 this file, he was able to play the file as is and also convert the = file to=20 .mov format. Here is the .mov version of the file for those who have=20 Quicktime.
Jay

>
> Hi, Randy,
>
> Are = there any=20 intellectual property issues with the qcp format?
>
> = Also,=20 were the interoperable implementations of the qcp format = really
> done=20 independently?  My understanding is that Eudora is a = Qualcomm
>=20 product and that Apple acted merely as an integrator and = distributer
>=20 of the PureVoice technology from Qualcomm.  If these=20 implementations
> are not independent it may be misleading for = you to=20 talk about
> interoperability.
>
> -Pete
> =
>=20
> Randall Gellens writes:
>  > At 1:52 PM +0100 = 3/11/03, Lars-Erik Jonsson (EAB) wrote:
>  > =
> =20 > >  OK, but why has not this issue been brought up=20 earlier?
>  >
>  > Because of an = unfortunate=20 oversight.  Neither myself nor the other
>  > = authors of=20 the evrc/smv draft were aware of the qcp
> format.  I = very=20
>  > much regret this.  At the time we were = working on=20 the
> evrc/smv draft,
>  > we specified a file = format=20 to make the draft complete. 
> Had we been =
>  >=20 aware of an existing format that was currently being used to =
> =20 > interoperably exchange vocoder frames, I'm sure it would have = been=20
>  > considered instead of inventing something=20 new.
>  >
>  > >   The=20 EVRC/SMV
>  > >  format work in AVT has been = going on=20 for a long time,
> and therefore one
>  > = > =20 can question whether it is correct (from a procedural
> point = of=20 view) to
>  > >  suddenly not use what has = been=20 developed in this WG,
> but use something
>  >=20 >  defined elsewhere. IETF standardization is usually an =
>=20 engineering
>  > >  process, not = rubber-stamping of=20 already deployed
> technical solutions.
>  >=20
>  > When I learned of the qcp format, my suggestion = for how=20 to proceed
>  > was to register a new mime type = (audio/qcp)=20 so as to not risk
>  > delaying the evrc draft.  = (As one=20 of the authors of that draft, I
>  > have no desire = to delay=20 it at all.)  This is what the current qcp
>  > = draft=20 says.  However, I was told to do the technically
> = correct thing=20
>  > instead.
>  >
>  >=20 >  Note that I am not aware of all the details in this =
>=20 matter, but what
>  > >  has been communicated = on the=20 list does not provide
> enough material for
>  = >=20 >  motivating what has been proposed. "We have already =
>=20 deployed this
>  > >  alternative format while = you=20 were trying to agree on a
> standard, and
>  >=20 >  now we think you should use our format instead since it = is=20 more
>  > >  widely deployed" is a rather = strange way=20 of arguing in standards
>  > >  development, I = think.
>  >
>  > The QCP format was in=20 deployment when we started working on the
>  > = evrc/smv=20 draft, but neither I not the other authors were aware of =
>  >=20 this.  It's not the case that the qcp format was deployed =
>=20 afterwards
>  > or in parallel, in an attempt to = circumvent=20 process.
>  >
>  > The question now is = how best=20 to proceed.  As I said, my initial
>  > = suggestion was=20 to take the easy path of not deleting the
> file format=20
>  > from the evrc/smv draft, and instead to use a = kludge of=20
> registering a
>  > new mime type for the qcp = file=20 format.
>
>

Hari Garudadri (from = Vancouver,=20 B.C.)
mobile : = 858-229-2801

------_=_NextPart_001_01C2EC28.413B0D52-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 17 01:11:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20562 for ; Mon, 17 Mar 2003 00:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H5a6n22550 for avt-archive@odin.ietf.org; Mon, 17 Mar 2003 00:36:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5ZjO22500; Mon, 17 Mar 2003 00:35:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H5NmO21985 for ; Mon, 17 Mar 2003 00:23:48 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20074 for ; Mon, 17 Mar 2003 00:07:03 -0500 (EST) Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.3) with ESMTP id h2H55s65074589; Sun, 16 Mar 2003 21:05:55 -0800 (PST) (envelope-from casner@acm.org) Date: Sun, 16 Mar 2003 21:11:11 -0800 (PST) From: Stephen Casner To: Randall Gellens cc: "Lars-Erik Jonsson (EAB)" , Adam Li , Ietf-Avt , "'Scott Bradner'" , "'Colin Perkins'" , "'Allison Mankin'" , , , , , , , , , , , , , , , , , , , , , , , Subject: RE: [AVT] File format for EVRC/SMV vocoder In-Reply-To: Message-ID: <20030316204933.D96234-100000@oak.packetdesign.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 Sun, 16 Mar 2003, Randall Gellens wrote: > When I learned of the qcp format, my suggestion for how to proceed > was to register a new mime type (audio/qcp) so as to not risk > delaying the evrc draft. (As one of the authors of that draft, I > have no desire to delay it at all.) This is what the current qcp > draft says. However, I was told to do the technically correct thing > instead. My guidance to you on this was in two parts: 1. I don't think it makes sense he have audio/qcp as a type that does not say what encoding is inside the qcp format file. That led to my suggestion to use the existing audio/qcelp and audio/evrc types. When I wrote that, I was forgetting that there already was a file format associated with audio/evrc. 2. It sounded to me as if there was substantial following for qcp file format as the container for EVRC, and that the format in the evrc-smv draft was created only because the authors were unaware of the qcp format. If the second point accurately reflected the situation, then it would not be technically correct to proceed with publishing the file format in the evrc-smv draft, and it would be fortunate that we discovered this before publication. However, we are now hearing significant objection to the idea of deleting the file format in the evrc-smv draft on a variety of points. There can be two formats, but all of you, on both sides of the question, are going to suffer pain in the future if there are two formats rather than one. You know its true. So, the process here is to honestly assess the demand for the two formats, without ego as to who wrote what. If there are IPR claims for one or the other, then that factors into the decision. If it is a question of market penetration, and competitors have chosen sides, then we may be forced into the position of specifying both (or neither). My first point above can be satisfied while still defining both formats by associating the file format with audio/qcelp (where, as I understand it, there is no conflict) and audio/evrc-qcp. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 17 14:09:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25400 for ; Mon, 17 Mar 2003 14:09:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HJPbg26443 for avt-archive@odin.ietf.org; Mon, 17 Mar 2003 14:25:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJOoO26359; Mon, 17 Mar 2003 14:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJGNO25920 for ; Mon, 17 Mar 2003 14:16:23 -0500 Received: from mail-out2.apple.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24999 for ; Mon, 17 Mar 2003 13:59:19 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2HJ1VsJ011635 for ; Mon, 17 Mar 2003 11:01:31 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 17 Mar 2003 11:01:16 -0800 Received: from [203.209.47.65] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id h2HJ1I614410; Mon, 17 Mar 2003 11:01:19 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 17 Mar 2003 11:00:27 -0800 To: Jae-Yong Lee , Harinath Garudadri , Pete McCann , Randall Gellens From: Dave Singer Subject: RE: [AVT] File format for EVRC/SMV vocoder Cc: "Lars-Erik Jonsson (EAB)" , Adam Li , Ietf-Avt , casner@acm.org, Scott Bradner , Colin Perkins , Allison Mankin , mdturner@lucent.com, smathai@lucent.com, lioy@qualcomm.com, zeng@packetvideo.com, sherwood@packetvideo.com, villa@icsl.ucla.edu, yllee@samsung.com, jeonghoon@samsung.com, tom.hiller@lucent.com, David.Leon@nokia.com, nleung@qualcomm.com, dgal@lucent.com, ajayrajkumar@lucent.com, magnus.westerlund@era-t.ericsson.se, vbharga@cisco.com, craig.greer@nokia.com, magda@qualcomm.com, ned.freed@mrochek.com, csp@isi.edu, sakazawa@kddilabs.jp Content-Type: multipart/alternative; boundary="============_-1164194718==_ma============" 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: , --============_-1164194718==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:55 +0900 3/17/03, Jae-Yong Lee wrote: >Hello Hari and all, > >Well there is a sort of plug-in for Quicktime for that. >But I'm not sure if we can count this in since, with plug-in, >virtually everything is possible. >Maybe someone from Apple can clarify hopefully. This FAQ seems to say that we ship a QCP importer. I couldn't remember, and can't find a QCP file. > >Jay > > >-----Original Message----- >From: Harinath Garudadri [mailto:hgarudad@qualcomm.com] >Sent: Monday, March 17, 2003 9:12 AM >To: Jae-Yong Lee; Pete McCann; Randall Gellens >Cc: Lars-Erik Jonsson (EAB); Adam Li; Ietf-Avt; casner@acm.org; >Scott Bradner; Colin Perkins; Allison Mankin; mdturner@lucent.com; >smathai@lucent.com; lioy@qualcomm.com; zeng@packetvideo.com; >sherwood@packetvideo.com; villa@icsl.ucla.edu; yllee@samsung.com; >jeonghoon@samsung.com; tom.hiller@lucent.com; David.Leon@nokia.com; >nleung@qualcomm.com; dgal@lucent.com; ajayrajkumar@lucent.com; >magnus.westerlund@era-t.ericsson.se; vbharga@cisco.com; >craig.greer@nokia.com; magda@qualcomm.com; ned.freed@mrochek.com; >hgarudad@qualcomm.com; csp@isi.edu; sakazawa@kddilabs.jp >Subject: RE: [AVT] File format for EVRC/SMV vocoder > >At 08:04 AM 3/17/2003 +0900, Jae-Yong Lee wrote: > >>Hi all, >> >>To my best knowledge, QT is supporting QCELP "codec" >>(in QT file format), not the .qcp file format. >> > >I was able to create a qcp file in my Eudora client and send to >someone who uses a different email client. When he launched >Quicktime for this file, he was able to play the file as is and also >convert the file to .mov format. Here is the .mov version of the >file for those who have Quicktime. > >>Jay >> > > > > Hi, Randy, > > > > Are there any intellectual property issues with the qcp format? > > > > Also, were the interoperable implementations of the qcp format really > > done independently? My understanding is that Eudora is a Qualcomm >> product and that Apple acted merely as an integrator and distributer >> of the PureVoice technology from Qualcomm. If these implementations >> are not independent it may be misleading for you to talk about >> interoperability. >> >> -Pete >> >> >> Randall Gellens writes: >> > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote: >> > >> > > OK, but why has not this issue been brought up earlier? >> > >> > Because of an unfortunate oversight. Neither myself nor the other >> > authors of the evrc/smv draft were aware of the qcp >> format. I very >> > much regret this. At the time we were working on the >> evrc/smv draft, >> > we specified a file format to make the draft complete. >> Had we been >> > aware of an existing format that was currently being used to >> > interoperably exchange vocoder frames, I'm sure it would have been >> > considered instead of inventing something new. >> > >> > > The EVRC/SMV >> > > format work in AVT has been going on for a long time, >> and therefore one >> > > can question whether it is correct (from a procedural >> point of view) to >> > > suddenly not use what has been developed in this WG, >> but use something >> > > defined elsewhere. IETF standardization is usually an >> engineering > > > > process, not rubber-stamping of already deployed >> technical solutions. >> > >> > When I learned of the qcp format, my suggestion for how to proceed >> > was to register a new mime type (audio/qcp) so as to not risk >> > delaying the evrc draft. (As one of the authors of that draft, I >> > have no desire to delay it at all.) This is what the current qcp >> > draft says. However, I was told to do the technically >> correct thing >> > instead. >> > >> > > Note that I am not aware of all the details in this >> matter, but what >> > > has been communicated on the list does not provide >> enough material for >> > > motivating what has been proposed. "We have already >> deployed this >> > > alternative format while you were trying to agree on a >> standard, and >> > > now we think you should use our format instead since it is more >> > > widely deployed" is a rather strange way of arguing in standards >> > > development, I think. >> > >> > The QCP format was in deployment when we started working on the >> > evrc/smv draft, but neither I not the other authors were aware of >> > this. It's not the case that the qcp format was deployed >> afterwards >> > or in parallel, in an attempt to circumvent process. >> > >> > The question now is how best to proceed. As I said, my initial >> > suggestion was to take the easy path of not deleting the >> file format >> > from the evrc/smv draft, and instead to use a kludge of >> registering a >> > new mime type for the qcp file format. >> >> > >Hari Garudadri (from Vancouver, B.C.) >mobile : 858-229-2801 -- David Singer Apple Computer/QuickTime --============_-1164194718==_ma============ Content-Type: text/html; charset="us-ascii" RE: [AVT] File format for EVRC/SMV vocoder
At 10:55 +0900 3/17/03, Jae-Yong Lee wrote:
Hello Hari and all,
 
Well there is a sort of plug-in for Quicktime for that.
But I'm not sure if we can count this in since, with plug-in, virtually everything is possible.
Maybe someone from Apple can clarify hopefully.

This FAQ seems to say that we ship a QCP importer.  I couldn't remember, and can't find a QCP file.

<http://www.cdmatech.com/solutions/products/purevoice_quicktime.html>

 
Jay
 
-----Original Message-----
From: Harinath Garudadri [mailto:hgarudad@qualcomm.com]
Sent: Monday, March 17, 2003 9:12 AM
To: Jae-Yong Lee; Pete McCann; Randall Gellens
Cc: Lars-Erik Jonsson (EAB); Adam Li; Ietf-Avt; casner@acm.org; Scott Bradner; Colin Perkins; Allison Mankin; mdturner@lucent.com; smathai@lucent.com; lioy@qualcomm.com; zeng@packetvideo.com; sherwood@packetvideo.com; villa@icsl.ucla.edu; yllee@samsung.com; jeonghoon@samsung.com; tom.hiller@lucent.com; David.Leon@nokia.com; nleung@qualcomm.com; dgal@lucent.com; ajayrajkumar@lucent.com; magnus.westerlund@era-t.ericsson.se; vbharga@cisco.com; craig.greer@nokia.com; magda@qualcomm.com; ned.freed@mrochek.com; hgarudad@qualcomm.com; csp@isi.edu; sakazawa@kddilabs.jp
Subject: RE: [AVT] File format for EVRC/SMV vocoder
At 08:04 AM 3/17/2003 +0900, Jae-Yong Lee wrote:
Hi all,

To my best knowledge, QT is supporting QCELP "codec"
(in QT file format), not the .qcp file format.

I was able to create a qcp file in my Eudora client and send to someone who uses a different email client. When he launched Quicktime for this file, he was able to play the file as is and also convert the file to .mov format. Here is the .mov version of the file for those who have Quicktime.
Jay
>
> Hi, Randy,
>
> Are there any intellectual property issues with the qcp format?
>
> Also, were the interoperable implementations of the qcp format really
> done independently?  My understanding is that Eudora is a Qualcomm
> product and that Apple acted merely as an integrator and distributer
> of the PureVoice technology from Qualcomm.  If these implementations
> are not independent it may be misleading for you to talk about
> interoperability.
>
> -Pete
>
>
> Randall Gellens writes:
>  > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote:
>  >
>  > >  OK, but why has not this issue been brought up earlier?
>  >
>  > Because of an unfortunate oversight.  Neither myself nor the other
>  > authors of the evrc/smv draft were aware of the qcp
> format.  I very
>  > much regret this.  At the time we were working on the
> evrc/smv draft,
>  > we specified a file format to make the draft complete. 
> Had we been
>  > aware of an existing format that was currently being used to
>  > interoperably exchange vocoder frames, I'm sure it would have been
>  > considered instead of inventing something new.
>  >
>  > >   The EVRC/SMV
>  > >  format work in AVT has been going on for a long time,
> and therefore one
>  > >  can question whether it is correct (from a procedural
> point of view) to
>  > >  suddenly not use what has been developed in this WG,
> but use something
>  > >  defined elsewhere. IETF standardization is usually an
> engineering
>  > >  process, not rubber-stamping of already deployed
> technical solutions.
>  >
>  > When I learned of the qcp format, my suggestion for how to proceed
>  > was to register a new mime type (audio/qcp) so as to not risk
>  > delaying the evrc draft.  (As one of the authors of that draft, I
>  > have no desire to delay it at all.)  This is what the current qcp
>  > draft says.  However, I was told to do the technically
> correct thing
>  > instead.
>  >
>  > >  Note that I am not aware of all the details in this
> matter, but what
>  > >  has been communicated on the list does not provide
> enough material for
>  > >  motivating what has been proposed. "We have already
> deployed this
>  > >  alternative format while you were trying to agree on a
> standard, and
>  > >  now we think you should use our format instead since it is more
>  > >  widely deployed" is a rather strange way of arguing in standards
>  > >  development, I think.
>  >
>  > The QCP format was in deployment when we started working on the
>  > evrc/smv draft, but neither I not the other authors were aware of
>  > this.  It's not the case that the qcp format was deployed
> afterwards
>  > or in parallel, in an attempt to circumvent process.
>  >
>  > The question now is how best to proceed.  As I said, my initial
>  > suggestion was to take the easy path of not deleting the
> file format
>  > from the evrc/smv draft, and instead to use a kludge of
> registering a
>  > new mime type for the qcp file format.
>
>
Hari Garudadri (from Vancouver, B.C.)
mobile : 858-229-2801


--
David Singer
Apple Computer/QuickTime
--============_-1164194718==_ma============-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 19 04:55:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17335 for ; Wed, 19 Mar 2003 04:55:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JACKW16411 for avt-archive@odin.ietf.org; Wed, 19 Mar 2003 05:12:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JA8kO16279; Wed, 19 Mar 2003 05:08:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JA4uO15415 for ; Wed, 19 Mar 2003 05:04:56 -0500 Received: from backexch.zh.corp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17239 for ; Wed, 19 Mar 2003 04:47:06 -0500 (EST) Received: by backexch.zh.corp with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 11:51:43 +0200 Message-ID: From: =?iso-8859-9?Q?N=FCkhet_=D6zbek_=28Dijital_Arge=29?= To: "'avt@ietf.org'" Date: Wed, 19 Mar 2003 11:54:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2JA4uO15416 Subject: [AVT] Hello 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 Hi, I am anew subscriber of the list. And I have a question about H26.L and H.324 framework. What is H.324 framework? And what is the relation with H26.L? Thanks & Regards, Nükhet. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 19 14:21:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01876 for ; Wed, 19 Mar 2003 14:21:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJcU425848 for avt-archive@odin.ietf.org; Wed, 19 Mar 2003 14:38:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJbvO25704; Wed, 19 Mar 2003 14:37:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJUYO24595 for ; Wed, 19 Mar 2003 14:30:34 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01594 for ; Wed, 19 Mar 2003 14:12:34 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.8/8.12.8) with ESMTP id h2JJEjof070309; Wed, 19 Mar 2003 11:14:45 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 11:14:45 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7928@MISTY> From: Thomas Zeng To: "'casner@acm.org'" Cc: "'avt@ietf.org'" Date: Wed, 19 Mar 2003 11:14:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] Server RTCP RR demultiplexing when one port is used to receive RR s from lots of clients 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 Steve: As promised, I went back to double checke RFC1889. It is said in section 6.1: "SR or RR: The first RTCP packet in the compound packet must always be a report packet to facilitate header validation as described in Appendix A.2. This is true even if no data has been sent nor received, in which case an empty RR is sent, and even if the only other RTCP packet in the compound packet is a BYE." Now when a compound RTCP packet arrives in the server's RTCP port, if RC (Report Count) is not zero, the server's SSRC must be present. Hence server is able to uniquely determine client's identity (since server is capable of asisgn unique Sender SSRC for each client). You are right that there is a trick involved: even if no data is received from the server, RC is set to 1 (instead of zero which seems to be recommended but not required by 1889), a report block is included in the RR with zero bytes/packets. Do you see any problem? - thomas _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 19 20:11:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19154 for ; Wed, 19 Mar 2003 20:11:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K1TJY27009 for avt-archive@odin.ietf.org; Wed, 19 Mar 2003 20:29:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1SpO26985; Wed, 19 Mar 2003 20:28:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1RHO26939 for ; Wed, 19 Mar 2003 20:27:17 -0500 Received: from ns.live.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19078 for ; Wed, 19 Mar 2003 20:09:09 -0500 (EST) Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.8/8.12.5) with ESMTP id h2K1BNAe014213; Wed, 19 Mar 2003 17:11:23 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.8/8.12.3/Submit) id h2K1BMkh014206; Wed, 19 Mar 2003 17:11:23 -0800 (PST) Message-Id: <4.3.1.1.20030319162428.00b783a0@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 19 Mar 2003 17:11:07 -0800 To: multicast@lists.uoregon.edu From: Ross Finlayson Cc: avt@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Bad RTCP in IETF multicast sessions 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: , FYI, I have noticed a couple of problems (one minor; one major) with RTCP packets being sent on at least two of the current IETF multicast sessions: "channel 1 MPEG-1" and "channel 2 MPEG-1". (I haven't checked the H.261 sessions. Note also that the separate, high-bitrate, NCast sessions do not seem to have the problem.) First, the minor problem: Two of the participants (receivers): 128.223.214.24 (==tesla.uoregon.edu) 158.38.62.70 (==tikneppen.uninett.no) on the "channel 1 MPEG-1" session have been sending RTCP packets like the following: 81ca0002 e8e9e765 010e3132 These appear to be RTCP "CNAME" "SDES" packets, but there are a couple of problems with them: 1/ Because these RTCP packets don't begin with a "RR" (or "SR"), they're illegal, according to section 6.1 of the current RTP spec: "draft-ietf-avt-rtp-new-12.txt". 2/ The "length" field in the "CNAME" SDES item (see section 6.5.1 of the RTP spec) is 14 (==0x0e), but there are only two following bytes (0x31 and 0x32)! These participants both appear to be using the same (broken) implementation. Is this MIM? In any case, it should be fixed. Now, the major problem: The sending nodes for both "channel 1 MPEG-1" and "channel 2 MPEG-1" 130.129.32.30 and 130.129.32.10, respectively are sending RTCP "Sender Report" (SR) packets that contain a bad RTP timestamp field. Because of this, the RTP timestamp -> NTP time mapping is getting messed up, which in turn is messing up client audio/video synchronization. Example: 1/ A RTP (video) packet with timestamp 0x2bfc3a46 is received at (Unix epoch) time 1048118445.555259 2/ Next, a RTCP SR packet is received (for the video session): 80c80006 16a2d20b c2238330 69780000 3f0b1b5d 00160cf2 56d52c81 81ca0005 16a2d20b 010d3133 302e3132 392e3332 2e333000 81cc0008 16a2d20b 4d534f4b 1964eb29 00010010 ec1f67fd da1efce1 194ac2ed 7d7ca166 (This RTCP packet actually contains a SDES and an APP packet, following the SR, but for the purpose of this message I care only about the SR.) The NTP timestamp in this SR packet is 0xc2238330,0x69780000 which maps to the (Unix epoch) time 1048118448.411987. So far, so good. However, the RTP timestamp in this SR is 0x3f0b1b5d which is *completely different* from the timestamps that have been appearing in RTP packets around this time. In fact, it's more than 3000 seconds later! Note that the very next packet received is: 3/ A RTP (video) packet with timestamp 0x2bfc6932 It wouldn't be so bad if both the video and audio sessions had SRs with NTP->RTP timestamp mappings that were 3000+ seconds too high. Unfortunately, though, this happens only with the video session. The RTP timestamps in the audio session's SR's are OK. Because of this, a receiver's A/V time synchronization can get badly messed up. Please try to fix this (if not for the rest of this IETF, then in time for the next one). Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 19 20:27:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19515 for ; Wed, 19 Mar 2003 20:27:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K1jTe28439 for avt-archive@odin.ietf.org; Wed, 19 Mar 2003 20:45:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1i8O28397; Wed, 19 Mar 2003 20:44:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1hZO28374 for ; Wed, 19 Mar 2003 20:43:35 -0500 Received: from vmmr7.verisignmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19482 for ; Wed, 19 Mar 2003 20:25:22 -0500 (EST) From: jai@elle7.org Received: from ms2.verisignmail.com (ms2.verisignmail.com [216.168.230.175] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OTB71332; Wed, 19 Mar 2003 20:27:37 -0500 (EST) Received: from ms2.verisignmail.com (localhost.verisignmail.com [127.0.0.1]) by ms2.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACR24474; Wed, 19 Mar 2003 20:27:37 -0500 (EST) Message-Id: <200303200127.ACR24474@ms2.verisignmail.com> Received: from 205.188.209.165 by ms2.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Wed, 19 Mar 2003 20:27:37 -0500 Date: Wed, 19 Mar 2003 20:27:37 -0500 To: avt@ietf.org X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] New to the list 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 Hello all. First let me start by saying... I'm a musician, with a MIDI keyboard, who is amazed by the fact that I've been around all these IETF's and hadn't wandered into one of your WG sessions... (pulled into other WG's and BOF's, more relative to my day job :-)Glad someone pointed me in your direction. Oh well I have lots of catching up to do. I have 2 questions, both very basic... Sometime ago(90's), when first doing recording from MIDI to MAC, I had to use a serial cable connected some sort of interface connected to a MIDI cable to the MIDI device. With all of the developments with RTP and RTCP, being able to run the protocols over IPv4 and IPv6, from a MIDI device, do you have examples of what a network diagram would look like? What types of cables and routers support this type of traffic? The Q&A section on the Charter page is very informative! Thanks, Jai (aka Jessica) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 19 23:05:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23204 for ; Wed, 19 Mar 2003 23:05:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K4N8D05906 for avt-archive@odin.ietf.org; Wed, 19 Mar 2003 23:23:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4LdO05805; Wed, 19 Mar 2003 23:21:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4HMO05590 for ; Wed, 19 Mar 2003 23:17:22 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23082 for ; Wed, 19 Mar 2003 22:59:10 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.8/8.12.8) with ESMTP id h2K41LMG004932 for ; Wed, 19 Mar 2003 23:01:21 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200303200401.h2K41LMG004932@purple.nge.isi.edu> To: avt@ietf.org Date: Wed, 19 Mar 2003 20:01:21 -0800 From: Colin Perkins Subject: [AVT] Presentations from San Francisco meeting 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: , You can find copies of the presentation materials for both AVT sessions at http://www.ietf.org/proceedings/03mar/index.html Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 19 23:29:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24056 for ; Wed, 19 Mar 2003 23:29:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K4le307802 for avt-archive@odin.ietf.org; Wed, 19 Mar 2003 23:47:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4lDO07785; Wed, 19 Mar 2003 23:47:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K1bsO28141 for ; Wed, 19 Mar 2003 20:37:55 -0500 Received: from darkwing.uoregon.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19356 for ; Wed, 19 Mar 2003 20:19:46 -0500 (EST) Received: from darkwing.uoregon.edu (llynch@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.8/8.12.8) with ESMTP id h2K1M0LJ027478; Wed, 19 Mar 2003 17:22:00 -0800 (PST) Received: from localhost (llynch@localhost) by darkwing.uoregon.edu (8.12.8/8.12.8/Submit) with ESMTP id h2K1LvPs027458; Wed, 19 Mar 2003 17:22:00 -0800 (PST) Date: Wed, 19 Mar 2003 17:21:57 -0800 (PST) From: "Lucy E. Lynch" To: Ross Finlayson cc: multicast@lists.uoregon.edu, In-Reply-To: <4.3.1.1.20030319162428.00b783a0@laptop-localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: multicast: Bad RTCP in IETF multicast sessions 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: , Ross - yes, I'm running mim on tesla from the command line (using an sdp file). Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch@darkwing.uoregon.edu (541) 346-1774/Cell: 912-7998 On Wed, 19 Mar 2003, Ross Finlayson wrote: > FYI, I have noticed a couple of problems (one minor; one major) with RTCP > packets being sent on at least two of the current IETF multicast sessions: > "channel 1 MPEG-1" and "channel 2 MPEG-1". (I haven't checked the H.261 > sessions. Note also that the separate, high-bitrate, NCast sessions do > not seem to have the problem.) > > First, the minor problem: Two of the participants (receivers): > 128.223.214.24 (==tesla.uoregon.edu) > 158.38.62.70 (==tikneppen.uninett.no) > on the "channel 1 MPEG-1" session have been sending RTCP packets like the > following: > 81ca0002 e8e9e765 010e3132 > These appear to be RTCP "CNAME" "SDES" packets, but there are a couple of > problems with them: > 1/ Because these RTCP packets don't begin with a "RR" (or "SR"), they're > illegal, according to section 6.1 of the current RTP spec: > "draft-ietf-avt-rtp-new-12.txt". > 2/ The "length" field in the "CNAME" SDES item (see section 6.5.1 of the > RTP spec) is 14 (==0x0e), but there are only two following bytes (0x31 and > 0x32)! > > These participants both appear to be using the same (broken) > implementation. Is this MIM? In any case, it should be fixed. > > > Now, the major problem: The sending nodes for both "channel 1 MPEG-1" and > "channel 2 MPEG-1" > 130.129.32.30 and 130.129.32.10, respectively > are sending RTCP "Sender Report" (SR) packets that contain a bad RTP > timestamp field. Because of this, the RTP timestamp -> NTP time mapping is > getting messed up, which in turn is messing up client audio/video > synchronization. > > Example: > 1/ A RTP (video) packet with timestamp 0x2bfc3a46 is received at (Unix > epoch) time 1048118445.555259 > 2/ Next, a RTCP SR packet is received (for the video session): > 80c80006 16a2d20b c2238330 69780000 3f0b1b5d 00160cf2 56d52c81 > 81ca0005 16a2d20b 010d3133 302e3132 392e3332 2e333000 81cc0008 > 16a2d20b 4d534f4b 1964eb29 00010010 ec1f67fd da1efce1 194ac2ed > 7d7ca166 > (This RTCP packet actually contains a SDES and an APP packet, following the > SR, but for the purpose of this message I care only about the SR.) > The NTP timestamp in this SR packet is > 0xc2238330,0x69780000 > which maps to the (Unix epoch) time 1048118448.411987. So far, so > good. However, the RTP timestamp in this SR is > 0x3f0b1b5d > which is *completely different* from the timestamps that have been > appearing in RTP packets around this time. In fact, it's more than 3000 > seconds later! Note that the very next packet received is: > 3/ A RTP (video) packet with timestamp 0x2bfc6932 > > It wouldn't be so bad if both the video and audio sessions had SRs with > NTP->RTP timestamp mappings that were 3000+ seconds too > high. Unfortunately, though, this happens only with the video > session. The RTP timestamps in the audio session's SR's are OK. Because > of this, a receiver's A/V time synchronization can get badly messed up. > > Please try to fix this (if not for the rest of this IETF, then in time for > the next one). > > Ross. > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 20 00:17:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26067 for ; Thu, 20 Mar 2003 00:17:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K5Z1f10905 for avt-archive@odin.ietf.org; Thu, 20 Mar 2003 00:35:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K5XPO10785; Thu, 20 Mar 2003 00:33:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K5W2O10741 for ; Thu, 20 Mar 2003 00:32:02 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25975 for ; Thu, 20 Mar 2003 00:13:48 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2K5G1HQ016177; Thu, 20 Mar 2003 06:16:01 +0100 (MET) Received: from era.ericsson.se (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id HH7GK4CS; Thu, 20 Mar 2003 06:16:00 +0100 Message-ID: <3E794E8D.2070601@era.ericsson.se> Date: Thu, 20 Mar 2003 06:15:57 +0100 X-Sybari-Trust: 66940d9b d6a25af5 ae26be38 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Zeng CC: "'casner@acm.org'" , "'avt@ietf.org'" Subject: Re: [AVT] Server RTCP RR demultiplexing when one port is used to receive RR s from lots of clients References: <72263E8E8622D611975C0002B32C19D84A7928@MISTY> 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 Thomas, When we are talking about demultiplexing of multiple RTP session on the same server port I have a different view. First the demultiplexing is not based on the SSRC but on the source IP address and port. An RTP session between two entities can be defined by the two end points address and ports. Assumes that data is sent and received on the same port. By strictly defining the RTP session with these two 4-tuples of client address and port and server address and port for RTP and RTCP makes it possible to have separate SSRC spaces for each client. As not being one who have actually implemented this, I still guess that this how it has been done in a lot of servers out there. This solution of course does not work when one come to cases where the clients address is not known. Thomas Zeng wrote: >Hi Steve: > >As promised, I went back to double checke RFC1889. > >It is said in section 6.1: > > "SR or RR: The first RTCP packet in the compound packet must always >be a report packet to facilitate header validation as described in Appendix >A.2. This is true even if no data has been sent nor received, in which case >an empty RR is sent, and even if the only other RTCP packet in the compound >packet is a BYE." > >Now when a compound RTCP packet arrives in the server's RTCP port, if RC >(Report Count) is not zero, the server's SSRC must be present. Hence server >is able to uniquely determine client's identity (since server is capable of >asisgn unique Sender SSRC for each client). >You are right that there is a trick involved: even if no data is received >from the server, RC is set to 1 (instead of zero which seems to be >recommended but not required by 1889), a report block is included in the RR >with zero bytes/packets. >Do you see any problem? > I see some problems with this. You assume that the client gets the SSRC of the server through signaling (RTSP). However RTP has not seen the SSRC yet. This creates problems with the implementations. A RTCP implementation creates the RTCP receiver report blocks based on the implementations internal state. This state is normally populated based on incoming traffic. Therefore having the client create a state for the server that is not based on received traffic will requires implementation work. Secondly, their is a problem with the report block. To include a report block you must include the extended sequence number as being the last packet seen plus the roll over counter. This creates problems as the client RTP implementation has so far not seen any packet. So sending a report block does in fact lie. I see this as an problem. This may certainly have issues with the RTP/RTCP implementations. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 20 04:16:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12353 for ; Thu, 20 Mar 2003 04:16:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K9YBK05269 for avt-archive@odin.ietf.org; Thu, 20 Mar 2003 04:34:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K9WhO05223; Thu, 20 Mar 2003 04:32:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K9VRO05155 for ; Thu, 20 Mar 2003 04:31:27 -0500 Received: from oak.FernUni-Hagen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12309 for ; Thu, 20 Mar 2003 04:12:49 -0500 (EST) Received: from amavis by oak.FernUni-Hagen.de with scanned-ok (Exim 4.04) id 18vw8d-0005pk-00; Thu, 20 Mar 2003 10:15:03 +0100 Received: from lgks2.fernuni-hagen.de ([132.176.12.66]) by oak.FernUni-Hagen.de with esmtp (Exim 4.04) id 18vw8U-0005pG-00; Thu, 20 Mar 2003 10:14:54 +0100 Received: from LGKS2/SpoolDir by lgks2.fernuni-hagen.de (Mercury 1.48); 20 Mar 03 10:14:18 +0100 Received: from SpoolDir by LGKS2 (Mercury 1.48); 20 Mar 03 10:14:10 +0100 Received: from notebookms (132.176.12.20) by lgks2.fernuni-hagen.de (Mercury 1.48); 20 Mar 03 10:14:02 +0100 Reply-To: From: "Stepping, Michael" To: "Nükhet Özbek \(Dijital Arge\)" , Subject: RE: [AVT] Hello Date: Thu, 20 Mar 2003 10:14:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Low X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2K9VmO05165 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 Hi, Your questions are related to Video codecs. You will find a lot of information if you google for MPEG-4, MPEG-4 AVC, H.264 or simply look in ISO/IEC 14496-10 or ITU-T H.264, respectively. Yours, Michael > -----Original Message----- > To: 'avt@ietf.org' > Subject: [AVT] Hello > > > Hi, > > I am anew subscriber of the list. > And I have a question about H26.L and H.324 framework. > What is H.324 framework? And what is the relation with H26.L? > > Thanks & Regards, > Nükhet. > _______________________________________________ > Audio/Video Transport Working Group _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 20 12:42:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26756 for ; Thu, 20 Mar 2003 12:42:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KI0Yw09810 for avt-archive@odin.ietf.org; Thu, 20 Mar 2003 13:00:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KI02O09714; Thu, 20 Mar 2003 13:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHsLO09305 for ; Thu, 20 Mar 2003 12:54:21 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26506 for ; Thu, 20 Mar 2003 12:35:52 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.8/8.12.8) with ESMTP id h2KHc3of091990; Thu, 20 Mar 2003 09:38:03 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 09:38:03 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D803E04822@MISTY> From: Thomas Zeng To: Magnus Westerlund , Thomas Zeng Cc: "'avt@ietf.org'" Subject: RE: [AVT] Server RTCP RR demultiplexing when one port is used to receive RR s from lots of clients Date: Thu, 20 Mar 2003 09:38:02 -0800 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: , Thanks for your comments, Magnus. My answers inlined. -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Wednesday, March 19, 2003 9:16 PM To: Thomas Zeng Cc: 'casner@acm.org'; 'avt@ietf.org' Subject: Re: [AVT] Server RTCP RR demultiplexing when one port is used to receive RR s from lots of clients Hi Thomas, When we are talking about demultiplexing of multiple RTP session on the same server port I have a different view. First the demultiplexing is not based on the SSRC but on the source IP address and port. An RTP session between two entities can be defined by the two end points address and ports. Assumes that data is sent and received on the same port. By strictly defining the RTP session with these two 4-tuples of client address and port and server address and port for RTP and RTCP makes it possible to have separate SSRC spaces for each client. As not being one who have actually implemented this, I still guess that this how it has been done in a lot of servers out there. This solution of course does not work when one come to cases where the clients address is not known. [TZ] The last case (when Server is in the open, and Clinet is behind a NAT) is what I am talking about. Thomas Zeng wrote: >Hi Steve: > >As promised, I went back to double checke RFC1889. > >It is said in section 6.1: > > "SR or RR: The first RTCP packet in the compound packet must always >be a report packet to facilitate header validation as described in Appendix >A.2. This is true even if no data has been sent nor received, in which case >an empty RR is sent, and even if the only other RTCP packet in the compound >packet is a BYE." > >Now when a compound RTCP packet arrives in the server's RTCP port, if RC >(Report Count) is not zero, the server's SSRC must be present. Hence server >is able to uniquely determine client's identity (since server is capable of >asisgn unique Sender SSRC for each client). >You are right that there is a trick involved: even if no data is received >from the server, RC is set to 1 (instead of zero which seems to be >recommended but not required by 1889), a report block is included in the RR >with zero bytes/packets. >Do you see any problem? > I see some problems with this. You assume that the client gets the SSRC of the server through signaling (RTSP). However RTP has not seen the SSRC yet. This creates problems with the implementations. A RTCP implementation creates the RTCP receiver report blocks based on the implementations internal state. This state is normally populated based on incoming traffic. Therefore having the client create a state for the server that is not based on received traffic will requires implementation work. [TZ] Here Server SSRC happens to be in the RTP header. Hence client can use RTP header to obtain server SSRC if client has received at least one RTP for the session. If it has not but has received Setup response, it then can use SSRC obtained from there. Yes, it is not nice because RTP implementation is prefered not to have dependencies on the control protocol. However, RTP implementation must somehow obtain server's RTCP receive address and port, anyway, from no where but the control protocol. Adding SSRC to the list of dependencies isn't a new breach of the rule. Secondly, their is a problem with the report block. To include a report block you must include the extended sequence number as being the last packet seen plus the roll over counter. This creates problems as the client RTP implementation has so far not seen any packet. So sending a report block does in fact lie. I see this as an problem. This may certainly have issues with the RTP/RTCP implementations. [TZ] Yes, I agree with you on this one. Fortunately, since not only the highest SeqNum but also the total number bytes received are 0, there is no confusion. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 21 09:11:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13995 for ; Fri, 21 Mar 2003 09:11:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LEU2K08232 for avt-archive@odin.ietf.org; Fri, 21 Mar 2003 09:30:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LETOO08149; Fri, 21 Mar 2003 09:29:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LERKO08085 for ; Fri, 21 Mar 2003 09:27:20 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13892 for ; Fri, 21 Mar 2003 09:08:28 -0500 (EST) Received: by mail-blue.research.att.com (Postfix, from userid 612) id 9F129B7DE2; Fri, 21 Mar 2003 09:11:55 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id E234EB7B8A for ; Fri, 21 Mar 2003 09:11:54 -0500 (EST) Received: from research.att.com (brow0005.research.att.com [135.207.56.5]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id JAA11118 for ; Fri, 21 Mar 2003 09:10:16 -0500 (EST) Message-ID: <3E7B1D6A.8090901@research.att.com> Date: Fri, 21 Mar 2003 09:10:50 -0500 From: Eric Cheung Organization: AT&T Labs Research User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Subject: Re: [AVT] Question on RTP sequence number in RFC2833 and bis-02 References: <3E5CB17B.2010805@research.att.com> <3E68C817.4030303@research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-135.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) 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 Henning Schulzrinne and I discussed this at IETF 56, and I am sending this to close this thread. The RTP packets sent out at the end an event should have increasing sequence number. This is primarily so that the receiver can detect if one or more of these packets are lost. If they all have the same sequence number, then there is no way for the receiver to tell. Some implementations I have tested send out 3 packets with same sequence number. This should not present a major problem in terms of receiver recognizing the DTMF event, but may cause inaccurate RTCP reports. Thanks Eric Eric Cheung wrote: > Hi, I am still hoping that I can get some clarification from the WG on > this question. Apologies if this was discussed before, but I could not > find anything by searching on the archive. > > Thanks > Eric > > Eric Cheung wrote: > >> Hi Henning, Scott >> >> Want to clarify a fine point. >> >> In RFC2833: >> >> If there has been no new event >> in the last interval, the event SHOULD be retransmitted three times >> or until the next event is recognized. >> >> Q1: For a device conforming to RFC2833, should the RTP sequence number >> in the 3 packets be incremented, or should they be the same? >> >> >> In RFC2833bis-02, this seems to be clarified: >> >> If an event has ended and >> there has been no new event in the last interval, the event SHOULD be >> retransmitted three times at the interval used by the source for >> updates. >> >> In all cases, the RTP sequence number MUST be incremented by one in >> each RTP packet. >> >> Q2: Can you confirm that if a device conforms to bis-02, the sequence >> number in the 3 packets will be monotonically increasing? >> >> Q3: In writing this, I realize that I am not sure whether there should >> be 4 packets (1 original transmission + 3 retransmission) or 3 >> packets. Can you clarify this? >> >> >> Sorry for the nit-picking, but when testing it seems many devices do >> many different things when it comes to 2833. >> >> Thanks >> Eric > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 21 10:03:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14904 for ; Fri, 21 Mar 2003 10:03:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LFLd311626 for avt-archive@odin.ietf.org; Fri, 21 Mar 2003 10:21:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFIFO11437; Fri, 21 Mar 2003 10:18:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFGlO11345 for ; Fri, 21 Mar 2003 10:16:47 -0500 Received: from lists.herlein.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14680 for ; Fri, 21 Mar 2003 09:57:53 -0500 (EST) Received: from tux.herlein.com (tux.herlein.com [192.168.70.50]) by lists.herlein.com (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id h2LEh6C06530 for ; Fri, 21 Mar 2003 06:43:06 -0800 Date: Fri, 21 Mar 2003 07:00:10 -0800 (PST) From: Greg Herlein To: avt@ietf.org In-Reply-To: <3E7B1D6A.8090901@research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Speex: Apologies for Missed Meeting 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 those expecting my presentation yesterday on the Speex codec, I apologize for not being there. I was caught out in the traffic mess that occurred due to the anti-war protests - I could not get to the meeting in time. I hope that you all had a chance to look at the codec and the profile anyway, and that if you have comments you will make them to the list or privately. Version 1.0 of the codec specification and implementation will be released on Monday. We ask that if you have concerns about the actual codec portion (as opposed to the RTP Profile) that you make those concerns known immediatley if you think it should delay the 1.0 release. Again, sorry I could not make it. Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 21 11:56:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18726 for ; Fri, 21 Mar 2003 11:56:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LHFDb19820 for avt-archive@odin.ietf.org; Fri, 21 Mar 2003 12:15:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHEdO19691; Fri, 21 Mar 2003 12:14:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LH92O19244 for ; Fri, 21 Mar 2003 12:09:02 -0500 Received: from mailman.packetdesign.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18588 for ; Fri, 21 Mar 2003 11:50:05 -0500 (EST) 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 h2LGq7cC042354; Fri, 21 Mar 2003 08:52:08 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 21 Mar 2003 08:58:23 -0800 (PST) From: Stephen Casner To: Greg Herlein cc: avt@ietf.org Subject: Re: [AVT] Speex: Apologies for Missed Meeting In-Reply-To: Message-ID: <20030321085158.V397-100000@oak.packetdesign.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: , Greg, > To those expecting my presentation yesterday on the Speex codec, > I apologize for not being there. I was caught out in the traffic > mess that occurred due to the anti-war protests - I could not get > to the meeting in time. I did step through your slides so that the audience could read them, although that is not the same as the presentation you would have made. > I hope that you all had a chance to look at the codec and the > profile anyway, and that if you have comments you will make them > to the list or privately. One quick correction: your document is a "payload format" not a "profile". The the introduction of the RTP spec for the explanation of the difference. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Mar 21 21:59:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06069 for ; Fri, 21 Mar 2003 21:59:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2M3I5530434 for avt-archive@odin.ietf.org; Fri, 21 Mar 2003 22:18:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M3HGO30404; Fri, 21 Mar 2003 22:17:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M3F7O30362 for ; Fri, 21 Mar 2003 22:15:07 -0500 Received: from ns.live.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06038 for ; Fri, 21 Mar 2003 21:55:59 -0500 (EST) Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.8/8.12.5) with ESMTP id h2M2w4xU045961; Fri, 21 Mar 2003 18:58:04 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.8/8.12.3/Submit) id h2M2vpaR045752; Fri, 21 Mar 2003 18:57:51 -0800 (PST) Message-Id: <4.3.1.1.20030321182511.00b5ebc0@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 21 Mar 2003 18:55:15 -0800 To: avt@ietf.org From: Ross Finlayson Subject: Re: [AVT] Speex: Apologies for Missed Meeting Cc: Greg Herlein In-Reply-To: <20030321085158.V397-100000@oak.packetdesign.com> 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: , Greg, Sorry you couldn't make the meeting. Here were some comments that I had planned to make about the Speex RTP packet format: 1/ It's quite common in audio payload formats to use the RTP 'M' bit to indicate the start of a talkspurt . You might want to do the same (assuming, of course, that you plan to allow for senders to avoid sending packets during periods of silence). 2/ Having the number of frames per RTP packet indicated 'out of band' (i.e., using SDP) is unorthodox, and rather inflexible. The alternative, more common approach is to indicate that 'in band' - i.e., in the RTP packet itself. Because Speex frames are variable-length (correct?) and don't have a 'sync word' to indicate their start (correct?), you could do this by having a 'packet length' descriptor precede each Speex frame in a RTP packet. 3/ Similarly, what happens if a Speex frame is too large to fit in a RTP packet? Although Speex frames may be quite small, you should also allow for the possibility of RTP packets being even smaller. To deal with 2/ and 3/, you might consider having a descriptor - preceding each Speex frame in a RTP packet - something like the following: +-+-+-+-+-+-+-+-+ | S|E|D| L | +-+-+-+-+-+-+-+-+ where: - S (1 bit): Set to 1 iff the packet contains the start of a Speex frame (or one or more complete Speex frames) - E (1 bit): Set to 1 iff the packet contains the end of a Speex frame (or one or more complete Speex frames) - D (1 bit): Set to 0 if the descriptor is 1 octet (i.e., 8 bits) long. Set to 1 if the descriptor is 2 octets (i.e., 16 bits) long. - L (5 bits, or 13 bits, depending on "D"): The length of the following Speex frame. As a special case, a value of zero could mean: The entire remainder of the RTP packet is a single Speex frame. (Thus, if having just a single Speex frame per RTP packet is going to be the common case, then you could indicate this using just a single 0xC0 descriptor byte.) Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Mar 22 10:15:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28113 for ; Sat, 22 Mar 2003 10:15:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MFYVQ14922 for avt-archive@odin.ietf.org; Sat, 22 Mar 2003 10:34:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFXjO14889; Sat, 22 Mar 2003 10:33:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFVRO14842 for ; Sat, 22 Mar 2003 10:31:27 -0500 Received: from lists.herlein.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27788 for ; Sat, 22 Mar 2003 10:12:01 -0500 (EST) Received: from tux.herlein.com (tux.herlein.com [192.168.70.50]) by lists.herlein.com (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id h2MEv2C15326; Sat, 22 Mar 2003 06:57:02 -0800 Date: Sat, 22 Mar 2003 07:14:11 -0800 (PST) From: Greg Herlein To: Ross Finlayson cc: Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org In-Reply-To: <4.3.1.1.20030321182511.00b5ebc0@laptop-localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Speex payload discussion 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 overwhelming design goal for the speex codec implementation in RTP is "keep it as simple as possible" - at least so far. I know that the speex community will embrace anything that makes sense though, so comments are very welcome. > 1/ It's quite common in audio payload formats to use the RTP 'M' bit to > indicate the start of a talkspurt > . You might want to > do the same (assuming, of course, that you plan to allow for senders to > avoid sending packets during periods of silence). If speek is used in VBR with VAD enabled, then I don't think this is needed. The "silent frame" is only 5 bits long, so while it's not "avoiding sending packets" it is certainly saving lots of bandwidth. And it's totally transparent - the codec library takes care of it. Marker bits used this way are only hints - there is always the timestamp too. And, relying on a bit in a packet that may be lost seems unwise. The codec deals with it internally seemingly fine. Why make it harder? Sending such a "silent packet" is good too, since (assuming it arrives) it tells the decoder that there is in facta silent frame allowing it to play CN if it wants, and to keep the jitter playback buffer happily syncronized. > 2/ Having the number of frames per RTP packet indicated 'out > of band' (i.e., using SDP) is unorthodox, and rather > inflexible. The alternative, more common approach is to > indicate that 'in band' - i.e., in the RTP packet itself. > Because Speex frames are variable-length (correct?) and > don't have a 'sync word' to indicate their start (correct?), > you could do this by having a 'packet length' descriptor > precede each Speex frame in a RTP packet. Well, that was argued at length on the speex list. The normal way to use speex will be one frame per packet. That being the case, sending an extra octet in every frame only adds overhead that serves no useful purpose. Most of the speex folks seemed in favor of requiring out-of-band means to signal the unusual. > 3/ Similarly, what happens if a Speex frame is too large to > fit in a RTP packet? Although Speex frames may be quite > small, you should also allow for the possibility of RTP > packets being even smaller. Hmmmm. We'll have to think about that. I don't think you can split a G.723.1 frame across multiple RTP packets, so why have that capability in Speex? The largest single Speex frame is 110 bytes long (that's 44kbps rate sampled at 32kHz) ... so even on networks with small MTUs that should not be a problem. The nominal 8000kbps (8kHz sample rate) VoIP type frame would be only 20 bytes long. I susepct that no MTU will ever be smaller than that! > > To deal with 2/ and 3/, you might consider having a descriptor - preceding > each Speex frame in a RTP packet - something like the following: Well, same concern as above - your suggestion has come up before (remarkably similar to other proposals too - we all tend to think a bit alike it seems) but is it really needed to add that constant extra bits of overhead? One argument is that it's *only* a single octet. The other is that any overhead not needed in a majority of the cases is wasteful bloat. I'd love to hear comments from the wider AVT community on this. Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat Mar 22 10:24:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28247 for ; Sat, 22 Mar 2003 10:24:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MFhYY16057 for avt-archive@odin.ietf.org; Sat, 22 Mar 2003 10:43:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFhBO15978; Sat, 22 Mar 2003 10:43:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFgAO15951 for ; Sat, 22 Mar 2003 10:42:10 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28222 for ; Sat, 22 Mar 2003 10:22:47 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2MFOnl2002456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 22 Mar 2003 10:24:50 -0500 (EST) Message-ID: <3E7C8043.20904@cs.columbia.edu> Date: Sat, 22 Mar 2003 10:24:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Herlein CC: Ross Finlayson , Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org Subject: Re: [AVT] Speex payload discussion 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 > If speek is used in VBR with VAD enabled, then I don't think this > is needed. The "silent frame" is only 5 bits long, so while it's > not "avoiding sending packets" it is certainly saving lots of > bandwidth. And it's totally transparent - the codec library > takes care of it. Marker bits used this way are only hints - > there is always the timestamp too. And, relying on a bit in a > packet that may be lost seems unwise. The codec deals with it > internally seemingly fine. Why make it harder? Because M bits are useful hints to other applications that may not know the details of the codec format. Thus, all voice codecs should use them unless there's a really, really good reason not to. One of the design goals of RTP is to allow codec-unaware entities by providing hints about clock rates, silence periods and the like. I see no reason why Speex should deviate from this well-proven design. Henning _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 23 16:41:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11689 for ; Sun, 23 Mar 2003 16:41:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NM0ok30515 for avt-archive@odin.ietf.org; Sun, 23 Mar 2003 17:00:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NLwtO30014; Sun, 23 Mar 2003 16:58:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NLu2O29935 for ; Sun, 23 Mar 2003 16:56:02 -0500 Received: from lists.herlein.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11381 for ; Sun, 23 Mar 2003 16:36:00 -0500 (EST) Received: from tux.herlein.com (tux.herlein.com [192.168.70.50]) by lists.herlein.com (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id h2NLKOC24632; Sun, 23 Mar 2003 13:20:24 -0800 Date: Sun, 23 Mar 2003 13:37:42 -0800 (PST) From: Greg Herlein To: Henning Schulzrinne cc: Ross Finlayson , Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org Subject: Re: [AVT] Speex payload discussion In-Reply-To: <3E7C8043.20904@cs.columbia.edu> 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: , > Because M bits are useful hints to other applications that may not know > the details of the codec format. Thus, all voice codecs should use them > unless there's a really, really good reason not to. Well, I would argue (with all due respect) that other applications that don't know how to decode a codec should not set up that stream in the first place. :) I would argue that the marker bit is defined in the codec profile and if you don't know the details of the codec, you probably won't know what the marker bit means. It might mean something else entirely. :) But, seriously, RFC1890 states: "For applications which send no packets during silence, the first packet of a talkspurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero.' " It turns out that using libspeex it's implementation-specific whether you send 5-bit frames (padded to one octet) during silence, or whether you send nothing during silence. You *do* get the 5 bit value in the byte returned when you encode the frame. However, contrary to at least my understanding, you do *NOT* have to send that frame for libspeex to happily cruise along on the decoder side. If you don't send it, libspeex still does the right thing. If you do send it, libspeex still does the right thing. But, to retain the behavior of other "well-proven designs" I propose that we add language to the speex payload format that states that if an implementaion sends the 5-bit silence frame (as a one octet payload) that it SHOULD set the marker bit in the first subsequent packet that contains valid audio (non-silence) data. If the implementation does not send silence frames, then it MUST set the marker bit in the first subsequent packet that contains valid audio (non-silence) data. > One of the design goals of RTP is to allow codec-unaware entities by > providing hints about clock rates, silence periods and the like. I see > no reason why Speex should deviate from this well-proven design. I certainly did not intend to deviate from anything. I was only saying that if we send a (short) frame that is effectively a placeholder meaning "silence" then there was no need for the marker bit, and if there was no need, then it would be redundant to require it to be included. But, if it breaks other stuff to not set that bit, then by all means let's state it must be set. Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 23 16:58:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11936 for ; Sun, 23 Mar 2003 16:58:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NMHf331938 for avt-archive@odin.ietf.org; Sun, 23 Mar 2003 17:17:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMH8O31916; Sun, 23 Mar 2003 17:17:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMG8O31895 for ; Sun, 23 Mar 2003 17:16:08 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11914 for ; Sun, 23 Mar 2003 16:56:07 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h2NLwLl2016872 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 23 Mar 2003 16:58:23 -0500 (EST) Message-ID: <3E7E2E1D.5030501@cs.columbia.edu> Date: Sun, 23 Mar 2003 16:58:53 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Herlein CC: Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org Subject: Re: [AVT] Speex payload discussion 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 Among other reasons, the M bit allows codec-unaware applications to perform better playout delay adaptation (since you want to do those during silence, not talk spurts). Thus, I'm glad to hear that Speex will make this possible. Also, this is *not* an 'extra' bit. You already paid for it :-) > I certainly did not intend to deviate from anything. I was only > saying that if we send a (short) frame that is effectively a > placeholder meaning "silence" then there was no need for the > marker bit, and if there was no need, then it would be redundant Assuming you know the codec. My premise was that you didn't. > to require it to be included. But, if it breaks other stuff to > not set that bit, then by all means let's state it must be set. > > Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Mar 23 18:50:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15684 for ; Sun, 23 Mar 2003 18:50:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O0A3Q05730 for avt-archive@odin.ietf.org; Sun, 23 Mar 2003 19:10:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O08SO05644; Sun, 23 Mar 2003 19:08:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MII6O26140 for ; Sat, 22 Mar 2003 13:18:06 -0500 Received: from VL-MS-MR004.sc1.videotron.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00931 for ; Sat, 22 Mar 2003 12:58:39 -0500 (EST) Received: from [192.168.1.13] ([24.203.204.246]) by VL-MS-MR004.sc1.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HC500DNVWQL73@VL-MS-MR004.sc1.videotron.ca> for avt@ietf.org; Sat, 22 Mar 2003 13:01:34 -0500 (EST) Date: Sat, 22 Mar 2003 12:53:36 -0500 From: Jean-Marc Valin In-reply-to: To: Greg Herlein Cc: Ross Finlayson , Roger Hardiman , Simon Morlat , avt@ietf.org Message-id: <1048355615.1867.25.camel@idefix.homelinux.org> Organization: =?ISO-8859-1?Q?Universit=C3=A9_de?= Sherbrooke MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-type: multipart/signed; boundary="=-5Wx0NqlKmfjpx4HRWdzC"; protocol="application/pgp-signature"; micalg=pgp-sha1 References: Subject: [AVT] Re: Speex payload discussion 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: , --=-5Wx0NqlKmfjpx4HRWdzC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't got the full context, so I hope what I'm saying makes sense. > If speek is used in VBR with VAD enabled, then I don't think this > is needed. The "silent frame" is only 5 bits long, so while it's > not "avoiding sending packets" it is certainly saving lots of > bandwidth. And it's totally transparent - the codec library > takes care of it. Marker bits used this way are only hints - > there is always the timestamp too. And, relying on a bit in a > packet that may be lost seems unwise. The codec deals with it > internally seemingly fine. Why make it harder? Actually, the "silence frames" can only happen when DTX is enabled (just VBR or VAD is not enough). Also, while in Ogg files they are encoded with 5 bits, in network applications, there's really _no transmission_. Note also that the way it works is that there's already a flag in the last packet before silence that says "from now on, if you don't recieve anything, it's noise not packet loss". BTW, although for now we're not using the marker bit, it may still be good to set it. > Well, that was argued at length on the speex list. The normal > way to use speex will be one frame per packet. That being the > case, sending an extra octet in every frame only adds overhead > that serves no useful purpose. Most of the speex folks seemed in > favor of requiring out-of-band means to signal the unusual. I think I agree on your point. While if would be possible to get clever tricks to find the number of packets from the packet length, I don't think it's really clean. Jean-Marc --=20 Jean-Marc Valin, M.Sc.A. LABORIUS (http://www.gel.usherb.ca/laborius) Universit=E9 de Sherbrooke, Qu=E9bec, Canada --=-5Wx0NqlKmfjpx4HRWdzC Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Pour information voir http://www.gnupg.org iD8DBQA+fKMfdXwABdFiRMQRAv60AJkB1amPKRQy3GfNqccLdqtXKjCUhgCcCUlO 1h8CxIt4IvMK0JTlhwLp4vo= =DGN8 -----END PGP SIGNATURE----- --=-5Wx0NqlKmfjpx4HRWdzC-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 24 13:02:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27152 for ; Mon, 24 Mar 2003 13:02:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OIM7120948 for avt-archive@odin.ietf.org; Mon, 24 Mar 2003 13:22:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OILWO20912; Mon, 24 Mar 2003 13:21:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIKJO20865 for ; Mon, 24 Mar 2003 13:20:19 -0500 Received: from vmmr7.verisignmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27084 for ; Mon, 24 Mar 2003 12:59:49 -0500 (EST) From: jai@elle7.org Received: from ms2.verisignmail.com (ms2.verisignmail.com [216.168.230.175] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OTF98148; Mon, 24 Mar 2003 13:02:04 -0500 (EST) Received: from ms2.verisignmail.com (localhost.verisignmail.com [127.0.0.1]) by ms2.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACX08311; Mon, 24 Mar 2003 13:02:03 -0500 (EST) Message-Id: <200303241802.ACX08311@ms2.verisignmail.com> Received: from 192.112.38.35 by ms2.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Mon, 24 Mar 2003 13:02:03 -0500 Date: Mon, 24 Mar 2003 13:02:03 -0500 To: avt@ietf.org X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-----d94b291414b8629bed46899d54aa3bba" Subject: [AVT] Fwd: Speex Goes 1.0; Xiph.Org now a 501(c)3 Non-Profit Organization 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: , -------d94b291414b8629bed46899d54aa3bba Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Article today on www.slashdot.org -------d94b291414b8629bed46899d54aa3bba Content-Type: message/rfc822; name="Message 75" Content-Disposition: inline; filename="Message 75" Return-Path: Received: from vmmr2.verisignmail.com (vmmr2.verisignmail.com [10.166.0.139]) by ms2.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACX07961; Mon, 24 Mar 2003 13:00:06 -0500 (EST) Received: from vmbm2.verisignmail.com (vmbmnat.verisignmail.com [216.168.230.170]) by vmmr2.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PUQ89965; Mon, 24 Mar 2003 13:00:06 -0500 (EST) Received: from ops2.nic.mil (ops2.nic.mil [192.112.38.5]) by vmbm2.verisignmail.com (8.12.6/8.12.6) with ESMTP id h2OHxwVl023283 for ; Mon, 24 Mar 2003 12:59:59 -0500 (EST) Received: from JAZZPC (jazz-pc.nic.mil [192.112.38.35]) by ops2.nic.mil (8.12.8/8.12.8) with ESMTP id h2OHwMdL015342 for ; Mon, 24 Mar 2003 12:58:22 -0500 (EST) From: "Jessica Little" To: Subject: Speex Goes 1.0; Xiph.Org now a 501(c)3 Non-Profit Organization Date: Mon, 24 Mar 2003 12:58:35 -0500 Message-ID: <000001c2f22e$fdde0ac0$232670c0@nic.mil> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C2F205.15119FB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2F205.15119FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Slashdot article today... http://www.xiph.org/press/2003/nonprofitspeex1/ ------=_NextPart_000_0001_01C2F205.15119FB0 Content-Type: application/octet-stream; name="Speex Goes 1.0; Xiph.Org now a 501(c)3 Non-Profit Organization.url" Content-Disposition: attachment; filename="Speex Goes 1.0; Xiph.Org now a 501(c)3 Non-Profit Organization.url" Content-Transfer-Encoding: 7bit [DEFAULT] BASEURL=http://www.xiph.org/press/2003/nonprofitspeex1/ [InternetShortcut] URL=http://www.xiph.org/press/2003/nonprofitspeex1/ Modified=E0AA37DF2EF2C20183 ------=_NextPart_000_0001_01C2F205.15119FB0-- -------d94b291414b8629bed46899d54aa3bba-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 24 14:48:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00414 for ; Mon, 24 Mar 2003 14:48:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OK84T28379 for avt-archive@odin.ietf.org; Mon, 24 Mar 2003 15:08:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OK7cO28347; Mon, 24 Mar 2003 15:07:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OK6UO27560 for ; Mon, 24 Mar 2003 15:06:30 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00377 for ; Mon, 24 Mar 2003 14:46:03 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h2OJltN10485; Mon, 24 Mar 2003 14:47:55 -0500 Message-Id: <200303241947.h2OJltN10485@chiron.nge.isi.edu> To: Greg Herlein cc: Ross Finlayson , Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org Subject: Re: [AVT] Speex payload discussion In-Reply-To: Your message of "Sat, 22 Mar 2003 07:14:11 PST." Date: Mon, 24 Mar 2003 14:47:55 -0500 From: Colin Perkins 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: , A few comments inline - I'll skip the M bit issue, since I agree with Henning's comments. --> Greg Herlein writes: ... >> 2/ Having the number of frames per RTP packet indicated 'out >> of band' (i.e., using SDP) is unorthodox, and rather >> inflexible. The alternative, more common approach is to >> indicate that 'in band' - i.e., in the RTP packet itself. >> Because Speex frames are variable-length (correct?) and >> don't have a 'sync word' to indicate their start (correct?), >> you could do this by having a 'packet length' descriptor >> precede each Speex frame in a RTP packet. > >Well, that was argued at length on the speex list. The normal >way to use speex will be one frame per packet. That being the >case, sending an extra octet in every frame only adds overhead >that serves no useful purpose. Most of the speex folks seemed in >favor of requiring out-of-band means to signal the unusual. The EVRC payload format addresses this by defining a simple format where only a single frame is included in the packet, and a more complex format which has a header and multiple frames. The signalling then selects which of the two formats is used. This may be an acceptable solution here, too. Alternatively, if you can tell the length of the frame by parsing the frame data, there is no need to signal the number of frames per packet. >> 3/ Similarly, what happens if a Speex frame is too large to >> fit in a RTP packet? Although Speex frames may be quite >> small, you should also allow for the possibility of RTP >> packets being even smaller. > >Hmmmm. We'll have to think about that. I don't think you can >split a G.723.1 frame across multiple RTP packets, so why have >that capability in Speex? The largest single Speex frame is 110 >bytes long (that's 44kbps rate sampled at 32kHz) ... so even on >networks with small MTUs that should not be a problem. The >nominal 8000kbps (8kHz sample rate) VoIP type frame would be only >20 bytes long. I susepct that no MTU will ever be smaller than >that! Given the small size of the packets, it's probably acceptable to leave fragementation to the IP layer. Cheers, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 24 15:04:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01037 for ; Mon, 24 Mar 2003 15:04:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OKOjL29016 for avt-archive@odin.ietf.org; Mon, 24 Mar 2003 15:24:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKODO28999; Mon, 24 Mar 2003 15:24:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OKNbO28958 for ; Mon, 24 Mar 2003 15:23:37 -0500 Received: from lists.herlein.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00843 for ; Mon, 24 Mar 2003 15:03:09 -0500 (EST) Received: from tux.herlein.com (tux.herlein.com [192.168.70.50]) by lists.herlein.com (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id h2OJlpC31937; Mon, 24 Mar 2003 11:47:51 -0800 Date: Mon, 24 Mar 2003 12:05:13 -0800 (PST) From: Greg Herlein To: Colin Perkins cc: Ross Finlayson , Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org Subject: Re: [AVT] Speex payload discussion In-Reply-To: <200303241947.h2OJltN10485@chiron.nge.isi.edu> 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: , > The EVRC payload format addresses this by defining a simple format where > only a single frame is included in the packet, and a more complex format > which has a header and multiple frames. The signalling then selects which > of the two formats is used. This may be an acceptable solution here, too. Is it *that* bad a thing to just let the signalling define the number of frames in a packet in the first place, the way it's currently defined? > Alternatively, if you can tell the length of the frame by parsing the frame > data, there is no need to signal the number of frames per packet. That's not possible, unfortunately. Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 24 15:55:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03473 for ; Mon, 24 Mar 2003 15:55:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OLF6a32558 for avt-archive@odin.ietf.org; Mon, 24 Mar 2003 16:15:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLEeO32537; Mon, 24 Mar 2003 16:14:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OLDHO32490 for ; Mon, 24 Mar 2003 16:13:17 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03434 for ; Mon, 24 Mar 2003 15:52:48 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h2OKt1x10867; Mon, 24 Mar 2003 15:55:01 -0500 Message-Id: <200303242055.h2OKt1x10867@chiron.nge.isi.edu> To: Greg Herlein cc: Ross Finlayson , Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org Subject: Re: [AVT] Speex payload discussion In-Reply-To: Your message of "Mon, 24 Mar 2003 12:05:13 PST." Date: Mon, 24 Mar 2003 15:55:01 -0500 From: Colin Perkins 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 Herlein writes: >> The EVRC payload format addresses this by defining a simple format where >> only a single frame is included in the packet, and a more complex format >> which has a header and multiple frames. The signalling then selects which >> of the two formats is used. This may be an acceptable solution here, too. > >Is it *that* bad a thing to just let the signalling define the >number of frames in a packet in the first place, the way it's >currently defined? No, it's just a little unusual. If there's no reason why a sender would want to change the number of frames per packet, then signaling it out of band is entirely appropriate. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 24 17:31:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06246 for ; Mon, 24 Mar 2003 17:31:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMp6w07060 for avt-archive@odin.ietf.org; Mon, 24 Mar 2003 17:51:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMoTO06928; Mon, 24 Mar 2003 17:50:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMkIO06783 for ; Mon, 24 Mar 2003 17:46:18 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06077 for ; Mon, 24 Mar 2003 17:25:46 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.8/jtpda-5.4+victor) with ESMTP id h2OMS50u018873 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Mon, 24 Mar 2003 23:28:05 +0100 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.6) with ESMTP id h2OMS5w13111; Mon, 24 Mar 2003 23:28:05 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Timur Friedman To: IETF AVT WG Subject: Re: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-03.txt Date: Mon, 24 Mar 2003 23:28:03 +0100 User-Agent: KMail/1.4.3 References: <200303061542.KAA21142@ietf.org> <3E6DF4E6.3080106@era.ericsson.se> In-Reply-To: <3E6DF4E6.3080106@era.ericsson.se> Cc: Magnus Westerlund MIME-Version: 1.0 Message-Id: <200303242328.03345.timur.friedman@lip6.fr> X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OMkIO06784 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 Magnus Westerlund wrote : > 24. Section A.1: Why is the extended sequence number initiated to the > middle of the space? Normally one would start with an extended sequence > number of 0. Shouldn't one try to be consistent with extended highest > sequence number received in the receiver reporting. For the detailed packet traces, reported upon by the Loss RLE blocks defined in the RTCP Extended Reports draft, we wish to make as few assumptions as possible regarding the packets that are observed. In particular, we wish to avoid making the assumptions made for basic RTCP: for instance, that a certain number of packets must be received in order for a source to be considered valid, or that a certain number of packets must be received in order to consider that a large jump in sequence numbers has occurred. These assumptions aid the functionality of RTCP, helping avoid errors in the receiver count, for instance. But they might mask the sort of anomalous events that one would wish to catch with extended reports. To address the particular question raised above, it is entirely possible that the sequence numbers could jump backwards. This could result in rollover in the 16-bit RTP sequence number space. To avoid rollover in the larger 32-bit extended sequence number space, we suggest starting roughly in the middle of that space. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 26 07:39:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23843 for ; Wed, 26 Mar 2003 07:39:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QCxrS25146 for avt-archive@odin.ietf.org; Wed, 26 Mar 2003 07:59:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCxGO25106; Wed, 26 Mar 2003 07:59:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCvEO24969 for ; Wed, 26 Mar 2003 07:57:14 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23732 for ; Wed, 26 Mar 2003 07:35:50 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QCbtbh025732; Wed, 26 Mar 2003 13:37:55 +0100 (MET) Received: from era.ericsson.se (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.2655.55) id HMMS4ST4; Wed, 26 Mar 2003 13:37:55 +0100 Message-ID: <3E819F22.8020807@era.ericsson.se> Date: Wed, 26 Mar 2003 13:37: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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Herlein CC: Jean-Marc Valin , Roger Hardiman , Simon Morlat , avt@ietf.org Subject: Re: [AVT] Speex payload discussion References: <200303242055.h2OKt1x10867@chiron.nge.isi.edu> 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 Colin Perkins wrote: >--> Greg Herlein writes: > > >>>The EVRC payload format addresses this by defining a simple format where >>>only a single frame is included in the packet, and a more complex format >>>which has a header and multiple frames. The signalling then selects which >>>of the two formats is used. This may be an acceptable solution here, too. >>> >>> >>Is it *that* bad a thing to just let the signalling define the >>number of frames in a packet in the first place, the way it's >>currently defined? >> >> > >No, it's just a little unusual. If there's no reason why a sender would >want to change the number of frames per packet, then signaling it out of >band is entirely appropriate. > > Yes, but there normally exist one very good reason why one wants to change the number of frames per packet, congestion control. For most low bit-rate codecs the simplest way of reducing the bit-rate is simple to reduce the number of packets sent. As the IP/UDP/RTP headers often represents a bit-rate of one or more complete audio streams. By sending two instead of one frame per packet the rate can often be reduced by 30%. However as this trade off often comes at the expense of less robustness and increased end-to-end delay one tries to avoid it if possible. Therefore it is reasonable to be able to change this on the fly. However if the Speex codec contains other mechanisms that are useful to change the bit-rate then it might not be necessary. An alternative way if to actually define different payload types when there might be need for different packetizations. Another point, if you have variable frame length how does one distinguish the end of one frame from the beginning of the next? If you don't have such a difference it will not be possible to demultiplex at the receiver. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 26 10:36:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01068 for ; Wed, 26 Mar 2003 10:36:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QFvQZ06852 for avt-archive@odin.ietf.org; Wed, 26 Mar 2003 10:57:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFubO06802; Wed, 26 Mar 2003 10:56:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFtEO06725 for ; Wed, 26 Mar 2003 10:55:14 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00926 for ; Wed, 26 Mar 2003 10:33:50 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QFaAbh029051 for ; Wed, 26 Mar 2003 16:36:10 +0100 (MET) Received: from era.ericsson.se (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.2655.55) id HMMSWNX9; Wed, 26 Mar 2003 16:36:11 +0100 Message-ID: <3E81C8EA.2020500@era.ericsson.se> Date: Wed, 26 Mar 2003 16:36:10 +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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] SDP signaling for RTCP XR format 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, Below is an proposal for an chapter on SDP signaling in the RTCP XR format. Please provide any comments as soon as possible. This will be included in the next revision of the draft. Best Regards Magnus Westerlund ------------------------------------------------------ 5. SDP Signaling This section defines a SDP attribute that can be used for signaling in applications utilizing SDP [s3]. This is signaling is defined to be used with Offer-Answer [s1] and for applications using SDP to describe media configurations, like in SAP [s4] and RTSP [s5]. There exist other potential signaling methods, which are not defined here. The RTCP XR formats MAY be used without prior signaling. This is in line with other RTCP packet types and follows the normal rules as written in [7]. All the reporting blocks defined in this document can be used without prior signaling. If any future defined report block does not allow usage without signaling, so should be noted and motivated in its specification. 5.1 The SDP attribute This section defines one new SDP attribute "rtcp-xr" that can be used to signal the participants in a media session that it should utilize any specified reporting format(s). This attribute can in the future be easily extended with new parameters to cover any new reporting formats. The RTCP XR format SDP attribute is defined as below in ABNF [s2]. It is an session and media level attribute. When specified at session level it applies to all media blocks part of the session. Any media level specification MUST replace an session level specification, if present, for that media block. rtcp-xr-attrib = "a=" "rtcp-xr" ":" xr-format *(SP xr-format) CRLF xr-format = pckt-loss-rle / dupp-rle / rcv-ts / stat-sum / rcv-rtt / voip-stat / format-ext pckt-loss-rle = "rle-pckt" ["=" 1*DIGIT] dupp-rle = "rle-dup" ["=" 1*DIGIT] rcv-ts = "recv-ts" ["=" 1*DIGIT] stat-sum = "stat-sum" recv-rtt = "recv-rtt" voip-stat = "voip-sum" format-ext = non-ws-string non-ws-string = 1*(%x21-FF) The "rtcp-xr" attribute contains one or more XR format related parameters. Each parameter defines its own interpretation as this will depend on the format(s). The attribute is extensible so that any future XR format block can define its own parameter(s). There may be formats where a "rtcp-xr" parameter is not applicable. However, for any future defined formats the need of a parameter should be evaluated. The defined "rtcp-xr" parameters belong to two categories. The first category corresponds to reporting formats that simple reports on the RTP stream and related things. The second category is formats that perform some type of functionality, like the RTT measuring functionality for a RTP receiver. This functionality uses two different XR formats, that together provide the functionality. For category 1, the reporting formats, this document defines the following parameters. The parameter names and their corresponding XR format is given in table 1. Parameter name XR format (Nr and Name) -------------------------- rle-pckt 1 Loss RLE Report Block rle-dup 2 Duplicate RLE Report Block recv-ts 3 Timestamp Report Block stat-sum 4 Statistics Summary Report Block voip-sum 7 VoIP Metrics Report Block Table 1. The category 1 parameters and their XR formats. The "rle-pckt", "rle-dup", and "recv-ts" parameters MAY all take specify an integer value. This value indicates the largest size the whole report block SHOULD have in bytes. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size. Category 2, consist of the RTT measuring formats using the XR formats "Receiver Timestamp Report Block" (5) and "DLRR Report Block" (6). These two formats and their functionality is represented by the "recv-rtt" parameter. 5.2 Usage in Offer-Answer When having reporting formats, it is in the interest of the sender of media, to request that the receiver sends reports on this media stream. However the interpretation will be dependent on any direction attribute. In the below definition, text applying for media stream with "sendrecv" attributes does also apply to media streams without any direction attribute. The definitions apply for media streams with a unicast destination, unless otherwise noted. For media streams in offers with a "sendonly" or a "sendrecv" attribute the inclusion of "rtcp-xr" attributes with parameters belonging to category 1, has the interpretation that the receiver of the offer SHOULD send the XR formats corresponding to the parameter to the sender of these streams. When doing the answer the answerer MAY include the rtcp-xr attribute with category 1 parameters for media streams with the "sendrecv" attribute to request that the offerer SHOULD send the corresponding XR formats from the offerer to the answerer. For media streams in offers with "recvonly" attribute the offerer MAY include a parameter to declare its capability of sending the corresponding XR formats. If the answerer includes a "rtcp-xr" attribute with an category 1 parameter the offerer SHOULD send the corresponding XR formats. For media streams with multicast destinations the inclusion of an rtcp-xr attribute with category 1 parameters means that any media recipient SHOULD send the corresponding XR formats in RTCP. For an SDP offer with media streams containing the "rtcp-xr" attribute with the "recv-rtt" parameter the offerer declares itself capable of receiving the "Receiver Timestamp Report Block" and send responses using the "DLRR Report Block". The answerer MAY also include the parameter (recv-rtt) and thereby declare its capability to receive and respond to the RTT measuring XR formats. The inclusion of the parameter does not require the receiver of an offer or answer to actually send any "Receiver Timestamp Report Block". Note that the usage of the Receiver Timestamp Report Block is only useful for a receiver only, as any media sender will have this functionality in the RTCP Sender Report packet type. For an SDP offer with media streams with multicast destinations containing the "rtcp-xr" attribute with the "recv-rtt" parameter the participants SHOULD respond with a "DLRR Report Block" to any received "Receiver Timestamp Report Block". A participant SHOULD NOT respond to a "Receiver Timestamp Report Block" if the parameter are not present in the offer. The answerer SHALL NOT add the "recv-rtt" parameter in a "rtcp-xr" attribute in any response for a media stream with multicast destination. 5.3 Usage out-side of Offer/Answer This applies to the usage of SDP that is currently defined in SAP and RTSP where SDP is used to declare what applies for a multi-media presentation. This SDP applies to how a receiver of these media streams shall behave to receive the media and under what rules. Therefore the usage of the "rtcp-xr" format is simpler in this case then compared to offer/answer, however the functionality goal is the same. For media streams having the "rtcp-xr" attribute with any category 1 parameter the receiver of this media stream SHOULD send the corresponding reports. If the attribute contains the "recv-rtt" parameter the recipient of the media stream MAY send "Receiver Timestamp Report Block". The receiver of an "Receiver Timestamp Report Block" SHOULD send a "DLRR Report Block" in response if and only if the "recv-rtt" parameter is present. 6. IANA Considerations This document defines a new RTCP packet type, the extended report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. Further this document defines a new SDP attribute "a=rtcp-xr" to be registered, and for its parameters a IANA registry is defined. 6.1 XR Packet Type The IANA SHALL register the RTP extended report (XR) packet defined by this document as packet type 207 in the registry of RTP RTCP Control Packet types (PT). 6.2 RTP XR Block Type Registry The IANA SHALL create the RTP XR Block Type Registry to cover the name space of the extended report block type (BT) field specified in Section 3 of this document. The BT field contains eight bits, allowing 256 values. The IANA SHALL manage the RTP XR Block Type Registry according to the Specification Required policy of RFC 2434 [6]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Timestamp Report Block 4 Statistics Summary Report Block 5 Receiver Timestamp Report Block 6 DLRR Report Block 7 VoIP Metrics Report Block The BT value 255 is reserved for future extensions. Furthermore, future specifications SHOULD avoid the value 0. Doing so facilitates packet validity checking, since an all-zeros field might commonly be found in an ill-formed packet. 6.3 The "rtcp-xr" SDP attribute One SDP attribute is to be registered using the below information: SDP Attribute ("att-field"): Attribute name: rtcp-xr Long form: RTP Extended Report Parameters Type of name: att-field Type of attribute: Session and Media level Subject to charset: No Purpose: See this document Reference: This document Values: See this document and registrations below The attribute has an extensible parameter field and therefore a registry for these parameters are needed. IANA is requested to create one RTCP-XR SDP parameter registry and register the defined values. This registry is managed according to the Specification Required policy of RFC 2434. Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - An ABNF definition of the parameter, in accordance with the "format-ext" definition. - A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer. This document registers the six parameters defined in chapter 5.1, "rle-pckt", "rle-dup", "recv-ts", "stat-sum", "voip-sum", and "recv- rtt". 7. Security Considerations This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports also apply to XR reports. This section details the additional security considerations that apply to the extensions. The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per- packet information contained in Loss RLE, Duplicate RLE, and Timestamp Report Blocks facilitates MINC inference of multicast distribution trees for RTP data packets, and inference of link characteristics such as loss and delay. This inference reveals information that might otherwise be considered confidential to autonomous system administrators. The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. No new mechanisms are introduced in this document to ensure confidentiality. Standard encryption procedures can be used when confidentiality is a concern to end hosts. Autonomous system administrators concerned about the loss of confidentiality regarding their networks can encrypt traffic, or filter it to exclude RTCP packets containing the XR report blocks concerned. Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets SHOULD NOT be encrypted or filtered. The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD limit the size of XR report blocks and employ the thinning techniques described in this document in order to fit reports into the space available. The usage of the SDP parameters defined affect the behavior of the RTCP XR format blocks. However the security implications are dependent on the report formats. Due to the fact that behavior can be changed by the SDP signaling, the SDP is RECOMMENDED to be authenticate to prevent tampering by intermediates. References The references are divided into normative references and non- normative references. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. [s2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Engineering Task Force, November 1997. [2] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000. [s3] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Internet Engineering Task Force, April 1998. [3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," best current practice BCP 11, RFC 2028, IETF, October 1996. [4] ITU-T, "The E-Model, a computational model for use in transmission planning," Recommendation G.107 (05/00), May 2000. [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, RFC 1700, IETF, October 1994. [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," best current practice BCP 26, RFC 2434, IETF, October 1998. [s1] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, Internet Engineering Task Force, June 2002. [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. Non-Normative References [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior," IEEE Communications Magazine, May 2000. [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu measurement infrastructures using RTP," Proc. IEEE Infocom 2002. [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2001. [s4] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC 2974, Internet Engineering Task Force, October 2000. [s5] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1998. [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Mar 26 11:20:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02473 for ; Wed, 26 Mar 2003 11:20:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGf8u10689 for avt-archive@odin.ietf.org; Wed, 26 Mar 2003 11:41:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGeAO10612; Wed, 26 Mar 2003 11:40:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGd6O10477 for ; Wed, 26 Mar 2003 11:39:06 -0500 Received: from mex.italtel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02404 for ; Wed, 26 Mar 2003 11:17:43 -0500 (EST) Received: .(localhost [127.0.0.1]) by mex.italtel.it (8.9.3/8.9.0) with ESMTP id RAA03434 for ; Wed, 26 Mar 2003 17:20:03 +0100 (MET) Received: from imads01.milano.italtel.it (imads01.milano.italtel.it [138.132.90.3]) by mix.italtel.it (8.9.3/8.9.3) with ESMTP id RAA02213 for ; Wed, 26 Mar 2003 17:20:02 +0100 (MET) Received: from imads01.milano.italtel.it (ic4dk4.settimo.italtel.it [138.132.81.105]) by imads01.milano.italtel.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FD64S3TY; Wed, 26 Mar 2003 17:20:01 +0100 Message-ID: <3E81D042.662CB80@imads01.milano.italtel.it> Date: Wed, 26 Mar 2003 17:07:30 +0100 From: Giuseppe Giordano Organization: Italtel X-Mailer: Mozilla 4.5 [it] (WinNT; I) X-Accept-Language: it MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] RTCP when remote member SDP is not available 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 I have a doubt about RTCP. Rfc 1889 says that RTCP reports should be sent even if a endpoint is receive only, or sendonly, that is in the case of a monodirectional connection. But, if I created a connection between 2 media gateways (unicast RTP session) by means of MGCP protocol in the following way: 1) CRCX message to the first gateway (endpoint A) cx mode = rcvonly remote session description: absent 2) Answer to the CRCX message with endpoin A local session description 3) CRCX message to the second gateway (endpoint B) cx mode = sendonly remote session description: present In this case, endpoint A must send RTCP reports to B? Endpoint A receives RTP packets from B. Can it use the RTP sender IP address to deliver RTCP packets? Thanks for the attention, best regards, Giuseppe Giordano _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Mar 27 10:30:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03395 for ; Thu, 27 Mar 2003 10:30:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RFpwb25917 for avt-archive@odin.ietf.org; Thu, 27 Mar 2003 10:51:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RFnVO25717; Thu, 27 Mar 2003 10:49:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RFiRO25494 for ; Thu, 27 Mar 2003 10:44:27 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02947 for ; Thu, 27 Mar 2003 10:22:33 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HCE007FUYQZX7@panasonic.de> for avt@ietf.org; Thu, 27 Mar 2003 16:23:27 +0100 (MET) Date: Thu, 27 Mar 2003 16:23:24 +0100 From: Jose Rey Subject: RE: [AVT] SDP signaling for RTCP XR format In-reply-to: <3E81C8EA.2020500@era.ericsson.se> To: Magnus Westerlund , IETF AVT WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=utf-8 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2RFiRO25495 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 Hi Magnus, I've got some comments/questions on your proposal... 1.- The term "RTCP XR format" to address the Loss RLE Report Block, Duplicate RLE ..., is not consistent with the rest of the draft. I prefer "XR blocks" which is used throghout the text. 2.- Just curious, why are the report blocks used without signalling? It would be helpful to include the reason for this in the draft (if it's not there already and I missed it) 3.- I like your classification of parameters because is needed afterwards to define the usage, however I don't understand your reasoning since both types of parameters define a functionality. Why not rename it to unilateral (category 1) and collaborative (category 2) or something alike? 4.- Section 5.2 par. 5: This is a bit confusing. The receiver may declare its capability for the XR blocks and not send the report blocks themselves? Shouldn't it be that by declaring its capability is also declaring its willingness to use them? Or is it maybe because the receiver decides itself when to send (them dynamically during the session) them and thus might be that they are not needed at all? Does this make sense? Maybe is the text that confuses me. thanks, José > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf > Of Magnus > Westerlund > Sent: Wednesday, March 26, 2003 4:36 PM > To: IETF AVT WG > Subject: [AVT] SDP signaling for RTCP XR format > > > Hi, > > Below is an proposal for an chapter on SDP signaling in the RTCP XR > format. Please provide any comments as soon as possible. This will be > included in the next revision of the draft. > > Best Regards > > Magnus Westerlund > > ------------------------------------------------------ > > 5. SDP Signaling > > This section defines a SDP attribute that can be used for signaling > in applications utilizing SDP [s3]. This is signaling is defined to > be used with Offer-Answer [s1] and for applications using SDP to > describe media configurations, like in SAP [s4] and RTSP > [s5]. There > exist other potential signaling methods, which are not > defined here. > > The RTCP XR formats MAY be used without prior signaling. This is in > line with other RTCP packet types and follows the normal rules as > written in [7]. All the reporting blocks defined in this > document can > be used without prior signaling. If any future defined report block > does not allow usage without signaling, so should be noted and > motivated in its specification. > > 5.1 The SDP attribute > > This section defines one new SDP attribute "rtcp-xr" that > can be used > to signal the participants in a media session that it > should utilize > any specified reporting format(s). This attribute can in the future > be easily extended with new parameters to cover any new reporting > formats. > > The RTCP XR format SDP attribute is defined as below in > ABNF [s2]. It > is an session and media level attribute. When specified at session > level it applies to all media blocks part of the session. Any media > level specification MUST replace an session level specification, if > present, for that media block. > > rtcp-xr-attrib = "a=" "rtcp-xr" ":" xr-format *(SP xr-format) CRLF > > xr-format = pckt-loss-rle > / dupp-rle > / rcv-ts > / stat-sum > / rcv-rtt > / voip-stat > / format-ext > > pckt-loss-rle = "rle-pckt" ["=" 1*DIGIT] > dupp-rle = "rle-dup" ["=" 1*DIGIT] > rcv-ts = "recv-ts" ["=" 1*DIGIT] > stat-sum = "stat-sum" > recv-rtt = "recv-rtt" > voip-stat = "voip-sum" > format-ext = non-ws-string > > non-ws-string = 1*(%x21-FF) > > The "rtcp-xr" attribute contains one or more XR format related > parameters. Each parameter defines its own interpretation as this > will depend on the format(s). The attribute is extensible > so that any > future XR format block can define its own parameter(s). > There may be > formats where a "rtcp-xr" parameter is not applicable. However, for > any future defined formats the need of a parameter should be > evaluated. > > The defined "rtcp-xr" parameters belong to two categories. > The first > category corresponds to reporting formats that simple > reports on the > RTP stream and related things. The second category is formats that > perform some type of functionality, like the RTT measuring > functionality for a RTP receiver. This functionality uses two > different XR formats, that together provide the functionality. > > For category 1, the reporting formats, this document defines the > following parameters. The parameter names and their > corresponding XR > format is given in table 1. > > Parameter name XR format (Nr and Name) > -------------------------- > rle-pckt 1 Loss RLE Report Block > rle-dup 2 Duplicate RLE Report Block > recv-ts 3 Timestamp Report Block > stat-sum 4 Statistics Summary Report Block > voip-sum 7 VoIP Metrics Report Block > > Table 1. The category 1 parameters and their XR formats. > > > The "rle-pckt", "rle-dup", and "recv-ts" parameters MAY all take > specify an integer value. This value indicates the largest size the > whole report block SHOULD have in bytes. This shall be seen as an > indication that thinning shall be applied if necessary to meet the > target size. > > Category 2, consist of the RTT measuring formats using the > XR formats > "Receiver Timestamp Report Block" (5) and "DLRR Report Block" (6). > These two formats and their functionality is represented by the > "recv-rtt" parameter. > > 5.2 Usage in Offer-Answer > > When having reporting formats, it is in the interest of > the sender of > media, to request that the receiver sends reports on this media > stream. However the interpretation will be dependent on > any direction > attribute. In the below definition, text applying for media stream > with "sendrecv" attributes does also apply to media streams without > any direction attribute. The definitions apply for media > streams with > a unicast destination, unless otherwise noted. > > For media streams in offers with a "sendonly" or a "sendrecv" > attribute the inclusion of "rtcp-xr" attributes with parameters > belonging to category 1, has the interpretation that the > receiver of > the offer SHOULD send the XR formats corresponding to the parameter > to the sender of these streams. When doing the answer the answerer > MAY include the rtcp-xr attribute with category 1 parameters for > media streams with the "sendrecv" attribute to request that the > offerer SHOULD send the corresponding XR formats from the > offerer to > the answerer. > > For media streams in offers with "recvonly" attribute the > offerer MAY > include a parameter to declare its capability of sending the > corresponding XR formats. If the answerer includes a "rtcp-xr" > attribute with an category 1 parameter the offerer SHOULD send the > corresponding XR formats. > > For media streams with multicast destinations the inclusion of an > rtcp-xr attribute with category 1 parameters means that any media > recipient SHOULD send the corresponding XR formats in RTCP. > > For an SDP offer with media streams containing the "rtcp-xr" > attribute with the "recv-rtt" parameter the offerer declares itself > capable of receiving the "Receiver Timestamp Report Block" and send > responses using the "DLRR Report Block". The answerer MAY also > include the parameter (recv-rtt) and thereby declare its capability > to receive and respond to the RTT measuring XR formats. > The inclusion > of the parameter does not require the receiver of an offer > or answer > to actually send any "Receiver Timestamp Report Block". > Note that the > usage of the Receiver Timestamp Report Block is only useful for a > receiver only, as any media sender will have this functionality in > the RTCP Sender Report packet type. > > For an SDP offer with media streams with multicast destinations > containing the "rtcp-xr" attribute with the "recv-rtt" > parameter the > participants SHOULD respond with a "DLRR Report Block" to any > received "Receiver Timestamp Report Block". A participant > SHOULD NOT > respond to a "Receiver Timestamp Report Block" if the parameter are > not present in the offer. The answerer SHALL NOT add the "recv-rtt" > parameter in a "rtcp-xr" attribute in any response for a > media stream > with multicast destination. > > > 5.3 Usage out-side of Offer/Answer > > This applies to the usage of SDP that is currently defined > in SAP and > RTSP where SDP is used to declare what applies for a multi-media > presentation. This SDP applies to how a receiver of these media > streams shall behave to receive the media and under what rules. > Therefore the usage of the "rtcp-xr" format is simpler in this case > then compared to offer/answer, however the functionality > goal is the > same. > > For media streams having the "rtcp-xr" attribute with any > category 1 > parameter the receiver of this media stream SHOULD send the > corresponding reports. If the attribute contains the "recv-rtt" > parameter the recipient of the media stream MAY send "Receiver > Timestamp Report Block". The receiver of an "Receiver Timestamp > Report Block" SHOULD send a "DLRR Report Block" in response if and > only if the "recv-rtt" parameter is present. > > > 6. IANA Considerations > > This document defines a new RTCP packet type, the extended report > (XR) type, within the existing Internet Assigned Numbers Authority > (IANA) registry of RTP RTCP Control Packet Types. This > document also > defines a new IANA registry: the registry of RTP XR Block Types. > Within this new registry, this document defines an initial set of > seven block types and describes how the remaining types are to be > allocated. Further this document defines a new SDP attribute > "a=rtcp-xr" to be registered, and for its parameters a > IANA registry > is defined. > > 6.1 XR Packet Type > > The IANA SHALL register the RTP extended report (XR) packet defined > by this document as packet type 207 in the registry of RTP RTCP > Control Packet types (PT). > > 6.2 RTP XR Block Type Registry > > The IANA SHALL create the RTP XR Block Type Registry to cover the > name space of the extended report block type (BT) field > specified in > Section 3 of this document. The BT field contains eight bits, > allowing 256 values. The IANA SHALL manage the RTP XR Block Type > Registry according to the Specification Required policy of RFC 2434 > [6]. Future specifications SHOULD attribute block type values in > strict numeric order following the values attributed in this > document: > > > BT name > -- ---- > 1 Loss RLE Report Block > 2 Duplicate RLE Report Block > 3 Timestamp Report Block > 4 Statistics Summary Report Block > 5 Receiver Timestamp Report Block > 6 DLRR Report Block > 7 VoIP Metrics Report Block > > > The BT value 255 is reserved for future extensions. > > Furthermore, future specifications SHOULD avoid the value 0. Doing > so facilitates packet validity checking, since an all-zeros field > might commonly be found in an ill-formed packet. > > 6.3 The "rtcp-xr" SDP attribute > > One SDP attribute is to be registered using the below information: > > SDP Attribute ("att-field"): > > Attribute name: rtcp-xr > Long form: RTP Extended Report Parameters > Type of name: att-field > Type of attribute: Session and Media level > Subject to charset: No > Purpose: See this document > Reference: This document > Values: See this document and registrations below > > The attribute has an extensible parameter field and therefore a > registry for these parameters are needed. IANA is > requested to create > one RTCP-XR SDP parameter registry and register the defined values. > This registry is managed according to the Specification Required > policy of RFC 2434. Any registration MUST contain the following > information: > > - Contact information of the one doing the registration, > including at > least name, address, and email. > > - An ABNF definition of the parameter, in accordance with the > "format-ext" definition. > > - A description of what the parameter represents and how > it shall be > interpreted, both normally and in Offer/Answer. > > This document registers the six parameters defined in chapter 5.1, > "rle-pckt", "rle-dup", "recv-ts", "stat-sum", "voip-sum", > and "recv- > rtt". > > > 7. Security Considerations > > This document extends the RTCP reporting mechanism. The security > considerations that apply to RTCP reports also apply to XR reports. > This section details the additional security considerations that > apply to the extensions. > > The extensions introduce heightened confidentiality concerns. > Standard RTCP reports contain a limited number of summary > statistics. > The information contained in XR reports is both more detailed and > more extensive (covering a larger number of parameters). The per- > packet information contained in Loss RLE, Duplicate RLE, and > Timestamp Report Blocks facilitates MINC inference of multicast > distribution trees for RTP data packets, and inference of link > characteristics such as loss and delay. This inference reveals > information that might otherwise be considered confidential to > autonomous system administrators. The VoIP Metrics Report Block > provides information on the quality of ongoing voice calls. Though > such information might be carried in application specific format in > standard RTP sessions, making it available in a standard > format here > makes it more available to potential eavesdroppers. > > No new mechanisms are introduced in this document to ensure > confidentiality. Standard encryption procedures can be used when > confidentiality is a concern to end hosts. Autonomous system > administrators concerned about the loss of confidentiality > regarding > their networks can encrypt traffic, or filter it to exclude RTCP > packets containing the XR report blocks concerned. > > Any encryption or filtering of XR report blocks entails a loss of > monitoring information to third parties. For example, a > network that > establishes a tunnel to encrypt VoIP Report Blocks denies that > information to the service providers traversed by the tunnel. The > service providers cannot then monitor or respond to the quality of > the VoIP calls that they carry, potentially creating > problems for the > network's users. As a default, XR packets SHOULD NOT be > encrypted or > filtered. > > The extensions also make certain denial of service attacks easier. > This is because of the potential to create RTCP packets much larger > than average with the per packet reporting capabilities of the Loss > RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the > automatic bandwidth adjustment mechanisms in RTCP, if some session > participants are sending large RTCP packets, all participants will > see their RTCP reporting intervals lengthened, meaning they will be > able to report less frequently. To limit the effects of large > packets, even in the absence of denial of service attacks, > applications SHOULD limit the size of XR report blocks and > employ the > thinning techniques described in this document in order to fit > reports into the space available. > > The usage of the SDP parameters defined affect the behavior of the > RTCP XR format blocks. However the security implications are > dependent on the report formats. Due to the fact that > behavior can be > changed by the SDP signaling, the SDP is RECOMMENDED to be > authenticate to prevent tampering by intermediates. > > > References > > The references are divided into normative references and non- > normative references. > > Normative References > > [1] S. Bradner, "Key words for use in RFCs to indicate requirement > levels," BCP 14, RFC 2119, IETF, March 1997. > > [s2] D. Crocker, P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, Internet Engineering Task Force, > November 1997. > > [2] ETSI, "Quality of Service (QoS) measurement > methodologies," ETSI > TS 101 329-5 V1.1.1 (2000-11), November 2000. > > [s3] M. Handley, V. Jacobson, "SDP: Session Description Protocol", > RFC 2327, Internet Engineering Task Force, April 1998. > > [3] R. Hovey and S. Bradner, "The Organizations Involved > in the IETF > Standards Process," best current practice BCP 11, RFC 2028, IETF, > October 1996. > > [4] ITU-T, "The E-Model, a computational model for use in > transmission planning," Recommendation G.107 (05/00), May 2000. > > [5] J. Reynolds and J. Postel, "Assigned Numbers," standard STD 2, > RFC 1700, IETF, October 1994. > > [6] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA > Considerations Section in RFCs," best current practice BCP 26, RFC > 2434, IETF, October 1998. > > [s1] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the > Session Description Protocol (SDP)", RFC 3264, Internet Engineering > Task Force, June 2002. > > [7] H. Schulzrinne, S. Casner, R. Frederick, and V. > Jacobson, "RTP: A > transport protocol for real-time applications," RFC 1889, IETF, > February 1996. > > Non-Normative References > > [8] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. > Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The > Use of End-to-End Multicast Measurements for > Characterizing Internal > Network Behavior," IEEE Communications Magazine, May 2000. > > [9] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu > measurement infrastructures using RTP," Proc. IEEE Infocom 2002. > > [10] A. D. Clark, "Modeling the Effects of Burst Packet Loss and > Recency on Subjective Voice Quality," Proc. IP Telephony Workshop > 2001. > > [s4] M. Handley, C. Perkins, E. Whelan, "Session Announcement > Protocol", RFC 2974, Internet Engineering Task Force, October 2000. > > [s5] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming > protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. > 1998. > > [11] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion > Control Framework for Heterogeneous Multicast Environments", Proc. > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Mar 31 03:03:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28757 for ; Mon, 31 Mar 2003 03:03:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V8QLc15588 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 03:26:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V8NOO15465; Mon, 31 Mar 2003 03:23:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V8IEO15270 for ; Mon, 31 Mar 2003 03:18:14 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28619 for ; Mon, 31 Mar 2003 02:54:34 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2V7uwrs012112; Mon, 31 Mar 2003 09:56:59 +0200 (MEST) Received: from era.ericsson.se (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.2655.55) id HKFZCFGV; Mon, 31 Mar 2003 09:56:59 +0200 Message-ID: <3E87F4CC.7080704@era.ericsson.se> Date: Mon, 31 Mar 2003 09:57:00 +0200 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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose Rey CC: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format References: Content-Type: text/plain; charset=UTF-8; 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 Jose, Thanks for giving some comments, it helps improving the text quickly. Responses below: Jose Rey wrote: >Hi Magnus, > >I've got some comments/questions on your proposal... > >1.- The term "RTCP XR format" to address the Loss RLE Report Block, Duplicate RLE ..., is not consistent with the rest of the draft. I prefer "XR blocks" which is used throghout the text. > Yes, I agree that I may not have used a totally aligned language. It should be corrected. >2.- Just curious, why are the report blocks used without signaling? It would be helpful to include the reason for this in the draft (if it's not there already and I missed it) > As I understand it the use case for having report blocks without signaling is that you know that you are using application foo. Foo has defined that we will use certain report blocks. Then it is not necessary to use the signaling, which may in fact not exist. Certain report blocks may be used to discover if the other end parts understand them. For example the RTT measurement can be tried a few times to see if any receiver responds to them. >3.- I like your classification of parameters because is needed afterwards to define the usage, however I don't understand your reasoning since both types of parameters define a functionality. Why not rename it to unilateral (category 1) and collaborative (category 2) or something alike? > Yes, good proposal. I will see what I can do about the text. >4.- Section 5.2 par. 5: This is a bit confusing. The receiver may declare its capability for the XR blocks and not send the report blocks themselves? Shouldn't it be that by declaring its capability is also declaring its willingness to use them? Or is it maybe because the receiver decides itself when to send (them dynamically during the session) them and thus might be that they are not needed at all? Does this make sense? Maybe is the text that confuses me. > > > The text might not be the best. However the functionality provided is that only the receiver can choice to use the Receiver Timestamp Report Block or not. The other end does only need to know if the other end part actually understands them and will respond with a DLRR Report block. If the other ends does not understand it is wasted bandwidth. Here one issue actually surface. Is it the right thing to restrict a receiver to not send DLRR report block unless the usage has been explicitly signaled in multicast? The reason why I see a need to restrict it is the potential to create enormous report blocks in large multicast groups. And the only result is that the different receivers will determine there RTT to other receivers which seems to be rather pointless in most application. It seems that you would in fact like to control this operation to a few different operation modes in multicast. 1. fully meshed, both senders and receivers return DLRR blocks. 2. Sender only, only senders return DLRR blocks. 3. functionality off, no one responds with DLRR blocks. Should we define such a distinction in the signaling? Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 08:43:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06157 for ; Mon, 31 Mar 2003 08:43:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VE6mv04271 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 09:06:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VE4lO04140; Mon, 31 Mar 2003 09:04:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VE3TO04088 for ; Mon, 31 Mar 2003 09:03:29 -0500 Received: from mail.pel.panasonic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06033 for ; Mon, 31 Mar 2003 08:39:42 -0500 (EST) Received: from atrgreyj (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HCM00K0F8NMER@panasonic.de> for avt@ietf.org; Mon, 31 Mar 2003 15:40:35 +0200 (MET DST) Date: Mon, 31 Mar 2003 15:40:36 +0200 From: Jose Rey Subject: RE: [AVT] SDP signaling for RTCP XR format In-reply-to: <3E87F4CC.7080704@era.ericsson.se> To: Magnus Westerlund Cc: IETF AVT WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=UTF-8 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VE3TO04089 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 Hi Magnus, please see inline: > >2.- Just curious, why are the report blocks used without > signaling? It would be helpful to include the reason for this > in the draft (if it's not there already and I missed it) > > > > As I understand it the use case for having report blocks without > signaling is that you know that you are using application > foo. Foo has > defined that we will use certain report blocks. Then it is > not necessary > to use the signaling, which may in fact not exist. Certain > report blocks > may be used to discover if the other end parts understand them. For > example the RTT measurement can be tried a few times to see if any > receiver responds to them. I think such a reasoning should be included in the text. The problem I see is that if someone is not aware of this fact, he could just download the SDP description and start a session. Since the offerer might "secretly" need some category1 parameters which the answerer is (of course) not providing as he wasn't requested to do so, the reception would be probably not of good quality, thus making a total waste of bandwidth out of the whole procedure... To solve this, why not declare some kind of attribute in SDP that defines the set of feedback messages that the application needs of? > > >3.- I like your classification of parameters because is > needed afterwards to define the usage, however I don't > understand your reasoning since both types of parameters > define a functionality. Why not rename it to unilateral > (category 1) and collaborative (category 2) or something alike? > > > > Yes, good proposal. I will see what I can do about the text. Good. > > >4.- Section 5.2 par. 5: This is a bit confusing. The > receiver may declare its capability for the XR blocks and not > send the report blocks themselves? Shouldn't it be that by > declaring its capability is also declaring its willingness to > use them? Or is it maybe because the receiver decides itself > when to send (them dynamically during the session) them and > thus might be that they are not needed at all? Does this make > sense? Maybe is the text that confuses me. > > > > > > > > The text might not be the best. However the functionality provided is > that only the receiver can choice to use the Receiver > Timestamp Report > Block or not. The other end does only need to know if the > other end part > actually understands them and will respond with a DLRR Report > block. If > the other ends does not understand it is wasted bandwidth. > I agree with the above. My comment was more that I think declarations in answers to category1-offers should be binding: if declared -> MUST be sent; if not declared -> MUST not be sent. Declarations in the offers just indicate the offerer SHOULD send them if supported, as it is now. For the category2 parameters it is different, since it is the receiver that benefits from such metrics, thus: if declared in the answer-> MAY be sent; if not declared -> MUST NOT be sent because the answerer does not wish to have such metrics. This is valid both unicast and multicast. Is this also your view? Would this work with the Offer/Answer model? > Here one issue actually surface. Is it the right thing to restrict a > receiver to not send DLRR report block unless the usage has been > explicitly signaled in multicast? The reason why I see a need to > restrict it is the potential to create enormous report blocks > in large > multicast groups. I disagree with your last sentence: RRs only report on RTP packets, not on RTCP. Thus, the size of the RRs would be equal, whether XRs are sent or not. It is only the number of RTCP packets ("traditional" and XR) that would be different. Still... a waste of bandwidth if it is not needed for every session member to know the RTT to every other one ... > And the only result is that the different receivers > will determine there RTT to other receivers which seems to be rather > pointless in most application. It seems that you would in > fact like to > control this operation to a few different operation modes in > multicast. > 1. fully meshed, both senders and receivers return DLRR blocks. > 2. Sender only, only senders return DLRR blocks. > 3. functionality off, no one responds with DLRR blocks. > > Should we define such a distinction in the signaling? Yes, I find this useful. The third one would be the one without rtcp-xr attribute in the offer (if you assume declaration/omission is binding). One more thing: how about the RTCP bandwidth sharing of the XR packets? how is, for example, the order of transmission defined relative to the "traditional" RTCP packets? I think this is not specified, a short comment would do like "the profile in use SHALL ensure that the RTCP bandwidth is equally shared by packets sent by this RTP server or sender". cheers, José _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 09:25:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07250 for ; Mon, 31 Mar 2003 09:25:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEn3e07683 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 09:49:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEmAO07630; Mon, 31 Mar 2003 09:48:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VElmO07584 for ; Mon, 31 Mar 2003 09:47:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07167 for ; Mon, 31 Mar 2003 09:24:00 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VEQPUE006873; Mon, 31 Mar 2003 16:26:25 +0200 (MEST) Received: from era.ericsson.se (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.2655.55) id 2A4KHSAL; Mon, 31 Mar 2003 16:26:26 +0200 Message-ID: <3E885013.4090804@era.ericsson.se> Date: Mon, 31 Mar 2003 16:26:27 +0200 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.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose Rey CC: IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format References: Content-Type: text/plain; charset=UTF-8; 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 Jose, Jose Rey wrote: >Hi Magnus, > >please see inline: > > > >>>2.- Just curious, why are the report blocks used without >>> >>> >>signaling? It would be helpful to include the reason for this >>in the draft (if it's not there already and I missed it) >> >> >>As I understand it the use case for having report blocks without >>signaling is that you know that you are using application >>foo. Foo has >>defined that we will use certain report blocks. Then it is >>not necessary >>to use the signaling, which may in fact not exist. Certain >>report blocks >>may be used to discover if the other end parts understand them. For >>example the RTT measurement can be tried a few times to see if any >>receiver responds to them. >> >> > >I think such a reasoning should be included in the text. The problem I see is that if someone is not aware of this fact, he could just download the SDP description and start a session. Since the offerer might "secretly" need some category1 parameters which the answerer is (of course) not providing as he wasn't requested to do so, the reception would be probably not of good quality, thus making a total waste of bandwidth out of the whole procedure... > > Yes, I will try to clarify this. My intention is that the SDP parameters should be used if there is SDP signaling available for this application. The one exception is that application foo always uses these reports. And since you are running the client for application foo it knows that it shall use the report formats. >To solve this, why not declare some kind of attribute in SDP that defines the set of feedback messages that the application needs of? > You mean in the general case for like SDES information types, etc.? >>>4.- Section 5.2 par. 5: This is a bit confusing. The >>> >>> >>receiver may declare its capability for the XR blocks and not >>send the report blocks themselves? Shouldn't it be that by >>declaring its capability is also declaring its willingness to >>use them? Or is it maybe because the receiver decides itself >>when to send (them dynamically during the session) them and >>thus might be that they are not needed at all? Does this make >>sense? Maybe is the text that confuses me. >> >> >>> >>> >>> >>> >>The text might not be the best. However the functionality provided is >>that only the receiver can choice to use the Receiver >>Timestamp Report >>Block or not. The other end does only need to know if the >>other end part >>actually understands them and will respond with a DLRR Report >>block. If >>the other ends does not understand it is wasted bandwidth. >> >> >> > >I agree with the above. My comment was more that I think declarations in answers to category1-offers should be binding: if declared -> MUST be sent; if not declared -> MUST not be sent. Declarations in the offers just indicate the offerer SHOULD send them if supported, as it is now. > I think SHOULD is a good requirement levels for something that is simply information. If you have very good reason not to send a report format you should not be forced to do it. However you should have really good reasons before you don't. When it comes to the other direction I might be more willingly to adopt a MUST NOT send policy. The question is how you can make it work with the MAY at top level. Some better language may solve this. I also need to consider what implications this have in interactions with clients not understanding the attribute. Probably no problem as they will not send it. >For the category2 parameters it is different, since it is the receiver that benefits from such metrics, thus: if declared in the answer-> MAY be sent; if not declared -> MUST NOT be sent because the answerer does not wish to have such metrics. This is valid both unicast and multicast. Is this also your view? Would this work with the Offer/Answer model? > > Yes, it is my view. So far I don't see any problems in Offer/Answer usage. Please think this trough one more time. > > > >>Here one issue actually surface. Is it the right thing to restrict a >>receiver to not send DLRR report block unless the usage has been >>explicitly signaled in multicast? The reason why I see a need to >>restrict it is the potential to create enormous report blocks >>in large >>multicast groups. >> >> > >I disagree with your last sentence: RRs only report on RTP packets, not on RTCP. Thus, the size of the RRs would be equal, whether XRs are sent or not. It is only the number of RTCP packets ("traditional" and XR) that would be different. Still... a waste of bandwidth if it is not needed for every session member to know the RTT to every other one ... > > No, I think you are missing one thing where the DLRR blocks can become enormous. If you are part of an ASM group with 100 participants and they all send the Receiver Timestamp block in there RTCP reports. Normally you will send on average at the same pace as all others. Therefore your DLRR response will contain 100 sources. As everybody is doing this the average RTCP size will be large. Therefore the usage of option 1 below seems to be limited to small groups. When using option 2 only a few out of all sending the Receiver Timestamp block actually answers with the delay information. Therefore only the sender reporting will be effected by this. > > >>And the only result is that the different receivers >>will determine there RTT to other receivers which seems to be rather >>pointless in most application. It seems that you would in >>fact like to >>control this operation to a few different operation modes in >>multicast. >>1. fully meshed, both senders and receivers return DLRR blocks. >>2. Sender only, only senders return DLRR blocks. >>3. functionality off, no one responds with DLRR blocks. >> >>Should we define such a distinction in the signaling? >> >> > >Yes, I find this useful. The third one would be the one without rtcp-xr attribute in the offer (if you assume declaration/omission is binding). > > >One more thing: how about the RTCP bandwidth sharing of the XR packets? how is, for example, the order of transmission defined relative to the "traditional" RTCP packets? I think this is not specified, a short comment would do like "the profile in use SHALL ensure that the RTCP bandwidth is equally shared by packets sent by this RTP server or sender". > > Are you meaning the sharing of bandwidth between different RTCP packet types? And also within a XR packet that the different blocks are sent not all the time? The first problem is that the RTCP compound packet can reach the MTU and some packets has to be excluded. I think round robin in that case is a reasonable strategy if not defined elsewhere. This would mean equal share for all non mandatory packets. I think the same strategy can be used within a XR packet to ensure that all types of report blocks may send. However looking at the block types that can be sent that has variable size I has proposed a way of limiting the packet size. I think such a limitation should also be possible to defined for the DLRR packet. I hesitant to write policy that actually is application or profile dependent. However defining a default behavior I find acceptable with a side note that this can be replaced by application or profile specifications. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 10:46:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11908 for ; Mon, 31 Mar 2003 10:46:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VGA3D14712 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 11:10:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VG9OO14606; Mon, 31 Mar 2003 11:09:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VG8JO14481 for ; Mon, 31 Mar 2003 11:08:19 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11774 for ; Mon, 31 Mar 2003 10:44:27 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h2VFkivm002320; Mon, 31 Mar 2003 10:46:45 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200303311546.h2VFkivm002320@purple.nge.isi.edu> To: Magnus Westerlund cc: Jose Rey , IETF AVT WG Subject: Re: [AVT] SDP signaling for RTCP XR format In-Reply-To: Your message of "Mon, 31 Mar 2003 09:57:00 +0200." <3E87F4CC.7080704@era.ericsson.se> Date: Mon, 31 Mar 2003 10:46:44 -0500 From: Colin Perkins 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: ... >>2.- Just curious, why are the report blocks used without signaling? It >>would be helpful to include the reason for this in the draft (if it's not >>there already and I missed it) > >As I understand it the use case for having report blocks without >signaling is that you know that you are using application foo. Foo has >defined that we will use certain report blocks. Then it is not necessary >to use the signaling, which may in fact not exist. Certain report blocks >may be used to discover if the other end parts understand them. For >example the RTT measurement can be tried a few times to see if any >receiver responds to them. RTP allows applications to send new types of RTCP packet, even if these are not explicitly signalled. RTCP XR shouldn't impose additional restrictions. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 15:29:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23201 for ; Mon, 31 Mar 2003 15:29:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VKr3N15957 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 15:53:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VKqNK15932; Mon, 31 Mar 2003 15:52:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VKjTK15631 for ; Mon, 31 Mar 2003 15:45:29 -0500 Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22892 for ; Mon, 31 Mar 2003 15:21:34 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h2VKN9G11842 for avt@ietf.org; Mon, 31 Mar 2003 12:23:09 -0800 Date: Mon, 31 Mar 2003 12:23:09 -0800 From: John Lazzaro Message-Id: <200303312023.h2VKN9G11842@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Interesting effort out of P1394 ... 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 everyone, New effort in the IEEE of possible interest to AVT folks: http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.033103/230905415 Running IEEE 1394 over the 1000baseT physical layer, with negotiations to switch the wire between Ethernet and IEEE P1394 layer 2. Intended for audio and video, but since 1394 has a MIDI payload already, this would be a third way to send MIDI out of a RJ-45 socket (MWPP over RTP over IP, DMIDI over Layer 2 Ethernet, and IEEE 1394 over the physical layer for 1000baseT). ------------------------------------------------------------------------- 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 mailnull@www1.ietf.org Mon Mar 31 16:06:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24567 for ; Mon, 31 Mar 2003 16:06:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VLTbS18227 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 16:29:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VLTCK18209; Mon, 31 Mar 2003 16:29:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VLMWK17941 for ; Mon, 31 Mar 2003 16:22:32 -0500 Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24070 for ; Mon, 31 Mar 2003 15:58:35 -0500 (EST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h2VL0xqq014938 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Mon, 31 Mar 2003 23:00:59 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with SMTP id h2VL0xp16631; Mon, 31 Mar 2003 23:00:59 +0200 (CEST) Message-ID: <00cc01c2f7b7$dd92daa0$a648e384@lip6.fr> From: "Timur Friedman" To: "Magnus Westerlund" , "Colin Perkins" Cc: "Jose Rey" , "IETF AVT WG" References: <200303311546.h2VFkivm002320@purple.nge.isi.edu> Subject: Re: [AVT] SDP signaling for RTCP XR format Date: Mon, 31 Mar 2003 21:00:57 +0200 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: isis.lip6.fr 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 Perkins wrote: > --> Magnus Westerlund writes: > ... > >>2.- Just curious, why are the report blocks used without signaling? It > >>would be helpful to include the reason for this in the draft (if it's not > >>there already and I missed it) > > > >As I understand it the use case for having report blocks without > >signaling is that you know that you are using application foo. Foo has > >defined that we will use certain report blocks. Then it is not necessary > >to use the signaling, which may in fact not exist. Certain report blocks > >may be used to discover if the other end parts understand them. For > >example the RTT measurement can be tried a few times to see if any > >receiver responds to them. > > RTP allows applications to send new types of RTCP packet, even if these are > not explicitly signalled. RTCP XR shouldn't impose additional restrictions. The draft will be sure to specify that SDP signalling is an optional mechanism, to avoid any confusion. - Timur _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 17:17:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28041 for ; Mon, 31 Mar 2003 17:17:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VMeZQ24189 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 17:40:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VMe4K24142; Mon, 31 Mar 2003 17:40:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VMaoK23236 for ; Mon, 31 Mar 2003 17:36:50 -0500 Received: from f1ee40-19.idc1.level3.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27883 for ; Mon, 31 Mar 2003 17:12:51 -0500 (EST) Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with SMTP id WAA18559 for ; Mon, 31 Mar 2003 22:15:17 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 31 Mar 2003 15:15:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 31 Mar 2003 15:15:16 -0700 Message-ID: <3DB099919328BA41905F651A6EF8397608CD5A@idc1exc0004.corp.global.level3.com> Thread-Topic: [AVT] Interesting effort out of P1394 ... Thread-Index: AcL3xPbN1S24RcrVSKm/n9F2O4fIVQACyRQA From: "Hashmi, Mohamed Hadi" To: X-OriginalArrivalTime: 31 Mar 2003 22:15:16.0759 (UTC) FILETIME=[023E4270:01C2F7D3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VMaoK23237 Subject: [AVT] Couple of clarifications on RFC2833 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 Question-1 the RFC 2833, section 3.6 states the following "If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly." What this "corresponding" mean? Does it mean that all the RTP packets related to that event should use the SAME timestamp as that of its first packet or does it mean that timestamp for next packet= timestamp of the first packet + duration of event? I have seen some implementations where all the RTP packets for one specific DTMF event use the timestamp as that of first packet. But this creates an interesting situation where audio RTP packets will have latest time stamp and then we have DTMF RTP packet carrying a previous timestamp. Since sequence number are incremented sequentially for both audio as well dtmf RTP packets, the dtmf packets with higher sequence number will have smaller timestamp value compared to an audio RTP packet with smaller sequence number. Question-2 While using inband DTMF detection the sequence numbers are incremented by "one" for every packet sent by the media gateway for that call whether they are dtmf or audio. That means in an RTP stream for example , sequence numbers 5,8,9,10,11 could belong to a DTMF event RTP packets while 1,2,3,4,6,7,12,13 to audio RTP packets. This is perfectly alright with in-band DTMF detection. How should the sequence numbers be assigned for out-of-band DTMF detection? As in this case there would be two RTP stream going to different IP address /port, one for audio and another one for DTMF. If sequence numbers are assigned as above then both audio receivers as well as DTMF receiver are going to get gaps in sequence numbers ? Or should there be one set of sequence numbers for audio stream and another for DTMF stream? Will appreciate any clarification on these Thanks Hadi _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 18:10:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00930 for ; Mon, 31 Mar 2003 18:10:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VNUcU26745 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 18:30:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNTEK26697; Mon, 31 Mar 2003 18:29:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNSTK26652 for ; Mon, 31 Mar 2003 18:28:29 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00171 for ; Mon, 31 Mar 2003 18:04:31 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h2VN6pn02859; Mon, 31 Mar 2003 18:06:51 -0500 Message-Id: <200303312306.h2VN6pn02859@chiron.nge.isi.edu> To: "Hashmi, Mohamed Hadi" cc: avt@ietf.org Subject: Re: [AVT] Couple of clarifications on RFC2833 In-Reply-To: Your message of "Mon, 31 Mar 2003 15:15:16 MST." <3DB099919328BA41905F651A6EF8397608CD5A@idc1exc0004.corp.global.level3.com> Date: Mon, 31 Mar 2003 18:06:51 -0500 From: Colin Perkins 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: , --> "Hashmi, Mohamed Hadi" writes: >Question-1 > >the RFC 2833, section 3.6 states the following > >"If an event continues for more than one period, the source generating the >events should send a new event packet with the RTP timestamp value >corresponding to the beginning of the event and the duration of the event >increased correspondingly." > >What this "corresponding" mean? Does it mean that all the RTP packets >related to that event should use the SAME timestamp as that of its first >packet or does it mean that timestamp for next packet timestamp of the >first packet + duration of event? My understanding is that all the packets comprising a single event have the same timestamp. The second (and subsequent) packets have the same timestamp as the first packet, but increased duration fields. >I have seen some implementations where all the RTP packets for one specific >DTMF event use the timestamp as that of first packet. But this creates an >interesting situation where audio RTP packets will have latest time stamp >and then we have DTMF RTP packet carrying a previous timestamp. Since >sequence number are incremented sequentially for both audio as well dtmf >RTP packets, the dtmf packets with higher sequence number will have >smaller timestamp value compared to an audio RTP packet with smaller >sequence number. So? RTP does not mandate that packets are sent in order of increasing timestamp. >Question-2 > >While using inband DTMF detection the sequence numbers are incremented by >"one" for every packet sent by the media gateway for that call whether they >are dtmf or audio. That means in an RTP stream for example , sequence >numbers 5,8,9,10,11 could belong to a DTMF event RTP packets while 1,2,3, >4,6,7,12,13 to audio RTP packets. This is perfectly alright with in-band >DTMF detection. > >How should the sequence numbers be assigned for out-of-band DTMF >detection? As in this case the re would be two RTP stream going to >different IP address /port, one for audio and another one for DTMF. If >sequence numbers are assigned as above then both audio receivers as well as >DTMF receiver are going to get gaps in sequence numbers ? Or should there >be one set of sequence numbers for audio stream and another for DTMF >stream? If there are two separate RTP streams, they each have their own sequence number space. Accordingly, you'd use one set of sequence numbers for audio stream and another for DTMF stream. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 18:32:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02492 for ; Mon, 31 Mar 2003 18:32:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VNuJM28550 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 18:56:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNqrK28362; Mon, 31 Mar 2003 18:52:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNpiK28308 for ; Mon, 31 Mar 2003 18:51:44 -0500 Received: from f1ee40-19.idc1.level3.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02264 for ; Mon, 31 Mar 2003 18:27:45 -0500 (EST) Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with SMTP id XAA11766; Mon, 31 Mar 2003 23:30:04 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 31 Mar 2003 16:30:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AVT] Couple of clarifications on RFC2833 Date: Mon, 31 Mar 2003 16:30:01 -0700 Message-ID: <3DB099919328BA41905F651A6EF839767A478B@idc1exc0004.corp.global.level3.com> Thread-Topic: [AVT] Couple of clarifications on RFC2833 Thread-Index: AcL32jo1UB0A5NkmSYirn65o6kCz0wAAo3Qw From: "Hashmi, Mohamed Hadi" To: "Colin Perkins" Cc: X-OriginalArrivalTime: 31 Mar 2003 23:30:02.0085 (UTC) FILETIME=[73B4B150:01C2F7DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VNpiK28309 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 Colin, Thanks for you quick answers. >So? RTP does not mandate that packets are sent in order of increasing >timestamp. This can potentially impact the inter arrival jitter calculation and also latency. The way to overcome this problem will be to ignore DTMF packets >If there are two separate RTP streams, they each have their own sequence >number space. Accordingly, you'd use one set of sequence numbers for audio >.stream and another for DTMF stream. Is this observation based on RFC1889 or is this explicitly stated in RFC2833? I mean how do I convince a vendor that this is how it is supposed to be done? Thanks Hadi -----Original Message----- From: Colin Perkins [mailto:csp@isi.edu] Sent: Monday, March 31, 2003 4:07 PM To: Hashmi, Mohamed Hadi Cc: avt@ietf.org Subject: Re: [AVT] Couple of clarifications on RFC2833 --> "Hashmi, Mohamed Hadi" writes: >Question-1 > >the RFC 2833, section 3.6 states the following > >"If an event continues for more than one period, the source generating the >events should send a new event packet with the RTP timestamp value >corresponding to the beginning of the event and the duration of the event >increased correspondingly." > >What this "corresponding" mean? Does it mean that all the RTP packets >related to that event should use the SAME timestamp as that of its first >packet or does it mean that timestamp for next packet timestamp of the >first packet + duration of event? My understanding is that all the packets comprising a single event have the same timestamp. The second (and subsequent) packets have the same timestamp as the first packet, but increased duration fields. >I have seen some implementations where all the RTP packets for one specific >DTMF event use the timestamp as that of first packet. But this creates an >interesting situation where audio RTP packets will have latest time stamp >and then we have DTMF RTP packet carrying a previous timestamp. Since >sequence number are incremented sequentially for both audio as well dtmf >RTP packets, the dtmf packets with higher sequence number will have >smaller timestamp value compared to an audio RTP packet with smaller >sequence number. So? RTP does not mandate that packets are sent in order of increasing timestamp. This can potentially impact the inter arrival jitter calculation and also latency >Question-2 > >While using inband DTMF detection the sequence numbers are incremented by >"one" for every packet sent by the media gateway for that call whether they >are dtmf or audio. That means in an RTP stream for example , sequence >numbers 5,8,9,10,11 could belong to a DTMF event RTP packets while 1,2,3, >4,6,7,12,13 to audio RTP packets. This is perfectly alright with in-band >DTMF detection. > >How should the sequence numbers be assigned for out-of-band DTMF >detection? As in this case the re would be two RTP stream going to >different IP address /port, one for audio and another one for DTMF. If >sequence numbers are assigned as above then both audio receivers as well as >DTMF receiver are going to get gaps in sequence numbers ? Or should there >be one set of sequence numbers for audio stream and another for DTMF >stream? If there are two separate RTP streams, they each have their own sequence number space. Accordingly, you'd use one set of sequence numbers for audio stream and another for DTMF stream. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Mar 31 22:48:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09230 for ; Mon, 31 Mar 2003 22:48:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h314C8u13023 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 23:12:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h314ARK12976; Mon, 31 Mar 2003 23:10:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3146dK12110 for ; Mon, 31 Mar 2003 23:06:39 -0500 Received: from gateway.blr.dlink.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09153 for ; Mon, 31 Mar 2003 22:42:30 -0500 (EST) Received: from bino (localhost [127.0.0.1]) by gateway.blr.dlink.com (8.11.0/8.11.0) with SMTP id h313qG116868; Tue, 1 Apr 2003 09:22:16 +0530 Message-ID: <004601c2f66f$5a63fc20$8964a8c0@bino> From: "Bino George" To: "Hashmi, Mohamed Hadi" Cc: References: <3DB099919328BA41905F651A6EF8397608CD5A@idc1exc0004.corp.global.level3.com> Subject: Re: [AVT] Couple of clarifications on RFC2833 Date: Sun, 30 Mar 2003 09:19:23 +0530 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Hello Hashmi: This issue is discussed a lot in this mailing list. Please scan through the mailing list or google for "RFC2833 + Confusions" Ex: http://www1.ietf.org/mail-archive/working-groups/avt/current/msg01693.html Finally, Please read my comments also. ----- Original Message ----- From: Hashmi, Mohamed Hadi To: Sent: Tuesday, April 01, 2003 3:45 AM Subject: [AVT] Couple of clarifications on RFC2833 > ----------------------------------------- (on the network)---------------- > > email-body was scanned and no virus found > -----------------------------------------D-Link R & D E-Mail Traffic----------- > ---------------------------------------------------------------------------- ---- Question-1 the RFC 2833, section 3.6 states the following "If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly." What this "corresponding" mean? Does it mean that all the RTP packets related to that event should use the SAME timestamp as that of its first packet or does it mean that timestamp for next packet= timestamp of the first packet + duration of event? Bino: Please visualize the DTMF events starting from a RTP TS and after that the DTMF event packet will represent its duration. If you really want a notion of Current RTP TS you can add up Events Starting RTP TS + Duration. I have seen some implementations where all the RTP packets for one specific DTMF event use the timestamp as that of first packet. But this creates an interesting situation where audio RTP packets will have latest time stamp and then we have DTMF RTP packet carrying a previous timestamp. Since sequence number are incremented sequentially for both audio as well dtmf RTP packets, the dtmf packets with higher sequence number will have smaller timestamp value compared to an audio RTP packet with smaller sequence number. Bino: Logic is very simple. Read session 3.2 ( Simultaneous Generation of Audio and Events) and read RFC 2198 (RTP Payload for Redundant Audio Data). Otherwise go ahead with a simple solution, support only outofband DTMF or inband DTMF. This will dramatically improve the interoperability of your device. Question-2 While using inband DTMF detection the sequence numbers are incremented by "one" for every packet sent by the media gateway for that call whether they are dtmf or audio. That means in an RTP stream for example , sequence numbers 5,8,9,10,11 could belong to a DTMF event RTP packets while 1,2,3,4,6,7,12,13 to audio RTP packets. This is perfectly alright with in-band DTMF detection. How should the sequence numbers be assigned for out-of-band DTMF detection? As in this case there would be two RTP stream going to different IP address /port, one for audio and another one for DTMF. If sequence numbers are assigned as above then both audio receivers as well as DTMF receiver are going to get gaps in sequence numbers ? Or should there be one set of sequence numbers for audio stream and another for DTMF stream? Will appreciate any clarification on these Bino: Please read RFC 2198 (RTP Payload for Redundant Audio Data). Thanks Hadi _______________________________________________ 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 mailnull@www1.ietf.org Mon Mar 31 23:00:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09375 for ; Mon, 31 Mar 2003 23:00:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h314NvH13375 for avt-archive@odin.ietf.org; Mon, 31 Mar 2003 23:23:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h314MTK13312; Mon, 31 Mar 2003 23:22:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h314K9K13258 for ; Mon, 31 Mar 2003 23:20:09 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09328 for ; Mon, 31 Mar 2003 22:56:04 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h313wOvm003870; Mon, 31 Mar 2003 22:58:24 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304010358.h313wOvm003870@purple.nge.isi.edu> To: "Hashmi, Mohamed Hadi" cc: avt@ietf.org Subject: Re: [AVT] Couple of clarifications on RFC2833 In-Reply-To: Your message of "Mon, 31 Mar 2003 16:30:01 MST." <3DB099919328BA41905F651A6EF839767A478B@idc1exc0004.corp.global.level3.com> Date: Mon, 31 Mar 2003 22:58:24 -0500 From: Colin Perkins 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: , --> "Hashmi, Mohamed Hadi" writes: >Colin, > > >Thanks for you quick answers. > >>So? RTP does not mandate that packets are sent in order of increasing >>timestamp. > >This can potentially impact the inter arrival jitter calculation and also >latency. The way to over come this problem will be to ignore DTMF packets It can affect the jitter calculation (there is a similar issue when video frames are split across multiple RTP packets). The latency should not be affected, if you design the playout buffer appropriately. >>If there are two separate RTP streams, they each have their own sequence >>number space. Accordingly, you'd use one set of sequence numbers for audio >>.stream and another for DTMF stream. > >Is this observation based on RFC1889 or is this explicitly stated in >RFC2833? I mean how do I convince a vendor that this is how it is supposed >to be done? It's standard RTP behaviour. If you share a sequence number space across multiple sessions, sent to different locations, you cannot tell if there was loss. Hence you should use separate sequence number spaces for each RTP session. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt