From exim@www1.ietf.org Fri Aug 1 06:11:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04630 for ; Fri, 1 Aug 2003 06:11:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iWsm-0002F2-OT for avt-archive@odin.ietf.org; Fri, 01 Aug 2003 06:11:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71ABWjd008596 for avt-archive@odin.ietf.org; Fri, 1 Aug 2003 06:11:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iWsI-0002Dr-44; Fri, 01 Aug 2003 06:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVC2-00073t-Jx for avt@optimus.ietf.org; Fri, 01 Aug 2003 04:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02505 for ; Fri, 1 Aug 2003 04:23:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVBz-0003QO-00 for avt@ietf.org; Fri, 01 Aug 2003 04:23:15 -0400 Received: from ims.ku.edu.tr ([193.140.63.3] helo=ku.edu.tr) by ietf-mx with esmtp (Exim 4.12) id 19iVBy-0003Q7-00 for avt@ietf.org; Fri, 01 Aug 2003 04:23:15 -0400 Received: from fener.ku.edu.tr not authenticated [193.140.62.55] by ku.edu.tr with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Fri, 01 Aug 2003 11:30:10 +0300 Received: from mail-Message_Server by fener.ku.edu.tr with Novell_GroupWise; Fri, 01 Aug 2003 11:15:43 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 01 Aug 2003 11:15:37 +0200 From: "REHA CIVANLAR" To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [AVT] address search Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable As per the WG chairs' requests, I made a revision on RFC 2250. However, I = don't have the current coordinates of my co-authors. So, Don Hoffman and = Gerard Fernando, if you are still observing this list please let me know = your coordinates. Rest of the list, please accept my apologies for this. ------------------------------------------------------ M. Reha Civanlar Computer Engineering Department Ko=E7 University Istanbul, TURKEY +90 212 338 1719 rcivanlar@ku.edu.tr _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Aug 4 12:03:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02581 for ; Mon, 4 Aug 2003 12:03:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhnh-0003dT-JI for avt-archive@odin.ietf.org; Mon, 04 Aug 2003 12:03:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74G39BU013971 for avt-archive@odin.ietf.org; Mon, 4 Aug 2003 12:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhnZ-0003ci-Al; Mon, 04 Aug 2003 12:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhnV-0003cN-HI for avt@optimus.ietf.org; Mon, 04 Aug 2003 12:02:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02550; Mon, 4 Aug 2003 12:02:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jhnU-0003Hc-00; Mon, 04 Aug 2003 12:02:56 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19jhnT-0003HZ-00; Mon, 04 Aug 2003 12:02:55 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h74G2sJ01996; Mon, 4 Aug 2003 09:02:54 -0700 (PDT) Message-Id: <200308041602.h74G2sJ01996@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 04 Aug 2003 09:02:54 -0700 Subject: [AVT] RFC 3550 NOW AVAILABLE in PostScript Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3550 Title: RTP: A Transport Protocol for Real-Time Applications Author(s): H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Status: Standards Track Date: July 2003 Mailbox: schulzrinne@cs.columbia.edu, casner@acm.org, ronf@bluecoat.com, van@packetdesign.com Pages: 89 Characters: 630740 Obsoletes: 1889 I-D Tag: draft-ietf-avt-rtp-new-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3550.ps This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030804085920.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3550 --OtherAccess Content-Type: Message/External-body; name="rfc3550.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030804085920.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Aug 4 12:07:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02677 for ; Mon, 4 Aug 2003 12:07:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhrR-0003pM-ED for avt-archive@odin.ietf.org; Mon, 04 Aug 2003 12:07:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74G71sj014706 for avt-archive@odin.ietf.org; Mon, 4 Aug 2003 12:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhrQ-0003oC-Lg; Mon, 04 Aug 2003 12:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jhqh-0003nK-AK for avt@optimus.ietf.org; Mon, 04 Aug 2003 12:06:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02637; Mon, 4 Aug 2003 12:06:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jhqf-0003K8-00; Mon, 04 Aug 2003 12:06:13 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19jhqe-0003K5-00; Mon, 04 Aug 2003 12:06:13 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h74G6BJ03830; Mon, 4 Aug 2003 09:06:11 -0700 (PDT) Message-Id: <200308041606.h74G6BJ03830@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 04 Aug 2003 09:06:11 -0700 Subject: [AVT] RFC 3551 NOW AVAILABLE in PostScript Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3551 Title: RTP Profile for Audio and Video Conferences with Minimal Control Author(s): H. Schulzrinne, S. Casner Status: Standards Track Date: July 2003 Mailbox: schulzrinne@cs.columbia.edu, casner@acm.org Pages: 38 Characters: 317286 Obsoletes: 1890 I-D Tag: draft-ietf-avt-profile-new-13.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3551.ps This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030804090313.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3551 --OtherAccess Content-Type: Message/External-body; name="rfc3551.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030804090313.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Aug 5 10:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12993 for ; Tue, 5 Aug 2003 10:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2bf-0000j4-Q3 for avt-archive@odin.ietf.org; Tue, 05 Aug 2003 10:16:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75EG7PS002784 for avt-archive@odin.ietf.org; Tue, 5 Aug 2003 10:16:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2ba-0000fi-3y; Tue, 05 Aug 2003 10:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2ao-0000eR-Fz for avt@optimus.ietf.org; Tue, 05 Aug 2003 10:15:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12690; Tue, 5 Aug 2003 10:15:08 -0400 (EDT) Message-Id: <200308051415.KAA12690@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, 05 Aug 2003 10:15:08 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-retransmission-09.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Retransmission Payload Format Author(s) : J. Rey et al. Filename : draft-ietf-avt-rtp-retransmission-09.txt Pages : 27 Date : 2003-8-5 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-09.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-09.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-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-5090151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-retransmission-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5090151.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 Aug 6 12:56:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24381 for ; Wed, 6 Aug 2003 12:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRZ4-00068M-9r for avt-archive@odin.ietf.org; Wed, 06 Aug 2003 12:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Gt6Te023572 for avt-archive@odin.ietf.org; Wed, 6 Aug 2003 12:55:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRYz-00067d-2M; Wed, 06 Aug 2003 12:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kNcE-0003Jb-SJ for avt@optimus.ietf.org; Wed, 06 Aug 2003 08:42:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14253; Wed, 6 Aug 2003 08:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kNaX-0002Sk-00; Wed, 06 Aug 2003 08:40:21 -0400 Received: from orion.lrg.ufsc.br ([150.162.63.1] helo=lrg.ufsc.br) by ietf-mx with esmtp (Exim 4.12) id 19kNaV-0002Sg-00; Wed, 06 Aug 2003 08:40:20 -0400 Received: from localhost (westphal@localhost) by (8.9.3+Sun/8.9.3) with ESMTP id JAA19562 Date: Wed, 6 Aug 2003 09:23:37 -0400 (WST) From: Carlos Becker Westphall To: noms2004-oc@noms2004.org cc: liste_cfip@info.uqam.ca, tccc@comsoc.org, itc@comsoc.org, rmt@lbl.gov, mboned@network-services.uoregon.edu, avt@ietf.org, nanog@merit.edu, news-announce-conferences@uunet.uu.net, amlist@takilab.k.dendai.ac.jp, disman@dorothy.bmc.com, aaa-wg@merit.edu, rmonmib@ietf.org, policy@ietf.org, snmpv3@lists.tislabs.com, sming@ops.ietf.org, mpls@uu.net, mobile-ip@sunroof.eng.sun.com, gsmp@ietf.org, diffserv@ietf.org, sip@ietf.org, manet@ietf.org, cfp@mmlab.snu.ac.kr, conf@colmar.uha.fr, multicomm@research.panasonic.com, nemo@nal.motlabs.com, seamoby@ietf.org, TCPC.Mail@rome.ece.cornell.edu, dares-announcement@enst-bretagne.fr, dnac_2002@yahoo.fr, all@inf.ethz.ch, all_ifi@ifi.unizh.ch, arl@arl.wustl.edu, commsoft@ieee.org, comswtc@ieee.org, confs-conferencesa@comsoc.org, cost263@fokus.gmd.de, cost264@lip6.fr, disman@dorothy.bmc.com, enternet@bbn.com, gi-fb3@fokus.gmd.de, giga@tele.pitt.edu, ifip-tc6@informatik.rwth-aachen.de, int-serv@ISI.EDU, issll@mercury.lcs.mit.edu, itc@i-teletraffic.org, itc@ieee.org, kom-meeting@KOM.th-darmstadt.de, KUVS-L@listserv.uni-heidelberg.de, kuvs-elg@fokus.gmd.de, mmb@ira.uka.de, multicomm@comsoc.org, members@ngni.org, netnomics@listserver.tue.nl, nichains@BXL.DG13.cec.eu.int, pilc@grc.nasa.gov, reres@laas.fr, RHDM@lip6.fr, rm@openmash.org, sigmetrics-bb@haven.epm.ornl.gov.cnri.reston.va.us, spects02@comp.leeds.ac.uk, tcgn@ieee.org, tcgn@majordomo.ieee.org, tcpp-announce@eece.unm.edu, tik@tik.ee.ethz.ch, wiss-mitarb@ee.ethz.ch, xtp-relay@cs.concordia.ca, jwkhong@postech.ac.kr, Carlos Becker Westphall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] NOMS 2004 - Nine days to the Deadline - 15th August 2003 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , ***** Paper submission deadline extended to Friday 15th August 2003 ***** Network Operation & Management Symposium 2004 "Managing Next Generation Convergence Networks and Services" Seoul Korea, 19-23, April 2004 See < http://www.noms2004.org/> for latest information The 9th IEEE/IFIP Network Operations and Management Symposium (NOMS 2004) will be held 19-23 April, 2004 at Seoul, Korea. Held in the even-numbered years since 1988, NOMS 2004 will continue the established tradition of NOMS and IM as the primary forum for technical exchange of research, standards, development, systems integrator, service providers, and user communities. NOMS 2004 will present the latest approaches and technical solutions in the area of network operations and management. An exciting, peer-reviewed program of technical sessions, tutorials, posters, panels and vendor exhibits will address the ever-increasing interest in overall management solutions for all types of communications and computing networks, systems, services and enterprise applications. The concept of network convergence has recently emerged as a new attempt for the merging of telephony and data networks into a single, multi-service network exploiting the ubiquity of the Internet Protocol. For this increasingly attractive business model, in both wired and wireless domains, strategic research is required to devise the best integration architectures, operations and management solutions. This creates a unique opportunity for the network operation and management community to respond to the ever-increasing demand for network resilience, security, quality-of-service and mobility management at unprecedented scales. The NOMS 2004 provides the forum for discussing these research challenges and many others inherent to the integrated management of next generation converged networks and services. This year NOMS 2004 will broaden the scope of previous IM and NOMS by expanding its program to include a broader set of topics ranging from network operation and management to network planning, service engineering and business processes for network and service management. Special attention will be given to experiences that emphasize lessons learned and reports on practice from industry. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal. Authors are also invited to submit proposals for tutorials, panel discussions, poster demonstrations, or birds-of-a-feather sessions. Important Dates: Deadline for Submitting Papers: 15 August 2003 Deadline for Tutorials, Panels and Posters: 1 October 2003 Notification of Acceptance:15 November 2003 Deadline for Submitting Revised Papers:15 December 2003 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Aug 10 22:57:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22433 for ; Sun, 10 Aug 2003 22:57:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m2s9-0006z8-87 for avt-archive@odin.ietf.org; Sun, 10 Aug 2003 22:57:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B2vPSH026840 for avt-archive@odin.ietf.org; Sun, 10 Aug 2003 22:57:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m2rl-0006yA-TX; Sun, 10 Aug 2003 22:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m2qq-0006xW-CM for avt@optimus.ietf.org; Sun, 10 Aug 2003 22:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22400 for ; Sun, 10 Aug 2003 22:55:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m2qm-0002Qu-00 for avt@ietf.org; Sun, 10 Aug 2003 22:56:00 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 19m2qm-0002Qr-00 for avt@ietf.org; Sun, 10 Aug 2003 22:56:00 -0400 Received: from [68.100.8.94] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1724355 for ; Sun, 10 Aug 2003 22:56:00 -0400 From: "Marshall Eubanks" To: avt@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Sun, 10 Aug 2003 22:56:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [AVT] RR Reporting Extensions ? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello; Can anyone tell me what has happened to draft-ietf-avt-rtcp-report-extns , RTCP reporting extensions ? Did this make RFC ? What is the current version ? Regards Marshall Eubanks T.M. Eubanks e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Our New Video Service is in Beta testing http://www.americafree.tv _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Aug 10 23:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22668 for ; Sun, 10 Aug 2003 23:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m37H-0007XO-6B for avt-archive@odin.ietf.org; Sun, 10 Aug 2003 23:13:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B3D3n6028946 for avt-archive@odin.ietf.org; Sun, 10 Aug 2003 23:13:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m37D-0007WK-Nm; Sun, 10 Aug 2003 23:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m36i-0007W4-GY for avt@optimus.ietf.org; Sun, 10 Aug 2003 23:12:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22661 for ; Sun, 10 Aug 2003 23:12:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m36g-0002UK-00 for avt@ietf.org; Sun, 10 Aug 2003 23:12:26 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19m36g-0002UH-00 for avt@ietf.org; Sun, 10 Aug 2003 23:12:26 -0400 Received: from alansnotebook [66.156.11.167] by telchemy.com with ESMTP (SMTPD32-7.14) id A9422350078; Sun, 10 Aug 2003 23:10:58 -0400 From: "Alan Clark" To: "Marshall Eubanks" , Subject: RE: [AVT] RR Reporting Extensions ? Date: Sun, 10 Aug 2003 23:16:53 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marshall Draft -06 was approved by the IESG and is now in the RFC Editor queue. You can track it's progress through the IESG section of the IETF web site. Regards Alan Clark -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Marshall Eubanks Sent: Sunday, August 10, 2003 10:56 PM To: avt@ietf.org Subject: [AVT] RR Reporting Extensions ? Hello; Can anyone tell me what has happened to draft-ietf-avt-rtcp-report-extns , RTCP reporting extensions ? Did this make RFC ? What is the current version ? Regards Marshall Eubanks T.M. Eubanks e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Our New Video Service is in Beta testing http://www.americafree.tv _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Aug 11 04:16:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09820 for ; Mon, 11 Aug 2003 04:16:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m7qm-0001Kq-BA for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 04:16:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B8GKWx005132 for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 04:16:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m7qW-0001KD-SI; Mon, 11 Aug 2003 04:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m7qK-0001Jt-JW for avt@optimus.ietf.org; Mon, 11 Aug 2003 04:15:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09804 for ; Mon, 11 Aug 2003 04:15:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m7qH-0003pI-00 for avt@ietf.org; Mon, 11 Aug 2003 04:15:49 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19m7qH-0003pF-00 for avt@ietf.org; Mon, 11 Aug 2003 04:15:49 -0400 Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Aug 2003 10:15:44 +0200 From: "Jose Rey" To: "Colin Perkins" Cc: Subject: RE: [AVT] 3GPP timed text draft: more generic? Date: Mon, 11 Aug 2003 10:15:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20030728061758.2c17d347.csp@csperkins.org> Importance: Normal Reply-By: Tue, 5 Aug 2003 13:30:00 +0200 X-Message-Flag: Follow up X-OriginalArrivalTime: 11 Aug 2003 08:15:44.0187 (UTC) FILETIME=[C2CA80B0:01C35FE0] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, --snip Colin Perkins wrote: > A specific payload format for 3GPP timed text might be > appropriate, but I > would like to understand the options and alternatives before > we make that > choice. Is 3GPP the only body doing timed and/or decorated > text? If not, > what are the alternatives, and how do they relate? > > -- at the moment there are at least two more standardisation bodies interested in timed text: MPEG and W3C. - MPEG is currently defining their own TT format based on 3GPP TT (see Committee Draft of ISO/IEC 14496-17 from July'03 Meeting in Trondheim) by defining the access unit structure, the stream type, the object type indication and decoder specific info of the timed text samples. The definition of these items enables the transport over RTP using the mpeg4simple draft. The work in MPEG is assumed to be finalised around July 2004. - W3C is at a very early stage in defining a timed text authoring format. It has recently (May'03) published a draft for use cases and requirements of a timed text authoring format: http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030515/. This draft has a rather long list of requirements and lists many functionalities. In my understanding W3C targets to a generic format with rich functionality. I don't know how quick it may develop (anyone?). None of these above is an option for us, because 1) the only timed text format in 3GPP is 3GPP timed text 2) 3GPP has not adopted the mpeg4simple for transport and 3) for this 3GPP timed text format we need an RTP payload format within the current 3GPP Release 6 schedule (i.e. March'04). cheers, Jose > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, July 28, 2003 3:18 PM > To: Jose Rey > Cc: avt@ietf.org > Subject: Re: [AVT] 3GPP timed text draft: more generic? > > > --> "Jose Rey" writes: > > > > Hi all, > > > > during the presentation of the payload format for 3GPP > timed text some > > concerns arose on whether this work should be more generic. On the > > other hand I also emphasized the fact that there's a > deadline to meet > > here for 3GPP Release 6: March '04. > > > > It is our opinion that, in this case, a more specific > payload format for > > the 3GPP timed text format is the right way to go. Does > anybody think > > otherwise? We would like to hear comments/critic on this, > in order to > > progress to working group work item. How could it be made > more generic? > > Colin Perkins > csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Aug 11 04:49:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10438 for ; Mon, 11 Aug 2003 04:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8MT-0002P6-6X for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 04:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B8n5ph009239 for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 04:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8MO-0002OQ-TP; Mon, 11 Aug 2003 04:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7mx-0005Sw-NM for avt@optimus.ietf.org; Fri, 08 Aug 2003 10:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11071 for ; Fri, 8 Aug 2003 10:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7mv-0000sL-00 for avt@ietf.org; Fri, 08 Aug 2003 10:00:13 -0400 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 19l7mu-0000rc-00 for avt@ietf.org; Fri, 08 Aug 2003 10:00:12 -0400 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) for id 19l7mK-00052F-Lm; Fri, 08 Aug 2003 15:59:36 +0200 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Fri, 8 Aug 2003 15:59:35 +0200 (CEST) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) for id 19l7mC-0004cw-LT; Fri, 08 Aug 2003 15:59:28 +0200 Received: from almathea (mail@almathea.tkn.TU-Berlin.DE [130.149.49.56]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h78DxRC08294 for ; Fri, 8 Aug 2003 15:59:27 +0200 Received: from karl by almathea with local (Exim 3.35 #1 (Debian)) id 19l7mB-00033n-00 for ; Fri, 08 Aug 2003 15:59:27 +0200 To: avt@ietf.org Message-Id: From: Holger Karl Date: Fri, 08 Aug 2003 15:59:27 +0200 X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Fri, 08 Aug 2003 15:59:30 +0200 Subject: [AVT] Call for Papers: WiOpt'04 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Note: The submission deadline is 5th of November, 2003. *************************************************** ******** CALL FOR PAPERS ******** *************************************************** * * * WiOpt '04 * * * * 2nd Workshop on Modeling and Optimization * * in Mobile, Ad Hoc and Wireless Networks * * * * March 24 - 26, 2004, Cambridge, UK * * * * * *************************************************** Workshop Website: http://www.cl.cam.ac.uk/Research/SRG/wiopt04/ This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocol design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad hoc networks. Papers to be presented at WiOpt'04 will be selected based on extended abstracts of up to 8 pages, double-spaced, 12 point font size. The submission should not exceed 3000 words including tables and figures, each of which count as 250 words. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of the MONET journal. Plenary Speakers: Bruce Hajek (University of Illinois at Urbana-Champaign, USA) Ian Akyildiz (Georgia Institute of Technology, USA) IMPORTANT DATES: Submission of extended abstract: Nov. 5, 2003. Notification of acceptance: Jan. 15, 2003. Camera ready copy: Feb. 15, 2003. (Further details on the workshop website, http://www.cl.cam.ac.uk/Research/SRG/wiopt04/) General chairman: Imrich Chlamtac Vice General Chair: Roger Whitaker Program Co-Chairs: Marco Conti and Tamer Basar Program committee of the conference: Eitan Altman, Venkat Anantharam, Konstantin Avrachenkov, Andrew Campbell, A. Chockalingam, Jon Crowcroft, Silvia Giordano, Stephen V. Hanly, Jean-Pierre Hubaux, Holger Karl, Peter Key, P. R. Kumar, Peter Marbach, Philippe Nain, Sven Oestring, Yoshikuni Onozato, Ramesh Rao, Ness Shroff, Violet Syrotiuk, Thierry Turletti, Adam Wolisz, Jeff Wieselthier Local Arrangements Co-Chair: Sven Oestring and Julian Chesterfield Publicity Chair: Holger Karl Sponsors: The workshop is co-sponsored by * Univ. of Cambridge * IIT (Istituto di Informatica e Telematica) * Intel * Microsoft * IEEE IT Society (technical co-sponsorship) (ACM sponsorship is pending.) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Aug 11 05:36:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11422 for ; Mon, 11 Aug 2003 05:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m95x-0003zt-B1 for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 05:36:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B9a5gZ015354 for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 05:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m95t-0003yy-T1; Mon, 11 Aug 2003 05:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m95G-0003ye-F2 for avt@optimus.ietf.org; Mon, 11 Aug 2003 05:35:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11308 for ; Mon, 11 Aug 2003 05:35:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m95D-0004GV-00 for avt@ietf.org; Mon, 11 Aug 2003 05:35:19 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19m95C-0004GR-00 for avt@ietf.org; Mon, 11 Aug 2003 05:35:18 -0400 Received: from alor ([130.209.247.84]:53957 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19m94Z-0005HV-00 for avt@ietf.org; Mon, 11 Aug 2003 10:34:39 +0100 Date: Mon, 11 Aug 2003 10:34:33 +0100 Subject: Re: [AVT] Working group last call: draft-ietf-avt-rfc2833bis-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Colin Perkins To: avt@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <20030727181503.3e3ce1d3.csp@csperkins.org> Message-Id: <043832C5-CBDF-11D7-B8F1-000A957FC5F2@csperkins.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, Jul 28, 2003, at 02:15 Europe/London, Colin Perkins wrote: > This is to announce a working group last call on the RTP Payload for > DTMF > Digits, Telephony Tones and Signals . > Please send any final comments on this draft to the mailing list by > 11th > August 2003. If no substantive technical issues are raised, we intend > to > submit this draft for publication as a proposed standard RFC to > obsolete > RFC 2833. > > Note that this draft will not be advanced until we receive at least one > valid review from someone not directly involved with production of the > draft (i.e., not an author or contributor). This is to solicit reviews of the draft-ietf-avt-rfc2833bis-03.txt. As noted above, we will not advance the draft until at least one valid technical review, from someone not directly involved with the production of the draft, is received. -- 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 Aug 11 06:04:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11850 for ; Mon, 11 Aug 2003 06:04:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m9Wz-0004w5-LE for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 06:04:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BA4186018967 for avt-archive@odin.ietf.org; Mon, 11 Aug 2003 06:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m9Wy-0004vN-TI; Mon, 11 Aug 2003 06:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m9WG-0004vC-BO for avt@optimus.ietf.org; Mon, 11 Aug 2003 06:03:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11846 for ; Mon, 11 Aug 2003 06:03:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m9WC-0004QS-00 for avt@ietf.org; Mon, 11 Aug 2003 06:03:12 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19m9WC-0004QC-00 for avt@ietf.org; Mon, 11 Aug 2003 06:03:12 -0400 Received: from alor ([130.209.247.84]:54010 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19m9Vj-0005fS-00; Mon, 11 Aug 2003 11:02:43 +0100 Date: Mon, 11 Aug 2003 11:02:37 +0100 Subject: Re: [AVT] 3GPP timed text draft: more generic? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Jose Rey" From: Colin Perkins In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, Aug 11, 2003, at 09:15 Europe/London, Jose Rey wrote: > Colin Perkins wrote: >> A specific payload format for 3GPP timed text might be >> appropriate, but I >> would like to understand the options and alternatives before >> we make that >> choice. Is 3GPP the only body doing timed and/or decorated >> text? If not, >> what are the alternatives, and how do they relate? >> >> -- > > at the moment there are at least two more standardisation bodies > interested in timed text: MPEG and W3C. > > - MPEG is currently defining their own TT format based on 3GPP TT (see > Committee Draft of ISO/IEC 14496-17 from July'03 Meeting in Trondheim) > by defining the access unit structure, the stream type, the object type > indication and decoder specific info of the timed text samples. The > definition of these items enables the transport over RTP using the > mpeg4simple draft. The work in MPEG is assumed to be finalised around > July 2004. > > - W3C is at a very early stage in defining a timed text authoring > format. It has recently (May'03) published a draft for use cases and > requirements of a timed text authoring format: > http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030515/. This draft has a > rather long list of requirements and lists many functionalities. In my > understanding W3C targets to a generic format with rich functionality. > I > don't know how quick it may develop (anyone?). I believe SMPTE may also have timed text work in their Digital Cinema group? > None of these above is an option for us, because 1) the only timed text > format in 3GPP is 3GPP timed text 2) 3GPP has not adopted the > mpeg4simple for > transport and 3) for this 3GPP timed text format we need an RTP payload > format within the current 3GPP Release 6 schedule (i.e. March'04). I agree that using the MPEG4-simple format doesn't make sense, and that the W3C schedule looks to be too long for 3GPP requirements. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Aug 12 10:18:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15437 for ; Tue, 12 Aug 2003 10:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZyZ-0004On-3C for avt-archive@odin.ietf.org; Tue, 12 Aug 2003 10:18:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CEIFvl016905 for avt-archive@odin.ietf.org; Tue, 12 Aug 2003 10:18:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZyM-0004LH-Ax; Tue, 12 Aug 2003 10:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZxj-0004KW-AP for avt@optimus.ietf.org; Tue, 12 Aug 2003 10:17:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15232; Tue, 12 Aug 2003 10:17:16 -0400 (EDT) Message-Id: <200308121417.KAA15232@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, 12 Aug 2003 10:17:16 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-mpeg1and2-mod-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 MPEG1/MPEG2 Author(s) : D. Hoffman et al. Filename : draft-ietf-avt-mpeg1and2-mod-00.txt Pages : 15 Date : 2003-8-12 This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. Most of this memo is identical to RFC 2250, an Internet standards track RTP payload format definition. No changes have been made in the packet formats on the wire. The main reason for this revision is to allow the use of this payload format with dynamic payload types that can specify the timestamp clock frequency by non-RTP means for improved jitter compensation. We used this opportunity to improve the description of the payload format specification by clarifying some wording that have been reported to be problematic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mpeg1and2-mod-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-mpeg1and2-mod-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-mpeg1and2-mod-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-12102748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mpeg1and2-mod-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mpeg1and2-mod-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-12102748.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 Aug 12 11:12:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18309 for ; Tue, 12 Aug 2003 11:12:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19maof-0006UN-0V for avt-archive@odin.ietf.org; Tue, 12 Aug 2003 11:12:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CFC4rb024937 for avt-archive@odin.ietf.org; Tue, 12 Aug 2003 11:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19maoZ-0006Td-Bz; Tue, 12 Aug 2003 11:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mant-0006OW-Ll for avt@optimus.ietf.org; Tue, 12 Aug 2003 11:11:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18270 for ; Tue, 12 Aug 2003 11:11:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19manq-0001Ss-00 for avt@ietf.org; Tue, 12 Aug 2003 11:11:15 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19manq-0001SC-00 for avt@ietf.org; Tue, 12 Aug 2003 11:11:14 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CFAf300016; Tue, 12 Aug 2003 11:10:41 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYGYZKA0; Tue, 12 Aug 2003 11:10:42 -0400 Received: from nortelnetworks.com (acart1gn.ca.nortel.com [47.129.129.196]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYPT23S0; Tue, 12 Aug 2003 11:10:41 -0400 Message-ID: <3F39036F.5000906@nortelnetworks.com> Date: Tue, 12 Aug 2003 11:10:39 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: avt@ietf.org CC: paulej@packetizer.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] [Fwd: I-D ACTION:draft-jones-avt-audio-t38-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 What's this all about? First point is that image/t38 is already a registered MIME type. Second point is that T.38 does NOT use RTP transport, in contradiction to the statement in the I-D that it does. -------- Original Message -------- Subject: I-D ACTION:draft-jones-avt-audio-t38-00.txt Date: Mon, 11 Aug 2003 15:46:16 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration Author(s) : P. Jones Filename : draft-jones-avt-audio-t38-00.txt Pages : 4 Date : 2003-8-11 This document defines the MIME sub-type audio/t38. The packetization and usage of this MIME type, which is intended for use within SDP [2] and H.248 [3] systems, is specified within ITU-T Recommendation T.38 [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jones-avt-audio-t38-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 ... _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Aug 12 22:22:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07029 for ; Tue, 12 Aug 2003 22:22:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mlHA-0006Cm-UV for avt-archive@odin.ietf.org; Tue, 12 Aug 2003 22:22:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D2MCgx023852 for avt-archive@odin.ietf.org; Tue, 12 Aug 2003 22:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mlH0-0006C8-8I; Tue, 12 Aug 2003 22:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mlGj-0006Bx-VR for avt@optimus.ietf.org; Tue, 12 Aug 2003 22:21:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07026 for ; Tue, 12 Aug 2003 22:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mlGg-0005Oo-00 for avt@ietf.org; Tue, 12 Aug 2003 22:21:42 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19mlGg-0005Oh-00 for avt@ietf.org; Tue, 12 Aug 2003 22:21:42 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h7D2LVJA020108; Tue, 12 Aug 2003 22:21:32 -0400 Message-ID: <01ae01c36141$9cc635f0$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "Tom Taylor" , References: <3F39036F.5000906@nortelnetworks.com> Date: Tue, 12 Aug 2003 22:21:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] Re: I-D ACTION:draft-jones-avt-audio-t38-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 Tom, The purpose is to register the MIME type "audio/t38". The reason is that work is underway within ITU-T Q14/16 to support the carriage of T.38's IFP packets through RTP. This will allow us to then signal a single "m=" like that looks like this: m=audio 5600 RTP/AVP 18 98 a=rtpmap:98 t38/8000 When two media gateways have negotiated this (or similar) SDP and a fax tone is detected on the line side, a mode shift may occur by simply transmitting packets with PT=98, rather than PT=18. This reduces the need for either consuming additional UDP ports per call for image/t38 or going through a lengthy exchange of messages to open a fax channel. Paul ----- Original Message ----- From: "Tom Taylor" To: Cc: Sent: Tuesday, August 12, 2003 11:10 AM Subject: [Fwd: I-D ACTION:draft-jones-avt-audio-t38-00.txt] > What's this all about? First point is that image/t38 is already a registered MIME > type. Second point is that T.38 does NOT use RTP transport, in contradiction to the > statement in the I-D that it does. > > -------- Original Message -------- > Subject: I-D ACTION:draft-jones-avt-audio-t38-00.txt > Date: Mon, 11 Aug 2003 15:46:16 -0400 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type > Registration > Author(s) : P. Jones > Filename : draft-jones-avt-audio-t38-00.txt > Pages : 4 > Date : 2003-8-11 > > This document defines the MIME sub-type audio/t38. The packetization > and usage of this MIME type, which is intended for use within SDP [2] > and H.248 [3] systems, is specified within ITU-T Recommendation T.38 > [1]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-jones-avt-audio-t38-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 > ... > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 13 04:54:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12774 for ; Wed, 13 Aug 2003 04:54:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mrOb-00064M-H8 for avt-archive@odin.ietf.org; Wed, 13 Aug 2003 04:54:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D8sHpS023290 for avt-archive@odin.ietf.org; Wed, 13 Aug 2003 04:54:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mrOO-000631-TU; Wed, 13 Aug 2003 04:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mrNo-0005zm-Cb for avt@optimus.ietf.org; Wed, 13 Aug 2003 04:53:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12750 for ; Wed, 13 Aug 2003 04:53:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mrNl-0007h8-00 for avt@ietf.org; Wed, 13 Aug 2003 04:53:25 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19mrNk-0007h5-00 for avt@ietf.org; Wed, 13 Aug 2003 04:53:24 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7D8rPgM016963 for ; Wed, 13 Aug 2003 10:53:25 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 13 Aug 2003 10:53:29 +0200 Message-ID: <1F55F6582266314A85A55F6241509B67078E5458@Esealnt863.al.sw.ericsson.se> From: "Karl Norrman (KI/EAB)" To: "'avt@ietf.org'" Subject: Re: [AVT] possible error on testvectors of draft "draft-ietf-avt- srtp-08.txt" Date: Wed, 13 Aug 2003 10:51:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hello, As Claudio Thomas points out, there is an error in the test-vectors for f8-mode present in the draft. To aid implementors of f8-mode we would like to make more test-vectors available. It would be nice if anyone with an implementation could verify the test-vectors retrievable through this link: http://standards.ericsson.net/fli/drafts.html Our intention is to incorporate a reference to these in the next version. Regards, Karl > Actual link: >http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-08.txt > > > Chapter B.1 AES-f8 Test Vectors (page 52) > > > Position: j=2 > > > IV' XOR j : 595b699bbd3bc0df26062093c1ad8f70 > > Should be > > IV' XOR j : 595b699bbd3bc0df26062093c1ad8f71 > > > Reason: > > Last byte of IV' = 73, j=02: 73 xor 02 = 71 (0011 xor 0010 = 0001) > > > If my calculator is right, then the values after this position also can't be correct. > > > Do someone have already implemented it to give me working vextors? Or can somebody explain me >what is wrong on my calc? > > > Thanks, > > > Claudio _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Aug 15 20:21:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18723 for ; Fri, 15 Aug 2003 20:21:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nooa-0004oo-TB for avt-archive@odin.ietf.org; Fri, 15 Aug 2003 20:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7G0L4t7018520 for avt-archive@odin.ietf.org; Fri, 15 Aug 2003 20:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nooX-0004mw-3D; Fri, 15 Aug 2003 20:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nonh-0004mN-8S for avt@optimus.ietf.org; Fri, 15 Aug 2003 20:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18683 for ; Fri, 15 Aug 2003 20:20:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nonf-00076r-00 for avt@ietf.org; Fri, 15 Aug 2003 20:20:07 -0400 Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx with esmtp (Exim 4.12) id 19none-00076o-00 for avt@ietf.org; Fri, 15 Aug 2003 20:20:06 -0400 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.3)); Fri, 15 Aug 2003 17:16:18 -0700 Received: from pcirvarchen (dhcp-2-138-183.broadcom.com [10.2.138.183]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA28117 for ; Fri, 15 Aug 2003 17:19:23 -0700 (PDT) From: "Raymond Chen" To: avt@ietf.org Subject: RE: [AVT] Comments on draft-chen-rtp-bv-00.txt Date: Fri, 15 Aug 2003 17:21:48 -0700 Message-ID: <011d01c3638c$61e6c1f0$b78a020a@pcirvarchen> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-WSS-ID: 1323A85B935-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Magnus and Colin, Thank you very much for taking the time to read our draft and for providing useful comments. We are reviewing your comments and all other feedback and are working on a draft 01 to incorporate changes. We hope to have a revised version before long. Thanks. Raymond -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Friday, July 25, 2003 8:28 AM To: IETF AVT WG Subject: [AVT] Comments on draft-chen-rtp-bv-00.txt Hi, Here are some comments on this draft. Before this I would like to say thank you to the authors for providing a very good initial version of the draft. I have very few comments. 1. There is need to tighten up the use of aggregation of consecutive frames. I would propose that in section 3.2 and 4.2 add a sentence stating that any frames in payload MUST be consecutive. If that is not intended there is need for having some mechanism for recovering the timestamp for each individual frame. 2. Section 3 and 4 are both missing specification for how to use the marker bit. I would suggest the normal definition that for packets with there first frame being an speech onset the marker bit is set to 1, otherwise 0. Please see draft-ietf-avt-profile-new-13.txt 3. I would also like to see some more text on how one recovers the RTP timestamp for an aggregated frame. I now that as long as you only intend to aggregate consecutive frames it will be RTP TS + TS_rate*0.005*(n-1) however this should be written out. 4. I would also suggest that you tighten the language in Section 5 regarding that BroadVoice 16 and 32 frames shall not be mixed in a file. Please use the suitable RFC 2119 language for this. 5. Section 6.1, the usage of maxptime. Are there any need to define a default value for maxptime and especially of selecting 200 ms? 6. Section 6.1, Public Specification. This needs to be a complete reference. 7. Section 7. I would suggest that you improve your text for how to map the parameters to SDP. I would suggest borrowing text from section 8.3 of RFC 3267. 8. The reference list needs to be split into normative and informative references. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Aug 17 23:59:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27529 for ; Sun, 17 Aug 2003 23:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19obAn-0004yF-2i for avt-archive@odin.ietf.org; Sun, 17 Aug 2003 23:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7I3xDLH019104 for avt-archive@odin.ietf.org; Sun, 17 Aug 2003 23:59:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19obAb-0004xZ-I8; Sun, 17 Aug 2003 23:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19obAD-0004xN-Hv for avt@optimus.ietf.org; Sun, 17 Aug 2003 23:58:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27524 for ; Sun, 17 Aug 2003 23:58:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19obAB-0004VH-00 for avt@ietf.org; Sun, 17 Aug 2003 23:58:35 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19obAA-0004VA-00 for avt@ietf.org; Sun, 17 Aug 2003 23:58:34 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7I3vwD04490; Sun, 17 Aug 2003 23:57:58 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYKXJCBA; Sun, 17 Aug 2003 23:57:58 -0400 Received: from nortelnetworks.com (acart1cc.ca.nortel.com [47.129.129.55]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q8CYHRCJ; Sun, 17 Aug 2003 23:57:58 -0400 Message-ID: <3F404EC2.30804@nortelnetworks.com> Date: Sun, 17 Aug 2003 23:57:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: avt@ietf.org CC: hgs@cs.columbia.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Review comments on draft-ietf-avt-rfc2833bis-03.txt (part 1) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Need the brief IETF copyright declaration at the beginning? Abstract: isn't this intended to replace rather than merely update RFC 2833? Page 2 first para: suggest "and" instead of "as well as" to provide more balance in the list of applications in the first sentence, and "In the second application.." rather than "Secondly.." further down. Otherwise the reader is left searching for the second application. Page 3 second-last para, last sentence, might be rephrased: "Busy tone is generated by the ISDN terminal or, for analog instruments, by the caller's switch, triggered by the appropriate ISUP message." Page 4 first para might better read: "If a gateway cannot provide a tone representation, it SHOULD send the named signals and also send the audio tones as regular RTP audio packets ...". Page 4, second-last para seems to have been cut off after "RFC 2198 [4] is used to". Page 4 last para, first sentence: suggest replacing "to generate tone signals again" with "to regenerate the tones from the named events". In the second sentence, add "their peer" in front of "Internet end systems". Section 3.2 "Events and audio" bullet: missing "source" before "sends". Last sentence of section 3.2: suggest replacing "in general should not interfere" by "are unlikely to interfere". Section 3.3, compliance (immediately after the bullets). First point: I'd suggest a subheading at this point: "3.3.1 Implementation considerations". First para after bullets: to make things easier for the reader, add indication that Table 2 is in section 3.10. To make it even easier, indicate that these are all DTMF events. Suggested phrasing: "A compliant implementation MUST support the DTMF events listed in Table 2 (section 3.10)." I don't mention the "Flash" exception because I don't think "Flash" belongs in section 3.10/Table 2. (Further discussion below.) Third para after bullets: change "render all tones in Table 6 the same ..." to "render all the country-specific line events in Table 6 (section 3.13) using the same tone ...". Final para before 3.4: move up to immediately follow the bullets, particularly if the suggestion to add sub-heading 3.3.1 is accepted. As a further improvement, add a final para to the main 3.3 (before the 3.3.1 sub-heading), defining state transition events and describing the meaning of the "State?" column in the tables. The text for this latter should be moved here from section 3.4, "Duration", where people can easily miss it. Here's a suggestion: "Certain events represent transitions into particular states. They are indicated by the presence of "Yes" values in the column headed "State?" in the event tables 2 through 6. Notes to the tables indicate which states are mutually exclusive (that is, which states are terminated when a given state is reported). Notes may also indicate other state-related restrictions on what events can be reported." You can keep your current state number idea instead, but I personally feel that notes put the restrictions across more straightforwardly. Section 3.4, "Timestamp": the statement "The receiver calculates jitter for RTCP receiver reports based on all packets with a given timestamp." is presumably a note for information rather than normative text. Hence it seems appropriate to put "Note: " in front of this statement. The sentence following this one seems to be completely off topic and could be omitted. Section 3.4, "Duration": as suggested above, move the general description of state transition events to 3.3. Thus the second para becomes: "The special duration value of zero is reserved to indicate that the event lasts "forever", i.e., is a state and is considered to be effective until updated. Only events marked with a "Yes" in the "state?" column in the tables below are allowed to use a duration value of zero. Other named events with such a duration SHOULD be ignored." Soft-state: should we indicate any action for the receiver? I see two possibilities: - the receiver SHOULD consider the state "unknown" once it has expired without refresh, or - the receiver MAY assume persistence of the state even if it has not been refreshed within the specified duration. Section 3.4, E bit: the third para is mostly redundant. Why not just say: "For named RTP events labeled "state" in Tables 2 through 6, sending of a packet with the "E" bit set is OPTIONAL." I think the paragraphs following this one, beginning with "Receiver implementations MAY use different algorithms ..." and ending just before the R-bit description, might logically constitute a new subsection: "3.4.1 Use of payload data to generate tones". This section would follow the R-bit description. Within those paras, para beginning "Alternatively, ...": rephrase slightly to make clear the three stopping conditions for a tone: "Alternatively, the receiver can start a tone and play it until - it receives a packet with the "E" bit set, or - it receives the next tone, indicated by a new timestamp value, or - a given amount of time passes. This is more robust ..." Final para of that set, beginning "If a receiver has extended a tone ...": I suggest changing "when" to "if" and "that event" to "the same event instance". Thus the sentence would read (with some additional words at the end): "If a receiver has extended a tone by the maximum extension duration and started playing silence, it MUST NOT resume playing the tone if later packets arrive for the same event instance, as this would cause spurious events to be detected downstream." Section 3.6, second para, last line has garbled punctuation -- or is it just that "in order to" begins a new sentence and a capital is needed? If I understand that quotation from Q.24 (can't bring it up at the moment to check it), the part about "signalling velocity" means that the minimum interval from the start of one tone signal to the start of the next should be 93 ms. Perhaps this is how it should be stated? More from tomorrow's campsite. Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Aug 18 13:06:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26076 for ; Mon, 18 Aug 2003 13:06:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onSN-0004nG-4s for avt-archive@odin.ietf.org; Mon, 18 Aug 2003 13:06:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IH6BuW018420 for avt-archive@odin.ietf.org; Mon, 18 Aug 2003 13:06:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onSE-0004mo-CC; Mon, 18 Aug 2003 13:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19onRR-0004kE-SD for avt@optimus.ietf.org; Mon, 18 Aug 2003 13:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26050 for ; Mon, 18 Aug 2003 13:05:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19onRQ-0000wH-00 for avt@ietf.org; Mon, 18 Aug 2003 13:05:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19onRO-0000vk-00 for avt@ietf.org; Mon, 18 Aug 2003 13:05:10 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2003 10:12:11 -0700 Received: from cisco.com (sjc-vpn2-473.cisco.com [10.21.113.217]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7IH4btp006289; Mon, 18 Aug 2003 10:04:37 -0700 (PDT) Message-ID: <3F410723.A4C4EB55@cisco.com> Date: Mon, 18 Aug 2003 13:04:35 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: avt@ietf.org, Henning Schulzrinne Subject: Re: [AVT] Working group last call: draft-ietf-avt-rfc2833bis-03.txt References: <043832C5-CBDF-11D7-B8F1-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greetings. Please find review comments for 2833bis-03 below (some more nit-picking than others). Section 2, 7th and 8th paragraph, Section 3.2 first half. - The discussion in Section 2 about what representation to send seems to ignore any negotiation that may have taken place. It is also somewhat contrary to the first part of Section 3.2, which says that the source is free to choose any of the four approaches. I think a bigger issue here is that the document does not have an offer/answer section. Section 3, 4th paragraph - Last sentence says "RFC 2198 [4] is used to". Either something is missing here or this should be deleted. Section 3.2, first list item (Events and audio) - It is not clear to me whether redundancy encoding (RFC 2198) is used here or not and it should probably be spelled out. Section 3.2, first item in list OLD: PCMU or the codec NEW: PCMU or another codec ^^^^^^^^ Section 3.3, second paragraph - Text currently says "MUST support the events listed in Table 2 with the exception of flash". We discussed this for 2833 in the past, and agreed that (in practice) only the events you actually declare support for are supported (there was an implementation note to that effect at http://www.cs.columbia.edu/~hgs/rtp/payload.html in the past, but this URL no longer works). In other words, you don't necessarily have to support all DTMF tones to support RFC2833bis. Section 3.3, second last paragraph: - There is no normative language in this section, but nevertheless, it would probably be worthwhile clarifying that this has no bearing on implementations (in fact, I don't agree completely with the statements in this paragraph and would consider removing it). Section 3.5, duration field bullet - Text says "all but the last event have the maximum duration expressible in the duration field". Should then explain what the last event actually has in this field. Section 3.5, E field bullet, second paragraph: - Text says "until retransmitting the last packet for a tone". There should either be a forward reference to Section 3.6 to explain what "retransmit" means (since it's not just a single packet retransmission, but rather a resend of the event with a new sequence number or use of 2198) or it should be explained here. Section 3.5, E field bullet, third paragraph: - Text says "the appearance of a different named event implies the end of the previous state". That's not entirely accurate; only if the new event belongs to the same "state class" as the old state will the state be changed (e.g. receipt of a DTMF digit does not end the off-hook state). Section 3.5, E field bullet, second last paragraph: - Text says "A slight extension of tone durations and shortening of pauses is generally harmless". "Generally" is the keyword here, as there are cases where it is not harmless and implementations need to do their absolute best to maintain the original timing - this may be worth pointing out. Section 3.6, 4th paragraph: - Text says "If an event has ended and there bas been no new event in the last interval, the event with final duration SHOULD be sent a total of three times at the interval used by the source for the updates". When subevents had been sent, the duration will not really be the "final duration". Also, let's say a new event occurs after I sent the final event two times; do I still send the old event a third time ? Section 3.6, 4th paragraph, last sentence: - Text says "The last update is also repeated at the end of subevents, as there is no other way to detect the duration of the event". Does this also apply if a new event happens right after the end of the subevent ? Either way, it's probably worth clarifying. Section 3.9: - There should be offer/answer considerations here (probably a separate sub-section). In particular, how the "fmtp" parameter is processed should be discussed (e.g. seems reasonable that, within the context of offer/answer, it is actually negotiated). Also, for sendonly or sendrecv streams, it seems reasonable the events can not only be received, but also sent. Section 3.10, second paragraph: - Text says "The Flash event must only be sent when the state is off hook". What does "state" refer to here (e.g. do we have to have an off-hook state signaled via the 2833bis off-hook event in order to use this) ? Also, "must" should probably be "MUST". Section 3.11, /ANSam event, third paragraph - Let's say we send ANS, get a phase reversal, and then send /ANS. The text is not entirely clear on what happens from here. If the expected phase reversals continue to occur, I believe we continue sending the /ANS which should probably be stated. Also, in that case, is it still one and the same event, and hence the timestamp continues unchanged ? If I don't get the expected phase reversal, do I then send ANS again ? Clarification on these points would be good. Section 3.11, V8bis signals - I know little about V8bis and could easily be wrong here, but some of the V8bis signals look suspicious to me, so unless somebody that knows about this has reviewed it, I'd be concerned. It seems that only a subset of the V8bis signals are included and that you would need more to implement some of the V8bis state transitions (see e.g. Figure 11 in V8.bis). Also, based on a cursory look at V8bis, the definition of CRDi does not seem correct (if I understand correctly, CRDi would not be issued in response to CRe; CRDr would). Tones affected by this comment are: CRDi, CRDr, CRe, ESi, ESr, MRdi, MRdr, MRe. Section 3.11, CI: - Text says "To fully express the call indicator, it would be followed by a call function octet, composed of individual V.21 bit events". It's unclear if the expectation here is to include the stop and start bit as well (producing 10 bits) or whether only the call function octet itself is expected to be sent, in which case the start and stop bits will have to be generated by the receiver if the tone is to be sent out. Section 3.11, Table 3: - For the "V.25, echo canceller disable" row, it's not clear whether the "ANS, /ANS, ANS, /ANS" indication refers to the ITU-T spec or the 2833bis. I assume it's the former, since the representation in 2833bis would rather be "ANS, /ANS........" (I believe). If so, this should probably be clarified. Section 3.12, 3.13, and 5: - The example in Section 5 surprised me a little inasmuch as it included silence as part of the tone. Thinking further about this, it leads to a more general question about how some of the "tones" in Section 3.12 and 3.13 (and maybe others, e.g. seems similar to the /ANS, /ANSam question), which are actually not just tones, but tone patterns, are represented and rendered. In the case of ringing, is each "event" a single ring, a single ring-cycle, or does it continue ? What about trailing silence in a tone pattern in general ? For example, confirmation tone as defined in GR-506-CORE ends with a steady application of tone off, so when does it end ? I think we need more description of these issues in general in the definition of these kinds of tones. Section 3.13: - At a minimum, we need to have references for the tones in this section (and preferably some text too). Right now these event numbers could be anything. Section 3.14, ABCD transitional and Trunk Unavailable - Text says "At the time of a transition, the same ABCD information is sent 3 times at an interval of 5 ms". Seems a bit strange to me that the general retransmission strategy is not being used here. What is the reasoning behind this ? A similar comment applies to the "Trunk unavailable" event. Section 3.14, Continuity Tones: - Both the 1780 and the 2010 can be either sent or received (depending on the switch configuration at either end). Section 3.14: - I have asked another person to review this section as well, so there may be additional comments here. Section 4.3: - May be worth describing how the Marker bit is used. Section 7, and References - Reference to RFC 1889 and RFC 1890 should be replaced with RFC 3550 and RFC 3551. Normative References: - [3]: Latest version of V.8 is 11/00 - [9]: Latest version of T.30 is 07/03 - [11]: Latest version of V.8bis is 11/00 - [16]: Latest version of Q.440 is 11/88 (not 11/98) - [17]: Latest version of Q.140 is 11/88 (not 11/98) - [18]: Latest version of Q.151 is 11/88 (not 11/98) - [19]: Latest version of I.366.2 is 11/00 - [20]: Latest version of Q.400 is 11/88 (not 11/98) - [21]: Latest version of Q.411 is 11/88 (not 11/98) - [22]: Latest version of Q.421 is 11/88 (not 11/98) - [24]: Latest version of E.180 is 03/98. Also delete "Recommendation Supplement 2 to" from the text. In addition to the above, I have some strictly editorial comments which I will send separately to just the author. -- Flemming Colin Perkins wrote: > On Monday, Jul 28, 2003, at 02:15 Europe/London, Colin Perkins wrote: > > This is to announce a working group last call on the RTP Payload for > > DTMF > > Digits, Telephony Tones and Signals . > > Please send any final comments on this draft to the mailing list by > > 11th > > August 2003. If no substantive technical issues are raised, we intend > > to > > submit this draft for publication as a proposed standard RFC to > > obsolete > > RFC 2833. > > > > Note that this draft will not be advanced until we receive at least one > > valid review from someone not directly involved with production of the > > draft (i.e., not an author or contributor). > > This is to solicit reviews of the draft-ietf-avt-rfc2833bis-03.txt. As > noted above, we will not advance the draft until at least one valid > technical review, from someone not directly involved with the > production of the draft, is received. > > -- > Colin Perkins > http://csperkins.org/ > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Aug 19 15:26:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03064 for ; Tue, 19 Aug 2003 15:26:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pC71-0005vI-41 for avt-archive@odin.ietf.org; Tue, 19 Aug 2003 15:25:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JJPlV8022749 for avt-archive@odin.ietf.org; Tue, 19 Aug 2003 15:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pC6H-0005sD-CN; Tue, 19 Aug 2003 15:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pC5a-0005qd-D6 for avt@optimus.ietf.org; Tue, 19 Aug 2003 15:24:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02931 for ; Tue, 19 Aug 2003 15:24:14 -0400 (EDT) From: t-nomura@ccm.cl.nec.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pC5Z-0006DO-00 for avt@ietf.org; Tue, 19 Aug 2003 15:24:17 -0400 Received: from dhcp-99-33.tulane.edu ([129.81.99.33] helo=ADA) by ietf-mx with esmtp (Exim 4.12) id 19pC5X-0006CP-00 for avt@ietf.org; Tue, 19 Aug 2003 15:24:15 -0400 To: Date: Tue, 19 Aug 2003 14:27:59 --0500 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00B120C5" Message-Id: Subject: [AVT] Re: Approved Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00B120C5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00B120C5 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00B120C5-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Aug 19 16:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06206 for ; Tue, 19 Aug 2003 16:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCi2-0007zO-Hh for avt-archive@odin.ietf.org; Tue, 19 Aug 2003 16:04:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JK426o030694 for avt-archive@odin.ietf.org; Tue, 19 Aug 2003 16:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCi1-0007yM-Er; Tue, 19 Aug 2003 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCh6-0007wn-7R for avt@optimus.ietf.org; Tue, 19 Aug 2003 16:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06126 for ; Tue, 19 Aug 2003 16:02:59 -0400 (EDT) From: schirlin@us.ibm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCh4-00079e-00 for avt@ietf.org; Tue, 19 Aug 2003 16:03:02 -0400 Received: from yktgi01e0-s3.watson.ibm.com ([129.34.20.17] helo=DIMA) by ietf-mx with esmtp (Exim 4.12) id 19pCh2-000792-00 for avt@ietf.org; Tue, 19 Aug 2003 16:03:00 -0400 To: Date: Tue, 19 Aug 2003 16:03:00 --0400 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0668C7F6" Message-Id: Subject: [AVT] Re: Details Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0668C7F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0668C7F6 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0668C7F6-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 20 08:16:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05948 for ; Wed, 20 Aug 2003 08:16:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pRso-0001SA-QL for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 08:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KCGAAP005587 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 08:16:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pRsf-0001RO-FB; Wed, 20 Aug 2003 08:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pRrw-0001QX-1U for avt@optimus.ietf.org; Wed, 20 Aug 2003 08:15:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05888 for ; Wed, 20 Aug 2003 08:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pRru-00006D-00 for avt@ietf.org; Wed, 20 Aug 2003 08:15:14 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19pRru-00005r-00 for avt@ietf.org; Wed, 20 Aug 2003 08:15:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36714.6FC0AE72" Date: Wed, 20 Aug 2003 15:13:16 +0300 Message-ID: Thread-Topic: RTP/RTCP Simulator Thread-Index: AcNnFMTrKRF2s8dAEdeSeADQt7+w2w== From: "Oren Peleg" To: Subject: [AVT] RTP/RTCP Simulator Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C36714.6FC0AE72 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi all, I am searching for an RTP/RTCP simulator for RTP/RTCP protocol testing. = Should include advance RTP/RTCP control capabilities (E.g. working with = Padding, extensions, etc.). Can anyone recommend on such a product? Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------_=_NextPart_001_01C36714.6FC0AE72 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RTP/RTCP Simulator

Hi all,

I am searching for an = RTP/RTCP simulator for RTP/RTCP protocol testing. Should include advance = RTP/RTCP control capabilities (E.g. working with Padding, extensions, = etc.). Can anyone recommend on such a product?

Thanks,

Oren Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email : Oren.Peleg@audiocodes.com

------_=_NextPart_001_01C36714.6FC0AE72-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 20 08:35:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06480 for ; Wed, 20 Aug 2003 08:35:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pSB7-0002BG-6F for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 08:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KCZ5mR008376 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 08:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pSB4-0002AF-HV; Wed, 20 Aug 2003 08:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pSAB-000219-TI for avt@optimus.ietf.org; Wed, 20 Aug 2003 08:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06406 for ; Wed, 20 Aug 2003 08:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pSAA-0000Fl-00 for avt@ietf.org; Wed, 20 Aug 2003 08:34:06 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19pSA9-0000Fi-00 for avt@ietf.org; Wed, 20 Aug 2003 08:34:05 -0400 Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Aug 2003 14:34:01 +0200 From: "Jose Rey" To: "Colin Perkins" Cc: Subject: RE: [AVT] 3GPP timed text draft: more generic? Date: Wed, 20 Aug 2003 14:34:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: X-Message-Flag: Follow up X-OriginalArrivalTime: 20 Aug 2003 12:34:01.0172 (UTC) FILETIME=[556E8140:01C36717] 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 Colin, all, > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, August 11, 2003 12:03 PM > To: Jose Rey > Cc: avt@ietf.org > Subject: Re: [AVT] 3GPP timed text draft: more generic? > > > On Monday, Aug 11, 2003, at 09:15 Europe/London, Jose Rey wrote: > > Colin Perkins wrote: > >> A specific payload format for 3GPP timed text might be > >> appropriate, but I > >> would like to understand the options and alternatives before > >> we make that > >> choice. Is 3GPP the only body doing timed and/or decorated > >> text? If not, > >> what are the alternatives, and how do they relate? > >> > >> -- > > > > at the moment there are at least two more standardisation bodies > > interested in timed text: MPEG and W3C. > > > > - MPEG is currently defining their own TT format based on > 3GPP TT (see > > Committee Draft of ISO/IEC 14496-17 from July'03 Meeting in > Trondheim) > > by defining the access unit structure, the stream type, the > object type > > indication and decoder specific info of the timed text samples. The > > definition of these items enables the transport over RTP using the > > mpeg4simple draft. The work in MPEG is assumed to be > finalised around > > July 2004. > > > > - W3C is at a very early stage in defining a timed text authoring > > format. It has recently (May'03) published a draft for use > cases and > > requirements of a timed text authoring format: > > http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030515/. This > draft has a > > rather long list of requirements and lists many > functionalities. In my > > understanding W3C targets to a generic format with rich > functionality. > > I > > don't know how quick it may develop (anyone?). > > I believe SMPTE may also have timed text work in their Digital Cinema > group? > Yes, there is a DC28.2W Subtitles and Captions Adhoc Group in SMPTE dealing with a stream timed text format. I've checked the website and as far as I understand from the available documents they intend to develop a media format to stream text encoded as MNG (Multi-image Network Graphics) images. On April'02 they were still working on a requirements document for the stream text format but no output has been published until today, at least publicly. Question to the group: is anyone aware of the progress of this item? thanks, Jose > > None of these above is an option for us, because 1) the > only timed text > > format in 3GPP is 3GPP timed text 2) 3GPP has not adopted the > > mpeg4simple for > > transport and 3) for this 3GPP timed text format we need an > RTP payload > > format within the current 3GPP Release 6 schedule (i.e. March'04). > > I agree that using the MPEG4-simple format doesn't make > sense, and that > the W3C schedule looks to be too long for 3GPP requirements. > > -- > 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 Aug 20 10:00:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09415 for ; Wed, 20 Aug 2003 10:00:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pTVR-0005qU-Iq for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 10:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KE09lp022471 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 10:00:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pTVK-0005pW-4v; Wed, 20 Aug 2003 10:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pTUv-0005of-UK for avt@optimus.ietf.org; Wed, 20 Aug 2003 09:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09354 for ; Wed, 20 Aug 2003 09:59:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pTUt-00017E-00 for avt@ietf.org; Wed, 20 Aug 2003 09:59:35 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19pTUt-000176-00 for avt@ietf.org; Wed, 20 Aug 2003 09:59:35 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id AE68130200B8; Wed, 20 Aug 2003 09:58:00 -0400 Reply-To: From: "Alan Clark" To: "'Oren Peleg'" , Subject: RE: [AVT] RTP/RTCP Simulator Date: Wed, 20 Aug 2003 09:46:57 -0400 Message-ID: <003f01c36721$86996f50$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C366FF.FF8955F0" 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.1106 Importance: Normal In-Reply-To: Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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_0040_01C366FF.FF8955F0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit RTP/RTCP SimulatorOren We have software for both RTP/ RTCP generation and analysis, RTCP XR generation and parsing and also for trace file generation and analysis. Regards Alan Clark Telchemy -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Oren Peleg Sent: Wednesday, August 20, 2003 8:13 AM To: avt@ietf.org Subject: [AVT] RTP/RTCP Simulator Hi all, I am searching for an RTP/RTCP simulator for RTP/RTCP protocol testing. Should include advance RTP/RTCP control capabilities (E.g. working with Padding, extensions, etc.). Can anyone recommend on such a product? Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------=_NextPart_000_0040_01C366FF.FF8955F0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RTP/RTCP Simulator
Oren
 
We = have software=20 for both RTP/ RTCP generation and analysis, RTCP XR generation and = parsing and=20 also for trace file generation and analysis. 
 
Regards
 
Alan=20 Clark
Telchemy
 
 
-----Original Message-----
From: avt-admin@ietf.org=20 [mailto:avt-admin@ietf.org]On Behalf Of Oren = Peleg
Sent:=20 Wednesday, August 20, 2003 8:13 AM
To: = avt@ietf.org
Subject:=20 [AVT] RTP/RTCP Simulator

Hi all,

I am searching for an RTP/RTCP = simulator for=20 RTP/RTCP protocol testing. Should include advance RTP/RTCP control = capabilities=20 (E.g. working with Padding, extensions, etc.). Can anyone recommend on = such a=20 product?

Thanks,

Oren=20 Peleg

Work=20 phone No. : 03 - 5394167

Home=20 phone No. : 03 - 5335913

Cell=20 phone No. : 055 - 669613

Email :=20 Oren.Peleg@audiocodes.com

------=_NextPart_000_0040_01C366FF.FF8955F0-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 20 11:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14941 for ; Wed, 20 Aug 2003 11:34:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUyP-0001Z3-VX for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 11:34:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFY9I5006009 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 11:34:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUyH-0001Xu-PK; Wed, 20 Aug 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pSoe-00045m-Dp for avt@optimus.ietf.org; Wed, 20 Aug 2003 09:15:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07677 for ; Wed, 20 Aug 2003 09:15:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pSoc-0000dn-00 for avt@ietf.org; Wed, 20 Aug 2003 09:15:54 -0400 Received: from [209.172.119.195] (helo=node24.neomagic.com) by ietf-mx with esmtp (Exim 4.12) id 19pSoc-0000df-00 for avt@ietf.org; Wed, 20 Aug 2003 09:15:54 -0400 Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h7KDFNhV007481 for ; Wed, 20 Aug 2003 06:15:23 -0700 Received: from neomagic.com ([192.168.31.225]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h7KDFJVQ022600; Wed, 20 Aug 2003 06:15:20 -0700 Message-ID: <3F442392.4010503@neomagic.com> Date: Wed, 20 Aug 2003 18:42:42 -0700 From: Avinash Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org CC: Vivek Mudgil Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] RTCP timestamp units Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I am facing an issue in inter-stream (audio-video) synchronization between two RTP streams. The NTP-RTP timestamp correlation comes in the RTCP packets, but the RFC does not specify the units in which the NTP is to be specified. This causes a problem in calculating the audio-video synchronization. As far as I understand, the Synchronization is not possible unless the unit of the NTP is known exactly, which can only be known after the second RTCP packet arrives (from which you can indirectly judje the NTP granularity and hence it's unit). Are there any known solutions to this problem ? Thanks Avinash _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 20 12:12:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17555 for ; Wed, 20 Aug 2003 12:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVZ5-00056o-3t for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 12:12:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KGC3MH019604 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 12:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVZ2-00055S-Pm; Wed, 20 Aug 2003 12:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVYJ-00053z-Rh for avt@optimus.ietf.org; Wed, 20 Aug 2003 12:11:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17497 for ; Wed, 20 Aug 2003 12:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVYI-0002zL-00 for avt@ietf.org; Wed, 20 Aug 2003 12:11:14 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19pVYH-0002yq-00 for avt@ietf.org; Wed, 20 Aug 2003 12:11:14 -0400 Received: from bisa ([130.209.247.104]:54743 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19pVXn-0007Y2-00; Wed, 20 Aug 2003 17:10:43 +0100 Date: Wed, 20 Aug 2003 17:10:38 +0100 Subject: Re: [AVT] RTCP timestamp units Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: avt@ietf.org, Vivek Mudgil To: Avinash Bhatia From: Colin Perkins In-Reply-To: <3F442392.4010503@neomagic.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, Aug 21, 2003, at 02:42 Europe/London, Avinash Bhatia wrote: > I am facing an issue in inter-stream (audio-video) synchronization > between two RTP streams. The NTP-RTP timestamp correlation comes in > the RTCP packets, but the RFC does not specify the units in which the > NTP is to be specified. This causes a problem in calculating the > audio-video synchronization. > As far as I understand, the Synchronization is not possible unless > the unit of the NTP is known exactly, which can only be known after > the second RTCP packet arrives (from which you can indirectly judje > the NTP granularity and hence it's unit). Are there any known > solutions to this problem ? RTP makes no guarantee of the accuracy or resolution of the clock the sender is using to generate the timestamp. However, the format of the timestamp is precisely specified in Section 4 of RFC 3550 (the upper 32 bits are seconds, the lower 32 bits fractions of a second, since 1 January 1900). -- 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 Aug 20 13:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22755 for ; Wed, 20 Aug 2003 13:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWuN-0000T0-RC for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 13:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KHc7xv001783 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 13:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWuG-0000S8-Rn; Wed, 20 Aug 2003 13:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWtf-0000FJ-6V for avt@optimus.ietf.org; Wed, 20 Aug 2003 13:37:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22455 for ; Wed, 20 Aug 2003 13:37:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWtc-0004Gk-00 for avt@ietf.org; Wed, 20 Aug 2003 13:37:20 -0400 Received: from foxtrot.nab.org ([209.116.240.194]) by ietf-mx with esmtp (Exim 4.12) id 19pWtc-0004Gg-00 for avt@ietf.org; Wed, 20 Aug 2003 13:37:20 -0400 Received: from mail.nab.org by [209.116.240.194] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 20 Aug 2003 13:37:20 -0400 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEB837@mail.NAB.ORG> From: "Allison, Art" To: "'Colin Perkins'" , Avinash Bhatia Cc: avt@ietf.org, Vivek Mudgil Subject: RE: [AVT] RTCP timestamp units Date: Wed, 20 Aug 2003 13:37:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Colin By saying (no guarantee of ... resolution) it seems you are saying that the RFC does not actually require all 32 bits to be incremented. If so one can chose how many bits to send with real values, and zero fill the rest. Is that correct? I would think that the resolution would be the precision of the number, and the value of the lsb would establish absolutely the resolution (but it may be offset by an unknown amount from real time which offset could vary - i.e. no accuracy). Art ::{) Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Wednesday, August 20, 2003 12:11 PM To: Avinash Bhatia Cc: avt@ietf.org; Vivek Mudgil Subject: Re: [AVT] RTCP timestamp units On Thursday, Aug 21, 2003, at 02:42 Europe/London, Avinash Bhatia wrote: > I am facing an issue in inter-stream (audio-video) synchronization > between two RTP streams. The NTP-RTP timestamp correlation comes in > the RTCP packets, but the RFC does not specify the units in which the > NTP is to be specified. This causes a problem in calculating the > audio-video synchronization. > As far as I understand, the Synchronization is not possible unless > the unit of the NTP is known exactly, which can only be known after > the second RTCP packet arrives (from which you can indirectly judje > the NTP granularity and hence it's unit). Are there any known > solutions to this problem ? RTP makes no guarantee of the accuracy or resolution of the clock the sender is using to generate the timestamp. However, the format of the timestamp is precisely specified in Section 4 of RFC 3550 (the upper 32 bits are seconds, the lower 32 bits fractions of a second, since 1 January 1900). -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 20 14:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26832 for ; Wed, 20 Aug 2003 14:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXX2-000347-B7 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 14:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KII4LU011772 for avt-archive@odin.ietf.org; Wed, 20 Aug 2003 14:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXX1-00032C-0p; Wed, 20 Aug 2003 14:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pXWy-00031V-EC for avt@optimus.ietf.org; Wed, 20 Aug 2003 14:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26802 for ; Wed, 20 Aug 2003 14:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pXWv-0004sy-00 for avt@ietf.org; Wed, 20 Aug 2003 14:17:57 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19pXWv-0004sV-00 for avt@ietf.org; Wed, 20 Aug 2003 14:17:57 -0400 Received: from bisa ([130.209.247.104]:55242 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19pXWR-0008Ky-00; Wed, 20 Aug 2003 19:17:27 +0100 Date: Wed, 20 Aug 2003 19:17:21 +0100 Subject: Re: [AVT] RTCP timestamp units Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Avinash Bhatia , avt@ietf.org, Vivek Mudgil To: "Allison, Art" From: Colin Perkins In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEB837@mail.NAB.ORG> Message-Id: <8A42914A-D33A-11D7-9694-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Art, On Wednesday, Aug 20, 2003, at 18:37 Europe/London, Allison, Art wrote: > By saying (no guarantee of ... resolution) it seems you are saying > that the > RFC does not actually require all 32 bits to be incremented. If so one > can > chose how many bits to send with real values, and zero fill the rest. > Is that correct? That's one possible implementation choice for generating the NTP-format timestamp in RTCP SR packets, yes. However, all 32 bits of the RTP timestamp MUST be incremented. > I would think that the resolution would be the precision of the > number, and > the value of the lsb would establish absolutely the resolution (but it > may > be offset by an unknown amount from real time which offset could vary > - i.e. > no accuracy). The sender may not know the resolution of its clock, and hence the LSBs of the NTP format timestamp may be garbage. I expect this will make it difficult to infer the characteristics of the clock from the timestamp values. Of course, if RTP is used in a controlled environment, it may be possible to mandate that senders use a clock with tightly-specified characteristics in that environment. -- 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 Thu Aug 21 03:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20364 for ; Thu, 21 Aug 2003 03:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pjZG-0007jO-4N for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 03:09:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7L79A2R029688 for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 03:09:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pjZ7-0007dP-EA; Thu, 21 Aug 2003 03:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pjYc-0007cR-SL for avt@optimus.ietf.org; Thu, 21 Aug 2003 03:08:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20332 for ; Thu, 21 Aug 2003 03:08:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pjYY-000786-00 for avt@ietf.org; Thu, 21 Aug 2003 03:08:26 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19pjYY-000783-00 for avt@ietf.org; Thu, 21 Aug 2003 03:08:26 -0400 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h7L78QJA025891 for ; Thu, 21 Aug 2003 03:08:27 -0400 Message-ID: <01fe01c367b2$ed8ac4c0$441c550a@cisco.com> From: "Paul E. Jones" To: Date: Thu, 21 Aug 2003 03:07:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] On draft-hellstrom-avt-rfc2793bis-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I wanted to call your attention to draft-hellstrom-avt-rfc2793bis-00.txt, which was just made available as an Internet Draft. There are a number of enhancements, primarily focused on allowing text and audio transmitted between two trunking gateways to be switched via a payload type. Other minor modifications were made, including the recommendation of using 3 levels of redundancy to reduce the probability of losing any transmitted text and language to improve how packets get (re)transmitted. The document also proposes the registration of an audio/t140 MIME type for the benefit of GWs that will be transmitting received audio and text to another device over IP. I would like to see this accepted as a work item for the AVT working group. ITU-T SG16 is working to produce a standard for transport of PSTN textphone signals over an IP network between two trunking gateways. This work will be vitally important for the completion of that standard, which they hope to approve in January 2004. (Yes, it's an aggressive schedule.) Already, I've received a comment suggesting that fmtp should be used to allow a device to specify a "character per second" transmission rate. I'll revise the next revision accordingly, but I'd certainly like to hear any other comments on this draft. Thanks! Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 21 03:48:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21414 for ; Thu, 21 Aug 2003 03:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pkAw-00014O-9O for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 03:48:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7L7m6Cw004098 for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 03:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pkAr-00012B-En; Thu, 21 Aug 2003 03:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19phEH-0007W9-Fj for avt@optimus.ietf.org; Thu, 21 Aug 2003 00:39:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01599 for ; Thu, 21 Aug 2003 00:39:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19phEE-00058d-00 for avt@ietf.org; Thu, 21 Aug 2003 00:39:18 -0400 Received: from [209.172.119.195] (helo=node24.neomagic.com) by ietf-mx with esmtp (Exim 4.12) id 19phEE-00058B-00 for avt@ietf.org; Thu, 21 Aug 2003 00:39:18 -0400 Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h7L4clhV028207; Wed, 20 Aug 2003 21:38:47 -0700 Received: from neomagic.com ([192.168.31.254]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h7L4cbVQ013371; Wed, 20 Aug 2003 21:38:39 -0700 Message-ID: <3F445094.7060303@neomagic.com> Date: Thu, 21 Aug 2003 10:24:44 +0530 From: Vivek Mudgil Reply-To: vmudgil@neomagic.com Organization: NeoMagic 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: Colin Perkins CC: "Allison, Art" , Avinash Bhatia , avt@ietf.org Subject: Re: [AVT] RTCP timestamp units References: <8A42914A-D33A-11D7-9694-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Section 4 of RFC 3550 clearly specifies that for RTP purposes, only differences between pairs of NTP timestamps are used. This implies that for inter-media synchronisation, the receiver should have received at least 2 RTCP SR reports. Which in turn imply that inter-media synchronisation in playback is only possible after a minimum of 5 sec (min RTCP Interval). Is this implication right or am I missing something? Even if first NTP timestamp is used for synchronisation,, assuming that the NTP time stamp is provided as specified in Section 4, how will a receiver synchronise the two media till the first SR report is received? Colin Perkins wrote: > Art, > > On Wednesday, Aug 20, 2003, at 18:37 Europe/London, Allison, Art wrote: > >> By saying (no guarantee of ... resolution) it seems you are saying >> that the >> RFC does not actually require all 32 bits to be incremented. If so one >> can >> chose how many bits to send with real values, and zero fill the rest. >> Is that correct? > > > That's one possible implementation choice for generating the NTP-format > timestamp in RTCP SR packets, yes. However, all 32 bits of the RTP > timestamp MUST be incremented. > >> I would think that the resolution would be the precision of the >> number, and >> the value of the lsb would establish absolutely the resolution (but it >> may >> be offset by an unknown amount from real time which offset could vary >> - i.e. >> no accuracy). > > > The sender may not know the resolution of its clock, and hence the LSBs > of the NTP format timestamp may be garbage. I expect this will make it > difficult to infer the characteristics of the clock from the timestamp > values. > > Of course, if RTP is used in a controlled environment, it may be > possible to mandate that senders use a clock with tightly-specified > characteristics in that environment. > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 21 04:34:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21415 for ; Thu, 21 Aug 2003 03:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pkAw-00014Q-9g for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 03:48:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7L7m6q5004099 for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 03:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pkAs-00012J-5E; Thu, 21 Aug 2003 03:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19phap-0008TN-Nt for avt@optimus.ietf.org; Thu, 21 Aug 2003 01:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02841 for ; Thu, 21 Aug 2003 01:02:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pham-0005TI-00 for avt@ietf.org; Thu, 21 Aug 2003 01:02:37 -0400 Received: from [209.172.119.195] (helo=node24.neomagic.com) by ietf-mx with esmtp (Exim 4.12) id 19pham-0005Sz-00 for avt@ietf.org; Thu, 21 Aug 2003 01:02:36 -0400 Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h7L526hV031001; Wed, 20 Aug 2003 22:02:06 -0700 Received: from neomagic.com ([192.168.31.225]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h7L51tVQ015452; Wed, 20 Aug 2003 22:01:57 -0700 Message-ID: <3F45016E.2040605@neomagic.com> Date: Thu, 21 Aug 2003 10:29:18 -0700 From: Avinash Bhatia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vmudgil@neomagic.com CC: Colin Perkins , "Allison, Art" , avt@ietf.org Subject: Re: [AVT] RTCP timestamp units References: <8A42914A-D33A-11D7-9694-000A957FC5F2@csperkins.org> <3F445094.7060303@neomagic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The first query is valid in context of Section 6.3.1 of RFC 1889, but does not hold any more (i.e., since 3550), since the line "It is permissible to use the sampling clock to estimate elapsed wallclock time." has been removed. However, it still says that "A sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero.". In such a case, how is the reciever of multiple streams expected to do inter-stream synchronization ? Vivek Mudgil wrote: > Section 4 of RFC 3550 clearly specifies that for RTP purposes, only > differences between pairs of NTP timestamps are used. This implies that > for inter-media synchronisation, the receiver should have received at > least 2 RTCP SR reports. Which in turn imply that inter-media > synchronisation in playback is only possible after a minimum of 5 sec > (min RTCP Interval). Is this implication right or am I missing something? > > Even if first NTP timestamp is used for synchronisation,, assuming that > the NTP time stamp is provided as specified in Section 4, how will a > receiver synchronise the two media till the first SR report is received? > > Colin Perkins wrote: > >> Art, >> >> On Wednesday, Aug 20, 2003, at 18:37 Europe/London, Allison, Art wrote: >> >>> By saying (no guarantee of ... resolution) it seems you are saying >>> that the >>> RFC does not actually require all 32 bits to be incremented. If so >>> one can >>> chose how many bits to send with real values, and zero fill the rest. >>> Is that correct? >> >> >> >> That's one possible implementation choice for generating the >> NTP-format timestamp in RTCP SR packets, yes. However, all 32 bits of >> the RTP timestamp MUST be incremented. >> >>> I would think that the resolution would be the precision of the >>> number, and >>> the value of the lsb would establish absolutely the resolution (but >>> it may >>> be offset by an unknown amount from real time which offset could >>> vary - i.e. >>> no accuracy). >> >> >> >> The sender may not know the resolution of its clock, and hence the >> LSBs of the NTP format timestamp may be garbage. I expect this will >> make it difficult to infer the characteristics of the clock from the >> timestamp values. >> >> Of course, if RTP is used in a controlled environment, it may be >> possible to mandate that senders use a clock with tightly-specified >> characteristics in that environment. >> > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 21 06:35:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27137 for ; Thu, 21 Aug 2003 06:35:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pmmX-0008L3-Sc for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 06:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LAZ5G0032026 for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 06:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pmmU-0008Jd-1r; Thu, 21 Aug 2003 06:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pmll-0008HD-L4 for avt@optimus.ietf.org; Thu, 21 Aug 2003 06:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27062 for ; Thu, 21 Aug 2003 06:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pmlh-0001IX-00 for avt@ietf.org; Thu, 21 Aug 2003 06:34:13 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19pmlh-0001IE-00 for avt@ietf.org; Thu, 21 Aug 2003 06:34:13 -0400 Received: from bisa ([130.209.247.104]:56900 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19pmlC-0002W0-00; Thu, 21 Aug 2003 11:33:42 +0100 Date: Thu, 21 Aug 2003 11:33:36 +0100 Subject: Re: [AVT] RTCP timestamp units Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Allison, Art" , Avinash Bhatia , avt@ietf.org To: vmudgil@neomagic.com From: Colin Perkins In-Reply-To: <3F445094.7060303@neomagic.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, Aug 21, 2003, at 05:54 Europe/London, Vivek Mudgil wrote: > Section 4 of RFC 3550 clearly specifies that for RTP purposes, only > differences between pairs of NTP timestamps are used. This implies > that > for inter-media synchronisation, the receiver should have received at > least 2 RTCP SR reports. Which in turn imply that inter-media > synchronisation in playback is only possible after a minimum of 5 sec > (min RTCP Interval). Is this implication right or am I missing > something? In order to perform lip-sync you need to receive one RTCP SR packet relating to the audio stream, and one RTCP SR packet relating to the video stream. This pair of NTP-format timestamps, and their corresponding RTP timestamps, is used to align the media. This means there is an initial delay - on average 2.5 seconds duration if you use the default RTCP timing rules - when the receiver does not have the necessary information to perform lip-sync. > Even if first NTP timestamp is used for synchronisation,, assuming that > the NTP time stamp is provided as specified in Section 4, how will a > receiver synchronise the two media till the first SR report is > received? The receiver cannot synchronise media streams until an RTCP SR packet has been received from each stream. -- 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 Thu Aug 21 06:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27306 for ; Thu, 21 Aug 2003 06:39:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pmqM-0000PK-KX for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 06:39:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LAd24X001525 for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 06:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pmqL-0000O0-DV; Thu, 21 Aug 2003 06:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pmpp-0000NV-Gu for avt@optimus.ietf.org; Thu, 21 Aug 2003 06:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27259 for ; Thu, 21 Aug 2003 06:38:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pmpl-0001M3-00 for avt@ietf.org; Thu, 21 Aug 2003 06:38:25 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19pmpk-0001LY-00 for avt@ietf.org; Thu, 21 Aug 2003 06:38:25 -0400 Received: from bisa ([130.209.247.104]:56905 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19pmpH-0002YN-00; Thu, 21 Aug 2003 11:37:55 +0100 Date: Thu, 21 Aug 2003 11:37:50 +0100 Subject: Re: [AVT] RTCP timestamp units Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: vmudgil@neomagic.com, "Allison, Art" , avt@ietf.org To: Avinash Bhatia From: Colin Perkins In-Reply-To: <3F45016E.2040605@neomagic.com> Message-Id: <833650B3-D3C3-11D7-BA7B-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, Aug 21, 2003, at 18:29 Europe/London, Avinash Bhatia wrote: > The first query is valid in context of Section 6.3.1 of RFC 1889, but > does not hold any more (i.e., since 3550), since the line "It is > permissible to use the sampling clock to estimate elapsed wallclock > time." has been removed. > However, it still says that "A sender that has no notion of wallclock > or elapsed time may set the NTP timestamp to zero.". In such a case, > how is the reciever of multiple streams expected to do inter-stream > synchronization ? If the sender sets the NTP timestamp to zero, it is not possible for a receiver to do inter-stream synchronisation. -- 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 Thu Aug 21 14:16:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18710 for ; Thu, 21 Aug 2003 14:16:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptz3-0001tg-MY for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 14:16:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LIGTLM007285 for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 14:16:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptyj-0001mn-LK; Thu, 21 Aug 2003 14:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptwi-0001NK-UU for avt@optimus.ietf.org; Thu, 21 Aug 2003 14:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16011 for ; Thu, 21 Aug 2003 13:35:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ptLN-00067k-00 for avt@ietf.org; Thu, 21 Aug 2003 13:35:29 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19ptLM-00067K-00 for avt@ietf.org; Thu, 21 Aug 2003 13:35:28 -0400 Received: from bisa ([130.209.247.104]:58270 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19ptKr-0006Fy-00; Thu, 21 Aug 2003 18:34:57 +0100 Date: Thu, 21 Aug 2003 18:34:51 +0100 Subject: Re: [AVT] Re: I-D ACTION:draft-jones-avt-audio-t38-00.txt] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Tom Taylor" , To: "Paul E. Jones" From: Colin Perkins In-Reply-To: <01ae01c36141$9cc635f0$0401a8c0@packetizer.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, It seems that this draft needs more motivation and background information in the introduction, to make it clear exactly what is being registered and the scope of applicability for this MIME type. An additional section "Relation to RFC 3362" would also be appropriate, I believe. I also have a number of other comments: - Bibliographic citations are not allowed in the abstract, you should move them into the introduction. - The "Conventions used in this document" section should be a numbered section, after the introduction. - The draft needs copyright and IPR notices adding - The current section 2 can probably be included under the "Encoding Considerations" header of the MIME registration. - Section 3 should be titled "IANA Considerations" - Section 3: The RTP timestamp rate is presumably a required parameter? - The draft needs a brief section explaining how the MIME name and any parameters are mapped onto SDP (e.g. see Section 5.1 of RFC 3557). - Security considerations needs to reference the security considerations of the RTP spec and any applicable profiles, along with any equivalent section in T.38 itself. - References need to be split into Normative and Informative sections. You might also consider reading http://www.ietf.org/ID-nits.html where a lot of these issues are discussed. Cheers, Colin On Wednesday, Aug 13, 2003, at 03:21 Europe/London, Paul E. Jones wrote: > Tom, > > The purpose is to register the MIME type "audio/t38". The reason is > that > work is underway within ITU-T Q14/16 to support the carriage of T.38's > IFP > packets through RTP. This will allow us to then signal a single "m=" > like > that looks like this: > > m=audio 5600 RTP/AVP 18 98 > a=rtpmap:98 t38/8000 > > When two media gateways have negotiated this (or similar) SDP and a > fax tone > is detected on the line side, a mode shift may occur by simply > transmitting > packets with PT=98, rather than PT=18. This reduces the need for > either > consuming additional UDP ports per call for image/t38 or going through > a > lengthy exchange of messages to open a fax channel. > > Paul > > ----- Original Message ----- > From: "Tom Taylor" > To: > Cc: > Sent: Tuesday, August 12, 2003 11:10 AM > Subject: [Fwd: I-D ACTION:draft-jones-avt-audio-t38-00.txt] > > >> What's this all about? First point is that image/t38 is already a > registered MIME >> type. Second point is that T.38 does NOT use RTP transport, in > contradiction to the >> statement in the I-D that it does. >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-jones-avt-audio-t38-00.txt >> Date: Mon, 11 Aug 2003 15:46:16 -0400 >> From: Internet-Drafts@ietf.org >> Reply-To: Internet-Drafts@ietf.org >> To: IETF-Announce: ; >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type >> Registration >> Author(s) : P. Jones >> Filename : draft-jones-avt-audio-t38-00.txt >> Pages : 4 >> Date : 2003-8-11 >> >> This document defines the MIME sub-type audio/t38. The packetization >> and usage of this MIME type, which is intended for use within SDP [2] >> and H.248 [3] systems, is specified within ITU-T Recommendation T.38 >> [1]. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-00.txt >> >> To remove yourself from the IETF Announcement list, send a message to >> ietf-announce-request with the word unsubscribe in the body of the > message. >> >> Internet-Drafts are also available by anonymous FTP. Login with the > username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-jones-avt-audio-t38-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 >> ... >> > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 21 14:17:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18822 for ; Thu, 21 Aug 2003 14:17:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptze-00027Q-GK for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 14:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LIH6s6008117 for avt-archive@odin.ietf.org; Thu, 21 Aug 2003 14:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptzZ-0001y5-NK; Thu, 21 Aug 2003 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ptwn-0001NK-AI for avt@optimus.ietf.org; Thu, 21 Aug 2003 14:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17088 for ; Thu, 21 Aug 2003 13:58:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ptht-0006OZ-00 for avt@ietf.org; Thu, 21 Aug 2003 13:58:45 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19ptht-0006OW-00 for avt@ietf.org; Thu, 21 Aug 2003 13:58:45 -0400 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h7LHwhJA004152; Thu, 21 Aug 2003 13:58:44 -0400 Message-ID: <02ba01c3680d$c57a8370$75aa6b80@cisco.com> From: "Paul E. Jones" To: "Colin Perkins" Cc: "Tom Taylor" , References: Subject: Re: [AVT] Re: I-D ACTION:draft-jones-avt-audio-t38-00.txt] Date: Thu, 21 Aug 2003 13:58:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin, Thanks for the feedback. I will try to incorporate your requests into a new revision of the draft over the next few days. Paul ----- Original Message ----- From: "Colin Perkins" To: "Paul E. Jones" Cc: "Tom Taylor" ; Sent: Thursday, August 21, 2003 1:34 PM Subject: Re: [AVT] Re: I-D ACTION:draft-jones-avt-audio-t38-00.txt] > Hi, > > It seems that this draft needs more motivation and background > information in the introduction, to make it clear exactly what is being > registered and the scope of applicability for this MIME type. An > additional section "Relation to RFC 3362" would also be appropriate, I > believe. > > I also have a number of other comments: > > - Bibliographic citations are not allowed in the abstract, you should > move > them into the introduction. > - The "Conventions used in this document" section should be a numbered > section, after the introduction. > - The draft needs copyright and IPR notices adding > - The current section 2 can probably be included under the "Encoding > Considerations" header of the MIME registration. > - Section 3 should be titled "IANA Considerations" > - Section 3: The RTP timestamp rate is presumably a required parameter? > - The draft needs a brief section explaining how the MIME name and any > parameters are mapped onto SDP (e.g. see Section 5.1 of RFC 3557). > - Security considerations needs to reference the security > considerations > of the RTP spec and any applicable profiles, along with any > equivalent > section in T.38 itself. > - References need to be split into Normative and Informative sections. > > You might also consider reading http://www.ietf.org/ID-nits.html where > a lot of these issues are discussed. > > Cheers, > Colin > > > > > On Wednesday, Aug 13, 2003, at 03:21 Europe/London, Paul E. Jones wrote: > > Tom, > > > > The purpose is to register the MIME type "audio/t38". The reason is > > that > > work is underway within ITU-T Q14/16 to support the carriage of T.38's > > IFP > > packets through RTP. This will allow us to then signal a single "m=" > > like > > that looks like this: > > > > m=audio 5600 RTP/AVP 18 98 > > a=rtpmap:98 t38/8000 > > > > When two media gateways have negotiated this (or similar) SDP and a > > fax tone > > is detected on the line side, a mode shift may occur by simply > > transmitting > > packets with PT=98, rather than PT=18. This reduces the need for > > either > > consuming additional UDP ports per call for image/t38 or going through > > a > > lengthy exchange of messages to open a fax channel. > > > > Paul > > > > ----- Original Message ----- > > From: "Tom Taylor" > > To: > > Cc: > > Sent: Tuesday, August 12, 2003 11:10 AM > > Subject: [Fwd: I-D ACTION:draft-jones-avt-audio-t38-00.txt] > > > > > >> What's this all about? First point is that image/t38 is already a > > registered MIME > >> type. Second point is that T.38 does NOT use RTP transport, in > > contradiction to the > >> statement in the I-D that it does. > >> > >> -------- Original Message -------- > >> Subject: I-D ACTION:draft-jones-avt-audio-t38-00.txt > >> Date: Mon, 11 Aug 2003 15:46:16 -0400 > >> From: Internet-Drafts@ietf.org > >> Reply-To: Internet-Drafts@ietf.org > >> To: IETF-Announce: ; > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> > >> > >> Title : Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type > >> Registration > >> Author(s) : P. Jones > >> Filename : draft-jones-avt-audio-t38-00.txt > >> Pages : 4 > >> Date : 2003-8-11 > >> > >> This document defines the MIME sub-type audio/t38. The packetization > >> and usage of this MIME type, which is intended for use within SDP [2] > >> and H.248 [3] systems, is specified within ITU-T Recommendation T.38 > >> [1]. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-00.txt > >> > >> To remove yourself from the IETF Announcement list, send a message to > >> ietf-announce-request with the word unsubscribe in the body of the > > message. > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the > > username > >> "anonymous" and a password of your e-mail address. After logging in, > >> type "cd internet-drafts" and then > >> "get draft-jones-avt-audio-t38-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 > >> ... > >> > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > > > -- > Colin Perkins > http://csperkins.org/ > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Aug 22 08:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20729 for ; Fri, 22 Aug 2003 08:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qBB8-0008Gu-V6 for avt-archive@odin.ietf.org; Fri, 22 Aug 2003 08:38:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MCc63p031770 for avt-archive@odin.ietf.org; Fri, 22 Aug 2003 08:38:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qBB3-0008Fb-45; Fri, 22 Aug 2003 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qBAR-000889-Tn for avt@optimus.ietf.org; Fri, 22 Aug 2003 08:37:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20660 for ; Fri, 22 Aug 2003 08:37:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qBAQ-0003Hb-00 for avt@ietf.org; Fri, 22 Aug 2003 08:37:22 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19qBAP-0003HF-00 for avt@ietf.org; Fri, 22 Aug 2003 08:37:22 -0400 Received: from bisa ([130.209.247.104]:61238 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19qB9v-0002gj-00; Fri, 22 Aug 2003 13:36:51 +0100 Date: Fri, 22 Aug 2003 13:36:41 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: magnus.westerlund@ericsson.com To: avt@ietf.org From: Colin Perkins Content-Transfer-Encoding: 7bit Message-Id: <484975AB-D49D-11D7-88B7-000A957FC5F2@csperkins.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [AVT] Progressing ULP and UXP Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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 working group has previously agreed that the drafts on Generic FEC with Uneven Level Protection (draft-ietf-avt-ulp-07.txt) and Erasure-Resilient Transmission of Progressive Multimedia Streams (draft-ietf-avt-uxp-05.txt) provide somewhat similar services, but are targeted at different environments or requirements. We proposed that the drafts should advance to the IESG together, with applicability statements showing the differing emphasis of the proposals. Since that time, the ULP draft has broadened in scope to become a proposed replacement for the Parity FEC specification of RFC 2733. The UXP draft remains narrowly targeted, and has been blocked waiting for the completion of the ULP work. Accordingly, due to the increased scope of the ULP draft, we now propose to allow these drafts to advance separately to completion, rather than linking their progress (neither draft is complete at this time). We welcome any comments from the working group on this proposal. Thanks, Colin and Magnus _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Aug 25 04:24:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02296 for ; Mon, 25 Aug 2003 04:24:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rCeH-00049g-HW for avt-archive@odin.ietf.org; Mon, 25 Aug 2003 04:24:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P8OOrX015957 for avt-archive@odin.ietf.org; Mon, 25 Aug 2003 04:24:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rCe3-00047X-C2; Mon, 25 Aug 2003 04:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qHXU-00045j-Tv for avt@optimus.ietf.org; Fri, 22 Aug 2003 15:25:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15288 for ; Fri, 22 Aug 2003 15:25:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qHXT-0000oE-00 for avt@ietf.org; Fri, 22 Aug 2003 15:25:35 -0400 Received: from smtp3.vsnl.net ([203.200.235.233]) by ietf-mx with esmtp (Exim 4.12) id 19qHXS-0000o2-00 for avt@ietf.org; Fri, 22 Aug 2003 15:25:35 -0400 Received: from happy ([172.16.28.233]) by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HK100JS6CMAI7@smtp3.vsnl.net> for avt@ietf.org; Sat, 23 Aug 2003 00:55:25 +0530 (IST) Received: from ([219.65.47.65]) by smtp3.vsnl.net (InterScan E-Mail VirusWall Unix); Sat, 23 Aug 2003 00:55:25 +0530 (IST) Date: Sat, 23 Aug 2003 00:54:51 +0530 From: Deepak Kotian To: avt@ietf.org Reply-to: Deepak Kotian Message-id: <008101c368e3$0f908420$072f41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_6l2VfOZFFFyo0dMCvDRO5A)" X-Priority: 3 X-MSMail-priority: Normal Subject: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ES so that it works with RTSP client like RealOne/QuickTime Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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. --Boundary_(ID_6l2VfOZFFFyo0dMCvDRO5A) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Can I please get a good reference documents for RTP timestamp calculation for MPEG1 Video and Audio ES so that it works with RTSP client like RealOne/QuickTime, Basically, based on RFC 1889 and RFC 2250. Any help on this would be appreciated. Thanks and Regard Deepak --Boundary_(ID_6l2VfOZFFFyo0dMCvDRO5A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
Can I please get a good reference documents for RTP timestamp calculation for MPEG1 Video and Audio ES so that it works with RTSP client like RealOne/QuickTime,
Basically, based on RFC 1889 and RFC 2250.
 
Any help on this would be appreciated.
 
Thanks and Regard
Deepak
 

 

 --Boundary_(ID_6l2VfOZFFFyo0dMCvDRO5A)-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Aug 26 02:34:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19523 for ; Tue, 26 Aug 2003 02:34:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rXOj-0008HX-OW for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 02:33:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7Q6XbCU031784 for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 02:33:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rXOE-0008F5-VO; Tue, 26 Aug 2003 02:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rWey-00064F-PG for avt@optimus.ietf.org; Tue, 26 Aug 2003 01:46:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05559 for ; Tue, 26 Aug 2003 01:46:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rWev-0004Kl-00 for avt@ietf.org; Tue, 26 Aug 2003 01:46:25 -0400 Received: from c2mailgwalt.mailcentro.com ([207.183.238.112]) by ietf-mx with esmtp (Exim 4.12) id 19rWeu-0004KJ-00 for avt@ietf.org; Tue, 26 Aug 2003 01:46:24 -0400 Received: from c2web203 (c0mailgwalt4.prontomail.com [207.183.238.114]) by c2mailgwalt.mailcentro.com (8.12.8/8.12.0-c2mailgw04) with SMTP id h7Q5kOLS031642; Mon, 25 Aug 2003 22:46:27 -0700 X-Version: Mailcentro(english) X-SenderIP: 203.200.24.199 X-SenderID: 8114614 From: "Neo Anderson" Message-Id: Date: Tue, 26 Aug 2003 11:14:13 +0530 X-Priority: Normal Content-Type: text/html To: dkotian3@vsnl.net Reply-To: Neo@wiseone.zzn.com Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ES so that itworks with RTSP client like RealOne/QuickTime CC: avt@ietf.org X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by Mailcentro using amavisd-milter wirh reject option 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,

Since you have mentioned the documents yourself, I think they
provide sufficient information for interop with realone. Check out
rfc3550 too.

We need to provide the timestamp with the proper clock rates
mentioned for the specific media type payload format (rfc2250).

For example, if the clock is 90kHz, practically, multiply the
timestamp in seconds by 90000. This is the RTP  timestamp value to be
transmitted in the packet. Check out the clock rates carefully for
each media type and associated payload format is used.

Take care of putting proper NTP and RTP timestamp correlation while
sending SR packets.

There is also an interoperablity statement for RTP/RTSP in the real
networks site. Sorry, I am not able to cite the exact document at
present. try downloading from their website.








--Neo
Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com
__________________
http://www.zzn.com

_______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Aug 26 20:38:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27161 for ; Tue, 26 Aug 2003 20:38:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmYY-0004I1-9h for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 18:44:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QMisAi016484 for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 18:44:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmPK-0003ag-PQ; Tue, 26 Aug 2003 18:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlfI-0001f5-Dq for avt@optimus.ietf.org; Tue, 26 Aug 2003 17:47:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12665 for ; Tue, 26 Aug 2003 17:47:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rlfF-0002ne-00 for avt@ietf.org; Tue, 26 Aug 2003 17:47:45 -0400 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 19rlfE-0002mL-00 for avt@ietf.org; Tue, 26 Aug 2003 17:47:44 -0400 Received: from happy ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HK8000IWXN7FC@smtp2.vsnl.net> for avt@ietf.org; Wed, 27 Aug 2003 03:12:48 +0530 (IST) Received: from ([219.65.47.100]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Wed, 27 Aug 2003 03:12:48 +0530 (IST) Date: Wed, 27 Aug 2003 03:12:35 +0530 From: Deepak Kotian To: avt@ietf.org Reply-to: Deepak Kotian Message-id: <002a01c36c1a$f6d4da40$642f41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_B/F6T02gIujN0dfkvFJ71Q)" X-Priority: 3 X-MSMail-priority: Normal Subject: [AVT] Where can I get ISO/IEC 1172 from Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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. --Boundary_(ID_B/F6T02gIujN0dfkvFJ71Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I want to implement RFC 2250 for MPEG1 Video and Audio ES. Helix( RealOne forum) say that I would need ISO/IEC 1172 for RFC=20 implementation. Where can I get ISO/IEC 1172 from, any inputs on = this one please Here is the extract of the document from real networks *********************** =B7 MPEG-1 Helix Universal Server delivers ISO/IEC 1172 compliant video and system = bit=20 streams over RTSP/RTP. RealOne Player and QuickTime Player, for example, = can play MPEG-1 streams. Helix Universal Server delivers MPEG-1 content=20 with file extensions of mpa, mpg, mpeg, mpv, mps, m2v, m1v, and mpe *********************** Thanks and Regards Deepak ----- Original Message -----=20 From: Deepak Kotian=20 To: Neo@wiseone.zzn.com=20 Cc: avt@ietf.org=20 Sent: Tuesday, August 26, 2003 8:26 PM Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio = ES so that itworks with RTSP client like RealOne/QuickTime Hi, >>There is also an interoperablity statement for >>RTP/RTSP in the = real=20 >>networks site. Sorry, I am not able to cite the >>exact document at=20 >>present. try downloading from their website. Just to add. About this documents, there seems to be no=20 document with the RealOne guys for the timestamp calculation,etc. I = checked with them at the helix forum. Thanks and Regards Deepak ----- Original Message -----=20 From: Deepak Kotian=20 To: Neo@wiseone.zzn.com=20 Cc: avt@ietf.org=20 Sent: Tuesday, August 26, 2003 7:33 PM Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and = Audio ES so that itworks with RTSP client like RealOne/QuickTime Hi, Thanks for the inputs. But, these RFCs do not mention about the PTS or DTS timestamp calculation, it seems the RTP timestamp is derived from PTS or DTS of headers. Which is usually 33 bits, that too is mystery to me as the RTP timestamp is 32 bits.=20 That is what I have heard. Is there a very simple implementation where Minimal RTSP server is implemented and works with RealOne via RTP for both MPEG1 audio=20 and video Elementary stream. The helix source is really very big to understand quickly. Some more inputs would be of great help. Thanks and Regards Deepak ----- Original Message -----=20 From: Neo Anderson=20 To: dkotian3@vsnl.net=20 Cc: avt@ietf.org=20 Sent: Tuesday, August 26, 2003 11:14 AM Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and = Audio ES so that itworks with RTSP client like RealOne/QuickTime Hi, Since you have mentioned the documents yourself, I think they=20 provide sufficient information for interop with realone. Check = out=20 rfc3550 too. We need to provide the timestamp with the proper clock rates=20 mentioned for the specific media type payload format = (rfc2250). For example, if the clock is 90kHz, practically, multiply the=20 timestamp in seconds by 90000. This is the RTP timestamp = value to be=20 transmitted in the packet. Check out the clock rates carefully = for=20 each media type and associated payload format is used. Take care of putting proper NTP and RTP timestamp correlation = while=20 sending SR packets. There is also an interoperablity statement for RTP/RTSP in the = real=20 networks site. Sorry, I am not able to cite the exact document = at=20 present. try downloading from their website. --Neo Get your own Free E-mail at Witch Wisdom = http://www.witchwisdom.com __________________ http://www.zzn.com --Boundary_(ID_B/F6T02gIujN0dfkvFJ71Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
    I want to implement = RFC 2250 for=20 MPEG1 Video and Audio ES.
    Helix( RealOne=20 forum) say that I would need ISO/IEC=20 1172 for RFC
    implementation. = Where can I get=20 ISO/IEC 1172 from, any = inputs on this=20 one please
 
Here is the extract of the document = from real=20 networks
***********************
=B7       MPEG-1
Helix Universal = Server=20 delivers ISO/IEC 1172 compliant video and system bit
streams over = RTSP/RTP.=20 RealOne Player and QuickTime Player, for example,
can play MPEG-1 = streams.=20 Helix Universal Server delivers MPEG-1 content
with file extensions = of mpa,=20 mpg, mpeg, mpv, mps, m2v, m1v, and mpe
***********************
 
Thanks and Regards
Deepak
 
----- Original Message -----
From:=20 Deepak = Kotian=20
Sent: Tuesday, August 26, 2003 = 8:26=20 PM
Subject: Re: [AVT] RTP = timestamp=20 calculation for MPEG1 Video and Audio ES so that itworks with RTSP = client like=20 RealOne/QuickTime

Hi,
 
>>There is=20 also an interoperablity statement for >>RTP/RTSP in the real=20
>>networks site. Sorry, I am not able to cite the = >>exact=20 document at
>>present. try downloading from their=20 website.
 
Just to add.
About this=20 documents, there seems to be no
document with the=20 RealOne guys for the timestamp calculation,etc. I checked with them at = the=20 helix forum.
 
Thanks and=20 Regards
Deepak
 

----- Original Message -----
From:=20 Deepak Kotian=20
Sent: Tuesday, August 26, = 2003 7:33=20 PM
Subject: Re: [AVT] RTP = timestamp=20 calculation for MPEG1 Video and Audio ES so that itworks with RTSP = client=20 like RealOne/QuickTime

Hi,
 
Thanks for the inputs.
But, these RFCs do not mention = about the PTS or=20 DTS timestamp
calculation, it seems the RTP = timestamp is=20 derived from PTS or DTS
of headers. Which is usually 33 = bits, that too=20 is mystery to me as
the RTP timestamp is 32=20 bits. 
That is what I have = heard.
 
Is there a very simple = implementation where=20 Minimal RTSP server
is implemented and works with = RealOne via RTP=20 for both MPEG1 audio
and video Elementary = stream.
The helix source is really very big = to=20 understand quickly.
Some more inputs would be of great=20 help.
 
Thanks and Regards
Deepak
 
 
----- Original Message ----- =
From:=20 Neo=20 Anderson
Sent: Tuesday, August 26, = 2003 11:14=20 AM
Subject: Re: [AVT] RTP = timestamp=20 calculation for MPEG1 Video and Audio ES so that itworks with RTSP = client=20 like RealOne/QuickTime

Hi,

Since you have mentioned the = documents=20 yourself, I think they
provide sufficient information for = interop=20 with realone. Check out
rfc3550 too.

We need to = provide the=20 timestamp with the proper clock rates
mentioned for the = specific=20 media type payload format (rfc2250).

For example, if = the clock=20 is 90kHz, practically, multiply the
timestamp in seconds = by 90000.=20 This is the RTP  timestamp value to be
transmitted in = the=20 packet. Check out the clock rates carefully for
each media = type=20 and associated payload format is used.

Take care of = putting=20 proper NTP and RTP timestamp correlation while
sending SR=20 packets.

There is also an interoperablity statement for = RTP/RTSP in the real
networks site. Sorry, I am not able = to cite=20 the exact document at
present. try downloading from their=20 website.








--Neo
Get your own Free E-mail at = Witch=20 Wisdom=20 = http://www.witchwisdom.com
__________________
http://www.zzn.com

<= /FONT> --Boundary_(ID_B/F6T02gIujN0dfkvFJ71Q)-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 00:50:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20761 for ; Wed, 27 Aug 2003 00:50:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmgM-0004mm-8i for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 18:52:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QMqwVV018355 for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 18:52:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlv8-0002Lo-Uq; Tue, 26 Aug 2003 18:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkPs-0006gK-CM for avt@optimus.ietf.org; Tue, 26 Aug 2003 16:27:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06149 for ; Tue, 26 Aug 2003 16:27:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rkPp-00010T-00 for avt@ietf.org; Tue, 26 Aug 2003 16:27:45 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19rkPo-0000zf-00 for avt@ietf.org; Tue, 26 Aug 2003 16:27:45 -0400 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h7QKQIwr042822; Tue, 26 Aug 2003 13:26:18 -0700 (PDT) (envelope-from casner@acm.org) Date: Tue, 26 Aug 2003 13:27:14 -0700 (PDT) From: Stephen Casner To: Henning Schulzrinne cc: Oren Peleg , avt@ietf.org In-Reply-To: <3F4B5BD6.9040908@cs.columbia.edu> Message-ID: <20030826132131.S16301@ash.packetdesign.com> References: <3F4B5BD6.9040908@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: Question on 4.1 section of RFC3551 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Tue, 26 Aug 2003, Henning Schulzrinne wrote: > For example, in a conference bridge, it would be counterproductive to > send CN packets for all but the active speaker(s). Also, IETF specs > aren't product sales and training manuals - it is not the IETF's job to > tell people that engineering systems without CN is generally a bad idea. > Sending CN is not required for interoperability, so being too > prescriptive doesn't seem helpful here. I agree with Henning's sentiments here. To go further, I would say that the receiver SHOULD be prepared to work well even if CN is not received, because it is always possible that the CN packet may be lost even if it was sent. Many miles were logged on the MBone tools (vat, RAT, NeVoT and friends) with no CN. You may choose to discount these as not be of service grade, but they worked properly without requiring CN. When we have multicast sessions from the IETF meeting with hundreds of participants, we were glad that those hundreds of participants weren't sending CN all the time. Yet at any point that any one of them wanted to say something back to the session, the communication path was ready. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 02:16:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10914 for ; Wed, 27 Aug 2003 02:16:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rqRI-0007HR-NT for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 22:53:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R2rd8f027961 for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 22:53:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmyQ-0005uC-3N; Tue, 26 Aug 2003 19:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rfGj-0005d4-Cj for avt@optimus.ietf.org; Tue, 26 Aug 2003 10:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09920 for ; Tue, 26 Aug 2003 10:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rfGg-00029r-00 for avt@ietf.org; Tue, 26 Aug 2003 10:57:58 -0400 Received: from smtp3.vsnl.net ([203.200.235.233]) by ietf-mx with esmtp (Exim 4.12) id 19rfGf-00029U-00 for avt@ietf.org; Tue, 26 Aug 2003 10:57:57 -0400 Received: from happy ([172.16.28.233]) by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HK8006YTEW7J8@smtp3.vsnl.net> for avt@ietf.org; Tue, 26 Aug 2003 20:27:50 +0530 (IST) Received: from ([219.65.48.163]) by smtp3.vsnl.net (InterScan E-Mail VirusWall Unix); Tue, 26 Aug 2003 20:27:50 +0530 (IST) Date: Tue, 26 Aug 2003 20:26:19 +0530 From: Deepak Kotian Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ES so that itworks with RTSP client like RealOne/QuickTime To: Neo@wiseone.zzn.com Cc: avt@ietf.org Reply-to: Deepak Kotian Message-id: <013a01c36be2$5648d320$132e41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_RupAAvP1cosB7xO7InEKdA)" X-Priority: 3 X-MSMail-priority: Normal Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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. --Boundary_(ID_RupAAvP1cosB7xO7InEKdA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, >>There is also an interoperablity statement for >>RTP/RTSP in the real >>networks site. Sorry, I am not able to cite the >>exact document at >>present. try downloading from their website. Just to add. About this documents, there seems to be no document with the RealOne guys for the timestamp calculation,etc. I checked with them at the helix forum. Thanks and Regards Deepak ----- Original Message ----- From: Deepak Kotian To: Neo@wiseone.zzn.com Cc: avt@ietf.org Sent: Tuesday, August 26, 2003 7:33 PM Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ES so that itworks with RTSP client like RealOne/QuickTime Hi, Thanks for the inputs. But, these RFCs do not mention about the PTS or DTS timestamp calculation, it seems the RTP timestamp is derived from PTS or DTS of headers. Which is usually 33 bits, that too is mystery to me as the RTP timestamp is 32 bits. That is what I have heard. Is there a very simple implementation where Minimal RTSP server is implemented and works with RealOne via RTP for both MPEG1 audio and video Elementary stream. The helix source is really very big to understand quickly. Some more inputs would be of great help. Thanks and Regards Deepak ----- Original Message ----- From: Neo Anderson To: dkotian3@vsnl.net Cc: avt@ietf.org Sent: Tuesday, August 26, 2003 11:14 AM Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ES so that itworks with RTSP client like RealOne/QuickTime Hi, Since you have mentioned the documents yourself, I think they provide sufficient information for interop with realone. Check out rfc3550 too. We need to provide the timestamp with the proper clock rates mentioned for the specific media type payload format (rfc2250). For example, if the clock is 90kHz, practically, multiply the timestamp in seconds by 90000. This is the RTP timestamp value to be transmitted in the packet. Check out the clock rates carefully for each media type and associated payload format is used. Take care of putting proper NTP and RTP timestamp correlation while sending SR packets. There is also an interoperablity statement for RTP/RTSP in the real networks site. Sorry, I am not able to cite the exact document at present. try downloading from their website. --Neo Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com __________________ http://www.zzn.com --Boundary_(ID_RupAAvP1cosB7xO7InEKdA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
>>There is also an interoperablity statement for >>RTP/RTSP in the real
>>networks site. Sorry, I am not able to cite the >>exact document at
>>present. try downloading from their website.
 
Just to add.
About this documents, there seems to be no
document with the RealOne guys for the timestamp calculation,etc. I checked with them at the helix forum.
 
Thanks and Regards
Deepak
 

----- Original Message -----
Sent: Tuesday, August 26, 2003 7:33 PM
Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ES so that itworks with RTSP client like RealOne/QuickTime

Hi,
 
Thanks for the inputs.
But, these RFCs do not mention about the PTS or DTS timestamp
calculation, it seems the RTP timestamp is derived from PTS or DTS
of headers. Which is usually 33 bits, that too is mystery to me as
the RTP timestamp is 32 bits. 
That is what I have heard.
 
Is there a very simple implementation where Minimal RTSP server
is implemented and works with RealOne via RTP for both MPEG1 audio
and video Elementary stream.
The helix source is really very big to understand quickly.
Some more inputs would be of great help.
 
Thanks and Regards
Deepak
 
 
----- Original Message -----
Sent: Tuesday, August 26, 2003 11:14 AM
Subject: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ES so that itworks with RTSP client like RealOne/QuickTime

Hi,

Since you have mentioned the documents yourself, I think they
provide sufficient information for interop with realone. Check out
rfc3550 too.

We need to provide the timestamp with the proper clock rates
mentioned for the specific media type payload format (rfc2250).

For example, if the clock is 90kHz, practically, multiply the
timestamp in seconds by 90000. This is the RTP  timestamp value to be
transmitted in the packet. Check out the clock rates carefully for
each media type and associated payload format is used.

Take care of putting proper NTP and RTP timestamp correlation while
sending SR packets.

There is also an interoperablity statement for RTP/RTSP in the real
networks site. Sorry, I am not able to cite the exact document at
present. try downloading from their website.








--Neo
Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com
__________________
http://www.zzn.com

--Boundary_(ID_RupAAvP1cosB7xO7InEKdA)-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 02:20:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14327 for ; Wed, 27 Aug 2003 02:20:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rrJT-0001mW-Q8 for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 23:49:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R3nc5D006806 for avt-archive@odin.ietf.org; Tue, 26 Aug 2003 23:49:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmp3-0005Ec-Vi; Tue, 26 Aug 2003 19:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rdPr-0002cX-IK for avt@optimus.ietf.org; Tue, 26 Aug 2003 08:59:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02138 for ; Tue, 26 Aug 2003 08:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rdPq-0000PN-00 for avt@ietf.org; Tue, 26 Aug 2003 08:59:18 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19rdPp-0000P4-00 for avt@ietf.org; Tue, 26 Aug 2003 08:59:17 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36BD1.9005E74E" Date: Tue, 26 Aug 2003 15:57:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: Question on 4.1 section of RFC3551 Thread-Index: AcNr0ZBKzZlokNbdEdeSegDQt7+w2w== From: "Oren Peleg" To: , Cc: Subject: [AVT] Question on 4.1 section of RFC3551 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C36BD1.9005E74E Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, At 4.1 section of the RFC3551 it is written: "Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence = insertion descriptor" or "comfort noise" frame to specify parameters for = artificial noise that may be generated during a period of silence to = approximate the background noise at the source. For other payload = formats, a generic Comfort Noise (CN) payload format is specified in RFC = 3389 [9]. When the CN payload format is used with another payload = format, different values in the RTP payload type field distinguish = comfort-noise packets from those of the selected payload format." Shouldnt it be mentioned that a CN packet (of any format) SHOULD be used = on silence detection? There is a reference to "applications which send either no packets or = occasional comfort- noise packets during silence" Since G711 AppendixII = specify CN for G711 (and even recommend using in other coders without = Built-in Silence compression), What kind of application is it that does = not send any packet during Silence? isnt it contradicts the above = section which suggests that the RFC3389 is a valid option for payload = format who does not have CN capabilities? Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------_=_NextPart_001_01C36BD1.9005E74E Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Question on 4.1 section of RFC3551

Hi,

At 4.1 section of the RFC3551 = it is written:

"Some payload formats (see Sections 4.5.3 and = 4.5.6) define a "silence insertion descriptor" or = "comfort noise" frame to specify parameters for artificial = noise that may be generated during a period of silence to approximate = the background noise at the source. For other payload formats, a generic = Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When the = CN payload format is used with another payload format, different values = in the RTP payload type field distinguish comfort-noise packets from = those of the selected payload format."

Shouldnt it be mentioned = that a CN packet (of any format) SHOULD be used on silence = detection?

There is a reference to = "applications which send either no packets or occasional comfort- = noise packets during silence" Since G711 AppendixII specify CN for = G711 (and even recommend using in other coders without Built-in Silence = compression), What kind of application is it that does not send any = packet during Silence? isnt it contradicts the above section which = suggests that the RFC3389 is a valid option for payload format who does = not have CN capabilities?

Thanks,

Oren Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email : Oren.Peleg@audiocodes.com

------_=_NextPart_001_01C36BD1.9005E74E-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 02:45:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27516 for ; Wed, 27 Aug 2003 02:45:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rsZ9-00066C-Hd for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 01:09:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R59so0023424 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 01:09:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmpK-0005GH-4m; Tue, 26 Aug 2003 19:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rdZ4-0002yh-2c for avt@optimus.ietf.org; Tue, 26 Aug 2003 09:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02408 for ; Tue, 26 Aug 2003 09:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rdZ2-0000S6-00 for avt@ietf.org; Tue, 26 Aug 2003 09:08:48 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19rdZ1-0000S3-00 for avt@ietf.org; Tue, 26 Aug 2003 09:08:47 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h7QD8d8I019213; Tue, 26 Aug 2003 09:08:39 -0400 (EDT) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h7QD8cG06336; Tue, 26 Aug 2003 09:08:39 -0400 Message-ID: <3F4B5BD6.9040908@cs.columbia.edu> Date: Tue, 26 Aug 2003 09:08:38 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oren Peleg CC: casner@acm.org, avt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Question on 4.1 section of RFC3551 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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 For example, in a conference bridge, it would be counterproductive to send CN packets for all but the active speaker(s). Also, IETF specs aren't product sales and training manuals - it is not the IETF's job to tell people that engineering systems without CN is generally a bad idea. Sending CN is not required for interoperability, so being too prescriptive doesn't seem helpful here. Oren Peleg wrote: > Hi, > > At 4.1 section of the RFC3551 it is written: > > "Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence > insertion descriptor" or "comfort noise" frame to specify parameters for > artificial noise that may be generated during a period of silence to > approximate the background noise at the source. For other payload > formats, a generic Comfort Noise (CN) payload format is specified in RFC > 3389 [9]. When the CN payload format is used with another payload > format, different values in the RTP payload type field distinguish > comfort-noise packets from those of the selected payload format." > > Shouldnt it be mentioned that a CN packet (of any format) SHOULD be used > on silence detection? > > There is a reference to "applications which send either no packets or > occasional comfort- noise packets during silence" Since G711 AppendixII > specify CN for G711 (and even recommend using in other coders without > Built-in Silence compression), What kind of application is it that does > not send any packet during Silence? isnt it contradicts the above > section which suggests that the RFC3389 is a valid option for payload > format who does not have CN capabilities? > > Thanks, > > Oren Peleg > > Work phone No. : 03 - 5394167 > > Home phone No. : 03 - 5335913 > > Cell phone No. : 055 - 669613 > > Email : Oren.Peleg@audiocodes.com > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 13:49:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21917 for ; Wed, 27 Aug 2003 13:49:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3SS-0002ka-P2 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 12:47:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RGliBA010565 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 12:47:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2w9-0000k1-9y; Wed, 27 Aug 2003 12:14:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19roCo-000131-69 for avt@optimus.ietf.org; Tue, 26 Aug 2003 20:30:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26527 for ; Tue, 26 Aug 2003 20:30:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19roCl-000680-00 for avt@ietf.org; Tue, 26 Aug 2003 20:30:31 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19roCl-00067O-00 for avt@ietf.org; Tue, 26 Aug 2003 20:30:31 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h7R0Tqlx032950 for ; Tue, 26 Aug 2003 17:29:52 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 17:29:52 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A7D7E@misty.packetvideo.com> From: Thomas Zeng To: avt@ietf.org Date: Tue, 26 Aug 2003 17:29:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] Interpreting RFC2327: SDP whitespace problem in "s=" line Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hello All: During recent interop testing, one issue has come up regarding whether it is valid to have "s=[single space]" in an SDP as the subject of a presentation. In section 6 of RFC2327 (see http://www.ietf.org/rfc/rfc2327.txt?number=2327): An SDP session description consists of a number of lines of text of the form = is always exactly one character and is case-significant. is a structured text string whose format depends on . It also will be case-significant unless a specific field defines otherwise. Whitespace is not permitted either side of the `=' sign. In general is either a number of fields delimited by a single space character or a free format string. Taken off context, this paragraph seems to be prohibiting '[space]=' or '=[space]' . However, we don't think the intent was to place restrictions on . If is a free-format string, then it should be able to start with a space. (And this is what the ABNF definition says, for the value in the 's=' case). We checked http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-13.txt as well, which clearly states that if there is no meaningful subject, a single space should be used in "s=" line, yet it apparently has contracdictory statement in section 5. We hereby would like to confirm with this mailing list, that "s=[single space]" is a legal subject line. We would also appreciate clarification in http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-13.txt , section 5, to indicate that: " An SDP session description consists of a number of lines of text of the form: = where MUST be exactly one case-significant character and is structured text whose format depends on . In general is either a number of fields delimited by a single space character, or a free format string. [modified text] Whitespace MUST NOT be used either side of the "=" sign, except if the free format string begins with a space or contains a single space. An exampel is: "s=[single space]", which is a legal SDP line." Thanks in advance for your feedback. thomas PacketVideo Corp. www.pv.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 17:56:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11650 for ; Wed, 27 Aug 2003 17:56:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s42T-0004wE-GF for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 13:24:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RHOvLv018976 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 13:24:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2w3-0000ib-Dx; Wed, 27 Aug 2003 12:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rqcy-0007qO-F1 for avt@optimus.ietf.org; Tue, 26 Aug 2003 23:05:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10592 for ; Tue, 26 Aug 2003 23:05:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rqcu-00020I-00 for avt@ietf.org; Tue, 26 Aug 2003 23:05:40 -0400 Received: from smtp3.vsnl.net ([203.200.235.233]) by ietf-mx with esmtp (Exim 4.12) id 19rqct-0001zl-00 for avt@ietf.org; Tue, 26 Aug 2003 23:05:39 -0400 Received: from happy ([172.16.28.233]) by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HK900JXECJFBI@smtp3.vsnl.net> for avt@ietf.org; Wed, 27 Aug 2003 08:34:32 +0530 (IST) Received: from ([219.65.46.219]) by smtp3.vsnl.net (InterScan E-Mail VirusWall Unix); Wed, 27 Aug 2003 08:34:32 +0530 (IST) Date: Wed, 27 Aug 2003 08:33:54 +0530 From: Deepak Kotian Subject: Re: [AVT] Where can I get ISO/IEC 1172 from To: "Sandy (Alexander) MacInnis" , avt@ietf.org Reply-to: Deepak Kotian Message-id: <001401c36c47$da2f0be0$db2e41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_oxjF1x8snIqivsFUXbmBYw)" X-Priority: 3 X-MSMail-priority: Normal References: <4.3.2.7.2.20030826173350.03c178f0@mailhost.sj.broadcom.com> Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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. --Boundary_(ID_oxjF1x8snIqivsFUXbmBYw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the input. So, basically it is difficult to get it. Can someone in the forum have a handy document for calculation of RTP = timestamp with reference to PTS/DTS for Video and Audio ES. Any help on this would be great. Thanks and Regards Deepak ----- Original Message -----=20 From: Sandy (Alexander) MacInnis=20 To: Deepak Kotian ; avt@ietf.org=20 Sent: Wednesday, August 27, 2003 6:09 AM Subject: Re: [AVT] Where can I get ISO/IEC 1172 from The MPEG-1 standard is ISO/IEC 11172 (not 1172). That looks like a = typo. The systems part is 11172-1, video is 11172-2, and audio is 11172-3. These standards are copyrighted by ISO/IEC, and they are available in = hard copy from the national standards bodies and IEC. There may be some people with bootleg non-final soft copies, but as = far as I know they are not permitted to be distributed due to copyright. --Sandy MacInnis Broadcom (Chair of MPEG-1 Systems and MPEG-2 Systems at the time they were = developed.) At 02:42 PM 8/26/2003, Deepak Kotian wrote: Hi, =20 I want to implement RFC 2250 for MPEG1 Video and Audio ES. Helix( RealOne forum) say that I would need ISO/IEC 1172 for RFC = implementation. Where can I get ISO/IEC 1172 from, any inputs on = this one please =20 Here is the extract of the document from real networks *********************** =B7 MPEG-1 Helix Universal Server delivers ISO/IEC 1172 compliant video and = system bit=20 streams over RTSP/RTP. RealOne Player and QuickTime Player, for = example,=20 can play MPEG-1 streams. Helix Universal Server delivers MPEG-1 = content=20 with file extensions of mpa, mpg, mpeg, mpv, mps, m2v, m1v, and mpe *********************** =20 Thanks and Regards Deepak --Boundary_(ID_oxjF1x8snIqivsFUXbmBYw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the input.
So, basically it is difficult to get=20 it.
Can someone in the forum have a handy = document for=20 calculation of RTP timestamp with reference
to PTS/DTS for Video and Audio = ES.
 
Any help on this would be = great.
 
Thanks and Regards
Deepak
----- Original Message -----
From:=20 Sandy=20 (Alexander) MacInnis
Sent: Wednesday, August 27, = 2003 6:09=20 AM
Subject: Re: [AVT] Where can I = get=20 ISO/IEC 1172 from

The MPEG-1 standard is ISO/IEC 11172 (not 1172). That = looks=20 like a typo.

The systems part is 11172-1, video is 11172-2, and = audio=20 is 11172-3.

These standards are copyrighted by ISO/IEC, and = they are=20 available in hard copy from the national standards bodies and=20 IEC.

There may be some people with bootleg non-final soft = copies, but=20 as far as I know they are not permitted to be distributed due to=20 copyright.

--Sandy MacInnis
Broadcom
(Chair of MPEG-1 = Systems and=20 MPEG-2 Systems at the time they were developed.)

At 02:42 PM = 8/26/2003,=20 Deepak Kotian wrote:
Hi,
 
    I=20 want to implement RFC 2250 for MPEG1 Video and Audio = ES.
    Helix( RealOne forum) say = that I would=20 need ISO/IEC 1172 for = RFC=20
    = implementation. Where=20 can I get ISO/IEC 1172=20 from, any inputs on this one=20 please
 
Here is the = extract of=20 the document from real networks
***********************
=B7    &nb= sp; =20 MPEG-1
Helix Universal Server delivers ISO/IEC 1172 compliant = video and=20 system bit
streams over RTSP/RTP. RealOne Player and QuickTime = Player,=20 for example,
can play MPEG-1 streams. Helix Universal Server = delivers=20 MPEG-1 content
with file extensions of mpa, mpg, mpeg, mpv, mps, = m2v,=20 m1v, and mpe
***********************
 
Thanks and Regards
Deepak
--Boundary_(ID_oxjF1x8snIqivsFUXbmBYw)-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 21:06:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26023 for ; Wed, 27 Aug 2003 21:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s55V-0001Yv-9c for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 14:32:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RIW9Zj005981 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 14:32:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s52I-0001Sv-2b; Wed, 27 Aug 2003 14:28:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s29U-0007OA-Tp for avt@optimus.ietf.org; Wed, 27 Aug 2003 11:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08508 for ; Wed, 27 Aug 2003 11:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s29T-0000sK-00 for avt@ietf.org; Wed, 27 Aug 2003 11:24:03 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19s29S-0000r7-00 for avt@ietf.org; Wed, 27 Aug 2003 11:24:03 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h7RFMwwr071212; Wed, 27 Aug 2003 08:22:59 -0700 (PDT) (envelope-from casner@acm.org) Date: Wed, 27 Aug 2003 08:28:28 -0700 (PDT) From: Stephen Casner To: Oren Peleg cc: Henning Schulzrinne , avt@ietf.org In-Reply-To: Message-ID: <20030827082723.R8152@oak.packetdesign.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] RE: Question on 4.1 section of RFC3551 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Wed, 27 Aug 2003, Oren Peleg wrote: > Yet, if a CN is present you can distinguish between silence or > unknown state of the session connection & you can use a CNG to give > better QoS to the listener. Your point is well taken - Off course > the receiver SHOULD be robust, but still, In a Coder point of view, > (I am not sure this working group is the right address, but still > ..) there is the G711 Appendix II which defines silence > compression. Or should I ask, when stopping the packet sending due > to silence, what is the standard used for doing so? None other than RFC 3551. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 21:49:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29737 for ; Wed, 27 Aug 2003 21:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBE4-0003tx-7i for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 21:05:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S15O3F014991 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 21:05:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4um-0000ws-IM; Wed, 27 Aug 2003 14:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ruqL-0006va-Uh for avt@optimus.ietf.org; Wed, 27 Aug 2003 03:35:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01612 for ; Wed, 27 Aug 2003 03:35:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ruqJ-000038-00 for avt@ietf.org; Wed, 27 Aug 2003 03:35:47 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19ruqJ-00002W-00 for avt@ietf.org; Wed, 27 Aug 2003 03:35:47 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 27 Aug 2003 10:33:40 +0300 Message-ID: Thread-Topic: Question on 4.1 section of RFC3551 Thread-Index: AcNsEDLU92YOj42yR5uE63HArj9aFAAVIEEg From: "Oren Peleg" To: "Stephen Casner" , "Henning Schulzrinne" Cc: Content-Transfer-Encoding: quoted-printable Subject: [AVT] RE: Question on 4.1 section of RFC3551 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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 Yet, if a CN is present you can distinguish between silence or unknown = state of the session connection & you can use a CNG to give better QoS = to the listener. Your point is well taken - Off course the receiver = SHOULD be robust, but still, In a Coder point of view, (I am not sure = this working group is the right address, but still ..) there is the G711 = Appendix II which defines silence compression. Or should I ask, when = stopping the packet sending due to silence, what is the standard used = for doing so? Thanks, Oren P. -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: Tuesday, August 26, 2003 11:27 PM To: Henning Schulzrinne Cc: Oren Peleg; avt@ietf.org Subject: Re: Question on 4.1 section of RFC3551 On Tue, 26 Aug 2003, Henning Schulzrinne wrote: > For example, in a conference bridge, it would be counterproductive to > send CN packets for all but the active speaker(s). Also, IETF specs > aren't product sales and training manuals - it is not the IETF's job = to > tell people that engineering systems without CN is generally a bad = idea. > Sending CN is not required for interoperability, so being too > prescriptive doesn't seem helpful here. I agree with Henning's sentiments here. To go further, I would say that the receiver SHOULD be prepared to work well even if CN is not received, because it is always possible that the CN packet may be lost even if it was sent. Many miles were logged on the MBone tools (vat, RAT, NeVoT and friends) with no CN. You may choose to discount these as not be of service grade, but they worked properly without requiring CN. When we have multicast sessions from the IETF meeting with hundreds of participants, we were glad that those hundreds of participants weren't sending CN all the time. Yet at any point that any one of them wanted to say something back to the session, the communication path was ready. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 22:31:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03383 for ; Wed, 27 Aug 2003 22:31:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sABP-0008W8-TF for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 19:58:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RNwZsj032698 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 19:58:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4oE-0000Dd-Vu; Wed, 27 Aug 2003 14:14:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3aa-0003Ik-IC for avt@optimus.ietf.org; Wed, 27 Aug 2003 12:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17123 for ; Wed, 27 Aug 2003 12:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s3aY-0003BW-00 for avt@ietf.org; Wed, 27 Aug 2003 12:56:06 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19s3aX-0003AE-00 for avt@ietf.org; Wed, 27 Aug 2003 12:56:06 -0400 Received: from bisa ([130.209.247.104]:50392 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19s3a0-000708-00; Wed, 27 Aug 2003 17:55:32 +0100 Date: Wed, 27 Aug 2003 17:55:25 +0100 Subject: Re: [AVT] Interpreting RFC2327: SDP whitespace problem in "s=" line Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: avt@ietf.org To: Thomas Zeng From: Colin Perkins In-Reply-To: <72263E8E8622D611975C0002B32C19D84A7D7E@misty.packetvideo.com> Message-Id: <40F3E13D-D8AF-11D7-BBA2-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, Aug 27, 2003, at 01:29 Europe/London, Thomas Zeng wrote: > Hello All: > > During recent interop testing, one issue has come up regarding whether > it is > valid to have "s=[single space]" in > an SDP as the subject of a presentation. > > In section 6 of RFC2327 (see > http://www.ietf.org/rfc/rfc2327.txt?number=2327): > > An SDP session description consists of a number of lines of text of > the form = is always exactly one character and > is > case-significant. is a structured text string whose format > depends on . It also will be case-significant unless a > specific field defines otherwise. Whitespace is not permitted > either > side of the `=' sign. In general is either a number of > fields > delimited by a single space character or a free format string. > > Taken off context, this paragraph seems to be prohibiting > '[space]=' or > '=[space]' . However, we don't think the intent was to > place > restrictions on . If is a free-format string, then it > should > be able to start with a space. (And this is what the ABNF definition > says, > for the value in the 's=' case). > > We checked > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-13.txt as > well, which clearly states that > if there is no meaningful subject, a single space should be used in > "s=" > line, yet it apparently has contracdictory statement in section 5. > > We hereby would like to confirm with this mailing list, that "s=[single > space]" is a legal subject line. I would consider it to be legal. RFC 3264 (offer/answer) also recommends either a single space or a single dash ("-") character in the s= line. -- 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 Aug 27 23:18:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08282 for ; Wed, 27 Aug 2003 23:18:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8ZV-0003sy-KA for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 18:15:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RMFLpU014930 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 18:15:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4Yc-0007iP-Lh; Wed, 27 Aug 2003 13:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3B1-0001Op-0b for avt@optimus.ietf.org; Wed, 27 Aug 2003 12:29:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13701 for ; Wed, 27 Aug 2003 12:29:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s3Az-00026N-00 for avt@ietf.org; Wed, 27 Aug 2003 12:29:41 -0400 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 19s3Ay-00025g-00 for avt@ietf.org; Wed, 27 Aug 2003 12:29:40 -0400 Received: from happy ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HKA004VBDSHO4@smtp2.vsnl.net> for avt@ietf.org; Wed, 27 Aug 2003 21:59:08 +0530 (IST) Received: from ([219.65.46.64]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Wed, 27 Aug 2003 21:59:08 +0530 (IST) Date: Wed, 27 Aug 2003 21:58:52 +0530 From: Deepak Kotian Subject: Re: Re: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ESsothat itworks with RTSP client like RealOne/QuickTime To: Neo@wiseone.zzn.com, avt@ietf.org Reply-to: Deepak Kotian Message-id: <001101c36cb8$4dc8e6a0$402e41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <10491FEA901861A45AA107A5F36FBC53@neo.wiseone.zzn.com> 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 Thanks for the information. I think, there is no soft copy available for this one. Do you know where I can buy it online please. Could please shell out a formula something like audio for Video ES. The PTS of 33 bits, I meant from docs similar to these. http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-hoffman-rtp-mpeg-encap-01.t xt *****Extract***** These PES packets contain presentation time stamps (PTS). The MPEG2 System standard specifies that the time interval between contiguous PTS's should not be greater than 0.7 seconds. We propose that PTS's should be present in every RTP fixed header. In the MPEG2 System standard the PTS is defined to 33 bits with an accuracy of 90 kHz. However, in this RTP encapsulation we use only the 32 LSB's. Consequently, the PTS would cycle every 13.26 hours. *****Extract***** Also, I have heard that for B picture frame the timestamp needs to reduced as well. Could you elaborate on those lines as well. Thanks very much for the help extended, really appreciated. Some more help would make my life easier. Thanks and Regards Deepak ----- Original Message ----- From: "Neo Anderson" To: ; Sent: Wednesday, August 27, 2003 6:42 PM Subject: Re: Re: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ESsothat itworks with RTSP client like RealOne/QuickTime > >>...Which is usually 33 bits, that too is mystery to me as > >>the RTP timestamp is 32 bits. > > First, I am not able to relate the 33 bits you have mentioned to any > timestamp at all (kindly enlighten with reference)! > and you might have to buy ISO/IEC 11172-2 for reference if u need > to... > > TS calc in a nutshell: > If u are streaming from a stored file: > > Else, some public source decoder will help to get how to extract the > temporal_reference and the picture_rate/frame_rate_code fields from > the MPEG-1 ES. From these two parameters, timestamp can be calculated. > > When u have the encoder running live at the constant frame rate, the > timestamp to be carried MAY be directly given by the encoder or we > can sample the system clock (gettimeofday() etc.) for the RTP > timestamp (which implies PTS will be sent in the RTP packet) at the > instant when the frame is generated. > > For Audio, > If it is constant bitrate (which I presume will be in most cases of > streaming), then you will have to increment the timestamp based on > the samples per frame. RTP timestamp will be the timestamp for the > first audio frame in the RTP packet (it is most likely that multiple > audio frames are carried in the RTP packet). convert this into the > resolution as required by rfc2250 (90kHz). Also check out the RTP FAQ > on this. > Example: > Sampling Rate = Fs Hz > Calculated Samples per frame = x > Timestamp in 90kHz units = ((x/Fs) * 90000) > > For variable bit rate audio, > Calculate the number of samples per frame for each individual audio > frame. Based on the sampling frequency, calculate the timestamp which > is to be sent for each frame and use the timestamp of the first audio > frame in the rtp packet. > > To calculate the number of samples, you will find lot of info on the > web for the MPEG1 audio frame structure and related formula. > http://www.wotsit.org is one of them. Check for mp3 frame format for > audio. > > >>You guys are my last hope on this, the helix guys have redirected me > >>to this forum. > Hopefully now... > > > > --Neo > Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com > __________________ > http://www.zzn.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 23:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11009 for ; Wed, 27 Aug 2003 23:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAb4-0001EZ-SZ for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 20:25:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S0P6BO004732 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 20:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4s9-0000NO-4J; Wed, 27 Aug 2003 14:18:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19roNk-0001e8-QY for avt@optimus.ietf.org; Tue, 26 Aug 2003 20:41:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27445 for ; Tue, 26 Aug 2003 20:41:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19roNi-0006L9-00 for avt@ietf.org; Tue, 26 Aug 2003 20:41:50 -0400 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 19roNh-0006L6-00 for avt@ietf.org; Tue, 26 Aug 2003 20:41:49 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.3)); Tue, 26 Aug 2003 17:41:12 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA14989; Tue, 26 Aug 2003 17:40:37 -0700 (PDT) Received: from PCSJCA-MACINNIS.broadcom.com ( svpn-10-240-253-28.broadcom.com [10.240.253.28]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id h7R0f3ow019784; Tue, 26 Aug 2003 17:41:03 -0700 (PDT) Message-ID: <4.3.2.7.2.20030826173350.03c178f0@mailhost.sj.broadcom.com> X-Sender: macinnis@mailhost.sj.broadcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Aug 2003 17:39:24 -0700 To: "Deepak Kotian" , avt@ietf.org From: "Sandy (Alexander) MacInnis" Subject: Re: [AVT] Where can I get ISO/IEC 1172 from In-Reply-To: <002a01c36c1a$f6d4da40$642f41db@vsnl.net> MIME-Version: 1.0 X-WSS-ID: 135521A21079159-01-01 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The MPEG-1 standard is ISO/IEC 11172 (not 1172). That looks like a typo.

The systems part is 11172-1, video is 11172-2, and audio is=20 11172-3.

These standards are copyrighted by ISO/IEC, and they are available in hard copy from the national standards bodies and IEC.

There may be some people with bootleg non-final soft copies, but as far as I know they are not permitted to be distributed due to=20 copyright.

--Sandy MacInnis
Broadcom
(Chair of MPEG-1 Systems and MPEG-2 Systems at the time they were developed.)

At 02:42 PM 8/26/2003, Deepak Kotian wrote:
Hi,
 
    I want to implement RFC 225= 0 for MPEG1 Video and Audio ES.
    Helix( RealOne forum) say that I would need ISO/IEC 1172 for RFC
    implementation. Where can I get ISO/IEC 1172 from, any inputs on this one please
 
Here is the extract of the document from real networks
***********************
=B7       MPEG-1
Helix Universal Server delivers ISO/IEC 1172 compliant video and system bit
streams over RTSP/RTP. RealOne Player and QuickTime Player, for example,
can play MPEG-1 streams. Helix Universal Server delivers MPEG-1 content
with file extensions of mpa, mpg, mpeg, mpv, mps, m2v, m1v, and mpe
***********************
 
Thanks and Regards
Deepak
_______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Aug 27 23:47:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11250 for ; Wed, 27 Aug 2003 23:47:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sC5d-0007lZ-7o for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 22:00:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S20jO9029847 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 22:00:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8NZ-0003D9-VM; Wed, 27 Aug 2003 18:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5J9-0002Kj-1e for avt@optimus.ietf.org; Wed, 27 Aug 2003 14:46:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25770 for ; Wed, 27 Aug 2003 14:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5J5-0005Oi-00 for avt@ietf.org; Wed, 27 Aug 2003 14:46:11 -0400 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 19s5J4-0005O5-00 for avt@ietf.org; Wed, 27 Aug 2003 14:46:11 -0400 Received: from happy ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HKA00569K3XIO@smtp2.vsnl.net> for avt@ietf.org; Thu, 28 Aug 2003 00:15:37 +0530 (IST) Received: from ([219.65.48.194]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Thu, 28 Aug 2003 00:15:37 +0530 (IST) Date: Thu, 28 Aug 2003 00:14:48 +0530 From: Deepak Kotian Subject: Re: [AVT] Where can I get ISO/IEC 1172 from To: Colin Perkins Cc: "Sandy (Alexander) MacInnis" , avt@ietf.org Reply-to: Deepak Kotian Message-id: <006f01c36ccb$5e6bf480$832f41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <64F8852F-D8B7-11D7-BBA2-000A957FC5F2@csperkins.org> 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 The cost seems to be 44,00 swiss francs, I do not have that much of budget to shell on this right now. Unless there is some other way to get it. I just need a proper RTP timestamp calcualation for MPEG1 audio and Video ES considering various frames and I think someone in the gr= oup should have some handy docuement on it. Can someone share it generously. Thanks and Regards Deepak ----- Original Message ----- =46rom: "Colin Perkins" To: "Deepak Kotian" Cc: "Sandy (Alexander) MacInnis" ; Sent: Wednesday, August 27, 2003 11:23 PM Subject: Re: [AVT] Where can I get ISO/IEC 1172 from I believe you can now buy copies of ISO standards online, available f= or download as PDF files. See http://www.iso.ch/iso/en/prods-services/ISOstore/store.html Colin On Wednesday, Aug 27, 2003, at 04:03 Europe/London, Deepak Kotian wro= te: > Thanks for the input. > So, basically it is difficult to get it. > Can someone in the forum have a handy document for calculation of R= TP > timestamp with reference > to PTS/DTS for Video and Audio ES. > > Any help on this would be great. > > Thanks and Regards > Deepak > > ----- Original Message ----- > From: Sandy (Alexander) MacInnis > To: Deepak Kotian ; avt@ietf.org > Sent: Wednesday, August 27, 2003 6:09 AM > Subject: Re: [AVT] Where can I get ISO/IEC 1172 from > > The MPEG-1 standard is ISO/IEC 11172 (not 1172). That looks like a > typo. > > The systems part is 11172-1, video is 11172-2, and audio is 11172-3= . > > These standards are copyrighted by ISO/IEC, and they are available = in > hard copy from the national standards bodies and IEC. > > There may be some people with bootleg non-final soft copies, but as > far as I know they are not permitted to be distributed due to > copyright. > > --Sandy MacInnis > Broadcom > (Chair of MPEG-1 Systems and MPEG-2 Systems at the time they were > developed.) > > At 02:42 PM 8/26/2003, Deepak Kotian wrote: > > Hi, > > I want to implement RFC 2250 for MPEG1 Video and Audio ES. > Helix( RealOne forum) say that I would need ISO/IEC 1172 for RFC > implementation. Where can I get ISO/IEC 1172 from, any inputs on > this one please > > Here is the extract of the document from real networks > *********************** > =B7 MPEG-1 > Helix Universal Server delivers ISO/IEC 1172 compliant video and > system bit > streams over RTSP/RTP. RealOne Player and QuickTime Player, for > example, > can play MPEG-1 streams. Helix Universal Server delivers MPEG-1 con= tent > with file extensions of mpa, mpg, mpeg, mpv, mps, m2v, m1v, and mpe > *********************** > > Thanks and Regards > Deepak > > -- 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 Thu Aug 28 00:22:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13935 for ; Thu, 28 Aug 2003 00:22:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBgK-00068x-Ov for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 21:34:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1YaiT023605 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 21:34:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6f9-0006Db-2u; Wed, 27 Aug 2003 16:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5am-00036m-1z for avt@optimus.ietf.org; Wed, 27 Aug 2003 15:04:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27451 for ; Wed, 27 Aug 2003 15:04:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5ai-0005s3-00 for avt@ietf.org; Wed, 27 Aug 2003 15:04:24 -0400 Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx with esmtp (Exim 4.12) id 19s5ah-0005ry-00 for avt@ietf.org; Wed, 27 Aug 2003 15:04:23 -0400 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.3)); Wed, 27 Aug 2003 12:00:12 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA26666; Wed, 27 Aug 2003 12:02:35 -0700 (PDT) Received: from PCSJCA-MACINNIS.broadcom.com ( dhcp-10-9-253-57.broadcom.com [10.9.253.57]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id h7RJ30ow028777; Wed, 27 Aug 2003 12:03:01 -0700 (PDT) Message-ID: <4.3.2.7.2.20030827114948.030295c8@mailhost.sj.broadcom.com> X-Sender: macinnis@mailhost.sj.broadcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Aug 2003 12:01:20 -0700 To: "Deepak Kotian" , "Colin Perkins" From: "Sandy (Alexander) MacInnis" Subject: Re: [AVT] Where can I get ISO/IEC 1172 from cc: avt@ietf.org In-Reply-To: <006601c36cc9$fff553c0$832f41db@vsnl.net> References: <64F8852F-D8B7-11D7-BBA2-000A957FC5F2@csperkins.org> MIME-Version: 1.0 X-WSS-ID: 13522031860336-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The MPEG-1 Systems standard doesn't say anything directly about RTP. Fundamentally, it specifies a formal timing model for determining the conformance of bit streams, and this timing model uses time stamps. There are 3 types of time stamps included: - SCR (System Clock Reference) - this is in effect a sample of the stream's (i.e. sender's) time base as it applies to the compressed stream. To the receiver it means, in effect, "When you get this, the time is the value in this SCR". - PTS (Presentation Time Stamp) - indicates the presentation (i.e. display) time of a picture. This is always delayed from the time the compressed data at the start of a picture arrives, since there is a non-negative delay in the compressed data buffer and it takes time to transfer a picture across a finite rate channel. - DTS (Decoding Time Stamp) - indicates the decoding time of a picture, in case it is different from the PTS. This is really to easy conformance testing, decoders don't need to make use of it. DTS != PTS in the case of I and P pictures in streams that may have B pictures, due to the re-ordering delay that is inherent in the use of B pictures. All of these refer to an idealized decoder model called an STD (System Target Decoder); there are significant differences between the STD model and most real decoders. For example, in the STD, pictures are decoded instantaneously, and they are displayed instantaneously (not with raster scan). Those differences are not relevant to an encoder - the requirements of the stream are set by the standard, not by individual decoders. However decoders typically have to make some adjustments to account for the time required to decode pictures, etc. All of the time stamps (SCR, PTS, DTS) are samples of same underlying time base. This is fundamental to the way MPEG Systems works (MPEG-1, MPEG-2 Transport, and MPEG-2 Program streams). --Sandy At 11:35 AM 8/27/2003, Deepak Kotian wrote: >Thanks for the link. >I assume, it will really help for RTP timestamp calculation >for realTime video generated from encoder boards. > >Thanks and Regards >Deepak _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 28 03:33:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11967 for ; Thu, 28 Aug 2003 03:33:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sD5A-0004YB-AZ for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 23:04:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S34JlF017468 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 23:04:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8Hm-0002wa-R4; Wed, 27 Aug 2003 17:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s59g-0001h3-86 for avt@optimus.ietf.org; Wed, 27 Aug 2003 14:36:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24983 for ; Wed, 27 Aug 2003 14:36:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s59d-0005FL-00 for avt@ietf.org; Wed, 27 Aug 2003 14:36:25 -0400 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 19s59c-0005Ev-00 for avt@ietf.org; Wed, 27 Aug 2003 14:36:25 -0400 Received: from happy ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HKA005P4JNLP7@smtp2.vsnl.net> for avt@ietf.org; Thu, 28 Aug 2003 00:05:49 +0530 (IST) Received: from ([219.65.48.194]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Thu, 28 Aug 2003 00:05:49 +0530 (IST) Date: Thu, 28 Aug 2003 00:05:32 +0530 From: Deepak Kotian Subject: Re: [AVT] Where can I get ISO/IEC 1172 from To: Colin Perkins Cc: "Sandy (Alexander) MacInnis" , avt@ietf.org Reply-to: Deepak Kotian Message-id: <006601c36cc9$fff553c0$832f41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <64F8852F-D8B7-11D7-BBA2-000A957FC5F2@csperkins.org> 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 Thanks for the link. I assume, it will really help for RTP timestamp calculation for realTime video generated from encoder boards. Thanks and Regards Deepak ----- Original Message ----- =46rom: "Colin Perkins" To: "Deepak Kotian" Cc: "Sandy (Alexander) MacInnis" ; Sent: Wednesday, August 27, 2003 11:23 PM Subject: Re: [AVT] Where can I get ISO/IEC 1172 from I believe you can now buy copies of ISO standards online, available f= or download as PDF files. See http://www.iso.ch/iso/en/prods-services/ISOstore/store.html Colin On Wednesday, Aug 27, 2003, at 04:03 Europe/London, Deepak Kotian wro= te: > Thanks for the input. > So, basically it is difficult to get it. > Can someone in the forum have a handy document for calculation of R= TP > timestamp with reference > to PTS/DTS for Video and Audio ES. > > Any help on this would be great. > > Thanks and Regards > Deepak > > ----- Original Message ----- > From: Sandy (Alexander) MacInnis > To: Deepak Kotian ; avt@ietf.org > Sent: Wednesday, August 27, 2003 6:09 AM > Subject: Re: [AVT] Where can I get ISO/IEC 1172 from > > The MPEG-1 standard is ISO/IEC 11172 (not 1172). That looks like a > typo. > > The systems part is 11172-1, video is 11172-2, and audio is 11172-3= . > > These standards are copyrighted by ISO/IEC, and they are available = in > hard copy from the national standards bodies and IEC. > > There may be some people with bootleg non-final soft copies, but as > far as I know they are not permitted to be distributed due to > copyright. > > --Sandy MacInnis > Broadcom > (Chair of MPEG-1 Systems and MPEG-2 Systems at the time they were > developed.) > > At 02:42 PM 8/26/2003, Deepak Kotian wrote: > > Hi, > > I want to implement RFC 2250 for MPEG1 Video and Audio ES. > Helix( RealOne forum) say that I would need ISO/IEC 1172 for RFC > implementation. Where can I get ISO/IEC 1172 from, any inputs on > this one please > > Here is the extract of the document from real networks > *********************** > =B7 MPEG-1 > Helix Universal Server delivers ISO/IEC 1172 compliant video and > system bit > streams over RTSP/RTP. RealOne Player and QuickTime Player, for > example, > can play MPEG-1 streams. Helix Universal Server delivers MPEG-1 con= tent > with file extensions of mpa, mpg, mpeg, mpv, mps, m2v, m1v, and mpe > *********************** > > Thanks and Regards > Deepak > > -- 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 Thu Aug 28 04:42:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17716 for ; Thu, 28 Aug 2003 04:42:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDWa-0006ih-2H for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 23:32:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3WeCx025826 for avt-archive@odin.ietf.org; Wed, 27 Aug 2003 23:32:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9Hh-0005nK-Gx; Wed, 27 Aug 2003 19:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4Ux-0007Ps-Hn for avt@optimus.ietf.org; Wed, 27 Aug 2003 13:54:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22219 for ; Wed, 27 Aug 2003 13:54:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s4Uv-0004bD-00 for avt@ietf.org; Wed, 27 Aug 2003 13:54:21 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19s4Uu-0004aN-00 for avt@ietf.org; Wed, 27 Aug 2003 13:54:20 -0400 Received: from bisa ([130.209.247.104]:50859 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19s4UP-0007Oz-00; Wed, 27 Aug 2003 18:53:49 +0100 Date: Wed, 27 Aug 2003 18:53:41 +0100 Subject: Re: [AVT] Where can I get ISO/IEC 1172 from Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Sandy (Alexander) MacInnis" , avt@ietf.org To: Deepak Kotian From: Colin Perkins In-Reply-To: <001401c36c47$da2f0be0$db2e41db@vsnl.net> Message-Id: <64F8852F-D8B7-11D7-BBA2-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I believe you can now buy copies of ISO standards online, available for=20= download as PDF files. See=20 http://www.iso.ch/iso/en/prods-services/ISOstore/store.html Colin On Wednesday, Aug 27, 2003, at 04:03 Europe/London, Deepak Kotian wrote: > Thanks for the input. > So, basically it is difficult to get it. > Can someone in the forum have a handy document for calculation of RTP=20= > timestamp with reference > to PTS/DTS for Video and Audio ES. > =A0 > Any help on this would be great. > =A0 > Thanks and Regards > Deepak > > ----- Original Message ----- > From: Sandy (Alexander) MacInnis > To: Deepak Kotian ; avt@ietf.org > Sent: Wednesday, August 27, 2003 6:09 AM > Subject: Re: [AVT] Where can I get ISO/IEC 1172 from > > The MPEG-1 standard is ISO/IEC 11172 (not 1172). That looks like a=20 > typo. > > The systems part is 11172-1, video is 11172-2, and audio is 11172-3. > > These standards are copyrighted by ISO/IEC, and they are available in=20= > hard copy from the national standards bodies and IEC. > > There may be some people with bootleg non-final soft copies, but as=20 > far as I know they are not permitted to be distributed due to=20 > copyright. > > --Sandy MacInnis > Broadcom > (Chair of MPEG-1 Systems and MPEG-2 Systems at the time they were=20 > developed.) > > At 02:42 PM 8/26/2003, Deepak Kotian wrote: > > Hi, > =A0 > =A0=A0=A0 I want to implement RFC 2250 for MPEG1 Video and Audio ES. > =A0=A0=A0 Helix( RealOne forum) say that I would need ISO/IEC 1172 for = RFC > =A0=A0=A0 implementation. Where can I get ISO/IEC 1172 from, any = inputs on=20 > this one please > =A0 > Here is the extract of the document from real networks > *********************** > =B7=A0=A0=A0=A0=A0=A0 MPEG-1 > Helix Universal Server delivers ISO/IEC 1172 compliant video and=20 > system bit > streams over RTSP/RTP. RealOne Player and QuickTime Player, for=20 > example, > can play MPEG-1 streams. Helix Universal Server delivers MPEG-1 = content > with file extensions of mpa, mpg, mpeg, mpv, mps, m2v, m1v, and mpe > *********************** > =A0 > Thanks and Regards > Deepak > > --=20 Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 28 06:59:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00076 for ; Thu, 28 Aug 2003 06:59:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sHPp-0004xs-Uz for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 03:41:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S7fvnq019042 for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 03:41:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDJR-0005h7-8e; Wed, 27 Aug 2003 23:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9kA-0006xw-9w for avt@optimus.ietf.org; Wed, 27 Aug 2003 19:30:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18558 for ; Wed, 27 Aug 2003 19:30:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9k8-00032U-00 for avt@ietf.org; Wed, 27 Aug 2003 19:30:24 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 19s9k7-00031Z-00 for avt@ietf.org; Wed, 27 Aug 2003 19:30:24 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 27 Aug 2003 16:29:45 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Aug 2003 16:29:43 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Aug 2003 16:29:41 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Aug 2003 16:30:09 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Aug 2003 16:29:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [AVT] Where can I get ISO/IEC 1172 from Date: Wed, 27 Aug 2003 16:29:32 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24603FBFD06@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] Where can I get ISO/IEC 1172 from thread-index: AcNs6Cq3z7g2WdupRdqu8lUX4bnWnAAB1TfA From: "Gary Sullivan" To: "Sandy \(Alexander\) MacInnis" , "Deepak Kotian" , X-OriginalArrivalTime: 27 Aug 2003 23:29:17.0182 (UTC) FILETIME=[087DC9E0:01C36CF3] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36CF3.102CBB52" ------_=_NextPart_001_01C36CF3.102CBB52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fully-legit electronic copies may be purchased from the following link: =20 http://tinyurl.com/lewc=20 =20 (It's not even expensive -- about $31 for either video or systems.)=20 =20 -Gary Sullivan =20 -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Sandy (Alexander) MacInnis Sent: Tuesday, August 26, 2003 5:39 PM To: Deepak Kotian; avt@ietf.org Subject: Re: [AVT] Where can I get ISO/IEC 1172 from The MPEG-1 standard is ISO/IEC 11172 (not 1172). That looks like a typo. The systems part is 11172-1, video is 11172-2, and audio is 11172-3. These standards are copyrighted by ISO/IEC, and they are available in hard copy from the national standards bodies and IEC. There may be some people with bootleg non-final soft copies, but as far as I know they are not permitted to be distributed due to copyright. --Sandy MacInnis Broadcom (Chair of MPEG-1 Systems and MPEG-2 Systems at the time they were developed.) At 02:42 PM 8/26/2003, Deepak Kotian wrote: Hi, =20 I want to implement RFC 2250 for MPEG1 Video and Audio ES. Helix( RealOne forum) say that I would need ISO/IEC 1172 for RFC=20 implementation. Where can I get ISO/IEC 1172 from, any inputs on this one please =20 Here is the extract of the document from real networks *********************** * MPEG-1 Helix Universal Server delivers ISO/IEC 1172 compliant video and system bit=20 streams over RTSP/RTP. RealOne Player and QuickTime Player, for example, can play MPEG-1 streams. Helix Universal Server delivers MPEG-1 content=20 with file extensions of mpa, mpg, mpeg, mpv, mps, m2v, m1v, and mpe *********************** =20 Thanks and Regards Deepak _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt=20 ------_=_NextPart_001_01C36CF3.102CBB52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Fully-legit electronic copies may be purchased from the = following=20 link:
 
http://tinyurl.com/lewc =
 
(It's = not even=20 expensive -- about $31 for either video or = systems.) 
 
-Gary=20 Sullivan
 
-----Original Message-----
From:=20 avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of = Sandy=20 (Alexander) MacInnis
Sent: Tuesday, August 26, 2003 5:39=20 PM
To: Deepak Kotian; avt@ietf.org
Subject: Re: = [AVT]=20 Where can I get ISO/IEC 1172 from

The MPEG-1 = standard is=20 ISO/IEC 11172 (not 1172). That looks like a typo.

The systems = part is=20 11172-1, video is 11172-2, and audio is 11172-3.

These = standards are=20 copyrighted by ISO/IEC, and they are available in hard copy from the = national=20 standards bodies and IEC.

There may be some people with bootleg = non-final soft copies, but as far as I know they are not permitted to = be=20 distributed due to copyright.

--Sandy = MacInnis
Broadcom
(Chair of=20 MPEG-1 Systems and MPEG-2 Systems at the time they were = developed.)

At=20 02:42 PM 8/26/2003, Deepak Kotian wrote:
Hi,
 
    I=20 want to implement RFC 2250 for MPEG1 Video and Audio = ES.
    Helix( RealOne forum) say = that I would=20 need ISO/IEC 1172 for = RFC=20
    = implementation. Where=20 can I get ISO/IEC 1172=20 from, any inputs on this one=20 please
 
Here is the = extract of=20 the document from real networks
***********************
·   &nbs= p;  =20 MPEG-1
Helix Universal Server delivers ISO/IEC 1172 compliant = video and=20 system bit
streams over RTSP/RTP. RealOne Player and QuickTime = Player,=20 for example,
can play MPEG-1 streams. Helix Universal Server = delivers=20 MPEG-1 content
with file extensions of mpa, mpg, mpeg, mpv, mps, = m2v,=20 m1v, and mpe
***********************
 
Thanks and Regards
Deepak
______________________________________= _________=20 Audio/Video Transport Working Group avt@ietf.org=20 https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C36CF3.102CBB52-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 28 09:36:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14118 for ; Thu, 28 Aug 2003 09:36:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKgB-0001E4-9X for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 07:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SBB3lQ004705 for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 07:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sHCL-0004Aj-Ki; Thu, 28 Aug 2003 03:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCuc-0003lu-Mf for avt@optimus.ietf.org; Wed, 27 Aug 2003 22:53:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05869 for ; Wed, 27 Aug 2003 22:53:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCuZ-0007hv-00 for avt@ietf.org; Wed, 27 Aug 2003 22:53:23 -0400 Received: from smtp3.vsnl.net ([203.200.235.233]) by ietf-mx with esmtp (Exim 4.12) id 19sCuY-0007hI-00 for avt@ietf.org; Wed, 27 Aug 2003 22:53:22 -0400 Received: from happy ([172.16.28.233]) by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HKB00L5W6MQKD@smtp3.vsnl.net> for avt@ietf.org; Thu, 28 Aug 2003 08:22:08 +0530 (IST) Received: from ([219.65.47.112]) by smtp3.vsnl.net (InterScan E-Mail VirusWall Unix); Thu, 28 Aug 2003 08:22:08 +0530 (IST) Date: Thu, 28 Aug 2003 08:20:24 +0530 From: Deepak Kotian Subject: Re: [AVT] Where can I get ISO/IEC 1172 from To: "Sandy (Alexander) MacInnis" , Colin Perkins Cc: avt@ietf.org Reply-to: Deepak Kotian Message-id: <001f01c36d0f$4575f040$702f41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <64F8852F-D8B7-11D7-BBA2-000A957FC5F2@csperkins.org> <4.3.2.7.2.20030827114948.030295c8@mailhost.sj.broadcom.com> 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 Thanks for inputs. Just telling you the backgorund. I have an encoder which sends out Video ES and Audio ES, I want to send it out in RTP format to play it on RealOne player. We have supported RTSP Minimal server and RealOne player plays Video with some breaks and latency and 2 sec audio after 1 minute. Do not know the exact reason. So, we are doubting the RTP timestamp calculation which is not clear from the RFC. We have done encapsulation as per RFC 2250. Any suggestions on this List my query/problem in a simpler way. 1. Where do I source the Time to be fed in RTP timestamp field in the RTP header in my case, should it be PTS/DTS/SCR. This is mainly for MPEG1 for Video ES Is there some calculation needed for the same. 2. Also, If the calculation is to be done from MPEG1 headers, the SCR/PTS field seems to of 33 bits, how do we fit it in 32 bit timestamp of RTP. 3. Should the SCR or PTS or DTS be multiplied by 90 and fed in the RTP timestamp. 4. Is there a special way to calculate time for B-Frame for Video ES. Can one over here kindly give their view on these queries. Thanks and Regards Deepak ----- Original Message ----- From: "Sandy (Alexander) MacInnis" To: "Deepak Kotian" ; "Colin Perkins" Cc: Sent: Thursday, August 28, 2003 12:31 AM Subject: Re: [AVT] Where can I get ISO/IEC 1172 from > The MPEG-1 Systems standard doesn't say anything directly about RTP. > > Fundamentally, it specifies a formal timing model for determining the > conformance of bit streams, and this timing model uses time stamps. > > There are 3 types of time stamps included: > > - SCR (System Clock Reference) - this is in effect a sample of the stream's > (i.e. sender's) time base as it applies to the compressed stream. To the > receiver it means, in effect, "When you get this, the time is the value in > this SCR". > > - PTS (Presentation Time Stamp) - indicates the presentation (i.e. display) > time of a picture. This is always delayed from the time the compressed data > at the start of a picture arrives, since there is a non-negative delay in > the compressed data buffer and it takes time to transfer a picture across a > finite rate channel. > > - DTS (Decoding Time Stamp) - indicates the decoding time of a picture, in > case it is different from the PTS. This is really to easy conformance > testing, decoders don't need to make use of it. DTS != PTS in the case of I > and P pictures in streams that may have B pictures, due to the re-ordering > delay that is inherent in the use of B pictures. > > All of these refer to an idealized decoder model called an STD (System > Target Decoder); there are significant differences between the STD model > and most real decoders. For example, in the STD, pictures are decoded > instantaneously, and they are displayed instantaneously (not with raster > scan). Those differences are not relevant to an encoder - the requirements > of the stream are set by the standard, not by individual decoders. However > decoders typically have to make some adjustments to account for the time > required to decode pictures, etc. > > All of the time stamps (SCR, PTS, DTS) are samples of same underlying time > base. This is fundamental to the way MPEG Systems works (MPEG-1, MPEG-2 > Transport, and MPEG-2 Program streams). > > --Sandy > > At 11:35 AM 8/27/2003, Deepak Kotian wrote: > >Thanks for the link. > >I assume, it will really help for RTP timestamp calculation > >for realTime video generated from encoder boards. > > > >Thanks and Regards > >Deepak > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Aug 28 20:20:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03330 for ; Thu, 28 Aug 2003 20:20:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVL6-0000VS-OK for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 18:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SMY0MV001940 for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 18:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSNE-0000Ab-VL; Thu, 28 Aug 2003 15:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPeh-0008Rl-P7 for avt@optimus.ietf.org; Thu, 28 Aug 2003 12:29:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28175 for ; Thu, 28 Aug 2003 12:29:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sPef-0002Jj-00 for avt@ietf.org; Thu, 28 Aug 2003 12:29:49 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19sPee-0002Iu-00 for avt@ietf.org; Thu, 28 Aug 2003 12:29:48 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Thu, 28 Aug 2003 09:29:11 -0700 Date: Thu, 28 Aug 2003 09:29:14 -0700 (PDT) From: Aaron Colwell X-X-Sender: aaron@raven.dev.prognet.com To: Deepak Kotian cc: "Sandy (Alexander) MacInnis" , Colin Perkins , avt@ietf.org Subject: Re: [AVT] Where can I get ISO/IEC 1172 from In-Reply-To: <001f01c36d0f$4575f040$702f41db@vsnl.net> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit comments inline On Thu, 28 Aug 2003, Deepak Kotian wrote: > Thanks for inputs. > Just telling you the backgorund. > I have an encoder which sends out Video ES and Audio ES, I want > to send it out in RTP format to play it on RealOne player. We have > supported RTSP Minimal server and RealOne player plays Video with some > breaks > and latency and 2 sec audio after 1 minute. Do not know the exact reason. > So, we are doubting the RTP timestamp calculation which is not > clear from the RFC. We have done encapsulation as per RFC 2250. > > Any suggestions on this > > > List my query/problem in a simpler way. > > 1. Where do I source the Time to be fed in RTP timestamp field in the > RTP header in my case, should it be PTS/DTS/SCR. This is mainly for > MPEG1 for Video ES > Is there some calculation needed for the same. If you look at the RTP RFCs (RFC 1889 or RFC 3550) you will see that it says "The timestamp reflects the sampling instant of the first octet in the RTP data packet". This statement implies PTS. Later in that section it specifically talks about MPEG. It says "Consecutive RTP packets MAY contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames." This again implies PTS because in the case where B frames are used the PTS timestamps are not monotonically increasing when the frames are transmitted in decode order. > > 2. Also, If the calculation is to be done from MPEG1 headers, the SCR/PTS > field > seems to of 33 bits, how do we fit it in 32 bit timestamp of RTP. Drop the 33rd bit. Doing this will just cause the RTP timestamp to wrap faster than the MPEG timestamp. > > 3. Should the SCR or PTS or DTS be multiplied by 90 and fed in the RTP > timestamp. I'm not 100% sure about this, but I believe that the PTS sample rate is 90kHz. That is the same sample rate that the RTP timestamps should be in for MPEG. You should not need to modify the timestamps in any way other than adding the random offset specified in the RTP spec. > > 4. Is there a special way to calculate time for B-Frame for Video ES. See my answer for 1. Just use the PTS timestamps. Aaron > > > Can one over here kindly give their view on these queries. > > Thanks and Regards > Deepak > > > > > > ----- Original Message ----- > From: "Sandy (Alexander) MacInnis" > To: "Deepak Kotian" ; "Colin Perkins" > Cc: > Sent: Thursday, August 28, 2003 12:31 AM > Subject: Re: [AVT] Where can I get ISO/IEC 1172 from > > > > The MPEG-1 Systems standard doesn't say anything directly about RTP. > > > > Fundamentally, it specifies a formal timing model for determining the > > conformance of bit streams, and this timing model uses time stamps. > > > > There are 3 types of time stamps included: > > > > - SCR (System Clock Reference) - this is in effect a sample of the > stream's > > (i.e. sender's) time base as it applies to the compressed stream. To the > > receiver it means, in effect, "When you get this, the time is the value in > > this SCR". > > > > - PTS (Presentation Time Stamp) - indicates the presentation (i.e. > display) > > time of a picture. This is always delayed from the time the compressed > data > > at the start of a picture arrives, since there is a non-negative delay in > > the compressed data buffer and it takes time to transfer a picture across > a > > finite rate channel. > > > > - DTS (Decoding Time Stamp) - indicates the decoding time of a picture, in > > case it is different from the PTS. This is really to easy conformance > > testing, decoders don't need to make use of it. DTS != PTS in the case of > I > > and P pictures in streams that may have B pictures, due to the re-ordering > > delay that is inherent in the use of B pictures. > > > > All of these refer to an idealized decoder model called an STD (System > > Target Decoder); there are significant differences between the STD model > > and most real decoders. For example, in the STD, pictures are decoded > > instantaneously, and they are displayed instantaneously (not with raster > > scan). Those differences are not relevant to an encoder - the requirements > > of the stream are set by the standard, not by individual decoders. However > > decoders typically have to make some adjustments to account for the time > > required to decode pictures, etc. > > > > All of the time stamps (SCR, PTS, DTS) are samples of same underlying time > > base. This is fundamental to the way MPEG Systems works (MPEG-1, MPEG-2 > > Transport, and MPEG-2 Program streams). > > > > --Sandy > > > > At 11:35 AM 8/27/2003, Deepak Kotian wrote: > > >Thanks for the link. > > >I assume, it will really help for RTP timestamp calculation > > >for realTime video generated from encoder boards. > > > > > >Thanks and Regards > > >Deepak > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Aug 29 00:38:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24705 for ; Fri, 29 Aug 2003 00:38:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWwb-0004ym-7Y for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 20:16:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0GnnW019098 for avt-archive@odin.ietf.org; Thu, 28 Aug 2003 20:16:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSz0-0001v9-Jn; Thu, 28 Aug 2003 16:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sRz7-0007Oq-7E for avt@optimus.ietf.org; Thu, 28 Aug 2003 14:59:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08813 for ; Thu, 28 Aug 2003 14:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sRz4-0004rY-00 for avt@ietf.org; Thu, 28 Aug 2003 14:59:02 -0400 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 19sRz2-0004rH-00 for avt@ietf.org; Thu, 28 Aug 2003 14:59:01 -0400 Received: from happy ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HKC00BS0FAYHY@smtp2.vsnl.net> for avt@ietf.org; Fri, 29 Aug 2003 00:27:23 +0530 (IST) Received: from ([219.65.48.197]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Fri, 29 Aug 2003 00:27:23 +0530 (IST) Date: Fri, 29 Aug 2003 00:24:55 +0530 From: Deepak Kotian Subject: Re: [AVT] Where can I get ISO/IEC 1172 from To: Aaron Colwell Cc: "Sandy (Alexander) MacInnis" , Colin Perkins , avt@ietf.org Reply-to: Deepak Kotian Message-id: <000a01c36d96$20c047a0$c53041db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: 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 Thanks very much for an excellent response. We will check this one out and see how it works for us. 1. Also, the RFC 2250 does not say much about how to clearly encapsulate the MPEG1 Audio ES, frag_offset, frame sync and timestamp for the same. Can one give more details on it. I calculated the as per one of the post, the loading in RealOne seems faster, but there seems to be audio being played for the same. 2. Which RFC/document would be good reference for details of MPEG1 system and audio/video ES header details and how MPEG1 packetization is done,etc. Could one please let me know. Thanks and Regards Deepak ----- Original Message ----- From: "Aaron Colwell" To: "Deepak Kotian" Cc: "Sandy (Alexander) MacInnis" ; "Colin Perkins" ; Sent: Thursday, August 28, 2003 9:59 PM Subject: Re: [AVT] Where can I get ISO/IEC 1172 from > comments inline > > On Thu, 28 Aug 2003, Deepak Kotian wrote: > > > Thanks for inputs. > > Just telling you the backgorund. > > I have an encoder which sends out Video ES and Audio ES, I want > > to send it out in RTP format to play it on RealOne player. We have > > supported RTSP Minimal server and RealOne player plays Video with some > > breaks > > and latency and 2 sec audio after 1 minute. Do not know the exact reason. > > So, we are doubting the RTP timestamp calculation which is not > > clear from the RFC. We have done encapsulation as per RFC 2250. > > > > Any suggestions on this > > > > > > List my query/problem in a simpler way. > > > > 1. Where do I source the Time to be fed in RTP timestamp field in the > > RTP header in my case, should it be PTS/DTS/SCR. This is mainly for > > MPEG1 for Video ES > > Is there some calculation needed for the same. > > If you look at the RTP RFCs (RFC 1889 or RFC 3550) you will see that it > says "The timestamp reflects the sampling instant of the first octet in > the RTP data packet". This statement implies PTS. Later in that section it > specifically talks about MPEG. It says > "Consecutive RTP packets MAY contain timestamps that are not monotonic > if the data is not transmitted in the order it was sampled, as in the > case of MPEG interpolated video frames." > > This again implies PTS because in the case where B frames are used the PTS > timestamps are not monotonically increasing when the frames are > transmitted in decode order. > > > > > 2. Also, If the calculation is to be done from MPEG1 headers, the SCR/PTS > > field > > seems to of 33 bits, how do we fit it in 32 bit timestamp of RTP. > Drop the 33rd bit. Doing this will just cause the RTP timestamp to wrap > faster than the MPEG timestamp. > > > > > 3. Should the SCR or PTS or DTS be multiplied by 90 and fed in the RTP > > timestamp. > I'm not 100% sure about this, but I believe that the PTS sample rate is > 90kHz. That is the same sample rate that the RTP timestamps should be in > for MPEG. You should not need to modify the timestamps in any way other > than adding the random offset specified in the RTP spec. > > > > > 4. Is there a special way to calculate time for B-Frame for Video ES. > See my answer for 1. Just use the PTS timestamps. > > > Aaron > > > > > > > Can one over here kindly give their view on these queries. > > > > Thanks and Regards > > Deepak > > > > > > > > > > > > ----- Original Message ----- > > From: "Sandy (Alexander) MacInnis" > > To: "Deepak Kotian" ; "Colin Perkins" > > Cc: > > Sent: Thursday, August 28, 2003 12:31 AM > > Subject: Re: [AVT] Where can I get ISO/IEC 1172 from > > > > > > > The MPEG-1 Systems standard doesn't say anything directly about RTP. > > > > > > Fundamentally, it specifies a formal timing model for determining the > > > conformance of bit streams, and this timing model uses time stamps. > > > > > > There are 3 types of time stamps included: > > > > > > - SCR (System Clock Reference) - this is in effect a sample of the > > stream's > > > (i.e. sender's) time base as it applies to the compressed stream. To the > > > receiver it means, in effect, "When you get this, the time is the value in > > > this SCR". > > > > > > - PTS (Presentation Time Stamp) - indicates the presentation (i.e. > > display) > > > time of a picture. This is always delayed from the time the compressed > > data > > > at the start of a picture arrives, since there is a non-negative delay in > > > the compressed data buffer and it takes time to transfer a picture across > > a > > > finite rate channel. > > > > > > - DTS (Decoding Time Stamp) - indicates the decoding time of a picture, in > > > case it is different from the PTS. This is really to easy conformance > > > testing, decoders don't need to make use of it. DTS != PTS in the case of > > I > > > and P pictures in streams that may have B pictures, due to the re-ordering > > > delay that is inherent in the use of B pictures. > > > > > > All of these refer to an idealized decoder model called an STD (System > > > Target Decoder); there are significant differences between the STD model > > > and most real decoders. For example, in the STD, pictures are decoded > > > instantaneously, and they are displayed instantaneously (not with raster > > > scan). Those differences are not relevant to an encoder - the requirements > > > of the stream are set by the standard, not by individual decoders. However > > > decoders typically have to make some adjustments to account for the time > > > required to decode pictures, etc. > > > > > > All of the time stamps (SCR, PTS, DTS) are samples of same underlying time > > > base. This is fundamental to the way MPEG Systems works (MPEG-1, MPEG-2 > > > Transport, and MPEG-2 Program streams). > > > > > > --Sandy > > > > > > At 11:35 AM 8/27/2003, Deepak Kotian wrote: > > > >Thanks for the link. > > > >I assume, it will really help for RTP timestamp calculation > > > >for realTime video generated from encoder boards. > > > > > > > >Thanks and Regards > > > >Deepak > > > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Aug 29 21:16:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24754 for ; Fri, 29 Aug 2003 21:16:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19suAv-0005Qj-Fc for avt-archive@odin.ietf.org; Fri, 29 Aug 2003 21:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U15886020830 for avt-archive@odin.ietf.org; Fri, 29 Aug 2003 21:05:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stnb-0004iO-5C; Fri, 29 Aug 2003 20:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19spQU-0001EI-AU for avt@optimus.ietf.org; Fri, 29 Aug 2003 16:00:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00091 for ; Fri, 29 Aug 2003 16:00:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19spQP-0005Zu-00 for avt@ietf.org; Fri, 29 Aug 2003 16:00:49 -0400 Received: from smtp3.vsnl.net ([203.200.235.233]) by ietf-mx with esmtp (Exim 4.12) id 19spQO-0005ZK-00 for avt@ietf.org; Fri, 29 Aug 2003 16:00:49 -0400 Received: from happy ([172.16.28.233]) by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HKE007BNCWYRG@smtp3.vsnl.net> for avt@ietf.org; Sat, 30 Aug 2003 01:30:42 +0530 (IST) Received: from ([219.65.48.182]) by smtp3.vsnl.net (InterScan E-Mail VirusWall Unix); Sat, 30 Aug 2003 01:30:42 +0530 (IST) Date: Sat, 30 Aug 2003 01:28:58 +0530 From: Deepak Kotian Subject: Re: Re: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ESsothat itworks with RTSP client like RealOne/QuickTime To: Neo@wiseone.zzn.com, avt@ietf.org Reply-to: Deepak Kotian Message-id: <002e01c36e68$1e544840$b63041db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <10491FEA901861A45AA107A5F36FBC53@neo.wiseone.zzn.com> 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 About the audio encapsulation part. These are points I am not clear. 1. I am encapsulating the audio frames based on Audio Frame Sync code. I determine the end of the frame if I get a next frame sync code. So, one RTP packet consists of one frame. Is this correct ? 2. About the formula > Sampling Rate = Fs Hz > Calculated Samples per frame = x > Timestamp in 90kHz units = ((x/Fs) * 90000) How do I calculate samples per frame, Could you please stick the extract over here. I tried the http://www.wotsit.org/search.asp?page=5&s=music but it says . If I check mpeghdr.htm file, It says ****** How to calculate frame size Read the BitRate, SampleRate and Padding (as value of one or zero) of the frame header and use the formula: FrameSize = 144 * BitRate / SampleRate + Padding Example: BitRate = 128000, SampleRate=441000, Padding=0 ==> FrameSize=417 bytes ****** But, I am not sure from where 144 has come from. And where does the padding bit come from. Moreever, it seems the decimal value is truncated. Could not find samples per frame calulation. Could one please let elaborate more on this. Now we seem to be OK with video and we just need help on audio. Please let us know Thanks and Regards Deepak ----- Original Message ----- From: "Neo Anderson" To: ; Sent: Wednesday, August 27, 2003 6:42 PM Subject: Re: Re: Re: [AVT] RTP timestamp calculation for MPEG1 Video and Audio ESsothat itworks with RTSP client like RealOne/QuickTime > >>...Which is usually 33 bits, that too is mystery to me as > >>the RTP timestamp is 32 bits. > > First, I am not able to relate the 33 bits you have mentioned to any > timestamp at all (kindly enlighten with reference)! > and you might have to buy ISO/IEC 11172-2 for reference if u need > to... > > TS calc in a nutshell: > If u are streaming from a stored file: > > Else, some public source decoder will help to get how to extract the > temporal_reference and the picture_rate/frame_rate_code fields from > the MPEG-1 ES. From these two parameters, timestamp can be calculated. > > When u have the encoder running live at the constant frame rate, the > timestamp to be carried MAY be directly given by the encoder or we > can sample the system clock (gettimeofday() etc.) for the RTP > timestamp (which implies PTS will be sent in the RTP packet) at the > instant when the frame is generated. > > For Audio, > If it is constant bitrate (which I presume will be in most cases of > streaming), then you will have to increment the timestamp based on > the samples per frame. RTP timestamp will be the timestamp for the > first audio frame in the RTP packet (it is most likely that multiple > audio frames are carried in the RTP packet). convert this into the > resolution as required by rfc2250 (90kHz). Also check out the RTP FAQ > on this. > Example: > Sampling Rate = Fs Hz > Calculated Samples per frame = x > Timestamp in 90kHz units = ((x/Fs) * 90000) > > For variable bit rate audio, > Calculate the number of samples per frame for each individual audio > frame. Based on the sampling frequency, calculate the timestamp which > is to be sent for each frame and use the timestamp of the first audio > frame in the rtp packet. > > To calculate the number of samples, you will find lot of info on the > web for the MPEG1 audio frame structure and related formula. > http://www.wotsit.org is one of them. Check for mp3 frame format for > audio. > > >>You guys are my last hope on this, the helix guys have redirected me > >>to this forum. > Hopefully now... > > > > --Neo > Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com > __________________ > http://www.zzn.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 Sat Aug 30 11:29:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18333 for ; Sat, 30 Aug 2003 11:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t77V-0000a1-0n for avt-archive@odin.ietf.org; Sat, 30 Aug 2003 10:54:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7UEsSSA002223 for avt-archive@odin.ietf.org; Sat, 30 Aug 2003 10:54:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t62J-000659-Im; Sat, 30 Aug 2003 09:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t0Ao-00009X-MF for avt@optimus.ietf.org; Sat, 30 Aug 2003 03:29:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28377 for ; Sat, 30 Aug 2003 03:29:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t0Am-0003WU-00 for avt@ietf.org; Sat, 30 Aug 2003 03:29:24 -0400 Received: from c2mailgwalt.mailcentro.com ([207.183.238.112]) by ietf-mx with esmtp (Exim 4.12) id 19t0Al-0003RA-00 for avt@ietf.org; Sat, 30 Aug 2003 03:29:23 -0400 Received: from c2web204 (c0mailgwalt4.prontomail.com [207.183.238.114]) by c2mailgwalt.mailcentro.com (8.12.8/8.12.0-c2mailgw03) with SMTP id h7U7NtGX022208; Sat, 30 Aug 2003 00:23:55 -0700 X-Version: Mailcentro(english) X-SenderIP: 203.200.24.199 X-SenderID: 8114614 From: "Neo Anderson" Message-Id: <06CBBE487D6DA5C418B073D7F77C0A92@neo.wiseone.zzn.com> Date: Sat, 30 Aug 2003 12:57:03 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: dkotian3@vsnl.net, avt@ietf.org Reply-To: Neo@wiseone.zzn.com Subject: Re: Re: Re: Re: [AVT] RTP timestamp calculation for MPEG1 Video and AudioESsothat itworks with RTSP client like RealOne/QuickTime X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by Mailcentro using amavisd-milter wirh reject option 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 Comments inline: >1. I am encapsulating the audio frames based on Audio Frame Sync >code. > I determine the end of the frame if I get a next frame sync code. > So, one RTP packet consists of one frame. > Is this correct ? In cases when there is no intermediate data between the mpeg frames, this is correct. (For most practical cases this should hold good). Else, the size of the frame has to be calculated using the same formula as in (2). (If you are doing live encoding, are you not able to get the frame length from the encoder itself?) >2. About the formula >> Sampling Rate = Fs Hz >> Calculated Samples per frame = x >> Timestamp in 90kHz units = ((x/Fs) * 90000) >How do I calculate samples per frame, Could you please stick the >extract >over here. I tried the http://www.wotsit.org/search.asp? >page=5&s=music There are some more files. Kindly have a look into them too. (Search for mp3 in wotsit) >but it says . >If I check mpeghdr.htm file, >It says >****** >How to calculate frame size > >Read the BitRate, SampleRate and Padding (as value of one or zero) of the >frame header and use the formula: >FrameSize = 144 * BitRate/ SampleRate + Padding >Example: BitRate = 128000, SampleRate=441000, Padding=0 ==> >FrameSize=417 >bytes ****** >But, I am not sure from where 144 has come from. And where does the >padding >bit come from. Note 1: SampleRate=441000 should be 44100. All the bits come from the MPEG frame header which resides after the sync. You will have to parse the related info from the frame. Another good reading of mpeghdr.htm should solve your problem of parsing the frame header. 144 comes like this: There are 1152 "RAW" samples per frame in layer II & III. After compression, frame length is calculated in slots. One slot is 1 byte long for layer II and layer III. Consider Fs = 44100 and BR=128000 Duration of audio in a frame = 1152/44100 (seconds) Since we get 128000 bits in a second: Number of bits in this duration = ((1152/44100) * 128000) * (1), where 1 is the number of slots or (((1152/44100)*128000)/8) * (1) BYTES, where 1 is the number of slots. The variables here are Fs and BR. The constant field is (1152/8) = 144. Extract from the same url above: "Padding is used to fit the bit rates exactly. For an example: 128k 44.1kHz layer II uses a lot of 418 bytes and some of 417 bytes long frames to get the exact 128k bitrate. For Layer I slot is 32 bits long, for Layer II and Layer III slot is 8 bits long. " Suggests you will have a few frames which are padded and a few which do not, in order to maintain proper bitrate because we end up in a fraction with "0.95" slots left over per frame (0.4 bits i.e. we may insert one padded frame for every 19 frames, say and frame length will be 418)! Try other sampling frequencies and you will not end up with a fractional value. 44100 and 22050 is maintained for some historical reason to do with cd's and tv's... --Neo Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com __________________ http://www.zzn.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Aug 30 13:49:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22694 for ; Sat, 30 Aug 2003 13:49:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t9L7-0006Us-UK for avt-archive@odin.ietf.org; Sat, 30 Aug 2003 13:16:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7UHGfxE024971 for avt-archive@odin.ietf.org; Sat, 30 Aug 2003 13:16:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t8WQ-0004i6-W2; Sat, 30 Aug 2003 12:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t6tj-0008MQ-1s for avt@optimus.ietf.org; Sat, 30 Aug 2003 10:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15769 for ; Sat, 30 Aug 2003 10:40:07 -0400 (EDT) From: dkotian3@vsnl.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t6tg-0006Gn-00 for avt@ietf.org; Sat, 30 Aug 2003 10:40:12 -0400 Received: from webmail2.vsnl.net ([203.197.12.44] helo=bom6.vsnl.net.in) by ietf-mx with esmtp (Exim 4.12) id 19t6tf-0006GN-00 for avt@ietf.org; Sat, 30 Aug 2003 10:40:11 -0400 Received: from webmail2.vsnl.net (webmail2 [203.197.12.44]) by bom6.vsnl.net.in (Postfix) with ESMTP id 2EFE24FEA5; Sat, 30 Aug 2003 20:11:27 -0500 (GMT) Received: (from nobody@localhost) by webmail2.vsnl.net (8.11.7+Sun/8.11.7) id h7V1BQf04608; Sat, 30 Aug 2003 20:11:26 -0500 (GMT) Date: Sat, 30 Aug 2003 20:11:26 -0500 (GMT) Message-Id: <200308310111.h7V1BQf04608@webmail2.vsnl.net> X-Authentication-Warning: webmail2.vsnl.net: nobody set sender to dkotian3@vsnl.net using -f Content-Type: text/plain Content-Disposition: inline MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: neo@wiseone.zzn.com Subject: Re: Re: Re: Re: [AVT] RTP timestamp calculation for MPEG1 Video and AudioESsothat itworks with RTSP client like RealOne/QuickTime X-Mailer: VSNL, Web based email X-Sender-Ip: 203.124.139.195 Cc: avt@ietf.org Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks very much for a excellent response. This is good information. Also observed : We just tried sending the PTS from MPEG1 header as it is in the RTP timestamp field for each MPEG1 packet for audio and it=20 also worked fine and smooth on RealOne. Thanks and Regards Deepak Thanks and Regards Deepak neo@wiseone.zzn.com wrote Comments inline: >1. I am encapsulating the audio frames based on Audio Frame Sync=20 >code. > I determine the end of the frame if I get a next frame sync code. > So, one RTP packet consists of one frame. > Is this correct ? In cases when there is no intermediate data between the mpeg frames,=20 this is correct. (For most practical cases this should hold good). Else, the size of the frame has to be calculated using the same=20 formula as in (2). (If you are doing live encoding, are you not able to get the frame=20 length from the encoder itself?) >2. About the formula >> Sampling Rate =3D Fs Hz >> Calculated Samples per frame =3D x >> Timestamp in 90kHz units =3D ((x/Fs) * 90000) >How do I calculate samples per frame, Could you please stick the=20 >extract >over here. I tried the http://www.wotsit.org/search.asp? >page=3D5&s=3Dmusic There are some more files. Kindly have a look into them too. (Search=20 for mp3 in wotsit) >but it says . >If I check mpeghdr.htm file, >It says >****** >How to calculate frame size > >Read the BitRate, SampleRate and Padding (as value of one or zero)=20 of the >frame header and use the formula: >FrameSize =3D 144 * BitRate/ SampleRate + Padding >Example: BitRate =3D 128000, SampleRate=3D441000, Padding=3D0 =3D=3D> =20 >FrameSize=3D417 >bytes ****** >But, I am not sure from where 144 has come from. And where does the=20 >padding >bit come from. Note 1: SampleRate=3D441000 should be 44100. All the bits come from the MPEG frame header which resides after the=20 sync. You will have to parse the related info from the frame. Another good reading of mpeghdr.htm should solve your problem of=20 parsing the frame header.=20 144 comes like this: There are 1152 "RAW" samples per frame in layer II & III. After compression, frame length is calculated in slots. One slot is 1 byte long for layer II and layer III. Consider Fs =3D 44100 and BR=3D128000 Duration of audio in a frame =3D 1152/44100 (seconds) Since we get 128000 bits in a second: Number of bits in this duration =3D ((1152/44100) * 128000) * (1),=20 where 1 is the number of slots or=20 (((1152/44100)*128000)/8) * (1) BYTES, where 1 is the number of slots. The variables here are Fs and BR. The constant field is (1152/8) =3D=20 144. Extract from the same url above: "Padding is used to fit the bit rates exactly. For an example: 128k=20 44.1kHz layer II uses a lot of 418 bytes and some of 417 bytes long=20 frames to get the exact 128k bitrate. For Layer I slot is 32 bits=20 long, for Layer II and Layer III slot is 8 bits long. " Suggests you will have a few frames which are padded and a few which=20 do not, in order to maintain proper bitrate because we end up in a=20 fraction with "0.95" slots left over per frame (0.4 bits i.e. we may=20 insert one padded frame for every 19 frames, say and frame length=20 will be 418)! Try other sampling frequencies and you will not end up with a=20 fractional value. 44100 and 22050 is maintained for some historical reason to do with=20 cd's and tv's... --Neo Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com __________________ http://www.zzn.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt