From exim@www1.ietf.org Mon Jan 5 08:26:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17045 for ; Mon, 5 Jan 2004 08:26:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdUjc-0002yM-OL for avt-archive@odin.ietf.org; Mon, 05 Jan 2004 08:25:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05DPW8L011381 for avt-archive@odin.ietf.org; Mon, 5 Jan 2004 08:25:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdUj8-0002wz-LN; Mon, 05 Jan 2004 08:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdUio-0002w4-Ge for avt@optimus.ietf.org; Mon, 05 Jan 2004 08:24:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17019 for ; Mon, 5 Jan 2004 08:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdUid-0002jw-00 for avt@ietf.org; Mon, 05 Jan 2004 08:24:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdUg2-0002bk-00 for avt@ietf.org; Mon, 05 Jan 2004 08:21:52 -0500 Received: from [209.172.119.195] (helo=scha24.neomagic.com) by ietf-mx with esmtp (Exim 4.12) id 1AdUa5-0002Ls-00 for avt@ietf.org; Mon, 05 Jan 2004 08:15:41 -0500 Received: from scha21.neomagic.com (scha21.neomagic.com [192.168.51.21]) by scha24.neomagic.com (8.12.5/8.12.5) with ESMTP id i05EE28l006976 for ; Mon, 5 Jan 2004 06:14:02 -0800 Received: from neomagic.com ([192.168.31.247]) by scha21.neomagic.com (8.12.5/8.12.5) with ESMTP id i05DGm4U025670 for ; Mon, 5 Jan 2004 05:16:49 -0800 Message-ID: <3FF96823.5080608@neomagic.com> Date: Mon, 05 Jan 2004 19:05:31 +0530 From: B Prashanth Reply-To: B Prashanth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] AMR Profile Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear All, Can anyone please tell me that if RTP stack is sending AMR speech data then does the encoded AMR payload, i.e. the AMR speech frame, contain the AMR frame header (specifying the Frame type) or Does the AMR speech frame contain just the raw, encoded speech data in the form of Class A, B and C bits? Please note that the header being talked about here is the AMR speech frame's header and not the RTP's AMR profile header (Specified in RFC 3267). -- Prashanth B.P. Sr. Design Engr. NeoMagic Design Center. Polyplex Building, First Floor B-37 Sector 1 Noida INDIA 201301 E-Mail: bprashanth@neomagic.com Tel: +91-120-2536205/6 Extn:4103 Fax: +91-120-2536207 NeoMagic Corporation, based in Santa Clara, California, provides Applications Processors to enable new generations of handheld systems, offering the lowest power, smallest form-factor, and best multimedia features and performance. The company has pioneered the integration of memory, complex logic, and analog circuits into single-chip solutions. URL: http://www.neomagic.com. -- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 7 16:33:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03355 for ; Wed, 7 Jan 2004 16:33:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLIk-0002md-MB for avt-archive@odin.ietf.org; Wed, 07 Jan 2004 16:33:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07LXIeV010696 for avt-archive@odin.ietf.org; Wed, 7 Jan 2004 16:33:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeLIS-0002li-O1; Wed, 07 Jan 2004 16:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae2g7-0004hh-F4 for avt@optimus.ietf.org; Tue, 06 Jan 2004 20:40:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15607 for ; Tue, 6 Jan 2004 20:40:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae2g5-0005WY-00 for avt@ietf.org; Tue, 06 Jan 2004 20:40:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae2eC-0005Ob-00 for avt@ietf.org; Tue, 06 Jan 2004 20:38:12 -0500 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1Ae2cJ-0005Gt-00 for avt@ietf.org; Tue, 06 Jan 2004 20:36:15 -0500 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i071aFUX005434 for ; Tue, 6 Jan 2004 17:36:15 -0800 (PST) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i071aE9L021340 for ; Tue, 6 Jan 2004 17:36:14 -0800 (PST) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HR3J4C00.J38 for ; Tue, 6 Jan 2004 17:36:12 -0800 Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: avt@ietf.org From: "John Lazzaro" Date: Tue, 6 Jan 2004 17:36:12 -0800 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=SUBJ_ALL_CAPS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] RTP MIDI ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi everyone, From Colin's IETF 58 minutes, on RTP MIDI: > John Lazzaro plans to ensure he has finished his implementation > before requesting working group last call to catch any final bugs in > the specification. However, he expects to have finished this by the > end of the year. Came close, but not quite done yet -- on the bright side, running C now exists for all recovery journal chapters (channel and system), with most of the bitfield format features exercised (some were just too painful to fit into sfront's code base), and no major issues were found. Many smaller issues were caught --"if you do not test it, it does not work", as they say in the chip design world. A few more weeks of continuity work is needed -- going back and forth between reading 40K lines of C code and 160 pages of I-D, to see if any issues remain that fell through the cracks ... --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 7 18:27:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13180 for ; Wed, 7 Jan 2004 18:27:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeN4r-0000Hd-Pi for avt-archive@odin.ietf.org; Wed, 07 Jan 2004 18:27:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07NR5gD001088 for avt-archive@odin.ietf.org; Wed, 7 Jan 2004 18:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeN4m-0000H0-Fi; Wed, 07 Jan 2004 18:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeN4d-0000Gi-3w for avt@optimus.ietf.org; Wed, 07 Jan 2004 18:26:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13160 for ; Wed, 7 Jan 2004 18:26:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeN4G-0007aj-00 for avt@ietf.org; Wed, 07 Jan 2004 18:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeN0E-0007T9-00 for avt@ietf.org; Wed, 07 Jan 2004 18:22:19 -0500 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AeMv9-0007Fd-00 for avt@ietf.org; Wed, 07 Jan 2004 18:17:03 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i07NACD5022436 for ; Wed, 7 Jan 2004 17:16:06 -0600 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3FBBC62E0102C919 for avt@ietf.org; Wed, 7 Jan 2004 18:15:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jan 2004 17:16:06 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA37B4@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Thread-Index: AcPVaKDiYUzLONTNTZa3axUxiFsPgQABzgVQ From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable All, Please review and comment on the current draft of 'Requirements for = ECRTP over MPLS' = http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-00= .txt. As agreed at IETF-58 and on the list, the main changes are as follows: 1. focus on requirements for ECRTP over MPLS (defer other requirements = until later). 2. eliminate MPLS jargon such as CE, PE, etc., just talk about routers = R1, R2, etc. 3. eliminate absolute performance objectives and simply state the = requirement to 'minimize delta degradation'. 4. eliminate absolute scalability requirements, and simply state the = goal to improve scalability of the number of compressed flows that can = be handled. There was considerable discussion of the previous draft at IETF-58 (see = the AVT meeting minutes at = http://ietf.org/proceedings/03nov/index.html), but not much discussion = on the list. Let's get the discussion going on the list so we can converge on this = draft prior to IETF-59 (week of March 1), and meet the AVT charter item = milestone: Mar 2004 Finish requirements for ECRTP over MPLS; re-charter for = subsequent work Thanks, Jerry -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, January 07, 2004 4:01 PM Subject: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Requirements for ECRTP over MPLS Author(s) : J. Ash Filename : draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Pages : 0 Date : 2004-1-8 =09 VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS=20 labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an=20 MPLS VPN, the packet header is at least 48 bytes, while the voice=20 payload is often no more than 30 bytes, for example. VoIP header=20 compression can significantly reduce the VoIP overhead through various=20 compression mechanisms, such as enhanced compressed RTP (ECRTP). This=20 is important on access links where bandwidth is scarce, and can be=20 important on backbone facilities, especially where costs are high (e.g., = some global cross-sections). We consider using MPLS to route ECRTP=20 compressed packets over multiple router hops without=20 compression/decompression cycles at each router. Such an ECRTP over=20 MPLS capability can increase the bandwidth efficiency as well as=20 processing scalability of the maximum number of simultaneous VoIP flows=20 which use header compression at each router. This draft gives a problem = statement, goals, requirements, and an example scenario for ECRTP over=20 MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-00= .txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 7 18:34:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13529 for ; Wed, 7 Jan 2004 18:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNBa-0000t7-MX for avt-archive@odin.ietf.org; Wed, 07 Jan 2004 18:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07NY26P003396 for avt-archive@odin.ietf.org; Wed, 7 Jan 2004 18:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNBY-0000s6-Uy; Wed, 07 Jan 2004 18:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeNAo-0000qI-Iu for avt@optimus.ietf.org; Wed, 07 Jan 2004 18:33:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13362 for ; Wed, 7 Jan 2004 18:33:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNAl-000040-00 for avt@ietf.org; Wed, 07 Jan 2004 18:33:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeN7s-0007im-00 for avt@ietf.org; Wed, 07 Jan 2004 18:30:14 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AeN47-0007ZF-00 for avt@ietf.org; Wed, 07 Jan 2004 18:26:19 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i07NOqSu007360; Thu, 8 Jan 2004 00:24:54 +0100 (CET) From: "Gunnar Hellstrom" To: "avt IETF" , "Toip list" Cc: "Text Telephone Forum" Date: Thu, 8 Jan 2004 00:25:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0385_01C3D57D.F2316EA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] A new version of the text transport is ready. FW: I-D ACTION:draft-ietf-avt-rfc2793bis-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: , This is a multi-part message in MIME format. ------=_NextPart_000_0385_01C3D57D.F2316EA0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i07NOqSu007360 Content-Transfer-Encoding: quoted-printable A new version of the RTP transport specification for real time interactiv= e text is available as described below. Further down is a collection of comments received on the previous version= , and the responses from the authors. I hope this specification will contribute to compatibility between conversational multimedia applications as well as other applications including text among available media. Actions in ITU are depending on progress of this specification, so any further comment should be submitted to the IETF avt group very soon. Regards ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, January 07, 2004 10:01 PM To: IETF-Announce: Subject: I-D ACTION:draft-ietf-avt-rfc2793bis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rfc2793bis-01.txt Pages : 19 Date : 2004-1-7 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-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 messag= e. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2793bis-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-rfc2793bis-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. ------Answers on comments by Magnus Westerlund ------------------------- > 1. The abstract should probably be rewritten, I think the second > paragraph is not relevant enough for this, while the RTP payload format > for gateways are not mentioned at all. Done. The second paragraph is replaced with a short notice about the two = RTP payloads. > 2. I think the TOC is long enough to have it alone on the second page, > i.e. I would propose that one start the introduction chapter on page 3. Done. > 3. The third last paragraph in chapter 1 seems to be a clear motivation > for using TCP to transport text. I think there need to be some further > elaboration on the reasons for using RTP, because the second last > paragraph is not a obvious result of the previous one. A description of the benefit of using RTP for text transmission is added. > 4. Chapter 1, last paragraph, last sentence "and introduces a means of > transporting text > interleaved with voice within the same RTP session.". Is " a means" > correct english? Changed to "a method". > 5. In section 2, a reference to the complete information for RFC 2119 > would be nice. Done. > 6. Section 3: "When transport of T.140 text session data in RTP is > desired, the > payloads as described in this specification SHOULD be used." This > sentence seems a bit strange. I don't think using normative words about > using this payload format real has any meaning. Changed to a sentence that describes the contents of the section instead. > 7. Section 3.1, "This format is primarily used when text is transmitted > on a separate > RTP session dedicated for the transmission of text and not shared > with other media, such as audio, DTMF, etc. IP textphone devices > most commonly use this format." > > I think the restriction this payload format imposes on the media stream > should be clearly documented in this section. One unnecessary restriction has been eliminated. That was that FEC use wa= s described as possible for audio/t140 only. Now it is described as possibl= e for both formats. Other specific restrictions are not known. The descript= ion of ITU-T T.140 gives the application framework and the natural restrictio= ns that follow from the intention of carrying text character by character in= a live conversation. We do not see a need to describe any specific restrict= ion here. > 8. Section 3.2: "This T140block counter may be utilized to detect lost > characters." I think one should clearly indicate that the counter if fo= r > detecting not lost characters but lost T140 blocks. I also think the > comments made in the WG session in Minneapolis that the last block > before a switch to another audio format can't be detected. "characters" are now changed to "blocks". The exact same problem exists with text/t140. If you do not get the last transmitted UDP packet, you will not know until you get the next one. The end result is precisely the same, regardless of text/T140 or audio/t140. That is similar to the case for other conversational media. You cannot be sure you heard the last word, seen the last move or read the last character that the other e= nd expressed. > 9. Section 3.6, "Note, also, that incoming text from a PSTN circuit > might be at a higher bit-rate than can be played out on an egress PSTN > circuit." The scenario and what is meant in this sentence is not clear. We do not want to extend the discussion here of characteristics of the ol= d PSTN textphone types, their different speeds, and what can be done in the tran= sit gateway application. We find it more appropriate to describe the transmission format here and discuss application in depth in the specifications of gateway applications that the audio/t140 format is intended for. > 10. Section 3.7; "For profiles that use dynamic payload type number > assignment, this payload format is identified by the name "T140" (see > section 8). If redundancy is used per RFC 2198, the Payload Type MUST > indicate that payload format ("RED")." I think that one should be > clearer. We are using MIME type according to the definition in chapter > 8, and also RED has its MIME type that can be used to identify the name. > Therefore I would reformulate the sentences to: "For profiles that use > dynamic payload type number assignment, this payload format can be > identified by the MIME types "text/T140" and "audio/T140" (see section > 8). If redundancy is used per RFC 2198, another payload type number > needs to be provided for the redundancy format. MIME types for > identifying RFC 2198 are available in RFC 3555 and RFC YYYY." Where RFC > YYYY is the RFC number for the text/RED registration. Done. > 11. Section 3.7, The RTP sequence number: redefining the RTP sequence > number through normative text is not good. Please provide a reference t= o > RFC 3550 and then you can have the informative text. Done. > 12. Section 3.7: "Timestamp: The RTP Timestamp encodes the approximate > instance of entry of the primary text in the packet. A clock frequency > of 1000 > Hz MUST be used for text/t140. The clock frequency may be > specified for audio/t140 and is generally set to be 8000 Hz, as that is > most common for audio." > > In the last sentence above, it says: The clock frequency may be ... Thi= s > is unclear, it needs normative language, making it clear that the rate > MAY be set to any value, if not specified by out of band mechanism a RT= P > TS rate value of 8000 SHALL be used. Changed to "For audio/T140, the clock frequency MAY be set to any value. If not specified by out of band mechanism, the frequency value is generally set to be 8000 Hz, as that is most common for audio." > 12.5. Section 3.7, why is the marker bit not defined? The marker bit is not used. > 13. Section 3.8: What is the following text doing in this chapter? > "When redundant transmission of the data according to RFC 2198 is > desired, the RTP header is followed by one or more redundant data > block headers, one for each redundant data block to be included. > Each of these headers provides the timestamp offset and length of th= e > corresponding data block plus a payload type number indicating this > payload format ("T140"). Redundant data older than 16383 divided by > the clock frequency MUST not be transmitted." > > It would seem to belong in section describing the usage of RED. I think > there are more things in regards to usage of RED, like section 3.9, > that can be collected in a separate chapter clarifying that it concerns > the usage of RED for t140. Using RED or other ways to incrrease reliability has influence over many sections. It touches the user needs of reliability, the packetisation, the procedures = to discover and recover loss, the marking of unrecoverable loss, the SDP parameters, and = the MIME registrations. We find it more natural to cover these aspects in one chapter each and within these chapters cover the transmission variants. > 14. Section 4.1 "A maximum buffering time of 500 ms is specified." Wher= e > is it specified? The buffering time is specified in T.140. The reference was quite confusi= ng as you noticed, it is changed. > 15. Section 5: Another comment from the WG meeting in Minneapolis, was > the need to make it clear that although the MIME parameter CPS the > instantaneous reception rate might be higher due to jitter. Added. > 16. Section 8.1, as text/t140 in RFC 2793 does not have rate, and it is > not need (due to fixed rate), I would remove it. The mapping to SDP > chapter can simply explain that one simply puts in the rate. Still, the rate is a required parameter in the MIME registration. Therefo= re, it is not removed. It is also best to maintain it for backwards compatibility with RFC2793 implementations. > 17. There should also be an interoperability consideration regarding CP= S > parameter. The action required is described in the text. Further implications if the parameter is not obeyed, belongs more to descriptions in gateway specifications where the audio/t1= 40 format is applied. -----------Answers on comments by Gregg Vanderheiden-------------------------------------------- >I think we should move to amend RFC2793bis to INCLUDE the redundancy as = a >central part of the standard. (a MUST). >Can you think of why you would use RFC2793bis without redundancy? Wi= ll >it be used for anything besides text over VoIP? >I am particularly concerned that in an emergency, an otherwise QOS >environment could become congested quickly and RFC2793 would fail except= if >it had redundancy required. And if it will be required, then why not a= dd >it to the base definition. Gregg wanted that the use of text/t140 with 300 ms between transmissions = and one original and 3 redundant generations of text transmitted, would be pronounced as mandatory to ensure sufficien= t text reliability in congested and catastrophy situations. We have a very clear sharpening from the current RFC2793, by RECOMMENDING these parameters. We do not want to limit the application by mandating these parameters, an= d believe that we can rely on implementers to be wise enough to follow the RECOMMENDED values when there are no reasons to do otherwise. -----------Answers on Frank Shear=B4=B4s comments------------------------------------------------------- >I noticed that the RFC 2793bis draft never speaks of byte ordering. Is i= t >assumed, since this is usually used in the context of RTP, that the byte >order of the T140block counter is the byte order defined in RTP, i.e., >network order? >Wouldn't it be slightly better to specifically mention the byte order in the >draft, just to avoid any potential confusion? The following text is inserted: a 16-bit "t140block counter" (with the most significant bit transmitted first) >A very minor mistake: in section 5, "from section 14 or RFC 3550 apply" >should be "from section 14 of RFC 3550 apply". Woops, we missed that one. ( it is now in section 7 ). Hope it can be lef= t for final edits. ------=_NextPart_000_0385_01C3D57D.F2316EA0 Content-Type: Message/External-body; name="ATT00828.dat" Content-Disposition: attachment; filename="ATT00828.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-7151711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc2793bis-01.txt ------=_NextPart_000_0385_01C3D57D.F2316EA0 Content-Type: Message/External-body; name="draft-ietf-avt-rfc2793bis-01.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rfc2793bis-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-7151711.I-D@ietf.org> ------=_NextPart_000_0385_01C3D57D.F2316EA0-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jan 11 19:23:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24101 for ; Sun, 11 Jan 2004 19:23:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfprL-0000Pf-Vk for avt-archive@odin.ietf.org; Sun, 11 Jan 2004 19:23:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0C0NB9W001584 for avt-archive@odin.ietf.org; Sun, 11 Jan 2004 19:23:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfprB-0000Ox-3C; Sun, 11 Jan 2004 19:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afpr5-0000Om-Nc for avt@optimus.ietf.org; Sun, 11 Jan 2004 19:22:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24091 for ; Sun, 11 Jan 2004 19:22:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afpr4-0005Pp-00 for avt@ietf.org; Sun, 11 Jan 2004 19:22:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfppG-0005MQ-00 for avt@ietf.org; Sun, 11 Jan 2004 19:21:03 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1Afpog-0005HR-00 for avt@ietf.org; Sun, 11 Jan 2004 19:20:26 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63949 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AfpoB-00067u-00; Mon, 12 Jan 2004 00:19:56 +0000 Date: Mon, 12 Jan 2004 00:19:57 +0000 From: Colin Perkins To: "Ash, Gerald R (Jerry), ALABS" Cc: avt@ietf.org Subject: Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Message-Id: <20040112001957.4dea61e3.csp@csperkins.org> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA02BA37B4@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA02BA37B4@KCCLUST06EVS1.ugd.att.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 --> "Ash, Gerald R (Jerry), ALABS" writes: > Please review and comment on the current draft of 'Requirements for ECRTP > over MPLS' > http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-00.txt. To me, this is a considerable improvement on the previous version. A few comments: In a number of places, the draft describes "using MPLS to route ECRTP compressed packets over multiple router hops". Does this mean routing compressed packets over an MPLS LSP? If so, I recommend clarifying the draft to prevent confusion with multiple IP hops. I'm not sure discussion of access links is appropriate, since MPLS is unlikely to be used in this scenario. In section 3, the requirements list ECRTP without discussion. I think ECRTP is an appropriate solution, but it would be useful to motivation the choice by discussing the requirements for the compression. This is particularly important, since there are alternative algorithms (e.g. ROHC) that may be considered. In section 3, the draft nots that protocol extensions may be required for ECRTP. Are these changes to ECRTP or a mapping of ECRTP onto a new "link" layer? If the latter, the draft could do with clarification. The draft should discuss the type of extension needed for RSVP-TE and LDP, since this will feed into any new work plan. Security considerations: Are there no issues with DoS attacks on MPLS routers, due to the increased number of flows? Before publication, the draft will need an IANA Consideratations section (even if it just says "No IANA actions are required") and the IPR boiler- plate. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jan 12 10:10:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00910 for ; Mon, 12 Jan 2004 10:10:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3hn-0007Xv-7G for avt-archive@odin.ietf.org; Mon, 12 Jan 2004 10:10:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CFAFN1028958 for avt-archive@odin.ietf.org; Mon, 12 Jan 2004 10:10:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3hb-0007V6-KJ; Mon, 12 Jan 2004 10:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag3gc-0007Op-0M for avt@optimus.ietf.org; Mon, 12 Jan 2004 10:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00607 for ; Mon, 12 Jan 2004 10:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3gZ-0006dW-00 for avt@ietf.org; Mon, 12 Jan 2004 10:08:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3eb-0006Xe-00 for avt@ietf.org; Mon, 12 Jan 2004 10:06:57 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3cf-0006H6-00 for avt@ietf.org; Mon, 12 Jan 2004 10:04:57 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0CF4sAh020776; Mon, 12 Jan 2004 16:04:54 +0100 Received: from ericsson.com (pcp042838pcs.ki.sw.ericsson.se [147.214.34.105]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZD15YMH; Mon, 12 Jan 2004 16:04:54 +0100 Message-ID: <4002B74A.9040000@ericsson.com> Date: Mon, 12 Jan 2004 16:03:38 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivica Rimac CC: avt@ietf.org Subject: Re: [AVT] RE: [MMUSIC] time-lined static media with FLUTE & IMG References: <3FDF2C1D.7070705@kom.tu-darmstadt.de> In-Reply-To: <3FDF2C1D.7070705@kom.tu-darmstadt.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Ivica, I think Rod manage to repeat my opinions on what need to be done to have a solution that works. And there are probably more interesting problems buried in the actual application of the proposals. Therefore I think that it is necessary that someone who desires this type of solutions starts working on the problems. I would think that a test implementation combined with writing the necessary documents to propose the necessary standard extensions. All to ensure that one has not forgotten things. Then there are probably also some issues around how to make the solution the right level of generic applicability. I hope you better understand why I would not call it straightforward. Cheers Magnus _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jan 12 10:44:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02811 for ; Mon, 12 Jan 2004 10:44:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4EW-0000bi-LA for avt-archive@odin.ietf.org; Mon, 12 Jan 2004 10:44:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CFi4Zw002334 for avt-archive@odin.ietf.org; Mon, 12 Jan 2004 10:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4ET-0000au-S7; Mon, 12 Jan 2004 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4EB-0000ZJ-VS for avt@optimus.ietf.org; Mon, 12 Jan 2004 10:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02776 for ; Mon, 12 Jan 2004 10:43:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4E9-0000HV-00 for avt@ietf.org; Mon, 12 Jan 2004 10:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4DN-00009o-00 for avt@ietf.org; Mon, 12 Jan 2004 10:42:54 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Ag48E-0007js-00 for avt@ietf.org; Mon, 12 Jan 2004 10:37:34 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0CFb4YG009213; Mon, 12 Jan 2004 16:37:08 +0100 (MET) Received: from ericsson.com (research-hrgfx0.ki.sw.ericsson.se [147.214.34.105]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3G9JXT; Mon, 12 Jan 2004 16:39:29 +0100 Message-ID: <4002BED8.1000305@ericsson.com> Date: Mon, 12 Jan 2004 16:35:53 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: B Prashanth CC: avt@ietf.org Subject: Re: [AVT] AMR Profile References: <3FF96823.5080608@neomagic.com> In-Reply-To: <3FF96823.5080608@neomagic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, When AMR is sent over RTP, the speech data in the payload format is as specified by RFC 3267. RFC 3267 gives the following information about how the speech data shall be arranged. From RFC 3267: 4.3.3. Speech Data Speech data of a payload contains one or more speech frames or comfort noise frames, as described in the ToC of the payload. Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame present in the speech data. Each speech frame represents 20 ms of speech encoded with the mode indicated in the FT field of the corresponding ToC entry. The length of the speech frame is implicitly defined by the mode indicated in the FT field. The order and numbering notation of the bits are as specified for Interface Format 1 (IF1) in [2] for AMR and [4] for AMR-WB. As specified there, the bits of speech frames have been rearranged in order of decreasing sensitivity, while the bits of comfort noise frames are in the order produced by the encoder. The resulting bit sequence for a frame of length K bits is denoted d(0), d(1), ..., d(K-1). [2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP). [4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). B Prashanth wrote: > Dear All, > Can anyone please tell me that if RTP stack is sending AMR speech data > then does the encoded AMR payload, i.e. the AMR speech frame, contain > the AMR frame header (specifying the Frame type) or Does the AMR > speech frame contain just the raw, encoded speech data in the form of > Class A, B and C bits? The answer is that the speech frame does only contain the raw speech bits, denoted d(0)..d(K-1) as explained by Section 4.2 in TS 26.101. Not the the following IF1 fields: Frame Quality Indicator (1 bit), Mode Indication (3 bits), Mode Request (3 bits), and Codec CRC (8 bits). These fields are instead located in other fields in the RTP payload for AMR. > > Please note that the header being talked about here is the AMR speech > frame's header and not the RTP's AMR profile header (Specified in RFC > 3267). With AMR profile I assume that you are talking about the RTP payload format, not profile. A Profile is something else in RTP terms. Do you think the quoted text is unclear and needs modification? Cheers Magnus Westerlund _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 14 10:16:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22788 for ; Wed, 14 Jan 2004 10:16:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agmkf-0004f0-Dj for avt-archive@odin.ietf.org; Wed, 14 Jan 2004 10:16:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EFGDWP017908 for avt-archive@odin.ietf.org; Wed, 14 Jan 2004 10:16:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgmkT-0004dg-2n; Wed, 14 Jan 2004 10:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgmkI-0004dO-LR for avt@optimus.ietf.org; Wed, 14 Jan 2004 10:15:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22659 for ; Wed, 14 Jan 2004 10:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgmkG-0007Vu-00 for avt@ietf.org; Wed, 14 Jan 2004 10:15:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgmjF-0007Sf-00 for avt@ietf.org; Wed, 14 Jan 2004 10:14:46 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AgmiK-0007Qf-00 for avt@ietf.org; Wed, 14 Jan 2004 10:13:48 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0EFDiqY027724; Wed, 14 Jan 2004 16:13:44 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jan 2004 16:13:44 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Colin Perkins'" , "Ash, Gerald R (Jerry), ALABS" Cc: avt@ietf.org Subject: RE: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.tx t Date: Wed, 14 Jan 2004 16:13:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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 agree with all Colins comments, and I have further commented on two of them, as well as providing some additional points below. /L-E > In section 3, the requirements list ECRTP without discussion. > I think ECRTP is an appropriate solution, but it would be > useful to motivation the choice by discussing the requirements > for the compression. This is particularly important, since > there are alternative algorithms (e.g. ROHC) that may be > considered. I would really like to see such a discussion, or even better, actually cover both ECRTP and ROHC. That should not make the work much harder, it rather makes sense to do both at the same time. > In section 3, the draft notes that protocol extensions may be > required for ECRTP. Are these changes to ECRTP or a mapping > of ECRTP onto a new "link" layer? If the latter, the draft > could do with clarification. I guess the latter is the case... L-E.1: Is really "Hop-by-hop ECRTP over MPLS" the correct title? I think this is really about the opposite, i.e. HC over multiple MPLS hops. I would suggest: "Requirements for Header Compression over MPLS", as that would also cover both ECRTP and ROHC (then we can decide later whether to cover ROHC or not) and we get rid of the hop-by-hop confusion. L-E.2: The abstract is rather long, can we do something about that? Since the details are in the intro, we can remove some, I think. L-E.3: The following text is confusing, and it is also an example where I think my previous comment on "hop-by-hop" apply (section 2): "More important in almost all locations is decreasing the access bandwidth. While hop-by-hop ECRTP over MPLS clearly helps decrease bandwidth requirements, it also avoids compression-decompression cycles at every router hop. So although bandwidth is getting cheaper, the value of compression does not go away. In addition, IPv6 will increase the size of headers and therefore increase the importance of header compression for VoIP flows." I do not know exactly what the above text wanted to say. The argument that bandwidth cost is still important has been addressed in the top of the section and could potentially be summarized before starting the processing discussion), an alternative text could be (end of current paragraph plus 2 new paragraphs to follow the current one): "So although bandwidth is getting cheaper, the value of compression does not go away. While hop-by-hop header compression could be applied to decrease bandwidth requirements, that would instead imply a processing requirement for compression-decompression cycles at every router hop. Therefore, end-to-end header compression over MPLS seems to be a viable alternative to get the compression benefits without introducing costly processing demands on intermediate nodes. It should further be noted that IPv6 will increase the size of headers, and therefore increase the importance of header compression for VoIP flows." L-E.4: The third paragraph of section 2 is also confusing. Is not the idea to use existing HC techniques along with MPLS labels, in principle??? L-E.5: Goal a in section 3 could explicitly say MPLS networks, i.e. "a. provide more efficient voice transport over MPLS networks," L-E.6: Goal c, should it not say "not significantly increase..."??? L-E.7: The uppercase MUST, SHOULD, etc are not defined to have a special meaning, so it is meaningless to use them if we do not give them special meaning. Note that you have to define their meaning yourself, you can not simply point at 2119, as those definitions only apply to standards track document. I would use lower case words. L-E.8: Requirement b could simply say "should use existing protocols, such as ECRTP and/or ROHC,...." L-E.9: For requirement d, I would suggest "Should make use of..." L-E.10: The example scenario makes me even more convinced that "hop by hop" is NOT the right terminology for what we are aiming for, as it is rather the opposite, we want to avoid hop-by-hop compression. Overall, I agree with Colin that this is a significant improvement from the last document version. Good work! BR /L-E _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 14 14:22:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04279 for ; Wed, 14 Jan 2004 14:22:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqag-0001lP-5A for avt-archive@odin.ietf.org; Wed, 14 Jan 2004 14:22:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EJMA6T006775 for avt-archive@odin.ietf.org; Wed, 14 Jan 2004 14:22:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqaW-0001jb-Ib; Wed, 14 Jan 2004 14:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqaO-0001jF-06 for avt@optimus.ietf.org; Wed, 14 Jan 2004 14:21:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04178 for ; Wed, 14 Jan 2004 14:21:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgqaL-0003Yi-00 for avt@ietf.org; Wed, 14 Jan 2004 14:21:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgqZN-0003Wz-00 for avt@ietf.org; Wed, 14 Jan 2004 14:20:49 -0500 Received: from via-smtp3.imconline.net ([66.155.127.63]) by ietf-mx with esmtp (Exim 4.12) id 1AgqYP-0003Vg-00; Wed, 14 Jan 2004 14:19:49 -0500 Received: from telchemy.com ([66.155.69.251]) by via-smtp3.imconline.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 14 Jan 2004 14:18:23 -0500 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-8.03) id A5CF90F00FE; Wed, 14 Jan 2004 14:17:35 -0500 Reply-To: From: "Alan Clark" To: "'Andy Bierman'" , , "'Romascanu, Dan \(Dan\)'" Cc: Date: Wed, 14 Jan 2004 14:18:25 -0500 Message-ID: <008d01c3dad3$2f6ccd00$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 14 Jan 2004 19:18:23.0896 (UTC) FILETIME=[2DDDA180:01C3DAD3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-rmonmib-raqmon-framework-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've copied this list of comments to AVT as some of them relate to the use of RTCP for reporting purposes. 1. Scope Although the framework makes general reference to "real time applications", most of the examples give are VoIP related. It seems that the primary intended use of RAQMON is VoIP performance monitoring and the umbrella "real time applications" scope is something of a "red herring". 2. VoIP Media path QoS The document suggests that RAQMON provides QoS statistics, including media path stats, but does not refer to or incorporate RFC3611 - the scope of which is specifically VoIP media path QoS. The RFC3611 VoIP metrics form the basis of a number of VoIP QoS reporting protocols, and seem to represent a reasonable level of cross-industry consensus on what is "reasonable" for VoIP QoS monitoring. RAQMON stands alone in trying to argue that RTCP SR/RR statistics are sufficient for VoIP (or Video) QoS monitoring when the industry has moved on to other more appropriate metrics. 3. Reporting intervals RAQMON proposes RTCP as one option for the transport of PDUs. RFC3550 provides guidance on the intervals at which RTCP frames should be sent. The RAQMON framework proposes an independent set of rules on RTCP transmission timing - the AVT group is usually fairly insistent that the rules described in RFC3550 are applied to RTCP and hence within the RAQMON draft the current definition of reporting intervals should be replaced by references to the appropriate parts of RFC3550. RAQMON encourages the use of multiple consecutive RTCP frame transmissions to send long RAQMON reports. This would certainly be in conflict with the recommendations of RFC3550. 4. Measurement methodology RAQMON proposed that the measurement methodology used to generate the reported metrics is "outside the scope" of RAQMON and should be left to the implementer. Whilst implementers can "get away with this" in certain closed system applications it makes any form of open system/ multi-vendor network/ inter-domain QoS management almost impossible. If the only application of RAQMON is for use in closed, single-vendor applications then why make it a standard? Reference to using "IETF and ITU specificed methodologies" is insufficient, for example there are many definitions of jitter within ITU and IETF standards. Some of the metrics specified are also impractical - for example one way delay. This requires an accurate synchronized time source at the two ends of an IP connection - probes that implement this metric often use GPS to obtain the level of timing accuracy needed, simply relying on NTP timers (even with an NTP server) would be generally inadequate. As another example, Section 5.11 defines Round Trip Delay as potentially including or not including the end system delay. Jitter buffers can sometimes reach several hundred milliseconds in size and hence knowing if a reported 300 millisecond round trip delay did or didn't include the end system delay could make a large difference to the user perceived delay. As another example, Section 5.14 describes the count of the number of "application packets" as a metric that "could be measured in different ways, including the methodology described in RFC3550". Is an application packet a CODEC frame, an RTP frame, UDP or IP packet? 5. Mis-understanding of loss and jitter >From section 5.18 "Packet loss tracks persistent congestion while jitter measures tracks transient congestion. Packet loss metric SHOULD indicate loss associated to the network environment as well as local device losses over time. Packet loss of underlying transport network can be measured using various methodologies e.g. as described in [RFC2680], [RFC 3550] and local device level packet losses should to be captured by the local device specific algorithms." 5.a The first sentence is incorrect, also there is no apparent reason for making the statement 5.b SHOULD leaves us not knowing if the reported loss number includes packet discards or not. If I have a call on which 2% of the packets were reported as (lost, lost+discarded?) then do I know if this was a good call? Obviously if the 2% were lost and an additional 5% were discarded then the call would be much worse than if the 2% related to both lost and discarded packets!! 5.c With reference to comment 4 above, "various methodologies" and "local device specific algorithms" leaves us completely in the dark on what has been reported. 6. References Doesn't refer to RFC3611? Regards Alan Clark _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 14 16:53:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16163 for ; Wed, 14 Jan 2004 16:53:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agswj-0002aZ-6W for avt-archive@odin.ietf.org; Wed, 14 Jan 2004 16:53:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ELr5Sn009925 for avt-archive@odin.ietf.org; Wed, 14 Jan 2004 16:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agswf-0002ZX-Nb; Wed, 14 Jan 2004 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqjP-0002JL-Uh for avt@optimus.ietf.org; Wed, 14 Jan 2004 14:31:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04707 for ; Wed, 14 Jan 2004 14:31:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgqjN-0003x0-00 for avt@ietf.org; Wed, 14 Jan 2004 14:31:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgqiL-0003tU-00 for avt@ietf.org; Wed, 14 Jan 2004 14:30:06 -0500 Received: from h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1Agqhm-0003qk-00 for avt@ietf.org; Wed, 14 Jan 2004 14:29:30 -0500 Received: (cpmta 10489 invoked from network); 14 Jan 2004 11:29:26 -0800 Received: from 161.136.100.120 (HELO PC10882K) by smtp.register-admin.com (209.228.32.119) with SMTP; 14 Jan 2004 11:29:26 -0800 X-Sent: 14 Jan 2004 19:29:26 GMT Message-ID: <003501c3dad4$dfdadb90$786488a1@PC10882K> From: "John Cumbo" To: Date: Wed, 14 Jan 2004 14:30:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] secure avt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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, my question has to do with secure avt. I am a network analyst for a hospital IS department, and we are implementing a distance learning center. Part of my responsibility will be securing AV transmissions between our learning center and other sites, and I suppose this is a very general request for the status of things like using SRTP for doing this. My concerns are centered upon HIPAA and how that governing body will affect these types of data transmissions. Is there any currently accepted standard for doing this type of thing? Is SRTP a current accepted standard for doing this? Or is this part of what the AVT task force is developing. Any input would be appreciated _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 15 04:23:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21017 for ; Thu, 15 Jan 2004 04:23:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3iV-0006ps-Ty for avt-archive@odin.ietf.org; Thu, 15 Jan 2004 04:23:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F9N79m026276 for avt-archive@odin.ietf.org; Thu, 15 Jan 2004 04:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3iO-0006pH-Kg; Thu, 15 Jan 2004 04:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah3hj-0006oC-Rl for avt@optimus.ietf.org; Thu, 15 Jan 2004 04:22:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20966 for ; Thu, 15 Jan 2004 04:22:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah3hh-0006UH-00 for avt@ietf.org; Thu, 15 Jan 2004 04:22:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah3gi-0006S4-00 for avt@ietf.org; Thu, 15 Jan 2004 04:21:17 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Ah3fq-0006QZ-00 for avt@ietf.org; Thu, 15 Jan 2004 04:20:22 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0F9KJYG010728; Thu, 15 Jan 2004 10:20:19 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Jan 2004 10:20:19 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Colin Perkins'" , "Ash, Gerald R (Jerry), ALABS" Cc: avt@ietf.org Subject: RE: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.tx t Date: Thu, 15 Jan 2004 10:19:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Ash and others, Unfortunately, Magnus had sent me the draft and I assumed it was the new official version, but I guess it was a pre-version. The official one is again an improvement, so you can ignore my comments L-E.1 and L-E.10 below, but I still believe it would make sense to generalize ECRTP to "Header Compression", i.e. to include ROHC in the scope. Cheers, /L-E > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of > Lars-Erik Jonsson (LU/EAB) > Sent: den 14 januari 2004 16:13 > To: 'Colin Perkins'; Ash, Gerald R (Jerry), ALABS > Cc: avt@ietf.org > Subject: RE: [AVT] RE: I-D > ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.tx t > > > Hi all, > > I agree with all Colins comments, and I have further commented on > two of them, as well as providing some additional points below. > > /L-E > > > > In section 3, the requirements list ECRTP without discussion. > > I think ECRTP is an appropriate solution, but it would be > > useful to motivation the choice by discussing the requirements > > for the compression. This is particularly important, since > > there are alternative algorithms (e.g. ROHC) that may be > > considered. > > I would really like to see such a discussion, or even better, > actually cover both ECRTP and ROHC. That should not make the > work much harder, it rather makes sense to do both at the same > time. > > > > In section 3, the draft notes that protocol extensions may be > > required for ECRTP. Are these changes to ECRTP or a mapping > > of ECRTP onto a new "link" layer? If the latter, the draft > > could do with clarification. > > I guess the latter is the case... > > > L-E.1: > Is really "Hop-by-hop ECRTP over MPLS" the correct title? I > think this is really about the opposite, i.e. HC over multiple > MPLS hops. I would suggest: > "Requirements for Header Compression over MPLS", > as that would also cover both ECRTP and ROHC (then we can > decide later whether to cover ROHC or not) and we get rid of > the hop-by-hop confusion. > > > L-E.2: > The abstract is rather long, can we do something about that? > Since the details are in the intro, we can remove some, I think. > > > L-E.3: > The following text is confusing, and it is also an example where > I think my previous comment on "hop-by-hop" apply (section 2): > "More important in almost all locations is decreasing the > access bandwidth. While hop-by-hop ECRTP over MPLS clearly > helps decrease bandwidth requirements, it also avoids > compression-decompression cycles at every router hop. So > although bandwidth is getting cheaper, the value of compression > does not go away. In addition, IPv6 will increase the size of > headers and therefore increase the importance of header > compression for VoIP flows." > > I do not know exactly what the above text wanted to say. The > argument that bandwidth cost is still important has been > addressed in the top of the section and could potentially be > summarized before starting the processing discussion), an > alternative text could be (end of current paragraph plus > 2 new paragraphs to follow the current one): > > "So although bandwidth is getting cheaper, the value of > compression does not go away. > > While hop-by-hop header compression could be applied to > decrease bandwidth requirements, that would instead imply a > processing requirement for compression-decompression cycles at > every router hop. Therefore, end-to-end header compression over > MPLS seems to be a viable alternative to get the compression > benefits without introducing costly processing demands on > intermediate nodes. > > It should further be noted that IPv6 will increase the size > of headers, and therefore increase the importance of header > compression for VoIP flows." > > > L-E.4: > The third paragraph of section 2 is also confusing. Is not > the idea to use existing HC techniques along with MPLS > labels, in principle??? > > > L-E.5: > Goal a in section 3 could explicitly say MPLS networks, i.e. > "a. provide more efficient voice transport over MPLS networks," > > > L-E.6: > Goal c, should it not say "not significantly increase..."??? > > > L-E.7: > The uppercase MUST, SHOULD, etc are not defined to have a > special meaning, so it is meaningless to use them if we do > not give them special meaning. Note that you have to define > their meaning yourself, you can not simply point at 2119, as > those definitions only apply to standards track document. > I would use lower case words. > > > L-E.8: > Requirement b could simply say "should use existing protocols, > such as ECRTP and/or ROHC,...." > > > L-E.9: > For requirement d, I would suggest "Should make use of..." > > > L-E.10: > The example scenario makes me even more convinced that > "hop by hop" is NOT the right terminology for what we are > aiming for, as it is rather the opposite, we want to avoid > hop-by-hop compression. > > > Overall, I agree with Colin that this is a significant > improvement from the last document version. Good work! > > BR > /L-E > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 15 11:23:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13614 for ; Thu, 15 Jan 2004 11:23:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhAH5-0000wA-CR for avt-archive@odin.ietf.org; Thu, 15 Jan 2004 11:23:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FGNFw7003598 for avt-archive@odin.ietf.org; Thu, 15 Jan 2004 11:23:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhAGr-0000vI-Jv; Thu, 15 Jan 2004 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhAGU-0000ub-9H for avt@optimus.ietf.org; Thu, 15 Jan 2004 11:22:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13568 for ; Thu, 15 Jan 2004 11:22:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhAGS-0001x3-00 for avt@ietf.org; Thu, 15 Jan 2004 11:22:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhAFg-0001vL-00 for avt@ietf.org; Thu, 15 Jan 2004 11:21:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AhAFA-0001sE-00 for avt@ietf.org; Thu, 15 Jan 2004 11:21:16 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 15 Jan 2004 08:21:01 -0800 Received: from mbaugher-w2k07.cisco.com (rtp-vpn3-15.cisco.com [10.82.216.15]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0FGKfLF022828; Thu, 15 Jan 2004 11:20:42 -0500 (EST) Message-Id: <6.0.0.22.2.20040115080435.0397b638@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 15 Jan 2004 08:20:39 -0800 To: "John Cumbo" From: Mark Baugher Subject: Re: [AVT] secure avt Cc: In-Reply-To: <003501c3dad4$dfdadb90$786488a1@PC10882K> References: <003501c3dad4$dfdadb90$786488a1@PC10882K> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , John, SRTP soon will be an Internet Proposed Standard. It very well may be the right choice for securing your application, all things being equal. You will need to have an authorization and key management infrastructure to support an SRTP product. You should also consider various alternatives. One alternative is IPsec, which secures UDP and has been successful in providing confidentiality and/or authentication for media streams for many applications. SRTP is quite new and there are lots of IPsec-based products but fewer SRTP-based products at the present time. You might choose IPsec over SRTP if you want to have an IPsec VPN among your sites and don't need any of the features that SRTP has over IPsec, such as the following. 1. SRTP allows compressed RTP and has much less packet overhead than IPsec. 2. SRTP provides application-layer security, which is more secure for some applications particularly when multi-user computers are used as end systems. 3. SRTP is tailored to RTP and supports, for example, encrypted RTP with unencrypted RTCP flows. Mark At 11:30 AM 1/14/2004, John Cumbo wrote: >Hello, > >my question has to do with secure avt. I am a network analyst for a hospital >IS department, and we are implementing a distance learning center. Part of >my responsibility will be securing AV transmissions between our learning >center and other sites, and I suppose this is a very general request for the >status of things like using SRTP for doing this. My concerns are centered >upon HIPAA and how that governing body will affect these types of data >transmissions. Is there any currently accepted standard for doing this type >of thing? Is SRTP a current accepted standard for doing this? Or is this >part of what the AVT task force is developing. > >Any input would be appreciated > > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 15 16:41:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01840 for ; Thu, 15 Jan 2004 16:41:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFEt-0003q8-49 for avt-archive@odin.ietf.org; Thu, 15 Jan 2004 16:41:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FLfJc8014710 for avt-archive@odin.ietf.org; Thu, 15 Jan 2004 16:41:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFEc-0003oN-NP; Thu, 15 Jan 2004 16:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFEM-0003nl-7b for avt@optimus.ietf.org; Thu, 15 Jan 2004 16:40:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01732 for ; Thu, 15 Jan 2004 16:40:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFEK-0005FT-00 for avt@ietf.org; Thu, 15 Jan 2004 16:40:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFDH-00053O-00 for avt@ietf.org; Thu, 15 Jan 2004 16:39:40 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AhFC5-0004p5-00 for avt@ietf.org; Thu, 15 Jan 2004 16:38:25 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63854 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AhFBY-0005n5-00 for avt@ietf.org; Thu, 15 Jan 2004 21:37:52 +0000 Date: Thu, 15 Jan 2004 21:37:56 +0000 From: Colin Perkins To: avt@ietf.org Message-Id: <20040115213756.2e2c22f3.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Fw: I-D ACTION:draft-perkins-avt-rtp-reactive-fec-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Takes working group chair hat off...] The following may be of interest to the group. Colin ------- Forwarded message: >Date: Thu, 15 Jan 2004 16:09:47 -0500 >From: Internet-Drafts@ietf.org >To: IETF-Announce: ; >Subject: I-D ACTION:draft-perkins-avt-rtp-reactive-fec-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : RTP Retransmission Using Reactive FEC > Author(s) : C. Perkins > Filename : draft-perkins-avt-rtp-reactive-fec-00.txt > Pages : 8 > Date : 2004-1-15 > > This memo describes how the RTP Payload Format for Generic Forward > Error Correction can be combined with the Extended RTP Profile for > RTCP-based Feedback to provide a solution for retransmission of lost > RTP packets. Such a retransmission format is expected to be useful to > improve the reliability of real-time applications with relaxed delay > bounds, for example non-interactive streaming audio/video. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-perkins-avt-rtp-reactive-fec-00.txt ... ------- End of Forwarded Message -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jan 18 13:23:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27120 for ; Sun, 18 Jan 2004 13:23:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiHZV-0008RS-Tk for avt-archive@odin.ietf.org; Sun, 18 Jan 2004 13:22:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0IIMr0t032401 for avt-archive@odin.ietf.org; Sun, 18 Jan 2004 13:22:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiHYf-0008M5-A8; Sun, 18 Jan 2004 13:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiHXj-0008LM-G8 for avt@optimus.ietf.org; Sun, 18 Jan 2004 13:21:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27062 for ; Sun, 18 Jan 2004 13:20:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiHXh-0001D0-00 for avt@ietf.org; Sun, 18 Jan 2004 13:21:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiHWg-00019z-00 for avt@ietf.org; Sun, 18 Jan 2004 13:19:59 -0500 Received: from law9-f82.law9.hotmail.com ([64.4.9.82] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AiHWL-00018D-00 for avt@ietf.org; Sun, 18 Jan 2004 13:19:37 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 18 Jan 2004 10:19:07 -0800 Received: from 195.92.194.15 by lw9fd.law9.hotmail.msn.com with HTTP; Sun, 18 Jan 2004 18:19:06 GMT X-Originating-IP: [195.92.194.15] X-Originating-Email: [nours20002@hotmail.com] X-Sender: nours20002@hotmail.com From: "nour s" To: avt@ietf.org Date: Sun, 18 Jan 2004 18:19:06 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jan 2004 18:19:07.0064 (UTC) FILETIME=[8F7B2380:01C3DDEF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Subject: [AVT] important questions Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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 have explaining about SSRC synchronization source could you please give me an example about it ,I know that is is different from source address, but are there any relation between them? also I would to ask this question: how the packets travel fron the source address to destination address is there any protocol for choosing the routing,? please give me more information about that thanks for your help nour _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jan 19 04:08:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07549 for ; Mon, 19 Jan 2004 04:08:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiVON-0004Dt-Dv for avt-archive@odin.ietf.org; Mon, 19 Jan 2004 04:08:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J98IwZ016232 for avt-archive@odin.ietf.org; Mon, 19 Jan 2004 04:08:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiVO6-0004Aa-RX; Mon, 19 Jan 2004 04:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiVNW-00044l-Uz for avt@optimus.ietf.org; Mon, 19 Jan 2004 04:07:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07515 for ; Mon, 19 Jan 2004 04:07:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiVNU-00055d-00 for avt@ietf.org; Mon, 19 Jan 2004 04:07:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiVMV-00053Q-00 for avt@ietf.org; Mon, 19 Jan 2004 04:06:24 -0500 Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 1AiVM2-000507-00 for avt@ietf.org; Mon, 19 Jan 2004 04:05:54 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i0J95OLQ021851 for ; Mon, 19 Jan 2004 10:05:24 +0100 Received: from ox.inria.fr (ox.inria.fr [138.96.88.70]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id i0J93jZ5020814; Mon, 19 Jan 2004 10:03:48 +0100 Received: from sophia.inria.fr (localhost [127.0.0.1]) by ox.inria.fr (8.12.10/8.12.5) with ESMTP id i0J93jAG017311; Mon, 19 Jan 2004 10:03:45 +0100 Message-ID: <400B9D71.3040508@sophia.inria.fr> Date: Mon, 19 Jan 2004 10:03:45 +0100 From: Abdelbasset Trad User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: fr-FR,en MIME-Version: 1.0 To: Abdelbasset Trad CC: avt@ietf.org Subject: Re: [AVT] important questions References: <400B9CE3.30309@sophia.inria.fr> In-Reply-To: <400B9CE3.30309@sophia.inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 SSRC is an identification related to a session used for synchronisation at the destination, one user (one source address) may have several SSRC for instance if he has a video session and audio session being transmitted. SSRCs are chosen randomly at every RTP transmission in order to be unique and to not have the same SSRC at different users. Routing is independent from RTP transmission, it is done at routers using protocols such OSPF, RIP... A. Trad > >> >> hi, >> I would like to have explaining about SSRC synchronization source >> could you please give me an example about it ,I know that is is >> different from source address, but are there any relation between them? >> also I would to ask this question: >> how the packets travel fron the source address to destination address >> is there any protocol for choosing the routing,? please give me more >> information about that >> >> thanks for your help >> >> nour >> >> _________________________________________________________________ >> Express yourself with cool new emoticons >> http://www.msn.co.uk/specials/myemo >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > > > > -- ------------------------------------------ Abdelbasset TRAD INRIA Planete Project 2004 Route des Lucioles, BP-93 06902 Sophia-Antipolis Cedex, France Phone: (+33) 4 92 38 50 22 Fax: (+33) 4 92 38 79 78 Email: atrad@sophia.inria.fr http://www-sop.inria.fr/planete/atrad ------------------------------------------ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 20 15:44:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20832 for ; Tue, 20 Jan 2004 15:44:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2jb-00084m-Pk for avt-archive@odin.ietf.org; Tue, 20 Jan 2004 15:44:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KKiR7T031031 for avt-archive@odin.ietf.org; Tue, 20 Jan 2004 15:44:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2jC-0007zO-Q9; Tue, 20 Jan 2004 15:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2iT-0007wG-HK for avt@optimus.ietf.org; Tue, 20 Jan 2004 15:43:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20432; Tue, 20 Jan 2004 15:43:15 -0500 (EST) Message-Id: <200401202043.PAA20432@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, 20 Jan 2004 15:43:15 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2032-bis-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.261 Video Streams Author(s) : T. Turletti, C. Huitema, R. Even Filename : draft-ietf-avt-rfc2032-bis-00.txt Pages : 23 Date : 2004-1-20 This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2032-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc2032-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-20142421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc2032-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc2032-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20142421.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 20 16:31:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20833 for ; Tue, 20 Jan 2004 15:44:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2jb-00084l-PT for avt-archive@odin.ietf.org; Tue, 20 Jan 2004 15:44:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KKiREW031033 for avt-archive@odin.ietf.org; Tue, 20 Jan 2004 15:44:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2jD-0007zW-EP; Tue, 20 Jan 2004 15:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2iY-0007xK-EM for avt@optimus.ietf.org; Tue, 20 Jan 2004 15:43:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20448; Tue, 20 Jan 2004 15:43:20 -0500 (EST) Message-Id: <200401202043.PAA20448@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, 20 Jan 2004 15:43:19 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2429-bis-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Author(s) : J. Ott, G. Sullivan, S. Wenger, C. Zhu, R. Even Filename : draft-ietf-avt-rfc2429-bis-00.txt Pages : 34 Date : 2004-1-20 This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2429-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc2429-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-20142445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc2429-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc2429-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20142445.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 21 10:35:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26414 for ; Wed, 21 Jan 2004 10:35:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKNx-0006jn-Av for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 10:35:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LFZHki025898 for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 10:35:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKNh-0006hs-QV; Wed, 21 Jan 2004 10:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjKMu-0006dH-76 for avt@optimus.ietf.org; Wed, 21 Jan 2004 10:34:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26315 for ; Wed, 21 Jan 2004 10:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjKMq-0003im-00 for avt@ietf.org; Wed, 21 Jan 2004 10:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKLt-0003hG-00 for avt@ietf.org; Wed, 21 Jan 2004 10:33:09 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AjKLV-0003fq-00 for avt@ietf.org; Wed, 21 Jan 2004 10:32:45 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0LFWgYG006657; Wed, 21 Jan 2004 16:32:42 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDHMX5M; Wed, 21 Jan 2004 16:32:42 +0100 Message-ID: <400E9B40.3080206@ericsson.com> Date: Wed, 21 Jan 2004 16:31:12 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "Paul E. Jones" , avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-text-red-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Paul, Here are some comments on the text/RED mime registration: 1. Section 3: rate parameter: I think the "may" in the last sentence should be a normative one. 2. Section 3: The "pt" list is not motivated, one does not understand the purpose of it. I think you should add a little text to make it clear. Expanding the first sentence like this may be sufficient: "a comma-separated list of RTP payload types that MAY occur in the redundancy payload." 3. Section 3: Security considerations: Referencing the wrong chapter. I think you could also should rewrite it so that it becomes more standalone. Proposal: "see section 5 of RFC XXXX." Do also put in a RFC-editor note about replacing XXXX with the documents number. 4. Section 4, second bullet. The rate parameter is not explicitly stated. I think the second sentence should be: "The rate parameter's value goes as rate in the "a=rtpmap" attribute." The MUST statement belongs to the MIME type parameter in general and should be moved there instead. 5. Section 4, the last bullet for the "pt" list. This is under specified, the following problems exist: - The removal or not of <"> quoting etc. is not defined. - How to handle any "dynamic-payload-type "=" content-type" string is also not explained. 6. Section 4, the "pt" example. I think it can be improved with stating what the 99 is. 7. Section 5: A proposal for how to handle the security problem is always good. Proposal: "To prevent modification of the primary, secondary or header information, payload integrity protection over at least the complete RTP packet is recommend, for example using SRTP []." 8. Section 6, The first reference is an informative one, please move it to an informative reference list. Also reference 7 is not used at all, please remove. I expect that the when these things are addressed the document is ready for WG last call. cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 21 12:53:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01768 for ; Wed, 21 Jan 2004 12:53:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMXN-0008HS-Tb for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 12:53:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LHr9r0031829 for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 12:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMXF-0008FI-0B; Wed, 21 Jan 2004 12:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMWV-0008E4-UH for avt@optimus.ietf.org; Wed, 21 Jan 2004 12:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01662 for ; Wed, 21 Jan 2004 12:52:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjMWU-00026M-00 for avt@ietf.org; Wed, 21 Jan 2004 12:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjMVZ-00023w-00 for avt@ietf.org; Wed, 21 Jan 2004 12:51:18 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AjMUt-00021h-00 for avt@ietf.org; Wed, 21 Jan 2004 12:50:35 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0LHoNAh001679; Wed, 21 Jan 2004 18:50:34 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJB4GK4V; Wed, 21 Jan 2004 18:52:19 +0100 Message-ID: <400EBB85.3060704@ericsson.com> Date: Wed, 21 Jan 2004 18:48:53 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: gunnar.hellstrom@omnitor.com, "Paul E. Jones" CC: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-avt-rfc2793bis-01 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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 Gunnar and Paul, Here is my comments on the payload format. 1. Abstract: You need to remove the [1] reference. 2. Section 1: There is a MUST in the introduction. It should be changed to lower case must of two reasons. First, this document does not define that T.140 elements use ISO 10646-1. Secondly, having normative language in an introduction is not appropriate. 3. Section 3.2: Last sentence of second paragraph. "This T140block counter may be utilized to detect lost blocks." I would propose to change this to: "This T140block counter is intended to be utilized to detect lost blocks and avoid duplication of blocks." 4. section 3.3, last sentence: Is this SHOULD correct? Why does the paragraph implies that CCS SHOULD be place in one block, why not MAY or SHALL? 5. The robustness features of the draft. As I have privately commented I would prefer to see the robustness features be collected into a single chapter. I think by moving sections: 3.4, 3.5, 3.8, 3.9, and 4.4 into a new chapter, between 4 and 5 the draft can be made more understandable. 6. Section 3.6: I think one should be more explicit about the fact that the rendering of (reasonably) late blocks is recommend and very beneficial. 7. Section 3.6: End of last paragraph: I think I understand the motivation behind the recommendation that voice is discarded rather then the T.140 when going from IP to PSTN at a gateway. However I think one should reflect somewhat on the effects on the audio also. 8. Section 3.7: Timestamp. "For audio/T140, the clock frequency MAY be set to any value. If not specified by out of band mechanism, the frequency value is generally set to be 8000 Hz, as that is most common for audio." I think the "generally set to be 8000 Hz" is not good enough. There needs to be strict rules on what to do, otherwise you are in trouble. I think that if not out-of-band signalling, where the interleaved audio can be matched in rate, a fixed rate shall be set. I am also missing the sentence saying: "When using this payload format interleaved with an audio codec, the rate SHOULD be chosen to be the same as the audio codec(s) to avoid RTP timestamp rate switching." 9. Section 3.7: Missing marker bit definition. Even if not used it MUST be defined as being not used and set to 0. 10. Section 3.8: I think there are no reason to have a section called "additional headers" and then simply having it state, no headers exist. It is mostly about redundancy anyway, please rename. 11. section 3.9, second paragraph. This paragraph is very hard to interpret. First it talks about audio/t140, then about text/t140, and when you come to the rules you are rather confused about for what it applies. Please try to improve the paragraph through restructuring. 12. In regards to the robustness options. As we now have available mechanism to report packet losses, RFC 3611, but probably more important draft-ietf-avt-rtcp-feedback and its NACK format, there is now possibilities to do reactive repairs. I think the possibility should at least be mentioned, or if it doesn't work, that should be motivated. Please investigate this. 13. Section 5, Second paragraph: "To control the character transmission rate, the "fmtp" attribute [7] is used with the following syntax:" I think this sentence should be changed to explain that; first CPS is a MIME parameter, secondly that this is how it is mapped according to section x to SDP. 14. Section 6.3: The RED SDP examples. Why does on have a=fmtp lines like this? To my understanding of the pt list it should only contain a single 98. This is either a bug here, or problem in the text/red document. 15. Section 7: I think the security section can be improved: - Separate the three main issues, confidentiality, integrity, and source authentication. They are different, and have different severity and attacks, and different counters. - The section should give recommendations to mechanism that allows one to counter these problems. For the two first SRTP works very well. For the last it provides some properties that can be used to accomplish that, combined with the signalling. So please expand this. 16. Section 8: Should be titled "IANA Consideration". And the introduction to the chapter should request that the two mime types are registered. 17. Section 8.1, and 8.2: The registration should mention "This type is only defined for transfer via RTP." 18. Section 8.1, and 8.2: Security consideration: Please point at section 7 of RFC XXXX. 19. Section 8.2: The rate parameter for audio should contain the rule that it SHOULD be matched with interleaved audio codecs. 20. Section 11: Are really all references normative. I would expect that 5, 6, and 8 are informative. I have however not looked closely at it. 21. As it seems there will be some more RFC editors notes, they may be moved into a separate RFC-editor section instead of being spread through the document. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 21 15:30:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06793 for ; Wed, 21 Jan 2004 15:30:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOzM-0008HE-GS for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 15:30:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LKUC1e031766 for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 15:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOzD-0008Cp-5z; Wed, 21 Jan 2004 15:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOyU-00083c-Ip for avt@optimus.ietf.org; Wed, 21 Jan 2004 15:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06705 for ; Wed, 21 Jan 2004 15:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjOyT-0000Cm-00 for avt@ietf.org; Wed, 21 Jan 2004 15:29:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjOxV-0000AI-00 for avt@ietf.org; Wed, 21 Jan 2004 15:28:17 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AjOwf-00006W-00 for avt@ietf.org; Wed, 21 Jan 2004 15:27:25 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61777 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AjOvq-0005AK-00; Wed, 21 Jan 2004 20:26:34 +0000 Date: Wed, 21 Jan 2004 20:26:44 +0000 From: Colin Perkins To: Magnus Westerlund Cc: gunnar.hellstrom@omnitor.com, paulej@packetizer.com, avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-avt-rfc2793bis-01 Message-Id: <20040121202644.6eb04350.csp@csperkins.org> In-Reply-To: <400EBB85.3060704@ericsson.com> References: <400EBB85.3060704@ericsson.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 --> Magnus Westerlund writes: > Hi Gunnar and Paul, > > Here is my comments on the payload format. ... > 12. In regards to the robustness options. As we now have available > mechanism to report packet losses, RFC 3611, but probably more important > draft-ietf-avt-rtcp-feedback and its NACK format, there is now > possibilities to do reactive repairs. I think the possibility should at > least be mentioned, or if it doesn't work, that should be motivated. > Please investigate this. Unless specified otherwise, it should be assumed that the standard, payload format independent, repair schemes can be used with any new payload format. I don't see any need to list them specially here. > 14. Section 6.3: The RED SDP examples. Why does on have a=fmtp lines > like this? To my understanding of the pt list it should only contain a > single 98. This is either a bug here, or problem in the text/red > document. The SDP fragments such as m=text 11000 RTP/AVP 98 100 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98 appear to be correct. The "a=fmtp:100 98/98" line indicates that both primary and redundant coding use payload type 98. > 15. Section 7: I think the security section can be improved: > - Separate the three main issues, confidentiality, integrity, and source > authentication. They are different, and have different severity and > attacks, and different counters. > - The section should give recommendations to mechanism that allows one > to counter these problems. For the two first SRTP works very well. For > the last it provides some properties that can be used to accomplish > that, combined with the signalling. > So please expand this. Note that this is recommendations, rather than "MUST" requirements, since SRTP is not appropriate in all cases. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 21 22:36:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23995 for ; Wed, 21 Jan 2004 22:36:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjVdg-0007Wp-Va for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 22:36:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M3aGci028935 for avt-archive@odin.ietf.org; Wed, 21 Jan 2004 22:36:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjVdS-0007AA-3T; Wed, 21 Jan 2004 22:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjVcy-0006NT-RD for avt@optimus.ietf.org; Wed, 21 Jan 2004 22:35:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23978 for ; Wed, 21 Jan 2004 22:35:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjVcv-0004NV-00 for avt@ietf.org; Wed, 21 Jan 2004 22:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjVbz-0004MZ-00 for avt@ietf.org; Wed, 21 Jan 2004 22:34:33 -0500 Received: from ns8.sony.co.jp ([137.153.0.33]) by ietf-mx with esmtp (Exim 4.12) id 1AjVbd-0004LH-00 for avt@ietf.org; Wed, 21 Jan 2004 22:34:09 -0500 Received: from mail2.sony.co.jp (mail2.sony.co.jp [43.0.1.202]) Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8/Sony) with ESMTP id i0M3Y7C00348 for ; Thu, 22 Jan 2004 12:34:07 +0900 (JST) Received: from jptkyxim02.jp.sony.com (jptkyxim02.jp.sony.com [43.15.17.88]) by mail2.sony.co.jp (R8/Sony) with ESMTP id i0M3Y6H00340 for ; Thu, 22 Jan 2004 12:34:06 +0900 (JST) Received: from jptkyxwa01.jp.sony.com ([43.15.31.1]) by jptkyxim02.jp.sony.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 Jan 2004 12:34:06 +0900 Received: from [43.13.117.153] ([43.13.117.153]) by jptkyxwa01.jp.sony.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 Jan 2004 12:34:06 +0900 Mime-Version: 1.0 (Apple Message framework v609) To: avt@ietf.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-21--201518565 Cc: Mitsuyuki Hatanaka , Jun Matsumoto Subject: [AVT] pre-submission of rtp payload for atrac-family From: Matthew Romaine Date: Thu, 22 Jan 2004 12:34:05 +0900 X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 22 Jan 2004 03:34:06.0190 (UTC) FILETIME=[968BC8E0:01C3E098] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --Apple-Mail-21--201518565 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hello avt groupers (particularly Colin and Magnus), I have attached an rtp payload format for the ATRAC family of audio codecs Sony has been developing. Some of you may be familiar with the ATRAC-X payload we were working on last year. With a bit of guidance from Mangus, we have decided to considerably simplify the payload, while at the same time generalize it so that previous ATRAC codecs, which are still widely used, could be included. As I seek comments from listers on what needs to be fixed and clarified, I have a question about the naming convention. Must we treat this as a completely new payload format (-00), which would mean committing to an earlier deadline, or can we consider this a continued revision of previous submissions (making this a -04)? Please fire away with comments. Thanks, Matt --Apple-Mail-21--201518565 Content-Type: text/plain; x-unix-mode=0644; name="draft-hatanataka-avt-rtp-atrac-family-00.txt" Content-Disposition: attachment; filename=draft-hatanataka-avt-rtp-atrac-family-00.txt Content-Transfer-Encoding: 7bit Internet Engineering Task Force Mitsuyuki Hatanaka Internet Draft Matthew Romaine January 2004 Sony Corporation Expires: June 2004 RTP payload format for ATRAC family Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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]. Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the ATRAC family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document includes support for data fragmentation and elementary redundancy measures. Hatanaka Expires June 2004 [Page 1] Internet Draft January 2004 1 Introduction The ATRAC family of perceptual audio codecs are designed to address numerous needs for high quality low bit-rate audio transfer. ATRAC technology can be found in many consumer and professional products and applications, including MD players, voice recorders, mobile phones, and CD players. The need for real-time streaming of audio data has grown, and this document details our efforts in increasing the product and application space for the ATRAC family of codecs. Recent advances in ATRAC technology allow for multiple channels of audio to be encoded in customizable groupings. This should allow for future expansions in scaled streaming. To provide the greatest flexibility in streaming any one of the ATRAC family member codecs however, this payload format does not distinguish between the codecs on a packet level. This simplified payload format contains only the basic information needed to disassemble a packet of ATRAC audio in order to decode it. Timestamps are in sample units, with audio data encoded into frames of 512, 1024, or 2048 samples. There is basic support for fragmentation and redundancy, so ATRAC frames MAY exceed an MTU size of 1500 octets. 2 Payload Format 2.1 RTP Header 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=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contributing source (CSRC) identifiers | | ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension (X): 1bit Set to zero as no header extensions are currently being supported. Marker (M): 1 bit Set to zero as profiling is currently not used. Payload Type (PT): 7 bits The payload type can either be dynamically allocated at the application level, or an RTP profile for a class of applications is expected to assign the payload type for this format. A dynamic allocation should designate this format as ATRAC-Family. Hatanaka Expires June 2004 [Page 2] Internet Draft January 2004 Sequence number: 16 bits This field is as defined in [1]. Timestamp: 32 bits A timestamp representing the sampling time of the first sample of the first ATRAC frame in the RTP packet. The clock frequency MUST be set to the sample rate of the encoded audio data, and is conveyed out-of-band. V/P/CC identifiers: These three fields, 2 bits, 1 bit, and 4 bits respectively, are as defined in [1]. SSRC/CSRC identifiers: These two fields, each 32 bits with one SSRC field and a maximum of 16 CSRC fields, are as defined in [1]. 2.2 Payload Header The ATRAC family payload header is a scant two octets. This should make processing very simple. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|FrgNo| Rsrvd |NFrames| FrOff | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Continuous flag (C): 1 bit Set to one if this is a continuation of a fragmented packet. Fragment Number (FrgNo): 3 bits In the event of data fragmentation, this value is 1 for the first packet, and increases sequentially for the remaining fragmented data packets. Number of Frames (NFrames): 4 bits The number of frames in this packet. This allows for a maximum of 16 ATRAC-encoded audio encapsulations per packet, with 0 indicating one frame. Keep in mind only the first frame is allowed to be fragmented. Additionally, this must not be anything other than 0 for subsequent packets containing the fragmented frame. Frame Offset (FrOff): 4 bits The purpose of frame offsets is to provide a basic mechanism for the transmission of redundant data. Using the current packet's timestamp as a reference, the frame offset is converted to units of the timestamp, which then corresponds to the playback time of the first frame in the packet. This field should NOT be used in packets containing fragmented data. Hatanaka Expires June 2004 [Page 3] Internet Draft January 2004 2.3 Payload Data ATRAC payload data consists of 4 bits representing the frame ID. The following 2 octets then represent the byte-length of encoded audio data. After that, the actual audio data follows. 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |FrameID| Block Length | ATRAC data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame ID: 4 bits A sequential identifier, starting from 0 for each new non-fragmented packet, identifying the start of each frame in this packet. Block length: 12 bits The byte length of encoded audio data until the end of the current packet. This is so that in the case of fragmentation, if only a subsequent packet is received, decoding can still occur. 12 bits allows for a maximum block length of 4096 bytes. In the event data is larger but would still fit within MTU limits, fragmentation must occur. 3 Frame Packetization Each RTP packet contains either an integer number of ATRAC encoded audio frames, with a maximum of 16, or one ATRAC frame fragment. As many complete ATRAC frames as can fit in a single path-MTU should be placed in an RTP packet, with the aforementioned maximum of 16. However, if an ATRAC frame will not fit into an RTP packet, it must be fragmented. The start of a fragmented frame gets placed in its own RTP packet, its Continuous bit (C) set to one, and its Fragment Number (FragNo) set to one. As the frame must be the only one in the packet, the Number of Frames field is also one. Subsequent packets are to contain the remaining fragmented frame data, with the Fragment Number increasing sequentially and the Continuous bit (C) consistently set to one. As subsequent packets do not contain any new frames, the Number of Frames field is to be zero. The last packet of fragmented data must have the Continuous bit (C) set to zero. In the event of fragmentation, the basic redundancy measures should NOT be used. 3.1 Example Fragmented ATRAC Frame An example of a fragmented ATRAC frame is presented below. The encoded audio data frame is split over three RTP packets. For brevity, the RTP packet header details have been excluded. Hatanaka Expires June 2004 [Page 4] Internet Draft January 2004 Packet 1: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 1 | Rsrvd | 1 | 0 | 1 | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATRAC data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet 2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 2 | Rsrvd | 0 | 0 | 1 | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...more ATRAC data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 3 | Rsrvd | 0 | 0 | 1 | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...the last of the ATRAC data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following points highlight important characteristics of the example above: -) the transition from one to zero of the Continuous bit (C) -) a sequential increase in the Fragment Number -) except for the first packet, a zero for the Number of Frames field 4 SDP Usage Certain attributes will need to be initiated before content can be streamed. For these purposes, the Session Description Protocol [3] should be used. Specifics in implementation are outside the scope of this document. However, the following attributes may prove useful. m = audio PortNumber (X-)ATRAC/44100/2 a = rtpmap:PT_ATRAC (X-)ATRAC/44100/2 a = fmtp:PT_ATRAC Profile [profile] FrameSampleSize [fsSize] BitRate [bps] ChannelConfigIndex [cci] Hatanaka Expires June 2004 [Page 5] Internet Draft January 2004 5 Security Considerations Certain security precautions may be desired to protect copyrighted material. The payload format as described in this document is subject to the security considerations defined in [1]. These security considerations imply the protection and confidentiality of the streamed content through encryption. Encryption may be performed on the encoded ATRAC since the compression scheme follows an end-to-end model. 6 References [1] RTP: A Transport Protocol for Real-Time Applications (RFC 1889) [2] RTP Payload Format for Vorbis Encoded Audio. Work in progress, draft-kerr-avt-rtp-vorbis-00.txt [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 7 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. 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 PROPOSE. Hatanaka Expires June 2004 [Page 6] Internet Draft January 2004 8 Authors' Addresses Mitsuyuki Hatanaka Sony Corporation 6-7-35 Kitashinagawa Shinagawa-ku Tokyo, 141-0001 Japan Email: hatanaka@av.crl.sony.co.jp Matthew Romaine Sony Corporation 6-7-35 Kitashinagawa Shinagawa-ku Tokyo, 141-0001 Japan Email: Matthew.Romaine@jp.sony.com Jun Matsumoto Sony Corporation 6-7-35 Kitashinagawa Shinagawa-ku Tokyo, 141-0001 Japan Email: jun@av.crl.sony.co.jp Hatanaka Expires June 2004 [Page 7] --Apple-Mail-21--201518565 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit ---------------------------------------- Matthew M.I. Romaine IMNC Audio Codec Group Sony Corporation phone: 03-5448-6065 fax: 03-5448-5617 ---------------------------------------- --Apple-Mail-21--201518565-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 02:23:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11412 for ; Thu, 22 Jan 2004 02:23:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZBL-0002zV-45 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 02:23:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M7NEYa011425 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 02:23:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZB8-0002uk-Pp; Thu, 22 Jan 2004 02:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZAp-0002pK-Qt for avt@optimus.ietf.org; Thu, 22 Jan 2004 02:22:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11354 for ; Thu, 22 Jan 2004 02:22:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjZAm-0004Fw-00 for avt@ietf.org; Thu, 22 Jan 2004 02:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjZ9p-0004EV-00 for avt@ietf.org; Thu, 22 Jan 2004 02:21:42 -0500 Received: from mta2.wss.scd.yahoo.com ([66.218.85.33]) by ietf-mx with esmtp (Exim 4.12) id 1AjZ9X-0004CQ-00 for avt@ietf.org; Thu, 22 Jan 2004 02:21:23 -0500 Received: from folly.herlein.com (198.144.205.235) by mta2.wss.scd.yahoo.com (7.0.016) (authenticated as gregh@arkstream.com) id 3FFD94F5008D3C14 for avt@ietf.org; Wed, 21 Jan 2004 23:20:54 -0800 Date: Wed, 21 Jan 2004 23:20:54 -0800 (PST) From: Greg Herlein X-X-Sender: gregh@folly.herlein.com To: avt@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] RFC2250 Profile Implementations? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Does anyone know of any RFC2250 implementations that are open source - particularly that support MPEG transport streams? Second, can anyoneconfirm which streaming servers that support RTP also support this RFC? I'm double checking my own research, and just wondering if I missed any... Thanks in advance, Greg Herlein _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 02:54:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12560 for ; Thu, 22 Jan 2004 02:54:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZfB-0006z0-55 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 02:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M7s5QE026795 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 02:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZf7-0006xc-0V; Thu, 22 Jan 2004 02:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZem-0006x4-Le for avt@optimus.ietf.org; Thu, 22 Jan 2004 02:53:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12552 for ; Thu, 22 Jan 2004 02:53:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjZei-0005BD-00 for avt@ietf.org; Thu, 22 Jan 2004 02:53:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjZdm-0005AI-00 for avt@ietf.org; Thu, 22 Jan 2004 02:52:38 -0500 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1AjZdc-00059G-00 for avt@ietf.org; Thu, 22 Jan 2004 02:52:28 -0500 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jan 2004 09:51:57 +0200 Message-ID: From: "Even, Roni" To: "'Matthew Romaine'" , avt@ietf.org Cc: Mitsuyuki Hatanaka , Jun Matsumoto Subject: RE: [AVT] pre-submission of rtp payload for atrac-family Date: Thu, 22 Jan 2004 09:51:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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, A small question, I did not see any reference in the draft for the codec itself, is it a publicly available codec Thanks Roni Even ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Matthew Romaine [mailto:Matthew.Romaine@jp.sony.com] Sent: Thursday, January 22, 2004 5:34 AM To: avt@ietf.org Cc: Mitsuyuki Hatanaka; Jun Matsumoto Subject: [AVT] pre-submission of rtp payload for atrac-family Hello avt groupers (particularly Colin and Magnus), I have attached an rtp payload format for the ATRAC family of audio codecs Sony has been developing. Some of you may be familiar with the ATRAC-X payload we were working on last year. With a bit of guidance from Mangus, we have decided to considerably simplify the payload, while at the same time generalize it so that previous ATRAC codecs, which are still widely used, could be included. As I seek comments from listers on what needs to be fixed and clarified, I have a question about the naming convention. Must we treat this as a completely new payload format (-00), which would mean committing to an earlier deadline, or can we consider this a continued revision of previous submissions (making this a -04)? Please fire away with comments. Thanks, Matt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 03:36:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13593 for ; Thu, 22 Jan 2004 03:36:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaJv-0001NQ-Eh for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 03:36:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M8aBMw005240 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 03:36:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaJn-0001GE-4b; Thu, 22 Jan 2004 03:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaJR-0001F5-3Q for avt@optimus.ietf.org; Thu, 22 Jan 2004 03:35:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13564 for ; Thu, 22 Jan 2004 03:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjaJO-0006dy-00 for avt@ietf.org; Thu, 22 Jan 2004 03:35:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjaIV-0006bY-00 for avt@ietf.org; Thu, 22 Jan 2004 03:34:43 -0500 Received: from ns5.sony.co.jp ([137.153.0.45]) by ietf-mx with esmtp (Exim 4.12) id 1AjaHZ-0006ZG-00 for avt@ietf.org; Thu, 22 Jan 2004 03:33:45 -0500 Received: from mail21.sony.co.jp (mail21.sony.co.jp [43.0.1.221]) Received: from mail21.sony.co.jp (localhost [127.0.0.1]) by mail21.sony.co.jp (R8/Sony) with ESMTP id i0M8Xhix029609 for ; Thu, 22 Jan 2004 17:33:43 +0900 (JST) Received: from jptkyxim01.jp.sony.com (jptkyxim01.jp.sony.com [43.15.17.87]) by mail21.sony.co.jp (R8/Sony) with ESMTP id i0M8XhJc029597 for ; Thu, 22 Jan 2004 17:33:43 +0900 (JST) Received: from jptkyxwa01.jp.sony.com ([43.15.31.1]) by jptkyxim01.jp.sony.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 Jan 2004 17:33:39 +0900 Received: from [43.13.117.153] ([43.13.117.153]) by jptkyxwa01.jp.sony.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 Jan 2004 17:33:39 +0900 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, Mitsuyuki Hatanaka , Jun Matsumoto From: Matthew Romaine Subject: Re: [AVT] pre-submission of rtp payload for atrac-family Date: Thu, 22 Jan 2004 17:33:41 +0900 To: "Even, Roni" X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 22 Jan 2004 08:33:39.0525 (UTC) FILETIME=[6F7D0F50:01C3E0C2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Roni, The codec itself is proprietary, so details are only available through licensing. Thanks, Matt On 2004/01/22, at 16:51, Even, Roni wrote: > Hi, > A small question, I did not see any reference in the draft for the > codec > itself, is it a publicly available codec > Thanks > Roni Even > > ************************************* > Roni Even > > Polycom Israel > > Tel: +972-3-9251200 > Cell: +972-55-481099 > email:roni.even@polycom.co.il > ******************************************* _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 03:41:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13772 for ; Thu, 22 Jan 2004 03:41:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaOe-00025c-KU for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 03:41:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M8f4Nt007872 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 03:41:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaOb-00022e-9v; Thu, 22 Jan 2004 03:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaOK-00020I-Fr for avt@optimus.ietf.org; Thu, 22 Jan 2004 03:40:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13756 for ; Thu, 22 Jan 2004 03:40:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjaOI-0006sb-00 for avt@ietf.org; Thu, 22 Jan 2004 03:40:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjaNO-0006rA-00 for avt@ietf.org; Thu, 22 Jan 2004 03:39:47 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AjaNB-0006p1-00 for avt@ietf.org; Thu, 22 Jan 2004 03:39:33 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0M8dWYG020208; Thu, 22 Jan 2004 09:39:32 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3JQ67F; Thu, 22 Jan 2004 09:42:26 +0100 Message-ID: <400F8BEA.8040605@ericsson.com> Date: Thu, 22 Jan 2004 09:38:02 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Colin Perkins CC: gunnar.hellstrom@omnitor.se, paulej@packetizer.com, avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-avt-rfc2793bis-01 References: <400EBB85.3060704@ericsson.com> <20040121202644.6eb04350.csp@csperkins.org> In-Reply-To: <20040121202644.6eb04350.csp@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, Okay, some further comments. Sorry for including the wrong address to Gunnar (its an .se not .com address). Colin Perkins wrote: >--> Magnus Westerlund writes: > > >>Hi Gunnar and Paul, >> >>Here is my comments on the payload format. >> >> >... > > >>12. In regards to the robustness options. As we now have available >>mechanism to report packet losses, RFC 3611, but probably more >> >> >important > > >>draft-ietf-avt-rtcp-feedback and its NACK format, there is now >>possibilities to do reactive repairs. I think the possibility should >> >> >at > > >>least be mentioned, or if it doesn't work, that should be motivated. >>Please investigate this. >> >> > >Unless specified otherwise, it should be assumed that the standard, >payload >format independent, repair schemes can be used with any new payload >format. >I don't see any need to list them specially here. > > Yes, your right. Although I like to make people more aware of the possibilities, it is probably a less good idea to create unnecessary convolution. > > >>14. Section 6.3: The RED SDP examples. Why does on have a=fmtp lines >>like this? To my understanding of the pt list it should only contain a >> >> > > > >>single 98. This is either a bug here, or problem in the text/red >>document. >> >> > >The SDP fragments such as > > m=text 11000 RTP/AVP 98 100 > a=rtpmap:98 t140/1000 > a=rtpmap:100 red/1000 > a=fmtp:100 98/98 > >appear to be correct. The "a=fmtp:100 98/98" line indicates that both >primary and redundant coding use payload type 98. > > I think we have an inconsistency between the MIME type registrations in RFC 3555 and draft-ietf-avt-text-red, and whats in RFC 2198. In the RFC 3555 the following is written about the payload type list paramter: Required parameters: pt: a comma-separated list of RTP payload types. Because comma is a special character, the list must be a quoted-string (enclosed in double quotes). For static payload types, each list element is simply the type number. For dynamic payload types, each list element is a mapping of the dynamic payload type number to an embedded MIME content-type specification for the payload format corresponding to the dynamic payload type. The format of the mapping is: dynamic-payload-type "=" content-type If the content-type string includes a comma, then the content-type string MUST be a quoted-string. If the content- type string does not include a comma, it MAY still be quoted. Since it is part of the list which must itself be a quoted- string, that means the quotation marks MUST be quoted with backslash quoting as specified in RFC 2045. If the content- type string itself contains a quoted-string, then the requirement for backslash quoting is recursively applied. To specify the audio/RED payload format in SDP, the pt parameter is mapped to an a=fmtp attribute by eliminating the parameter name (pt) and changing the commas to slashes. For example, 'pt="0,5"' maps to 'a=fmtp:99 0/5'. A more complicated example, with a dynamic payload type, is: pt = "0, 103 = \"audio/G729D;annexb=yes\" " m=audio 49170 RTP/AVP 99 0 103 a=rtpmap:99 RED/8000 a=fmtp:99 0/103 a=rtpmap:103 G729D/8000 a=fmtp:103 annexb=yes In RFC 2198 the following paragraph can be found: To receive a redundant stream, this is all that is required. However to send a redundant stream, the sender needs to know which codecs are recommended for the primary and secondary (and tertiary, etc) encodings. This information is specific to the redundancy format, and is specified using an additional attribute "fmtp" which conveys format-specific information. A session directory does not parse the values specified in an fmtp attribute but merely hands it to the media tool unchanged. For redundancy, we define the format parameters to be a slash "/" separated list of RTP payload types. Thus a complete example is: m=audio 12345 RTP/AVP 121 0 5 a=rtpmap:121 red/8000/1 a=fmtp:121 0/5 This specifies that the default format for senders is redundancy with PCM as the primary encoding and DVI as the secondary encoding. Encodings cannot be specified in the fmtp attribute unless they are also specified as valid encodings on the media ("m=") line. So how do we resolve this. I think that the intention of declaring primary and secondary codec looks nice but is not really necessary and has problems. I think the most important factor is to know which PTs that may appear in the RED format so be able to set up the correct processing. The reason I think the primary/secondary concept is wrong is the case where you have more than two codecs, and the possibility that more than one is in fact the primary. An example of this is when having congestion control indication that the bandwidht must be reduced. Then maybe the best way of doing this is to switch primary encoding while still using redundancy. In this case the RFC 2198 language can't express it. This needs to be resolved for the text/RED MIME registration. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 03:48:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13936 for ; Thu, 22 Jan 2004 03:48:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaVR-0002dn-Sb for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 03:48:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M8m56i010126 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 03:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaVN-0002ch-U3; Thu, 22 Jan 2004 03:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjaV7-0002b7-JZ for avt@optimus.ietf.org; Thu, 22 Jan 2004 03:47:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13925 for ; Thu, 22 Jan 2004 03:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjaV5-00077F-00 for avt@ietf.org; Thu, 22 Jan 2004 03:47:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjaU7-000758-00 for avt@ietf.org; Thu, 22 Jan 2004 03:46:43 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AjaTB-00073E-00 for avt@ietf.org; Thu, 22 Jan 2004 03:45:46 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0M8jhYG021520; Thu, 22 Jan 2004 09:45:43 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDHR5KS; Thu, 22 Jan 2004 09:45:43 +0100 Message-ID: <400F8D5D.7090006@ericsson.com> Date: Thu, 22 Jan 2004 09:44:13 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Matthew Romaine CC: avt@ietf.org, Mitsuyuki Hatanaka , Jun Matsumoto Subject: Re: [AVT] pre-submission of rtp payload for atrac-family References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Matthew, Matthew Romaine wrote: >As I seek comments from listers on what needs to be fixed and >clarified, I have a question about the naming convention. Must we >treat this as a completely new payload format (-00), which would mean >committing to an earlier deadline, or can we consider this a continued >revision of previous submissions (making this a -04)? > > The numbering of the version of drafts is in relation to the rest of the name. As you have changed it, correctly (in my opinion) as you have changed the scope, this draft should be submitted as 00. Please submit this version AS IT IS to the internet-drafts@ietf.org to avoid any future confusion about the numbering. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 04:04:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14157 for ; Thu, 22 Jan 2004 04:04:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajakw-0003Qp-Ak for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 04:04:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M946TD013190 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 04:04:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajakr-0003QC-Ig; Thu, 22 Jan 2004 04:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjakY-0003PI-BU for avt@optimus.ietf.org; Thu, 22 Jan 2004 04:03:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14154 for ; Thu, 22 Jan 2004 04:03:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjakV-0007Ug-00 for avt@ietf.org; Thu, 22 Jan 2004 04:03:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajajb-0007Tf-00 for avt@ietf.org; Thu, 22 Jan 2004 04:02:44 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AjajP-0007SG-00 for avt@ietf.org; Thu, 22 Jan 2004 04:02:31 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0M92WYG025512; Thu, 22 Jan 2004 10:02:32 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZJB4KNAW; Thu, 22 Jan 2004 10:04:30 +0100 Message-ID: <400F914E.9090006@ericsson.com> Date: Thu, 22 Jan 2004 10:01:02 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> In-Reply-To: <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Paul, [CCing the AVT list as there are issues here that needs open discussion] Response inline. Paul E. Jones wrote: >Magnus, > >I'll try to make these changes. I have questions for clarification: > > > >>1. Section 3: rate parameter: I think the "may" in the last sentence >>should be a normative one. >> >> > >What do you mean by "normative"? > You should use normative language, in other words the MAY normative word that you use through reference to RFC 2119. > > > >>5. Section 4, the last bullet for the "pt" list. This is under >>specified, the following problems exist: >>- The removal or not of <"> quoting etc. is not defined. >> >> > >Are you suggesting that people would not necessarily know if the quotes >are >part of the syntax or not? > > You are stripping the outer quotation marks, are you leaving the inner in place, in there converted form, or do you change to standard quotation? > > >>- How to handle any "dynamic-payload-type "=" content-type" string is >>also not explained. >> >> > >I do not understand your concern. Can you explain further? > > When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the pt=content-type structure at all. As the information is available in the SDP as defined PT. Therefore you only need to reference these PTs. So when having SDP should you in fact remove all of these pt=content-type declarations and only use PTs in the list? I would also like to point out that the this declaration of "dynamic-payload-type "=" content-type" is not sufficiently clear. For RTP payload formats using parameters to configure this, this string is insufficient unless the parameter list can be included in the content-type part. > > >>7. Section 5: A proposal for how to handle the security problem is >>always good. Proposal: "To prevent modification of the primary, >>secondary or header information, payload integrity protection over at >>least the complete RTP packet is recommend, for example using SRTP >> >> >[]." > >I agree with the added text, but concerned about referencing SRTP >explicitly. Will the RFC be published before this document? I do not >want >to hold up progress due to a reference. Would be be OK to leave off >"for >example using SRTP"? > The SRTP is in the RFC editors queue, so yes, it will be available before this document. Put SRTP into the informative reference list and write an RFC editors note that request that he replace the draft reference with the RFC number when it becomes available. > > > >>8. Section 6, The first reference is an informative one, please move >> >> >it > > >>to an informative reference list. Also reference 7 is not used at all, >>please remove. >> >> > >I can do that. What about 7, as well (RFC 3555)? > > > >>I expect that the when these things are addressed the document is >> >> >ready > > >>for WG last call. >> >> > >I've got all changes made, except those that are questions above. >Looking >forward to your reply... and thank you very much for your careful >review. > > Great! Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 05:56:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16435 for ; Thu, 22 Jan 2004 05:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjcVJ-0000ss-Hz for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 05:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MAu5oO003392 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 05:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjcVG-0000rx-Bu; Thu, 22 Jan 2004 05:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjcUz-0000qq-3L for avt@optimus.ietf.org; Thu, 22 Jan 2004 05:55:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16412 for ; Thu, 22 Jan 2004 05:55:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjcUv-0003L8-00 for avt@ietf.org; Thu, 22 Jan 2004 05:55:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjcTw-0003JB-00 for avt@ietf.org; Thu, 22 Jan 2004 05:54:41 -0500 Received: from rrcs-midsouth-24-199-215-15.biz.rr.com ([24.199.215.15] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AjcT3-0003HI-00 for avt@ietf.org; Thu, 22 Jan 2004 05:53:45 -0500 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id i0MArhVC019734; Thu, 22 Jan 2004 05:53:44 -0500 Message-ID: <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> From: "Paul E. Jones" To: "Magnus Westerlund" Cc: References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt Date: Thu, 22 Jan 2004 05:51:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Magnus, > >>1. Section 3: rate parameter: I think the "may" in the last sentence > >>should be a normative one. > >> > >> > > > >What do you mean by "normative"? > > > > You should use normative language, in other words the MAY normative word > that you use through reference to RFC 2119. Got it.. it's now MAY. As a general question, why would capitalization suggest a different meaning? > >>5. Section 4, the last bullet for the "pt" list. This is under > >>specified, the following problems exist: > >>- The removal or not of <"> quoting etc. is not defined. > >> > >> > > > >Are you suggesting that people would not necessarily know if the quotes > >are > >part of the syntax or not? > > > > > You are stripping the outer quotation marks, are you leaving the inner > in place, in there converted form, or do you change to standard quotation? Well, this is a good question. Clearly, I know what the end result is to be, but how should this be written? The text I am using was borrowed from RFC 3555, which uses the same notation. Please suggest specific changes to clarify this. > >>- How to handle any "dynamic-payload-type "=" content-type" string is > >>also not explained. > >> > >> > > > >I do not understand your concern. Can you explain further? > > > > > > When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the > pt=content-type structure at all. As the information is available in the > SDP as defined PT. Therefore you only need to reference these PTs. So > when having SDP should you in fact remove all of these pt=content-type > declarations and only use PTs in the list? > > I would also like to point out that the this declaration of > "dynamic-payload-type "=" content-type" is not sufficiently clear. For > RTP payload formats using parameters to configure this, this string is > insufficient unless the parameter list can be included in the > content-type part. Ah, I understand. As I mentioned above, this follows the example in RFC 3555, which also does not go into discussion on this (as far as I know). I assume the reason for that was simply that the entire focus was on SDP, anyway, with little focus on MIME, really. In any case, I can add text in this regard, but I need some guidance as to what we should have inserted to make this clearer. > >>7. Section 5: A proposal for how to handle the security problem is > >>always good. Proposal: "To prevent modification of the primary, > >>secondary or header information, payload integrity protection over at > >>least the complete RTP packet is recommend, for example using SRTP > >> > >> > >[]." > > > >I agree with the added text, but concerned about referencing SRTP > >explicitly. Will the RFC be published before this document? I do not > >want > >to hold up progress due to a reference. Would be be OK to leave off > >"for > >example using SRTP"? > > > > The SRTP is in the RFC editors queue, so yes, it will be available > before this document. Put SRTP into the informative reference list and > write an RFC editors note that request that he replace the draft > reference with the RFC number when it becomes available. OK.. no problem. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 07:22:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18406 for ; Thu, 22 Jan 2004 07:22:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdqZ-0005Pk-B0 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 07:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MCM7rD020809 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 07:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdqT-0005Ou-9H; Thu, 22 Jan 2004 07:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdqM-0005OY-Th for avt@optimus.ietf.org; Thu, 22 Jan 2004 07:21:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18315 for ; Thu, 22 Jan 2004 07:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjdqM-0006m0-00 for avt@ietf.org; Thu, 22 Jan 2004 07:21:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajdja-0006Fd-00 for avt@ietf.org; Thu, 22 Jan 2004 07:14:54 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Ajdh2-0005wK-00 for avt@ietf.org; Thu, 22 Jan 2004 07:12:16 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0MCBnqY015575; Thu, 22 Jan 2004 13:11:49 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZDHT016; Thu, 22 Jan 2004 13:11:49 +0100 Message-ID: <400FBDAA.1050208@ericsson.com> Date: Thu, 22 Jan 2004 13:10:18 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> In-Reply-To: <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul, Comments inline. Paul E. Jones wrote: >Got it.. it's now MAY. As a general question, why would capitalization >suggest a different meaning? > > This is due to that you have defined to have a separate meaning when you include the following statement in regards to RFC 2119. 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. The reason why you do this is that in most case you desire to separate the cases when something really must be followed, i.e. being normative, and when it is only for information and does not carry necessary the same strict meaning. You really should read RFC 2119, its only 3 pages. >Well, this is a good question. Clearly, I know what the end result is >to >be, but how should this be written? The text I am using was borrowed >from >RFC 3555, which uses the same notation. Please suggest specific changes >to >clarify this. > > > I think we need to resolve what discrepancy we have between RFC 2198 and RFC 3555 before being able to close this issue. However I don't think that much text is required, just being explicit about it. >>> >>> >>When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the >>pt=content-type structure at all. As the information is available in >> >> >the > > >>SDP as defined PT. Therefore you only need to reference these PTs. So >>when having SDP should you in fact remove all of these pt=content-type >>declarations and only use PTs in the list? >> >>I would also like to point out that the this declaration of >>"dynamic-payload-type "=" content-type" is not sufficiently clear. For >>RTP payload formats using parameters to configure this, this string is >>insufficient unless the parameter list can be included in the >>content-type part. >> >> > >Ah, I understand. As I mentioned above, this follows the example in RFC >3555, which also does not go into discussion on this (as far as I know). >I >assume the reason for that was simply that the entire focus was on SDP, >anyway, with little focus on MIME, really. > >In any case, I can add text in this regard, but I need some guidance as >to >what we should have inserted to make this clearer. > > > I would definitely like to have some more input from Colin and others about how this problem should be resolved. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 22 09:32:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22317 for ; Thu, 22 Jan 2004 09:32:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjfsO-0004Tb-Fv for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 09:32:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MEW8fD017206 for avt-archive@odin.ietf.org; Thu, 22 Jan 2004 09:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjfsH-0004Sh-Ao; Thu, 22 Jan 2004 09:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjfrL-0004Rc-JK for avt@optimus.ietf.org; Thu, 22 Jan 2004 09:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22261 for ; Thu, 22 Jan 2004 09:30:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajfr9-0004g8-00 for avt@ietf.org; Thu, 22 Jan 2004 09:30:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajfng-0004Zd-00 for avt@ietf.org; Thu, 22 Jan 2004 09:27:17 -0500 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AjflD-0004PP-00 for avt@ietf.org; Thu, 22 Jan 2004 09:24:43 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i0ME0VKU003081 for ; Thu, 22 Jan 2004 08:23:48 -0600 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 400ABCEB001E9587; Thu, 22 Jan 2004 09:23:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jan 2004 08:23:45 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3849@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Thread-Index: AcPYodDrRUJs23mBSa+NKC8FcnAyPAITEcagAAA2tFA= From: "Ash, Gerald R (Jerry), ALABS" To: "Lars-Erik Jonsson (LU/EAB)" , "Colin Perkins" , Cc: "Ash, Gerald R (Jerry), ALABS" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Colin & Lars-Erik, Thanks very much for your comments and suggestions. In addition to all = of your editorial suggestions, the changes to the updated draft will = include: > In a number of places, the draft describes "using MPLS to route ECRTP > compressed packets over multiple router hops". Does this mean routing > compressed packets over an MPLS LSP? If so, I recommend clarifying the > draft to prevent confusion with multiple IP hops. Changed the language as suggested. =20 > I'm not sure discussion of access links is appropriate, since MPLS is > unlikely to be used in this scenario. We now refer to 'low-speed' links rather than 'access links'. It's = debatable how far MPLS will extend. =20 > In section 3, the requirements list ECRTP without discussion.=20 > I think ECRTP is an appropriate solution, but it would be useful to=20 > motivate the choice by discussing the requirements for the=20 > compression. This is particularly important, since there are=20 > alternative algorithms (e.g. ROHC) that may be considered. We've added discussion as suggested. ECRTP should be used to make ECRTP = over MPLS more tolerant of packet loss, to guard against frequent = resynchronizations, and to minimize the need for error recovery. ROHC = can also be considered, however ROHC does not accommodate packet = reordering to protect against out-of-sequence packets, which can occur = on MPLS LSPs. We didn't change the title of the document, as suggested = by L-E, since Colin specifically suggested the current title, and that = also corresponds to the AVT milestone. =20 > In section 3, the draft notes that protocol extensions may be=20 > required for ECRTP. Are these changes to ECRTP or a mapping of > ECRTP onto a new "link" layer? If the latter, the draft could > do with clarification. The draft should discuss the type of > extension needed for RSVP-TE and LDP, since this will feed=20 > into any new work plan. We've added text on protocol extensions required for ECRTP, RSVP-TE, and = LDP > Security considerations: Are there no issues with DoS attacks on MPLS > routers, due to the increased number of flows? We've added text to discuss DoS attacks in the security section. > Before publication, the draft will need an IANA Considerations section > (even if it just says "No IANA actions are required") and the=20 > IPR boiler-plate. We've added an IANA Considerations Section and Intellectual Property = Statement Section. Thanks, Jerry _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 23 19:17:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04495 for ; Fri, 23 Jan 2004 19:17:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkBU3-00028Q-Dw for avt-archive@odin.ietf.org; Fri, 23 Jan 2004 19:17:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0O0H7hB008157 for avt-archive@odin.ietf.org; Fri, 23 Jan 2004 19:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkBTw-00026y-7i; Fri, 23 Jan 2004 19:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkBTs-00026c-6z for avt@optimus.ietf.org; Fri, 23 Jan 2004 19:16:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04481 for ; Fri, 23 Jan 2004 19:16:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkBTq-00077t-00 for avt@ietf.org; Fri, 23 Jan 2004 19:16:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkBSs-00076b-00 for avt@ietf.org; Fri, 23 Jan 2004 19:15:54 -0500 Received: from mta2.wss.scd.yahoo.com ([66.218.85.33]) by ietf-mx with esmtp (Exim 4.12) id 1AkBRv-00074a-00 for avt@ietf.org; Fri, 23 Jan 2004 19:14:55 -0500 Received: from folly.herlein.com (198.144.205.235) by mta2.wss.scd.yahoo.com (7.0.016) (authenticated as gregh@arkstream.com) id 3FFD94F5009E4AA5 for avt@ietf.org; Fri, 23 Jan 2004 16:14:25 -0800 Date: Fri, 23 Jan 2004 16:14:25 -0800 (PST) From: Greg Herlein X-X-Sender: gregh@folly.herlein.com To: avt@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] RFC2250 (DVB UDP) MPEG2 Encapsulation - 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: , Does anyone know of a shipping client that definitely supports rfc2250 (or it's big brother, the DVB spec for MPEG2-TS in RTP in UDP)? I'm looking for other clients - software or hardware - that actually support this (for real). There's a lot of confusion out there regarding what protocols folks really mean when they toss of the phrase "MPEG2 in UDP" - and I'm trying to nail down firmly which support the right way (tm). Greg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jan 25 21:22:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00561 for ; Sun, 25 Jan 2004 21:22:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkwOF-0005P6-VR for avt-archive@odin.ietf.org; Sun, 25 Jan 2004 21:22:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0Q2MFRC020723 for avt-archive@odin.ietf.org; Sun, 25 Jan 2004 21:22:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkwO0-0005Mw-Qs; Sun, 25 Jan 2004 21:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkwNa-0005M9-No for avt@optimus.ietf.org; Sun, 25 Jan 2004 21:21:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00510 for ; Sun, 25 Jan 2004 21:21:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkwNY-00048F-00 for avt@ietf.org; Sun, 25 Jan 2004 21:21:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkwMb-00045U-00 for avt@ietf.org; Sun, 25 Jan 2004 21:20:33 -0500 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1AkwLm-00043Y-00 for avt@ietf.org; Sun, 25 Jan 2004 21:19:42 -0500 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0Q2Jgf4029621 for ; Sun, 25 Jan 2004 18:19:43 -0800 (PST) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0Q2JgkP010460 for ; Sun, 25 Jan 2004 18:19:42 -0800 (PST) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HS2RSS00.BQX for ; Sun, 25 Jan 2004 18:19:40 -0800 Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <1829D27A-4FA6-11D8-9314-00039372C384@eecs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: avt@ietf.org From: "John Lazzaro" Date: Sun, 25 Jan 2004 18:19:39 -0800 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Updated RTP MIDI 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: , Content-Transfer-Encoding: 7bit Hi everyone, Sent off the updated versions of the RTP MIDI payload format document (draft-ietf-avt-rtp-midi-format-01.txt) and implementation guide (draft-ietf-avt-rtp-midi-guidelines-01.txt) to internet-drafts@ietf.org yesterday. Pick up copies here: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt All of the bitfields have now been coded into sfront -- code to send and receive packets, and diagnostic code to print out packets in flight and to show how the receiver recovers from real (801.11b) and simulated packet loss. The change log describes fixes to bugs that were caught during sfront coding. Also, the SDP ABNF passes the IETF online validator. I think these documents are ready for Last Call -- i.e. this is the "candidate Last Call" release I referenced in earlier postings to the list. So, if you've been holding off reading the documents until I declared them "done" ... now is a good time to read them. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jan 26 04:20:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25874 for ; Mon, 26 Jan 2004 04:20:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2ul-00043Y-LG for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 04:20:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0Q9KFfc015542 for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 04:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2uX-00041c-Rf; Mon, 26 Jan 2004 04:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2tb-0003uI-UP for avt@optimus.ietf.org; Mon, 26 Jan 2004 04:19:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25834 for ; Mon, 26 Jan 2004 04:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al2tZ-00071h-00 for avt@ietf.org; Mon, 26 Jan 2004 04:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al2sp-0006yA-00 for avt@ietf.org; Mon, 26 Jan 2004 04:18:15 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Al2rw-0006sN-00 for avt@ietf.org; Mon, 26 Jan 2004 04:17:20 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0Q9HJqY014417; Mon, 26 Jan 2004 10:17:19 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CR3KPJZV; Mon, 26 Jan 2004 10:20:25 +0100 Message-ID: <4014DABD.3030105@ericsson.com> Date: Mon, 26 Jan 2004 10:15:41 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: "Paul E. Jones" , avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> <400FBDAA.1050208@ericsson.com> In-Reply-To: <400FBDAA.1050208@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 had some off-line discussion regarding the MIME registration problem for text/RED. Know understanding the intention having the ordering requirement on RFC 2198 being firm for the "pt" list, I would propose the following text change for the "pt" list: "pt: a comma-separated ordered list enumerating the primary, secondary, etc., encoding's RTP payload types in accordance with RFC 2198. Because comma is ..." Then one addition to the SDP section (4) is also needed in my opinion. Please add the following text where appropriate. "For each redundancy payload type defined the ordering of the primary, and redundancy encoding(s) are fixed. If more than one combination of primary, and redundancy encoding(s) are desired, multiple redundancy payload types needs to be defined." Then only the last issue below remains to be resolved as I see it. Cheers Magnus Magnus Westerlund wrote: > >>>> >>> >>> When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the >>> pt=content-type structure at all. As the information is available in >>> >> >> the >> >> >>> SDP as defined PT. Therefore you only need to reference these PTs. So >>> when having SDP should you in fact remove all of these pt=content-type >>> declarations and only use PTs in the list? >>> >>> I would also like to point out that the this declaration of >>> "dynamic-payload-type "=" content-type" is not sufficiently clear. For >>> RTP payload formats using parameters to configure this, this string is >>> insufficient unless the parameter list can be included in the >>> content-type part. >>> >> >> >> Ah, I understand. As I mentioned above, this follows the example in RFC >> 3555, which also does not go into discussion on this (as far as I know). >> I >> assume the reason for that was simply that the entire focus was on SDP, >> anyway, with little focus on MIME, really. >> >> In any case, I can add text in this regard, but I need some guidance as >> to >> what we should have inserted to make this clearer. >> >> >> > I would definitely like to have some more input from Colin and others > about how this problem should be resolved. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jan 26 20:03:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27271 for ; Mon, 26 Jan 2004 20:03:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdP-0001nR-0e for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 20:03:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R13IKw006894 for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 20:03:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdB-0001bT-QW; Mon, 26 Jan 2004 20:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al6dn-00025S-Bn for avt@optimus.ietf.org; Mon, 26 Jan 2004 08:18:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05242 for ; Mon, 26 Jan 2004 08:18:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al6dm-0005kQ-00 for avt@ietf.org; Mon, 26 Jan 2004 08:18:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al6cp-0005ib-00 for avt@ietf.org; Mon, 26 Jan 2004 08:18:00 -0500 Received: from rrcs-midsouth-24-199-215-15.biz.rr.com ([24.199.215.15] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1Al6cS-0005gc-00 for avt@ietf.org; Mon, 26 Jan 2004 08:17:36 -0500 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id i0QDHXZ2010202; Mon, 26 Jan 2004 08:17:34 -0500 Message-ID: <00a001c3e40e$7c61b8c0$e1cd6a9c@cisco.com> From: "Paul E. Jones" To: "Magnus Westerlund" Cc: References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> <400FBDAA.1050208@ericsson.com> <4014DABD.3030105@ericsson.com> Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt Date: Mon, 26 Jan 2004 08:15:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Magnus, > I have had some off-line discussion regarding the MIME registration > problem for text/RED. Know understanding the intention having the > ordering requirement on RFC 2198 being firm for the "pt" list, I would > propose the following text change for the "pt" list: > > "pt: a comma-separated ordered list enumerating the primary, secondary, > etc., encoding's RTP payload types in accordance with RFC 2198. Because > comma is ..." There was a desire early on not to explicitly tie the MIME registration to RFC 2198. Certainly, it is the main driver for producing the document, but it was viewed as not the only potential user of this registration. Thus, do we really want this text or just leave it as it is in the current draft? > Then one addition to the SDP section (4) is also needed in my opinion. > Please add the following text where appropriate. > > "For each redundancy payload type defined the ordering of the primary, > and redundancy encoding(s) are fixed. If more than one combination of > primary, and redundancy encoding(s) are desired, multiple redundancy > payload types needs to be defined." Perhaps you can educate me here, but why would the order matter? The payload format defined in RFC 2198 allows for the PT of the redundant data to be specified along with the payload. Thus, it seems that the ordering of is not so important. Of course, a distinction must be made between primary versus redundant, but it is not clear to me why this strict clause is needed. Please clarify. > Then only the last issue below remains to be resolved as I see it. And, how can we close on that issue below? Paul > > Cheers > > Magnus > > Magnus Westerlund wrote: > > > > >>>> > >>> > >>> When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the > >>> pt=content-type structure at all. As the information is available in > >>> > >> > >> the > >> > >> > >>> SDP as defined PT. Therefore you only need to reference these PTs. So > >>> when having SDP should you in fact remove all of these pt=content-type > >>> declarations and only use PTs in the list? > >>> > >>> I would also like to point out that the this declaration of > >>> "dynamic-payload-type "=" content-type" is not sufficiently clear. For > >>> RTP payload formats using parameters to configure this, this string is > >>> insufficient unless the parameter list can be included in the > >>> content-type part. > >>> > >> > >> > >> Ah, I understand. As I mentioned above, this follows the example in RFC > >> 3555, which also does not go into discussion on this (as far as I know). > >> I > >> assume the reason for that was simply that the entire focus was on SDP, > >> anyway, with little focus on MIME, really. > >> > >> In any case, I can add text in this regard, but I need some guidance as > >> to > >> what we should have inserted to make this clearer. > >> > >> > >> > > I would definitely like to have some more input from Colin and others > > about how this problem should be resolved. > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jan 26 20:03:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27278 for ; Mon, 26 Jan 2004 20:03:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdP-0001nV-16 for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 20:03:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R13IuM006892 for avt-archive@odin.ietf.org; Mon, 26 Jan 2004 20:03:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdI-0001iX-Si; Mon, 26 Jan 2004 20:03:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al7EZ-0004NC-Bq for avt@optimus.ietf.org; Mon, 26 Jan 2004 08:56:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06132 for ; Mon, 26 Jan 2004 08:56:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al7EX-00073W-00 for avt@ietf.org; Mon, 26 Jan 2004 08:56:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al7De-000720-00 for avt@ietf.org; Mon, 26 Jan 2004 08:56:02 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Al7Cz-0006zu-00 for avt@ietf.org; Mon, 26 Jan 2004 08:55:21 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0QDtJqY001679; Mon, 26 Jan 2004 14:55:19 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZD2V598; Mon, 26 Jan 2004 14:55:19 +0100 Message-ID: <40151BE4.1010503@ericsson.com> Date: Mon, 26 Jan 2004 14:53:40 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: avt@ietf.org CC: Colin Perkins Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] The need for Offer/Answer sections in RTP payload format specifications Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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 AVT members, We AVT chairs would like to make all writers of RTP payload format aware of one thing. There exist a need for most RTP payload formats to have a section discussing the usage of the MIME parameters in regards to the SDP Offer and Answer model defined in RFC 3264. This concerns all RTP payload formats that use parameters to configure either the payload format itself or the transported codec. The reason for these is to achieve the best possible interoperability. And the interoperability is affected in several ways through the use of MIME defined parameters. - Configuration of RTP payload formats and codecs: If one end-point A offers functionality set SA and end-point B offers another functionality set SB. Then it is possible that SA has no common subset with SB, thus preventing interoperability. - Understanding when offered set SA and supported set SB contains possibilities for sub-setting. Certain offered sets can be subsetted and still useful. A MIME specification should be explicit about if parameters can be downgraded or not. For example, an video profile level specification can be downgraded to a lower level in the response and still achieve interoperability. However an AMR payload format configuration parameter like "octet-align" is binary, i.e. requiring one to support this configuration. - Possibility to make recommendations on how to form offers that maximizes interoperability. However this is application dependent and should normally be kept in an more open terms. However for example for the AMR payload format can be configured into several usages. For some applications it does make sense to offer multiple payload types where the payload format is configured in different way. For example a streaming server can offer both a octet-aligned only PT and one with interleaving if they would use offer answer. Thus we request that authors write an "Offer-Answer model consideration" in their SDP usage section. This should cover the following: - How configurations effect the interoperability. - What parameters that are possible to subset and which are not. - Recommendations on how to achieve good interoperability. Comments on this are solicited. Best Regards Magnus & Colin -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 03:55:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25535 for ; Tue, 27 Jan 2004 03:55:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlP07-0001rK-Cz for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 03:55:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R8tFxD007146 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 03:55:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlOzv-0001qN-59; Tue, 27 Jan 2004 03:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlOzc-0001ps-4e for avt@optimus.ietf.org; Tue, 27 Jan 2004 03:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25509 for ; Tue, 27 Jan 2004 03:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlOzZ-0000xk-00 for avt@ietf.org; Tue, 27 Jan 2004 03:54:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlOyc-0000uk-00 for avt@ietf.org; Tue, 27 Jan 2004 03:53:43 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AlOy6-0000rV-00 for avt@ietf.org; Tue, 27 Jan 2004 03:53:10 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0R8rBAh001664; Tue, 27 Jan 2004 09:53:11 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CZD20ZYL; Tue, 27 Jan 2004 09:53:11 +0100 Message-ID: <40162693.4040805@ericsson.com> Date: Tue, 27 Jan 2004 09:51: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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> <400FBDAA.1050208@ericsson.com> <4014DABD.3030105@ericsson.com> <00a001c3e40e$7c61b8c0$e1cd6a9c@cisco.com> In-Reply-To: <00a001c3e40e$7c61b8c0$e1cd6a9c@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Paul, comments inline: Paul E. Jones wrote: >Magnus, > > > >>I have had some off-line discussion regarding the MIME registration >>problem for text/RED. Know understanding the intention having the >>ordering requirement on RFC 2198 being firm for the "pt" list, I would >>propose the following text change for the "pt" list: >> >>"pt: a comma-separated ordered list enumerating the primary, >> >> >secondary, > > >>etc., encoding's RTP payload types in accordance with RFC 2198. >> >> >Because > > >>comma is ..." >> >> > >There was a desire early on not to explicitly tie the MIME registration >to >RFC 2198. Certainly, it is the main driver for producing the document, >but >it was viewed as not the only potential user of this registration. >Thus, do >we really want this text or just leave it as it is in the current draft? > > No, It must be tied to RFC 2198. In my recollection the opinion expressed was to not tie it to RFC 2793. I think we should go with the new text, because I find the old text confusing as it does not inform explicitly that about the semantics of the parameter. >>Then only the last issue below, remains to be resolved as I see it. >> >> > >And, how can we close on that issue below? > > I don't know really, it seems that we should be compatible with what is used for audio/RED. However what is really used here is not totally clear. Based on the examples in RFC 2198 one does rely on having dynamic PTs to be declared through "a=rtpmap". What is you others opinion about this? Cheers Magnus > > >>Cheers >> >>Magnus >> >>Magnus Westerlund wrote: >> >> >> >>>>>When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the >>>>>pt=content-type structure at all. As the information is available >>>>> >>>>> >in > > >>>>the >>>> >>>> >>>> >>>> >>>>>SDP as defined PT. Therefore you only need to reference these PTs. >>>>> >>>>> >So > > >>>>>when having SDP should you in fact remove all of these >>>>> >>>>> >pt=content-type > > >>>>>declarations and only use PTs in the list? >>>>> >>>>>I would also like to point out that the this declaration of >>>>>"dynamic-payload-type "=" content-type" is not sufficiently clear. >>>>> >>>>> >For > > >>>>>RTP payload formats using parameters to configure this, this >>>>> >>>>> >string is > > >>>>>insufficient unless the parameter list can be included in the >>>>>content-type part. >>>>> >>>>> >>>>> >>>>Ah, I understand. As I mentioned above, this follows the example >>>> >>>> >in >RFC > > >>>>3555, which also does not go into discussion on this (as far as I >>>> >>>> >know). > > >>>>I >>>>assume the reason for that was simply that the entire focus was on >>>> >>>> >SDP, > > >>>>anyway, with little focus on MIME, really. >>>> >>>>In any case, I can add text in this regard, but I need some >>>> >>>> >guidance as > > >>>>to >>>>what we should have inserted to make this clearer. >>>> >>>> >>>> >>>> >>>> >>>I would definitely like to have some more input from Colin and >>> >>> >others > > >>>about how this problem should be resolved. >>> >>> >>> >>-- >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> >> >> > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 04:17:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26164 for ; Tue, 27 Jan 2004 04:17:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPLG-0003ar-LT for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 04:17:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R9H66n013764 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 04:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPLC-0003ZK-4L; Tue, 27 Jan 2004 04:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPKl-0003SC-LE for avt@optimus.ietf.org; Tue, 27 Jan 2004 04:16:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26130 for ; Tue, 27 Jan 2004 04:16:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlPKi-000242-00 for avt@ietf.org; Tue, 27 Jan 2004 04:16:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlPJp-00021u-00 for avt@ietf.org; Tue, 27 Jan 2004 04:15:37 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AlPJH-0001zc-00 for avt@ietf.org; Tue, 27 Jan 2004 04:15:03 -0500 Received: from MCOMREYJ ([10.10.100.173]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Jan 2004 10:14:25 +0100 From: "Jose Rey" To: Cc: "Joerg Ott" , "Noriyuki Sato" , Date: Tue, 27 Jan 2004 10:14:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-OriginalArrivalTime: 27 Jan 2004 09:14:25.0557 (UTC) FILETIME=[F580AC50:01C3E4B5] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA26131 Subject: [AVT] FW: draft-burmeister-avt-rtcp-feedback-sim-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: quoted-printable Dear all, the Last Call period for the RTCP Feedback Sims draft has ended. ADs had minor comments addressed by this update. The revised draft (draft-burmeister-avt-rtcp-feedback-sim-03.txt) was sent yesterday to the= ID manager. Meanwhile you can download it from: http://www.pel.panasonic.de/ietf/docs/draft-burmeister-avt-rtcp-feedback-= sim -03.txt cheers, Jos=E9 > -----Original Message----- > From: Jose Rey [mailto:rey@panasonic.de] > Sent: Monday, January 26, 2004 5:46 PM > To: internet-drafts@ietf.org > Cc: magnus.westerlund@era.ericsson.se; Colin Perkins > Subject: draft-burmeister-avt-rtcp-feedback-sim-03.txt > > > > Dear I-D editors, > > this is to submit the following Internet Draft for continued > discussion in the AVT Working Group: > > Title: Extended RTP Profile for RTCP-based Feedback > - Results of the Timing Rule Simulations - > Authors: Burmeister, et al. > Date: January, 26th 2004 > File name: draft-burmeister-avt-rtcp-feedback-sim-03.txt > > > > cheers, > Jos=E9 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 04:24:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26295 for ; Tue, 27 Jan 2004 04:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPS0-000436-1p for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 04:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R9O3IB015529 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 04:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPRw-00041w-Ou; Tue, 27 Jan 2004 04:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPRW-00040D-8j for avt@optimus.ietf.org; Tue, 27 Jan 2004 04:23:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26279 for ; Tue, 27 Jan 2004 04:23:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlPRT-0002MC-00 for avt@ietf.org; Tue, 27 Jan 2004 04:23:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlPQX-0002Jt-00 for avt@ietf.org; Tue, 27 Jan 2004 04:22:34 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AlPPb-0002Fj-00 for avt@ietf.org; Tue, 27 Jan 2004 04:21:35 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63161 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AlPP0-0001oR-00; Tue, 27 Jan 2004 09:20:58 +0000 Date: Tue, 27 Jan 2004 09:21:13 +0000 From: Colin Perkins To: Magnus Westerlund Cc: paulej@packetizer.com, avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt Message-Id: <20040127092113.0e4d55a8.csp@csperkins.org> In-Reply-To: <40162693.4040805@ericsson.com> References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> <400FBDAA.1050208@ericsson.com> <4014DABD.3030105@ericsson.com> <00a001c3e40e$7c61b8c0$e1cd6a9c@cisco.com> <40162693.4040805@ericsson.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 --> Magnus Westerlund writes: ... > I don't know really, it seems that we should be compatible with what is > used for audio/RED. However what is really used here is not totally > clear. Based on the examples in RFC 2198 one does rely on having dynamic > PTs to be declared through "a=rtpmap". > > What is you others opinion about this? RFC 2198 requires strict ordering so the sender knows which is the primary encoding, and which is the redundant. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 04:29:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26389 for ; Tue, 27 Jan 2004 04:29:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPWr-0004M9-Ti for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 04:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R9T51t016698 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 04:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPWo-0004KQ-03; Tue, 27 Jan 2004 04:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlPWM-0004JC-Fo for avt@optimus.ietf.org; Tue, 27 Jan 2004 04:28:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26378 for ; Tue, 27 Jan 2004 04:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlPWJ-0002Yu-00 for avt@ietf.org; Tue, 27 Jan 2004 04:28:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlPVP-0002X0-00 for avt@ietf.org; Tue, 27 Jan 2004 04:27:35 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AlPUk-0002Ut-00 for avt@ietf.org; Tue, 27 Jan 2004 04:26:54 -0500 Received: from MCOMREYJ ([10.10.100.173]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Jan 2004 10:26:17 +0100 From: "Jose Rey" To: Cc: "Colin Perkins" , "Magnus Westerlund" , "David Leon" , "Viktor Varsa" Date: Tue, 27 Jan 2004 10:26:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-OriginalArrivalTime: 27 Jan 2004 09:26:17.0491 (UTC) FILETIME=[9DD92E30:01C3E4B7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA26379 Subject: [AVT] FW: draft-ietf-avt-rtp-retransmission-10.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, the last revision of the RTP Retransmission Payload Format was already se= nt to the ID manager. Meanwhile, you can download it under: http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtp-retransmission-1= 0.t xt Changes: + some comments regarding the clarification of the IPR issues have been addressed in the introduction. + additionally, some normative language nits were corrected in section 4. + no changes in the contents Colin, I think it is appropriate to re-issue Last Call at this point cheers, Jos=E9 > -----Original Message----- > From: Jose Rey [mailto:rey@panasonic.de] > Sent: Monday, January 26, 2004 5:46 PM > To: IETF I-D Submission > Cc: Colin Perkins; Magnus Westerlund; David Leon > Subject: draft-ietf-avt-rtp-retransmission-10.txt > > > > Dear I-D editors, > > this is to submit the following Internet Draft for continued > discussion in the AVT Working Group: > > Title: RTP Retransmission Payload Format > Authors: Rey, et al. > Date: January, 26th 2004 > File name: draft-ietf-avt-rtp-retransmission-10.txt > > > > cheers, > > Jose _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 05:25:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28090 for ; Tue, 27 Jan 2004 05:25:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQPA-0007xa-IY for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 05:25:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RAPCnq030586 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 05:25:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQOz-0007wh-Vf; Tue, 27 Jan 2004 05:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQOe-0007wI-Oc for avt@optimus.ietf.org; Tue, 27 Jan 2004 05:24:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28041 for ; Tue, 27 Jan 2004 05:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlQOb-0005VO-00 for avt@ietf.org; Tue, 27 Jan 2004 05:24:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlQNg-0005T3-00 for avt@ietf.org; Tue, 27 Jan 2004 05:23:41 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AlQNJ-0005QZ-00 for avt@ietf.org; Tue, 27 Jan 2004 05:23:17 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i0RANF024993; Tue, 27 Jan 2004 11:23:15 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i0RANAZ07211; Tue, 27 Jan 2004 11:23:10 +0100 (MET) Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA01600; Tue, 27 Jan 2004 11:22:53 +0100 (MET) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 11:23:05 +0100 Message-ID: From: Belling Thomas To: "'Magnus Westerlund'" , avt@ietf.org Cc: Colin Perkins Subject: RE: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications Date: Tue, 27 Jan 2004 11:23:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Magnus and Collin, thank you for this initiative. We also had some internal dicussions about the AMR RTP payload format, = RFC 3267, with that respect. Is there any intention to remmedy this, e.g. by updating the RFC or = writing an additional one? Best regards, Thomas ---------------------------------- Dr. Thomas Belling Siemens AG =20 Sankt-Martin-Str. 76=20 D-81541 M=FCnchen Germany ICM N PG SP ST N1 MCH M 34 307 Tel +49 89 636 75207 Fax +49 89 636 75577 Mobile +49 172 2974678 Email Thomas.Belling@siemens.com -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of = Magnus Westerlund Sent: Monday, January 26, 2004 2:54 PM To: avt@ietf.org Cc: Colin Perkins Subject: [AVT] The need for Offer/Answer sections in RTP payload format = specifications Hi AVT members, We AVT chairs would like to make all writers of RTP payload format = aware of one thing. There exist a need for most RTP payload formats to have a section discussing the usage of the MIME parameters in regards to the SDP Offer and Answer model defined in RFC 3264. This concerns all RTP payload formats that use parameters to configure either the payload format itself or the transported codec. The reason for these is to achieve the best possible interoperability. And the interoperability is affected in several ways through the use of MIME defined parameters. - Configuration of RTP payload formats and codecs: If one end-point A offers functionality set SA and end-point B offers another = functionality set SB. Then it is possible that SA has no common subset with SB, thus preventing interoperability. - Understanding when offered set SA and supported set SB contains possibilities for sub-setting. Certain offered sets can be subsetted = and still useful. A MIME specification should be explicit about if parameters can be downgraded or not. For example, an video profile = level specification can be downgraded to a lower level in the response and still achieve interoperability. However an AMR payload format configuration parameter like "octet-align" is binary, i.e. requiring = one to support this configuration. - Possibility to make recommendations on how to form offers that maximizes interoperability. However this is application dependent and should normally be kept in an more open terms. However for example for the AMR payload format can be configured into several usages. For some applications it does make sense to offer multiple payload types where the payload format is configured in different way. For example a streaming server can offer both a octet-aligned only PT and one with interleaving if they would use offer answer. Thus we request that authors write an "Offer-Answer model = consideration" in their SDP usage section. This should cover the following: - How configurations effect the interoperability. - What parameters that are possible to subset and which are not. - Recommendations on how to achieve good interoperability. Comments on this are solicited. Best Regards Magnus & Colin --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 06:01:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29322 for ; Tue, 27 Jan 2004 06:01:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQxv-00028d-3G for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 06:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RB17Kw008218 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 06:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQxp-00027p-J6; Tue, 27 Jan 2004 06:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlQxR-00025G-N3 for avt@optimus.ietf.org; Tue, 27 Jan 2004 06:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29278 for ; Tue, 27 Jan 2004 06:00:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlQxO-0007Qc-00 for avt@ietf.org; Tue, 27 Jan 2004 06:00:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlQwP-0007MZ-00 for avt@ietf.org; Tue, 27 Jan 2004 05:59:34 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AlQvR-0007I1-00 for avt@ietf.org; Tue, 27 Jan 2004 05:58:33 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0RAwYAh014586; Tue, 27 Jan 2004 11:58:34 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DYMNWGAR; Tue, 27 Jan 2004 11:58:32 +0100 Message-ID: <401643F4.2040307@ericsson.com> Date: Tue, 27 Jan 2004 11:56:52 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Belling Thomas CC: avt@ietf.org Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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, Belling Thomas wrote: >Dear Magnus and Collin, > >thank you for this initiative. >We also had some internal dicussions about the AMR RTP payload format, >RFC 3267, with that respect. >Is there any intention to remmedy this, e.g. by updating the RFC or >writing an additional one? > >Best regards, Thomas > > > We authors are planning on updating RFC 3267 to go draft standard, then we can address this.. We will also fix some small issues with the text, however the current errata for RFC 3267 is very short. I have written an initial proposal for this text which I include below, however please remember that it is a first version. Comments are welcome. Cheers Magnus ---------- Text Proposal for new chapter 8.3 ------------- 8.3. Mapping MIME Parameters into SDP The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows: - The MIME type ("audio") goes in SDP "m=" as the media name. - The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed is specified in Section 4.1 in [24]. - The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively. - Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon separated list of parameter=value pairs. 8.3.1 Offer-Answer Model Considerations To achieve good interoperability with the AMR or the AMR-WB RTP payload in an Offer-Answer usage in SDP the following considerations should be made: - Each combination of the RTP payload configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. Due to the application dependent nature of any configuration and they being optionally to implement, care must be taken. When creating an offer in an application desiring to use the more advance features (crc, robust-sorting, interleaving, or more than one channel), the offerer is RECOMMENDED to also offer an payload type containing only the octet-align configuration with a single channel. If multiple configurations are of interest to the application they may all be offered, however care should be taken to not offer too many payload types. - The parameters "mode-set", "mode-change-period", and "mode-change-neighbor" SHOULD only be used when really needed due to gateway scenarios, however their nature are such that they must either be supported or no interoperability exist. - The parameters "maxptime" and "ptime" should in most cases not effect the interoperability, however the setting of the parameters can effect the performance of the application. 8.3.2 Examples Some example SDP session descriptions utilizing AMR and AMR-WB encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows it should be ignored. Example of usage of AMR in a possible GSM gateway scenario: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \ mode-change-neighbor=1 a=maxptime:20 Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98): m=audio 49120 RTP/AVP 99 98 a=rtpmap:99 AMR-WB/16000 a=fmtp:99 octet-align=1; crc=1 a=rtpmap:98 AMR-WB/16000 a=fmtp:98 octet-align=1 Example of usage of AMR-WB in a possible streaming scenario (two channel stereo): m=audio 49120 RTP/AVP 99 100 a=rtpmap:99 AMR-WB/16000/2 a=fmtp:99 interleaving=30 a=maxptime:100 Note that the payload format (encoding) names 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. -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 06:16:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29860 for ; Tue, 27 Jan 2004 06:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRCO-0003FM-Kr for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 06:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RBG4An012471 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 06:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRCL-0003EC-CW; Tue, 27 Jan 2004 06:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRC0-0003DH-08 for avt@optimus.ietf.org; Tue, 27 Jan 2004 06:15:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29822 for ; Tue, 27 Jan 2004 06:15:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlRBw-0000X8-00 for avt@ietf.org; Tue, 27 Jan 2004 06:15:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlRAx-0000TH-00 for avt@ietf.org; Tue, 27 Jan 2004 06:14:36 -0500 Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx with esmtp (Exim 4.12) id 1AlRA2-0000Np-00 for avt@ietf.org; Tue, 27 Jan 2004 06:13:38 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0HS50072HB4G08@dns1.cselt.it> for avt@ietf.org; Tue, 27 Jan 2004 12:12:16 +0100 (MET) Received: from iowa2k01a.cselt.it ([163.162.242.201]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Jan 2004 12:13:41 +0100 Received: from EXC2K05A.cselt.it ([163.162.36.101]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Tue, 27 Jan 2004 12:13:40 +0100 Date: Tue, 27 Jan 2004 12:13:08 +0100 From: Franceschini Guido Subject: AMR PT (was RE: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications) To: Magnus Westerlund Cc: avt@ietf.org Message-id: <3737D9839ED3D3408C73611BDA907A043522CF@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications Thread-Index: AcPkxPJ2V4FJjm6rQwis4iwaAozlJAAAEwDg content-class: urn:content-classes:message X-OriginalArrivalTime: 27 Jan 2004 11:13:40.0906 (UTC) FILETIME=[9E6C48A0:01C3E4C6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, since I have just read that you are considering to update RFC3267, here = is another possible issue. I am recently tracking an interoperability problem with my = implementation of RFC3267, which uses the Dynamic PT. The problem is that the other equipment uses the static PT=3D3, assigned = to GSM according to RFC3551. I have only found this statement on PT in RFC3267 : "The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically." Therefore my question is: shall we use the static PT=3D3 or the dynamic = PT ? Thanks in advance Guido Franceschini TILAB - Multimedia Division Via G.Reiss Romoli 274 I-10148 Torino, Italy tel + 39 011 228 6137 fax + 39 011 228 6299 -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus Westerlund Sent: Tuesday, January 27, 2004 11:57 AM To: Belling Thomas Cc: avt@ietf.org Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications Hi Thomas, Belling Thomas wrote: >Dear Magnus and Collin, > >thank you for this initiative. >We also had some internal dicussions about the AMR RTP payload format, >RFC 3267, with that respect. >Is there any intention to remmedy this, e.g. by updating the RFC or >writing an additional one? > >Best regards, Thomas > > =20 > We authors are planning on updating RFC 3267 to go draft standard, then=20 we can address this.. We will also fix some small issues with the text,=20 however the current errata for RFC 3267 is very short. I have written an initial proposal for this text which I include below,=20 however please remember that it is a first version. Comments are = welcome. Cheers Magnus ---------- Text Proposal for new chapter 8.3 ------------- 8.3. Mapping MIME Parameters into SDP The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows: - The MIME type ("audio") goes in SDP "m=3D" as the media name. - The MIME subtype (payload format name) goes in SDP "a=3Drtpmap" as the encoding name. The RTP clock rate in "a=3Drtpmap" MUST = be 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed is specified in Section 4.1 in [24]. - The parameters "ptime" and "maxptime" go in the SDP "a=3Dptime" and "a=3Dmaxptime" attributes, respectively. - Any remaining parameters go in the SDP "a=3Dfmtp" attribute by copying them directly from the MIME media type string as a semicolon separated list of parameter=3Dvalue pairs. 8.3.1 Offer-Answer Model Considerations To achieve good interoperability with the AMR or the AMR-WB RTP payload in an Offer-Answer usage in SDP the following considerations should be = made: - Each combination of the RTP payload configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. Due to the application dependent nature of any configuration and they being optionally to implement, care must be taken. When creating an offer in an application desiring to use the more advance features (crc, robust-sorting, interleaving, or more than one channel), the offerer is RECOMMENDED to also offer an payload type containing only the octet-align configuration with a single channel. If multiple configurations are of interest to the application they may all be offered, however care should be taken to not offer too many payload = types. - The parameters "mode-set", "mode-change-period", and "mode-change-neighbor" SHOULD only be used when really needed due to gateway scenarios, however their nature are such that they must either be supported or no interoperability exist. - The parameters "maxptime" and "ptime" should in most cases not effect the interoperability, however the setting of the parameters can effect the performance of the application. 8.3.2 Examples Some example SDP session descriptions utilizing AMR and AMR-WB encodings follow. In these examples, long a=3Dfmtp lines are folded = to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows it should be ignored. Example of usage of AMR in a possible GSM gateway scenario: m=3Daudio 49120 RTP/AVP 97 a=3Drtpmap:97 AMR/8000/1 a=3Dfmtp:97 mode-set=3D0,2,5,7; mode-change-period=3D2; \ mode-change-neighbor=3D1 a=3Dmaxptime:20 Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98): m=3Daudio 49120 RTP/AVP 99 98 a=3Drtpmap:99 AMR-WB/16000 a=3Dfmtp:99 octet-align=3D1; crc=3D1 a=3Drtpmap:98 AMR-WB/16000 a=3Dfmtp:98 octet-align=3D1 Example of usage of AMR-WB in a possible streaming scenario (two channel stereo): m=3Daudio 49120 RTP/AVP 99 100 a=3Drtpmap:99 AMR-WB/16000/2 a=3Dfmtp:99 interleaving=3D30 a=3Dmaxptime:100 Note that the payload format (encoding) names 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=3Dfmtp attribute. --=20 Magnus Westerlund=20 Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 06:26:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00133 for ; Tue, 27 Jan 2004 06:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRM7-0003xl-9H for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 06:26:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RBQ7C1015211 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 06:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRM3-0003vJ-Fk; Tue, 27 Jan 2004 06:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlRLj-0003sB-MR for avt@optimus.ietf.org; Tue, 27 Jan 2004 06:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00126 for ; Tue, 27 Jan 2004 06:25:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlRLf-00014N-00 for avt@ietf.org; Tue, 27 Jan 2004 06:25:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlRKm-00012G-00 for avt@ietf.org; Tue, 27 Jan 2004 06:24:45 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AlRKb-0000za-00 for avt@ietf.org; Tue, 27 Jan 2004 06:24:33 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0RBORY20953 for ; Tue, 27 Jan 2004 13:24:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 27 Jan 2004 13:24:25 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 27 Jan 2004 13:24:24 +0200 Received: from agni.research.nokia.com (hed040-220.research.nokia.com [172.21.40.220]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id NAA28726; Tue, 27 Jan 2004 13:24:33 +0200 (EET) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i0RBONKe032146; Tue, 27 Jan 2004 13:24:23 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i0RBOMw7032144; Tue, 27 Jan 2004 13:24:22 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Franceschini Guido Cc: Magnus Westerlund , avt@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3737D9839ED3D3408C73611BDA907A043522CF@EXC2K05A.cselt.it> (Franceschini Guido's message of "Tue, 27 Jan 2004 12:13:08 +0100") References: <3737D9839ED3D3408C73611BDA907A043522CF@EXC2K05A.cselt.it> Date: Tue, 27 Jan 2004 13:24:22 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 27 Jan 2004 11:24:24.0380 (UTC) FILETIME=[1DF69FC0:01C3E4C8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] Re: AMR PT Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Franceschini Guido writes: >The problem is that the other equipment uses the static PT=3, >assigned to GSM according to RFC3551. That is GSM-FR codec, completely different beast. >Therefore my question is: shall we use the static PT=3 or the dynamic PT ? Use dynamic PT. --Pekka _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jan 27 14:34:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19366 for ; Tue, 27 Jan 2004 14:34:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYyM-00060n-Vw for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 14:34:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RJY6LK023103 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 14:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYyG-0005zW-Iy; Tue, 27 Jan 2004 14:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYxN-0005y1-El for avt@optimus.ietf.org; Tue, 27 Jan 2004 14:33:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19292 for ; Tue, 27 Jan 2004 14:32:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYxA-0001D3-00 for avt@ietf.org; Tue, 27 Jan 2004 14:32:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYtu-00011u-00 for avt@ietf.org; Tue, 27 Jan 2004 14:29:31 -0500 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1AlYs8-0000sL-00 for avt@ietf.org; Tue, 27 Jan 2004 14:27:40 -0500 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0RJREEO017032 for ; Tue, 27 Jan 2004 11:27:14 -0800 (PST) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0RJRAkP027075 for ; Tue, 27 Jan 2004 11:27:10 -0800 (PST) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HS5Y1700.PT9 for ; Tue, 27 Jan 2004 11:27:07 -0800 Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: avt@ietf.org From: "John Lazzaro" Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload format specifications Date: Tue, 27 Jan 2004 11:27:06 -0800 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 > Magnus Westerlund writes: > > Thus we request that authors write an "Offer-Answer model > consideration" > in their SDP usage section. This should cover the following: > > - How configurations effect the interoperability. > - What parameters that are possible to subset and which are not. > - Recommendations on how to achieve good interoperability. In regards to RTP MIDI, I think it may be better for the readers of the "candidate Last Call" document to judge if the SDP sections as written (pages 20-24, and pages 68-103) handle Offer/Answer OK, and if the best solution is a new separate Offer/Answer section or a rewrite of the existing structure to discuss Offer/Answer in more depth. This way, I can handle those criticisms along with all of the other Last Call feedback at one time, in the hopes of reducing the total number of rewrite cycles before "candidate Last Call" becomes "Last Call". The alternative (going off and doing -02.txt versions to become the new "candidate Last Call", with a separate Offer/Answer section) probably knocks a month off the schedule. Not good ... My own intuition is that the RTP MIDI document is OK as it stands in regard to interop -- the world of RTP MIDI applications is big, and interoperability is going to require a framework document for each class of applications, written by application experts. The purpose of the SDP section in the payload document is to define a common set of SDP tools that these frameworks can subset. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 04:18:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21939 for ; Wed, 28 Jan 2004 04:18:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Allpu-0005IB-3g for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 04:18:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S9IEHJ020342 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 04:18:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Allph-0005Gv-KV; Wed, 28 Jan 2004 04:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Allp4-0005Fu-QG for avt@optimus.ietf.org; Wed, 28 Jan 2004 04:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21911 for ; Wed, 28 Jan 2004 04:17:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Allp2-0003zM-00 for avt@ietf.org; Wed, 28 Jan 2004 04:17:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Allo8-0003vn-00 for avt@ietf.org; Wed, 28 Jan 2004 04:16:25 -0500 Received: from ms-smtp-02-lbl.southeast.rr.com ([24.25.9.101] helo=ms-smtp-02-eri0.southeast.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1Allnm-0003sO-00 for avt@ietf.org; Wed, 28 Jan 2004 04:16:02 -0500 Received: from paris.packetizer.org (rrcs-midsouth-24-199-215-15.biz.rr.com [24.199.215.15]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i0S9Fxhl018215; Wed, 28 Jan 2004 04:15:59 -0500 (EST) Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id i0S9FvaS018782; Wed, 28 Jan 2004 04:15:59 -0500 Message-ID: <002101c3e57f$11904260$e1cd6a9c@cisco.com> From: "Paul E. Jones" To: "Magnus Westerlund" Cc: References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> <400FBDAA.1050208@ericsson.com> <4014DABD.3030105@ericsson.com> <00a001c3e40e$7c61b8c0$e1cd6a9c@cisco.com> <40162693.4040805@ericsson.com> Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt Date: Wed, 28 Jan 2004 04:13:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Magnus, > >>"pt: a comma-separated ordered list enumerating the primary, > >secondary, > >>etc., encoding's RTP payload types in accordance with RFC 2198. > >Because > >>comma is ..." > >> > >> > > > >There was a desire early on not to explicitly tie the MIME registration > >to > >RFC 2198. Certainly, it is the main driver for producing the document, > >but > >it was viewed as not the only potential user of this registration. > >Thus, do > >we really want this text or just leave it as it is in the current draft? > > > > > > No, It must be tied to RFC 2198. In my recollection the opinion > expressed was to not tie it to RFC 2793. I think we should go with the > new text, because I find the old text confusing as it does not inform > explicitly that about the semantics of the parameter. Sorry... I had the RFC numbers mixed up when I was responding. Yes, you're correct-- it was RFC 2793 that was the concern... no problem with your proposed text. I'll make those changes. > >>Then only the last issue below, remains to be resolved as I see it. > >And, how can we close on that issue below? > > I don't know really, it seems that we should be compatible with what is > used for audio/RED. However what is really used here is not totally > clear. Based on the examples in RFC 2198 one does rely on having dynamic > PTs to be declared through "a=rtpmap". > > What is you others opinion about this? Perhaps pointing out a concrete problem that might result in SDP might help lead to text that resolves the concerns. Paul > Cheers > > Magnus > > > > > > >>Cheers > >> > >>Magnus > >> > >>Magnus Westerlund wrote: > >> > >> > >> > >>>>>When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the > >>>>>pt=content-type structure at all. As the information is available > >>>>> > >>>>> > >in > > > > > >>>>the > >>>> > >>>> > >>>> > >>>> > >>>>>SDP as defined PT. Therefore you only need to reference these PTs. > >>>>> > >>>>> > >So > > > > > >>>>>when having SDP should you in fact remove all of these > >>>>> > >>>>> > >pt=content-type > > > > > >>>>>declarations and only use PTs in the list? > >>>>> > >>>>>I would also like to point out that the this declaration of > >>>>>"dynamic-payload-type "=" content-type" is not sufficiently clear. > >>>>> > >>>>> > >For > > > > > >>>>>RTP payload formats using parameters to configure this, this > >>>>> > >>>>> > >string is > > > > > >>>>>insufficient unless the parameter list can be included in the > >>>>>content-type part. > >>>>> > >>>>> > >>>>> > >>>>Ah, I understand. As I mentioned above, this follows the example > >>>> > >>>> > >in > >RFC > > > > > >>>>3555, which also does not go into discussion on this (as far as I > >>>> > >>>> > >know). > > > > > >>>>I > >>>>assume the reason for that was simply that the entire focus was on > >>>> > >>>> > >SDP, > > > > > >>>>anyway, with little focus on MIME, really. > >>>> > >>>>In any case, I can add text in this regard, but I need some > >>>> > >>>> > >guidance as > > > > > >>>>to > >>>>what we should have inserted to make this clearer. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>I would definitely like to have some more input from Colin and > >>> > >>> > >others > > > > > >>>about how this problem should be resolved. > >>> > >>> > >>> > >>-- > >> > >>Magnus Westerlund > >> > >>Multimedia Technologies, Ericsson Research EAB/TVA/A > >>---------------------------------------------------------------------- > >>Ericsson AB | Phone +46 8 4048287 > >>Torshamsgatan 23 | Fax +46 8 7575550 > >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> > >> > >> > >> > > > > > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 04:57:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23010 for ; Wed, 28 Jan 2004 04:57:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmRf-0007gq-BV for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 04:57:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S9vFeI029510 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 04:57:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmRY-0007fG-03; Wed, 28 Jan 2004 04:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlmQu-0007eG-RX for avt@optimus.ietf.org; Wed, 28 Jan 2004 04:56:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22957 for ; Wed, 28 Jan 2004 04:56:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlmQr-0006z8-00 for avt@ietf.org; Wed, 28 Jan 2004 04:56:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlmQ5-0006uS-00 for avt@ietf.org; Wed, 28 Jan 2004 04:55:37 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AlmPC-0006of-00 for avt@ietf.org; Wed, 28 Jan 2004 04:54:42 -0500 Received: from MCOMREYJ ([10.10.100.173]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 10:54:05 +0100 From: "Jose Rey" To: Date: Wed, 28 Jan 2004 10:54:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-OriginalArrivalTime: 28 Jan 2004 09:54:05.0647 (UTC) FILETIME=[AA8F55F0:01C3E584] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA22958 Subject: [AVT] FW: draft-burmeister-avt-rtcp-feedback-sim-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, FYI: the feedback sims draft -04 (with corrected email addresses) has bee= n submitted the ID manager, except for that it is the same exact document as -03. http://www.pel.panasonic.de/ietf/docs/draft-burmeister-avt-rtcp-feedback-= sim -04.txt cheers, Jos=E9 > -----Original Message----- > From: Jose Rey [mailto:rey@panasonic.de] > Sent: Wednesday, January 28, 2004 10:46 AM > To: internet-drafts@ietf.org > Cc: magnus.westerlund@era.ericsson.se; Colin Perkins > Subject: draft-burmeister-avt-rtcp-feedback-sim-04.txt > > > > Dear I-D editors, > > this is to submit the following Internet Draft for continued > discussion in the AVT Working Group: > > Title: Extended RTP Profile for RTCP-based Feedback > - Results of the Timing Rule Simulations - > Authors: Burmeister, et al. > Date: January, 28th 2004 > File name: draft-burmeister-avt-rtcp-feedback-sim-04.txt > > > > cheers, > Jos=E9 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 06:40:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26576 for ; Wed, 28 Jan 2004 06:40:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alo3G-0006yg-6s for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 06:40:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SBeAIu026813 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 06:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alo3A-0006xe-Jp; Wed, 28 Jan 2004 06:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alo2g-0006v6-J7 for avt@optimus.ietf.org; Wed, 28 Jan 2004 06:39:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26515 for ; Wed, 28 Jan 2004 06:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alo2c-0007OJ-00 for avt@ietf.org; Wed, 28 Jan 2004 06:39:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alo1g-0007K2-00 for avt@ietf.org; Wed, 28 Jan 2004 06:38:32 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Alo0t-0007Fh-00 for avt@ietf.org; Wed, 28 Jan 2004 06:37:43 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0SBbgYG005959; Wed, 28 Jan 2004 12:37:42 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DZZ5S1VG; Wed, 28 Jan 2004 12:37:41 +0100 Message-ID: <40179E9F.3000909@ericsson.com> Date: Wed, 28 Jan 2004 12:35:59 +0100 X-Sybari-Trust: 78237477 6b512624 d75201eb 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: avt@ietf.org Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> <400FBDAA.1050208@ericsson.com> <4014DABD.3030105@ericsson.com> <00a001c3e40e$7c61b8c0$e1cd6a9c@cisco.com> <40162693.4040805@ericsson.com> <002101c3e57f$11904260$e1cd6a9c@cisco.com> In-Reply-To: <002101c3e57f$11904260$e1cd6a9c@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Paul, Good, that resolves all but the last issue. Which I will try to recapitulate here: The MIME type parameter declaration declares that any dynamic payload type is to be expressed in the form "PT=content-type". However when mapping this into a SDP it seems strange to use this form, as any dynamic PT is already declared in the SDP using "a=rtpmap". So I think the mapping to SDP text should explain how this should be done in the best way. My proposal would be to add something like the following into the bullet about how to handle the "pt" parameter in section 4. "Any dynamic payload type in the list, SHALL NOT include its content-type, only the payload type number. The mapping of payload types to the content-type is done using the normal SDP procedures with "a=rtpmap". " Would this be satisfactory? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 07:41:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28372 for ; Wed, 28 Jan 2004 07:41:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alp0G-0002iY-2E for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 07:41:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SCf8RK010440 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 07:41:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alp08-0002ha-TB; Wed, 28 Jan 2004 07:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alozb-0002hD-FV for avt@optimus.ietf.org; Wed, 28 Jan 2004 07:40:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28357 for ; Wed, 28 Jan 2004 07:40:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aloza-0004b5-00 for avt@ietf.org; Wed, 28 Jan 2004 07:40:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aloyd-0004XV-00 for avt@ietf.org; Wed, 28 Jan 2004 07:39:28 -0500 Received: from ms-smtp-02-lbl.southeast.rr.com ([24.25.9.101] helo=ms-smtp-02-eri0.southeast.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1Aloy6-0004Tz-00 for avt@ietf.org; Wed, 28 Jan 2004 07:38:54 -0500 Received: from paris.packetizer.org (rrcs-midsouth-24-199-215-15.biz.rr.com [24.199.215.15]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i0SCcjhl011623; Wed, 28 Jan 2004 07:38:46 -0500 (EST) Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id i0SCciaS019603; Wed, 28 Jan 2004 07:38:44 -0500 Message-ID: <051901c3e59b$6535c4a0$e1cd6a9c@cisco.com> From: "Paul E. Jones" To: "Magnus Westerlund" Cc: References: <400E9B40.3080206@ericsson.com> <00d901c3e042$cc6a7ca0$e1cd6a9c@cisco.com> <400F914E.9090006@ericsson.com> <00af01c3e0d5$bb3e6430$34cc6a9c@cisco.com> <400FBDAA.1050208@ericsson.com> <4014DABD.3030105@ericsson.com> <00a001c3e40e$7c61b8c0$e1cd6a9c@cisco.com> <40162693.4040805@ericsson.com> <002101c3e57f$11904260$e1cd6a9c@cisco.com> <40179E9F.3000909@ericsson.com> Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt Date: Wed, 28 Jan 2004 07:36:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Magnus, That sounds fine to me. I'll insert that and make the complete text available again as a TD within a week or so. Of course, further input is certainly welcome. Paul ----- Original Message ----- From: "Magnus Westerlund" To: "Paul E. Jones" Cc: Sent: Wednesday, January 28, 2004 6:35 AM Subject: Re: [AVT] Comments on draft-ietf-text-red-00.txt > Hi Paul, > > Good, that resolves all but the last issue. Which I will try to > recapitulate here: > > The MIME type parameter declaration declares that any dynamic payload > type is to be expressed in the form "PT=content-type". However when > mapping this into a SDP it seems strange to use this form, as any > dynamic PT is already declared in the SDP using "a=rtpmap". So I think > the mapping to SDP text should explain how this should be done in the > best way. > > My proposal would be to add something like the following into the bullet > about how to handle the "pt" parameter in section 4. > > "Any dynamic payload type in the list, SHALL NOT include its > content-type, only the payload type number. The mapping of payload types > to the content-type is done using the normal SDP procedures with > "a=rtpmap". " > > Would this be satisfactory? > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 11:06:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06316 for ; Wed, 28 Jan 2004 11:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsCh-0006SR-IQ for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 11:06:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SG6Bge024807 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 11:06:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsCY-0006Op-2b; Wed, 28 Jan 2004 11:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsBl-0006Do-Ly for avt@optimus.ietf.org; Wed, 28 Jan 2004 11:05: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 LAA06126; Wed, 28 Jan 2004 11:05:08 -0500 (EST) Message-Id: <200401281605.LAA06126@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, 28 Jan 2004 11:05:07 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-guidelines-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 : An Implementation Guide for RTP MIDI Author(s) : J. Lazzaro Filename : draft-ietf-avt-rtp-midi-guidelines-01.txt Pages : 35 Date : 2004-1-27 This memo offers non-normative implementation guidance for the RTP MIDI payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-guidelines-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-midi-guidelines-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-midi-guidelines-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-midi-guidelines-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-midi-guidelines-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112517.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 11:06:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06317 for ; Wed, 28 Jan 2004 11:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsCh-0006Tq-NV for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 11:06:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SG6BcW024808 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 11:06:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsCZ-0006P9-4P; Wed, 28 Jan 2004 11:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlsBs-0006GT-3B for avt@optimus.ietf.org; Wed, 28 Jan 2004 11:05: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 LAA06142; Wed, 28 Jan 2004 11:05:14 -0500 (EST) Message-Id: <200401281605.LAA06142@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, 28 Jan 2004 11:05:13 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-format-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 MIDI Author(s) : J. Lazzaro Filename : draft-ietf-avt-rtp-midi-format-01.txt Pages : 119 Date : 2004-1-27 This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-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-midi-format-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-midi-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-midi-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-midi-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112530.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 13:13:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17967 for ; Wed, 28 Jan 2004 13:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluBW-0004Nt-UY for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 13:13:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SID6B4016849 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 13:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluBS-0004N6-4g; Wed, 28 Jan 2004 13:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluBM-0004Jz-6M for avt@optimus.ietf.org; Wed, 28 Jan 2004 13:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17955 for ; Wed, 28 Jan 2004 13:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluBK-0000ED-00 for avt@ietf.org; Wed, 28 Jan 2004 13:12:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AluAL-00007d-00 for avt@ietf.org; Wed, 28 Jan 2004 13:11:54 -0500 Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Alu9M-0007it-00 for avt@ietf.org; Wed, 28 Jan 2004 13:10:52 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i0SHZTp8032392 for ; Wed, 28 Jan 2004 13:10:22 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 40169495000B0C49 for avt@ietf.org; Wed, 28 Jan 2004 13:09:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jan 2004 12:10:22 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA02BA3881@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Thread-Index: AcPYodDrRUJs23mBSa+NKC8FcnAyPAITEcagAAA2tFABNnFZwA== From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [AVT] I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-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: quoted-printable All, Please review and comment on the current draft of 'Requirements for = ECRTP over MPLS' = http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-01= .txt. The draft has been updated according to the comments received (see = attached email). Let's keep the discussion going on the list so that we = can converge on this draft prior to IETF-59 (week of March 1), and meet = the AVT charter item milestone: Mar 2004 Finish requirements for ECRTP over MPLS; re-charter for = subsequent work Thanks, Jerry -----Original Message----- From: Ash, Gerald R (Jerry), ALABS=20 Sent: Thursday, January 22, 2004 9:24 AM To: Lars-Erik Jonsson (LU/EAB); Colin Perkins; avt@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt Colin & Lars-Erik, Thanks very much for your comments and suggestions. In addition to all = of your editorial suggestions, the changes to the updated draft will = include: > In a number of places, the draft describes "using MPLS to route ECRTP > compressed packets over multiple router hops". Does this mean routing > compressed packets over an MPLS LSP? If so, I recommend clarifying the > draft to prevent confusion with multiple IP hops. Changed the language as suggested. =20 > I'm not sure discussion of access links is appropriate, since MPLS is > unlikely to be used in this scenario. We now refer to 'low-speed' links rather than 'access links'. It's = debatable how far MPLS will extend. =20 > In section 3, the requirements list ECRTP without discussion.=20 > I think ECRTP is an appropriate solution, but it would be useful to=20 > motivate the choice by discussing the requirements for the=20 > compression. This is particularly important, since there are=20 > alternative algorithms (e.g. ROHC) that may be considered. We've added discussion as suggested. ECRTP should be used to make ECRTP = over MPLS more tolerant of packet loss, to guard against frequent = resynchronizations, and to minimize the need for error recovery. ROHC = can also be considered, however ROHC does not accommodate packet = reordering to protect against out-of-sequence packets, which can occur = on MPLS LSPs. We didn't change the title of the document, as suggested = by L-E, since Colin specifically suggested the current title, and that = also corresponds to the AVT milestone. =20 > In section 3, the draft notes that protocol extensions may be=20 > required for ECRTP. Are these changes to ECRTP or a mapping of > ECRTP onto a new "link" layer? If the latter, the draft could > do with clarification. The draft should discuss the type of > extension needed for RSVP-TE and LDP, since this will feed=20 > into any new work plan. We've added text on protocol extensions required for ECRTP, RSVP-TE, and = LDP > Security considerations: Are there no issues with DoS attacks on MPLS > routers, due to the increased number of flows? We've added text to discuss DoS attacks in the security section. > Before publication, the draft will need an IANA Considerations section > (even if it just says "No IANA actions are required") and the=20 > IPR boiler-plate. We've added an IANA Considerations Section and Intellectual Property = Statement Section. Thanks, Jerry _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 17:34:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04241 for ; Wed, 28 Jan 2004 17:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyG4-0008B6-IQ for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 17:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SMY45j031435 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 17:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyG0-00086i-W8; Wed, 28 Jan 2004 17:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlyFI-0007qP-20 for avt@optimus.ietf.org; Wed, 28 Jan 2004 17:33:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04057 for ; Wed, 28 Jan 2004 17:33:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlyFF-0005wF-00 for avt@ietf.org; Wed, 28 Jan 2004 17:33:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlyEB-0005jA-00 for avt@ietf.org; Wed, 28 Jan 2004 17:32:08 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AlyD2-0005LB-00 for avt@ietf.org; Wed, 28 Jan 2004 17:30:56 -0500 Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0SMUP9W011345; Wed, 28 Jan 2004 17:30:27 -0500 (EST) Message-ID: <401837F6.2090407@dynamicsoft.com> Date: Wed, 28 Jan 2004 17:30:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: avt@ietf.org, Colin Perkins Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload format specifications References: <40151BE4.1010503@ericsson.com> In-Reply-To: <40151BE4.1010503@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Magnus, This is a good thing. One point I would add to it is this. The offer/answer model has two ways you can interpret parameters that occur in SDP. Either they are *negotiated*, such that the aim of offer/answer is to achieve a common value(s) for the parameters that are shared between both sides, and the other is simply a statement of "this is what I am going to use", and both sides can have totally different values. This is called "declarative". It is important that the SDP usage section be very clear on what the intended semantic is. As examples, the set of codecs is negotiated, but the packetization intervals (ptime) are declarative. -Jonathan R. Magnus Westerlund wrote: > Hi AVT members, > > We AVT chairs would like to make all writers of RTP payload format aware > of one thing. There exist a need for most RTP payload formats to have a > section discussing the usage of the MIME parameters in regards to the > SDP Offer and Answer model defined in RFC 3264. This concerns all RTP > payload formats that use parameters to configure either the payload > format itself or the transported codec. > > The reason for these is to achieve the best possible interoperability. > And the interoperability is affected in several ways through the use of > MIME defined parameters. > - Configuration of RTP payload formats and codecs: If one end-point A > offers functionality set SA and end-point B offers another functionality > set SB. Then it is possible that SA has no common subset with SB, thus > preventing interoperability. > > - Understanding when offered set SA and supported set SB contains > possibilities for sub-setting. Certain offered sets can be subsetted and > still useful. A MIME specification should be explicit about if > parameters can be downgraded or not. For example, an video profile level > specification can be downgraded to a lower level in the response and > still achieve interoperability. However an AMR payload format > configuration parameter like "octet-align" is binary, i.e. requiring one > to support this configuration. > > - Possibility to make recommendations on how to form offers that > maximizes interoperability. However this is application dependent and > should normally be kept in an more open terms. However for example for > the AMR payload format can be configured into several usages. For some > applications it does make sense to offer multiple payload types where > the payload format is configured in different way. For example a > streaming server can offer both a octet-aligned only PT and one with > interleaving if they would use offer answer. > > Thus we request that authors write an "Offer-Answer model consideration" > in their SDP usage section. This should cover the following: > > - How configurations effect the interoperability. > - What parameters that are possible to subset and which are not. > - Recommendations on how to achieve good interoperability. > > Comments on this are solicited. > > Best Regards > > Magnus & Colin > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 20:26:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10705 for ; Wed, 28 Jan 2004 20:26:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0wc-0001Q5-Q1 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 20:26:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T1QALI005432 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 20:26:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0wV-0001Nn-El; Wed, 28 Jan 2004 20:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0wN-0001N1-Bp for avt@optimus.ietf.org; Wed, 28 Jan 2004 20:25:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10697 for ; Wed, 28 Jan 2004 20:25:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am0wL-0006wg-00 for avt@ietf.org; Wed, 28 Jan 2004 20:25:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am0vT-0006rw-00 for avt@ietf.org; Wed, 28 Jan 2004 20:24:59 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1Am0v3-0006m7-00 for avt@ietf.org; Wed, 28 Jan 2004 20:24:33 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61028 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1Am0uU-0002vb-00 for avt@ietf.org; Thu, 29 Jan 2004 01:23:58 +0000 Date: Thu, 29 Jan 2004 01:24:13 +0000 From: Colin Perkins To: avt@ietf.org Message-Id: <20040129012413.480e897d.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Advancing RTP spec & profile to Full 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: , Content-Transfer-Encoding: 7bit Folks, The RTP specification (RFC 3550) and the RTP Audio/Video Profile (RFC 3551) have remained at the Draft Standard level for more than four months, and past the occurrence of one IETF meeting. This exceeds the requirements of RFC 2026 for advancement to full Internet Standard status. Consequently, with the concurrence of the AVT working group, we would like to send a request to the IESG that these RFCs be advanced unchanged to Full Internet Standard. If you have any comments on this step, either agreement or objections, please reply to the mailing list. Colin, Magnus and Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jan 28 20:51:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11385 for ; Wed, 28 Jan 2004 20:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am1Kj-0003kV-8e for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 20:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T1p5vb014380 for avt-archive@odin.ietf.org; Wed, 28 Jan 2004 20:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am1Kg-0003j1-De; Wed, 28 Jan 2004 20:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am1Jh-0003gu-1U for avt@optimus.ietf.org; Wed, 28 Jan 2004 20:50:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11358 for ; Wed, 28 Jan 2004 20:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am1Je-0001Ih-00 for avt@ietf.org; Wed, 28 Jan 2004 20:49:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am1Il-0001Dm-00 for avt@ietf.org; Wed, 28 Jan 2004 20:49:04 -0500 Received: from [65.205.244.70] (helo=envy.pioneer-pra.com) by ietf-mx with esmtp (Exim 4.12) id 1Am1IS-00017v-00 for avt@ietf.org; Wed, 28 Jan 2004 20:48:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by envy.pioneer-pra.com (Postfix) with ESMTP id 6859D3778C; Wed, 28 Jan 2004 17:48:11 -0800 (PST) Received: from envy.pioneer-pra.com ([127.0.0.1]) by localhost (envy.pioneer-pra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08065-06; Wed, 28 Jan 2004 17:48:10 -0800 (PST) Received: from [10.0.2.120] (host-120.int.pioneer-pra.com [10.0.2.120]) by envy.pioneer-pra.com (Postfix) with ESMTP id 8478A3775A; Wed, 28 Jan 2004 17:48:10 -0800 (PST) In-Reply-To: <20040129012413.480e897d.csp@csperkins.org> References: <20040129012413.480e897d.csp@csperkins.org> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43028BF6-51FD-11D8-81DF-0003934AD338@pioneer-pra.com> Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, John Gildred From: John Gildred Subject: Re: [AVT] Advancing RTP spec & profile to Full Standard Date: Wed, 28 Jan 2004 17:48:40 -0800 To: Colin Perkins X-Mailer: Apple Mail (2.612) X-Virus-Scanned: by amavisd-new at pioneer-pra.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Agreed. On Jan 28, 2004, at 5:24 PM, Colin Perkins wrote: > Folks, > > The RTP specification (RFC 3550) and the RTP Audio/Video Profile (RFC > 3551) > have remained at the Draft Standard level for more than four months, > and > past the occurrence of one IETF meeting. This exceeds the > requirements of > RFC 2026 for advancement to full Internet Standard status. > > Consequently, with the concurrence of the AVT working group, we would > like > to send a request to the IESG that these RFCs be advanced unchanged to > Full > Internet Standard. If you have any comments on this step, either > agreement > or objections, please reply to the mailing list. > > Colin, Magnus and Steve > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > -John Gildred Vice President of Engineering Pioneer Research Center USA, Inc. A Division of Pioneer Electronics 101 Metro Drive, Suite 264 San Jose, California 95110 Office (408) 437-1800 Ext. 105 Mobile (510) 295-7770 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 29 03:15:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07477 for ; Thu, 29 Jan 2004 03:15:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am7KY-0008Mx-OE for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 03:15:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T8FIgm032122 for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 03:15:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am7KI-0008LB-QP; Thu, 29 Jan 2004 03:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am1VD-0004Q7-Q3 for avt@optimus.ietf.org; Wed, 28 Jan 2004 21:01:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11698 for ; Wed, 28 Jan 2004 21:01:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am1VB-0002Ja-00 for avt@ietf.org; Wed, 28 Jan 2004 21:01:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am1UD-0002F6-00 for avt@ietf.org; Wed, 28 Jan 2004 21:00:53 -0500 Received: from dhost001-17.intermedia.net ([64.78.61.64] helo=DHOST001-17.DEX001.intermedia.net) by ietf-mx with esmtp (Exim 4.12) id 1Am1TT-0002As-00 for avt@ietf.org; Wed, 28 Jan 2004 21:00:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Advancing RTP spec & profile to Full Standard Date: Wed, 28 Jan 2004 17:59:46 -0800 Message-ID: Thread-Topic: [AVT] Advancing RTP spec & profile to Full Standard Thread-Index: AcPmBuIqu+FQdCtlQNmDtd2lt8ZjCwABK9+A From: "Marwan Jabri" To: "Colin Perkins" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Agreed.=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: Wednesday, January 28, 2004 5:24 PM > To: avt@ietf.org > Subject: [AVT] Advancing RTP spec & profile to Full Standard >=20 > Folks, >=20 > The RTP specification (RFC 3550) and the RTP Audio/Video=20 > Profile (RFC 3551) have remained at the Draft Standard level=20 > for more than four months, and past the occurrence of one=20 > IETF meeting. This exceeds the requirements of RFC 2026 for=20 > advancement to full Internet Standard status. >=20 > Consequently, with the concurrence of the AVT working group,=20 > we would like to send a request to the IESG that these RFCs=20 > be advanced unchanged to Full Internet Standard. If you have=20 > any comments on this step, either agreement or objections,=20 > please reply to the mailing list. >=20 > Colin, Magnus and Steve >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 29 10:21:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23649 for ; Thu, 29 Jan 2004 10:21:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDyc-0005h6-Og for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 10:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TFL6pC021884 for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 10:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDyW-0005d7-UV; Thu, 29 Jan 2004 10:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDxb-0005V4-24 for avt@optimus.ietf.org; Thu, 29 Jan 2004 10:20:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23374; Thu, 29 Jan 2004 10:19:59 -0500 (EST) Message-Id: <200401291519.KAA23374@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, 29 Jan 2004 10:19:58 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-retransmission-10.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 Filename : draft-ietf-avt-rtp-retransmission-10.txt Pages : 27 Date : 2004-1-28 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 (denoted RTP/AVPF), is available in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-10.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-10.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-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-29104141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-retransmission-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-29104141.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 29 12:24:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02594 for ; Thu, 29 Jan 2004 12:24:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFts-0005YK-AC for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 12:24:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THOKD0021292 for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 12:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFtk-0005RU-Ca; Thu, 29 Jan 2004 12:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmF1l-0002iO-DI for avt@optimus.ietf.org; Thu, 29 Jan 2004 11:28:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29811 for ; Thu, 29 Jan 2004 11:28:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmF1k-0004qd-00 for avt@ietf.org; Thu, 29 Jan 2004 11:28:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmF0v-0004iq-00 for avt@ietf.org; Thu, 29 Jan 2004 11:27:34 -0500 Received: from [65.205.244.70] (helo=envy.pioneer-pra.com) by ietf-mx with esmtp (Exim 4.12) id 1AmF07-0004SB-00 for avt@ietf.org; Thu, 29 Jan 2004 11:26:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by envy.pioneer-pra.com (Postfix) with ESMTP id EAAFA377C0; Thu, 29 Jan 2004 08:26:12 -0800 (PST) Received: from envy.pioneer-pra.com ([127.0.0.1]) by localhost (envy.pioneer-pra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21864-03; Thu, 29 Jan 2004 08:26:11 -0800 (PST) Received: from [10.0.5.3] (c-67-169-144-239.client.comcast.net [67.169.144.239]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by envy.pioneer-pra.com (Postfix) with ESMTP id BCEC93775A; Thu, 29 Jan 2004 08:26:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: John Gildred From: John Gildred Date: Thu, 29 Jan 2004 08:26:07 -0800 To: avt@ietf.org X-Mailer: Apple Mail (2.609) X-Virus-Scanned: by amavisd-new at pioneer-pra.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Extending Parameters Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have a question regarding RFC 3555 media types. Is it allowed to include non-registered parameters with an existing IETF registered media type? For example: video/mp2t; my-profile=p1 If this is not allowed, how would I best provide this extra format info in the content type without creating a new type? I am not so concerned about SDP description, just the content type definition. -John _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 29 13:55:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07738 for ; Thu, 29 Jan 2004 13:55:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHJl-0004vy-H3 for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 13:55:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TIt9w9018960 for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 13:55:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHJd-0004sP-N5; Thu, 29 Jan 2004 13:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHJD-0004r1-7t for avt@optimus.ietf.org; Thu, 29 Jan 2004 13:54:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07653 for ; Thu, 29 Jan 2004 13:54:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHJA-0007Ur-00 for avt@ietf.org; Thu, 29 Jan 2004 13:54:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHII-0007OR-00 for avt@ietf.org; Thu, 29 Jan 2004 13:53:39 -0500 Received: from mail.vsnl.co.in ([202.54.117.12] helo=HQ-SMTP.vsnl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1AmHHc-0007Dp-00 for avt@ietf.org; Thu, 29 Jan 2004 13:52:56 -0500 Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Fri, 30 Jan 2004 00:28:47 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:18:22 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsC0-0006o1-Fh for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:05:28 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsBp-0006mX-Rg for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:05:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06142; Wed, 28 Jan 2004 11:05:14 -0500 (EST) Message-Id: <200401281605.LAA06142@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, 28 Jan 2004 11:05:13 -0500 Precedence: bulk X-OriginalArrivalTime: 28 Jan 2004 16:48:23.0750 (UTC) FILETIME=[8B24D660:01C3E5BE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-format-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 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 MIDI Author(s) : J. Lazzaro Filename : draft-ietf-avt-rtp-midi-format-01.txt Pages : 119 Date : 2004-1-27 This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-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-midi-format-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-midi-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-midi-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-midi-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112530.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jan 29 13:56:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07775 for ; Thu, 29 Jan 2004 13:56:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHKg-00056u-ES for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 13:56:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TIu6xG019621 for avt-archive@odin.ietf.org; Thu, 29 Jan 2004 13:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHKb-00055O-Lw; Thu, 29 Jan 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmHK5-00051u-1Z for avt@optimus.ietf.org; Thu, 29 Jan 2004 13:55:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07674 for ; Thu, 29 Jan 2004 13:55:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHK2-0007ac-00 for avt@ietf.org; Thu, 29 Jan 2004 13:55:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHJ4-0007Tx-00 for avt@ietf.org; Thu, 29 Jan 2004 13:54:27 -0500 Received: from mail.vsnl.co.in ([202.54.117.12] helo=HQ-SMTP.vsnl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1AmHID-0007Hu-00 for avt@ietf.org; Thu, 29 Jan 2004 13:53:33 -0500 Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Fri, 30 Jan 2004 00:29:25 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:19:47 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsC0-0006nt-Au for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:05:28 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsBj-0006mI-No for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:05:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06126; Wed, 28 Jan 2004 11:05:08 -0500 (EST) Message-Id: <200401281605.LAA06126@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, 28 Jan 2004 11:05:07 -0500 Precedence: bulk X-OriginalArrivalTime: 28 Jan 2004 16:49:49.0171 (UTC) FILETIME=[BE0F0C30:01C3E5BE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-midi-guidelines-01.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 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 Implementation Guide for RTP MIDI Author(s) : J. Lazzaro Filename : draft-ietf-avt-rtp-midi-guidelines-01.txt Pages : 35 Date : 2004-1-27 This memo offers non-normative implementation guidance for the RTP MIDI payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-guidelines-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-midi-guidelines-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-midi-guidelines-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-midi-guidelines-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-midi-guidelines-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112517.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 30 03:23:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01913 for ; Fri, 30 Jan 2004 03:23:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmTvi-0004bF-1w for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 03:23:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U8N9UX017677 for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 03:23:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmTvZ-0004aR-68; Fri, 30 Jan 2004 03:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmAbj-0000Qy-VL for avt@optimus.ietf.org; Thu, 29 Jan 2004 06:45:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13518 for ; Thu, 29 Jan 2004 06:45:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmAbf-0000Y9-00 for avt@ietf.org; Thu, 29 Jan 2004 06:45:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmAal-0000Rr-00 for avt@ietf.org; Thu, 29 Jan 2004 06:44:15 -0500 Received: from orion.lrg.ufsc.br ([150.162.63.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmAZw-0000MD-00; Thu, 29 Jan 2004 06:43:24 -0500 Received: by orion.lrg.ufsc.br (Postfix, from userid 3002) id 33CB2153A3; Thu, 29 Jan 2004 09:44:01 -0400 (WST) Received: from localhost (localhost [127.0.0.1]) by orion.lrg.ufsc.br (Postfix) with ESMTP id B5A031712E; Thu, 29 Jan 2004 09:44:00 -0400 (WST) Date: Thu, 29 Jan 2004 09:44:00 -0400 (WST) From: Carlos Becker Westphall To: neuman@ufc.br Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] ICT2004 - deadline extension Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Taking into account several requests for postponing the submission deadline for ICT2004, the organising committee has decided to extend it to February 14 so that the participation could be as large as possible. So take your time and visit the ICT2004 web site at www.ict2004.com.br. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 30 04:21:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04197 for ; Fri, 30 Jan 2004 04:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmUpn-0008Qe-2Y for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 04:21:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U9L7J7032398 for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 04:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmUpj-0008Oz-Vy; Fri, 30 Jan 2004 04:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmUpf-0008OS-LP for avt@optimus.ietf.org; Fri, 30 Jan 2004 04:20:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04161 for ; Fri, 30 Jan 2004 04:20:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmUpc-0001k7-00 for avt@ietf.org; Fri, 30 Jan 2004 04:20:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmUog-0001d9-00 for avt@ietf.org; Fri, 30 Jan 2004 04:19:59 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AmUno-0001WQ-00 for avt@ietf.org; Fri, 30 Jan 2004 04:19:04 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0U9J3Ah001660; Fri, 30 Jan 2004 10:19:03 +0100 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D77XQS9Q; Fri, 30 Jan 2004 10:19:04 +0100 Message-ID: <401A211D.7020107@ericsson.com> Date: Fri, 30 Jan 2004 10:17:17 +0100 X-Sybari-Trust: 30f74b79 6b512624 8d07a061 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: avt@ietf.org CC: Colin Perkins Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Deadlines for upcomming 59th IETF 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: , Content-Transfer-Encoding: 7bit Hi, The AVT WG is planning to have two sessions during the next IETF meeting, for a total of 4 or 4.5 hours. If you have issues or are going to submit drafts for the WG in Korea, please make note of the following deadlines. The deadline for submission of -00 internet-drafts is 9 am US EDT (GMT -04:00) on Monday the 9th of February. Individual submissions intended for eventual working group discussion should be named draft--avt--00.txt. Initial working group drafts, which have previously been approved by the chairs, may use the draft-ietf-avt- prefix. The deadline for all other internet-draft submissions is Monday 16th of February at 9 am US EDT. This day is also the last day to pre-register to the meeting, the cut-off is at 12.00 EDT. Any one desiring to have a presentation and discussion during the AVT working group's slots in Minneapolis MUST request time on the agenda. A submission of a draft is not sufficient for receiving agenda time. Send the request before the 16th of February, 2003 at 24.00 GMT to BOTH chairs. In the request include the following information: A. Presentation Title: B. Name of presenter: C. Draft Reference(s): D. Requested amount of time in minutes: Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 30 06:00:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08335 for ; Fri, 30 Jan 2004 06:00:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmWNj-0006pY-2E for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 06:00:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UB0DFL026204 for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 06:00:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmWNX-0006nB-Lu; Fri, 30 Jan 2004 06:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmWMa-0006jb-BF for avt@optimus.ietf.org; Fri, 30 Jan 2004 05:59:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08191 for ; Fri, 30 Jan 2004 05:59:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmWMW-0006ch-00 for avt@ietf.org; Fri, 30 Jan 2004 05:59:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmWLV-0006L3-00 for avt@ietf.org; Fri, 30 Jan 2004 05:57:58 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AmWKL-00065q-00 for avt@ietf.org; Fri, 30 Jan 2004 05:56:45 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0UAujYG004335; Fri, 30 Jan 2004 11:56:45 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DZZ9X4NR; Fri, 30 Jan 2004 11:56:45 +0100 Message-ID: <401A3803.7090206@ericsson.com> Date: Fri, 30 Jan 2004 11:54:59 +0100 X-Sybari-Trust: ea7dba80 6b512624 8d07a061 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: roni.even@polycom.co.il, avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-avt-rfc2032-bis-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have read this draft and have some comments. 1. All pages are missing the right page break codes. 2. Section 1. In the introduction I think the document should explain its status as being an update to RFC 2032. Isn't the intention to go to draft standard. I think this should be explained. 3. After Section 1. I am missing a "Conventions used in this document" section. This should mention RFC 2119 and also other conventions, like abbreviations, and that any picture is called frames that also is written somewhere else. The text in the document must also be updated using the normative language. 4. Section 2.1: Section 2.1, first paragraph: "Each MB carries information on a group of 16x16 pixels: luminance information is specified for 4 blocks of 8x8 pixels, while chrominance information is given by two "red" and "blue" colour difference components at a resolution of only 8x8 pixels." This sentence is strange. I think it means that within each MB of 16x16 pixels the luminance information is encoded for each pixel, sub divided into four 8x8 groups. While the chromiance information is subsampled, for 2x2 pixels, resulting in color resolution of 8x8 within the MB. 5. Section 2.1, The start code is specified as being 15 zeros and a single 1, I think one should clarify if this is bits or bytes. 6. Section 2.1. The start code bit-order is not obvious, as it is sometimes later in shortened form is represented as 10000000. 7. Section 3.1: The payload type specification. I think we should use some of the more explicit text, referring to profiles or dynamic allocation. Also the reference is wrong, it should be RFC 3551. 8. I haven't found any place requiring video data from different frames to be in separate RTP packets, however it seems a necessary restriction. 9. Section 3.1, The payload header I and V bits: Are these parameters not more suitable to be in a MIME parameter? I understand that we can't remove them. 10. Section 3.1: I am missing a more explicit section about what is allowed to place in the data part of the payload. 11. Section 4: I think this section should be brought up to current level by referencing the relevant techniques in published or on its way RFCs, like the FIR in the feedback specification. Also NACK formats, etc. 12. Section 4.1: The relation for these with the RTCP feedback document should be spelled out. 13. Section 4.1, second paragraph: " The H.261-specific control packets differ from normal RTCP packets in that they are not transmitted to the normal RTCP destination transport address for the RTP session (which is often a multicast address). Instead, these control packets are sent directly via unicast from the decoder to the coder. The destination port for these control packets is the same port that the coder uses as a source port for transmitting RTP (data) packets. Therefore, these packets may be considered "reverse" control packets." should this usage be allowed to continue, or should it be deprecated? It seems to have issues in relation to signalling, DOS, congestion control that will have to be explained in the updated version. Does implementations exist of this? 14. Section 5.1 the RTCP packet types registration, should probably be updated and included in this document? 15. Section 5: The parameters should be included in a semicolon separated list, not space separated. See RFC 3555. 16. Section 5.1.1: All the ANNEX values need to have values, otherwise they do not adhere to syntax. Therefore as they are binary, I can see two alternatives, either all get a 0 or 1 value, with a default of 0, i.e. not used. Or we create one parameter "annexes" which contain a list of the used annexes. 17. The document is missing clear RFC editor statements when it at least uses a replacement rule for the RFC number. 18. Section 5.1.1: The "author/Change controller" string has a stray ">". 19. Section 5.2: Again the space separated list, needs to be a semicolon separated list. 20. Section 5.2: Please write up offer/answer considerations. 21. Section 6. I think the security consideration needs to be expanded on in regards to the following topics: - The non-uniform decoder processing based on input, making DOS attacks possible. - The FIR and NACK issues, see rtcp feedback draft. - Congestion control, especially in regards to FIR and NACK - Integrity protection - Authentication 22. If this document is intended to go to draft, which I hope, the interoperability should be investigated. However it must not necessary go into the draft. 23. Section 8, Should become section 2, with another name. 24. Section 9. The second bullet is missing numbering. Also in regards to the optional new parameters, how does they effect interoperability. 25. Shouldn't there be at least an informative Reference to RFC 2032? 26. Authors list. you needs to dig up contact information for the other authors, Christian can't be a problem. If you fail you will have to remove them from the author list, and instead credit them somehow else. They must also agree to be ready to sign of the document when it is time for the authors 48 hours. -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 30 07:56:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13099 for ; Fri, 30 Jan 2004 07:56:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmYBw-0005ij-5b for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 07:56:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UCuCv2021942 for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 07:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmYBm-0005gK-MF; Fri, 30 Jan 2004 07:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmYAu-0005ev-DJ for avt@optimus.ietf.org; Fri, 30 Jan 2004 07:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13040 for ; Fri, 30 Jan 2004 07:55:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmYAt-0005h5-00 for avt@ietf.org; Fri, 30 Jan 2004 07:55:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmY9y-0005az-00 for avt@ietf.org; Fri, 30 Jan 2004 07:54:11 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AmY9j-0005Up-00 for avt@ietf.org; Fri, 30 Jan 2004 07:53:55 -0500 Received: from mangole ([130.209.247.112]:1054 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AmY99-0006bW-00; Fri, 30 Jan 2004 12:53:19 +0000 Date: Fri, 30 Jan 2004 12:53:38 +0000 From: Colin Perkins To: Magnus Westerlund Cc: avt@ietf.org Message-Id: <20040130125338.7d3a8b6a.csp@csperkins.org> In-Reply-To: <401A211D.7020107@ericsson.com> References: <401A211D.7020107@ericsson.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Deadlines for upcomming 59th IETF 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: , Content-Transfer-Encoding: 7bit --> Magnus Westerlund writes: > Hi, > > The AVT WG is planning to have two sessions during the next IETF > meeting, for a total of 4 or 4.5 hours. If you have issues or are going > to submit drafts for the WG in Korea, please make note of the following > deadlines. > > The deadline for submission of -00 internet-drafts is 9 am US EDT (GMT > -04:00) on Monday the 9th of February. Individual submissions intended > for eventual working group discussion should be named > draft--avt--00.txt. Initial working group > drafts, which have previously been approved by the chairs, may use the > draft-ietf-avt- prefix. > > The deadline for all other internet-draft submissions is Monday 16th of > February at 9 am US EDT. This day is also the last day to pre-register > to the meeting, the cut-off is at 12.00 EDT. A minor correction: both cutoff dates are at 9:00am EST (GMT -05:00). Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 30 09:59:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19473 for ; Fri, 30 Jan 2004 09:59:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ama72-0004uS-9z for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 09:59:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UExGAq018866 for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 09:59:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ama6n-0004tW-0i; Fri, 30 Jan 2004 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ama68-0004qA-Jh for avt@optimus.ietf.org; Fri, 30 Jan 2004 09:58:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19449 for ; Fri, 30 Jan 2004 09:58:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ama66-0006iG-00 for avt@ietf.org; Fri, 30 Jan 2004 09:58:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ama5F-0006aO-00 for avt@ietf.org; Fri, 30 Jan 2004 09:57:26 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1Ama4Y-0006Si-00 for avt@ietf.org; Fri, 30 Jan 2004 09:56:43 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0UEucYG027303; Fri, 30 Jan 2004 15:56:39 +0100 (MET) Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DZ59F4H8; Fri, 30 Jan 2004 15:56:50 +0100 Message-ID: <401A703C.6050006@ericsson.com> Date: Fri, 30 Jan 2004 15:54:52 +0100 X-Sybari-Trust: 7bd8999c 6b512624 10d098d8 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: roni.even@polycom.co.il, avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-ietf-avt-rfc2429bis-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Here is my comments on the update of RFC 2429. A lot of comments are similar to the ones for draft-ietf-avt-rfc2032-bis-00.txt. 1. Please try to submit documents with correct document dates, this says november. 2. In section 1, declare the intentions that this will update RFC 2429. 3. Conventions used in this document is missing. RFC 2119 pointer, and probably some other things should be here. 4. Section 2: fifth paragraph: Here I think one today should put in pointers at RTCP feedback. 5. Please work through and upgrade where appropriate to normative language. 6. Section 3: There should somewhere in the format specification be a note about that the usage of the timestamp make the RTCP jitter calculation to be less useful as it introduces jitter before transmission. 7. Section 3. Payload type: Please update the text with reference to profiles and usage of dynamic payload types. 8. Section 5.1: Reserved bits: I think it is appropriate to add: "MUST be ignored by receivers." 9. Section 5.1: PLEN: "If PLEN>0, the extra picture header is attached immediately following the rest of the payload header." I don't think it is clear enough what attached immediately following the rest of payload header. Is this before or after the other video redundancy coding header extension? 10. Section 6.1: What is the start code bit order? 11. Section 8.1, This registration updates the previous registered version in RFC 3555. please spell this out. 12. Section 8: Again the space separated list needs to be replace with semicolon separated. 13. Section 8.1: all parameters needs values, and default interpretations. Some parameters could be changed into values for a new aggregating parameter. 14. There is need for RFC editor consideration. 15. Section 8.1.1: In the Author/Change controller a stray ">" 16. Section 8.1.1: PAR: It does not define how the values are separated, colon maybe. 17. Section 8.1.2: I don't know if you can make a parameter registration though reference. 18. Section 8.2.1: Please change the title of "... options with SIP" to Offer/Answer. 19. Section 8.2.1: The order of the pictures size is not defined within the MIME parameter space at all. I think it belongs there if it is needed. 20. Section 8.2.1: The example using picture sizes: The definition of custom does not declare that space is allowed in the comma separated list. 21. Section 8.2.1: MaxBR and BPP: "MaxBitRate is video decoder property, hence it differs from SDP b : bandwidth-value attribute which refers more to application's total bandwidth (an application consists often of both audio and video)." What the b= SDP parameter refers to depends on the modifier, CT, AS, RS, RR. So I think you need to be a bit more specific here. 22. Section 9. I thought that most video codecs contains some non-uniform processing depending on input. Is this not at least a small threat of DOS. 23. Section 9: I am missing the following topics: Integrity, and Authentication. Congestion control on best effort networks is also a consideration as the codec can after all produce a rather high bandwidth. 24. Section 11, belongs in the conventions section in the beginning. 25. Should RFC 2190 be declared historic? 26. What MIME type should be recommended to support in this new version. 27. What is the interoperability status on all parts of this specification? 28. The new parameters and possibly some other changes needs interoperability statements. 29. Section 12: The numbering of the changes are strange. 30. Please get the correct contact information for the previous authors. And contact them to in regards to there possible interaction with this specification in the future. 31. Please get correct page breaks. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 30 11:49:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26746 for ; Fri, 30 Jan 2004 11:49:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbpO-0000LD-FM for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 11:49:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGnATq001255 for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 11:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbpF-0000JB-5g; Fri, 30 Jan 2004 11:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmboX-0000GZ-2s for avt@optimus.ietf.org; Fri, 30 Jan 2004 11:48:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26554; Fri, 30 Jan 2004 11:48:13 -0500 (EST) Message-Id: <200401301648.LAA26554@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, 30 Jan 2004 11:48:13 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-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 : RTP Payload Format for Uncompressed Video Author(s) : L. Gharai, C. Perkins Filename : draft-ietf-avt-uncomp-video-05.txt Pages : 19 Date : 2004-1-29 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, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-uncomp-video-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-uncomp-video-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-uncomp-video-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-30120834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-uncomp-video-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-uncomp-video-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30120834.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jan 30 13:30:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06964 for ; Fri, 30 Jan 2004 13:30:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdP8-0000vK-CB for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 13:30:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UIUAqm003501 for avt-archive@odin.ietf.org; Fri, 30 Jan 2004 13:30:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdOz-0000tL-PK; Fri, 30 Jan 2004 13:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdOL-0000sN-59 for avt@optimus.ietf.org; Fri, 30 Jan 2004 13:29:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06880 for ; Fri, 30 Jan 2004 13:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmdOI-0000Gg-00 for avt@ietf.org; Fri, 30 Jan 2004 13:29:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmdNJ-00008p-00 for avt@ietf.org; Fri, 30 Jan 2004 13:28:17 -0500 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1AmdML-0007mv-00 for avt@ietf.org; Fri, 30 Jan 2004 13:27:17 -0500 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0UIRGCJ012906 for ; Fri, 30 Jan 2004 10:27:17 -0800 (PST) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0UIRGuT024872 for ; Fri, 30 Jan 2004 10:27:16 -0800 (PST) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HSBF9E00.RYZ for ; Fri, 30 Jan 2004 10:27:14 -0800 Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: avt@ietf.org From: "John Lazzaro" Subject: Re: [AVT] Deadlines for upcomming 59th IETF meeting Date: Fri, 30 Jan 2004 10:27:13 -0800 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 > Magnus Westerlund writes: > > The deadline for all other internet-draft submissions is Monday 16th > of February at 9 am US EDT. Tentatively, the plan for the RTP MIDI documents is to wait until the 12th of February for comments, then spend the next four days updating the documents to submit -02.txt versions in time for the Feb 16th deadline. At the very least, -02.txt will be adjusted for the new Offer/Answer requirements. So, it would be ideal if folks who were interested in RTP MIDI could find the time to do a read-through and send along comments by Feb 12. If that's not possible, it would be good to know that there were folks who were planning to send in comments but needed more time to read them ... thanks, --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Jan 31 09:26:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21971 for ; Sat, 31 Jan 2004 09:26:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amw4Y-0008Tb-SS for avt-archive@odin.ietf.org; Sat, 31 Jan 2004 09:26:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0VEQAQP032534 for avt-archive@odin.ietf.org; Sat, 31 Jan 2004 09:26:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amw4Q-0008Rz-KA; Sat, 31 Jan 2004 09:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amw4O-0008RB-13 for avt@optimus.ietf.org; Sat, 31 Jan 2004 09:26:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21968 for ; Sat, 31 Jan 2004 09:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amw4M-0007Wc-00 for avt@ietf.org; Sat, 31 Jan 2004 09:25:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amw3U-0007R9-00 for avt@ietf.org; Sat, 31 Jan 2004 09:25:05 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1Amw2a-0007ED-00 for avt@ietf.org; Sat, 31 Jan 2004 09:24:08 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63688 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1Amw25-0004ZN-00; Sat, 31 Jan 2004 14:23:37 +0000 Date: Sat, 31 Jan 2004 14:23:52 +0000 From: Colin Perkins To: John Gildred Cc: avt@ietf.org Subject: Re: [AVT] Extending Parameters Message-Id: <20040131142352.22459d2e.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 --> John Gildred writes: > I have a question regarding RFC 3555 media types. Is it allowed to > include non-registered parameters with an existing IETF registered > media type? For example: video/mp2t; my-profile=p1 Such use does not conform to the standard. > If this is not allowed, how would I best provide this extra format info > in the content type without creating a new type? I am not so concerned > about SDP description, just the content type definition. If the MIME parameter is generally useful, the payload format RFC could be revised (as is happening for H.261 and H.263). -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt