From rem-conf Sun Nov 01 05:30:09 1998 From rem-conf-request@es.net Sun Nov 01 05:30:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zZxPQ-0004Vl-00; Sun, 1 Nov 1998 05:19:08 -0800 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zZxPO-0004Vb-00; Sun, 1 Nov 1998 05:19:06 -0800 Received: from tzi.uni-bremen.de (ruin.informatik.uni-bremen.de [134.102.200.36]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id OAA24663; Sun, 1 Nov 1998 14:18:42 +0100 (MET) Message-ID: <363A1B77.2CE0A58B@tzi.uni-bremen.de> Date: Fri, 30 Oct 1998 21:03:03 +0100 From: "Jörg Ott" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Angel Mateo CC: rem-conf@es.net Subject: Re: User control for mbone References: <199810221056.MAA08202@news.rediris.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Angel, I have written an extension to the 3.9-beta release of mrouted that provides a control port through which you can configure -- besides quite a few other things -- which multicast addresses to pass through and from which subnetworks to accept IGMP messages. Based upon this, we have developed a small control infrastructure that allows people to register their desire to subscribe to certain multicast groups at certain times (web based interface that also looks into SAP/SDP announcements and presents a weekly calendar to the user). The motivation is to avoid getting too many feeds a bad quality, but rather only a few in good quality. We are still in the experimental phase but it should be straightforward for you to write a small tool that listens to SAP announcements and feeds the mrouted.ctlport accordingly (we may do this as well as soon as the other stuff is done). If you need further information (or a copy of the software), please let me know. I hope this helps, Joerg From rem-conf Sun Nov 01 12:57:06 1998 From rem-conf-request@es.net Sun Nov 01 12:57:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0za4PH-0000JJ-00; Sun, 1 Nov 1998 12:47:27 -0800 Received: from usr6-dialup33.mix2.atlanta.cw.net (Safe and Sound) [166.55.52.97] by mail1.es.net with smtp (Exim 1.81 #2) id 0za4PE-0000Iz-00; Sun, 1 Nov 1998 12:47:25 -0800 From: Safe & Sound Products To: Message-Id: <419.436100.65754201Lisa_dubonet@mailexcite.com> Subject: Here it is! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 1 Nov 1998 12:47:25 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ///// Supercharge your computer with Desktop Server 98 ///// This ad is being sent in compliance with Senate bill 1618, Title 3, section 301. http://www.senate.gov/~murkowski/commercialemail/s771index.html DESKTOP SERVER 98 IS THE SIMPLEST WAY TO BRING NEW VISITORS TO YOUR WEBSITE & BUSINESS! Now you can stop worrying about losing your ISP so much. Desktop Server 98 completely eliminates all the hassles normally associated with sending bulk email. Desktop Server turns your personal computer into a "REAL" email server so you don't have to use any of your ISP's email resources. Now, it's almost impossible for ISP's to complain, because all the email advertisements are going out through your own computer. Your ISP won't even know you are sending email. For more information put "more info" on the subject line and email me at makemoney01@mailexcite.com Lisa Rae Dubonet Further transmissions to you by the sender of the email may be stopped at no cost to you by sending a reply to this email address with the word 'Remove' in the subject line. From rem-conf Mon Nov 02 06:05:46 1998 From rem-conf-request@es.net Mon Nov 02 06:05:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zaKRF-0000FO-00; Mon, 2 Nov 1998 05:54:33 -0800 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zaKRE-0000FD-00; Mon, 2 Nov 1998 05:54:32 -0800 Received: from fokus.gmd.de (donald [193.175.132.118]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA22894; Mon, 2 Nov 1998 14:51:05 +0100 (MET) Message-Id: <199811021351.OAA22894@mailhub.fokus.gmd.de> X-Mailer: exmh version 1.6.7 5/3/96 To: mmt-liste@tu-dresden.de cc: rem-conf@es.net, mbone@isi.edu Subject: Multimedia Internet Terminal Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Nov 1998 14:51:01 +0100 From: Dorgham Sisalem X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We would like to announce the release of a multimedia conferencing tool for the Internet called MInT (Multimedia Internet Terminal) which was developed in the USMInT Project sponsored by the German research Network (DFN) and in cooperation with the Columbia University MInT is a flexible multimedia tool set that allows the establishment and control of multimedia sessions across the Internet. The system architecture is fully distributed, with no central components. MInT offers the following features: o Audio transmission and reception for qualities ranging from GSM up to CD based on the NeVoT and VAT tools o Video transmission and reception based on VIC o An integrated conference control instance that hides the complexities of the single tools o floor control o voting based on MPoll o interface to SDR o RSVP reservation capabilities for all used applications o Adaptive video transmission o Joint viewing and remote control of postscript documents o Invitation of remote users based on the Session initiation protocol (SIP) with Email resolution capabilities MInT is available for Solaris and Linux For more information and free download please take a look at http://www.fokus.gmd.de/glone/products/mint for any questions or bug reports please contact sisalem@fokus.gmd.de Regards Dorgham Sisalem -- --- Dorgham Sisalem email: sisalem@fokus.gmd.de GMD-Fokus phone: ++49 30 34 63 71 70 Kaiserin-Augusta-Allee 31 fax: ++49 30 34 63 81 70 D-10589 Berlin URL: http://www.fokus.gmd.de/usr/sisalem From rem-conf Mon Nov 02 06:25:22 1998 From rem-conf-request@es.net Mon Nov 02 06:25:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zaKqj-0000qp-00; Mon, 2 Nov 1998 06:20:53 -0800 Received: from pinea.xerox.fr [193.56.117.2] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zaKqh-0000qb-00; Mon, 2 Nov 1998 06:20:52 -0800 Received: from meije.grenoble.xrce.xerox.com (meije.grenoble.xrce.xerox.com [13.202.220.10]) by pinea.xerox.fr (8.9.0/8.9.0) with ESMTP id PAA13709; Mon, 2 Nov 1998 15:18:16 +0100 (MET) Received: from caucase.grenoble.xrce.xerox.com (caucase.grenoble.xrce.xerox.com [13.202.222.150]) by meije.grenoble.xrce.xerox.com (8.9.1a/8.9.1) with ESMTP id PAA29449; Mon, 2 Nov 1998 15:18:14 +0100 (MET) Received: by caucase.grenoble.xrce.xerox.com with Internet Mail Service (5.5.2232.9) id ; Mon, 2 Nov 1998 15:18:14 +0100 Message-ID: From: Franck Martel To: "'Christian.Donot@inria.fr'" , "'mbone-fr@inria.fr'" , "'rem-conf@es.net'" , "'Pierre.Laforgue@imag.fr'" Subject: Mbone Date: Mon, 2 Nov 1998 15:18:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Sorry for my first mail but I didn't know that "rem-conf@es.net" was an english news group. Here are my questions. I am working on videoconferencing systems. Today we are using Sun Unix stations running with solaris 2.5 or 2.6. We have Flexcam camera , Sun video cards and sun microphones. We also have the MBone tools vic, vat and wb. I have to choose the hardware for our PCs (video capture card, soundcard, microphones, camera) which are running under Windows NT4.0. I have to test the MBone tools and other videoconferencing systems such as Netmeeting, CuSeeMe, MeetingPoint, Intelproshare, LiveLAN ... in order to see which is the best for us. What I would like to know is: 1) What kind of hardware could be suggested for our Sun Unix Stations and for our PCs? (concerning the PCs, I think we are going to choose the video carde Videum from Winov or Wincast from Hauppage is it a good choice? what about the performances of the Quickcam camera?) 2) I would like to join the FMBone or the MBone in order to test Sdr, Vic, Vat, Wb and other Mbone tools. I have visited the following URL http://www.urec.fr/xcast/ and want to know which is the nearest MBone point : is it still the router of IMAG? What is the procedure to join the MBone? Thank you for giving a reply. Franck MARTEL-BADINGA > -------------------------------------------------------------------------------------- > XEROX RESEARCH CENTER EUROPE > 6 chemin de Maupertuis > 38240 Meylan > FRANCE > > Phone: +33 (0)476.61.51.14 > Email : martel@xrce.xerox.com > -------------------------------------------------------------------------------------- > From rem-conf Mon Nov 02 11:25:09 1998 From rem-conf-request@es.net Mon Nov 02 11:25:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zaPRY-0004Ta-00; Mon, 2 Nov 1998 11:15:12 -0800 Received: from mail.aceltd.com (ace-pdc.aceltd.com) [38.200.249.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zaPRX-0004TO-00; Mon, 2 Nov 1998 11:15:11 -0800 Received: by ACE-PDC with Internet Mail Service (5.0.1460.8) id ; Mon, 2 Nov 1998 14:13:58 -0500 Message-ID: <237BD340B58ED111857500A0C99DBA9C149F37@ACE-PDC> From: Robert Kaplan To: "'rem-conf@es.net'" Subject: remove rkaplan@aceltd.com Date: Mon, 2 Nov 1998 14:13:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove rkaplan@aceltd.com Robert Kaplan Director of Product Development 14101 Sullyfield Circle Chantilly, Va 20151 (P) 703-968-5700 (F) 703-968-4331 From rem-conf Tue Nov 03 10:39:43 1998 From rem-conf-request@es.net Tue Nov 03 10:39:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zal9L-0000Kk-00; Tue, 3 Nov 1998 10:25:51 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zal9K-0000KZ-00; Tue, 3 Nov 1998 10:25:50 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id KAA06205; Tue, 3 Nov 1998 10:25:49 -0800 (PST) Message-Id: <3.0.3.32.19981103102548.00906930@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 03 Nov 1998 10:25:48 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/04 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar The Use of Documents in Offices Wednesday November 4, 1998 12:30-2:00 PM 405 Soda Hall Annette Adler Xerox Palo Alto Research Center This talk is about how documents get used. It describes a project, Goldfish, that I've been involved with for the last two years here at Xerox. Goldfish considers how people in a variety of office settings use documents, emerging document types and document appliances (such as pagers and palm pilots), particularly in the context of: 1. intermingled virtual and physical environments (and how folks negotiate getting back and forth) 2. heterogeneous media and document components (digital, paper, voice as well as mixtures of text, graphics, color/black and white, etc.) 3. multiple locations for work Using examples from real people in real offices I will talk about particularly interesting patterns of use that point at possible directions for further work. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Nov 03 13:36:03 1998 From rem-conf-request@es.net Tue Nov 03 13:36:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zao07-0003JA-00; Tue, 3 Nov 1998 13:28:31 -0800 Received: from cx38958-a.elcjn1.sdca.home.com (bonzo.org) [24.4.65.80] (marka) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zao06-0003J0-00; Tue, 3 Nov 1998 13:28:30 -0800 Received: (from marka@localhost) by bonzo.org (8.9.1/8.9.1) id NAA01729; Tue, 3 Nov 1998 13:28:17 -0800 Date: Tue, 3 Nov 1998 13:28:17 -0800 (PST) From: Mark Ayzenshteyn To: rem-conf@es.net Subject: configuration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Is this the right list to ask for help on configuring an machine to recive mbone broadcasts? I don't want to send a huge message detailing my setup just to find out I need to ask my questions elsewhere. Thanks, Mark ========================================================================== Mark Ayzenshteyn CE Major at UCSD marka@bonzo.org http://www.bonzo.org/~marka From rem-conf Tue Nov 03 14:30:13 1998 From rem-conf-request@es.net Tue Nov 03 14:30:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zaot5-0004SH-00; Tue, 3 Nov 1998 14:25:19 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zaot4-0004S7-00; Tue, 3 Nov 1998 14:25:18 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA23742 for ; Tue, 3 Nov 1998 17:25:08 -0500 (EST) Received: (from hgs@localhost) by erlang.cs.columbia.edu (8.9.1/8.9.1) id RAA12916; Tue, 3 Nov 1998 17:25:00 -0500 (EST) Date: Tue, 3 Nov 1998 17:25:00 -0500 (EST) From: Henning Schulzrinne Message-Id: <199811032225.RAA12916@erlang.cs.columbia.edu> To: rem-conf@es.net Subject: CFP: IEEE Network/Internet Computing special issue List: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Papers for a Joint Issue of IEEE Internet Computing (http://www.computer.org/internet) IEEE Network Magazine (http://www.comsoc.org/socstr/techcom/ntwrk/) --------------------------------------------------------------------- Special Issue on Internet Telephony (May/June 1999) --------------------------------------------------- Submission deadline: November 25, 1998 Guest Editor: Henning Schulzrinne Department of Computer Science Columbia University New York, NY Phone: 212 939 7042 Fax: 212 666 0140 WWW: http://www.cs.columbia.edu/~hgs email: hgs@cs.columbia.edu Internet telephony, that is, using the Internet as a communications infrastructure to replace and enhance existing telephone services, is promising to fundamentally change one of the most basic and familiar communications services. This special issue covers the technology needed to make Internet telephony a reality and the challenges that need to be addressed. This is a joint issue of the IEEE Internet Computing and IEEE Network Magazines. Topics of interest for technical papers include: * quality-of-service specific to large-scale telephony services * charging, billing and customer care * web-centric telephony service enhancements * service creation: applications, languages, tools * interworking with the global switched telephone network (GSTN): gateways, service location, directories * hybrid Internet-PSTN architectures * directory services * signaling * novel applications * embedded systems * management of QOS, services and * security and privacy issues * economic and regulatory impact We are especially interested in research papers that describe real services, software systems and experiments. Work-in-progress papers describing the state of on-going research projects in Internet telephony are also encouraged. Papers should explicate the technical issues related to Internet telephony, rather than just generic multimedia applications. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the pitfalls and problems encountered and how they may be overcome. Submission, Approval, Review, and Acceptance. --------------------------------------------- Authors are requested to send e-mail to the guest-editor, Henning Schulzrinne (hgs@cs.columbia.edu), giving a URL where the guest-editor can review the article. The paper can be in PostScript, PDF or HTML format. Upon approval by the guest-editor, all feature articles will then undergo a technical peer review consistent with other archival publications. Potential authors may wish to consult the sections on author information and guidelines for reviewers, which are given at http://www.comsoc.org/socstr/techcom/ntwrk. Articles for review should be in HTML or a common format easily read by reviewers. Authors will send all files to an anonymous ftp site provided by the guest editor. When an article consists of a collection of HTML and GIF files, all internal links pointing to this file should be relative. More details on the submission guidelines can be found in http://www.computer.org/internet/edguide.htm and http://www.comsoc.org/socstr/techcom/ntwrk/ Submission Deadline: November 25, 1998 Acceptance Notification: February 1, 1999 Final Manuscripts Due: March 1, 1999 Publication of Completed Special Issue: May/June 1999 http://www.comsoc.org/socstr/techcom/ntwrk/special/schulzrinne.html From rem-conf Tue Nov 03 15:20:10 1998 From rem-conf-request@es.net Tue Nov 03 15:20:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zapgD-0005Wa-00; Tue, 3 Nov 1998 15:16:05 -0800 Received: from ece.rice.edu [128.42.4.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zapgB-0005WQ-00; Tue, 3 Nov 1998 15:16:03 -0800 Received: from qos.ece.rice.edu (qos.ece.rice.edu [128.42.12.65]) by ece.rice.edu (8.9.0/8.9.0) with ESMTP id RAA10720 for ; Tue, 3 Nov 1998 17:16:02 -0600 (CST) Received: by qos.ece.rice.edu (8.9.0/8.9.0) id RAA07439 for rem-conf@es.net; Tue, 3 Nov 1998 17:16:01 -0600 (CST) From: "Edward W. Knightly" Message-Id: <981103171601.ZM7437@qos.ece.rice.edu> Date: Tue, 3 Nov 1998 17:16:01 -0600 X-Mailer: Z-Mail (4.0.1 13Jan97) To: rem-conf@es.net Subject: CFP: IEEE Network SI on Integrated and Differentiated Services for the Internet MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call For Papers - Special Issue of IEEE Network Magazine on Integrated and Differentiated Services for the Internet Guest Editors ============= Hui Zhang Edward Knightly School of Computer Science ECE Department Carnegie Mellon University Rice University 5000 Forbes Ave 6100 Main Street Pittsburgh, PA 15213-3891 Houston, TX 77005-1892 Phone: (412) 268-8945 Phone: (713) 737-5748 Fax: (412) 268-5574 Fax: (713) 524-5237 Email: hzhang@cs.cmu.edu Email: knightly@ece.rice.edu Several important trends have emerged following the Internet's success. First, the Internet has evolved into a global and commercial communication infrastructure. Second, Internet technology has become the technical basis for not only the Internet, but also for most data communication networks, both public and private. Finally, new and diverse applications are emerging, including distributed multimedia applications, making the inadequacies of a one-size-fits-all service increasingly apparent. These new developments challenge the original design goals of TCP/IP's best effort service model and end-system-only traffic management, and indicate potential opportunities for alternate service models and traffic management schemes. Consequently, new service models, protocols, and resource management architectures have been proposed to cope with emerging applications, and new business and administrative requirements. However, a number of questions must be addressed before enhanced network services can be deployed on the Internet: What are the appropriate service models? What are the architectures and algorithms required for multiple services to co-exist? What are the fundamental tradeoffs in scalability and granularity of quality of service control? This special issue of IEEE Network seeks to shed light on the state-of-the-art and the future of integrated services and differentiated services on the Internet. Topics of interest include: -Testbeds and trials for intserv and diffserv -QoS and scalability -QoS in heterogeneous networks -Multi-class scheduling architectures and algorithms -Internet admission control -Per-hop-behavior definitions and approaches -End-to-end QoS and service differentiation -QoS routing -QoS and aggregate traffic flows -Aggregate vs. per-flow QoS -Service measurement and monitoring -Pricing models -Future of QoS on the Internet Authors are requested to send an email to the guest editor, Ed Knightly, (knightly@ece.rice.edu), giving a URL where a postscript or PDF file can be downloaded by the guest editors. Important Dates --------------- Paper Submission Deadline: March 1 Feedback to Authors: April 1 Final Manuscripts to Publisher: July 1 Publication of Special Issue: September 1999 http://www.comsoc.org/socstr/techcom/ntwrk/special/knightly_zhang.html From rem-conf Wed Nov 04 03:56:53 1998 From rem-conf-request@es.net Wed Nov 04 03:56:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zb1Pl-000552-00; Wed, 4 Nov 1998 03:47:53 -0800 Received: from cancun.fi-a.unam.mx [132.248.54.10] by mail1.es.net with smtp (Exim 1.81 #2) id 0zb1Pj-00054r-00; Wed, 4 Nov 1998 03:47:51 -0800 Received: from default by cancun.fi-a.unam.mx with SMTP (1.38.193.4/16.2) id AA10806; Wed, 4 Nov 1998 05:37:55 -0600 Date: Wed, 4 Nov 1998 05:37:55 -0600 To: ceisuapaa76@helsingborg.se From: ceisuapaa76@helsingborg.se (Photo Transfer Specialties) Comments: Authenticated sender is Subject: You Favorite Photo On a Mousepad?...Great Gift! Message-Id: <19981104900VAA40538@easytoorder.fi-a.unam.mx> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list GREAT CHRISTMAS GIFT IDEA ! PHOTO TRANSFER SPECIALTIES MOUSEPADS WITH YOUR FAVORITE PHOTOS! Now you can have your favorite photos printed onto mousepads! Photo mousepads are our most popular gift year after year! In the past we have provided our HIGH QUALITY mousepads to thousands of customers. Most are so pleased they reorder each year! Photo mousepads make a PERFECT GIFT for ANYONE! Replace boring, dirty, frayed mousepads! Instead of plain, generic, boring corporate logos you can have PERSONALIZED photo mousepads brighten your desktop! PHOTO Mousepads are DAILY REMINDERS of your favorite: CHILDREN, PETS, EVENTS....... WEDDING PHOTOS, FAMILY, GRADUATION..... LOVED ONES,HOLIDAY PHOTOS,GRANDCHILDREN..... Anything you choose! Use your imagination! These HIGH QUALITY,LONG LASTING mousepads are non-skid 1/4" rubber bottoms with comfortable, washable cloth tops. PHOTO TRANSFER SPECIALTIES uses the latest technology available to transfer your favorite 3x5,4x6,5x7,and 8x10 photos onto mousepads. Your photos will be safely RETURNED with your order! This year we are offering a great new LOW PRICE and we are accepting CONVENIENT credit card payment as well as checks and money orders! ORDERS filled FAST and at a great new LOW PRICE! EASY ORDER FORM Please complete and PRINT this form. Mail your photograph(s), payment, and completed order form to the address below along with: Check or Money Order payable to PHOTO TRANSFER SPECIALTIES Or pay by VISA or MASTERCARD by filling out this convenient order form! ____ VISA ____ MASTERCARD Card number: __________________________________ (16 Digits) Expiration Date: ______________________________ Name on card: _________________________________ Billing Address:________________________________ ________________________________ Indicate amount: _______________________________ Signature :___________________________________ Date: __________________________________________ Email address(optional):________________________ CREDIT CARDS : All information must be accurate and complete for proper verification. Incomplete orders cannot be processed and will be returned. Charges on your statement will appear as Pacific Coast Mail Order. $ 10.99 EACH Photo Mousepads $ 9.99 EACH Additional Pads $ 2.50 EACH Shipping and Handling $ 1.05 EACH California residents (sales tax) Address Mousepads to be shipped to: Name: ____________________________________ Address: ____________________________________ Phone # ____________________________________ City,State,Zip_________________________________ Mail Payment, Photographs, and completed order form to: PHOTO TRANSFER SPECIALTIES P.O. BOX #782 ROSS, CA 94957 * Please allow 2 weeks for delivery. * Guarantee Christmas delivery with orders postmarked by December 10th! * Please feel free and copy and distribute this as you like. Combine your order with friends and coworkers and save $1.00 on each additional mousepad. This is a one time only mailing! You have already been placed on our remove list and will not receive another offer from us! Thank You! From rem-conf Thu Nov 05 09:26:08 1998 From rem-conf-request@es.net Thu Nov 05 09:26:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zbSjP-0004AE-00; Thu, 5 Nov 1998 08:57:59 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zbSjO-0004A4-00; Thu, 5 Nov 1998 08:57:58 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA15791; Thu, 5 Nov 1998 08:57:57 -0800 (PST) Message-Id: <3.0.3.32.19981105085757.00a8f210@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 05 Nov 1998 08:57:57 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/11 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Building a Platform for Online Education and Collaboration Wednesday, November 11, 1998 12:30-2:00 pm 405 Soda Hall Anoop Gupta Microsoft Research The demands placed on our higher-education system are rapidly changing. We expect a significant increase in enrollments for professional courses as life-long learning becomes both necessary and pervasive. Furthermore, the learners will demand anytime/anywhere access to the content, they will want the content personalized to meet their specific needs, and the content delivery to match the learning style that works best for them. Most importantly, such education must be delivered at a much lower cost than what we find today. Achieving these goals of scalability, access flexibility, and cost-effectiveness while maintaining educational excellence will not be simple. It will require us to re-think how we educate and to use technology aggressively though judiciously to create leverage. I believe that many of the core technology and infrastructure components for supporting this future vision are already in place today. However, for applications built on these technologies to be successful for the education community, we need to research and understand what are the special needs of learners/instructors, what aspects/activities (e.g., roles/types of collaboration, support for community formation/sustenance) are critical to learners, what is best done by technology and what is best left to humans. We need to build and deploy prototypes in educational environments and conduct studies to understand the issues deeply. The talk will cover issues in use of technology for education and collaboration, including description and demonstration of some projects started recently at Microsoft Research. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Thu Nov 05 15:01:27 1998 From rem-conf-request@es.net Thu Nov 05 15:01:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zbYFH-0007md-00; Thu, 5 Nov 1998 14:51:15 -0800 Received: from smtprich.nortel.com (smtprich) [192.135.215.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zbYFG-0007mT-00; Thu, 5 Nov 1998 14:51:14 -0800 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprich; Thu, 5 Nov 1998 12:18:29 -0600 Received: from zrtpd00n.us.nortel.com by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id V6T458GM; Thu, 5 Nov 1998 13:21:02 -0500 Received: from nrtphf51.us.nortel.com by zrtpd00n.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id V64F97S6; Thu, 5 Nov 1998 13:21:22 -0500 Sender: "Chris Fulmer" Message-ID: <3641EBE8.6F7F8AAB@americasm01.nt.com> Date: Thu, 05 Nov 1998 13:18:16 -0500 From: "Chris Fulmer" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778) MIME-Version: 1.0 To: rem-conf@es.net Subject: ietf-avt-dtmf-00.txt draft -> standard? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hey there... Does anybody know the status of the "ietf-avt-dtmf-00.txt" draft, which defines a method for transmitting DTMF digits via RTP (Presumably in an environment where at least part of the call will go over the PSTN)? I know that a number of vendors are implementing toward this draft, even though it's still a draft and an expired one at that. In addition, the IMTC VoIP interoperability agreement makes reference to this draft. May I suggest that we resurrect this draft and, if not already underway, get the standardization process rolling. It seems that if we don't, it's likely that it will end up as a de-facto standard, anyway. -- Chris Fulmer Northern Telecom chrisf@nortel.com From rem-conf Fri Nov 06 02:30:32 1998 From rem-conf-request@es.net Fri Nov 06 02:30:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zbj2P-000560-00; Fri, 6 Nov 1998 02:22:41 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zbj2N-00055q-00; Fri, 6 Nov 1998 02:22:40 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 6 Nov 1998 10:22:01 +0000 To: Chris Fulmer cc: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? In-reply-to: Your message of "Thu, 05 Nov 1998 13:18:16 EST." <3641EBE8.6F7F8AAB@americasm01.nt.com> Date: Fri, 06 Nov 1998 10:22:21 +0100 Message-ID: <678.910347741@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Chris Fulmer writes: > Does anybody know the status of the "ietf-avt-dtmf-00.txt" draft, which defines a >method for transmitting DTMF digits via RTP (Presumably in an environment where at >least part of the call will go over the PSTN)? I know that a number of vendors are >implementing toward this draft, even though it's still a draft and an expired one at >that. In addition, the IMTC VoIP interoperability agreement makes reference to this >draft. > > May I suggest that we resurrect this draft and, if not already underway, get the >standardization process rolling. It seems that if we don't, it's likely that it will >end up as a de-facto standard, anyway. As you say, the draft has expired. If someone (Henning?) was to produce an update, we would be happy to consider this in AVT. Colin From rem-conf Fri Nov 06 03:41:20 1998 From rem-conf-request@es.net Fri Nov 06 03:41:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zbkCT-00064o-00; Fri, 6 Nov 1998 03:37:09 -0800 Received: from ns.pa [168.77.8.2] by mail1.es.net with smtp (Exim 1.81 #2) id 0zbkCQ-00064e-00; Fri, 6 Nov 1998 03:37:07 -0800 Received: from Default by ns.pa (SMI-8.6/4.03) id GAA18086; Fri, 6 Nov 1998 06:27:59 +0500 Date: Fri, 6 Nov 1998 06:27:59 +0500 To: fuiheiso50@wallstreet10000.com From: fuiheiso50@wallstreet10000.com (kikiolp) Comments: Authenticated sender is Subject: Maximum Internet Presence - how to do it Message-Id: <19981106535BAA28242@colslw.gds4f.pa> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To be removed, reply with the word "delete" in subject area. Have you captured your Internet Market OR are YOU LIMITED BY: * Geographic boundaries or location * Lack of prospects * Lack of exposure DO YOU BELIEVE YOU HAVE A VIABLE PRODUCT OR SERVICE ? Did you know that there is a method of marketing that costs pennies but have the same effect as direct postal mail? THE SOLUTION Direct E-mail marketing is a proven and profitable method with a wide market. It is advantageous compared to conventional methods. The prospects are numerous and can be your city, state or the WORLD. You can now reach them for much less than conventional methods. YOUR ADVERTISEMENT SENT TO ...... Targeted OR General ! Targeted Mailings - Available !! If your product or service demands a targeted market such as country, state, gender, hobby, occupation, or industry, we can send your Ad to targeted recipients. Most targeted lists are available unless they are too targeted/specific. ASK US ! __________________________________________ MORE INFO (24 hrs): 1-888-220-9844 Ref# 6473GC __________________________________________ V*-/-M-/-* From rem-conf Fri Nov 06 05:15:49 1998 From rem-conf-request@es.net Fri Nov 06 05:15:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zbleN-0007Vn-00; Fri, 6 Nov 1998 05:10:03 -0800 Received: from chico.rediris.es [130.206.1.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zbldD-0007V4-00; Fri, 6 Nov 1998 05:09:34 -0800 Received: from news.rediris.es (news.rediris.es [130.206.1.38]) by chico.rediris.es (8.9.1/8.9.1) with ESMTP id OAA08201 for ; Fri, 6 Nov 1998 14:07:12 +0100 (MET) Received: from news.rediris.es (o2.rediris.es [130.206.1.45]) by news.rediris.es (8.8.7/8.8.7.7) with ESMTP id OAA07431 for ; Fri, 6 Nov 1998 14:07:10 +0100 (MET) Message-Id: <199811061307.OAA07431@news.rediris.es> X-Mailer: exmh version 2.0.1 12/23/97 From: Angel Mateo To: rem-conf@es.net Subject: mrouted with snmp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Nov 1998 14:07:11 +0100 Sender: amateo@news.rediris.es X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, has anybody mrouted release 3.9beta3 compiled with snmp support for SGI IRIX 6.3? does anybody know how can I compile it? I have tried to compiled the snmp library, but I get an error with an structure definition and I don't know how to fix it: gcc -O -c system.c system.c: In function `next_ifrp': system.c:62: structure has no member named `sa_len2' system.c:63: structure has no member named `sa_len2' *** Error code 1 (bu21) thanks ----------------------------------------- Angel L. Mateo Martinez RedIRIS/CSIC C/ Serrano, 142 28006 Madrid (Spain) Tlfo: +34-91-5855145 Fax: +34-91-5855146 From rem-conf Fri Nov 06 08:58:53 1998 From rem-conf-request@es.net Fri Nov 06 08:58:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zbp7m-0002Hc-00; Fri, 6 Nov 1998 08:52:38 -0800 Received: from pm01sm.pmm.cw.net [208.159.126.150] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zbp7l-0002FL-00; Fri, 6 Nov 1998 08:52:37 -0800 Received: from cs.columbia.edu (usr13-dialup12.mix2.Boston.cw.net [166.55.70.12]) by PM01SM.PMM.CW.NET (PMDF V5.2-29 #33505) with ESMTP id <0F2000L2QET1WF@PM01SM.PMM.CW.NET> for rem-conf@es.net; Fri, 6 Nov 1998 16:51:28 +0000 (GMT) Date: Fri, 06 Nov 1998 08:52:32 -0500 From: Henning Schulzrinne Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? To: Colin Perkins Cc: Chris Fulmer , rem-conf@es.net Message-id: <3642FF20.EC0F176F@cs.columbia.edu> Organization: Columbia University MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <678.910347741@cs.ucl.ac.uk> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm working on an update and hope to submit it before the I-D deadline. Comments on the old draft are welcome. The old draft can be found at http://www.cs.columbia.edu/~hgs/rtp Colin Perkins wrote: > > --> Chris Fulmer writes: > > Does anybody know the status of the "ietf-avt-dtmf-00.txt" draft, which defines a > >method for transmitting DTMF digits via RTP (Presumably in an environment where at > >least part of the call will go over the PSTN)? I know that a number of vendors are > >implementing toward this draft, even though it's still a draft and an expired one at > >that. In addition, the IMTC VoIP interoperability agreement makes reference to this > >draft. > > > > May I suggest that we resurrect this draft and, if not already underway, get the > >standardization process rolling. It seems that if we don't, it's likely that it will > >end up as a de-facto standard, anyway. > > As you say, the draft has expired. If someone (Henning?) was to produce an > update, we would be happy to consider this in AVT. > > Colin From rem-conf Fri Nov 06 20:32:23 1998 From rem-conf-request@es.net Fri Nov 06 20:32:22 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zbzqY-0005TH-00; Fri, 6 Nov 1998 20:19:34 -0800 Received: from [209.215.68.254] (helo=foreclosure-world.cc) by mail2.es.net with smtp (Exim 1.92 #1) id 0zbzqU-0005S9-00; Fri, 6 Nov 1998 20:19:30 -0800 From: foreclosure-world@foreclosure-world.cc To: aiken@es.net Date: Friday, November 6, 1998 10:48:30 o'clock PM EST Message-Id: <19981106224830.WAA21432@foreclosure-world.cc> Subject: Accept Credit Cards X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ACCEPT CREDIT CARDS!! PRE-APPROVED APPLICATION Good Credit/Bad Credit/No Credit NO APPLICATION FEES For a Limited Time Only! Regular $195.00 Application Fee Waived For This Offer! Increase Your Business Up To 100% Or More, Just By Accepting Credit Cards! This Means More Customers...More Orders...More Money! We Specialize in Home Based Businesses - Apply Today! Accept Visa, Mastercard, American Express, and Discover! Apply Now by visiting our Online Application Site! We are overwhelmed with Responses... http://www.onlineworld.cc * * * * * * * * * * * * * * * * * * * * * * * * * * * If you have received this message in error, please accept our apology as a responsible e-mailer, and reply with the word REMOVE in the subject line. * * * * * * * * * * * * * * * * * * * * * * * * * * * From rem-conf Sun Nov 08 20:49:34 1998 From rem-conf-request@es.net Sun Nov 08 20:49:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zciyz-0004yS-00; Sun, 8 Nov 1998 20:31:17 -0800 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zciyx-0004yI-00; Sun, 8 Nov 1998 20:31:15 -0800 Received: from alf-mobile ([140.249.38.232]) by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA20011 for ; Sun, 8 Nov 1998 23:28:21 -0500 From: aeisenberg@wpine.com (Alfred Eisenberg) To: Subject: REMOVE Date: Sun, 8 Nov 1998 23:29:41 -0500 Message-ID: <000b01be0b99$925999c0$e826f98c@alf-mobile.wpine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <19981106224830.WAA21432@foreclosure-world.cc> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >-----Original Message----- >From: foreclosure-world@foreclosure-world.cc >[mailto:foreclosure-world@foreclosure-world.cc] >Sent: Tuesday, January 06, 1998 5:49 AM >To: aiken@es.net >Subject: Accept Credit Cards > > >ACCEPT CREDIT CARDS!! >PRE-APPROVED APPLICATION >Good Credit/Bad Credit/No Credit > >NO APPLICATION FEES >For a Limited Time Only! >Regular $195.00 Application Fee Waived For This Offer! > >Increase Your Business Up To 100% Or More, Just By >Accepting Credit Cards! >This Means More Customers...More Orders...More Money! >We Specialize in Home Based Businesses - Apply Today! >Accept Visa, Mastercard, American Express, and Discover! > >Apply Now by visiting our Online Application Site! >We are overwhelmed with Responses... > >http://www.onlineworld.cc > > >* * * * * * * * * * * * * * * * * * * * * * * * * * * >If you have received this message in error, please >accept our apology as a responsible e-mailer, and >reply with the word REMOVE in the subject line. >* * * * * * * * * * * * * * * * * * * * * * * * * * * > > From rem-conf Sun Nov 08 22:15:42 1998 From rem-conf-request@es.net Sun Nov 08 22:15:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zckUj-00061Z-00; Sun, 8 Nov 1998 22:08:09 -0800 Received: from agora.rdrop.com [199.2.210.241] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zckUh-00061P-00; Sun, 8 Nov 1998 22:08:07 -0800 Received: from s.brower (ppp-d8.rdrop.com [199.2.212.41]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id WAA29937; Sun, 8 Nov 1998 22:08:02 -0800 (PST) Message-Id: <3.0.32.19981108220743.00a0ef1c@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 08 Nov 1998 22:07:44 -0800 To: wijnen@vnet.ibm.com From: Mark Baugher Subject: RTP MIB Cc: rem-conf@es.net, hmibs@mailbag.cps.intel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bert Thanks for your comments and pardon my very late reply to your note. On Thursday, September 03, 1998 9:18 AM, Bert Wijnen [SMTP:WIJNEN@VNET.IBM.COM] wrote: > Since this MIB was shortly discussed during the HMIBS-BOF, I took a > quick read thorugh the document. Here are some initial comments: > > 1.Section 3. > Please use the new MIB Boilerplate, see > http://www.ops.ietf.org/mib-boilerplate.html We'll do that. > > 2.You talk a lot about "Sub-agents". It sort of sounds as if you > prescribe or recommend to use Sub-agent technology. That to me > however seems an implementation detail. You should certainly leave > it open as to "how people implement". We mean the logical entity that processes messages to the RTP MIB as opposed to the SNMP Agent or the RTP management entity. This is not meant to convey sub-agent technology such as in DPI or a commercial product such as from Emanate. Since it's use in the RTP MIB is confusing we'll drop it in favor of "RTP agent." > > 3.You are redefining InterfaceIndex different from IF-MIB (RFC2233). > This is not allowed. If you want a special value of zero, then > you need to use a different name for the TC. > Seems you want to import InterfaceIndexOrZero from the IF-MIB and > use that TC instead. Well, I had a problem and looked around at how others solved it and then decided to solve it in exactly the same way the RFC1850 did. Since we did that, RFC 2233 was published with the InterfaceIndexOrZero TC. We'll use it. > > 4.I think sect 4.2 is not needed. The new boilerplate referes to the > SMIv2-TC document and things are well described there. Yes it does. > > 5.I find the wording in section 4.5 "strange". > See also point 2 above. I feel that we can drop this section now. When we started the RTP MIB there was concern voiced about RTP application-level framing design and the absence of a standards-based solution for SNMP management of host applications. This probably should not be a consideration and anyway is no longer the case. > > 6.I would use > RTP-MIB ::= DEFINITIONS BEGIN > Instead of > RTP ::= DEFINITIONS BEGIN Okay. > > 7.I would use rtpMIB instead of rtp for MODULE-IDENTITY > also, pls ensure to add > ::= { mib-2 xx } -- to be assigned by IANA when going to Proposed Okay. > > 8.The way your organize your MIB is technically OK I think. But we > prefer MIBs to look familiar and similar if possible. > The common way to start off the MIB is something like: > rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 } > rtpAdmin OBJECT IDENTIFIER ::= { rtpMIB 2 } > rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 3 } > > rtpDomains OBJECT IDENTIFIER ::= { rtpAdmin 1 } > rtpUDPDomain OBJECT IDENTIFIER ::= { rtpDomains 1 } > > Your objects then get rooted unde rtpMIBObjects, the conformance > and groups further down in your MIB get rooted under > rtpConformance, as follows: > > rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 1 } > rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 2 } > > rtpCompliance MODULE-COMPLIANCE > .... > ::= { rtpConformance 1 } > > rtpXxxGroup OBJECT-GROUP > .... > ::= { rtpGroups 1 } Okay. > > 9.I find text like: > "Cannot be changed after trpSessionRowStatus is 'active'." > ===== ======= > difficult to understand. What does "after ... is" mean? > Do you mean that once a row becomes active it can never be > be changed. Or do you mean that it cannot be changed while the > row is in "active" state, but that it can e changed if the row > is changed to "notInService" first??? This is from the DESCRIPTION clause of RowStatus in RFC 1903. SNMPv2 Working Group Standards Track [Page 7] RFC 1903 Textual Conventions for SNMPv2 January 1996 NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. It is the responsibility of the DESCRIPTION clause, quoting from above, to specify whether the status colums must not be 'active' in order to change the value of a conceptual column. That's what's intended here. I'll change it to simply read "must not be active." > > 10. In RowStatus, you must specify what the pre-requisites are > before a row can be made 'active' I thought we did specify that in our DESCRIPTION clause: "Value of 'active' when RTP or RTCP messages are being sent or received by an RTP System. A manager-created conceptual row must have the rtpSessionAddr initialized by the manager before becoming 'active'. What am I missing? > > 11.rtpSessionReceivers (as an example) is a counter32. > It seems to me that the description is not clear. I think it is > not the "maximum receivers", but "the number of joins that you have > seen". So maybe a better name would be rtpSessionReceiverJoins? > In any event, it is not clear to me what the count represents We should define it operationally as the number of receivers that have sent RTP Receiver Reports for the particular session as observed by the RTP management entity. "Number of joins" that have been seen sounds like a good way to describe this. > > 12.rtpSessionMonitor > You list a MUST for "RTP Host Systems" twice. Okay. > > 13.Take rtpSenderAddr as an example. > I think it would be usefull to specify that it is formatted > according to rtpUDPDomain (at least I think that is what it is) Yes and it's inconsistent that we mentioned that for the session address but not for the sender or receiver addresses. > > 14.Take as an example rtpSenderSRTime. I think by giving special > meaning to the value of zero, it is not really a TimeStamp any more. I agree. I think it would be better to return 'noSuchInstance' in place of using zero. > > 15.Take rtpRcvrRTT as an example. > Do I understand that in some rows a value could be present but in > others it would not be present. In that case a noSuchInstance > should be returned (only on a GET by the way, not on a GETNEXT) > instead of a noSUchObject (see RFC1905 for explanantion). There are cases where RTT can be reliably collected (clocks are synchronized between the RTP agent and the sender). If an RTP monitor is implemented in a sender, for example, then it will be able to collect RTT values for that sender's receivers but not necessarily for other senders. So it is as you say it is and I agree that noSuchInstance is what we should use rather than noSuchObject. > > 16.rtpRcvrLostOctets > Not that I promote Counter64... but is this a possible candidate > for COunter64 instead of Counter32?? See rules in RFC1902 A media stream in excess of 9.5 mbps can cause some RTP MIB octet counters to roll within an hour. We should use Counter64, not Counter32. > > 17.rtpRcvvrPT and rtpSenderPT > Is it possible that this is a session attribute and so would belong > in the session table? It might be that my lack of skills in RTP > show up here. No, there may be multiple streams to a session, and we need to support the possibility that there may be different PTs for individual sender's streams to an RTP session. > > 18.rtpCOmpliance. > It seems to me that you want at least 2 compliance statements, > one for n RTP monitor and one for an RTP HOST. > That makes it much easier for people to claim the proper > compliance. Okay. > Also, you use of "MAY NOT" probably means "does not need to" > as opposed "is not allowed to" (which is how I perceive it). > Seems to me that "does not need to" is the proper language, > or maybe "is not required to". We mean "is not required to" so we should replace "MAY NOT" with it. > > Hope this helps, Bert Thanks, Mark From rem-conf Sun Nov 08 23:50:14 1998 From rem-conf-request@es.net Sun Nov 08 23:50:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zclwo-00076e-00; Sun, 8 Nov 1998 23:41:14 -0800 Received: from sumo.vocaltec.co.il [199.203.72.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zclwh-00076U-00; Sun, 8 Nov 1998 23:41:09 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id JAA12256; Mon, 9 Nov 1998 09:37:35 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566B7.002A44AD ; Mon, 9 Nov 1998 09:41:40 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: Henning Schulzrinne cc: rem-conf@es.net, magnells@dialogic.com Message-ID: <422566D2.0065441D.00@il4.vocaltec.co.il> Date: Sun, 6 Dec 1998 20:47:32 +0200 Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There is definitely a need to expand this draft in two ways. One is obvious, and the other is a bit more subtle: 1. As I suggested many months ago, in addition to DTMF tones, there needs to be all of the network control tones that were in SGCP and are now in MGCP. Things like "off hook", "flash hook", "dial tone", "busy tone", "ringing" etc. BTW, this is enough that the title of the draft should be changed to something like "telephony control audio tones" rather than just "dtmf". 2. The problem is that all those tones are totally different physical tones (i.e. frequencies, durations, etc) in different parts of the world. For example, "ringing" in France sounds a bit like "busy" in America. This is not at all an impossible problem to solve, in fact it is relatively straightforward. There needs to be the possibility to express some simple "tone cadences" in this payload type. Basically it is enough to define a payload where each frame specifies a set of (frequency, energy, duration) triples to be played. The magic of RTP can then be used to specify very effeciently whatever network tones are needed. While it is true that once you do this, you don't need to specify a special octet for things like DTMF or "ringing", it probably is a very useful and practical thing to allow "shortcuts" for things them. Please let's take the "International" part of the IETF's name seriously. Just saying "dialtone1" to "dialtone4" will make it impossible to reproduce certain things in international calls. When I call England, I want to hear English ringing tones, etc. I personally think that it's a great idea to have the "shortcuts" as well. It could be a very useful new feature for a Frenchman to hear an "French ringing tone" when an French phone rings a Japanese phone. But I think that we definitely need both services. There is a slippery slope of just how much we need to specify. I would suggest that it is enough to have an arbitrary number of (Frequency, energy, duration) triples within each RTP packet. This may not cover absolutely every possible imaginable tone cadence, but it covers anything that people actually use in practise. Scott Henning Schulzrinne on 11/06/98 03:52:32 PM To: Colin Perkins cc: Chris Fulmer , rem-conf@es.net (bcc: Scott Petrack) Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? I'm working on an update and hope to submit it before the I-D deadline. Comments on the old draft are welcome. The old draft can be found at http://www.cs.columbia.edu/~hgs/rtp Colin Perkins wrote: > > --> Chris Fulmer writes: > > Does anybody know the status of the "ietf-avt-dtmf-00.txt" draft, which defines a > >method for transmitting DTMF digits via RTP (Presumably in an environment where at > >least part of the call will go over the PSTN)? I know that a number of vendors are > >implementing toward this draft, even though it's still a draft and an expired one at > >that. In addition, the IMTC VoIP interoperability agreement makes reference to this > >draft. > > > > May I suggest that we resurrect this draft and, if not already underway, get the > >standardization process rolling. It seems that if we don't, it's likely that it will > >end up as a de-facto standard, anyway. > > As you say, the draft has expired. If someone (Henning?) was to produce an > update, we would be happy to consider this in AVT. > > Colin From rem-conf Mon Nov 09 03:16:13 1998 From rem-conf-request@es.net Mon Nov 09 03:16:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zcpDw-00018Z-00; Mon, 9 Nov 1998 03:11:08 -0800 Received: from vnet.ibm.com [204.146.168.194] by mail1.es.net with smtp (Exim 1.81 #2) id 0zcpDv-00018O-00; Mon, 9 Nov 1998 03:11:07 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 8671; Mon, 09 Nov 98 06:11:05 2 E Date: Mon, 9 Nov 98 12:09:13 CET From: "Bert Wijnen" To: mbaugher@rdrop.com cc: rem-conf@es.net, hmibs@mailbag.cps.intel.com Subject: RTP MIB Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ref: Your note of Sun, 08 Nov 1998 22:07:44 -0800 Subject: Re: RTP MIB Good to read that I made some usefull comments. And thanks for explaining those areas I did not understand. One open question you raised: > > 10. In RowStatus, you must specify what the pre-requisites are > > before a row can be made 'active' > I thought we did specify that in our DESCRIPTION clause: > "Value of 'active' when RTP or RTCP messages are being > sent or received by an RTP System. A manager-created > conceptual row must have the rtpSessionAddr initialized by > the manager before becoming 'active'. > What am I missing? > Guess I didn't read it well enough. Seems OK after rereading. Bert From rem-conf Mon Nov 09 06:12:45 1998 From rem-conf-request@es.net Mon Nov 09 06:12:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zcrzW-0002ts-00; Mon, 9 Nov 1998 06:08:26 -0800 Received: from relay7.uu.net [192.48.96.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zcrzU-0002tc-00; Mon, 9 Nov 1998 06:08:24 -0800 Received: from [208.236.204.65] by relay7.UU.NET with SMTP (peer crosschecked as: gateus.nmss.com [208.236.204.65]) id QQfotk07013; Mon, 9 Nov 1998 09:07:57 -0500 (EST) From: Kevin_Bruemmer@nmss.com Received: from nmsnotes4.nmss.com by [208.236.204.65] via smtpd (for relay7.UU.NET [192.48.96.17]) with SMTP; 9 Nov 1998 14:12:17 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566B7.004DCF61 ; Mon, 9 Nov 1998 09:09:53 -0500 X-Lotus-FromDomain: NATURAL MICROSYSTEMS To: "Scott Petrack" cc: Henning Schulzrinne , rem-conf@es.net Message-ID: <852566B7.004AC2B5.00@notes4.nmss.com> Date: Mon, 9 Nov 1998 09:08:48 -0500 Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would like to participate in this activity. I am relatively new to Internet Telephony (1 year) - though I have extensive experience in telephony signal processing. I would like to bring myself up to speed on what ideas have already been discussed or proposed for RTP transport of DTMF and other call progession signals. I was not able to locate the subject draft (my assumption is that it has been removed from the drafts list because it has expired - right?). Could you send me an old copy of ieft-avt-dtmf-00.txt? I have spent some time going over the H.245 method for doing out-of-band DTMF transport. Discounting the fact that it is H-Series specific, not having been part of the discussions, I find the technique adopted in H.245 to be complicated to implement and probably even more complicated to test in a laboratory. I get the sense that this out-of-band technique was not fully tested before it was adopted in H.245 version 3. As far as other call progression signals, this is a big job. As you have stated there is no world-wide standard on call progression signals (the last I knew). Creating detectors for these signals is troublesome. PBXs do whatever they want and offer some programmability. Though modems and fax machines attempt dection of these signals, they usually "brute force" themselves through any ambiquities in detecting call progression signals. Kevin Bruemmer IP Telepony DSP Natural Microsystems "Scott Petrack" on 12/06/98 01:47:32 PM To: Henning Schulzrinne cc: rem-conf@es.net, magnells@dialogic.com (bcc: Kevin Bruemmer) Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? There is definitely a need to expand this draft in two ways. One is obvious, and the other is a bit more subtle: 1. As I suggested many months ago, in addition to DTMF tones, there needs to be all of the network control tones that were in SGCP and are now in MGCP. Things like "off hook", "flash hook", "dial tone", "busy tone", "ringing" etc. BTW, this is enough that the title of the draft should be changed to something like "telephony control audio tones" rather than just "dtmf". 2. The problem is that all those tones are totally different physical tones (i.e. frequencies, durations, etc) in different parts of the world. For example, "ringing" in France sounds a bit like "busy" in America. This is not at all an impossible problem to solve, in fact it is relatively straightforward. There needs to be the possibility to express some simple "tone cadences" in this payload type. Basically it is enough to define a payload where each frame specifies a set of (frequency, energy, duration) triples to be played. The magic of RTP can then be used to specify very effeciently whatever network tones are needed. While it is true that once you do this, you don't need to specify a special octet for things like DTMF or "ringing", it probably is a very useful and practical thing to allow "shortcuts" for things them. Please let's take the "International" part of the IETF's name seriously. Just saying "dialtone1" to "dialtone4" will make it impossible to reproduce certain things in international calls. When I call England, I want to hear English ringing tones, etc. I personally think that it's a great idea to have the "shortcuts" as well. It could be a very useful new feature for a Frenchman to hear an "French ringing tone" when an French phone rings a Japanese phone. But I think that we definitely need both services. There is a slippery slope of just how much we need to specify. I would suggest that it is enough to have an arbitrary number of (Frequency, energy, duration) triples within each RTP packet. This may not cover absolutely every possible imaginable tone cadence, but it covers anything that people actually use in practise. Scott Henning Schulzrinne on 11/06/98 03:52:32 PM To: Colin Perkins cc: Chris Fulmer , rem-conf@es.net (bcc: Scott Petrack) Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? I'm working on an update and hope to submit it before the I-D deadline. Comments on the old draft are welcome. The old draft can be found at http://www.cs.columbia.edu/~hgs/rtp Colin Perkins wrote: > > --> Chris Fulmer writes: > > Does anybody know the status of the "ietf-avt-dtmf-00.txt" draft, which defines a > >method for transmitting DTMF digits via RTP (Presumably in an environment where at > >least part of the call will go over the PSTN)? I know that a number of vendors are > >implementing toward this draft, even though it's still a draft and an expired one at > >that. In addition, the IMTC VoIP interoperability agreement makes reference to this > >draft. > > > > May I suggest that we resurrect this draft and, if not already underway, get the > >standardization process rolling. It seems that if we don't, it's likely that it will > >end up as a de-facto standard, anyway. > > As you say, the draft has expired. If someone (Henning?) was to produce an > update, we would be happy to consider this in AVT. > > Colin From rem-conf Mon Nov 09 07:54:33 1998 From rem-conf-request@es.net Mon Nov 09 07:54:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zctXy-00048g-00; Mon, 9 Nov 1998 07:48:06 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zctXu-00048W-00; Mon, 9 Nov 1998 07:48:03 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Nov 9 10:47:12 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA23953; Mon, 9 Nov 1998 10:47:04 -0500 (EST) Message-ID: <36470DD8.9B7C75C5@dnrc.bell-labs.com> Date: Mon, 09 Nov 1998 10:44:24 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Scott Petrack CC: Henning Schulzrinne , rem-conf@es.net, magnells@dialogic.com Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? References: <422566D2.0065441D.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scott Petrack wrote: > > 2. The problem is that all those tones are totally different physical tones > (i.e. frequencies, durations, etc) in different parts of the world. For > example, "ringing" in France sounds a bit like "busy" in America. > > This is not at all an impossible problem to solve, in fact it is relatively > straightforward. There needs to be the possibility to express some simple > "tone cadences" in this payload type. Basically it is enough to define a > payload where each frame specifies a set of (frequency, energy, duration) > triples to be played. The magic of RTP can then be used to specify very > effeciently whatever network tones are needed. I don't see how this solves it. Lets say, for arguments sake, a ringing is a 1khz tone in the US, and 2khz in France. Now, if a US RTP system encodes the ringing as 1khz, this won't be played properly in France. Perhaps I'm misunderstanding your solution? Use of what you call "shortcuts" will solve this problem, though. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Nov 09 10:30:33 1998 From rem-conf-request@es.net Mon Nov 09 10:30:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zcw11-0001mk-00; Mon, 9 Nov 1998 10:26:15 -0800 Received: from (mail.dialogic.com) [146.152.3.117] by mail1.es.net with smtp (Exim 1.81 #2) id 0zcw0z-0001mS-00; Mon, 9 Nov 1998 10:26:13 -0800 Received: from steiglitz.dialogic.com by mail.dialogic.com with smtp (Smail3.1.29.1 #1) id m0zcvH4-000Ig4C; Mon, 9 Nov 98 12:38 EST Message-Id: <3.0.3.32.19981109132415.006e7f38@mercury.dialogic.com> X-Sender: magnells@mercury.dialogic.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 09 Nov 1998 13:24:15 -0500 To: Jonathan Rosenberg From: Steven Magnell Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Cc: Scott Petrack , Henning Schulzrinne ,rem-conf@es.net In-Reply-To: <36470DD8.9B7C75C5@dnrc.bell-labs.com> References: <422566D2.0065441D.00@il4.vocaltec.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:44 AM 11/9/98 -0500, Jonathan Rosenberg wrote: >Scott Petrack wrote: >> >> 2. The problem is that all those tones are totally different physical tones >> (i.e. frequencies, durations, etc) in different parts of the world. For >> example, "ringing" in France sounds a bit like "busy" in America. >> >> This is not at all an impossible problem to solve, in fact it is relatively >> straightforward. There needs to be the possibility to express some simple >> "tone cadences" in this payload type. Basically it is enough to define a >> payload where each frame specifies a set of (frequency, energy, duration) >> triples to be played. The magic of RTP can then be used to specify very >> effeciently whatever network tones are needed. > >I don't see how this solves it. Lets say, for arguments sake, a ringing >is a 1khz tone in the US, and 2khz in France. Now, if a US RTP system >encodes the ringing as 1khz, this won't be played properly in France. >Perhaps I'm misunderstanding your solution? Use of what you call >"shortcuts" will solve this problem, though. What you describe replicates what happens today over the PSTN. The method of encoding the parameters describing call progress tones (ringing, busy, etc.), allows the listener to hear what is being generated at the far end without distortion created by a voice codec. When I place a call to France today, I hear a French ringing tone, not a US one. I'm not sure that the shortcuts that Scott proposes are appropriate within the RTP stream. Since call progress is reflected through the call signaling protocol (SIP, H.323, MGCP, etc.), an endpoint could choose to ignore the tones received via RTP and synthesize "local" versions based on call state. This would, of course, confuse a French caller who is calling home from the US and expects to hear a French ringing tone. steve magnell Dialogic Corporation From rem-conf Mon Nov 09 11:19:22 1998 From rem-conf-request@es.net Mon Nov 09 11:19:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zcwmS-0002o1-00; Mon, 9 Nov 1998 11:15:16 -0800 Received: from smtprich.nortel.com (smtprich) [192.135.215.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zcwmR-0002nr-00; Mon, 9 Nov 1998 11:15:15 -0800 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprich; Mon, 9 Nov 1998 13:14:11 -0600 Received: from zrtpd00x.us.nortel.com by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id WQFCYQRP; Mon, 9 Nov 1998 14:14:04 -0500 Received: from nrtphf51.us.nortel.com by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id V64J3AC7; Mon, 9 Nov 1998 14:14:04 -0500 Sender: "Chris Fulmer" Message-ID: <36473EFB.792581E4@americasm01.nt.com> Date: Mon, 09 Nov 1998 14:14:04 -0500 From: "Chris Fulmer" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778) MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? References: <422566D2.0065441D.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is something of an interesting question, and changes the meaning somewhat of the draft -- I believe that Henning's draft was intended to transfer indications of keypad-press 'events', whereas you're suggesting a somewhat more generic "This is how we pass fixed tones around," which has many applications outside of any telephony signalling. It's worthy of further study, but I'm not convinced that it makes sense for DTMF. It seems to me that a brief look at the problem the DTMF draft is trying to solve is in order. My impression (not having been involved at the time) is that a primary driver behind this draft is that with compressed-audio payloads (G.729, G.723.1, for example) which are optimized for voice, a receiver performing automated DTMF-recognition against the incoming stream may not be able to recognize the incoming DTMF due to changes in the waveform. Since there are all sorts of services which use DTMF, this can be a serious stumbling block in any VoIP/PSTN integration. So, the reason for encoding DTMF seperately is because there's going to be some automated recognition on the other end, which can't handle compressed/uncompressed audio. It is possible to make a case that Dial-tone, Busy, and so on are recognized as tones, especially by modems. But, I would suggest that these are actually call-setup signals, the exception being the flash. I'm not sure how you'd encode that using tones, though.... DTMF can also be considered to be signals, but I'd venture to say that they're a special kind, since they're not necessarily signals to the voice fabric. As such, they deserve special treatment. -- Chris Scott Petrack wrote: > There is definitely a need to expand this draft in two ways. One is > obvious, and the other is a bit more subtle: > > 1. As I suggested many months ago, in addition to DTMF tones, there needs > to be all of the network control tones that were in SGCP and are now in > MGCP. Things like "off hook", "flash hook", "dial tone", "busy tone", > "ringing" etc. > > BTW, this is enough that the title of the draft should be changed to > something like "telephony control audio tones" rather than just "dtmf". > > 2. The problem is that all those tones are totally different physical tones > (i.e. frequencies, durations, etc) in different parts of the world. For > example, "ringing" in France sounds a bit like "busy" in America. > > This is not at all an impossible problem to solve, in fact it is relatively > straightforward. There needs to be the possibility to express some simple > "tone cadences" in this payload type. Basically it is enough to define a > payload where each frame specifies a set of (frequency, energy, duration) > triples to be played. The magic of RTP can then be used to specify very > effeciently whatever network tones are needed. > > While it is true that once you do this, you don't need to specify a special > octet for things like DTMF or "ringing", it probably is a very useful and > practical thing to allow "shortcuts" for things them. > > Please let's take the "International" part of the IETF's name seriously. > Just saying "dialtone1" to "dialtone4" will make it impossible to reproduce > certain things in international calls. When I call England, I want to hear > English ringing tones, etc. > > I personally think that it's a great idea to have the "shortcuts" as well. > It could be a very useful new feature for a Frenchman to hear an "French > ringing tone" when an French phone rings a Japanese phone. But I think > that we definitely need both services. > > There is a slippery slope of just how much we need to specify. I would > suggest that it is enough to have an arbitrary number of (Frequency, > energy, duration) triples within each RTP packet. This may not cover > absolutely every possible imaginable tone cadence, but it covers anything > that people actually use in practise. > > Scott > > Henning Schulzrinne on 11/06/98 03:52:32 PM > > To: Colin Perkins > cc: Chris Fulmer , rem-conf@es.net (bcc: Scott Petrack) > Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? > > I'm working on an update and hope to submit it before the I-D deadline. > Comments on the old draft are welcome. The old draft can be found at > http://www.cs.columbia.edu/~hgs/rtp > > Colin Perkins wrote: > > > > --> Chris Fulmer writes: > > > Does anybody know the status of the "ietf-avt-dtmf-00.txt" draft, > which defines a > > >method for transmitting DTMF digits via RTP (Presumably in an > environment where at > > >least part of the call will go over the PSTN)? I know that a number of > vendors are > > >implementing toward this draft, even though it's still a draft and an > expired one at > > >that. In addition, the IMTC VoIP interoperability agreement makes > reference to this > > >draft. > > > > > > May I suggest that we resurrect this draft and, if not already > underway, get the > > >standardization process rolling. It seems that if we don't, it's likely > that it will > > >end up as a de-facto standard, anyway. > > > > As you say, the draft has expired. If someone (Henning?) was to produce > an > > update, we would be happy to consider this in AVT. > > > > Colin -- Chris Fulmer Nortel, Ltd RTP, NC From rem-conf Mon Nov 09 13:41:51 1998 From rem-conf-request@es.net Mon Nov 09 13:41:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zcyzX-0004Yk-00; Mon, 9 Nov 1998 13:36:55 -0800 Received: from iris.ctd.comsat.com [134.133.40.12] (exim) by mail1.es.net with smtp (Exim 1.81 #2) id 0zcyzV-0004YU-00; Mon, 9 Nov 1998 13:36:54 -0800 Received: from simao by iris.ctd.comsat.com with local (Exim 1.82 #1) id 0zcyxt-0001B0-00; Mon, 9 Nov 1998 16:35:13 -0500 From: Simao Campos To: "Chris Fulmer" Cc: Scott Petrack , rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? In-Reply-To: <36473EFB.792581E4@americasm01.nt.com> References: <422566D2.0065441D.00@il4.vocaltec.co.il> <36473EFB.792581E4@americasm01.nt.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid cc: X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P: GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Message-Id: Date: Mon, 9 Nov 1998 16:35:13 -0500 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, [Only my 2 cents on the issue.] The issue on carrying DTMF over RTP has been discussed extensively on this reflector, as well as on the ITU Q.13/16 reflector. Trying to keep it simple, we could stick to Henning's text (unless it is totally flawed :-), and if deemed worthwhile, an "evolutionary" text could start to make the current text more general. It has now the 10 digits, #, *, and flash, I suppose. Adding other features may add a considerable delay in the process. Someone mentioned that this is already being implemented by the industry, so it maybe important to give it a more formal stand (i.e. an RFC number), and go forward from there. Simao Campos =========================================================================== Simao Ferraz de Campos Neto, Sr.MTS *All comments are strictly my own* COMSAT Laboratories Tel: +1-301-428-4516 22300 Comsat Drive Fax: +1-301-428-9287 Clarksburg MD 20871 - USA E-mail: simao.campos@comsat.com =========================================================================== ******** Practice random kindness and senseless acts of beauty ******** =========================================================================== From rem-conf Mon Nov 09 15:36:33 1998 From rem-conf-request@es.net Mon Nov 09 15:36:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zd0ls-0005yj-00; Mon, 9 Nov 1998 15:30:56 -0800 Received: from mail-gw2.pacbell.net [206.13.28.53] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zd0lr-0005y7-00; Mon, 9 Nov 1998 15:30:55 -0800 Received: from [192.168.0.1] (ppp-206-170-6-106.rdcy01.pacbell.net [206.170.6.106]) by mail-gw2.pacbell.net (8.8.8/8.7.1+antispam) with SMTP id PAA18283; Mon, 9 Nov 1998 15:29:14 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Nov 1998 15:29:16 -0800 To: Simao Campos , "Chris Fulmer" From: Ari Ollikainen Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Cc: Scott Petrack , rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 4:35 PM 11/9/98, Simao Campos wrote: >Dear all, > >[Only my 2 cents on the issue.] > >The issue on carrying DTMF over RTP has been discussed extensively on >this reflector, as well as on the ITU Q.13/16 reflector. Trying to >keep it simple, we could stick to Henning's text (unless it is totally >flawed :-), and if deemed worthwhile, an "evolutionary" text could >start to make the current text more general. It has now the 10 digits, >#, *, and flash, I suppose. Adding other features may add a >considerable delay in the process. The version I read says: ----excerpt----- digit: The DTMF digits are encoded as follows: DTMF digit encoding (decimal) ________________________________ 0 0 1 1 2 2 9 9 !*! 10 # 11 A 12 B 13 C 14 D 15 Flash 16 ----end excerpt----- This table raises the question of the significance of "flash" for example, on an end-to-end basis. It's my impression that "flash" has local significance, ie between the end (instrument) and the nearest "switch". Also, how many ACD or IVR applications make use of A,B,C,D (and flash) tones, since they're NOT available on most phone keypads? Make it simpler: 0-9, *, # required A-D, Flash optional Nothing more. OLTECO Ari Ollikainen P.O. BOX 3688 Networking Technology and Architecture Stanford, CA Ari@OLTECO.com 94309-3688 415.517.3519 From rem-conf Tue Nov 10 07:58:56 1998 From rem-conf-request@es.net Tue Nov 10 07:58:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdG0l-0004wd-00; Tue, 10 Nov 1998 07:47:19 -0800 Received: from hertz.ece.wisc.edu [128.104.183.33] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdG0j-0004wS-00; Tue, 10 Nov 1998 07:47:17 -0800 Received: by hertz.ece.wisc.edu (SMI-8.6/SMI-SVR4) id JAA15943; Tue, 10 Nov 1998 09:47:16 -0600 Date: Tue, 10 Nov 1998 09:47:16 -0600 From: dovrolis@hertz.ece.wisc.edu (Constantinos) Message-Id: <199811101547.JAA15943@hertz.ece.wisc.edu> To: rem-conf@es.net Subject: G.723.1 and G.729 source code? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: ltqBEcQOKvrif8KzZz+TWQ== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi there, Can I find anywhere the source code for the G.723.1 or the G.729 codecs? I need it for research and not for commercial purposes.. Thanks a lot, Constantinos From rem-conf Tue Nov 10 08:51:43 1998 From rem-conf-request@es.net Tue Nov 10 08:51:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdGxv-00060r-00; Tue, 10 Nov 1998 08:48:27 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdGxu-00060h-00; Tue, 10 Nov 1998 08:48:26 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA01100; Tue, 10 Nov 1998 08:48:25 -0800 (PST) Message-Id: <3.0.3.32.19981110084824.00a89d70@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 10 Nov 1998 08:48:24 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: Reminder 11/11 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Building a Platform for Online Education and Collaboration Wednesday, November 11, 1998 12:30-2:00 pm 405 Soda Hall Anoop Gupta Microsoft Research The demands placed on our higher-education system are rapidly changing. We expect a significant increase in enrollments for professional courses as life-long learning becomes both necessary and pervasive. Furthermore, the learners will demand anytime/anywhere access to the content, they will want the content personalized to meet their specific needs, and the content delivery to match the learning style that works best for them. Most importantly, such education must be delivered at a much lower cost than what we find today. Achieving these goals of scalability, access flexibility, and cost-effectiveness while maintaining educational excellence will not be simple. It will require us to re-think how we educate and to use technology aggressively though judiciously to create leverage. I believe that many of the core technology and infrastructure components for supporting this future vision are already in place today. However, for applications built on these technologies to be successful for the education community, we need to research and understand what are the special needs of learners/instructors, what aspects/activities (e.g., roles/types of collaboration, support for community formation/sustenance) are critical to learners, what is best done by technology and what is best left to humans. We need to build and deploy prototypes in educational environments and conduct studies to understand the issues deeply. The talk will cover issues in use of technology for education and collaboration, including description and demonstration of some projects started recently at Microsoft Research. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Nov 10 10:51:28 1998 From rem-conf-request@es.net Tue Nov 10 10:51:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdInx-0007if-00; Tue, 10 Nov 1998 10:46:17 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdInv-0007iV-00; Tue, 10 Nov 1998 10:46:16 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Nov 10 13:44:54 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id NAA07363 for ; Tue, 10 Nov 1998 13:44:53 -0500 (EST) Message-ID: <36488900.6511715@dnrc.bell-labs.com> Date: Tue, 10 Nov 1998 13:42:08 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: New FEC draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I've just sent a new version of the FEC draft to the archives. It should appear shortly. Until then, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-fec-04.txt Changes since -03: * removal of Reed Solomon stuff * code has been compiled and tested * acknowledgements added * figures cleaned up, examples double-checked * no mask extension, E bit is now reserved Thats about it. Hopefully we can go to wg last call soon on this... -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Nov 10 11:07:40 1998 From rem-conf-request@es.net Tue Nov 10 11:07:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdJ78-0000a5-00; Tue, 10 Nov 1998 11:06:06 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdJ77-0000Zq-00; Tue, 10 Nov 1998 11:06:05 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Nov 10 14:04:05 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id OAA08632 for ; Tue, 10 Nov 1998 14:04:04 -0500 (EST) Message-ID: <36488D7F.F5F490C1@dnrc.bell-labs.com> Date: Tue, 10 Nov 1998 14:01:19 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Reed Solomon Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I've just sent a copy of the Reed Solomon FEC draft to the archives. This draft is the result of splitting the Reed Solomon stuff from the main FEC draft. Until the draft appears in the archives, you can find a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-reedsolomon-00.txt Comments welcome. Input from Reed Solomon experts is also much appreciated. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Nov 10 12:49:22 1998 From rem-conf-request@es.net Tue Nov 10 12:49:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdKfs-0002FC-00; Tue, 10 Nov 1998 12:46:04 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdKfq-0002F2-00; Tue, 10 Nov 1998 12:46:03 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Nov 10 15:44:15 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA12396 for ; Tue, 10 Nov 1998 15:44:13 -0500 (EST) Message-ID: <3648A4F8.38B5F4CA@dnrc.bell-labs.com> Date: Tue, 10 Nov 1998 15:41:28 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Yet another one.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, As per the discussion at the last meeting, I have taken all of the SSRC sampling stuff and put it into a new draft, for experimental track. I've submitted it to the archives. Until it appears, you can find a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-rtpsample-01.txt Comments welcome. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Nov 10 13:16:36 1998 From rem-conf-request@es.net Tue Nov 10 13:16:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdL7O-00034Z-00; Tue, 10 Nov 1998 13:14:30 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp [133.82.241.137] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdL7L-00034P-00; Tue, 10 Nov 1998 13:14:27 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp (yozo@localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.9.1/8.9.1) with ESMTP id GAA28741 for ; Wed, 11 Nov 1998 06:07:18 +0900 (JST) Message-Id: <199811102107.GAA28741@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: vic-2.8 problem. Date: Wed, 11 Nov 1998 06:07:18 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I join the session "Places all over the World" and send "view from IPC, Chiba Univ." but I have a problem. vic-2.8 often dumps core. looks like it stops the same place always inside tclNotify.c (see below). anyone experince the same problem? my environment is SS20+Solaris2.5.1 with sunvideo, adding two lines to /etc/system: > ** two lines added for vic with sunvideo work well > ** -- yozo. Tue May 26 15:44:30 JST 1998 > set shmsys:shminfo_shmmax=2097152 > set shmsys:shminfo_shmseg=24 -- yozo. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Script started on Wed Nov 11 05:56:24 1998 aohakobe:yozo% l core -rw-r--r-- 1 yozo staff 12155440 Nov 11 04:01 core aohakobe:yozo% file core core: ELF 32-bit MSB core file SPARC Version 1, from 'vic-2.8' aohakobe:yozo% gdb `which vic-2.8` core GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.5.1"... Core was generated by `vic -C Places all over the World -t 127 224.2.172.238/51482'. Program terminated with signal 11, Segmentation Fault. Reading symbols from /usr/lib/libintl.so.1...done. Reading symbols from /usr/openwin/lib/libXext.so.0...done. Reading symbols from /usr/openwin/lib/libX11.so.4...done. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libw.so.1...done. Reading symbols from /usr/lib/libmp.so.1...done. #0 0xe97e4 in Tcl_DoOneEvent (flags=1) at ./../generic/tclNotify.c:578 ./../generic/tclNotify.c:578: No such file or directory. (gdb) where #0 0xe97e4 in Tcl_DoOneEvent (flags=1) at ./../generic/tclNotify.c:578 #1 0xc in ?? () Cannot access memory at address 0x149c. (gdb) quit aohakobe:yozo% exit script done on Wed Nov 11 05:57:14 1998 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From rem-conf Tue Nov 10 13:37:51 1998 From rem-conf-request@es.net Tue Nov 10 13:37:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdLQo-0003me-00; Tue, 10 Nov 1998 13:34:34 -0800 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdLQn-0003mU-00; Tue, 10 Nov 1998 13:34:33 -0800 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id PAA03367 for ; Tue, 10 Nov 1998 15:34:32 -0600 (CST) Comments: ( Received on ftpbox.mot.com from client mothost.mot.com, sender ccof59@lmpsil02.comm.mot.com ) Received: from s-il02-d.comm.mot.com (s-il02-d.comm.mot.com [145.1.204.14]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id PAA04854 for ; Tue, 10 Nov 1998 15:34:32 -0600 (CST) Received: by s-il02-d.comm.mot.com with Internet Mail Service (5.5.2232.9) id ; Tue, 10 Nov 1998 15:32:43 -0600 Message-ID: From: Avasthi Pradeep-CCOF59 To: rem-conf@es.net Subject: RTP. Date: Tue, 10 Nov 1998 15:32:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I am experimenting with the ways to optimize the network bandwidth usage. I am looking at protocol header (UDP/IP) compression as a possible area to explore. I am hoping someone in this news group can help me with the following questions. I know of some network vendors that support RTP/UDP/IP compression on the network between links. Does anyone know any network equipment implementation that supports UDP/IP compression without having to use RTP? Using RTP may not by itself be such a bad thing if I can achieve the RTP/UDP/IP compression for 40 bytes down to 2-5 bytes. However I am concerned that having to use RTCP in conjunction with RTP may defeat the purpose somewhat. If I end up having to use RTP, is the implementation of RTCP mandatory? In a controlled network, when none of the hosts generate RTCP traffic, is there a danger of a network router or a bridge abrogating packet distribution to the members of a multicast group simply because the member did not send required RTCP packet? Thanks and regards. Pradeep Avasthi Control Centers Engineering Motorola/CE/CGISS/RNSG E-mail: CCOF59@email.mot.com Phone: (847) 576-4413 Fax : (847) 576-0510 Pgr : (800) Sky Page (PIN 447-5322) From rem-conf Tue Nov 10 13:52:40 1998 From rem-conf-request@es.net Tue Nov 10 13:52:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdLdI-0004QE-00; Tue, 10 Nov 1998 13:47:28 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdLdG-0004Pw-00; Tue, 10 Nov 1998 13:47:27 -0800 Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA15110; Tue, 10 Nov 1998 16:47:22 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3648B46A.421E4127@cs.columbia.edu> Date: Tue, 10 Nov 1998 16:47:22 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Avasthi Pradeep-CCOF59 CC: rem-conf@es.net Subject: Re: RTP. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Avasthi Pradeep-CCOF59 wrote: > > Hello, > > > Using RTP may not by itself be such a bad thing if I can achieve the > RTP/UDP/IP compression for 40 bytes down to 2-5 bytes. However I am > concerned that having to use RTCP in conjunction with RTP may defeat the > purpose somewhat. It is not clear to me why the 5% overhead induced by RTCP would have any significant bearing on your bandwidth usage. That said, I doubt that any applications refuse your packets if you don't send RTCP SR. (They shouldn't.) From rem-conf Tue Nov 10 14:23:35 1998 From rem-conf-request@es.net Tue Nov 10 14:23:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdMAD-0005NN-00; Tue, 10 Nov 1998 14:21:29 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdMAB-0005NC-00; Tue, 10 Nov 1998 14:21:28 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id RAA15007; Tue, 10 Nov 1998 17:21:22 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rem-conf@es.net Subject: Guidelines for writers of RTP payload format specifications Date: Tue, 10 Nov 1998 17:21:22 -0500 Message-ID: <15005.910736482@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A slightly revised draft of "Guidelines for writers of RTP payload format specifications" is now available from: http://north.east.isi.edu/~mjh/rtp-guidelines.txt http://north.east.isi.edu/~mjh/rtp-guidelines.ps If I get no additional comments or suggestions this week I'm going to send it to the ID editor and ask for a WG last call to be issued on it for Informational RFC status. Cheers, Mark From rem-conf Wed Nov 11 04:37:12 1998 From rem-conf-request@es.net Wed Nov 11 04:37:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdZOm-00039C-00; Wed, 11 Nov 1998 04:29:24 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdZOl-000391-00; Wed, 11 Nov 1998 04:29:23 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 11 Nov 1998 12:28:52 +0000 To: Avasthi Pradeep-CCOF59 cc: rem-conf@es.net Subject: Re: RTP. In-reply-to: Your message of "Tue, 10 Nov 1998 15:32:41 CST." Date: Wed, 11 Nov 1998 12:28:51 +0100 Message-ID: <1049.910787331@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Avasthi Pradeep-CCOF59 writes: >Hello, > >I am experimenting with the ways to optimize the network bandwidth usage. I >am looking at protocol header (UDP/IP) compression as a possible area to >explore. I am hoping someone in this news group can help me with the >following questions. > >I know of some network vendors that support RTP/UDP/IP compression on the >network between links. Does anyone know any network equipment implementation >that supports UDP/IP compression without having to use RTP? My understanding of the RTP header compression scheme is that it tries to compress a stream as RTP/UDP/IP, but failing that falls back to UDP/IP compression. >Using RTP may not by itself be such a bad thing if I can achieve the >RTP/UDP/IP compression for 40 bytes down to 2-5 bytes. However I am >concerned that having to use RTCP in conjunction with RTP may defeat the >purpose somewhat. > >If I end up having to use RTP, is the implementation of RTCP mandatory? In a >controlled network, when none of the hosts generate RTCP traffic, is there a >danger of a network router or a bridge abrogating packet distribution to the >members of a multicast group simply because the member did not send required >RTCP packet? A route or bridge shouldn't care about this, however there are some existing applications (eg: conferencing tools) which don't accept RTP packets until an RTCP packet has been received for that source. Colin From rem-conf Wed Nov 11 06:07:31 1998 From rem-conf-request@es.net Wed Nov 11 06:07:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdasv-0004FW-00; Wed, 11 Nov 1998 06:04:37 -0800 Received: from sumo.vocaltec.co.il [199.203.72.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdasr-0004FF-00; Wed, 11 Nov 1998 06:04:34 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id QAA05363 for ; Wed, 11 Nov 1998 16:01:49 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566B9.004D7732 ; Wed, 11 Nov 1998 16:06:07 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: rem-conf@es.net Message-ID: <422566B8.00394A26.00@il4.vocaltec.co.il> Date: Wed, 11 Nov 1998 16:01:46 +0200 Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [hoping that email is now working in this company. Thanks Jonathan for pointing out to me that this did not go everywhere] I'm sorry if I was not clear in stating my solution: To take Jonathan's example, when a French phone calls an American phone, two possible things might happen in my "solution": 1. The American gateway could encode the *tone cadence* which is appropriate for America into RTP (1Khz in Jonathan's toy example). This RTP would arrive at the French PSTN gateway, which would then translate the RTP into audio waveforms, so that the French phone caller would hear an true "American" ringing tone. This is what is usually desired, and almost always done in the current PSTN. (It is done this way so that when Americans call home from France they will get the familiar ringing sound). 2. The American gateway could encode the *shortcut* which is appropriate for America into RTP. The RTP octet for "RING" will be sent back by the American gateway, and then the calling French gateway will probably translate this into a French ring tone. We can debate endlessly which is "better", but that is a very stupid debate. (well let's just say that that is a debate which is best left to other standards bodies ;-)). What is smart is to say that we need to be able to provide both functions, in a way which is interoperable, efficient, and network-friendly. So I believe that the RTP "telephony audio control payload" needs to contain both "shortcuts" and "tone cadences". This will allow a remote system to pass back a payload which says "RING" if it wants, and such a payload will then be played out by the local gateway in accordance with the local gateway's rules. But it will also allow a remote system to pass back a payload which says "play a 1Khz tone for .5 seconds, then silence for 1 second, then a 1Khz tone for .5 seconds...." Such a payload would have to be played out as pure audio tones. One advantage (among many) of allowing the tone cadences is that maybe (just maybe) the list of shortcuts specified in SGCP is missing something. Experience with CTI has shown that the simple audio cadence stuff is simple enough to specify any needed tones. BTW, It is a *very* bad idea to send the audio tone cadences as "ordinary" audio (say G.723 or GSM or whatever). It is much more efficient and will lead to much better audio quality if the audio tone cadences are sent by a payload which is basically a sequence of triples (frequency, duration, energy). In the current worldwide phone system, tones such as "ringing" and "busy" are almost always generated at the far answering end, and they are passed back as audio tones. This means that when a call is made from an American phone to a Israeli phone, the caller will hear "Israeli" ringing tones or busy tones. We can argue whether this is good or bad, but it is what usually happens. Maybe the Israeli who is calling home from an American phone really expects to hear an Israeli ringing tone. But on the other hand, if the number is out of service, the American caller from the American phone will hear "Bezek shalom; ha-mispar eilav chiyyagta eino m'chubar". This is not always helpful to the caller from the American phone. The PSTN is not entirely uniform on what happens. There are situations where some sort of "error code" will be passed back, and the switch which is local to the caller will play a local tone or prompt. The original SGCP draft contained only "shortcuts", so clearly people think that it is useful to have them. But although I would never accuse either author of SGCP of being American, to have only shortcuts is a very American thing to do -- it assumes that the "RING" or "busy" or "Fast busy" tones are the same the world over. (Or at the very least that the caller's gateway gets to decide what the actual audio waveforms should be.) This is not how it works in international calls. Some "foreigners" (i.e. non Americans) are not going to like the fact that there is only one "RING" tone, etc. Having both really creates no interoperability problem at all, and certainly increases the "international" useability of this "telephony audio control" payload type. Scott Jonathan Rosenberg on 11/09/98 05:44:24 PM To: Scott Petrack cc: Henning Schulzrinne , rem-conf@es.net, magnells@dialogic.com Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Scott Petrack wrote: > > 2. The problem is that all those tones are totally different physical tones > (i.e. frequencies, durations, etc) in different parts of the world. For > example, "ringing" in France sounds a bit like "busy" in America. > > This is not at all an impossible problem to solve, in fact it is relatively > straightforward. There needs to be the possibility to express some simple > "tone cadences" in this payload type. Basically it is enough to define a > payload where each frame specifies a set of (frequency, energy, duration) > triples to be played. The magic of RTP can then be used to specify very > effeciently whatever network tones are needed. I don't see how this solves it. Lets say, for arguments sake, a ringing is a 1khz tone in the US, and 2khz in France. Now, if a US RTP system encodes the ringing as 1khz, this won't be played properly in France. Perhaps I'm misunderstanding your solution? Use of what you call "shortcuts" will solve this problem, though. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Nov 11 06:50:57 1998 From rem-conf-request@es.net Wed Nov 11 06:50:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdbb7-0005BQ-00; Wed, 11 Nov 1998 06:50:17 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdbb5-00059l-00; Wed, 11 Nov 1998 06:50:15 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA01018; Wed, 11 Nov 1998 09:49:08 -0500 (EST) Message-Id: <199811111449.JAA01018@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-reedsolomon-00.txt Date: Wed, 11 Nov 1998 09:49:08 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for Reed Solomon Codes Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-reedsolomon-00.txt Pages : 12 Date : 10-Nov-98 This document specifies a payload format for forward error correction of media encapsulated in RTP using Reed Solomon codes. The payload format allows end systems to transmit using arbitrary block lengths and codes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. Internet-Drafts are 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-reedsolomon-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-reedsolomon-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-reedsolomon-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: <19981110175850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-reedsolomon-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-reedsolomon-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981110175850.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Nov 11 06:50:57 1998 From rem-conf-request@es.net Wed Nov 11 06:50:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdba6-00059j-00; Wed, 11 Nov 1998 06:49:14 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdba4-00059Z-00; Wed, 11 Nov 1998 06:49:13 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id JAA16274; Wed, 11 Nov 1998 09:45:36 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Scott Petrack cc: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? In-reply-to: Your message of "Wed, 11 Nov 1998 16:01:46 +0200." <422566B8.00394A26.00@il4.vocaltec.co.il> Date: Wed, 11 Nov 1998 09:45:36 -0500 Message-ID: <16272.910795536@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >To take Jonathan's example, when a French phone calls an American phone, >two possible things might happen in my "solution": > >1. The American gateway could encode the *tone cadence* which is >appropriate for America into RTP (1Khz in Jonathan's toy example). This RTP >would arrive at the French PSTN gateway, which would then translate the RTP >into audio waveforms, so that the French phone caller would hear an true >"American" ringing tone. This is what is usually desired, and almost always >done in the current PSTN. (It is done this way so that when Americans call >home from France they will get the familiar ringing sound). > >2. The American gateway could encode the *shortcut* which is appropriate >for America into RTP. The RTP octet for "RING" will be sent back by the >American gateway, and then the calling French gateway will probably >translate this into a French ring tone. Why do you want these signalling messages to be sent by RTP rather than by SIP/H.323/whatever? Now writing a spec on encoding of tone cadence in a SIP "180 RINGING" body (or header field) would seem to be a useful piece of work. I can see the reason for DTMF for other purposes during a call, but why for signalling call status? I suppose that when I'm calling someone's PBX, get put on hold (and get whatever music they decide on), then get a ringing tone when finally a line becomes free, then it might be appropriate. However, then the gateway needs to be smart and make a content-based decision on whether to send "tone-codec" or "voice-codec". Is this a reasonable thing for a gateway to be able to decide correctly given than the remote end can pretty much generate any sounds? Cheers, Mark From rem-conf Wed Nov 11 06:51:03 1998 From rem-conf-request@es.net Wed Nov 11 06:51:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdbam-0005A1-00; Wed, 11 Nov 1998 06:49:56 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdbak-00059J-00; Wed, 11 Nov 1998 06:49:54 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA00991; Wed, 11 Nov 1998 09:48:50 -0500 (EST) Message-Id: <199811111448.JAA00991@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-fec-04.txt Date: Wed, 11 Nov 1998 09:48:50 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for Generic Forward Error Correction Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fec-04.txt Pages : 19 Date : 10-Nov-98 This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the pay- load and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. Internet-Drafts are 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-fec-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-fec-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-fec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981110175242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981110175242.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Nov 11 06:51:21 1998 From rem-conf-request@es.net Wed Nov 11 06:51:20 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdbbj-0005Bl-00; Wed, 11 Nov 1998 06:50:55 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdbbi-00059q-00; Wed, 11 Nov 1998 06:50:54 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA01057; Wed, 11 Nov 1998 09:49:50 -0500 (EST) Message-Id: <199811111449.JAA01057@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtpsample-01.txt Date: Wed, 11 Nov 1998 09:49:50 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : Sampling of the Group Membership in RTP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtpsample-01.txt Pages : 11 Date : 10-Nov-98 In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. Internet-Drafts are 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-rtpsample-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtpsample-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtpsample-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981110182003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtpsample-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtpsample-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981110182003.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Nov 11 08:15:53 1998 From rem-conf-request@es.net Wed Nov 11 08:15:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdcmw-0000F6-00; Wed, 11 Nov 1998 08:06:34 -0800 Received: from smtprtp.nortel.com (smtprtp) [192.122.117.66] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdcmu-0000Ew-00; Wed, 11 Nov 1998 08:06:32 -0800 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp; Wed, 11 Nov 1998 11:05:43 -0500 Received: from zrtpd00x.us.nortel.com by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id WWNXBVP9; Wed, 11 Nov 1998 11:05:39 -0500 Received: from nrtphf51.us.nortel.com by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id V64J3C0P; Wed, 11 Nov 1998 11:05:39 -0500 Sender: "Chris Fulmer" Message-ID: <3649B5D2.50727BF7@americasm01.nt.com> Date: Wed, 11 Nov 1998 11:05:38 -0500 From: "Chris Fulmer" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778) MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? References: <16272.910795536@north.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark Handley wrote: > > Why do you want these signalling messages to be sent by RTP rather > than by SIP/H.323/whatever? Now writing a spec on encoding of tone > cadence in a SIP "180 RINGING" body (or header field) would seem to be > a useful piece of work. One thing to consider is the case where the receiver is a computer, with no human directly involved. It seems to me that you don't really want the computer to have to know about all the different tones used for "Dial tone" all around the world. -- Chris Fulmer Nortel, Ltd RTP, NC These opinions do not necessarily reflect those of my employer. From rem-conf Wed Nov 11 10:08:00 1998 From rem-conf-request@es.net Wed Nov 11 10:07:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdecq-0001m4-00; Wed, 11 Nov 1998 10:04:16 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdecp-0001lu-00; Wed, 11 Nov 1998 10:04:15 -0800 Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id KAA19719 for ; Wed, 11 Nov 1998 10:04:14 -0800 (PST) Message-Id: <199811111804.KAA19719@gumby.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 From: "Larry Rowe" To: rem-conf@es.net Subject: [REMINDER] Berkeley MIG Seminar Today Reply-To: Rowe@bmrc.berkeley.edu Mime-Version: 1.0 Content-Type: text/enriched; charset=us-ascii Date: Wed, 11 Nov 1998 10:04:14 -0800 Sender: larry@bmrc.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Building a Platform for Online Education and Collaboration (Wednesday November 11, 1998 12:30-2:00 PDT 405 Soda Hall) Anoop Gupta (Microsoft Research ) The demands placed on our higher-education system are rapidly changing. We expect a significant increase in enrollments for professional courses as life-long learning becomes both necessary and pervasive. Furthermore, the learners will demand anytime/anywhere access to the content, they will want the content personalized to meet their specific needs, and the content delivery to match the learning style that works best for them. Most importantly, such education must be delivered at a much lower cost than what we find today. Achieving these goals of scalability, access flexibility, and cost-effectiveness while maintaining educational excellence will not be simple. It will require us to re-think how we educate and to use technology aggressively though judiciously to create leverage. I believe that many of the core technology and infrastructure components for supporting this future vision are already in place today. However, for applications built on these technologies to be successful for the education community, we need to research and understand what are the special needs of learners/instructors, what aspects/activities (e.g., roles/types of collaboration, support for community formation/sustenance) are critical to learners, what is best done by technology and what is best left to humans. We need to build and deploy prototypes in educational environments and conduct studies to understand the issues deeply. The talk will cover issues in use of technology for education and collaboration, including description and demonstration of some projects started recently at Microsoft Research. From rem-conf Wed Nov 11 13:02:56 1998 From rem-conf-request@es.net Wed Nov 11 13:02:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdhLC-0003un-00; Wed, 11 Nov 1998 12:58:14 -0800 Received: from alphatje.nl.net [193.78.240.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdhLB-0003ud-00; Wed, 11 Nov 1998 12:58:13 -0800 Received: from ldn52-21.Leiden.NL.net ([212.206.213.22]:18436 "HELO firebal" ident: "NO-IDENT-SERVICE[2]") by alphatje.NL.net with SMTP id <230439-29451>; Wed, 11 Nov 1998 21:57:14 +0100 From: "Gerard" To: Subject: RE: RTP. Date: Wed, 11 Nov 1998 21:57:57 +0100 Message-ID: <000901be0db6$5b34f9c0$16d5ced4@firebal> 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 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Avasthi, We've done testing RTP/UDP/IP header compression with Cisco equipment (IOS 11.3). This header compression brings us a lot of extra bandwith on ISDN lines. You don't need RTCP to get this header compression working. In fact the compression is straight forward and can even work one way. The only thing which was not in place is the PPP negotation. Gerard Niersman BTW. Which other vendor support this header compression ? -----Oorspronkelijk bericht----- Van: Avasthi Pradeep-CCOF59 [mailto:ccof59@lmpsil02.comm.mot.com] Verzonden: dinsdag 10 november 1998 22:33 Aan: rem-conf@es.net Onderwerp: RTP. Hello, I am experimenting with the ways to optimize the network bandwidth usage. I am looking at protocol header (UDP/IP) compression as a possible area to explore. I am hoping someone in this news group can help me with the following questions. I know of some network vendors that support RTP/UDP/IP compression on the network between links. Does anyone know any network equipment implementation that supports UDP/IP compression without having to use RTP? Using RTP may not by itself be such a bad thing if I can achieve the RTP/UDP/IP compression for 40 bytes down to 2-5 bytes. However I am concerned that having to use RTCP in conjunction with RTP may defeat the purpose somewhat. If I end up having to use RTP, is the implementation of RTCP mandatory? In a controlled network, when none of the hosts generate RTCP traffic, is there a danger of a network router or a bridge abrogating packet distribution to the members of a multicast group simply because the member did not send required RTCP packet? Thanks and regards. Pradeep Avasthi Control Centers Engineering Motorola/CE/CGISS/RNSG E-mail: CCOF59@email.mot.com Phone: (847) 576-4413 Fax : (847) 576-0510 Pgr : (800) Sky Page (PIN 447-5322) From rem-conf Wed Nov 11 13:46:22 1998 From rem-conf-request@es.net Wed Nov 11 13:46:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdi4T-0004p3-00; Wed, 11 Nov 1998 13:45:01 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdi4S-0004or-00; Wed, 11 Nov 1998 13:45:00 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id QAA17268; Wed, 11 Nov 1998 16:44:59 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rem-conf@es.net Subject: Generic RTP Multiplexing Date: Wed, 11 Nov 1998 16:44:59 -0500 Message-ID: <17266.910820699@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've written up the Generic RTP Multiplexing ideas I presented at the last IETF. The draft will be on the ID sites in a few days, but for now you can get it from: ASCII: http://north.east.isi.edu/~mjh/draft-ietf-avt-germ-00.txt Postscript: http://north.east.isi.edu/~mjh/draft-ietf-avt-germ-00.ps Cheers, Mark From rem-conf Thu Nov 12 03:14:45 1998 From rem-conf-request@es.net Thu Nov 12 03:14:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zducx-0002X5-00; Thu, 12 Nov 1998 03:09:27 -0800 Received: from sumo.vocaltec.co.il [199.203.72.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zducr-0002Wv-00; Thu, 12 Nov 1998 03:09:23 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id NAA24442; Thu, 12 Nov 1998 13:06:16 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566BA.003D680B ; Thu, 12 Nov 1998 13:10:43 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: Mark Handley cc: rem-conf@es.net Message-ID: <422566BA.00271E0B.00@il4.vocaltec.co.il> Date: Thu, 12 Nov 1998 13:06:16 +0200 Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark Handley wrote: >Why do you want these signalling messages to be sent by RTP rather >than by SIP/H.323/whatever? This issue was discussed ad infinitum et nauseum in the VoIP forum about 18 months ago, I'll try to summarize the discussion here: These are not signalling messages, these are "audio media segments" which happen to convey some information to the remote listner, in the same way that other audio media conveys some information to the remote listner. The requirement is to transport these audio media segments among telephone terminals and gateways in a way which is efficent, network friendly, and enables synchronization with respect to other elements in the audio stream. The solution is an RTP payload format. I can certainly imagine a world where such tones as DTMF, fast busy, ringing, etc. can exist only as pure signals, and maybe SIP will be a part of this process (if somehow a SIP spec ever gets out the door ;-)), but in the meantime those of us who are bridging telephone networks to the Internet need a way to transport such *realtime audio* as dtmf tones, ringing, busy, fast busy, etc. over IP. Here are a few quick examples of cases where the tones used as signalling need to have time-stamps and/or be synchronized with other parts of the media stream. If they are not convincing, I will resurrect some old VoIP forum documents. a) When I connect to a telephone answering machine, I can press digits or "*" or "#" to manipulate the recording or playback. Often it is essential that the keypresses be synchronized with ingoing or outgoing audio, or disasters can result. The requirement that the DTMF tones sometimes need to be synchronized with the audio coming from the other side as well leads to a requirement for global synchronization. (such as when you get a prompt like "Press 3 to save the message". If you don't press the 3 within a set number of seconds, serious problems can result). b) Standard telephone protocols are full of very strict timers. In order to interwork with these protocols, it is often useful or necessary to know exactly when the handset was raised, or a digit dialed, etc. An example would be in overlap dialling (i.e. when you dial the digits "one at a time"). In order for the gateway/switch to be able to decide if you have finished dialing a number, it needs to measure a certain precise time from the last keypress. In addition, one of the very practical problems that occurs in trying to separate "signalling gateways" from "media gateways" is what to do about all those audio media tones that might convey information needed by the signalling gateway. Hence the subject of the transport of this "media signalling" information came up, and the only way to ensure a decent translation of these media events at gateways is if the events contain timestamps, can be delivered in order and can be synchronized with other audio. >Now writing a spec on encoding of tone >cadence in a SIP "180 RINGING" body (or header field) would seem to be >a useful piece of work. I agree with you, and I have the answer prepared: Once the RTP payload is complete and correct, we need a MIME type for audio/RTP (if such a subtype does not already exist). Such an audio/RTP payload can be included within the message. Once nice feature of doing it this way is that if it makes sense the message might encode the tone cadence as audio/wav or some other audio sub-type if that makes sense. There are many issues that need to be thrased out here, related to the whole rathole of whether we need to define some "file format" for RTP streams. (In any case we will need some way to signal the dynamic payloads that are in such an audio/RTP payload). Let's save these ratholes for AFTER we do the actually essential piece of work, which is how to transport all these telephony audio signals via IP. The more messianic stuff (i.e. how to transport this in SIP) can wait until SIP actually exists. If we do our RTP work correctly, the answer will be very simple. >I can see the reason for DTMF for other purposes during a call, but >why for signalling call status? Because that's the way that 950 million terminals on the PSTN do it today, and I for one would like to connect these rather unfortunate beasts to the Internet. Remember, my goal is not really to "signal call status" (in the sense of "signal" == convey state information from one host to another), but rather just how to get the PSTN gateway to play out the right audio. >I suppose that when I'm calling someone's PBX, get put on hold (and >get whatever music they decide on), then get a ringing tone when >finally a line becomes free, then it might be appropriate. However, >then the gateway needs to be smart and make a content-based decision >on whether to send "tone-codec" or "voice-codec". Is this a >reasonable thing for a gateway to be able to decide correctly given >than the remote end can pretty much generate any sounds? In the scheme you suggest (which is to put such tone cadences into SIP or H.323), the gateway must also make a "content-based decision" to recognize DTMF, etc. within the audio and encode it into SIP or H.245. Indeed every gateway or PBX has the ability to detect such tones. All I am saying is that there are many applications where it is appropriate to transport the information within an RTP payload. The standard "non RTP means" (i.e. SIP/SDP or H.245) would be used to allow the gateway to determine if the remote side can understand the RTP payload, and if it can, then indeed the gateway will need intelligence to determine what is the right way to transport. The only scheme which requires no "content-based decision" is one where the tones are passed through as is. Several years of experience (including with cell phones as well as IP telephony) have pretty much proved that this is a bad idea. Scott Scott From rem-conf Thu Nov 12 07:49:53 1998 From rem-conf-request@es.net Thu Nov 12 07:49:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdyqC-0004aG-00; Thu, 12 Nov 1998 07:39:24 -0800 Received: from smtprtp.nortel.com (smtprtp) [192.122.117.66] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zdyoI-0004Z2-00; Thu, 12 Nov 1998 07:37:27 -0800 Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprtp; Thu, 12 Nov 1998 10:36:38 -0500 Received: from zrtpd00x.us.nortel.com by zrtpd00m.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id WQGMSQPC; Thu, 12 Nov 1998 10:36:32 -0500 Received: from nrtphf51.us.nortel.com by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id V64J314L; Thu, 12 Nov 1998 10:36:32 -0500 Sender: "Chris Fulmer" Message-ID: <364B0080.4B857FE1@americasm01.nt.com> Date: Thu, 12 Nov 1998 10:36:32 -0500 From: "Chris Fulmer" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778) MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? References: <422566BA.00271E0B.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm a little confused here. Is your argument for including non-DTMF tones in a seperate payload that because those tones exist in the PSTN, we need to transfer them via RTP, and thus we need a seperate payload format? I would make the argument that as long as you don't want to have the tones automatically detected by a host, that you can just compress them along with the voice -- the reason that DTMF is interesting (at least from my point of view -- I'd be interested in hearing others) is that compressing DTMF via G.723, G.729 or whatever can lead to something which is not recognizable as DTMF on the other end. For the rest of the tones you're talking about (Busy, Fast Busy, Dial, etc...), it's a person who's doing the recognizing, and they have a much higher tolerance for compression. Now, it's possible to make a bit of a point that there are other non-DTMF tones that need to be recognized. For example, although not much used any more, pay-phone 'bong' tones. In fact, there are a lot of such tones out there -- at one time, pretty much all PSTN signalling was in-band. I would argue, though, that the decision on whether or not to support all these tones needs to be made seperately. There's also the question of modem tones, fax tones, and so on. For fax, the industry appears to be dealing with this seperately. Your last paragraph implies that you don't think just passing the tones through is a good idea. I'm curious -- why? -- C Scott Petrack wrote: > Mark Handley wrote: > > >Why do you want these signalling messages to be sent by RTP rather > >than by SIP/H.323/whatever? > > This issue was discussed ad infinitum et nauseum in the VoIP forum about 18 > months ago, I'll try to summarize the discussion here: > > These are not signalling messages, these are "audio media segments" which > happen to convey some information to the remote listner, in the same way > that > other audio media conveys some information to the remote listner. > The requirement is to transport these audio media segments among telephone > terminals and gateways in a way which is efficent, network friendly, and > enables synchronization with respect to other elements in the audio stream. > The solution is an RTP payload format. > > I can certainly imagine a world where such tones as DTMF, fast busy, > ringing, etc. can exist only as pure signals, and maybe SIP will be a part > of this process (if somehow a SIP spec ever gets out the door ;-)), but in > the meantime those of us who are bridging telephone networks to the > Internet need a way to transport such *realtime audio* as dtmf tones, > ringing, busy, fast busy, etc. over IP. > > Here are a few quick examples of cases where the tones used as signalling > need to have time-stamps and/or be synchronized with other parts of the > media stream. If they are not convincing, I will resurrect some old VoIP > forum documents. > > a) When I connect to a telephone answering machine, I can press digits or > "*" or "#" to manipulate the recording or playback. Often it is essential > that the keypresses be synchronized with ingoing or outgoing audio, or > disasters can result. The requirement that the DTMF tones sometimes need to > be synchronized with the audio coming from the other side as well leads to > a requirement for global synchronization. (such as when you get a prompt > like "Press 3 to save the message". If you don't press the 3 within a set > number of seconds, serious problems can result). > b) Standard telephone protocols are full of very strict timers. In order to > interwork with these protocols, it is often useful or necessary to know > exactly when the handset was raised, or a digit dialed, etc. An > example would be in overlap dialling (i.e. when you dial the digits "one at > a time"). In order for the gateway/switch to be able to decide if you have > finished dialing a number, it needs to measure a certain precise time from > the last keypress. > > In addition, one of the very practical problems that occurs in trying to > separate "signalling gateways" from "media gateways" is what to do about > all those audio media tones that might convey information needed by the > signalling gateway. Hence the subject of the transport of this "media > signalling" information came up, and the only way to ensure a decent > translation of these media events at gateways is if the events contain > timestamps, can be delivered in order and can be synchronized with other > audio. > > >Now writing a spec on encoding of tone > >cadence in a SIP "180 RINGING" body (or header field) would seem to be > >a useful piece of work. > > I agree with you, and I have the answer prepared: Once the RTP > payload is complete and correct, we need a MIME type for audio/RTP (if such > a subtype does not already exist). Such an audio/RTP payload can be > included within the message. Once nice feature of doing it this way is that > if it makes sense the message might encode the tone cadence as audio/wav or > some other audio sub-type if that makes sense. > > There are many issues that need to be thrased out here, related to the > whole rathole of whether we need to define some "file format" for RTP > streams. (In any case we will need some way to signal the dynamic payloads > that are in such an audio/RTP payload). Let's save these ratholes for AFTER > we do the actually essential piece of work, which is how to transport all > these telephony audio signals via IP. The more messianic stuff (i.e. how to > transport this in SIP) can wait until SIP actually exists. If we do our RTP > work correctly, the answer will be very simple. > > >I can see the reason for DTMF for other purposes during a call, but > >why for signalling call status? > > Because that's the way that 950 million terminals on the PSTN do it today, > and I for one would like to connect these rather unfortunate beasts to the > Internet. Remember, my goal is not really to "signal call status" (in the > sense of "signal" == convey state information from one host to another), > but rather just how to get the PSTN gateway to play out the right audio. > > >I suppose that when I'm calling someone's PBX, get put on hold (and > >get whatever music they decide on), then get a ringing tone when > >finally a line becomes free, then it might be appropriate. However, > >then the gateway needs to be smart and make a content-based decision > >on whether to send "tone-codec" or "voice-codec". Is this a > >reasonable thing for a gateway to be able to decide correctly given > >than the remote end can pretty much generate any sounds? > > In the scheme you suggest (which is to put such tone cadences into SIP or > H.323), the gateway must also make a "content-based decision" to recognize > DTMF, etc. within the audio and encode it into SIP or H.245. Indeed every > gateway or PBX has the ability to detect such tones. > > All I am saying is that there are many applications where it is appropriate > to transport the information within an RTP payload. The standard "non RTP > means" (i.e. SIP/SDP or H.245) would be used to allow the gateway to > determine if the remote side can understand the RTP payload, and if it can, > then indeed the gateway will need intelligence to determine what is the > right way to transport. > > The only scheme which requires no "content-based decision" is one where the > tones are passed through as is. Several years of experience (including with > cell phones as well as IP telephony) have pretty much proved that this is a > bad idea. > > Scott -- Chris Fulmer Nortel, Ltd RTP, NC From rem-conf Thu Nov 12 11:38:47 1998 From rem-conf-request@es.net Thu Nov 12 11:38:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zdzQm-0004yj-00; Thu, 12 Nov 1998 08:17:12 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zdz7P-0004kx-00; Thu, 12 Nov 1998 07:57:11 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 12 Nov 1998 15:57:06 +0000 To: rem-conf@es.net Subject: AVT working group at the Orlando IETF Date: Thu, 12 Nov 1998 15:57:05 +0100 Message-ID: <5037.910886225@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The audio/video transport working group has two slots scheduled for the Orlando IETF: Wednesday, December 9 at 0900-1130 Thursday, December 10 at 1300-1500 Requests for agenda slots should be sent to me or Steve as soon as possible. Colin From rem-conf Thu Nov 12 14:31:20 1998 From rem-conf-request@es.net Thu Nov 12 14:31:19 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ze5AL-0002ne-00; Thu, 12 Nov 1998 14:24:37 -0800 Received: from nobozo.cs.berkeley.edu ([128.32.34.58]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0ze5AK-0002nU-00; Thu, 12 Nov 1998 14:24:36 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id OAA32499; Thu, 12 Nov 1998 14:24:35 -0800 (PST) Message-Id: <3.0.3.32.19981112142434.0090c580@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 12 Nov 1998 14:24:34 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/18 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar MPEG in the Real World: How MPEG-2 is used in the Cable and Broadcast Industry Wednesday November 18, 1998 12:30-2:00 pm 405 Soda Hall Steve Smoot Imedia Inc. To many multimedia researchers, compression technology is useful for what it can do on the desktop or over the internet. However, the most extensive (and most expensive) use of compression technology is in the Broadcast and Cable industry. This talk focuses on how industry uses digital video today: - the infrastructure (where and how compression is used) - major players (who makes the equipment and who buys it) - encoding and multiplexing (how they use it) I highlight how digital video in Broadcast and Cable differs from the Internet/academic multimedia experience. Towards the end, I describe the near-term future and speculate on the long-term future - where the cable industry starts to look a lot more like the usual multimedia experience. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Fri Nov 13 01:00:59 1998 From rem-conf-request@es.net Fri Nov 13 01:00:57 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeEzO-0007Sc-00; Fri, 13 Nov 1998 00:53:58 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zeEzM-0007SK-00; Fri, 13 Nov 1998 00:53:56 -0800 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 Nov 1998 08:53:48 +0000 to: confctrl@ISI.EDU cc: rem-conf@es.net cc: J.Crowcroft@cs.ucl.ac.uk Subject: review of "Video Compression Techniques", by Effelsberg&Steinmetz Date: Fri, 13 Nov 1998 08:53:47 +0100 Message-ID: <671.910947227@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There is a new book pout called, plainly "Video Compression Techniques", by Wolfgang Effelsberg and RalfS Steinmetz, published by dpunkt (see www.dpunkt.de), ISBN 3-920993-13-6 The book is aimed at the general reader ratehr than the signal processing or EE postdoctoral expert, and is a very good read. It covers most of the material one would like to see, inclkuding a general introduction to multimedia, data compression , detailed compression techniques (interpolation, subsampling, run length, vector quanitization, LZ, Huffman, Arithmetic, transcform, subband and differential encoding, then specifics of particular still image compression techniques followed by in depth coverage of MEG 1, 2, 4 and 7, and H.261, 263, and finally a quality, and performance analysis of the various techniques and algorithms and parameter setting. The book is accompanied by a CD with software to demonstrate a lot of the ideas, There is a web site associated with the book with the software and updates, and these are quite fun - the authors are very acive researchers in this area, butr are also good educators, and I foun the book easily the best introduction and overview of the topic, as well as quite useful on some details I was hazy about. Happy reading. see http://www.kom.e-technik.tu-darmstadt.de/Research/mmbook/ and follow links... for applets etc.... From rem-conf Fri Nov 13 01:43:08 1998 From rem-conf-request@es.net Fri Nov 13 01:43:07 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeFjC-0000lu-00; Fri, 13 Nov 1998 01:41:18 -0800 Received: from hermes.research.kpn.com ([139.63.192.8]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zeFjA-0000lg-00; Fri, 13 Nov 1998 01:41:16 -0800 Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-12 #D3149) with ESMTP id <01J44EMHAJE40009Y2@research.kpn.com> for rem-conf@es.net; Fri, 13 Nov 1998 10:40:45 +0100 Received: by ntl11.research.kpn.com with Internet Mail Service (5.5.2232.9) id ; Fri, 13 Nov 1998 10:40:53 +0100 Content-return: allowed Date: Fri, 13 Nov 1998 10:40:50 +0100 From: "Koenen, R.H." Subject: RE: review of "Video Compression Techniques", by Effelsberg&Stein metz To: 'Jon Crowcroft' , confctrl@ISI.EDU Cc: rem-conf@es.net Message-id: <802140B1D018D2118EB000A02461E5B67A6815@ntl11.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > There is a new book pout called, plainly > "Video Compression Techniques", by Wolfgang Effelsberg > and RalfS Steinmetz, published by dpunkt (see www.dpunkt.de), > ISBN 3-920993-13-6 Interesting book [...] > compression techniques followed by in depth coverage of MEG 1, 2, 4 > and 7, and H.261, 263, and finally a quality, and performance analysis > of the various techniques and algorithms and parameter setting. ... MPEG-7 being the odd one out, as it isn't a compression technique but a description intended to allow search and identification of multimedia material. See http://www.cselt.it/mpeg regards, Rob ---------------- Rob Koenen, chairman MPEG Requirements Group Multimedia Technology Group, KPN Research PO Box 421, 2260 AK Leidschendam The Netherlands tel +31 70 332 5310 fax +31 70 332 5567 GSM +31 653 815 686 > The book is accompanied by a CD with software to demonstrate a lot of > the ideas, There is a web site associated with the book with the > software and updates, and these are quite fun - the authors are very > acive researchers in this area, butr are also good educators, and I > foun the book easily the best introduction and overview of the topic, > as well as quite useful on some details I was hazy about. Happy > reading. > > see > http://www.kom.e-technik.tu-darmstadt.de/Research/mmbook/ > and follow links... for applets etc.... > From rem-conf Fri Nov 13 02:37:53 1998 From rem-conf-request@es.net Fri Nov 13 02:37:51 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeGYn-0001d9-00; Fri, 13 Nov 1998 02:34:37 -0800 Received: from proxy4.ba.best.com ([206.184.139.15] ident=root) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zeGYl-0001cz-00; Fri, 13 Nov 1998 02:34:35 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy4.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id CAA07675; Fri, 13 Nov 1998 02:32:35 -0800 (PST) Message-Id: <3.0.5.16.19981113032450.2fbf8bd2@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Fri, 13 Nov 1998 03:24:50 To: rem-conf@es.net, confctrl@isi.edu From: Ross Finlayson Subject: A "sdr" source-code patch for directory sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FYI to those of you who use "sdr" as your SDP session browser: I have developed a patch to the "sdr" source code that will allow "sdr" to properly handle 'directory' SDP sessions (for instance, the "Test Sessions", "Music", "Lectures and Seminars" directories that are currently being announced). In particular, when rebuilt with this patch, "sdr" can now be used to: - launch a directory session, with each directory's contents appearing in a new window - create new session announcements (including directory session announcements) within any directory You can find this patch online at (At the very least, I hope more people will start using the "Test Sessions" directory for creating globally-visible test sessions.) Ross. From rem-conf Fri Nov 13 02:56:54 1998 From rem-conf-request@es.net Fri Nov 13 02:56:54 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeGsm-0002IV-00; Fri, 13 Nov 1998 02:55:16 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zeGsi-0002I8-00; Fri, 13 Nov 1998 02:55:12 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id MAA14977; Fri, 13 Nov 1998 12:52:06 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566BB.003C1EC2 ; Fri, 13 Nov 1998 12:56:40 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: "Chris Fulmer" cc: rem-conf@es.net Message-ID: <422566BB.003A5690.00@il4.vocaltec.co.il> Date: Fri, 13 Nov 1998 12:50:30 +0200 Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >I would >argue, though, that the decision on whether or not to support all these tones >needs to be made seperately. I agree and that is my whole point -- sometimes the right decision (however this decision is made, "separately" or not) is to send them in RTP. So for those times, when that is the right decision, we need an RTP payload format. >Your last paragraph implies that you don't think just passing the tones >through is a good idea. I'm curious -- why? Because just passing the audio tones through often creates crappy sounding audio tones. This is often very annoying to the human user listening (for example, when the user needs to distinguish if the tone is busy or ringing or fast busy). Also, there are indeed many many CTI solutions out there which do recognize the tones such as ringing or fast busy. Is this "signalling" or is the CTI solution just replacing a "human user." Yawn -- I don't really care. I just want to pass the tones in a way which will make sure they get to the other side "well". All I am claiming is that for some applications the definition of "well" means that an RTP based solution is the only one that works. This whole subject is difficult because there are many many different applications and different requirements. We will never get 20 people to agree on requirements, etc. Two years of discussion seems to suggest that whatever requirement someone might write, there will be other people with different requirements. If there are enough people who think that it would be a good thing to have this payload type, then let's just do it. Scott "Chris Fulmer" on 11/12/98 05:36:32 PM To: Scott Petrack cc: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? I'm a little confused here. Is your argument for including non-DTMF tones in a seperate payload that because those tones exist in the PSTN, we need to transfer them via RTP, and thus we need a seperate payload format? I would make the argument that as long as you don't want to have the tones automatically detected by a host, that you can just compress them along with the voice -- the reason that DTMF is interesting (at least from my point of view -- I'd be interested in hearing others) is that compressing DTMF via G.723, G.729 or whatever can lead to something which is not recognizable as DTMF on the other end. For the rest of the tones you're talking about (Busy, Fast Busy, Dial, etc...), it's a person who's doing the recognizing, and they have a much higher tolerance for compression. Now, it's possible to make a bit of a point that there are other non-DTMF tones that need to be recognized. For example, although not much used any more, pay-phone 'bong' tones. In fact, there are a lot of such tones out there -- at one time, pretty much all PSTN signalling was in-band. I would argue, though, that the decision on whether or not to support all these tones needs to be made seperately. There's also the question of modem tones, fax tones, and so on. For fax, the industry appears to be dealing with this seperately. Your last paragraph implies that you don't think just passing the tones through is a good idea. I'm curious -- why? -- C Scott Petrack wrote: > Mark Handley wrote: > > >Why do you want these signalling messages to be sent by RTP rather > >than by SIP/H.323/whatever? > > This issue was discussed ad infinitum et nauseum in the VoIP forum about 18 > months ago, I'll try to summarize the discussion here: > > These are not signalling messages, these are "audio media segments" which > happen to convey some information to the remote listner, in the same way > that > other audio media conveys some information to the remote listner. > The requirement is to transport these audio media segments among telephone > terminals and gateways in a way which is efficent, network friendly, and > enables synchronization with respect to other elements in the audio stream. > The solution is an RTP payload format. > > I can certainly imagine a world where such tones as DTMF, fast busy, > ringing, etc. can exist only as pure signals, and maybe SIP will be a part > of this process (if somehow a SIP spec ever gets out the door ;-)), but in > the meantime those of us who are bridging telephone networks to the > Internet need a way to transport such *realtime audio* as dtmf tones, > ringing, busy, fast busy, etc. over IP. > > Here are a few quick examples of cases where the tones used as signalling > need to have time-stamps and/or be synchronized with other parts of the > media stream. If they are not convincing, I will resurrect some old VoIP > forum documents. > > a) When I connect to a telephone answering machine, I can press digits or > "*" or "#" to manipulate the recording or playback. Often it is essential > that the keypresses be synchronized with ingoing or outgoing audio, or > disasters can result. The requirement that the DTMF tones sometimes need to > be synchronized with the audio coming from the other side as well leads to > a requirement for global synchronization. (such as when you get a prompt > like "Press 3 to save the message". If you don't press the 3 within a set > number of seconds, serious problems can result). > b) Standard telephone protocols are full of very strict timers. In order to > interwork with these protocols, it is often useful or necessary to know > exactly when the handset was raised, or a digit dialed, etc. An > example would be in overlap dialling (i.e. when you dial the digits "one at > a time"). In order for the gateway/switch to be able to decide if you have > finished dialing a number, it needs to measure a certain precise time from > the last keypress. > > In addition, one of the very practical problems that occurs in trying to > separate "signalling gateways" from "media gateways" is what to do about > all those audio media tones that might convey information needed by the > signalling gateway. Hence the subject of the transport of this "media > signalling" information came up, and the only way to ensure a decent > translation of these media events at gateways is if the events contain > timestamps, can be delivered in order and can be synchronized with other > audio. > > >Now writing a spec on encoding of tone > >cadence in a SIP "180 RINGING" body (or header field) would seem to be > >a useful piece of work. > > I agree with you, and I have the answer prepared: Once the RTP > payload is complete and correct, we need a MIME type for audio/RTP (if such > a subtype does not already exist). Such an audio/RTP payload can be > included within the message. Once nice feature of doing it this way is that > if it makes sense the message might encode the tone cadence as audio/wav or > some other audio sub-type if that makes sense. > > There are many issues that need to be thrased out here, related to the > whole rathole of whether we need to define some "file format" for RTP > streams. (In any case we will need some way to signal the dynamic payloads > that are in such an audio/RTP payload). Let's save these ratholes for AFTER > we do the actually essential piece of work, which is how to transport all > these telephony audio signals via IP. The more messianic stuff (i.e. how to > transport this in SIP) can wait until SIP actually exists. If we do our RTP > work correctly, the answer will be very simple. > > >I can see the reason for DTMF for other purposes during a call, but > >why for signalling call status? > > Because that's the way that 950 million terminals on the PSTN do it today, > and I for one would like to connect these rather unfortunate beasts to the > Internet. Remember, my goal is not really to "signal call status" (in the > sense of "signal" == convey state information from one host to another), > but rather just how to get the PSTN gateway to play out the right audio. > > >I suppose that when I'm calling someone's PBX, get put on hold (and > >get whatever music they decide on), then get a ringing tone when > >finally a line becomes free, then it might be appropriate. However, > >then the gateway needs to be smart and make a content-based decision > >on whether to send "tone-codec" or "voice-codec". Is this a > >reasonable thing for a gateway to be able to decide correctly given > >than the remote end can pretty much generate any sounds? > > In the scheme you suggest (which is to put such tone cadences into SIP or > H.323), the gateway must also make a "content-based decision" to recognize > DTMF, etc. within the audio and encode it into SIP or H.245. Indeed every > gateway or PBX has the ability to detect such tones. > > All I am saying is that there are many applications where it is appropriate > to transport the information within an RTP payload. The standard "non RTP > means" (i.e. SIP/SDP or H.245) would be used to allow the gateway to > determine if the remote side can understand the RTP payload, and if it can, > then indeed the gateway will need intelligence to determine what is the > right way to transport. > > The only scheme which requires no "content-based decision" is one where the > tones are passed through as is. Several years of experience (including with > cell phones as well as IP telephony) have pretty much proved that this is a > bad idea. > > Scott -- Chris Fulmer Nortel, Ltd RTP, NC From rem-conf Fri Nov 13 06:23:54 1998 From rem-conf-request@es.net Fri Nov 13 06:23:53 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeK3K-0004MZ-00; Fri, 13 Nov 1998 06:18:22 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zeK3I-0004MO-00; Fri, 13 Nov 1998 06:18:21 -0800 Received: from henry.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 Nov 1998 14:18:08 +0000 X-Mailer: exmh version 1.6.9 8/22/96 To: rem-conf@es.net cc: confctrl@ISI.EDU, int-serv@isi.edu, diff-serv-interest@BayNetworks.COM, mbone@ISI.EDU, end2end-interest@ISI.EDU Subject: Interesting research..and book tokens Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Nov 1998 14:18:05 +0000 Message-ID: <1323.910966685@cs.ucl.ac.uk> From: Anna BOUCH X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, There's a really interesting questionnaire that you can answer at: http://www.cs.ucl.ac.uk/staff/A.Bouch/web_survey/ As an incentive for helping this research, you can also win 50 pounds of book tokens. Very grateful for your help, Anna P.S Any constructive criticisms/queries are welcome From rem-conf Fri Nov 13 06:39:10 1998 From rem-conf-request@es.net Fri Nov 13 06:39:09 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeKLe-00053A-00; Fri, 13 Nov 1998 06:37:18 -0800 Received: from blue.ocn.ne.jp ([203.139.160.87]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zeKLd-00052z-00; Fri, 13 Nov 1998 06:37:17 -0800 Received: from DRAGON by blue.ocn.ne.jp (8.8.8/8.8.8) id XAA06199; Fri, 13 Nov 1998 23:22:46 +0900 (JST) Reply-To: "ILC's WFI" From: "ILC's WFI" To: Subject: WFI (World Financial Infonet) 2 Date: Fri, 13 Nov 1998 23:18:15 +0900 Message-ID: <01be0f10$742f41a0$c416e1d2@DRAGON> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list $BGR7<(B $B5.e$2$^$9!#(B $B$3$N(BE-mail$B$O8B$i$l$?4k6H$NJ}$N$_$K$5$7>e$2$F$*$j$^$9$,!"$b$7$4ITMW$G$7$?$i!"(B $B$^$3$H$K?=$7Lu$"$j$^$;$s$,$*e$2$^$7$?$,!"$3$N(BE-mail$B$,$4LBOG$G$7$?$i!"$*e$2$^$9!#(B $B7I6q(B $B!J3t!K%"%$%(%k%7!<(B $B5HB; Fri, 13 Nov 1998 14:53:49 +0000 To: Mark Handley cc: rem-conf@es.net Subject: Re: Generic RTP Multiplexing In-reply-to: Your message of "Wed, 11 Nov 1998 16:44:59 EST." <17266.910820699@north.lcs.mit.edu> Date: Fri, 13 Nov 1998 14:53:48 +0100 Message-ID: <3001.910968828@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <17266.910820699@north.lcs.mit.edu>, Mark Handley typed: >>I've written up the Generic RTP Multiplexing ideas I presented at the >>last IETF. The draft will be on the ID sites in a few days, but for >>now you can get it from: Mark so a few questions 1/ why not alin it _exactly with RTPc? reason - if i build hardware rtp compression engines, it would be nice to re-use the h/w - especially since a box doing GERM might need to do a lot of it! 2/ what are the DMIF/FlowMux mappings? - do we have any templates from the MPEG people that we might use? - reason i ask is that you might want to consider having a simpler thing with either all or none and less complexity in processing the GERM byte....and subsequent wide variety of subsequent fields - i guess its a RISC type argument of how often how much changes and how many things change together... cheers jon From rem-conf Fri Nov 13 07:24:27 1998 From rem-conf-request@es.net Fri Nov 13 07:24:27 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeL2G-0006hO-00; Fri, 13 Nov 1998 07:21:20 -0800 Received: from north.lcs.mit.edu ([18.26.0.4]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zeL2F-0006hE-00; Fri, 13 Nov 1998 07:21:19 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id KAA20348; Fri, 13 Nov 1998 10:21:01 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Jon Crowcroft cc: rem-conf@es.net Subject: Re: Generic RTP Multiplexing In-reply-to: Your message of "Fri, 13 Nov 1998 14:53:48 +0100." <3001.910968828@cs.ucl.ac.uk> Date: Fri, 13 Nov 1998 10:21:01 -0500 Message-ID: <20346.910970461@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >so a few questions >1/ why not alin it _exactly with RTPc? reason - if i build hardware >rtp compression engines, it would be nice to re-use the h/w - >especially since a box doing GERM might need to do a lot of it! You get very poor compression if you do this. RTPc is intended to compress along the packets of a single flow. GERM is intended to compress across the packets of multiple flows. The predictor is completely different. Also RTPc doesn't put multiple subpackets in one IP packet. >2/ what are the DMIF/FlowMux mappings? - do we have any templates from >the MPEG people that we might use? _If_ there's concensus GERM is a good idea, then I expect someone who knows about MPEG will produce such a mapping. That someone is unlikely to be me though :-) Cheers, Mark From rem-conf Fri Nov 13 07:40:20 1998 From rem-conf-request@es.net Fri Nov 13 07:40:20 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeLJC-0007U8-00; Fri, 13 Nov 1998 07:38:50 -0800 Received: from e1.clubs.yahoo.com ([204.71.200.156]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zeLJB-0007Tv-00; Fri, 13 Nov 1998 07:38:49 -0800 Received: (from yahoo@localhost) by e1.clubs.yahoo.com (8.8.7/8.8.8) id HAA20171; Fri, 13 Nov 1998 07:38:18 -0800 (PST) Date: Fri, 13 Nov 1998 07:38:18 -0800 (PST) From: Yahoo! Clubs Message-Id: <199811131538.HAA20171@e1.clubs.yahoo.com> To: rem-conf@es.net Reply-To: ramiro_g@mailexcite.com Subject: You're invited! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello! You have been invited by elparto to join the listed Yahoo! Club named "Internet Telephony". To become a member of this club, just go to the Web address below: http://edit.clubs.yahoo.com/config/sjg?.i=internettelephony&.a=i& You need to go to the address above to join the club, but you can take a look at the club by going to: http://clubs.yahoo.com/clubs/internettelephony You can learn more about elparto by looking at the Yahoo! Public Profile: http://profiles.yahoo.com/elparto A Yahoo! Club is a great way to bring friends, family or anyone you know together using the latest in Web technologies. Club members are able to take advantage of a club's private chat room, message boards and other features. You can also create your own free club focused on any interest, such as hobbies, families and industry associations. Clubs are either listed or unlisted. Listed clubs are available to the public while unlisted clubs are available exclusively to those who receive invitations. If you have no interest in joining this club, there is no need for you to do anything. You will not be enrolled as a member. Thanks, The Yahoo! Clubs team http://clubs.yahoo.com/ P.S. If you need some help on getting started, go to: http://help.yahoo.com/help/clubs/ From rem-conf Fri Nov 13 07:45:49 1998 From rem-conf-request@es.net Fri Nov 13 07:45:48 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeLPH-00002k-00; Fri, 13 Nov 1998 07:45:07 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zeLPF-00001Z-00; Fri, 13 Nov 1998 07:45:05 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 Nov 1998 15:43:59 +0000 To: Mark Handley cc: Jon Crowcroft , rem-conf@es.net Subject: Re: Generic RTP Multiplexing In-reply-to: Your message of "Fri, 13 Nov 1998 10:21:01 EST." <20346.910970461@north.lcs.mit.edu> Date: Fri, 13 Nov 1998 15:43:57 +0100 Message-ID: <1425.910971837@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Mark Handley writes: >>2/ what are the DMIF/FlowMux mappings? - do we have any templates from >>the MPEG people that we might use? > >_If_ there's concensus GERM is a good idea, then I expect someone who >knows about MPEG will produce such a mapping. That someone is >unlikely to be me though :-) We have been talking about generic RTP multiplexing in the context of MPEG4, and there's certainly interest. As Mark says, whatever solution is adopted in AVT will undoubtably have a mapping for MPEG4. Colin From rem-conf Fri Nov 13 07:46:48 1998 From rem-conf-request@es.net Fri Nov 13 07:46:48 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeLQV-00009f-00; Fri, 13 Nov 1998 07:46:23 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zeLQU-00004i-00; Fri, 13 Nov 1998 07:46:22 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12021; Fri, 13 Nov 1998 10:45:48 -0500 (EST) Message-Id: <199811131545.KAA12021@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-germ-00.txt,.ps Date: Fri, 13 Nov 1998 10:45:47 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : GeRM: Generic RTP Multiplexing Author(s) : M. Handley Filename : draft-ietf-avt-germ-00.txt,.ps Pages : 8 Date : 12-Nov-98 This document describes GeRM, an RTP payload format for generic multiplexing of multiple RTP streams. This document is a product of the Audio/Video Transport (AVT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author. Internet-Drafts are 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-germ-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-germ-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-germ-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: <19981112105949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-germ-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-germ-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981112105949.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Nov 13 18:23:55 1998 From rem-conf-request@es.net Fri Nov 13 18:23:53 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zeVCo-00071f-00; Fri, 13 Nov 1998 18:12:54 -0800 Received: from ursamajor.cisco.com ([171.69.63.56]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zeVCn-00070d-00; Fri, 13 Nov 1998 18:12:53 -0800 Received: from sj-dial-3-42.cisco.com (sj-dial-3-42.cisco.com [171.68.179.43]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA11821; Fri, 13 Nov 1998 18:11:07 -0800 (PST) Date: Fri, 13 Nov 1998 18:10:46 -0800 (Pacific Standard Time) From: Stephen Casner To: Scott Petrack cc: Mark Handley , rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? In-Reply-To: <422566BA.00271E0B.00@il4.vocaltec.co.il> Message-ID: X-X-Sender: casner@ursamajor.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scott, I agree with what Chris Fulmer said: I can see why DTMF tones need to be detected by the gateway and re-encoded using a special DTMF payload type. Gateways will certainly have detectors for those tones and those tones are definitely designed to be detected by machines. However, I don't see why it is not acceptable to let the call progress tones go through the audio channel since they are intended for human ears to interpret. > In the scheme you suggest (which is to put such tone cadences into SIP or > H.323), the gateway must also make a "content-based decision" to recognize > DTMF, etc. within the audio and encode it into SIP or H.245. Indeed every > gateway or PBX has the ability to detect such tones. Yes. So I accept the argument that conveying these call-progress tones in SIP is not better than conveying them with a tone payload type. > The only scheme which requires no "content-based decision" is one where the > tones are passed through as is. Several years of experience (including with > cell phones as well as IP telephony) have pretty much proved that this is a > bad idea. How so? When you call France from a cell phone, the different French ringback tone doesn't get through successfully? -- Steve From rem-conf Sun Nov 15 10:20:58 1998 From rem-conf-request@es.net Sun Nov 15 10:20:56 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zf6ZR-00018n-00; Sun, 15 Nov 1998 10:06:45 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zf6ZM-00018d-00; Sun, 15 Nov 1998 10:06:42 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id UAA00734; Sun, 15 Nov 1998 20:03:12 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566BD.00639A85 ; Sun, 15 Nov 1998 20:07:56 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: Stephen Casner cc: Mark Handley , rem-conf@es.net Message-ID: <422566BD.00503C5F.00@il4.vocaltec.co.il> Date: Sun, 15 Nov 1998 19:00:36 +0200 Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Steve, >I agree with what Chris Fulmer said: I can see why DTMF tones need to >be detected by the gateway and re-encoded using a special DTMF payload >type. Gateways will certainly have detectors for those tones and >those tones are definitely designed to be detected by machines. >However, I don't see why it is not acceptable to let the call progress >tones go through the audio channel since they are intended for human >ears to interpret. > There are two reasons why it is often not acceptable to pass these tones through in the usual codecs. 1) The analogue call progress tones are not always intended for human ears to interpret. It happens often that machines need to interpret them. The entire CTI industry is founded on boards and machines which detect all the call progress tones. BrookTrout, NMS, Dialogic, Pika Tech, etc. all support detection of these tones on their analogue interface cards. 2) The current technology of voice codecs combined with the current loss, jitter, etc. in current IP networks implies that the call progress tones often sound terrible, and in fact often can not be recognized by the analogue CTI boards once they pass through an IP network via G.72x. For many applications, they can be made to sound much better by encoding them within a separate RTP payload type. What is true for DTMF tones is also true for other call progress tones. Both for DTMF and for the other tones I am proposing that they "go through the audio channel". I am merely proposing that for all the tones, it is often much better to use a special "audio codec" which is optimized for these tones, rather than G.723, G.729, or another "general purpose" audio codec. Think of it this way: we are all waiting breathlessly for new "IP friendly codecs" that will work well with redundancy, layering, etc. and will give good audio quality over real IP networks. The RTP payload type that I am proposing is in fact an "IP friendly codec" which works with the special audio of analogue telephone call progress tones. (For example, it has built in some special redundancy techniques optimized for this case). These special "codec" leads to call progress tones which sound much better to both remote ears and remote machines. There is in fact a price to be paid for encoding the call progress tones this way: it usually adds some delay to detect them. This is a serious consideration in some circumstances, but it is quite possible to overcome the problem by a decent smooth playout scheme. > >> The only scheme which requires no "content-based decision" is one where the >> tones are passed through as is. Several years of experience (including with >> cell phones as well as IP telephony) have pretty much proved that this is a >> bad idea. > >How so? When you call France from a cell phone, the different French >ringback tone doesn't get through successfully? No, often it doesn't, not in my experience. I have a digital cell phone both in Israel and in the USA, and I often call France, and sometimes the packet loss on my cell phone is so bad that I actually can't tell if the remote phone is ringing or busy. As a final indication that such a payload type is useful, even necessary, look at the sorts of scenarios which appear in SGCP/IPDC/MGCP. When the media gateway connects to an analogue PSTN, the media gateway needs to detect/generate all these analogue call progress tones and transport them to/from the Call Agent. Because of PSTN timing contraints within standards, it is essential to preserve the realtime nature of these signals as they are transported. For DTMF and for all other call progress tones. Scott From rem-conf Mon Nov 16 02:37:27 1998 From rem-conf-request@es.net Mon Nov 16 02:37:26 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfLwL-0001W4-00; Mon, 16 Nov 1998 02:31:25 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfLwA-0001Vs-00; Mon, 16 Nov 1998 02:31:16 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id MAA14149; Mon, 16 Nov 1998 12:27:54 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566BE.0039ACB8 ; Mon, 16 Nov 1998 12:29:57 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: casner@cisco.com cc: rem-conf@es.net Message-ID: <422566BE.0025CDA9.00@il4.vocaltec.co.il> Date: Mon, 16 Nov 1998 12:27:26 +0200 Subject: Request for slot in AVT -- putting all call progress tones into the RTP "dtmf" payload Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In my haste I didn't emphasize strongly enough some real reasons I think that it is very important to include other call progress tones in the "DTMF payload" (and in fact why I think we need the general (frequency, duration, energy) triples there as well). I got sidetracked into the narrower (but also important) issue of "why not send it within the ordinary audio payload." 1. The "NAVDEC" and "SIGTRANS" community (i.e. the guys doing RGSP,MGCP,SGCP,Q.931, etc.) have the requirement to transport the call progress tones (as well as other "control tones" like hookflash, off-hook, on-hoon, etc.) between various places in the Internet. This gives yet another example of how these tones are going to be detected by machines. They are never going to transport these tones within ordinary RTP audio. And in fact the solutions they propose (i.e. the parts of MGCP etc. which do this backhauling) are not as suitable as a new RTP payload would be. This is because the precise timing information is lost, and it is often vital. 2. Both the current DTMF draft and H.245v3 have in addition to DTMF a signal for "hookflash". Things like hook-flash and "off-hook" and "on-hook" are not call progress tones, but they are signals that go over analogue copper wire and there really are applications where it is vital to transport these signals over IP. I know of at least two hardware IP telephone devices which send these signals over IP in a proprietary, non-interoperable fashion. From what I can tell, these proprietary protocols will never work over anything other than a lossless, delay-less LAN. So the real reason is that there are implementations out there already that send analogue telephony signals over IP in proprietary, non-interoperable, non-WAN friendly ways, and there is everything to be gained from producing a decent solution (Especially when it is so simple to do). And we can see that there will be other implementations doing the same thing between Media GWs and Signalling GWs. This has happened before in IP Telephony -- the IETF said "simple telephony signalling is a stupid and uninteresting problem" and therefore manufacturers had no choice but to use signalling protocols that were never designed for widespread IP use. Let's not do this mistake again, please. Especially when the fix is so simple. I agree with Steve's basic point that if the tones are intended to be heard by human ears only, and you believe that the IP transport of ordinary audio is good enough, then there is no reason to re-encode the tones in a different payload. I just claim that it is often not possible to know who will hear the remote tones (human or machine), and the audio quality is often not good enough. So we need an alternative. This is a case where having two possibilities will not affect interoperability, and there is no IPR in the bit pattens used ;-). This is so important that I'd like to request a slot a AVT to discuss this. I will be submitting a sample payload draft by the deadline. Scott Petrack VocalTec Communications Ltd. petrack@vocaltec.com From rem-conf Mon Nov 16 04:21:16 1998 From rem-conf-request@es.net Mon Nov 16 04:21:15 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfNbV-00033T-00; Mon, 16 Nov 1998 04:18:01 -0800 Received: from 1cust161.tnt26.nyc3.da.uu.net ([208.255.64.161] helo=208.255.64.161) by mail2.es.net with smtp (Exim 1.92 #1) id 0zfNbS-00033J-00; Mon, 16 Nov 1998 04:17:59 -0800 From: sales@scottallenexportsales.com To: Subject: from Helen Astor /forward to pres. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 16 Nov 1998 04:17:59 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Referred by J.B.S./8/3/98 opt in >From Helen Astor, Somerset, New Jersey USA Please forward to the president of company. DONT JUST EMAIL BACK ! ! ! We are extremely targeted and will NOT send back just general info by e-mail. Targeted works beautifully.........untargeted does not. We need additional details over the phone to get you the properly targeted further info. If you are interested in: ............. English Speaking......................... 1. Bilingual sales reps.....currently seeking to represent American/and/or international companies. ......... We have lists of both. 2. Bilingual distributors.....currently importing from American/and/or international companies.............. we have lists of both 3. Bilingual end users .....currently importing from American/and/or international companies. ......... We have lists of both. 4. Bilingual agents...currently arranging private labeling, subcontracting, contracting work, and negotiating licensing arrangements for American/and/or international companies. ......... We have lists of both. 5. Bilingual suppliers of raw materials and components....currently selling internationally. 6. Bilingual buyers of close outs, surplus overruns, seconds.....currently buying from American/and/or international companies. We have lists of both. ........................ 7. Bilingual joint marketing partners.....currently seeking American/and/or International/ partners........We have lists of both. 8. Bilingual foreigners seeking to buy all or part of your business...or act as silent partner......................... 9. Bilingual foreigners who will supply finance for your business. .................. 10. Bilingual foreigners with new products for your business to sell. Our lists come two ways: Those doing business exclusively with America.... and those doing business worldwide. We have lists with their phone numbers, fax numbers, addresses, and contact names. All are English speaking and have internet accounts. First time exporters fine. Imports fine. Each list contains 360 to 410 names and costs $72.00 U.S. For the areas of: Mexico, Central, and South America,Japan/Asia, Eastern/Western Europe,China,Australia,Asia,the Middle East. Best Regards, Helen Astor Somerset, New Jersey USA PHONE CALLS ONLY please.........we are extremely targeted and need additional info from you. We will not reply back with General info over the internet. 732-247-3173 If you don't call we will presume you are not interested. From rem-conf Mon Nov 16 14:49:11 1998 From rem-conf-request@es.net Mon Nov 16 14:49:10 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfXGs-0001tS-00; Mon, 16 Nov 1998 14:37:22 -0800 Received: from smtprich.nortel.com ([192.135.215.8] helo=smtprich) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfXGr-0001tI-00; Mon, 16 Nov 1998 14:37:21 -0800 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprich; Mon, 16 Nov 1998 16:36:54 -0600 Received: from zrtpd00x.us.nortel.com by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id W7RCWJ01; Mon, 16 Nov 1998 17:37:39 -0500 Received: from nrtphf51.us.nortel.com by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id V64J3J1V; Mon, 16 Nov 1998 17:37:39 -0500 Sender: "Chris Fulmer" Message-ID: <3650A8FF.E9D5694@americasm01.nt.com> Date: Mon, 16 Nov 1998 17:36:48 -0500 From: "Chris Fulmer" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778) MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? References: <422566BD.00503C5F.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hmm... Wow. This is getting to be a very interesting conversation. It appears that you (Scott) and I have very different ideas about how everything will fit together. My point of view is from the toll-bypass universe, where there's an assumption that a phone call will route through the PSTN to a gateway, through an IP network to another gateway, then back onto the PSTN -- effectively using IP for long distance traffic. In this scenario, there really isn't much of a need to transfer many of the non-DTMF tones across... Dialtone is generated by the local PSTN switch, so it never goes across RTP. Similarly, when a call is placed to a busy line, a busy indication is returned to the switch, which plays a busy signal to the caller, and drops the outgoing leg, since there's no need to waste the bandwidth. And, you can go on through the line -- most of the tones are actually generated locally. You, on the other hand, appear to be more concerned with the local loop -- between the terminal and some soft of switch, which presumably would be providing dial-tone via RTP, and would effectively take the place of the wire between the home and the telephone switch. In this case, the terminal has very little intelligence -- presumably, when it's picked up, it sends some message which initiates an RTP session. From that point on, until hang-up, it just sits there encoding & decoding RTP. So, there's a bit of a paradigm difference here -- you seem to be taking the POTS approach, where the terminal is dumb, whereas I'm taking more of the ISDN approach, where the terminal has the capability to generate most of the signalling tones. Such things are the subject of religious wars, so I'm not going to comment further. It seems to me that your idea of submitting a seperate payload draft is a good one, but I'd personally prefer that it not hold up Henning's DTMF-only work, as I believe that there's an immediate need for a DTMF solution, due to several incompatible proprietary methods that are being used, as well as a few implementations of the original DTMF draft. Since the IMTC interoperability agreement talks about using that draft, it seems prudent to push forward on it. -- Chris Fulmer chrisf@nortel.com Nortel Networks Ltd Research Triangle Park NC USA Scott Petrack wrote: > Dear Steve, > > >I agree with what Chris Fulmer said: I can see why DTMF tones need to > >be detected by the gateway and re-encoded using a special DTMF payload > >type. Gateways will certainly have detectors for those tones and > >those tones are definitely designed to be detected by machines. > >However, I don't see why it is not acceptable to let the call progress > >tones go through the audio channel since they are intended for human > >ears to interpret. > > > > There are two reasons why it is often not acceptable to pass these tones > through in the usual codecs. > > 1) The analogue call progress tones are not always intended > for human ears to interpret. It happens often that machines need > to interpret them. The entire CTI industry is founded on boards and > machines > which detect all the call progress tones. BrookTrout, NMS, Dialogic, > Pika Tech, etc. all support detection of these tones on their analogue > interface cards. > > 2) The current technology of voice codecs combined with the > current loss, jitter, etc. in current IP networks implies that the call > progress tones often sound terrible, and in fact often can not be > recognized > by the analogue CTI boards once they pass through an IP network via > G.72x. For many applications, they can be made to sound much better by > encoding them within a separate RTP payload type. > > What is true for DTMF tones is also true for other call progress tones. > Both for DTMF and for the other tones I am > proposing that they "go through the audio channel". I am merely proposing > that for all the tones, > it is often much better to use a special "audio codec" which is > optimized for these tones, rather than G.723, G.729, or another "general > purpose" audio codec. > > Think of it this way: we are all waiting breathlessly for new "IP friendly > codecs" that will work well with redundancy, layering, etc. and will give > good audio quality over real IP networks. The RTP payload type that I am > proposing is in fact an "IP friendly codec" which works with the special > audio of analogue telephone call progress tones. (For example, it has > built in some special redundancy techniques optimized for this case). > These special "codec" leads to call progress tones which sound > much better to both remote ears and remote machines. > > There is in fact a price to be paid for encoding the call > progress tones this way: it usually adds some delay to detect them. This is > a > serious consideration in some circumstances, but it is quite possible to > overcome the problem by a decent smooth playout scheme. > > > > >> The only scheme which requires no "content-based decision" is one where > the > >> tones are passed through as is. Several years of experience (including > with > >> cell phones as well as IP telephony) have pretty much proved that this > is a > >> bad idea. > > > >How so? When you call France from a cell phone, the different French > >ringback tone doesn't get through successfully? > > No, often it doesn't, not in my experience. I have a digital cell phone > both in Israel and in the USA, and I often call France, and sometimes > the packet loss on my cell phone is so bad that I actually can't tell > if the remote phone is ringing or busy. > > As a final indication that such a payload type is useful, even necessary, > look at the sorts of scenarios which appear in SGCP/IPDC/MGCP. When the > media gateway connects to an analogue PSTN, the media gateway needs to > detect/generate all these analogue call progress tones and transport them > to/from the Call Agent. Because of PSTN timing contraints within standards, > it is essential to preserve the realtime nature of these signals as they > are transported. For DTMF and for all other call progress tones. > > Scott From rem-conf Mon Nov 16 14:49:11 1998 From rem-conf-request@es.net Mon Nov 16 14:49:10 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfXO3-0001zL-00; Mon, 16 Nov 1998 14:44:47 -0800 Received: from jekyll.piermont.com ([206.1.51.15]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfXO1-0001zB-00; Mon, 16 Nov 1998 14:44:45 -0800 Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id RAA16823; Mon, 16 Nov 1998 17:44:33 -0500 (EST) To: rem-conf@es.net Subject: spam Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 16 Nov 1998 17:44:32 -0500 Message-ID: <87ww4vntpr.fsf@jekyll.piermont.com> Lines: 40 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If the rem-conf mailing list were closed to postings by non-subscribers, this spam would never have gotten through. Could we get the mailing list closed? .pm Return-Path: rem-conf-request@es.net Delivery-Date: Mon Nov 16 07:25:36 1998 Delivered-To: perry@piermont.com Received: from mail2.es.net (mail2.es.net [198.128.3.182]) by frankenstein.piermont.com (Postfix) with ESMTP id 52E0917F2; Mon, 16 Nov 1998 07:25:34 -0500 (EST) Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfNbV-00033T-00; Mon, 16 Nov 1998 04:18:01 -0800 Received: from 1cust161.tnt26.nyc3.da.uu.net ([208.255.64.161] helo=208.255.64.161) by mail2.es.net with smtp (Exim 1.92 #1) id 0zfNbS-00033J-00; Mon, 16 Nov 1998 04:17:59 -0800 From: sales@scottallenexportsales.com To: Subject: from Helen Astor /forward to pres. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 16 Nov 1998 04:17:59 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sender: rem-conf-request@es.net Referred by J.B.S./8/3/98 opt in >From Helen Astor, Somerset, New Jersey USA Please forward to the president of company. DONT JUST EMAIL BACK ! ! ! [...] From rem-conf Mon Nov 16 15:33:45 1998 From rem-conf-request@es.net Mon Nov 16 15:33:44 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfXwt-0003SD-00; Mon, 16 Nov 1998 15:20:47 -0800 Received: from acsys.anu.edu.au ([150.203.20.41]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfXwr-0003S2-00; Mon, 16 Nov 1998 15:20:45 -0800 Received: from accordion (accordion [150.203.20.58]) by acsys.anu.edu.au (8.9.1/8.9.1) with SMTP id KAA03195; Tue, 17 Nov 1998 10:20:40 +1100 (EST) Message-Id: <3.0.32.19981117102008.009353d0@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 17 Nov 1998 10:20:09 +1100 To: rem-conf@es.net From: Markus Buchhorn Subject: Re: spam Cc: mbone@isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 17:44 16/11/98 -0500, Perry E. Metzger wrote: > >If the rem-conf mailing list were closed to postings by >non-subscribers, this spam would never have gotten through. > >Could we get the mailing list closed? The rem-conf list may be like the mbone list, in that the source address (rem-conf@es.net, mbone@isi.edu) is just a list of lists - which means you can't "see" if the poster is a subscriber directly. About the only way I can see right now is for people to post to local (mbone-oz, whatever) lists, which are closed, which in turn pass the message up to the main international list, which is closed to only receive messages from the various local/national lists. Not real elegant, but neither is centralising the large list. How many people are on the mbone/rem-conf lists around the world now ? And then how do you provide local lists as subsets ? Cheers, Markus Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Tue Nov 17 04:14:43 1998 From rem-conf-request@es.net Tue Nov 17 04:14:41 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfjsQ-0002jG-00; Tue, 17 Nov 1998 04:04:58 -0800 Received: from proxy3.ba.best.com ([206.184.139.14] ident=root) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfjsO-0002j6-00; Tue, 17 Nov 1998 04:04:56 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id EAA04176; Tue, 17 Nov 1998 04:02:30 -0800 (PST) Message-Id: <3.0.5.16.19981117041648.23c7693a@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Tue, 17 Nov 1998 04:16:48 To: rem-conf@es.net, confctrl@isi.edu From: Ross Finlayson Subject: A "sdr" source-code patch for directory sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A quick update to my earlier message. Bill Fenner reminded me that I hadn't mentioned which version of "sdr" I used to generate my patch. It was version 2.5.8 (the sdr source code version from UCL). Also (following another suggestion by Bill) I changed the patch to a contextual diff, to make it more useful when applied to an already-modified sdr source tree. (A reminder: The patch is available at ) Ross. From rem-conf Tue Nov 17 09:08:00 1998 From rem-conf-request@es.net Tue Nov 17 09:07:59 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfoV1-00062d-00; Tue, 17 Nov 1998 09:01:07 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfoV0-00062Q-00; Tue, 17 Nov 1998 09:01:06 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA08444; Tue, 17 Nov 1998 12:00:30 -0500 (EST) Message-Id: <199811171700.MAA08444@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-format-guidelines-01.txt,.ps Date: Tue, 17 Nov 1998 12:00:30 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : Guidelines for Writers of RTP Payload Format Specifications Author(s) : M. Handley Filename : draft-ietf-avt-rtp-format-guidelines-01.txt,.ps Pages : 7 Date : 16-Nov-98 This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifica- tions in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. Internet-Drafts are 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-format-guidelines-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-format-guidelines-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981116114722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-format-guidelines-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981116114722.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Nov 17 09:21:12 1998 From rem-conf-request@es.net Tue Nov 17 09:21:12 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfoim-0006SI-00; Tue, 17 Nov 1998 09:15:20 -0800 Received: from nobozo.cs.berkeley.edu ([128.32.34.58]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfoik-0006S6-00; Tue, 17 Nov 1998 09:15:18 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA32060; Tue, 17 Nov 1998 09:15:17 -0800 (PST) Message-Id: <3.0.3.32.19981117091517.00906a90@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 17 Nov 1998 09:15:17 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: Reminder: 11/18 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar MPEG in the Real World: How MPEG-2 is used in the Cable and Broadcast Industry Wednesday November 18, 1998 12:30-2:00 pm 405 Soda Hall Steve Smoot Imedia Inc. To many multimedia researchers, compression technology is useful for what it can do on the desktop or over the internet. However, the most extensive (and most expensive) use of compression technology is in the Broadcast and Cable industry. This talk focuses on how industry uses digital video today: - the infrastructure (where and how compression is used) - major players (who makes the equipment and who buys it) - encoding and multiplexing (how they use it) I highlight how digital video in Broadcast and Cable differs from the Internet/academic multimedia experience. Towards the end, I describe the near-term future and speculate on the long-term future - where the cable industry starts to look a lot more like the usual multimedia experience. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Nov 17 12:21:14 1998 From rem-conf-request@es.net Tue Nov 17 12:21:12 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfrP4-0001UV-00; Tue, 17 Nov 1998 12:07:10 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfrP2-0001UL-00; Tue, 17 Nov 1998 12:07:08 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id WAA29322 for ; Tue, 17 Nov 1998 22:04:16 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566BF.006E6EF0 ; Tue, 17 Nov 1998 22:06:13 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: rem-conf@es.net Message-ID: <422566BF.00294108.00@il4.vocaltec.co.il> Date: Tue, 17 Nov 1998 09:44:54 +0200 Subject: GSM payload format non-draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The ETSI TIPHON project specified a payload format for the two "new" GSM codecs (the half-rate codec and the "enhanced full rate codec"). I cannot submit the ETSI TIPHON specification as an internet-draft, because there is not an ascii version. Here is the URL to obtain the .pdf version of the document. I hope that it will be possible to include the relevant sections into the basic audio profile. http://docbox.etsi.fr/tech-org/tiphon/Document/tiphon/07-drafts/wg3/DTS0300 1/VP1.1.1/TS03001.pdf Scott Petrack VocalTec Communications Ltd. petrack@vocaltec.com From rem-conf Tue Nov 17 12:23:59 1998 From rem-conf-request@es.net Tue Nov 17 12:23:58 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfrYD-0001aT-00; Tue, 17 Nov 1998 12:16:37 -0800 Received: from sargasso.cse.msu.edu ([35.9.20.14]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfrYC-0001aJ-00; Tue, 17 Nov 1998 12:16:36 -0800 Received: from cerium.cps.msu.edu (cerium.cps.msu.edu [35.9.27.28]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id PAA29978 for ; Tue, 17 Nov 1998 15:16:31 -0500 (EST) Received: from cerium (localhost [127.0.0.1]) by cerium.cps.msu.edu (8.8.8/8.8.8) with SMTP id PAA08049 for ; Tue, 17 Nov 1998 15:16:31 -0500 (EST) Sender: leekwa44@cse.msu.edu Message-ID: <3651D99E.3735@cse.msu.edu> Date: Tue, 17 Nov 1998 15:16:30 -0500 From: Dr Kwang-il Lee Organization: Michgan State University X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: MPEG Traffic Model is Needed !! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello !! I'm looking for MPEG1/2 Traffic generator on OPNET. if anyone of you has it or know where I can get it, please let me know it. thnks for your help in advance >from Kwang-il Lee From rem-conf Tue Nov 17 14:14:56 1998 From rem-conf-request@es.net Tue Nov 17 14:14:54 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zftJB-00047O-00; Tue, 17 Nov 1998 14:09:13 -0800 Received: from cyclops.ece.ncsu.edu ([152.1.157.9]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zftJ9-00047E-00; Tue, 17 Nov 1998 14:09:11 -0800 Received: (from smmccraw@localhost) by cyclops.ece.ncsu.edu (8.8.4/UC02Jan97) id RAA07436 for rem-conf@es.net; Tue, 17 Nov 1998 17:09:09 -0500 (EST) From: "Steven Mark Mccraw" Message-Id: <9811171709.ZM7434@eos.ncsu.edu> Date: Tue, 17 Nov 1998 17:09:09 -0500 X-Mailer: Z-Mail (3.2.1 10oct95) To: rem-conf@es.net Subject: sdr plugins Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am attempting to create a plugin for sdr that will enable me to create sessions with media board, which is part of the recently released suite of mash tools developed at UCB. So far, this is what I have: media:mediaboard proto:udp tool:mb fmt:mb This seems to do something, because when I try to launch a session from sdr now, media board appears as an option. However, if I select it, I get the following message: No tool installed. You have no tool installed that could participate in a session with this media. I have installed mb, and even tried giving the full path to mb in the second half of the tool specification, but still get the same thing. I would greatly appreciate any insight or suggestions anyone may have regarding this. Sincerely, Mark McCraw From rem-conf Tue Nov 17 15:06:54 1998 From rem-conf-request@es.net Tue Nov 17 15:06:53 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfu2L-0005MW-00; Tue, 17 Nov 1998 14:55:53 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfu2H-0005M7-00; Tue, 17 Nov 1998 14:55:49 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id AAA01444; Wed, 18 Nov 1998 00:45:09 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566BF.007D2B14 ; Wed, 18 Nov 1998 00:47:10 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: "Chris Fulmer" cc: rem-conf@es.net Message-ID: <422566BF.0077E4C6.00@il4.vocaltec.co.il> Date: Tue, 17 Nov 1998 23:59:40 +0200 Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have now more or less finished a draft which is completely backward compatible with Henning's draft and gives essentially all the capabilities we could ever need. I will post it tomorrow, (perhaps with Henning's name on it if he agrees). I understand your concern to get something out (although we have waited for 2 years so far....). But I think that it would be very unfortunate indeed to need different RFCs for "local loop" stuff and for "trunk replacement" stuff. Especially when I can satisfy all the requirements (including the one that says "if you implemented Henning's draft you want to be ok). I think that you will find some things in it that are useful for trunk replacement as well. There is much more to the world than just DTMF and dialtone. As one of the authors of the VoIP IA, and one of the loudest mouths for DTMF-in-RTP, I certainly agree that there is need for something. I hope you will find my draft tomorrow fits the bill. (By the way, the VoIP IA says: "If when finalized, this draft meets with the VoIP forums approval, then it will be specified as an optional method that endpoints may use for DTMF carriage." So it is not true that the VoIP IA says to use the draft. But this is real nit-picking). Scott "Chris Fulmer" on 11/17/98 12:36:48 AM To: Scott Petrack cc: rem-conf@es.net Subject: Re: ietf-avt-dtmf-00.txt draft -> standard? Hmm... Wow. This is getting to be a very interesting conversation. It appears that you (Scott) and I have very different ideas about how everything will fit together. My point of view is from the toll-bypass universe, where there's an assumption that a phone call will route through the PSTN to a gateway, through an IP network to another gateway, then back onto the PSTN -- effectively using IP for long distance traffic. In this scenario, there really isn't much of a need to transfer many of the non-DTMF tones across... Dialtone is generated by the local PSTN switch, so it never goes across RTP. Similarly, when a call is placed to a busy line, a busy indication is returned to the switch, which plays a busy signal to the caller, and drops the outgoing leg, since there's no need to waste the bandwidth. And, you can go on through the line -- most of the tones are actually generated locally. You, on the other hand, appear to be more concerned with the local loop -- between the terminal and some soft of switch, which presumably would be providing dial-tone via RTP, and would effectively take the place of the wire between the home and the telephone switch. In this case, the terminal has very little intelligence -- presumably, when it's picked up, it sends some message which initiates an RTP session. From that point on, until hang-up, it just sits there encoding & decoding RTP. So, there's a bit of a paradigm difference here -- you seem to be taking the POTS approach, where the terminal is dumb, whereas I'm taking more of the ISDN approach, where the terminal has the capability to generate most of the signalling tones. Such things are the subject of religious wars, so I'm not going to comment further. It seems to me that your idea of submitting a seperate payload draft is a good one, but I'd personally prefer that it not hold up Henning's DTMF-only work, as I believe that there's an immediate need for a DTMF solution, due to several incompatible proprietary methods that are being used, as well as a few implementations of the original DTMF draft. Since the IMTC interoperability agreement talks about using that draft, it seems prudent to push forward on it. -- Chris Fulmer chrisf@nortel.com Nortel Networks Ltd Research Triangle Park NC USA Scott Petrack wrote: > Dear Steve, > > >I agree with what Chris Fulmer said: I can see why DTMF tones need to > >be detected by the gateway and re-encoded using a special DTMF payload > >type. Gateways will certainly have detectors for those tones and > >those tones are definitely designed to be detected by machines. > >However, I don't see why it is not acceptable to let the call progress > >tones go through the audio channel since they are intended for human > >ears to interpret. > > > > There are two reasons why it is often not acceptable to pass these tones > through in the usual codecs. > > 1) The analogue call progress tones are not always intended > for human ears to interpret. It happens often that machines need > to interpret them. The entire CTI industry is founded on boards and > machines > which detect all the call progress tones. BrookTrout, NMS, Dialogic, > Pika Tech, etc. all support detection of these tones on their analogue > interface cards. > > 2) The current technology of voice codecs combined with the > current loss, jitter, etc. in current IP networks implies that the call > progress tones often sound terrible, and in fact often can not be > recognized > by the analogue CTI boards once they pass through an IP network via > G.72x. For many applications, they can be made to sound much better by > encoding them within a separate RTP payload type. > > What is true for DTMF tones is also true for other call progress tones. > Both for DTMF and for the other tones I am > proposing that they "go through the audio channel". I am merely proposing > that for all the tones, > it is often much better to use a special "audio codec" which is > optimized for these tones, rather than G.723, G.729, or another "general > purpose" audio codec. > > Think of it this way: we are all waiting breathlessly for new "IP friendly > codecs" that will work well with redundancy, layering, etc. and will give > good audio quality over real IP networks. The RTP payload type that I am > proposing is in fact an "IP friendly codec" which works with the special > audio of analogue telephone call progress tones. (For example, it has > built in some special redundancy techniques optimized for this case). > These special "codec" leads to call progress tones which sound > much better to both remote ears and remote machines. > > There is in fact a price to be paid for encoding the call > progress tones this way: it usually adds some delay to detect them. This is > a > serious consideration in some circumstances, but it is quite possible to > overcome the problem by a decent smooth playout scheme. > > > > >> The only scheme which requires no "content-based decision" is one where > the > >> tones are passed through as is. Several years of experience (including > with > >> cell phones as well as IP telephony) have pretty much proved that this > is a > >> bad idea. > > > >How so? When you call France from a cell phone, the different French > >ringback tone doesn't get through successfully? > > No, often it doesn't, not in my experience. I have a digital cell phone > both in Israel and in the USA, and I often call France, and sometimes > the packet loss on my cell phone is so bad that I actually can't tell > if the remote phone is ringing or busy. > > As a final indication that such a payload type is useful, even necessary, > look at the sorts of scenarios which appear in SGCP/IPDC/MGCP. When the > media gateway connects to an analogue PSTN, the media gateway needs to > detect/generate all these analogue call progress tones and transport them > to/from the Call Agent. Because of PSTN timing contraints within standards, > it is essential to preserve the realtime nature of these signals as they > are transported. For DTMF and for all other call progress tones. > > Scott From rem-conf Tue Nov 17 16:17:51 1998 From rem-conf-request@es.net Tue Nov 17 16:17:51 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfvCA-000723-00; Tue, 17 Nov 1998 16:10:06 -0800 Received: from rumor.research.att.com ([192.20.225.9]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zfvC8-00071V-00; Tue, 17 Nov 1998 16:10:04 -0800 Received: from research.att.com ([135.207.30.100]) by rumor; Tue Nov 17 19:03:17 EST 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Tue Nov 17 19:07:15 EST 1998 Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id TAA24787; Tue, 17 Nov 1998 19:07:14 -0500 (EST) Message-ID: <028901be1287$47bce800$4683cf87@pcmrcfast.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Mark Handley" , Subject: Re: Generic RTP Multiplexing Date: Tue, 17 Nov 1998 19:06:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It seems like for some applications including MPEG-4, we have to establish a mechanism for identifying the multiplexed payloads at the receiver. As a simple example, lets assume that I use MPEG1 to encode left and right channels of a 3D video presentation and send these streams multiplexed using GeRM. At the receiver, how would I assign the packets to the correct channel (left, right)? May be we need to add an index. Any comments? ----------------------------------------------------------------------- M. Reha Civanlar Technology Leader, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf Tue Nov 17 16:23:55 1998 From rem-conf-request@es.net Tue Nov 17 16:23:55 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zfvL8-0007G4-00; Tue, 17 Nov 1998 16:19:22 -0800 Received: from acsys.anu.edu.au ([150.203.20.41]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zfvL6-0007FK-00; Tue, 17 Nov 1998 16:19:21 -0800 Received: from accordion (accordion [150.203.20.58]) by acsys.anu.edu.au (8.9.1/8.9.1) with SMTP id LAA01237 for ; Wed, 18 Nov 1998 11:19:12 +1100 (EST) Message-Id: <3.0.32.19981118111913.0098ee40@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 18 Nov 1998 11:19:14 +1100 To: rem-conf@es.net From: Markus Buchhorn Subject: Level 3 and Bellcore merge Voice over IP protocols Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FYI - seems to be slightly relevant to the current discussion ? >------------------------------------------- > >LEVEL 3 AND BELLCORE MERGE VOICE OVER IP PROTOCOL PROPOSALS >Level 3 Communications and Bellcore will merge their Voice over IP >proposals into a common specification to be called the Media >Gateway Control Protocol (MGCP). It will be available without a >fee to service providers and hardware and software vendors. MGCP >is designed for external control and management of "media >gateways" (such as voice over IP gateways, voice over ATM >gateways, modem banks, cable modems, set-top boxes, soft PBXs and >circuit cross connects) using software "call agents" or media gateway >controllers. A draft of the MGCP specification has been submitted >to the SS7-Internet mailing list of the IETF and to ETSI's >Telecommunications & Internet Protocol Harmonization Over Networks >(ETSI TIPHON) working group. Previously, Level 3 had led a >consortium developing an Internet Protocol Device Control (IPDC) >specification; Bellcore and Cisco Systems were developing a Simple >Gateway Control Protocol (SGCP). Both efforts are now merged into >MGCP. http://www.Level3.com/company/nov1698.html >Level 3, November 16, 1998 > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >NORTEL ANNOUNCES SS7-IP INTERWORKING INITIATIVE >Nortel Networks will lead an initiative to develop a standardized >signaling protocol and open network architecture to simplify >interworking between Signaling System 7 (SS7) and IP networks. >Nortel has submitted a general architecture definition for "IPS7" >to the IETF. It also plans to share the IPS7 concepts through >other related standards bodies. >http://www.nortel.com/home/press/1998c/11_16_9898621_SSIP_Protocol.html >Nortel Networks. November 16, 1998 > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >ATM Digest Web services now include a searchable Archive, >Headline Index and News Digests for WDM, ATM Satellite, >Broadband Wireless, ATM Security, MPOA, Industry >Mergers/Acquisitions, subscription information and more. >(http://www.atmdigest.com) > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >About our Sponsor: >FORE Systems is a leading global supplier of networking >solutions based on an Intelligent Infrastructure designed to >handle the networked applications of today and tomorrow. >FORE's Networks of Steel(TM) deliver the increased capacity, >reduced complexity and unparalleled flexibility and >scalability necessary to build networks that last. Thousands >of enterprise and service provider customers worldwide have >put FORE Systems' solutions at the heart of their networks. >(http://www.fore.com) > > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >About ATM News Inc. >The ATM News Digest is owned and published by ATM News Inc., >an independent company dedicated to reporting the latest >developments in the field of broadband networking. ATM News >Inc. is solely responsible for gathering, editing and >distributing the contents of this publication. > >Your comments and suggestions are kindly welcomed. > >James Carroll >Editor and Publisher, ATM News Digest >690 W. Fremont Ave., Suite #1 >Sunnyvale, CA 94087 >Tel. +1-408-245-9828 >Fax +1-408-245-9832 >http://www.atmdigest.com -- searchable archive, index > >Email: jcarroll@atmdigest.com -- for comments, news tips > info@atmdigest.com -- for subscription services > >REPLIES sent to this Web server message will not be received! > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Tue Nov 17 23:12:30 1998 From rem-conf-request@es.net Tue Nov 17 23:12:28 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zg1ie-0004Qo-00; Tue, 17 Nov 1998 23:08:04 -0800 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zg1ib-0004Qe-00; Tue, 17 Nov 1998 23:08:02 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Nov 18 02:07:55 EST 1998 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.185.217.215]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA04674; Wed, 18 Nov 1998 02:07:52 -0500 (EST) Message-ID: <365271E5.4F59B52E@dnrc.bell-labs.com> Date: Wed, 18 Nov 1998 02:06:13 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "M. Reha Civanlar" CC: Mark Handley , rem-conf@es.net Subject: Re: Generic RTP Multiplexing References: <028901be1287$47bce800$4683cf87@pcmrcfast.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list M. Reha Civanlar wrote: > > It seems like for some applications including MPEG-4, we have > to establish a mechanism for identifying the multiplexed payloads > at the receiver. As a simple example, lets assume that I use MPEG1 > to encode left and right channels of a 3D video presentation and send > these streams multiplexed using GeRM. At the receiver, how would I > assign the packets to the correct channel (left, right)? Normally the left and right channels would be in a single stream; I think rfc1890 details how to multiplex the bytes. Why would you want to split them into separate streams and then mux them with Germ? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Nov 18 03:02:19 1998 From rem-conf-request@es.net Wed Nov 18 03:02:17 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zg5Hr-0006XA-00; Wed, 18 Nov 1998 02:56:39 -0800 Received: from melimelo.enst-bretagne.fr ([192.108.115.36]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zg5Ho-0006Wq-00; Wed, 18 Nov 1998 02:56:36 -0800 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA35993; Wed, 18 Nov 1998 11:53:50 +0100 Received: from pacman (pacman.rennes.enst-bretagne.fr [193.52.74.218]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id LAA27796; Wed, 18 Nov 1998 11:53:14 +0100 (MET) From: Omar Elloumi Received: by pacman (SMI-8.6/rsalz-13-nov-89); Wed, 18 Nov 1998 11:53:13 +0100 Date: Wed, 18 Nov 1998 11:53:13 +0100 Message-Id: <199811181053.LAA02134@pacman> To: atm97authors@inesc.pt, atm96@inesc.pt, bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at Subject: ISCC CFP Cc: Hossam.Afifi@enst-bretagne.fr, Omar.Elloumi@enst-bretagne.fr X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My apologies if you receive multiple copies. Please note that the deadline is approaching. http://www.rennes.enst-bretagne.fr/~afifi/iscc.html -------- Final Call for Papers The Fourth IEEE Symposium on Computers and Communications ISCC'99 Sharm El Sheikh, Red Sea, Egypt July 6 - 8, 1999 Sponsored by* IEEE Communications Society and IEEE Computer Society** Continuing the tradition of this very highly attended series of symposia, ISCC'99 will provide an international technical forum for experts from industry and academia to exchange ideas and present results of ongoing research in the areas listed below. This year, special focus will be on the challenging issues related to the global reach of the Internet and its applications, that include the creation, management, dissemination, and communication of information. You are invited to submit a full paper, or a proposal for a panel, invited session, or tutorial, related to the following topics: Internet Services and Applications Electronic Commerce Security, Privacy and Information Access Digital Libraries and Content Hosting Multimedia Information Management and Exchange Internet Telephony Distributed Systems Architecture and Management Fault Tolerance and Error Recovery Nomadic Computing Wireless, Cellular, and Mobile Communications High Performance Networking and Protocols Intelligent Networks and Network Planning Network Design, Operation, and Management Control and Optimization of Communication Systems Network Reliability and Quality of Service Access Networks: xDSL, HFC, etc. Optical Systems and Networks Digital Satellite Communications Signal Processing in Communications and Networking Relevant Economic, Legal, and Social Issues Please send four copies of your original unpublished paper (not to exceed 20 double-spaced pages) to reach either Technical Program Co-Chair at the addresses below by December 1, 1998. A concise and representative abstract should be included. The paper should clearly indicate the complete postal and electronic mailing addresses, as well as the phone and fax numbers of the corresponding author. Prof.Dr. Radu Popescu-Zeletin Dr. Asser Tantawi Tech Program Co-Chair, ISCC'99 Tech Program Co-Chair, ISCC'99 GMD Fokus IBM Watson Research Center Kaiserin Augusta Allee 31 P.O. Box 704 D-10589 Berlin, GERMANY Yorktown Hts, NY 10598, USA Tel: +49 30 34 63 70 00 Tel: +1 (914) 784-7507 Fax: +49 30 34 63 80 00 Fax: +1 (914) 784-7455 zeletin@fokus.gmd.de tantawi@us.ibm.com Important Dates: ---------------- December 1, 1998 Paper submission deadline February 15, 1999 Notification of acceptance mailed to authors April 9, 1999 Final camera-ready manuscripts due Web Site: http://www.rennes.enst-bretagne.fr/~afifi/iscc.html From rem-conf Wed Nov 18 03:25:57 1998 From rem-conf-request@es.net Wed Nov 18 03:25:55 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zg5fG-0007DC-00; Wed, 18 Nov 1998 03:20:50 -0800 Received: from leporello.cs.unibo.it ([130.136.1.110] helo=CS.UniBO.IT) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zg5fD-0007Cw-00; Wed, 18 Nov 1998 03:20:47 -0800 Received: from susanna.cs.unibo.it (susanna.cs.unibo.it [130.136.2.6]) by CS.UniBO.IT (8.9.0/8.9.0) with SMTP id MAA21613 for ; Wed, 18 Nov 1998 12:20:02 +0100 (MET) Received: by susanna.cs.unibo.it (SMI-8.6/SMI-SVR4) id MAA21400; Wed, 18 Nov 1998 12:20:00 +0100 Date: Wed, 18 Nov 1998 12:20:00 +0100 From: cianca@CS.UniBO.IT (Paolo Ciancarini) Message-Id: <199811181120.MAA21400@susanna.cs.unibo.it> To: rem-conf@es.net Subject: Coordination99 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Our apologies if you receive multiple copies. Please note that the deadline is approaching. --------------- Call for Papers - Last Call COORDINATION '99 Third International Conference on Coordination Models and Languages Amsterdam, The Netherlands 26-28 April 1999 The last decade has seen the emergence of a class of models and languages variously termed "coordination languages", "configuration languages", "architectural description languages", and "agent-oriented programming languages". These formalisms provide a clean separation between individual software components and their interaction within the overall software organization. This separation makes large applications more tractable, supports global analysis, and enhances reuse of software. Building on the success of COORDINATION '96 and '97, whose proceedings were published as Springer Verlag LNCS 1061 and LNCS 1282, this conference provides a forum for the growing community of researchers interested in models, languages, and implementation techniques for coordination. Topics of interest include (but are not limited to): * Theoretical models and foundations for coordination: component composition, concurrency, mobility, dynamic aspects of coordination. * Specification, refinement, and analysis of software architectures: patterns and styles, verification of functional and non-functional properties. * Coordination, architectural, and interface definition languages: implementation, interoperability, heterogeneity. * Agent-oriented languages: formal models for interacting agents. * Dynamic software architectures: mobile agents, configuration, reconfiguration. * Tools and environments for the development of coordinated applications: integration within the development process. * Industrial relevance of coordination and software architectures: programming in the large, domain-specific software architectures and coordination models, case studies. Submission instructions: Authors are invited to send 6 copies of a full paper (in English, up to 6 000 words, preferably double-sided, please use LNCS style if you use LaTeX) at the postal address mentioned below. Full papers must be received no later than Nov 25 1998. Electronic submissions will not be considered. Simultaneous submission to other conferences or journals is not allowed. An abstract of no more than 250 words must be sent by email in ASCII format to coord99@cs.unibo.it. Included in the email must be the names and affiliations of all authors, and the full address information (address, phone, fax, email) of one contact author. The email abstract must be received by Nov 18 1998, one week before the full papers are due. Selection: Submissions should explicitly state their contribution and their relevance to the theme of the conference. Other criteria for selection will be originality, significance, correctness, and clarity. Conference location: Coordination '99 will be hosted by CWI in Amsterdam, NL. Information on CWI: http://www.cwi.nl Information on Amsterdam: http://www.cwi.nl/~steven/amsterdam.html http://www.cwi.nl/~behr/PanoramaUK/Panorama.html A copy of this CfP can be found at http://www.cs.unibo.it/~coord99/. IMPORTANT DATES Deadline for abstracts (email): Nov 18 1998 Deadline for paper submissions: Nov 25 1998 Notification of acceptance: Jan 28 1999 Camera-ready version due: Feb 26 1999 Conference: 26-28 April 1999 Address to send abstracts by e-mail: coord99@cs.unibo.it Address to send submissions: prof. P. Ciancarini Dipartimento di Scienze dell'Informazione Universita' di Bologna Mura Anteo Zamboni, 7 40127 Bologna - Italy Program co-chairs: Paolo Ciancarini (Italy) and Alexander Wolf (USA) Organizing Chairs: Farhad Arbab and Joost Kok (NL) Program Committee: Farhad Arbab (CWI/NL) Maarten Boasson (Signaal/NL) Nick Carriero (Yale/USA) Georges Gonthier (INRIA/F) Roberto Gorrieri (Bologna/Italy) Chris Hankin (IC/UK) Paola Inverardi (L'Aquila/Italy) Valerie Issarny (IRISA/F) Suresh Jagannathan (NEC/USA) Joost Kok (U.Leiden/NL) Jeff Kramer (IC/UK) Jose Meseguer (SRI/USA) Claudia Linnhoff-Popien (Aachen/D) Dewayne Perry (Bell Labs/USA) Antonio Porto (U.Lisbon/P) G. Catalin Roman (S. Louis/USA) Richard Taylor (UCI/USA) Robert Tolksdorf (TUBerlin/D) Mike Woolridge (QMC/UK) From rem-conf Wed Nov 18 06:40:52 1998 From rem-conf-request@es.net Wed Nov 18 06:40:51 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zg8g9-0001WE-00; Wed, 18 Nov 1998 06:33:57 -0800 Received: from rumor.research.att.com ([192.20.225.9]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zg8g5-0001W1-00; Wed, 18 Nov 1998 06:33:55 -0800 Received: from research.att.com ([135.207.30.100]) by rumor; Wed Nov 18 09:27:23 EST 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Wed Nov 18 09:32:05 EST 1998 Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id JAA06880; Wed, 18 Nov 1998 09:32:04 -0500 (EST) Message-ID: <02d601be1300$171b85c0$4683cf87@pcmrcfast.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Jonathan Rosenberg" Cc: "Mark Handley" , Subject: Re: Generic RTP Multiplexing Date: Wed, 18 Nov 1998 09:31:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I may multiplex them to reduce the overhead. In any case, this was an example intended to show the use. In MPEG-4, a multiplexing mechanism is needed for the reasons explained before and stated in Mark's draft. Additionally, a mechanism to identify the multiplexed payloads individually is needed because payloads with the same type and SSRC may be targeted to different objects/scenes at the receiver. This is similar to directing the MPEG1 packets to right and left channels at the receiver. ----------------------------------------------------------------------- M. Reha Civanlar Technology Leader, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc -----Original Message----- From: Jonathan Rosenberg To: M. Reha Civanlar Cc: Mark Handley ; rem-conf@es.net Date: Wednesday, November 18, 1998 2:09 AM Subject: Re: Generic RTP Multiplexing >M. Reha Civanlar wrote: >> >> It seems like for some applications including MPEG-4, we have >> to establish a mechanism for identifying the multiplexed payloads >> at the receiver. As a simple example, lets assume that I use MPEG1 >> to encode left and right channels of a 3D video presentation and send >> these streams multiplexed using GeRM. At the receiver, how would I >> assign the packets to the correct channel (left, right)? > >Normally the left and right channels would be in a single stream; I >think rfc1890 details how to multiplex the bytes. Why would you want to >split them into separate streams and then mux them with Germ? > >-Jonathan R. > > > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > From rem-conf Wed Nov 18 06:40:53 1998 From rem-conf-request@es.net Wed Nov 18 06:40:52 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zg8dv-0001V2-00; Wed, 18 Nov 1998 06:31:39 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zg8dt-0001Uj-00; Wed, 18 Nov 1998 06:31:37 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 18 Nov 1998 14:29:22 +0000 To: "M. Reha Civanlar" cc: Mark Handley , rem-conf Subject: Re: Generic RTP Multiplexing In-reply-to: Your message of "Tue, 17 Nov 1998 19:06:23 EST." <028901be1287$47bce800$4683cf87@pcmrcfast.research.att.com> Date: Wed, 18 Nov 1998 14:29:21 +0100 Message-ID: <25515.911399361@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> "M. Reha Civanlar" writes: >It seems like for some applications including MPEG-4, we have >to establish a mechanism for identifying the multiplexed payloads >at the receiver. As a simple example, lets assume that I use MPEG1 >to encode left and right channels of a 3D video presentation and send >these streams multiplexed using GeRM. At the receiver, how would I >assign the packets to the correct channel (left, right)? Use a different payload type number for each channel, even if they're using the same codec. An attribute in the SDP can specifiy which channel is mapped to each payload type. -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: +44 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf Wed Nov 18 10:21:25 1998 From rem-conf-request@es.net Wed Nov 18 10:21:24 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgC42-0004Z4-00; Wed, 18 Nov 1998 10:10:50 -0800 Received: from mail.utstar.com ([205.185.99.6] helo=Aries.utstar.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgC3z-0004Yu-00; Wed, 18 Nov 1998 10:10:48 -0800 Received: from ieee.org ([209.220.43.232]) by Aries.utstar.com (8.9.1/8.9.1) with ESMTP id MAA17180; Wed, 18 Nov 1998 12:52:52 -0500 (EST) Message-ID: <36530A4F.B38C7C39@ieee.org> Date: Wed, 18 Nov 1998 09:56:31 -0800 From: "Willie W.LU" Reply-To: wwlu@ieee.org Organization: IEEE Silicon Valley, USA X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: atm97authors@inesc.pt, atm96@inesc.pt CC: bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Subject: wmATM'99 in US References: <199811181053.LAA02134@pacman> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <<< My apologies if you receive multiple copies. >>> Dear Colleagues, For those still on the way to submit the technical contribution to wmATM'99 in Silicon Valley of US, please e-mail your extended summary to me ASAP by the end of this Month. For details about wmATM'99, please refer to: http://delson.org/tf-wmatm/wmatm99/ To catch up the wmATM enhanced 3G wireless HOT in Silicon Valley, submit your contribution to wmATM'99 now ! Thanks and regards. Sincerely, Willie W.Lu Chair, wmATM'99 Committee E-mail: wwlu@ieee.org From rem-conf Wed Nov 18 12:50:00 1998 From rem-conf-request@es.net Wed Nov 18 12:49:59 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgESa-0006d0-00; Wed, 18 Nov 1998 12:44:20 -0800 Received: from cs.columbia.edu ([128.59.16.20]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgESZ-0006cq-00; Wed, 18 Nov 1998 12:44:19 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA11280 for ; Wed, 18 Nov 1998 15:44:17 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA07313 for ; Wed, 18 Nov 1998 15:44:15 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3653319E.50A3CA16@cs.columbia.edu> Date: Wed, 18 Nov 1998 15:44:14 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: New DTMF draft: draft-ietf-avt-dtmf-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've just submitted a revision of the DTMF draft to the archives. You can find it at http://www.cs.columbia.edu/~hgs/rtp/payload.html in PS, PDF (with changebars) and ASCII. The draft incorporates minor 'bug fixes' and clarifications. I will be working with Scott Petrack to create a single draft after IETF, assuming we can reach rough consensus on approach and desirability within the WG. Another item to settle is the fate of section 4, the more compact scheme. Henning -- Henning Schulzrinne schulzrinne@cs.columbia.edu Dept. of Comp. Sci. ph +1 212 939-7042 Columbia University fax +1 212 666-0140 New York, NY 10027 http://www.cs.columbia.edu/~hgs From rem-conf Wed Nov 18 13:21:31 1998 From rem-conf-request@es.net Wed Nov 18 13:21:30 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgEzE-0007VB-00; Wed, 18 Nov 1998 13:18:04 -0800 Received: from e2.clubs.yahoo.com ([204.71.200.172]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgEzD-0007V0-00; Wed, 18 Nov 1998 13:18:03 -0800 Received: (from yahoo@localhost) by e2.clubs.yahoo.com (8.8.7/8.8.8) id NAA18377; Wed, 18 Nov 1998 13:04:16 -0800 (PST) Date: Wed, 18 Nov 1998 13:04:16 -0800 (PST) From: Yahoo! Clubs Message-Id: <199811182104.NAA18377@e2.clubs.yahoo.com> To: bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Reply-To: ramiro_g@mailexcite.com Subject: You're invited! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello! You have been invited by elparto to join the listed Yahoo! Club named "Internet Telephony". To become a member of this club, just go to the Web address below: http://edit.clubs.yahoo.com/config/sjg?.i=internettelephony&.a=i& You need to go to the address above to join the club, but you can take a look at the club by going to: http://clubs.yahoo.com/clubs/internettelephony You can learn more about elparto by looking at the Yahoo! Public Profile: http://profiles.yahoo.com/elparto A Yahoo! Club is a great way to bring friends, family or anyone you know together using the latest in Web technologies. Club members are able to take advantage of a club's private chat room, message boards and other features. You can also create your own free club focused on any interest, such as hobbies, families and industry associations. Clubs are either listed or unlisted. Listed clubs are available to the public while unlisted clubs are available exclusively to those who receive invitations. If you have no interest in joining this club, there is no need for you to do anything. You will not be enrolled as a member. Thanks, The Yahoo! Clubs team http://clubs.yahoo.com/ P.S. If you need some help on getting started, go to: http://help.yahoo.com/help/clubs/ From rem-conf Wed Nov 18 13:22:29 1998 From rem-conf-request@es.net Wed Nov 18 13:22:28 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgF1p-0007Ys-00; Wed, 18 Nov 1998 13:20:45 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgF1n-0007Yb-00; Wed, 18 Nov 1998 13:20:43 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id XAA20313 for ; Wed, 18 Nov 1998 23:17:56 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566C0.0075362B ; Wed, 18 Nov 1998 23:20:15 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: rem-conf@es.net Message-ID: <422566C0.00747469.00@il4.vocaltec.co.il> Date: Wed, 18 Nov 1998 23:18:14 +0200 Subject: draft-ietf-avt-tones-00.txt submitted Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have just submitted an internet draft which gives two new RTP payload formats: one for all the telephony signal events you could ever need (did you know that there are four separate dial tones in Germany?) one for telephone audio cadences. The payload format is backward compatible with draft-ietf-avt-dtmf-00.txt, so if that is a requirement it is satisfied. you can get it from http://www.vocaltec.com/~petrack/IETF/AVT/draft-ietf-avt-tones-00.txt RTP Payloads for Telephone Signal Events This note describes two RTP payload formats for in-band telephony signal events (TSE) such as DTMF, dial-tone, ring-tone, off-hook, SIT, etc. One payload is designed to carry a named signal, and the other is designed carry a compact representation of actual audio waveform cadence to be played. The two formats are independent, but they can be used together very usefully within redundant audio payloads; this enables highly efficient and robust transport of telephony network signal events along with a representation of the actual audio media associated to the signal events. Scott Petrack VocalTec Communications Ltd. petrack@vocaltec.com From rem-conf Wed Nov 18 18:11:54 1998 From rem-conf-request@es.net Wed Nov 18 18:11:52 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgJQx-0003Of-00; Wed, 18 Nov 1998 18:02:59 -0800 Received: from cs.columbia.edu ([128.59.16.20]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgJQu-0003OV-00; Wed, 18 Nov 1998 18:02:57 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA29067 for ; Wed, 18 Nov 1998 21:02:51 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA15168 for ; Wed, 18 Nov 1998 21:02:49 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <36537C49.39E633FD@cs.columbia.edu> Date: Wed, 18 Nov 1998 21:02:49 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Tones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In case people are interested in more telephone "folklore": a listing of all tones, from Albania to Zimbabwe, can be found at http://support.dialogic.com/resources/tones/. From rem-conf Thu Nov 19 02:56:25 1998 From rem-conf-request@es.net Thu Nov 19 02:56:24 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgRg4-0000BE-00; Thu, 19 Nov 1998 02:51:08 -0800 Received: from nscolmar.colmar.uha.fr ([194.167.108.34]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zgRfX-0000B0-00; Thu, 19 Nov 1998 02:50:40 -0800 Received: by nscolmar.colmar.uha.fr; (5.65v3.2/1.3/10May95) id AA21240; Thu, 19 Nov 1998 11:41:29 +0100 Message-Id: <3.0.5.32.19981119105448.007b41d0@colmar.colmar.uha.fr> X-Sender: lorenz@colmar.colmar.uha.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 19 Nov 1998 10:54:48 +0100 To: lorenz@colmar.colmar.uha.fr From: conf@colmar.uha.fr (by way of lorenz@colmar.colmar.uha.fr) Subject: Call for papers of ICATM'99 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We have enclosed the CFP for ICATM'99 below. Please feel free to circulate the CFP to interested colleagues. Please accept our sincere apologies if you receive multiple copies of this CFP. Best regards, __________________________________________________________________________ PRELIMINARY CALL FOR PAPERS=20 2nd International Conference on ATM ICATM'99 June 21-23, 1999 - Colmar, France GENERAL INFORMATION The 1999 International Conference on ATM (ICATM'99) is organized in cooperation with IEEE and the IEEE Communications Society on publication.=20 ICATM'99 is organized by academic, research and industrial societies will be held at the Technical Institute, Colmar, part of the University of Haute Alsace, France, from Monday June 21, 1999 to Wednesday June 23, 1999. The city of Colmar is ideally situated in the eastern part of France, near the German and Swiss borders. The city of Colmar has been working on its own Metropolitan Area Network (MAN) project, called OASICE, including LAN interconnection, PBX interconnection and interactive video. An exhibition illustrating these topics will be organized for industrial companies and development research institutes. In order to encourage closer interaction between academic and industrial ATM research communities, we solicit both academic research papers and industrial contributions.=20 TOPICS OF SPECIAL INTEREST Topics of interest include, but are not limited to the following: MPOA =09 LAN Emulation =09 IP over ATM, IPv6 over ATM =09 VLANs =09 High-Speed Routing =09 I-PNNI =09 NHRP =09 Java, Tina, Corba architectures =09 Interconnection =09 CTI (Computer Telephony Integration) =09 IP Switching, MPLS, Tag Switching, Fast IP, Aris ... Multicast ATM and Internet/Intranet Wireless ATM (LEO, MEO, GEO, from GSM to UMTS and IMT2000, Hyperlan2, ...) IP and ATM over xDSL Security IP and ATM Telephony Video (Davic, ...) Practical experiences results User applications QoS=20 WDM Scheduling=20 Resource allocation These topics can be discussed in term of concepts, state of the art, standards, implementations, performance, security and confidentiality, traffic management, running experiments, QoS (Quality of Service) and applications. INSTRUCTIONS FOR AUTHORS Mail four papers versions of a 2000-word extended abstract summarizing an original work. All the manuscripts must be written in English. The top of the first page of each paper should include the title of the paper, authors' name, position, address, telephone and fax numbers, e-mail of the author responsible for correspondence and a list of four keywords. The deadline for submission of all extended abstracts is December 10, 1998 with notification of acceptance by February 10, 1999. Submission of camera-ready paper is by March 30, 1999. Authors of accepted papers will be invited to submit full-length manuscripts for inclusion in the proceedings.=20 All submitted papers should be sent to the following address: Pascal LORENZ University of Haute Alsace IUT - Department GTR 34 rue du Grillenbreit 68008 Colmar, France Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042 E-mail: lorenz@colmar.uha.fr Check our Web page at http://iutsun1.colmar.uha.fr/ICATM99.html for the latest information concerning the conference. Best papers will be forwarded for consideration in a special issue of the journal Telecommunication Systems published by Baltzer Science Publishers. TUTORIALS AND WORKSHOPS Tutorials and workshops provide overviews of current high interest topics. Proposals for half of full day tutorials are due by December 10, 1999. ORGANIZATION OF ICATM'99 International Advisory Committee:=20 R. Addie (Australia) - University of Southern Queensland K. Begain (Jordan) - Mu'tah University B. Bing (Singapore) - Ngee Ann Polyechnic=09 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz J.P. Coudreuse (France) - Mitsubishi J. Crowcroft (UK) - University College London B. Gavish (USA) - Vanderbilt University J. Halpern (USA) - Newbridge R. Israel (France) - IEEE S. Komandur (USA) - Ascend Communications D. Kouvatsos (UK) - University of Bradford S. Kumar (USA) - Ericsson F. Le Faucheur (France) - Cisco P. Lorenz (France) - University of Haute Alsace J.J. Pansiot (France) - University of Strasbourg M. Potts (Switzerland) - Martel Z. Mammeri (France) - University of Le Havre S. Moyer (USA) - Bellcore R. Muraine (France) - Newbridge G. Pujolle (France) - University of Versailles-Saint-Quentin S. Rao (Switzerland) - Ascom A. Reid (UK) - British Telecom S. Ritzenthaler (France) - Newbridge P. Rolin (France) - ENST Bretagne R. Saracco (Italy) - CSELT G. Swallow (USA) - Cisco H. Tobiet (France) - Clemessy V.A. Villagra (Spain) - University of Madrid E. Vazquez Gallo (Spain) - University of Madrid IMPORTANT DATES Extended Abstract due: December 10, 1998 Notification of acceptance: February 10, 1999 Deadline for full-length camera-ready manuscript: March 30, 1999 ---------------------------------------------------------- Pascal LORENZ Universit=E9 de Haute Alsace IUT de Colmar - D=E9partement GTR 34 rue du Grillenbreit 68008 COLMAR - FRANCE Tel: 33 (0)3 89 20 23 66 - Fax: 33 (0)3 89 20 23 59 Mobile: 33 (0)6 03 65 80 42 Email: lorenz@colmar.uha.fr ----------------------------------------------------------- From rem-conf Thu Nov 19 06:38:19 1998 From rem-conf-request@es.net Thu Nov 19 06:38:18 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgV7t-0002Kp-00; Thu, 19 Nov 1998 06:32:05 -0800 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zgV7s-0002Ke-00; Thu, 19 Nov 1998 06:32:04 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Nov 19 09:30:23 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA19536; Thu, 19 Nov 1998 09:30:21 -0500 (EST) Message-ID: <36542AB3.6E14B08C@dnrc.bell-labs.com> Date: Thu, 19 Nov 1998 09:26:59 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "M. Reha Civanlar" CC: Mark Handley , rem-conf@es.net Subject: Re: Generic RTP Multiplexing References: <02d601be1300$171b85c0$4683cf87@pcmrcfast.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list M. Reha Civanlar wrote: > > I may multiplex them to reduce the overhead. You're still multiplexing them if you place the data into a single stream; the difference is in the granularity. In fact, the overhead of the muxing is less than if you use Germ to mux them. This is because you'll require one germ header for stream-muxing as opposed to two for treating them as separate sessions. > > In any case, this was an example intended to show the > use. In MPEG-4, a multiplexing mechanism is needed for > the reasons explained before and stated in Mark's draft. > Additionally, a mechanism to identify the multiplexed > payloads individually is needed because payloads with the > same type and SSRC may be targeted to different > objects/scenes at the receiver. In that case, shouldn't they have different SSRC since they really represent different media streams from the same user? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Nov 19 06:41:30 1998 From rem-conf-request@es.net Thu Nov 19 06:41:30 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgVEu-0002Q4-00; Thu, 19 Nov 1998 06:39:20 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgVEr-0002Pp-00; Thu, 19 Nov 1998 06:39:18 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id QAA05046; Thu, 19 Nov 1998 16:36:21 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566C1.00506AA6 ; Thu, 19 Nov 1998 16:38:21 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: Henning Schulzrinne cc: rem-conf@es.net Message-ID: <422566C1.00492E09.00@il4.vocaltec.co.il> Date: Thu, 19 Nov 1998 15:34:25 +0200 Subject: Re: Tones Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It is indeed fascinating reading, I agree. I would *love* to know the origin of the modulations at 16 2/3 Hz. If you're a good enough musician you can even hum some of the tones. More seriously, some comments/questions about what I did in the draft: 1. The original inspiration was MGCP and it's event packages. But I discovered that many of the MGCP events are US centric only; right now the list in the draft contains all the MGCP tones and all the ITU-T tones. If there are other named events that need to be added please let me know. 2. At first I tried to preserve the "packages" of MGCP, but I found that I didn't have enough bits to do this in any way but a flat namespace for events. Having thought about it a bit more, I think that a nicer solution might be to use a different PT for each "package." Thus we would define a family of codecs, one for each package, and register the name with IANA: "DTMF", "MF", "Trunk", "Line". The usual signalling of dynamic payload types (say SDP or H.245) would be used by applications to assign dynamic payload types to these "codecs." The payload type defined for "named events" would be unchanged, it's just that there would be a bit more order in the list, and exactly as in MGCP packages, it would be much easier to add new tones or new packages in the future. Such a scheme would then be an exact replacement for the MGCP scheme (except that it would retain all the nice time-synchronisation and multipoint features of RTP). 3. Although E.180 does not mention phase reversals, a friend told me that there are tone cadences where the phase of a tone is reversed every k msecs. Can someone confirm if this is true (I was told that it is the difference between a modem tone and a fax tone -- is this a V.8 issue?) If so, how many bits do I need to express "reverse the phase with frequency k"? 4. I toyed with extending the payload format to be slightly more general (for example, having independent volumes for each frequency). In the end I went for the simplest PT that will cover all telephony cadences. Scott Henning Schulzrinne on 11/19/98 04:02:49 AM To: rem-conf@es.net cc: (bcc: Scott Petrack) Subject: Tones In case people are interested in more telephone "folklore": a listing of all tones, from Albania to Zimbabwe, can be found at http://support.dialogic.com/resources/tones/. From rem-conf Thu Nov 19 07:18:12 1998 From rem-conf-request@es.net Thu Nov 19 07:18:11 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgVkz-0003lh-00; Thu, 19 Nov 1998 07:12:29 -0800 Received: from cs.columbia.edu ([128.59.16.20]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgVkx-0003lW-00; Thu, 19 Nov 1998 07:12:27 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA08281; Thu, 19 Nov 1998 10:12:23 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA28041; Thu, 19 Nov 1998 10:12:16 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <36543550.2F201C83@cs.columbia.edu> Date: Thu, 19 Nov 1998 10:12:16 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michah Lerner CC: "'Scott Petrack'" , rem-conf@es.net Subject: Re: Tones References: <25C33BBD0E6AD2119A1200A0C9D7D72501C6C5@exchlzcl.ipo.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michah Lerner wrote: > > I think some of the tones were selected to avoid harmonics and secondary > frequencies, for example to be reasonably independent of 60-cycle hum. > //m 16 2/3 Hz is also the frequency of US railroad AC current, I believe. Since tones were originally generated by motors, this may have had an influence (or common motivation). Obviously, it's 1/3 of 60 Hz. Most tones are around 440 Hz, the musical note 'a' and the standard tuning/reference frequency. From rem-conf Thu Nov 19 08:07:00 1998 From rem-conf-request@es.net Thu Nov 19 08:06:59 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgWVr-0004jw-00; Thu, 19 Nov 1998 08:00:55 -0800 Received: from gate.geoplex.com ([135.197.57.2] helo=sjgw.ipo.att.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgWVq-0004ji-00; Thu, 19 Nov 1998 08:00:54 -0800 Received: from exchsj01.ipo.att.com (exchsj01.ipo.att.com [135.197.41.8]) by sjgw.ipo.att.com (8.8.5/8.8.8) with ESMTP id IAA01592; Thu, 19 Nov 1998 08:00:21 -0800 (PST) Received: by EXCHSJ01 with Internet Mail Service (5.5.1960.3) id ; Thu, 19 Nov 1998 07:58:09 -0800 Message-ID: <25C33BBD0E6AD2119A1200A0C9D7D72501C6C6@exchlzcl.ipo.att.com> From: Michah Lerner To: "'Henning Schulzrinne'" , Michah Lerner Cc: "'Scott Petrack'" , rem-conf@es.net Subject: RE: Tones Date: Thu, 19 Nov 1998 08:00:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning is right. I was referring specifically to test-tones which are selected to avoid widely used frequencies and harmonics. //Michah -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, November 19, 1998 10:12 AM To: Michah Lerner Cc: 'Scott Petrack'; rem-conf@es.net Subject: Re: Tones Michah Lerner wrote: > > I think some of the tones were selected to avoid harmonics and secondary > frequencies, for example to be reasonably independent of 60-cycle hum. > //m 16 2/3 Hz is also the frequency of US railroad AC current, I believe. Since tones were originally generated by motors, this may have had an influence (or common motivation). Obviously, it's 1/3 of 60 Hz. Most tones are around 440 Hz, the musical note 'a' and the standard tuning/reference frequency. From rem-conf Thu Nov 19 08:32:54 1998 From rem-conf-request@es.net Thu Nov 19 08:32:53 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgWz9-0005gG-00; Thu, 19 Nov 1998 08:31:11 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgWz7-0005fC-00; Thu, 19 Nov 1998 08:31:09 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA13118; Thu, 19 Nov 1998 11:30:35 -0500 (EST) Message-Id: <199811191630.LAA13118@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-interleaving-00.txt Date: Thu, 19 Nov 1998 11:30:34 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 Interleaved Media Author(s) : C. Perkins Filename : draft-ietf-avt-interleaving-00.txt Pages : 6 Date : 18-Nov-98 This memo defines an interleaving scheme for RTP streams. This scheme is derived from the RTP payload format for redundant audio data [3] and hence is targetted primarily at streamed audio, although it may be of use in other scenarios. Internet-Drafts are 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-interleaving-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-interleaving-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-interleaving-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: <19981118102856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-interleaving-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-interleaving-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981118102856.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Nov 19 13:29:22 1998 From Peter.Cole@telescan.com Thu Nov 19 13:29:21 1998 Received: from exchange1.telescan.com ([204.251.138.227]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgbWi-0001QM-00; Thu, 19 Nov 1998 13:22:09 -0800 Received: by exchange1.telescan.com with Internet Mail Service (5.5.2232.9) id ; Thu, 19 Nov 1998 15:21:24 -0600 Message-ID: <81831E1053A2D111A03800805FEFA27D04C79C@exchange1.telescan.com> From: Peter Cole To: "'rem-conf-dist@es.net'" Subject: remove Date: Thu, 19 Nov 1998 15:21:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain remove From rem-conf Thu Nov 19 14:21:52 1998 From rem-conf-request@es.net Thu Nov 19 14:21:52 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgcRD-0002RD-00; Thu, 19 Nov 1998 14:20:31 -0800 Received: from ganymede.or.intel.com ([134.134.248.3]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zgcRC-0002Q8-00; Thu, 19 Nov 1998 14:20:30 -0800 Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id WAA19236; Thu, 19 Nov 1998 22:20:15 GMT Received: from mbaugher-desk.jf.intel.com (mbaugher-desk.jf.intel.com [192.198.161.123]) by ideal.jf.intel.com (8.9.0/8.9.0) with SMTP id OAA08266; Thu, 19 Nov 1998 14:20:09 -0800 (PST) From: Mark Baugher Message-Id: <199811192220.OAA08266@ideal.jf.intel.com> Sender: "Mark Baugher" To: "'Marek Kotelba'" Cc: , , , , , , , , , Subject: RE: Comments on draft-ietf-avt-rtp-mib-02.txt Date: Thu, 19 Nov 1998 14:20:02 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <199811132106.QAA17719@alpo.casc.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hi Marek, Is this a valid summary of what you want? 1. Don't use an integer as the sole index into any MIB table. 2. Index the rtpSessionTable by the session addresses so conceptual rows may be accessed by session addresses. 3. Always include an IP address as part of every table index so the SNMP Agent can demultiplex SNMP requests to the appropriate agent in a switch. I have some comments below. > -----Original Message----- > From: Marek Kotelba [mailto:mkotelba@ascend.com] > Sent: Friday, November 13, 1998 1:05 PM > To: mbaugher@intel.com; John.Du@intel.com; Stan_Naudus@3com.com > Cc: gkajos@videoserver.com; isuconick@videoserver.com; > amalis@ascend.com; jwest@ascend.com; cpazos@ascend.com; > gnair@ascend.com; jzhu@ascend.com; francois.audet@nortel.ca > Subject: Comments on draft-ietf-avt-rtp-mib-02.txt > > > Hi guys, > > My name is Marek Kotelba and I work for Ascend Communications Core > Switching Division in Westford, MA. We are currently working > on a project > to add the H.323 support on our ATM switches. Carlos Pazos and I have > proposed a new call signaling architecture and RTP > compression scheme for > transporting H.323 media streams over ATM SVCs. This new architecture > requires a new type of an H.323 entity: an H.323-to-H.323 > gateway. (For > reference, you may want to consult the ATM Forum baseline text in > btd-saa-rmoa-01_05.doc). > > As part of our project we are planning to implement the RTP > MIB. I read > your draft and have one fundamental comment on Section 4.5, SNMP > Implementations. I think it will be difficult to use the > proposed RTP MIB > in situation where multiple RTP entities contribute to the same tables > indexed by just the rtpSessionIndex. > > Consider that on the core switch, there may be a need to > support perhaps > tens of thousands of RTP connections. The switch has a single > SNMP agent > and many distributed H.323-to-H.323 gateways. According to > section 4.5, Section 4.5 was not intended to prescribe a particular implementation approach to the RTP MIB. How you implement the MIB is outside of the scope of the RTP MIB specification. I apologize if this section is confusing; we removed it from the latest draft that was submitted to internet-drafts yesterday. > each such gateway would have to contact a central session > index generator > on the switch whenever a new RTP session is created or > deleted. There are 2 How does your switch implement the IF-MIB's ifTestTable which uses a TestAndIncr object? What standard MIBs does your switch support? Have you extended them in order to support your special requirements? > reasons for that: the session index must be unique within the > switch, and > the SNMP agent needs to now how to direct an SNMP request to > the proper > gateway in the distributed system. That global index > management would chew > up a lot of resources. > > Next, consider a network administrator who needs to obtain > statistics for a > specific connection, say in a "help-desk" scenario that you mention in > Section 4.3.1. Since the rtpSessionIndex is arbitrary (has no > relation to > any protocol value) the administrator would need to browse > the entire (or > half on average) session table to find the session of > interest. Given the > number of connections supported on the switch and the slow > speed of SNMP, > this is impractical. Using an integer index is intended to reduce overhead. The alternative in rtpSessionTable is to index the table by the four objects that make each conceptual row unique. These are 1) rtpSessionRemAddr 2) rtpSessionLocAddr 3) rtpSessionIfIndex 4) rtpSessionIfAddr A Get operation would have to supply the OIDs with the values of each of these objects and would result in a lot of message overhead and more processing in the RTP Agent. I think that it's preferable to use an integer index into this table if it can be satisfactorily implemented. I'm not convinced yet that it cannot. We have considered adding a table to the RTP MIB to enable a network manager to access an rtpSessionTable conceptual row by identifying a specific connection (rtpSessionRemAddr and rtpSessionLocAddr). We would do this by having a second table that was indexed by the four objects and which would contain the rtpSessionIndex as a column in each conceptual row. To solve the problem that you describe, the network manager would lookup the rtpSessionIndex in the second table and then use it as the index in the rtpSessionTable. Would this work for you? > > Therefore, I would like to propose that all RTP MIB objects receive an > additional index in the form of the IP address of the entity > to which the > SNMP request pertains. That is, all global objects (e.g., > rtpSessionNewIndex) should be grouped in a new table, and > each existing > table should be given one more index. I don't get it. If we did this, how would it help with the problem of retrieving an entry from the rtpSessionTable using rtpSessionRemAddr and rtpSessionLocAddr - the problem discussed immediately above where you said you wanted to access rtpSessionTable for a specific connection? > > This would facilitate a direct access to the given RTP entity and > significantly reduce the number of sessions in the scope. For > a host, this > additional index would simply have the same value as the > address of the > SNMP agent. > > Please let me know what you think. I think that there are three requests here and not one. Do you agree with my assessment? regards,Mark > > Thanks, > Marek > From rem-conf Thu Nov 19 15:44:29 1998 From rem-conf-request@es.net Thu Nov 19 15:44:28 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgdg3-0003uN-00; Thu, 19 Nov 1998 15:39:55 -0800 Received: from rumor.research.att.com ([192.20.225.9]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zgdg1-0003uD-00; Thu, 19 Nov 1998 15:39:53 -0800 Received: from research.att.com ([135.207.30.100]) by rumor; Thu Nov 19 18:33:16 EST 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Thu Nov 19 18:38:04 EST 1998 Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id SAA00506; Thu, 19 Nov 1998 18:38:02 -0500 (EST) Message-ID: <05dd01be1415$84dd0aa0$4683cf87@pcmrcfast.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Jonathan Rosenberg" Cc: "Mark Handley" , Subject: Re: Generic RTP Multiplexing Date: Thu, 19 Nov 1998 17:58:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----Original Message----- From: Jonathan Rosenberg >M. Reha Civanlar wrote: >> >> I may multiplex them to reduce the overhead. > >You're still multiplexing them if you place the data into a single >stream; the difference is in the granularity. In fact, the overhead of >the muxing is less than if you use Germ to mux them. This is because >you'll require one germ header for stream-muxing as opposed to two for >treating them as separate sessions. I think, I am using the Germ header so that I don't need to use the complete RTP header for both. Particularly for this application, I can save a great deal by not transmitting areas 0, 1, 2, 4 and 6 because, the two streams consist of right and left pictures sampled at the same instant. >> In any case, this was an example intended to show the >> use. In MPEG-4, a multiplexing mechanism is needed for >> the reasons explained before and stated in Mark's draft. >> Additionally, a mechanism to identify the multiplexed >> payloads individually is needed because payloads with the >> same type and SSRC may be targeted to different >> objects/scenes at the receiver. > >In that case, shouldn't they have different SSRC since they really >represent different media streams from the same user? > >-Jonathan R. They may be considered to be different media streams, but why can't they share the same synch. source. I believe, the current draft does not outlaw this. ----------------------------------------------------------------------- M. Reha Civanlar Technology Leader, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf Thu Nov 19 16:01:23 1998 From rem-conf-request@es.net Thu Nov 19 16:01:22 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgdzd-0004kG-00; Thu, 19 Nov 1998 16:00:09 -0800 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zgdzc-0004k0-00; Thu, 19 Nov 1998 16:00:08 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Nov 19 18:58:38 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA13663; Thu, 19 Nov 1998 18:58:37 -0500 (EST) Message-ID: <3654AFE0.790E4B96@dnrc.bell-labs.com> Date: Thu, 19 Nov 1998 18:55:13 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "M. Reha Civanlar" CC: Mark Handley , rem-conf@es.net Subject: Re: Generic RTP Multiplexing References: <05dd01be1415$84dd0aa0$4683cf87@pcmrcfast.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list M. Reha Civanlar wrote: > > > They may be considered to be different media streams, but why can't > they share the same synch. source. I believe, the current draft does not > outlaw this. The main function of the SSRC, however, is to demultiplex data from different senders and identify which sender its from. This is exactly what you want to do (where sender is not a different person, but a different stream from the same person). I would ask the opposite - why would you want to use the same SSRC? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Nov 19 16:08:46 1998 From Adil.Khan.adil@nt.com Thu Nov 19 16:08:45 1998 Received: from smtpott1.nortel.ca ([192.58.194.78]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf-dist@es.net id 0zge7F-0005LH-00; Thu, 19 Nov 1998 16:08:01 -0800 Received: from zcard00m.ca.nortel.com (actually 47.2.0.111) by smtpott1; Thu, 19 Nov 1998 19:07:27 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id ; Thu, 19 Nov 1998 17:15:52 -0500 Message-ID: From: "Adil Khan" To: "'rem-conf-dist@es.net'" Subject: remove Date: Thu, 19 Nov 1998 17:15:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain > remove From rem-conf Fri Nov 20 11:23:44 1998 From rem-conf-request@es.net Fri Nov 20 11:23:42 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgvuS-00077M-00; Fri, 20 Nov 1998 11:08:00 -0800 Received: from rumor.research.att.com ([192.20.225.9]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zgvuR-00076s-00; Fri, 20 Nov 1998 11:07:59 -0800 Received: from research.att.com ([135.207.30.100]) by rumor; Fri Nov 20 14:01:17 EST 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Fri Nov 20 14:05:19 EST 1998 Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA19294; Fri, 20 Nov 1998 14:05:13 -0500 (EST) Message-ID: <075601be14b8$93cb3a20$4683cf87@pcmrcfast.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Jonathan Rosenberg" Cc: "Mark Handley" , Subject: Re: Generic RTP Multiplexing Date: Fri, 20 Nov 1998 14:04:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----Original Message----- From: Jonathan Rosenberg >The main function of the SSRC, however, is to demultiplex data from >different senders and identify which sender its from. This is exactly >what you want to do (where sender is not a different person, but a >different stream from the same person). I would ask the opposite - why >would you want to use the same SSRC? One problem with this, particularly when MPEG-4 streams are multiplexed, is that SSRC is not a part of SDP. Therefore, if I need to treat a particular stream differently during the presentation at the receiver, e.g. apply an audio signal to the left speaker, I have no place to specify it based on SSRC. Moreover, SSRCs may change in the middle of a session. ----------------------------------------------------------------------- M. Reha Civanlar Technology Leader, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf Fri Nov 20 13:31:07 1998 From rem-conf-request@es.net Fri Nov 20 13:31:05 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgy3A-00013x-00; Fri, 20 Nov 1998 13:25:08 -0800 Received: from f320.hotmail.com ([207.82.250.240] helo=hotmail.com) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zgy38-00013j-00; Fri, 20 Nov 1998 13:25:06 -0800 Received: (qmail 7409 invoked by uid 0); 20 Nov 1998 21:24:35 -0000 Message-ID: <19981120212435.7408.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Fri, 20 Nov 1998 13:24:34 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: rem-conf@es.net Cc: nschneid@hotmail.com Subject: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Fri, 20 Nov 1998 13:24:34 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have a proposition for VoIP applications to reduce rtp-mux header overhead. If all vocoders produce packets at constant rates (with constant frame sizes), is there really a need for any timestamps, and in the case of multiplexing, timestamp offsets? Would it not be simpler to negotiate the sample rate at call set-up, and mearely use sequence numbers to calculate jitter buffers and lost packets? Even if a vocoder produces inconsistant data lenghts (in the case of a adaptive compression algorithms, or when a VAD is utilized), couldn't the rate of packet creation stay constant, thus eliminating robust timing calculations? In a worst case situation, say 1ms samples, with a maximum latency of 400 ms, only 9 bits would be necessary to retain all of the necessary information point to point for jitter calculations. This way, the _original_ information is kept, rather than implementing timestamp offset calculations for multiplexing irregular data arrival times. This would become more critical in the case of multiple RTP hops along the network. If the end user, necessarily needs a timestamp, it could be recreated based on a preset sampling period and the sequence number. Is there any reason to keep the timestamp if the sampling period is remains constant? Regards, Neal A. Schneider ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Fri Nov 20 14:01:07 1998 From rem-conf-request@es.net Fri Nov 20 14:01:05 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zgyZ5-0001vQ-00; Fri, 20 Nov 1998 13:58:07 -0800 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zgyZ3-0001vE-00; Fri, 20 Nov 1998 13:58:05 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Nov 20 16:56:51 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA16406; Fri, 20 Nov 1998 16:56:50 -0500 (EST) Message-ID: <3655E4D2.4719B35@dnrc.bell-labs.com> Date: Fri, 20 Nov 1998 16:53:22 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Neal Schneider CC: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981120212435.7408.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Neal Schneider wrote: > > I have a proposition for VoIP applications to reduce rtp-mux header > overhead. If all vocoders produce packets at constant rates (with > constant frame sizes), is there really a need for any timestamps, and in > the case of multiplexing, timestamp offsets? Would it not be simpler to > negotiate the sample rate at call set-up, and mearely use sequence > numbers to calculate jitter buffers and lost packets? As with anything else, there is an engineering tradeoff. In the case of RTP, and RTP mux in particular, there is primarily a tradeoff between overhead and flexibility. RTP itself is designed more with flexibility in mind, making it more modular and applicable to a wide range of applications, not just voice. In the case of gateway to gateway communication, I believe a timestamp is still needed for each packet. This is because the time itself increases during silence periods, but the sequence number will not (assuming you send nothing during silence). I agree that no timestamps are needed if you assume there is no silence detection. To adequately reconstruct the silence periods, you will want a timestamp. Interestingly, for gw-gw communications, no packets are sent only if all users are in silence. This is unlikely for large degrees of multiplexing, but very likely for low degrees of multiplexing. If there was at least one user in a talkspurt at all points in time, you could get away with no timestamps, as you suggest, even with silence detection. You could also avoid the use of timestamps if you assume there is no network (or very little) jitter. Again, flexibility vs. efficiency. I'd personally rather have the protocol work for both best-effort networks and for tightly managed networks, where the jitter may in fact be small. Whether or not an offset is needed again depends on flexibility. I'd really be interested to hear from gateway vendors about whether their gateways can/do generate frames that are not synchronized. Our current proposal (draft-ietf-avt-aggregation-00) assumes synchronization and uses no offsets. These various tradeoffs, including your proposition, are discussed in detail in draft-ietf-avt-muxissues-00.txt. I believe part of the difficult we are having in reaching any consensus is a lack of requirements. This multiplexing problem is not terribly hard, and the solution really falls right out of the requirements. So, perhaps we should talk not about one protocol vs. another at this point, but figure out what people want it to support. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Nov 21 20:11:40 1998 From rem-conf-request@es.net Sat Nov 21 20:11:39 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zhQb8-0006P2-00; Sat, 21 Nov 1998 19:54:06 -0800 Received: from milagro.dirac.es ([194.224.142.2]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zhQb7-0006Os-00; Sat, 21 Nov 1998 19:54:05 -0800 Received: from earthlink.net (unverified [206.175.107.142]) by milagro.dirac.es (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 22 Nov 1998 04:51:33 +0100 Message-ID: To: From: Subject: UNIVERSITY DEGREE PROGRAMS. Date: Sat, 21 Nov 1998 19:20:34 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UNIVERSITY DEGREE PROGRAMS Increase your personal prestige and money earning power through an advanced university degree. Eminent, non-accredited universities will award you a degree for only $200. Degree granted based on your present knowledge and experience. No further effort necessary on your part. Just a short phone call is all that is required for a BA, MA, MBA, or PhD diploma in the field of your choice. For details, call 770-492-2925 BR7 From rem-conf Sun Nov 22 06:46:13 1998 From rem-conf-request@es.net Sun Nov 22 06:46:12 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zhafW-0003E6-00; Sun, 22 Nov 1998 06:39:18 -0800 Received: from sumo.vocaltec.co.il ([199.203.72.1]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zhafS-0003Dw-00; Sun, 22 Nov 1998 06:39:15 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id QAA01242; Sun, 22 Nov 1998 16:36:17 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566C4.005073E2 ; Sun, 22 Nov 1998 16:38:45 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: Henning Schulzrinne cc: rem-conf@es.net Message-ID: <422566C4.002A5C9B.00@il4.vocaltec.co.il> Date: Sun, 22 Nov 1998 11:25:09 +0200 Subject: A totally different (simpler?) approach to tones and errata Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=knG3woOS18KxrcDQoO1XomyQn7HgY72rMwpB65E0cpu2GEzbctkLdz8K" Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --0__=knG3woOS18KxrcDQoO1XomyQn7HgY72rMwpB65E0cpu2GEzbctkLdz8K Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sorry to drive us all crazy, but I just discovered two things that suggest we might want a different, much simpler approach to the telephone tones payload format: >From E.180 supp 2 (you can see it at the Dialogic URL given by Henning) it seems that Hungarian "special dial tone" in fact a combination of three frequencies (350+375+400 CONTINUOUS). At first I was going to suggest that we need three frequencies in the frequency format. But this bothered me a lot: what if we missed out something else? I have already mentioned that we might need to worry about tones that reverse phase at regular intervals. I have also heard a rumour of some other more complicated tones. But it turns out that there is a simple solution: It turns out that if you list all the possible combinations of frequencies that appear in the entire E.180 supp2 (which is the document that Henning pointed to at www.dialogic.com), there are only 111 possibilities. By "combinations of frequencies" I mean both pairs of frequencies that are summed, and pairs of frequencies in which one frequency modulates the other. I took the middle column of E.180 supp2, ran sort and uniq, and came up with 111 lines. Here is an extract of the resulting table, just to give an idea: ... 425 425+330 425+350 425+400 425+450 425+475 425 --0__=knG3woOS18KxrcDQoO1XomyQn7HgY72rMwpB65E0cpu2GEzbctkLdz8K Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable =D724 425=D725 425=D750 ... Perhaps it is better to just use the simpler Named Signal Event payload= format for these "Frequency events". We would use the event field to name a line in the table of frequency combinations. (This is identical to what we do for DTMF , where we give a special Event name t= o a particular combination of two frequencies). If we did this, we would have a single payload format, sp= lit into different "event families" or "packages", signalled by dynamic payload type: Line events (including DTMF, SIT, etc.) Trunk events (including MF, wink, etc.) PABX events Frequency events. We would still use RFC 2198 in order to allow the frequency cadences ba= ck up the named signal events. The advantage is a single payload format, and a much simpler architectu= re. The disadvantage is a certain lack of flexibility. But as I said, this= will cover all known telephone cadences, with over 100 places for future tone combinations. In fact, maybe this scheme is in fact more flexible, in that we will be able to add future frequency combinations even they do not happen to fit into the scheme we gave for tone frequency signals. I am going to write a new version of the tone encodings to reflect this= simpler approach. Comments? Scott = --0__=knG3woOS18KxrcDQoO1XomyQn7HgY72rMwpB65E0cpu2GEzbctkLdz8K-- From rem-conf Sun Nov 22 08:14:31 1998 From rem-conf-request@es.net Sun Nov 22 08:14:30 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zhc2N-0004Zv-00; Sun, 22 Nov 1998 08:06:59 -0800 Received: from ece.ee.duke.edu ([152.3.17.193] helo=ee.duke.edu) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zhc2M-0004Zl-00; Sun, 22 Nov 1998 08:06:58 -0800 Received: from localhost by ee.duke.edu (8.9.1a/8.9.1) with ESMTP id KAA09121; Sun, 22 Nov 1998 10:52:39 -0500 (EST) Date: Sun, 22 Nov 1998 10:52:39 -0500 (EST) From: Erol Gelenbe To: Omar Elloumi cc: atm97authors@inesc.pt, atm96@inesc.pt, bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Subject: Another Reminder .. In-Reply-To: <199811181053.LAA02134@pacman> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Sun Nov 22 08:14:31 1998 From rem-conf-request@es.net Sun Nov 22 08:14:30 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zhc2W-0004a7-00; Sun, 22 Nov 1998 08:07:08 -0800 Received: from ece.ee.duke.edu ([152.3.17.193] helo=ee.duke.edu) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zhc2V-0004Zx-00; Sun, 22 Nov 1998 08:07:07 -0800 Received: from localhost by ee.duke.edu (8.9.1a/8.9.1) with ESMTP id KAA09145; Sun, 22 Nov 1998 10:53:27 -0500 (EST) Date: Sun, 22 Nov 1998 10:53:27 -0500 (EST) From: Erol Gelenbe To: Omar Elloumi cc: atm97authors@inesc.pt, atm96@inesc.pt, bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Subject: Performance 99 In-Reply-To: <199811181053.LAA02134@pacman> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IFIP WG 7.3 Performance 99 Conference in Istanbul, Turkey, Aug 22-25, 1999 Conference Site Web Page: www.boun.edu.tr Deadline for submitting full papers or extended abstracts is December 1, 1998 - Submissions in electronic format should be sent to Dr. Raif Onvural at: ronvural@oro-logic.nctda.org From rem-conf Sun Nov 22 08:15:55 1998 From rem-conf-request@es.net Sun Nov 22 08:15:55 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zhc9J-0004dl-00; Sun, 22 Nov 1998 08:14:09 -0800 Received: from ece.ee.duke.edu ([152.3.17.193] helo=ee.duke.edu) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zhc9H-0004db-00; Sun, 22 Nov 1998 08:14:07 -0800 Received: from localhost by ee.duke.edu (8.9.1a/8.9.1) with ESMTP id LAA10330; Sun, 22 Nov 1998 11:00:13 -0500 (EST) Date: Sun, 22 Nov 1998 11:00:13 -0500 (EST) From: Erol Gelenbe To: "Willie W.LU" cc: atm97authors@inesc.pt, atm96@inesc.pt, bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Subject: Performance 99 In-Reply-To: <36530A4F.B38C7C39@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IFIP WG 7.3 Performance 99 Conference in Istanbul, Turkey, Aug 22-25, 1999 Conference Site Web Page: www.boun.edu.tr Deadline for submitting full papers or extended abstracts is December 1, 1998 - Submissions in electronic format should be sent to Dr. Raif Onvural at: ronvural@oro-logic.nctda.org From rem-conf Sun Nov 22 09:26:00 1998 From rem-conf-request@es.net Sun Nov 22 09:25:59 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zhdCm-00075w-00; Sun, 22 Nov 1998 09:21:48 -0800 Received: from cs.columbia.edu ([128.59.16.20]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zhdCl-00075m-00; Sun, 22 Nov 1998 09:21:47 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA11453; Sun, 22 Nov 1998 12:21:44 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA06840; Sun, 22 Nov 1998 12:21:42 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <36584826.E5FFE589@cs.columbia.edu> Date: Sun, 22 Nov 1998 12:21:42 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@es.net Subject: Re: A totally different (simpler?) approach to tones and errata References: <422566C4.002A5C9B.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scott Petrack wrote: > > Sorry to drive us all crazy, but I just discovered two things that suggest > we might want a different, much simpler approach to the telephone tones > payload format: > > > But it turns out that there is a simple solution: > > It turns out that if you list all the possible combinations of frequencies > that appear in the entire > E.180 supp2 (which is the document that Henning pointed to at > www.dialogic.com), there are > only 111 possibilities. By "combinations of frequencies" I mean both pairs > of frequencies that > are summed, and pairs of frequencies in which one frequency modulates the > other. I'm not I agree. Enumerating combinations assumes (a) that every entity recognizes the tones as precisely those tones and can thus map to the index; (b) that new tones are added very infrequently. In more detail: (a) If tones are generated from the signal, mapping to the index is reasonably easy. If however, a PSTN-connected entity does signal detection from a live signal, it is much harder, since it has to artificially find a mapping, even though its measurement is going to be imprecise. It seems far easier to have a filter bank for the common frequencies or an FFT (easily implemented for a DSP) that picks the strongest frequency components. (b) is necessary since if a receiver gets an index it does not recognize, it has absolutely no idea how to render it, since it could be anything from a dial tone to a SIT. At least with the special signals, if we structure the name space accordingly, we can have properties similar to that for SIP/HTTP/SMTP response codes: the class is good enough for a first-order approximation. I may not recognize the new "Dialtone V" in Germany, but rendering it as "dial tone" is probably pretty good. For rendition, ultimate precision is not necessary. Thus, even if the 350+375+400 tone is rendered as 350+375, it will be close enough for all but those with perfect pitch. A problem arises only if there were another continuous tone in Hungary with just 350+375 (which there isn't). In terms of phase changes, I doubt that human ears and FFT/filter-bank detectors are able to detect this, so I wouldn't worry too much about it. Thus, I would use a 3-tone plus modulation scheme which is easy to generate by filter banks or FFTs. If the tone is really a signal, the signal name is preferable, but with a suitable grouping, so that additions are easy. It should be noted that you can use the frequency/tone representations to play a good rendition of the music-on-hold classic "Greensleeves" :-) It will sound much better than a 5.3 kb/s rendition over G.723. (Yes, and the parallels to MIDI are duly noted. I still need to write that one up - we did an implementation a while ago. Indeed, maybe somebody with more musical training can check whether all tones are indeed found in a standard scale. What kind of chord is the Hungarian special dial tone?) Henning From rem-conf Mon Nov 23 10:13:52 1998 From rem-conf-request@es.net Mon Nov 23 10:13:51 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zi0DJ-0003fy-00; Mon, 23 Nov 1998 09:55:53 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp ([133.82.241.137] ident=root) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zi0DI-0003fo-00; Mon, 23 Nov 1998 09:55:52 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp (yozo@localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.9.1/8.9.1) with ESMTP id CAA27446; Tue, 24 Nov 1998 02:55:22 +0900 (JST) Message-Id: <199811231755.CAA27446@aohakobe.ipc.chiba-u.ac.jp> To: Angel Mateo cc: rem-conf@es.net Subject: Re: mrouted with snmp In-reply-to: Your message of "Fri, 06 Nov 1998 14:07:11 +0100." <199811061307.OAA07431@news.rediris.es> Date: Tue, 24 Nov 1998 02:55:21 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > has anybody mrouted release 3.9beta3 compiled with snmp support for SGI IRIX > 6.3? Angel, I happen to be able to access O2 machine(IRIX 6.3) and tried to compile mrouted-3.9-beta3. modifying several files I succeed to compile now. I don't have a privilege account on the machine, so, I cannot check if it work or not. please tell me if you try and it works well. or you can access it through ftp, too. -- yozo. From rem-conf Mon Nov 23 11:41:49 1998 From rem-conf-request@es.net Mon Nov 23 11:41:48 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zi1m1-0005AP-00; Mon, 23 Nov 1998 11:35:49 -0800 Received: from f280.hotmail.com ([207.82.251.171] helo=hotmail.com) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zi1lz-0005AF-00; Mon, 23 Nov 1998 11:35:47 -0800 Received: (qmail 23984 invoked by uid 0); 23 Nov 1998 19:35:16 -0000 Message-ID: <19981123193516.23981.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Mon, 23 Nov 1998 11:35:15 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: jdrosen@dnrc.bell-labs.com Cc: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 23 Nov 1998 11:35:15 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >As with anything else, there is an engineering tradeoff. In the case of >RTP, and RTP mux in particular, there is primarily a tradeoff between >overhead and flexibility. RTP itself is designed more with flexibility >in mind, making it more modular and applicable to a wide range of >applications, not just voice. Yes, but if the VoIP market expands greatly over the next few years, the study will focus from RTP recommendations to industry standards. The convergence of voice and data, in particular, could easily demand it's own specific RTP format, especially in multiplexing. > >In the case of gateway to gateway communication, I believe a timestamp >is still needed for each packet. This is because the time itself >increases during silence periods, but the sequence number will not >(assuming you send nothing during silence). I agree that no timestamps >are needed if you assume there is no silence detection. To adequately >reconstruct the silence periods, you will want a timestamp. >Interestingly, for gw-gw communications, no packets are sent only if all >users are in silence. This is unlikely for large degrees of >multiplexing, but very likely for low degrees of multiplexing. If there >was at least one user in a talkspurt at all points in time, you could >get away with no timestamps, as you suggest, even with silence >detection. You could also avoid the use of timestamps if you assume >there is no network (or very little) jitter. Again, flexibility vs. >efficiency. I'd personally rather have the protocol work for both >best-effort networks and for tightly managed networks, where the jitter >may in fact be small. > In terms of silence, there would have to be some compensation in the sequence number. In the case of multiplexing channels, there is nothing stopping the multiplexing engine from manipulating the sequence number (similar to fabricating a timestamp offset to recreate the 'original timestamp'). I believe that jitter calculations and control will be an issue even for intranets for many years to come, especially if the sample sizes are small. The solution would have to compensate for jitter control, and this goes back to the _key_ element of using solely sequence numbers and throwing out timestamps: The creation of voice packets from the original source remains constant (or at least is re-negotiated out of band). This is the only way jitter can be accounted for. With constant packet creation, the original timestamp can be recreated by simply multiplying the sequence number by the sample size. >Whether or not an offset is needed again depends on flexibility. I'd >really be interested to hear from gateway vendors about whether their >gateways can/do generate frames that are not synchronized. Our current >proposal (draft-ietf-avt-aggregation-00) assumes synchronization and >uses no offsets. > Offsets are needed in order to 'switch time domains' per say, so that each individual user can have a new timestamp based on the mux packet domain. This is fine for single mux points. With multiple mux hops, keeping track of time with a timestamp offset becomes an unsurmountable problem. That is why the original information _must_ be retained. But timestamps are a pain -> they are large and based on different clocks. Sequence numbers, however, will never differ from each other in any grand magnitude (in a voice application.) You would never have to reorder sample number 2 with sample number 2000 in a jitter buffer. >These various tradeoffs, including your proposition, are discussed in >detail in draft-ietf-avt-muxissues-00.txt. > >I believe part of the difficult we are having in reaching any consensus >is a lack of requirements. This multiplexing problem is not terribly >hard, and the solution really falls right out of the requirements. So, >perhaps we should talk not about one protocol vs. another at this point, >but figure out what people want it to support. > Yes, this is true. Probably the solution which really breaks into the market first will become the standard, even if it is not the best. The key with voice is providing quality, while still maintaining some acceptable efficiency. VoIP will be a large and defining market for the RTP. Regards, Neal A. Schneider >-Jonathan R. > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Mon Nov 23 12:27:26 1998 From rem-conf-request@es.net Mon Nov 23 12:27:25 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zi2WB-0006JY-00; Mon, 23 Nov 1998 12:23:31 -0800 Received: from utah.hep.net ([131.225.80.59]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zi2W9-0006JO-00; Mon, 23 Nov 1998 12:23:29 -0800 Received: from utah.hep.net (utah.hep.net [131.225.80.59]) by utah.hep.net (8.9.1/8.9.1) with SMTP id OAA22463 for ; Mon, 23 Nov 1998 14:23:27 -0600 (CST) Date: Mon, 23 Nov 1998 14:23:27 -0600 (CST) From: "H.A. Kippenhan Jr." To: rem-conf@es.net Subject: Latest versions of vat, vic, rat for Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all: Is anyone on the list aware of recent updates to the vat, vic, and rat applications for Linux (more recent than what's on the MICE web page? Also, do ports of these tools exist for Mac O/S version 8.*. The MICE page indicates not, but perhaps someone on the list has more recent info. Thanks and best regards - Kipp - \|/ o o +---------------------------------+-------------------------+----m--~--m----+ | H.A. Kippenhan Jr. | Internet: Kippenhan@FNAL.GOV | | HEP Network Resource Center | HEPnet/NSI DECnet: FNDCD::KIPPENHAN | | Fermi National Accelerator Lab. | Voice: (630) 840-8068 | | P.O. Box 500 MS: FCC-3E/368 | FAX: (630) 840-8208 | | Batavia, Illinois 60510 | http://www.hep.net/people/kippenhan.html| +---------------------------------+-----------------------------------------+ | All opinions & ideas expressed are mine alone, and may not necessarily | | reflect those of Fermilab, Univ. Research Assoc., or the Dept. of Energy | +---------------------------------------------------------------------------+ From rem-conf Mon Nov 23 12:50:58 1998 From rem-conf-request@es.net Mon Nov 23 12:50:57 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zi2ru-00075t-00; Mon, 23 Nov 1998 12:45:58 -0800 Received: from nobozo.cs.berkeley.edu ([128.32.34.58]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zi2rt-00075j-00; Mon, 23 Nov 1998 12:45:57 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id MAA17509; Mon, 23 Nov 1998 12:45:56 -0800 (PST) Message-Id: <3.0.3.32.19981123124555.009163c0@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 23 Nov 1998 12:45:55 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/25 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar SIP - Signaling for Internet Telephony and Conferencing Wednesday November 25, 1998 12:30-2:00 pm 405 Soda Hall Henning Schulzrinne Department of Computer Science, Columbia University For the first time in a generation, the fundamental mechanisms for providing common communications services, such as telephone, radio and TV, are being re-examined. In this talk, we investigate some of the technical issues and research that are part of "re-engineering" the telephone network. It appears likely that a large part of the telephone infrastructure will move from circuit-switching to packet switching in the next decade. Just as the move from analog to digital switching in the 1960s allowed services such as direct dial, touch tone and call waiting, we can now consider the next step: making telephone service as programmable as web servers and email. Others have compared the change in architecture to the transition from mainframes to PCs. Research issues include signaling protocols, languages for constructing services and new ways to provide mobility without mobile IP. This is joint work with Mark Handley, Jonathan Lennox, Jonathan Rosenberg and Eve Schooler. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Mon Nov 23 13:34:57 1998 From rem-conf-request@es.net Mon Nov 23 13:34:56 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zi3Xp-0000KN-00; Mon, 23 Nov 1998 13:29:17 -0800 Received: from degusse.iro.umontreal.ca ([132.204.24.51]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zi3Xn-0000KD-00; Mon, 23 Nov 1998 13:29:15 -0800 Received: from [132.204.26.174] (fernandez.IRO.UMontreal.CA [132.204.26.174]) by degusse.IRO.UMontreal.CA (8.9.1/8.9.1) with SMTP id OAA22482; Mon, 23 Nov 1998 14:23:53 -0500 (EST) Full-Name: Rachida Dssouli X-Sender: dssouli@richelieu.iro.umontreal.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Nov 1998 14:28:50 -0500 To: sdl99pc@IRO.UMontreal.CA From: dssouli@IRO.UMontreal.CA (Rachida Dssouli) Subject: SDL Forum'99/ Paper submission: 7 December 1998 Cc: atm97authors@inesc.pt, atm96@inesc.pt, bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@isi.edu, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My apologies if you receive multiple copies. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 9th SDL FORUM Call For Papers 21-25 June 1999 Montr=E9al, Qu=E9bec, Canada http://www.iro.umontreal.ca/sdl &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Organized by Universit=E9 de Montr=E9al SDL FORUM Society NORTEL =46or nearly two decades the SDL Forum has been an event held every second year where experts, users, toolmakers and even some critics of MSC and SDL can meet face to face. Although it is a conference, the name "Forum" is retained because the main characteristic of the Forum is a meeting place for people involved or interested in MSC and SDL. MSC - Message Sequence Chart - is a graphical and textual language for the description and specification of the interactions between system components. SDL - Specification and Description Language - has been designed to specify and describe the functional behavior of telecommunication systems. It has been used in a variety of fields, including data communication protocol specification. Both languages are standardized by ITU (MSC - Z.120 & SDL - Z.100) and commercial tools have been available for many years. The proceedings published by Elsevier are widely referenced, and the Forum is the basis of further improvements. Papers Authors are invited to submit papers for presentation at the SDL Forum and publication in the proceedings. Suggested topics include (but are not limited to): Application to telecommunications: ATM networks,Wire-less,Mobile Communication, Intelligent networks, ODP, CORBA, Architectures and distributed platforms. Other application areas: transport, robotics, electronics and real time syst= ems. Verification and testing of distributed systems. Use of SDL and MSC together with other languages (OMT, UML, ASN.1, Z, GDMO, = etc) Modelling timing aspects. Methodology and Experiences in software engineering. Tools and tool support. Education and training. Proliferation of SDL and MSC. Key dates Paper submission: 7 December 1998 Tutorials proposal: 30 January 1999 Acceptance notification: 10 February 1999 Camera ready form of accepted papers: 15 March 1999 Paper submission Papers should be submitted to Rachida Dssouli. Electronic submission is encouraged. =46ull papers should be up to 16 pages, 12 point, single spaced, including a= n informative abstract as well as names and affiliations of all authors, and a list of keywords facilitating the assignment of papers to referees. To submit a paper electronically please observe the following rules: Send two email messages to dssouli@iro.umontreal.ca: The first message, in plain text, indicates the title of the paper, its authors, and the following informations concerning the principal author: full name, full airmail address, and email address. The second message, in uuencoded compressed postscript or PDF, has the paper only. Please format your paper to be printed on the paper size of 8" by 11" (letter size). Contact address: Rachida Dssouli Universit=E9 de Montr=E9al, Dept. IRO. C.P. 6128, succursale Centre-Ville Montreal (Quebec) H3C 3J7, CANADA Tel.: 1- (514) 343-7599; =46AX: 1- (514) 343-5834 Tutorials Monday 21 June will be a tutorial day, with presentations on relevant topics by speakers with recognized experience and competence. The tutorial program will be published as part of the call for participation and the final program. Please, send proposals for tutorials to the SDL Forum tutorials' organizer: Yair Lahav Email : Yair.Lahav@ecitele.com Tool exhibition The Forum will be accompanied by a tool exhibition. Vendors of commercial tools, and designers of non-commercial and experimental tools related to MSC and SDL are invited to participate in the exhibition. Inquiries regarding reservation for an exhibition should be sent to both: Rachida Dssouli Email : sdl99@iro.umontreal.ca and Toma Macavei Email : tech@ivt.ca Program co-chairs Rachida Dssouli (DIRO, Universit=E9 de Montr=E9al, Canada) Gregor v. Bochmann (SITE, University of Ottawa, Canada) Yair Lahav (SDL Forum Society Chairman, ECI Telecom Ltd, Israel) Program Committee E. M. Aboulhamid (Univ. de Montr=E9al, Canada), A. Bo (Beijing University of Post & Tel., China), G.v. Bochmann (Univ. of Ottawa, Canada), R. Braek (Sintef Informatics, Norway), A. Cavalli (INT, Evry, France), P. Combes (CNET, France), R. Dssouli (Univ. de Montr=E9al, Canada), J. Ellsberger (Ericsson, Denmark), A. Ek (Telelogic, Sweden), H. Erdogmus (NRC, Canada), M. Ferguson (INRS, Canada), J. Fischer (University of Berlin, Germany), Q. Gao (IVT, China and Canada), O. Haugen (Ericsson, Norway), D. Hogrefe (University of Lubeck, Germany), G. J. Holzmann (Reserch Bell Labs, USA), C. Jard (IRISA, Rennes, France), F. Khendek (Concordia University, Canada), Y.Lahav (ECI Telecom Ltd, Israel), P. Leblanc (VERILOG, France), N. Mansurov (Academy of Sciences, Russia), S. Mauw (Technical University of Eindhoven, The Netherlands), B. Moller-Pedersen (Ericsson, Norway), O. Monkewich (NORTEL - Canada), A. Neczwid (Schaumburg Lab., Motorola, USA), A. Olsen (TeleDanemark, Denmark), R. Probert (University of Ottawa, Canada), R. Reed (TSE Ltd, UK), N. Rico (Nortel, Canada), E. Rudolph (Technical University of Munich, Germany), A. Sarma (EURESCOM, Germany), H. Ural (SITE, Univ. of Ottawa, Canada), L. Verhaard (Telelogic, Sweden), D. Vincent (CNET, France), Y. Wakahara (KDD , Japan), T. Weigert (Motorola, USA) Support for local organization A. En-Nouaary (DIRO), N. Sabeur, D. Ouimet (CRM), A. Elqortobi (DIRO) ------------------------------------------------------ Rachida Dssouli dssouli@iro.umontreal.ca Universite de Montreal, Dept. IRO. C.P. 6128, succursale Centre-Ville Montreal (Quebec) H3C 3J7, CANADA Tel.(514) 343-7599; FAX..-5834 -- From rem-conf Mon Nov 23 15:20:24 1998 From rem-conf-request@es.net Mon Nov 23 15:20:23 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zi5DJ-00054F-00; Mon, 23 Nov 1998 15:16:13 -0800 Received: from f87.hotmail.com ([207.82.250.193] helo=hotmail.com) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zi5DI-0004cL-00; Mon, 23 Nov 1998 15:16:12 -0800 Received: (qmail 26441 invoked by uid 0); 23 Nov 1998 23:15:40 -0000 Message-ID: <19981123231540.26440.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Mon, 23 Nov 1998 15:15:40 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: rem-conf@es.net Subject: VAD over the Real Time Protocol MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 23 Nov 1998 15:15:40 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is there any silence suppression information transmitted via the RTP? Are lost packets treated the same as periods of silence on the receiving end? Is noise inserted for both cases? Regards, Neal A. Schneider ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Mon Nov 23 21:10:40 1998 From rem-conf-request@es.net Mon Nov 23 21:10:38 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziAdx-0002Yr-00; Mon, 23 Nov 1998 21:04:05 -0800 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0ziAdv-0002Yh-00; Mon, 23 Nov 1998 21:04:03 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Nov 24 00:02:09 EST 1998 Received: from dnrc.bell-labs.com ([135.17.200.83]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA04432; Tue, 24 Nov 1998 00:02:07 -0500 (EST) Message-ID: <365A3D6E.1D7847D9@dnrc.bell-labs.com> Date: Tue, 24 Nov 1998 00:00:30 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Neal Schneider CC: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981123193516.23981.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Neal Schneider wrote: > > >As with anything else, there is an engineering tradeoff. In the case of > >RTP, and RTP mux in particular, there is primarily a tradeoff between > >overhead and flexibility. RTP itself is designed more with flexibility > >in mind, making it more modular and applicable to a wide range of > >applications, not just voice. > > Yes, but if the VoIP market expands greatly over the next few years, the > study will focus from RTP recommendations to industry standards. > The convergence of voice and data, in particular, could easily demand > it's own specific RTP format, especially in multiplexing. Thats why the group is developing a payload format for muxing. > In terms of silence, there would have to be some compensation in the > sequence number. In the case of multiplexing channels, there is nothing > stopping the multiplexing engine from manipulating the sequence number > (similar to fabricating a timestamp offset to recreate the 'original > timestamp'). Fudging the sequence number is a dangerous game. RTCP statistics will be indicating significant losses; this could screw up adaptive systems which use RTCP feedback. Also, some applications do different things for silence periods and for packet losses (they are, after all, different). These will also break. > > I believe that jitter calculations and control will be an issue even for > intranets for many years to come, especially if the sample sizes are > small. The solution would have to compensate for jitter control, and > this goes back to the _key_ element of using solely sequence numbers and > throwing out timestamps: Yes, I agree that jitter control and adaptive playout buffers are a good thing. But, I don't see why this is an argument for throwing away timestamps. > The creation of voice packets from the > original source remains constant (or at least is re-negotiated out of > band). This is the only way jitter can be accounted for. With constant > packet creation, the original timestamp can be recreated by simply > multiplying the sequence number by the sample size. Again, I don't see why eliminating timestamps is the "only way jitter can be accounted for". -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Nov 24 01:40:37 1998 From rem-conf-request@es.net Tue Nov 24 01:40:36 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziEsc-00050z-00; Tue, 24 Nov 1998 01:35:30 -0800 Received: from campino.informatik.rwth-aachen.de ([137.226.116.240]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0ziEsa-00050o-00; Tue, 24 Nov 1998 01:35:28 -0800 Received: from unknown (knallkopp.Informatik.RWTH-Aachen.DE [137.226.12.126]) by campino.informatik.rwth-aachen.de (8.9.1a/8.9.1/1) with SMTP id KAA06114; Tue, 24 Nov 1998 10:34:20 +0100 (MET) Message-Id: <199811240934.KAA06114@campino.informatik.rwth-aachen.de> From: Jakobs@i4.informatik.rwth-aachen.de Comments: Authenticated sender is jakobs@mail-i4.informatik.rwth-aachen.de To: Kai.Jakobs@i4.informatik.rwth-aachen.de Date: Tue, 24 Nov 1998 10:37:10 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Subject: CfPs: Conference and Book on Standardisation in IT Reply-to: Kai.Jakobs@i4.informatik.rwth-aachen.de Priority: normal X-mailer: Pegasus Mail/Mac (v2.2.1) Content-Transfer-Encoding: Quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ***Please accept my apologies if you receive these Calls more than once.**= * ************************************** 1st IEEE Conference on Standardisation and Innovation in Information Technology SIIT '99 Aachen, Germany September 15-17, 1999 Call for Papers http://www-i4.informatik.rwth-aachen.de/~jakobs/siit99/home.html To be innovative is crucial in today's increasingly competitive environment. This holds particularly for the deployment and utilisation of IT systems and applications, and it holds at both the corporate and the national/international level.Standards, on the other hand, have frequently been accused of hampering progress because of their slow development processes and an alleged lack of responsiveness to market needs. Yet, few large IT systems would ever materialise without them. With an unprecedented such system - the Global Information Infrastructure - on the horizon it is about time to study both innovation and standardisation processes, as well as - particularly - their interrelation. The conference aims at bringing together researchers and practitioners from the normally separated disciplines of telecommunications, technology studies, economics, business studies, management sciences, politics, and computer science, as well as IT users. Topics of Interest Papers that address issues relating to standardisation and/or innovation in IT, with an emphasis on the 'and', are solicited. Sample topics of interest include: - The role of standards in information infrastructures. - National/regional standardisation policies. - Analysis of, and new models for, standardisation processes. - The role of consortia in standards making. - The economic dimension of IT standards. - The impact of standards on innovations, and vice versa. - Corporate innovation processes. - National and regional innovation policies. - Case studies relating to standards setting and/or innovations in IT. Submission Instructions All submissions must be original material not previously published, and not be under review elsewhere. Each paper will be reviewed by at least two experts; accepted papers will be published in the conference proceedings. Submissions may be in the form of either full papers or short papers. Full papers should not exceed 6,000 words. Short papers (discussing e.g. concepts or research-in-progress) should not exceed 2,000 words. For both categories a separate title page should give the names and contact details of all authors (affiliation, postal address, e-mail, phone, fax). The key contact for correspondence must be clearly identified. The body of the paper should be preceded by a 200-words abstract. Electronic submission is strongly encouraged. Send a Postscript version or a PDF version of your paper either via ftp to ftp-i4.informatik.rwth-aachen.de/pub/incoming or as a MIME-encoded e-mail attachment to Kai.Jakobs@i4.informatik.rwth-aachen.de. Only if these options fail should hardcopies (4) of a paper be sent to Kai Jakobs; RWTH Aachen; Informatik IV; Ahornstr. 55; D-52074 Aachen; Germany. Important Dates Deadline for Submissions: 5.3.99 Notification of authors: 3.5.99 Camera-ready versions: 6.6.99 The best papers relating to the global perspectives of the (IT standards and standardisation) field will be recommended for possible publication in the Journal of Global Information Management. The journal's home page can be found at http://www.idea-group.com/jgim.htm Co-Sponsored by: IEEE IEEE Technical Committee on Enterprise Networking Technical University of Aachen ******************************** CALL FOR CHAPTERS IT Standards and Standardisation: A Global Perspective Edited by Kai Jakobs, Technical University of Aachen (Germany) In the light of the emerging global information infrastructure, IT standards are becoming increasingly important. At the same time, however, the standards setting process has been criticised as being slow, inefficient and out of touch with market needs. What can be done to resolve this situation, and to produce good and timely standards? To provide the basis for an answer to this question, the upcoming book, 'IT Standards and Standardisation: A Global Perspective', aims at painting as full a picture as possible of the varied and diverse aspects surrounding standards and standardisation. Accordingly, contributions are sought from researchers and practitioners from all relevant disciplines including, but not limited to computer science, economics, social sciences, management studies, politics, and users. Possible topics include, but are not limited to: - The role of standards in corporate/national/international infrastructures. - Analyses of standardisation policies. - The economics of IT standards. - The (changing?) roles of the different players in the process. - What about the users? - The importance of the individual. - Do we really need a new standards setting process? If you are interested in contributing a chapter for this forthcoming book, please forward a proposal of 2-4 pages on your topic before February 1, 1999. Authors of accepted proposals will be asked to submit four copies of their full manuscript by March 15, 1999. Final chapters should be between 25-30 double-spaced pages written in APA style. An abstract of 100-150 words should also be included. Idea Group Publishing will be the publisher of this book. Deadline for finished chapters will be July 1, 1999 with publication date of Fall of 1999. Please send all submissions (preferably through e-mail as PDF/Word files) and inquiries to: Kai Jakobs Technical University of Aachen Computer Science Department, Informatik IV Ahornstr. 55 D-52074 Aachen, Germany. E-mail: Kai.Jakobs@i4.informatik.rwth-aachen.de Tel: +49-241-80-21405 Fax: +49-241-8888-220 From rem-conf Tue Nov 24 04:39:17 1998 From rem-conf-request@es.net Tue Nov 24 04:39:16 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziHdH-0006pH-00; Tue, 24 Nov 1998 04:31:51 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0ziHdF-0006p2-00; Tue, 24 Nov 1998 04:31:49 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Nov 1998 12:30:50 +0000 X-Mailer: exmh version 1.6.6 3/24/96 To: Neal Schneider cc: rem-conf@es.net Subject: Re: VAD over the Real Time Protocol In-reply-to: Your message of "Mon, 23 Nov 1998 15:15:40 PST." <19981123231540.26440.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Nov 1998 12:30:50 +0100 Message-ID: <765.911910650@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <19981123231540.26440.qmail@hotmail.com>Neal Schneider writes: > Is there any silence suppression information transmitted via the RTP? I am not entirely sure what exactly you are asking. Are you asking about the transmission of comfort noise? There is a generic comfort noise (CN) payload defined in the RTP Profile documentation (draft-ietf-avt-profile-new-03 .txt) which sends the noise level to generated at the receiver. In addition, several codecs (G.723.1, G.729, GSM) have codec specific comfort noise data that can be identified by examining a few bits in the coded data. > Are lost packets treated the same as periods of silence on the receiving > end? Is noise inserted for both cases? This depends on the tool being used - I believe both NeVoT and RAT both use loss concealment algorithms. In RAT there are three schemes: (a) codec specific loss concealment mechanisms - using recommended repair technique for codec e.g. GSM repeating first frame parameters, then fading gain. (b) packet repetition - repeating unit before loss, gradually fading it. (c) pattern matching - locating boundaries of periodic sound and repeat with fade. There are certain proviso's on how well all the schemes can work i.e. length of loss should be less than the length of a phoneme and losses during transitions between phonemes generally fail to be concealed very well. There is a review of concealment algorithms in this month's IEEE Network magazine by Colin Perkins and myself that may be of interest. (Also available online http://www-mice.cs.ucl.ac.uk/multimedia/publications/ErrorCorrection.ps) Kind Regards - Orion From rem-conf Tue Nov 24 06:12:01 1998 From rem-conf-request@es.net Tue Nov 24 06:11:59 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziJ89-0000Le-00; Tue, 24 Nov 1998 06:07:49 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0ziJ82-0000LT-00; Tue, 24 Nov 1998 06:07:45 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Nov 1998 14:07:13 +0000 To: "H.A. Kippenhan Jr." cc: rem-conf@es.net Subject: Re: Latest versions of vat, vic, rat for Linux In-reply-to: Your message of "Mon, 23 Nov 1998 14:23:27 CST." Date: Tue, 24 Nov 1998 14:07:13 +0100 Message-ID: <962.911916433@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> "H.A. Kippenhan Jr." writes: > Is anyone on the list aware of recent updates to the vat, vic, and > rat applications for Linux (more recent than what's on the MICE > web page? The MICE page (http://www-mice.cs.ucl.ac.uk/multimedia/software/) is the master site for rat. The latest stable version is 3.0.28, the experimental branch is up to 3.2.6 but is not exactly reliable yet. The MASH project (http://www-mash.cs.berkeley.edu/mash/) may have later versions of vic and vat. Colin From rem-conf Tue Nov 24 06:24:50 1998 From rem-conf-request@es.net Tue Nov 24 06:24:49 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziJMH-0000cB-00; Tue, 24 Nov 1998 06:22:25 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0ziJMG-0000bm-00; Tue, 24 Nov 1998 06:22:24 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Nov 1998 14:21:27 +0000 X-Mailer: exmh version 1.6.6 3/24/96 To: "H.A. Kippenhan Jr." cc: rem-conf@es.net Subject: Re: Latest versions of vat, vic, rat for Linux In-reply-to: Your message of "Mon, 23 Nov 1998 14:23:27 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Nov 1998 14:21:26 +0100 Message-ID: <1026.911917286@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "H.A. Kippenhan Jr." wri tes: > Hi all: > > Is anyone on the list aware of recent updates to the vat, vic, and > rat applications for Linux (more recent than what's on the MICE > web page? The latest versions of vic and vat are MASH shell applications - see http://www-mash.cs.berkeley.edu/mash for more information. There is a Linux version. The latest release version of rat for linux is 3.0.28. The latest experimental version is 3.2.6. Both are available at http://www-mice.cs.ucl.ac.uk/multimedia/software/ in case you have an old URL. > > Also, do ports of these tools exist for Mac O/S version 8.*. The > MICE page indicates not, but perhaps someone on the list has more > recent info. > The are no MAC O/S ports. You might try Apple's QuickTime Conferencing (AFAIK no longer supported) - try ftp://ftp.mice.ed.ac.uk/mice/unsupported/Macintosh/. cheers - Orion -- Orion Hodson [Research Student] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Networked Multimedia Research Group Tel: ++(0)171 419 3704 Department of Computer Science Fax: ++(0)171 419 1397 University College London, Gower Street London, WC1E 6BT, UK. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rem-conf Tue Nov 24 06:27:51 1998 From rem-conf-request@es.net Tue Nov 24 06:27:50 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziJPt-0000lY-00; Tue, 24 Nov 1998 06:26:09 -0800 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0ziJPq-0000lJ-00; Tue, 24 Nov 1998 06:26:08 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Nov 1998 14:25:34 +0000 To: Neal Schneider cc: rem-conf@es.net Subject: Re: VAD over the Real Time Protocol In-reply-to: Your message of "Mon, 23 Nov 1998 15:15:40 PST." <19981123231540.26440.qmail@hotmail.com> Date: Tue, 24 Nov 1998 14:25:33 +0100 Message-ID: <1008.911917533@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Neal Schneider writes: >Is there any silence suppression information transmitted via the RTP? >Are lost packets treated the same as periods of silence on the receiving >end? Is noise inserted for both cases? The receiver can differentiate between silence and packet loss based on the combination of sequence number and timestamp. In addition, the first packet in a talkspurt has the marker bit set. RTP does not specify how a silence period is to be filled by a receiver, or which algorithm is used to detect silence at the sender. Comfort noise packets may be sent during the silence period, but this is not required. RTP does not specify the means by which a receiver deals with lost packets. An implementation may treat them in the same manner as a silent period, but may also perform some form of error concealement. Both are these are areas for product differentiation. -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: +44 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf Tue Nov 24 08:43:20 1998 From rem-conf-request@es.net Tue Nov 24 08:43:19 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziLTa-0003QZ-00; Tue, 24 Nov 1998 08:38:06 -0800 Received: from nobozo.cs.berkeley.edu ([128.32.34.58]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0ziLTY-0003QP-00; Tue, 24 Nov 1998 08:38:04 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA02244; Tue, 24 Nov 1998 08:38:04 -0800 (PST) Message-Id: <3.0.3.32.19981124083802.00a75c00@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 24 Nov 1998 08:38:02 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/25 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar SIP - Signaling for Internet Telephony and Conferencing Wednesday November 25, 1998 12:30-2:00 pm 405 Soda Hall Henning Schulzrinne Department of Computer Science, Columbia University For the first time in a generation, the fundamental mechanisms for providing common communications services, such as telephone, radio and TV, are being re-examined. In this talk, we investigate some of the technical issues and research that are part of "re-engineering" the telephone network. It appears likely that a large part of the telephone infrastructure will move from circuit-switching to packet switching in the next decade. Just as the move from analog to digital switching in the 1960s allowed services such as direct dial, touch tone and call waiting, we can now consider the next step: making telephone service as programmable as web servers and email. Others have compared the change in architecture to the transition from mainframes to PCs. Research issues include signaling protocols, languages for constructing services and new ways to provide mobility without mobile IP. This is joint work with Mark Handley, Jonathan Lennox, Jonathan Rosenberg and Eve Schooler. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Nov 24 09:20:06 1998 From rem-conf-request@es.net Tue Nov 24 09:20:05 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziM5Z-0004Ud-00; Tue, 24 Nov 1998 09:17:21 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0ziM5Y-0004UO-00; Tue, 24 Nov 1998 09:17:20 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA28344; Tue, 24 Nov 1998 12:16:44 -0500 (EST) Message-Id: <199811241716.MAA28344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-telephone-tones-00.txt Date: Tue, 24 Nov 1998 12:16:44 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 Payloads for Telephone Signal Events Author(s) : S. Petrack Filename : draft-ietf-avt-telephone-tones-00.txt Pages : 11 Date : 23-Nov-98 This note describes two RTP payload formats for in-band telephony signal events (TSE) such as DTMF, dial-tone, ring-tone, off-hook, SIT, etc. One payload is designed to carry a named signal, and the other is designed carry a compact representation of actual audio waveform cadence to be played. The two formats are independent, but they can be used together very usefully within redundant audio payloads; this enables highly efficient and robust transport of telephony network signal events along with a representation of the actual audio media associated to the signal events. Acknowledgements: This internet draft is an extension of H. Schulzrinne's draft ietf-avt-dtmf-00.txt and borrows heavily from it (including copying actual text). The main extensions appearing in this draft are as follows: a) many other telephony call progress tones and signal events have been added to the original DTMF and flash-hook of ietf-avt-dtmf-00.txt (an attempt has been made to align this with [MGCP] and [E.180 supp2] b) a second payload is defined which carries a highly compact frequency representation of the audio waveform of the signal; c) a few clarifications about reliability and redundancy, including how the two payloads will work together. Acknowledgement is also due to [MGCP]; part of this draft is an attempt to use RTP to provide the signal transport required by MGCP, in a way which can be reused by a large class of applications. Internet-Drafts are 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-telephone-tones-00.txt". A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-telephone-tones-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-telephone-tones-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: <19981123085651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-telephone-tones-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-telephone-tones-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981123085651.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Nov 24 09:37:22 1998 From rem-conf-request@es.net Tue Nov 24 09:37:22 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ziMNM-00056M-00; Tue, 24 Nov 1998 09:35:44 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0ziMNJ-00055j-00; Tue, 24 Nov 1998 09:35:42 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA28974; Tue, 24 Nov 1998 12:35:08 -0500 (EST) Message-Id: <199811241735.MAA28974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-dtmf-01.txt Date: Tue, 24 Nov 1998 12:35:07 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits Author(s) : H. Schulzrinne Filename : draft-ietf-avt-dtmf-01.txt Pages : 6 Date : 23-Nov-98 This memo describes how to carry dual-tone multifrequency (DTMF) signaling and other tone signals in RTP packets. Internet-Drafts are 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-dtmf-01.txt". A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dtmf-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-dtmf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981123090359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dtmf-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dtmf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981123090359.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Nov 24 15:17:11 1998 From rem-conf-request@es.net Tue Nov 24 15:17:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ziRYa-000441-00; Tue, 24 Nov 1998 15:07:40 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ziRYY-00043g-00; Tue, 24 Nov 1998 15:07:38 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA09646; Tue, 24 Nov 1998 18:06:33 -0500 (EST) Message-Id: <199811242306.SAA09646@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-03.txt Date: Tue, 24 Nov 1998 18:06:33 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, B. Strahm, I. Suconick Filename : draft-ietf-avt-rtp-mib-03.txt Pages : 26 Date : 23-Nov-98 This memo defines an experimental Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Real-Time Transport Protocol systems [1]. Comments should be made to the IETF Audio/Video Transport Working Group at rem-conf@es.net. This memo does not specify a standard for the Internet community. Internet-Drafts are 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-mib-03.txt". A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981123104302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981123104302.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Nov 24 15:33:24 1998 From rem-conf-request@es.net Tue Nov 24 15:33:23 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ziRun-0004X3-00; Tue, 24 Nov 1998 15:30:37 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ziRul-0004V7-00; Tue, 24 Nov 1998 15:30:35 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA10705; Tue, 24 Nov 1998 18:29:30 -0500 (EST) Message-Id: <199811242329.SAA10705@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-new-04.txt,.ps Date: Tue, 24 Nov 1998 18:29:30 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-new-04.txt,.ps Pages : 32 Date : 23-Nov-98 This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. The revision process is not yet complete; some changes which have been discussed and tentatively accepted in meetings of the Audio/Video Transport working group have not yet been incorporated into this draft. 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. However, the encoding definitions are independent of the particular transport mechanism used. 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. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-new-04.txt". A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-new-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981123165257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981123165257.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Nov 24 15:41:50 1998 From rem-conf-request@es.net Tue Nov 24 15:41:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ziS4w-0004uy-00; Tue, 24 Nov 1998 15:41:06 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ziS4v-0004t3-00; Tue, 24 Nov 1998 15:41:05 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA11409; Tue, 24 Nov 1998 18:40:02 -0500 (EST) Message-Id: <199811242340.SAA11409@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-new-02.txt,.ps Date: Tue, 24 Nov 1998 18:40:02 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-new-02.txt,.ps Pages : 94 Date : 23-Nov-98 This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. 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. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-new-02.txt". A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-new-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981123151258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981123151258.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Nov 26 11:22:07 1998 From rem-conf-request@es.net Thu Nov 26 11:22:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zj6nj-00050l-00; Thu, 26 Nov 1998 11:10:03 -0800 Received: from pompano.ithink.com [206.100.75.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zj6nh-00050G-00; Thu, 26 Nov 1998 11:10:01 -0800 Received: from vsjuab.org (unverified [208.170.33.75]) by pompano.ithink.com (Rockliffe SMTPRA 2.1.6) with SMTP id ; Wed, 25 Nov 1998 22:45:42 -0500 Date: Wed, 25 Nov 1998 22:45:42 -0500 Message-ID: From: pat@vsjuab.org To: pat@vsjuab.org Subject: Happy GobbleDaY! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------------------------------------------------------------------------------------ Get your own Dot COM, .NET, .ORG, .TO, or even a .CC! HOSTING INCLUDED or transfer yours FREE!! FREE SETUP, FREE TRANSFERS, NO HIDDEN COSTS! A Toll FREE support line! Call NOW, Operators are standing by: 407-622-2172 This is a special one time 10 day offer. call 407-622-2172 now to order For only $15.95/mo. HOSTING INCLUDED! YES! 15.95!! YOU receive all of these services: Ask about the Turkey Day special! ( Signup Special # TD-2000) Our servers are safe, secure, and fast. Adult only content is NOT WELCOME. 1. Your own domain name www.anynameyouchoose.com 2. 6 page professionally designed website templates WITH GRAPHICS 3. Total ftp access 24/7 and 20 megs of quality triple DS3 (digital) webspace!! 4. POP e-mail box that recieves ANYTHING addressed to @yourdomain 5. Unlimited e-mail addresses@anynameyouchoose.com 6. Toll free helpline for our customers available M-F from 9pm-6pm EST 7. 100megs of traffic/day 8. Support forum with all the tools and instruction you will ever need 9. Ongoing pledge to price freeze. Same price next year! 10. Guaranteed 99%uptime or your month is FREE 11.NO HIDDEN COSTS! NO SETUP FEES! FREE TRANSFERS! 12. An International hosting company with more than 33,000 Domains hosted since 1993 Don't miss this 1 time opportunity from Digital Global Networks! CALL NOW ====> 407-622-2172 *Front page support available **E-commerce, secure server service available ***Webmaster/Reseller accounts available Don't miss this 1 time opportunity from Digital Global Networks! CALL NOW ====> 407-622-2172 **THIS IS A ONE TIME MAILING; YOUR NAME HAS BEEN AUTOMATICALLY DELETED!!!!!!!! From rem-conf Thu Nov 26 22:56:03 1998 From rem-conf-request@es.net Thu Nov 26 22:56:00 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zjHgH-0002zQ-00; Thu, 26 Nov 1998 22:47:05 -0800 Received: from ip69.ts8.phx.inficad.com ([208.198.103.69] helo=208.198.103.69) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zjHgF-0002yw-00; Thu, 26 Nov 1998 22:47:03 -0800 From: PAUL@OAOU.A-BULK-EMAIL-MARKET.COM To: rem-conf@DFDD.es.net Subject: $name How To Doubled Sales! -MCTO X-Reply-To: PAUL@A-BULK-EMAIL-MARKET.COM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 26 Nov 1998 22:47:03 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list $name ######################################################### This message complies with the proposed United States Federal requirements for commercial e-mail bill, Section 301. For additional info see: http://www.senate.gov/~murkowski/commercialemail/EMailAmendText.html Required Sender Information: A-bulk-email-market 11600 North 29th ave Phx, AZ 85051 602-809-9954 ############################################################# $name No hype. This simple, low-cost service Doubled our sales. It's so good Now we're selling it. We're Paul & Melissa, real people, sharing a real offer. MERCHANT CARD SERVICE Limited time offer. The usual hefty application FEE IS WAIVED. Plus, accept checks directly by your computer. That's not all. Here's what you've been waiting for. No Bull. No baloney. No big bites out of your budget. We take: ***Internet business ***Mail order business ***Home based business ***New business Plus: ***No financial statement ***No tax returns ***No trade references ***No photos of your office ****NO KIDDING!!! Very affordable monthly fees. Like made for us small business folks. Discounts to knock at least one sock off. And that application fee ( others charge $125 to $495) IS WAIVED for the next two weeks. Paul & I have been doing business on the internet for over 5 years now. And rather successfully at that. Before that we had a little store. The merchant card banks wanted half an arm to start, plus a whopping 20%. Until we could raise the front fee, we struggled and struggled. When we finally got card status, our business more then doubled. Here's what we found out: ****MORE SALES ****Lots MORE impulse sales ****Higher average sales ****Much MORE frequent repeat sales ****Mail order sales we never had before ****Customers trust and loyalty ****Leveling out the payday peeks And at That time we had to go through the banker's critical evaluation and pay over $400 up front. If YOU don't have credit card status, now is the time to propel your business forward. That huge front fee is waived. And the rates are mouth watering. Give our NO-PRESSURE-CUSTOMER-REP a call, ask for Ext. 7,000 And are NO-PRESSURE-CUSTOMER-REP will answer all your questions. 1-888-869-5520 Ext.7,000 Paul & Melissa P.S. NO UP FRONT FEES. NOW IS THE TIME. ################################################### Per Section 301, Paragraph (a)(2)(C) of S. 1618, further ## transmissions to you by the sender of this e-mail may be ## stopped at NO COST to you by sending a reply to this e-mail ## address with the word "remove" in the subject line. ## mailto:PAUL@a-bulk-email-market.com?subject=Remove ## =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From rem-conf Fri Nov 27 02:59:55 1998 From rem-conf-request@es.net Fri Nov 27 02:59:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjLTy-0002rj-00; Fri, 27 Nov 1998 02:50:38 -0800 Received: from olympus.noc.uoa.gr (noc.uoa.gr) [195.134.100.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zjLTs-0002rS-00; Fri, 27 Nov 1998 02:50:32 -0800 Received: from kissavos.noc.uoa.gr (kissavos.noc.uoa.gr [195.134.100.101]) by noc.uoa.gr (8.8.8/8.8.8) with ESMTP id MAA09770; Fri, 27 Nov 1998 12:37:42 +0200 (EET) Received: from Encoder ([195.134.100.219]) by kissavos.noc.uoa.gr (8.8.8+Sun/8.8.8) with SMTP id MAA01177; Fri, 27 Nov 1998 12:53:17 +0200 (EET) Message-ID: <01f501be19f3$1aa1a0e0$db6486c3@Encoder.noc.uoa.gr> From: "laoutaris" To: , Subject: RTP over RSVP Date: Fri, 27 Nov 1998 12:45:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F2_01BE1A03.DD936100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01F2_01BE1A03.DD936100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=20 I am developing RSVP enabled applications for tele-conference and = tele-education. I am examining the possibilities of using RTP over RSVP. = Most of all i am interested in RTP's complementary protocol RTCP for = reporting delivery statistics. Has someone tested this scheme or is = there any papers regarding the pros and cons of RTP over RSVP. There are = a lot of issues to be discussed in such a configuration. For examples is = there a reason for using RTP's resequence info for sorting out-of-order = packets when RSVP delivers all packets across the same data path. I = don't doubt the value of RTP but i don't know if the use over RSVP is = justifiable. Has anyone got any pointers on this. Thanks a lot Nikos Laoutaris laoutaris@noc.uoa.gr National and Kapodestrian University of Athens =20 Network Operations Center ------=_NextPart_000_01F2_01BE1A03.DD936100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
    I am developing = RSVP enabled=20 applications for tele-conference and tele-education. I am examining the=20 possibilities of using RTP over RSVP. Most of all i am interested in = RTP's=20 complementary protocol RTCP for reporting delivery statistics. Has = someone=20 tested this scheme or is there any papers regarding the pros and cons of = RTP=20 over RSVP. There are a lot of issues to be discussed in such a = configuration.=20 For examples is there a reason for using RTP's resequence info for = sorting=20 out-of-order packets when RSVP delivers all packets across the same data = path. I=20 don't doubt the value of RTP but i don't know if the use over RSVP is=20 justifiable. Has anyone got any pointers on this.
 
Thanks a lot
 
Nikos Laoutaris
laoutaris@noc.uoa.gr
National and Kapodestrian University = of=20 Athens 
Network Operations=20 Center
------=_NextPart_000_01F2_01BE1A03.DD936100-- From rem-conf Fri Nov 27 05:00:24 1998 From rem-conf-request@es.net Fri Nov 27 05:00:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjNRa-00044t-00; Fri, 27 Nov 1998 04:56:18 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zjNRY-00044f-00; Fri, 27 Nov 1998 04:56:17 -0800 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Nov 1998 12:55:51 +0000 To: laoutaris cc: rem-conf , rsvp Subject: Re: RTP over RSVP In-reply-to: Your message of "Fri, 27 Nov 1998 12:45:51 +0200." <01f501be19f3$1aa1a0e0$db6486c3@Encoder.noc.uoa.gr> Date: Fri, 27 Nov 1998 12:55:49 +0100 Message-ID: <1275.912171349@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <01f501be19f3$1aa1a0e0$db6486c3@Encoder.noc.uoa.gr>, laoutaris typed : i take it you mean RTCP based feedback+adaption versus RSVP based reservation right? >> I am developing RSVP enabled applications for tele-conference and = >>tele-education. I am examining the possibilities of using RTP over RSVP. = >>Most of all i am interested in RTP's complementary protocol RTCP for = >>reporting delivery statistics. Has someone tested this scheme or is = >>there any papers regarding the pros and cons of RTP over RSVP. There are = >>a lot of issues to be discussed in such a configuration. For examples is = >>there a reason for using RTP's resequence info for sorting out-of-order = >>packets when RSVP delivers all packets across the same data path. I = >>don't doubt the value of RTP but i don't know if the use over RSVP is = >>justifiable. Has anyone got any pointers on this. it so, there is a body of work on whether adaption is better than reservation (or rather, when each is more applicable) - ranging from economic, thru human factors, right thru to codecs (how adaptable etc compared with what rate could you change reservations at etc etc) cheers jon From rem-conf Fri Nov 27 06:25:23 1998 From rem-conf-request@es.net Fri Nov 27 06:25:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjOjb-00050V-00; Fri, 27 Nov 1998 06:18:59 -0800 Received: from smtprich.nortel.com (smtprich) [192.135.215.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zjOja-00050L-00; Fri, 27 Nov 1998 06:18:58 -0800 Received: from zmers013 by smtprich; Fri, 27 Nov 1998 08:18:00 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Fri, 27 Nov 1998 09:17:27 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id ; Fri, 27 Nov 1998 09:17:06 -0500 Message-ID: From: "Vahe Balabanian" To: 'Jon Crowcroft' , laoutaris Cc: rem-conf , rsvp Subject: RE: RTP over RSVP Date: Fri, 27 Nov 1998 09:17:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Jon, Is there a summary of the papers you are quoting indicating that adaption is better than reservation? Cheers, Vahe > -----Original Message----- > From: Jon Crowcroft [SMTP:J.Crowcroft@cs.ucl.ac.uk] > Sent: Friday, November 27, 1998 6:56 AM > To: laoutaris > Cc: rem-conf; rsvp > Subject: Re: RTP over RSVP > > > In message <01f501be19f3$1aa1a0e0$db6486c3@Encoder.noc.uoa.gr>, laoutaris > typed > : > > i take it you mean RTCP based feedback+adaption > versus > RSVP based reservation > right? > > >> I am developing RSVP enabled applications for tele-conference and = > >>tele-education. I am examining the possibilities of using RTP over > RSVP. = > >>Most of all i am interested in RTP's complementary protocol RTCP for = > >>reporting delivery statistics. Has someone tested this scheme or is = > >>there any papers regarding the pros and cons of RTP over RSVP. There > are = > >>a lot of issues to be discussed in such a configuration. For examples > is = > >>there a reason for using RTP's resequence info for sorting out-of-order > = > >>packets when RSVP delivers all packets across the same data path. I = > >>don't doubt the value of RTP but i don't know if the use over RSVP is = > >>justifiable. Has anyone got any pointers on this. > > it so, there is a body of work on whether adaption is better than > reservation (or rather, when each is more applicable) - ranging from > economic, thru human factors, right thru to codecs (how adaptable etc > compared with what rate could you change reservations at etc etc) > > cheers > > jon > From rem-conf Fri Nov 27 06:33:39 1998 From rem-conf-request@es.net Fri Nov 27 06:33:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjOvl-0005Oi-00; Fri, 27 Nov 1998 06:31:33 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zjOvf-0005NU-00; Fri, 27 Nov 1998 06:31:28 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Nov 1998 14:30:31 +0000 To: rem-conf@es.net Subject: Proposed AVT agenda for the Orlando meeting cc: casner@cisco.com Date: Fri, 27 Nov 1998 14:30:30 +0100 Message-ID: <3644.912177030@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enclosed is the draft agenda for the AVT meeting in Orlando. This has to be finalised by Monday, so please send any comments or corrections to us as soon as possible. Also, if you've requested a slot & we've overlooked it, please let us know. Note that the Wednesday slot has been moved, and will now take place on Friday morning instead. Colin Perkins and Steve Casner =============================================================================== Audio/Video Transport WG A G E N D A Thursday, December 10 at 1300-1500 ================================== - Introduction 5 - Documents published since last meeting RFC2429 - H.263+ payload format RFC2431 - BT.656 payload format RFC2435 - JPEG-video payload format - Documents to act upon draft-ietf-avt-crtp-05.txt draft-ietf-avt-rtp-mib-02.txt (Baugher) 10 draft-ietf-avt-rtp-format-guidelines-01.txt (Handley) 5 - RTP Payload Format for PureVoice(tm) Audio draft-mckay-qcelp-01.txt - Transport of MPEG4 streams (Civanlar) 20 - Generic payload format draft-guillemot-genrtp-00.txt (Guillemot) 20 - RTP multiplexing proposals draft-ietf-avt-muxissues-00.txt (Rosenberg) 15 draft-ietf-avt-mux-rtp-00.txt (Subbiah) 5 draft-tanigawa-rtp-multiplex-01.txt draft-ietf-avt-germ-00.txt (Handley) 5 Discussion 20 Friday, December 11 at 0900-1130 ================================ - Payload formats for loss tolerant media draft-ietf-avt-fec-04.txt (Rosenberg) 5 draft-ietf-avt-reedsolomon-00.txt (Rosenberg) 10 draft-ietf-avt-interleaving-00.txt (Perkins) 10 - Transport of DTMF tones (Petrack) 20 draft-ietf-avt-tones-00.txt draft-ietf-avt-dtmf-01.txt - Update to RTP draft-ietf-avt-rtp-new-02.txt, .ps (Casner) 30 draft-ietf-avt-rtpsample-01.txt (Rosenberg) 15 draft-parnes-rtp-sdes-00.txt (Casner) 5 - Update to RTP audio/video profile draft-ietf-avt-profile-new-04.txt, .ps (Casner) 20 - Charter update (Perkins) 15 =============================================================================== From rem-conf Fri Nov 27 08:28:12 1998 From rem-conf-request@es.net Fri Nov 27 08:28:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjQfc-0006qP-00; Fri, 27 Nov 1998 08:23:00 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zjQfU-0006pu-00; Fri, 27 Nov 1998 08:22:59 -0800 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Nov 1998 16:21:59 +0000 To: Vahe Balabanian cc: laoutaris , rem-conf , rsvp Subject: Re: RTP over RSVP In-reply-to: Your message of "Fri, 27 Nov 1998 09:17:26 EST." Date: Fri, 27 Nov 1998 16:21:57 +0100 Message-ID: <2009.912183717@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message , Vah e Balabanian typed: >>Is there a summary of the papers you are quoting indicating that >>adaption is better than reservation? um, not that have - anyone else got a good biblio? ian wakeman's thesis has some stuff on this - see http://www.cogs.susx.ac.uk/users/ianw/research.html for a link to that..... >>Cheers, >> >>Vahe >> >>> -----Original Message----- >>> From: Jon Crowcroft [SMTP:J.Crowcroft@cs.ucl.ac.uk] >>> Sent: Friday, November 27, 1998 6:56 AM >>> To: laoutaris >>> Cc: rem-conf; rsvp >>> Subject: Re: RTP over RSVP >>> >>> >>> In message <01f501be19f3$1aa1a0e0$db6486c3@Encoder.noc.uoa.gr>, laoutaris >>> typed >>> : >>> >>> i take it you mean RTCP based feedback+adaption >>> versus >>> RSVP based reservation >>> right? >>> >>> >> I am developing RSVP enabled applications for tele-conference and = >>> >>tele-education. I am examining the possibilities of using RTP over >>> RSVP. = >>> >>Most of all i am interested in RTP's complementary protocol RTCP for = >>> >>reporting delivery statistics. Has someone tested this scheme or is = >>> >>there any papers regarding the pros and cons of RTP over RSVP. There >>> are = >>> >>a lot of issues to be discussed in such a configuration. For examples >>> is = >>> >>there a reason for using RTP's resequence info for sorting out-of-order >>> = >>> >>packets when RSVP delivers all packets across the same data path. I = >>> >>don't doubt the value of RTP but i don't know if the use over RSVP is = >>> >>justifiable. Has anyone got any pointers on this. >>> >>> it so, there is a body of work on whether adaption is better than >>> reservation (or rather, when each is more applicable) - ranging from >>> economic, thru human factors, right thru to codecs (how adaptable etc >>> compared with what rate could you change reservations at etc etc) >>> >>> cheers >>> >>> jon >>> cheers jon From rem-conf Fri Nov 27 08:54:33 1998 From rem-conf-request@es.net Fri Nov 27 08:54:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjR7S-0007Wg-00; Fri, 27 Nov 1998 08:51:46 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zjR7R-0007WW-00; Fri, 27 Nov 1998 08:51:45 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA03669; Fri, 27 Nov 1998 11:51:41 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA23467; Fri, 27 Nov 1998 11:51:34 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <365ED896.A956984E@cs.columbia.edu> Date: Fri, 27 Nov 1998 11:51:34 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jon Crowcroft CC: Vahe Balabanian , laoutaris , rem-conf , rsvp Subject: Re: RTP over RSVP References: <2009.912183717@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jon Crowcroft wrote: > > In message , Vah > e Balabanian typed: > > >>Is there a summary of the papers you are quoting indicating that > >>adaption is better than reservation? > > um, not that have - anyone else got a good biblio? Not broken out, but a search under "adaptive service" and "adaptation" in the network bibliography (http://www.cs.columbia.edu/~hgs/netbib) should reveal many of the papers. Also, we have an early draft survey paper in progress. Contact Xin Wang (xinwang@ctr.columbia.edu) if you are interested. For both, corrections and additions are welcome. Henning From rem-conf Fri Nov 27 09:24:23 1998 From rem-conf-request@es.net Fri Nov 27 09:24:23 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjRai-0000WJ-00; Fri, 27 Nov 1998 09:22:00 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zjRah-0000W9-00; Fri, 27 Nov 1998 09:21:59 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA05084; Fri, 27 Nov 1998 12:21:56 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA23863; Fri, 27 Nov 1998 12:21:55 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <365EDFB3.81A745AD@cs.columbia.edu> Date: Fri, 27 Nov 1998 12:21:55 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jon Crowcroft , Vahe Balabanian , laoutaris , rem-conf , rsvp Subject: Re: RTP over RSVP References: <2009.912183717@cs.ucl.ac.uk> <365ED896.A956984E@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne wrote: > > paper in progress. Contact Xin Wang (xinwang@ctr.columbia.edu) if you > are interested. Make that xinwang@cs.columbia.edu. Sorry. From rem-conf Fri Nov 27 14:29:19 1998 From rem-conf-request@es.net Fri Nov 27 14:29:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zjWFi-00037c-00; Fri, 27 Nov 1998 14:20:38 -0800 Received: from imo15.mx.aol.com [198.81.17.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zjWFf-00035k-00; Fri, 27 Nov 1998 14:20:35 -0800 Received: from BADJEEP97@aol.com by imo15.mx.aol.com (IMOv16.10) id HKDa019407; Fri, 27 Nov 1998 17:16:22 -0500 (EST) From: BADJEEP97@aol.com Message-ID: <7bb741b2.365f24b6@aol.com> Date: Fri, 27 Nov 1998 17:16:22 EST Mime-Version: 1.0 Subject: RE: CABLE DESCRAMBLER ......... Now Only $7.00 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 64 Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is really cool! PREMIUM CHANNELS........Descrambled! EASY to assemble plans for only $7.00 ! YOU WILL BE WATCHING all your FAVORITE PAY STATIONS featuring MOVIES, SPORTS. Adult entertainment, and any other scrambled signal NEXT WEEK! You can EASILY assemble a cable descrambler in less than 30 minutes! You have probably seen many advertisments for similar plans......... BUT OURS are BETTER! We have compared it to all the others and have actually IMPROVED the quality and SIMPLIFIED the design !!! ** We even include PHOTOS! ** OUR PLANS ARE BETTER! We have NEW, EASY TO READ,EASY to assemble plans for only $7.00! We have seen them advertised for as much as $29.00 and you have to wait weeks to receive them! WHAT THE OTHERS SAY IS TRUE! Parts are available at "The TV HUT" or any electronics store. Trademark rights do not allow us to use a national electronics retail chains' name but there is one in your town! Call and ask them BEFORE you order! They are very familiar with these plans! You will need these easy to obtain parts : 270-235 mini box 271-1325 2.2k ohm resistor 278-212 chasis connectors RG59 coaxial cable #12 copper wire Variable capacitor They may have to special order the variable capacitor, But WHY WAIT for a special order? WE have them! WE have secured a supply of the capacitors directly from the manufacturer and We WILL include one with your plans for an ADDITIONAL $10.00 only! All you need now is the EASY TO ASSEMBLE plans to show you how this educational device in 30 MINUTES! It is LEGAL, providing of course you use these plans for EDUCATIONAL PURPOSES only. See first hand and LEARN how this SIMPLE circuitry works! If you intend to use these plans for any other purpose DO NOT ORDER them. IT'S FUN TO BUILD! We're sure you'll enjoy this project! This is a unique opportunity for hobbiest of ANY skill level to learn simple circuitry! Learn how easy descrambling is! $ 7.00 for plans only $10.00 for variable capacitor only $17.00 for The easy to assemble plans and one variable capacitor! Please send check or money order payable to: Kraftworks P.O. Box 11752 San Rafael, Ca. 94912 WE pay postage and handling! Please allow 14 days for delivery. This is a one time only mailing! You have already been placed on our remove list and will not receive another offer from us! Thank You From rem-conf Sun Nov 29 09:24:51 1998 From rem-conf-request@es.net Sun Nov 29 09:24:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkARE-0002p7-00; Sun, 29 Nov 1998 09:15:12 -0800 Received: from sumo.vocaltec.co.il [199.203.72.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkARB-0002ok-00; Sun, 29 Nov 1998 09:15:10 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id TAA29037; Sun, 29 Nov 1998 19:12:16 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566CB.005EC2B6 ; Sun, 29 Nov 1998 19:15:02 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: Henning Schulzrinne cc: rem-conf@es.net Message-ID: <422566CB.0058D15A.00@il4.vocaltec.co.il> Date: Sun, 29 Nov 1998 18:33:36 +0200 Subject: Re: A totally different (simpler?) approach to tones and errata Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning, I understand your thoughts, and I went back and forth several times before I decided that enumerating the combinations is the simplest solution. My decision was based on some very practical considerations of real-life hardware that I have seen doing the detection. Also I think that I was not clear about part of my suggestion (see my last comment below) Let me give you the answers I gave myself. Would other Telephone Tone experts please comment on my reasoning? >(a) If tones are generated from the signal, mapping to the index is >reasonably easy. If however, a PSTN-connected entity does signal >detection from a live signal, it is much harder, since it has to >artificially find a mapping, even though its measurement is going to be >imprecise. It seems far easier to have a filter bank for the common >frequencies or an FFT (easily implemented for a DSP) that picks the >strongest frequency components. When a PSTN-connected entity does signal detection from a live signal, of course the detector will have a filter bank for the common frequencies or an FFT. This is true in either case, whether the encoding is going to send the "enumerated combinations" or the actual frequencies. The only difference in the two cases is that the universe of possible outcomes in one case is very restricted. In fact, this usually helps to make for more accurate detection. Real-life hardware (in switches and CTI equipment) knows in what country it is sitting and what the 10-15 possible outcomes are. The whole point of the fact that there is a limited number of tone-frequency combinations is that this a priori knowledge makes final decision easier, not harder. The frequency detection is identical, but the final decision is helped by the fact that the number of outcomes is limited. >(b) that new tones are added very infrequently. Not quite, all you need is that new *tone combinations* are not added very frequently. I don't think that there have been new tone combinations added for about 10 years. When some new tone is added to the network, in general the national administrations seems to just use one of the 150 combinations already available (perhaps with a different time cadence). So I agree that it would be a pain if new combos need to be added, but I don't think that this happens. > At least with the special signals, >if we structure the name space accordingly, we can have properties >similar to that for SIP/HTTP/SMTP response codes: the class is good >enough for a first-order approximation. I may not recognize the new >"Dialtone V" in Germany, but rendering it as "dial tone" is probably >pretty good. Perhaps there was a misunderstanding here. I think that we need BOTH the "special named signals" and ALSO a separate payload type for the frequency combinations. I agree that there is a good reason to always use the named signals if you can. So I agree that it is a good idea to do some clever grouping for the named signals so that a receiver could render "DialTone V" as "DialTone". Either way the frequency combos are encoded, my intention was that it would be possible to send both the named signal and also the frequency information. All I did in my newest suggestion is to say that we don't need two payload formats. It is enough to have one single payload format which can be used with many different payload types. The payload types wouldl be used to signal if the payload is DTMF, or MF, or some more complicated named signal, or indeed some frequency combo. All I did was notice that the fact that there is a small number of frequency combinations available in real life allows us to use a single payload format for all the needs. This seemed to me a real simplification, admittedly at the expense that you can't express any old combination of frequencies that might ever appear. We'll be able to play Greensleeves, but maybe not "Bess you is my woman now". To be honest, my main motivation was simple IETF-style practicality and simplicity. Having this one payload format covers all the cases I need, and then some. In the end, having a format which names "DTMF digit 6" is just a particular combination of frequencies too, so when I saw that we could give index names to ALL combinations of frequencies, I thought that this is the simplest thing to do. Scott --------------------------------------------------------------------------- ---------------------------------------------- Henning wrote: Enumerating combinations assumes (a) that every entity recognizes the tones as precisely those tones and can thus map to the index; (b) that new tones are added very infrequently. In more detail: (a) If tones are generated from the signal, mapping to the index is reasonably easy. If however, a PSTN-connected entity does signal detection from a live signal, it is much harder, since it has to artificially find a mapping, even though its measurement is going to be imprecise. It seems far easier to have a filter bank for the common frequencies or an FFT (easily implemented for a DSP) that picks the strongest frequency components. (b) is necessary since if a receiver gets an index it does not recognize, it has absolutely no idea how to render it, since it could be anything from a dial tone to a SIT. At least with the special signals, if we structure the name space accordingly, we can have properties similar to that for SIP/HTTP/SMTP response codes: the class is good enough for a first-order approximation. I may not recognize the new "Dialtone V" in Germany, but rendering it as "dial tone" is probably pretty good. For rendition, ultimate precision is not necessary. Thus, even if the 350+375+400 tone is rendered as 350+375, it will be close enough for all but those with perfect pitch. A problem arises only if there were another continuous tone in Hungary with just 350+375 (which there isn't). In terms of phase changes, I doubt that human ears and FFT/filter-bank detectors are able to detect this, so I wouldn't worry too much about it. Thus, I would use a 3-tone plus modulation scheme which is easy to generate by filter banks or FFTs. If the tone is really a signal, the signal name is preferable, but with a suitable grouping, so that additions are easy. From rem-conf Sun Nov 29 19:35:03 1998 From rem-conf-request@es.net Sun Nov 29 19:35:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkJyW-0006vd-00; Sun, 29 Nov 1998 19:26:12 -0800 Received: from pm03sm.pmm.cw.net [208.159.126.152] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkJyU-0006vL-00; Sun, 29 Nov 1998 19:26:10 -0800 Received: from cs.columbia.edu (usr8-dialup44.mix2.Boston.cw.net [166.55.68.236]) by PM03SM.PMM.CW.NET (PMDF V5.2-29 #33507) with ESMTP id <0F3700MQQTGIAR@PM03SM.PMM.CW.NET> for rem-conf@es.net; Mon, 30 Nov 1998 03:25:09 +0000 (GMT) Date: Sun, 29 Nov 1998 22:24:49 -0500 From: Henning Schulzrinne Subject: Re: A totally different (simpler?) approach to tones and errata To: Scott Petrack Cc: rem-conf@es.net Reply-to: hgs@cs.columbia.edu Message-id: <36621001.98196CEE@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science MIME-version: 1.0 X-Mailer: Mozilla 4.5b2 [en] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-US,de References: <422566CB.0058D15A.00@il4.vocaltec.co.il> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I just don't see the advantage of a table instead of the simple enumeration of frequencies. The space saving is rather minor, the amount of upgrade effort if we "forget" a combination is a major nuisance on the other hand. We are not coding tones explicitly to squeeze the last bit out of their transmission (since they are only a minor part of the overall network voice load, or otherwisee you are not going to be making money on your network...). From rem-conf Mon Nov 30 03:26:05 1998 From rem-conf-request@es.net Mon Nov 30 03:26:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkRN0-0002HO-00; Mon, 30 Nov 1998 03:19:58 -0800 Received: from sumo.vocaltec.co.il [199.203.72.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkRMx-0002HE-00; Mon, 30 Nov 1998 03:19:56 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id NAA13746; Mon, 30 Nov 1998 13:17:08 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566CC.003E3CC7 ; Mon, 30 Nov 1998 13:19:47 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: hgs@cs.columbia.edu cc: rem-conf@es.net Message-ID: <422566EA.00384AF2.00@il4.vocaltec.co.il> Date: Wed, 30 Dec 1998 13:17:07 +0200 Subject: Re: A totally different (simpler?) approach to tones and errata Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >I just don't see the advantage of a table instead of the simple >enumeration of frequencies. The simple enumeration of frequencies is what is done in the DTMF draft: after all, draft-ietf-avt-dtmf.txt just gives a table where index 1 means "697 Hz + 1209 Hz". I just thought that the advantages there also apply here. My understanding is that the combination of frequencies that is used in the world's telephone networks is pretty fixed and stable. It isn't going to grow. So the main advantage is just to do what is now done in DTMF. If one payload format is sufficient I thought that there is no reason to have two. There is nothing religious going on here, it's just that I thought to cut out uneeded generality. If people want the TSF (tone frequency format), I'm willing. Does anyone have a problem generating or detecting "any" frequency (as opposed to only the ones in current use)? Can I hear if anyone else has a thought on the subject? Maybe the easiest thing is to leave the tones draft more or less as I originally wrote it, with one payload type for named events and one for frequencies. (I would make the minor change that there could be more than two frequencies, and rearrange the modulation bits a bit better). Scott Henning Schulzrinne on 11/30/98 05:24:49 AM Please respond to hgs@cs.columbia.edu To: Scott Petrack cc: rem-conf@es.net Subject: Re: A totally different (simpler?) approach to tones and errata I just don't see the advantage of a table instead of the simple enumeration of frequencies. The space saving is rather minor, the amount of upgrade effort if we "forget" a combination is a major nuisance on the other hand. We are not coding tones explicitly to squeeze the last bit out of their transmission (since they are only a minor part of the overall network voice load, or otherwisee you are not going to be making money on your network...). From rem-conf Mon Nov 30 05:04:13 1998 From rem-conf-request@es.net Mon Nov 30 05:04:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkSxK-0003Ku-00; Mon, 30 Nov 1998 05:01:34 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkSxJ-0003Kk-00; Mon, 30 Nov 1998 05:01:33 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA05197; Mon, 30 Nov 1998 08:01:31 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA12590; Mon, 30 Nov 1998 08:01:30 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3662972A.9D7188C5@cs.columbia.edu> Date: Mon, 30 Nov 1998 08:01:30 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Herman Ranes , rem-conf@es.net Subject: Re: Subject: Tones References: <199811300833.DAA24142@cs.columbia.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id IAA05197 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Herman Ranes wrote: >=20 > =A7 >=20 > http://support.dialogic.com/resources/tones/. >=20 > Is this URL really correct? I receive an error message. It *was* correct until Dialogic removed the web page. From rem-conf Mon Nov 30 06:23:48 1998 From rem-conf-request@es.net Mon Nov 30 06:23:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkUBk-0004PF-00; Mon, 30 Nov 1998 06:20:32 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zkUBi-0004P5-00; Mon, 30 Nov 1998 06:20:30 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id JAA14773; Mon, 30 Nov 1998 09:19:51 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Scott Petrack cc: rem-conf@es.net Subject: Re: draft-ietf-avt-tones-00.txt submitted In-reply-to: Your message of "Wed, 18 Nov 1998 23:18:14 +0200." <422566C0.00747469.00@il4.vocaltec.co.il> Date: Mon, 30 Nov 1998 09:19:51 -0500 Message-ID: <14771.912435591@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Reading through this draft, I'm a little confused at what's being suggested for the use of the redundant payload format: A typical RTP packet, where the user is just dialing the last digit of the DTMF sequence "911". The first digit was 200 ms long and started at time 0, the second digit lasted 250 ms and started at time 800 ms, the third digit has just been pressed for 100 ms, at time 1.5 s. The frame duration is 50 ms. To make the parts recognizable, the figure below ignores byte alignment. Timestamp and sequence number are assumed to have been zero at the beginning of the first digit. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |0| 96 | 31 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 12000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | | 0x5234a8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | |1| 96 | 12400 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | |1| 96 | 5600 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Block PT | |0| 96 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |R R| volume | duration | | 9 |0 0| 7 | 1600 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |R R| volume | duration | | 1 |0 0| 10 | 2000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |R R| volume | duration | | 1 |0 0| 20 | 800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Now 50ms later, you send another packet. Assuming the user kept their finger on the 1 button, what is actually sent? There seem to be (at least) two options: - The third duration becomes 1200 and the timestamp becomes 12050, and the sequence number is incremented. - The third duration becomes 1200, the timestamp remains 12000, and I'm not clear if the sequence number gets incremented or not. Probably it does. In the first case the RTP timestamp is for the end of the last tone. In the second case it's for the beginning of the last tone. The latter is what I think you intended, and is in line with normal RTP usage, but leads to getting multiple packets for the same timestamp indicating different payloads (the duration changes). Any _normal_ RTP code that has already started playing out the tone of 100ms duration will discard the new packet because it's missed its playout point. Thus I don't think you can integrate this into a normal RTP player without putting all kinds of exception code in there. Did I miss something? Mark From rem-conf Mon Nov 30 08:25:59 1998 From rem-conf-request@es.net Mon Nov 30 08:25:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkW5s-0005vt-00; Mon, 30 Nov 1998 08:22:36 -0800 Received: from mailer.berkom.de [141.39.13.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkW5q-0005vj-00; Mon, 30 Nov 1998 08:22:34 -0800 Received: from gatekeeper4.telekom.de (gatekeeper4.berkom.de [141.39.2.1]) by mailer.berkom.de (8.8.8/8.8.8) with SMTP id QAA11521; Mon, 30 Nov 1998 16:11:58 +0100 (MET) Received: from mailgate4.telekom.de by gatekeeper4.telekom.de (5.65v3.2/1.1.10.5/29Nov96-0157PM) id AA10253; Mon, 30 Nov 1998 17:22:30 +0100 Received: from aix-serv.bln05.telekom.de by mailgate4.telekom.de (5.65v3.2/1.1.10.5/20Nov96-1032AM) id AA18398; Mon, 30 Nov 1998 17:22:30 +0100 Received: from berkom.de (W9F01592.dmst02.telekom.de [164.27.17.142]) by bln05.telekom.de (8.9.1/8.9.1) with ESMTP id RAA25396; Mon, 30 Nov 1998 17:23:09 +0100 Message-Id: <3662C5FF.C99A762B@berkom.de> Date: Mon, 30 Nov 1998 17:21:19 +0100 From: Olivier Avaro Reply-To: o.avaro@berkom.de Organization: Deutsche Telekom - Berkom X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: Jonathan Rosenberg Cc: Neal Schneider , rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981123193516.23981.qmail@hotmail.com> <365A3D6E.1D7847D9@dnrc.bell-labs.com> Content-Type: multipart/mixed; boundary="------------F3FCEC20CC8F441D98600C3F" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------F3FCEC20CC8F441D98600C3F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, Sorry to jump in late. If my mail seems provocative, it is just a consequence of my ignorance. The need of multiplexing audiovisual data has been identified in MPEG-4 few years ago and lead to the standardization of a solution named FlexMux. This solution is currently implemented and used by the free MPEG-4 software player Im1. Questions : 1- Does this solution has ever been proposed within this context ? 2- If so, has it been considered ? :-) 3- If so, what was the results of the consideration ? Answering these questions will greatly help to speed up the development of the specifications to carry MPEG-4 content over the internet. Currently, I understand that we may have two alternative tools that does the same job. No good. Thanks for your help, Olivier --------------F3FCEC20CC8F441D98600C3F Content-Type: text/x-vcard; charset=us-ascii; name="o.avaro.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Olivier Avaro Content-Disposition: attachment; filename="o.avaro.vcf" begin:vcard n:Olivier;Avaro x-mozilla-html:FALSE org:Deutsche Telekom - Berkom version:2.1 email;internet:o.avaro@berkom.de title:Chairman MPEG Systems Group - Project Manager tel;fax:+ 49 61 51 83 48 42 tel;work:+ 49 61 51 83 30 84 adr;quoted-printable:;;Deutsche Telekom Berkom GmbH=0D=0AAbt. T21;D-64307 Darmstadt;Deutschland;;Deutschland x-mozilla-cpt:;0 fn:Avaro Olivier end:vcard --------------F3FCEC20CC8F441D98600C3F-- From rem-conf Mon Nov 30 08:39:51 1998 From rem-conf-request@es.net Mon Nov 30 08:39:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkWIr-0006Nl-00; Mon, 30 Nov 1998 08:36:01 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkWIp-0006NU-00; Mon, 30 Nov 1998 08:35:59 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA16396; Mon, 30 Nov 1998 11:35:45 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA18105; Mon, 30 Nov 1998 11:35:28 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3662C950.8F16E573@cs.columbia.edu> Date: Mon, 30 Nov 1998 11:35:28 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Handley CC: Scott Petrack , rem-conf@es.net Subject: Re: draft-ietf-avt-tones-00.txt submitted References: <14771.912435591@north.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Both DTMF drafts (this segment is just a copy, more or less, of the stuff in avt-dtmf-01; thus, I'm jumping in here...) use the starting time of the digit for the timestamp and count the duration from that time. I agree that this raises issues as to "old" timestamps (past the playout point) appearing. A better mechanism may be to count the duration backwards from the timestamp instead of forwards and have each packet have a new timestamp indicating the sampling point. This is a bit different from standard audio usage, where the timestamp indicates the time of the first sample in the packet, however. From rem-conf Mon Nov 30 08:39:52 1998 From rem-conf-request@es.net Mon Nov 30 08:39:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkWKc-0006PM-00; Mon, 30 Nov 1998 08:37:50 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkWKb-0006PB-00; Mon, 30 Nov 1998 08:37:49 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA16597; Mon, 30 Nov 1998 11:37:47 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA18271; Mon, 30 Nov 1998 11:37:45 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3662C9D8.2EE5D3B1@cs.columbia.edu> Date: Mon, 30 Nov 1998 11:37:44 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: o.avaro@berkom.de CC: Jonathan Rosenberg , Neal Schneider , rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981123193516.23981.qmail@hotmail.com> <365A3D6E.1D7847D9@dnrc.bell-labs.com> <3662C5FF.C99A762B@berkom.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Olivier Avaro wrote: > > Hi all, > > Sorry to jump in late. If my mail seems provocative, it is just a consequence > of my ignorance. > > The need of multiplexing audiovisual data has been identified in MPEG-4 few > years ago and lead to the standardization of a solution named FlexMux. This > solution is currently implemented and used by the free MPEG-4 software player > Im1. > > Questions : > 1- Does this solution has ever been proposed within this context ? > 2- If so, has it been considered ? :-) > 3- If so, what was the results of the consideration ? Please consult the extensive discussion on this topic in the rem-conf mailing list archives. Besides, not the whole world will convert to MPEG-4 for all multimedia streams :-) > > Answering these questions will greatly help to speed up the development of the > specifications to carry MPEG-4 content over the internet. Currently, I > understand that we may have two alternative tools that does the same job. No > good. > > Thanks for your help, > > Olivier -- Henning Schulzrinne schulzrinne@cs.columbia.edu Dept. of Comp. Sci. ph +1 212 939-7042 Columbia University fax +1 212 666-0140 New York, NY 10027 http://www.cs.columbia.edu/~hgs From rem-conf Mon Nov 30 08:54:29 1998 From rem-conf-request@es.net Mon Nov 30 08:54:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkWZX-0007dH-00; Mon, 30 Nov 1998 08:53:15 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkWZV-0007d4-00; Mon, 30 Nov 1998 08:53:13 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA17490; Mon, 30 Nov 1998 11:53:11 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA18647; Mon, 30 Nov 1998 11:53:00 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3662CD6A.1FC3E24F@cs.columbia.edu> Date: Mon, 30 Nov 1998 11:52:59 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@es.net Subject: Re: A totally different (simpler?) approach to tones and errata References: <422566EA.00384AF2.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scott Petrack wrote: > > >I just don't see the advantage of a table instead of the simple > >enumeration of frequencies. > > The simple enumeration of frequencies is what is done in the DTMF draft: > after all, draft-ietf-avt-dtmf.txt just gives a table where index 1 means > "697 Hz + 1209 Hz". I just thought that the advantages there also apply > here. This is, I believe, somewhat different, since the set of DTMF signals won't be changed unless you modify a large fraction of the world's 640 million telephones. Adding new central-office tones doesn't require nearly that amount of change - one reason why DTMF is universal and CO tones are not. I think of DTMF "tones" as much more like the signal events like "Busy", except that they have a duration. > My understanding is that the combination of frequencies that is used > in the world's telephone networks is pretty fixed and stable. It isn't The problem is the "pretty". A few changes here and there are enough to make the table approach unwieldy at best. There may also be tones that the table misses (such as CNG and other fax/modem/control tones). A representation that can handle tones in the voiceband range seems much safer and adds only marginal space overhead. From a receiver perspective, it also seems easier, since I don't have to store the table. Plus, I can use it to play advertising jingles :-) This is not a major issue, but anything that doesn't require yet another IANA registry or 'vintages' on specifications is a win in my book... From rem-conf Mon Nov 30 08:55:39 1998 From rem-conf-request@es.net Mon Nov 30 08:55:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkWbh-00008Z-00; Mon, 30 Nov 1998 08:55:29 -0800 Received: from mailer.berkom.de [141.39.13.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkWbf-00008M-00; Mon, 30 Nov 1998 08:55:27 -0800 Received: from gatekeeper4.telekom.de (gatekeeper4.berkom.de [141.39.2.1]) by mailer.berkom.de (8.8.8/8.8.8) with SMTP id QAA12598; Mon, 30 Nov 1998 16:44:46 +0100 (MET) Received: from mailgate4.telekom.de by gatekeeper4.telekom.de (5.65v3.2/1.1.10.5/29Nov96-0157PM) id AA10749; Mon, 30 Nov 1998 17:55:25 +0100 Received: from aix-serv.bln05.telekom.de by mailgate4.telekom.de (5.65v3.2/1.1.10.5/20Nov96-1032AM) id AA19061; Mon, 30 Nov 1998 17:55:24 +0100 Received: from berkom.de (W9F01592.dmst02.telekom.de [164.27.17.142]) by bln05.telekom.de (8.9.1/8.9.1) with ESMTP id RAA17962; Mon, 30 Nov 1998 17:56:12 +0100 Message-Id: <3662CDBF.5BC55E5D@berkom.de> Date: Mon, 30 Nov 1998 17:54:23 +0100 From: Olivier Avaro Reply-To: o.avaro@berkom.de Organization: Deutsche Telekom - Berkom X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , Neal Schneider , rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981123193516.23981.qmail@hotmail.com> <365A3D6E.1D7847D9@dnrc.bell-labs.com> <3662C5FF.C99A762B@berkom.de> <3662C9D8.2EE5D3B1@cs.columbia.edu> Content-Type: multipart/mixed; boundary="------------49E23DB2750997C7631A2922" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------49E23DB2750997C7631A2922 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Besides, not the whole world will convert to MPEG-4 for all multimedia > streams :-) My question was more practical : Can we re-use the work that have been done instead of re-inventing the wheel ? than meta-technical: Why is there nothing rather than MPEG-4 ? But sure, I'll consult the archives :-) Pointer to the archives ? Thanks. O. --------------49E23DB2750997C7631A2922 Content-Type: text/x-vcard; charset=us-ascii; name="o.avaro.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Olivier Avaro Content-Disposition: attachment; filename="o.avaro.vcf" begin:vcard n:Olivier;Avaro x-mozilla-html:FALSE org:Deutsche Telekom - Berkom version:2.1 email;internet:o.avaro@berkom.de title:Chairman MPEG Systems Group - Project Manager tel;fax:+ 49 61 51 83 48 42 tel;work:+ 49 61 51 83 30 84 adr;quoted-printable:;;Deutsche Telekom Berkom GmbH=0D=0AAbt. T21;D-64307 Darmstadt;Deutschland;;Deutschland x-mozilla-cpt:;0 fn:Avaro Olivier end:vcard --------------49E23DB2750997C7631A2922-- From rem-conf Mon Nov 30 09:10:22 1998 From rem-conf-request@es.net Mon Nov 30 09:10:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkWok-0001Nd-00; Mon, 30 Nov 1998 09:08:58 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zkWoj-0001NT-00; Mon, 30 Nov 1998 09:08:57 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id MAA15122; Mon, 30 Nov 1998 12:07:41 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Henning Schulzrinne cc: Scott Petrack , rem-conf@es.net Subject: Re: draft-ietf-avt-tones-00.txt submitted In-reply-to: Your message of "Mon, 30 Nov 1998 11:35:28 EST." <3662C950.8F16E573@cs.columbia.edu> Date: Mon, 30 Nov 1998 12:07:41 -0500 Message-ID: <15120.912445661@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Both DTMF drafts (this segment is just a copy, more or less, of the >stuff in avt-dtmf-01; thus, I'm jumping in here...) use the starting >time of the digit for the timestamp and count the duration from that >time. I agree that this raises issues as to "old" timestamps (past the >playout point) appearing. A better mechanism may be to count the >duration backwards from the timestamp instead of forwards and have each >packet have a new timestamp indicating the sampling point. This is a bit >different from standard audio usage, where the timestamp indicates the >time of the first sample in the packet, however. In general, it's a little tricky to imagine how to playout these tones as tones in the presence of packet loss. This isn't a problem for machines that take the dtmf packets directly as input, but if there's a gateway back to audio-tones, this becomes problematic. The problem is that a player needs to assume a fixed playout delay, but the form of redundancy used gives a variable playout delay up to the maximum offset of the redundancy (2s). If I choose anything less than the 2s maximum offset, then I can't make use of the redundancy being given. Say the sender is sending tone packets every 50ms, and the receiver chooses a 90ms playout delay (based on previous audio jitter), and then lose two packets in a row . Now the receiver doesn't know whether it should play the previous tone for those two packets or insert silence. When the third packet turns up, it's too late. You need appplication-context information to know what the correct course of action is. In the case of DTMF, I'd say the best bet would be to treat the encoding as stateful and continue to play the previous tone until a new DTMF packet turns up. This may result in a tone being played too long, but the next tone can always be shortened to make up for this. DTMF tones recognition equipment doesn't normally care about tone duration. At this doesn't split a tone into two distinct tones, which would confuse downstream recognition systems. I don't know what the correct behaviour is for other tones Scott lists. Perhaps each packet should have information that says how long the tone should play for in the absense of future packets? Mark From rem-conf Mon Nov 30 13:18:11 1998 From rem-conf-request@es.net Mon Nov 30 13:18:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkaY4-00059S-00; Mon, 30 Nov 1998 13:08:00 -0800 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0zkaY3-00059G-00; Mon, 30 Nov 1998 13:07:59 -0800 Received: from research.att.com ([135.207.30.100]) by rumor; Mon Nov 30 16:01:12 EST 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Mon Nov 30 16:05:16 EST 1998 Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id QAA25886; Mon, 30 Nov 1998 16:04:04 -0500 (EST) Message-ID: <00b501be1ca5$2cd9b7c0$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: "adv reflector" , "4onip-sys" <4onip-sys@fzi.de>, <4on2-sys@fzi.de>, Subject: Packet Video 99- Last Call for papers Date: Mon, 30 Nov 1998 16:04:24 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00AF_01BE1C7B.19642060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00AF_01BE1C7B.19642060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Andrea Basso, AT&T Labs Research Senior Technical Staff Member Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com ------=_NextPart_000_00AF_01BE1C7B.19642060 Content-Type: text/plain; name="pkvd99cfpnew.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pkvd99cfpnew.txt" CALL FOR PAPERS Packet Video '99=20 The 9th International Packet Video Workshop=20 26-27 April 1999=20 New York City, U.S.A http://www.research.att.com/~mrc/PacketVideo99.html=20 In Europe: http://www.inria.fr/rodeo/turletti/pv99/=20 Sponsored by: AT&T, Columbia University, EURASIP, IEEE Signal Processing Society IMDSP & MMSP Technical Committees=20 The ninth International Packet Video Workshop (PV' 99) will be held at = the Davis auditorium, of Columbia University in New York City. The = workshop is devoted to presenting technological advancements and = innovations in video transmission over packet networks, in particular, = the Internet. Packet Video Workshops have been unique in providing a = common ground for people from video coding and networking fields. = Presentations on theory and practice, standards activities, and business = and consumer applications are encouraged. We cordially invite you to take part in this workshop by submitting your = work and look forward to seeing you in New York City in April 1999 for = what will be a most rewarding and exciting experience! =20 PV'99 is scheduled to take place in the week following Picture Coding = Symposium 99 (PCS' 99) which is being held in Portland Oregon, on 21-23 = April 1999. For information on PCS'99 please contact: pcs@pcs.ece.orst.edu TECHNICAL PROGRAM=20 The technical program of Packet Video '99 will consist of invited talks, = submitted paper presentations, poster sessions and a plenary session: = "After Internet Telephony, Internet Television..." Topics of interest include, but are not limited to, the following: * Video streaming over the Internet * Network adaptive video coding and transport * Packetized video for home LAN's * Packetized video for wireless/mobile systems * Layered coding for error resilience and heterogeneous networks * Packet loss resilient coding and transport=20 * Terminal and server architectures for Internet TV * Efficient transcoding for heterogeneous networks=20 * Congestion control * Error concealment * Statistical multiplexing for greater network and terminal utilization * Traffic shaping for efficient network and terminal utilization=20 * Interstream synchronization for multiple video presentations=20 * Performance modeling and evaluation * Rate control for VBR video * International Standards: MPEG-4, MPEG-7, H.263+, RTP, RTSP, SIP, SDP * Multicasting, MBONE applications * Implementations and commercial applications Best Paper Award: The author of the best paper will receive: A $250 cash = prize graciously donated by NEC USA, C&C Research Laboratories. Manuscripts submitted to PV'99 will be considered for publication in the = special issue of EURASIP Journal Signal Processing: Image Communication, = REAL-TIME VIDEO OVER THE INTERNET also. Submissions Please submit an electronic manuscript written in HTML, not exceeding 7 = Mbytes and 10 printed pages. We will produce a CD-ROM containing the = accepted papers. Electronic components accompanying your submission are = strongly encouraged. Submit your work in ONE of the following forms:=20 1) a set of HTML files organized in a single directory OR 2) as a URL (you must have the rights to all the material there, and = guarantee stability of the files until the conference). Detailed submission instructions for authors and help with manuscript = preparation=20 with HTML can be found on the conference web page:=20 =20 http://www.research.att.com/~mrc/PacketVideo99.html=20 ALL SUBMISSIONS MUST BE RECEIVED no later than: December 15th, 1998,=20 NOTIFICATION OF ACCEPTANCE: February 1, 1999 FINAL PAPERS DUE: March 15, 1999=20 GENERAL CHAIR PUBLICATION & LOCAL ARRANGEMENTS M. Reha Civanlar Andrea Basso AT&T Labs - Research AT&T Labs - Research 100 Schultz Drive, 3-213 100 Schultz Drive, 3-219 Red Bank, NJ 07701 Red Bank, NJ 07701 USA USA civanlar@research.att.com basso@research.att.com =09 PACKET VIDEO' 99 INTERNATIONAL STEERING COMMITTEE John Arnold, University of New South Wales, Australia Andrea Basso, AT&T Labs - Research, USA Stephen Casner, Precept Software, USA Shih-Fu Chang, Columbia University, USA Leonardo Chiariglione, CSELT, Italy M. Reha Civanlar, AT&T Labs - Research, USA Jon Crowcroft, University College of London, UK Mohammed Ghanbari, University of Essex UK Barry G. Haskell AT&T Labs - Research, USA Steven McCanne, U. C. Berkeley, USA Geoff Morrison, BT Labs, UK Joerg Ott, University of Bremen, Germany Sakae Okubo, Graphics Communication Labs, Japan D. Raychaudhuri, NEC Research, USA Amy Reibman, AT&T Labs - Research, USA Henning Schulzrinne, Columbia University, USA Gary Sullivan, PictureTel, USA Toshitaka Tsuda, Fujitsu, Japan Thierry Turletti, INRIA, France Stephan Wenger, Technical University of Berlin, Germany Hiroshi Yasuda, NTT, Japan ------=_NextPart_000_00AF_01BE1C7B.19642060-- From rem-conf Mon Nov 30 16:03:37 1998 From rem-conf-request@es.net Mon Nov 30 16:03:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkd9y-00077i-00; Mon, 30 Nov 1998 15:55:18 -0800 Received: from abu.ntu.edu.au [138.80.54.117] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkd9x-00077U-00; Mon, 30 Nov 1998 15:55:17 -0800 Received: (from malcolm@localhost) by abu.ntu.edu.au (8.7.5/8.7.3) id JAA08645 for rem-conf@es.net; Tue, 1 Dec 1998 09:25:55 +0930 (CST) Message-ID: <19981201092554.A8164@abu.ntu.edu.au> Date: Tue, 1 Dec 1998 09:25:54 +0930 From: Malcolm Caldwell To: rem-conf@es.net Subject: Linux vat Mail-Followup-To: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am looking for a version of vat for linux that will run cards supported by video for linux, or better video for linux 2. I have been on the list for a long time. I have a lot of problems finding various versions of vic for different platforms. I guess the problem is that vic stopped being supported. Heaps of people have made their own versions with various cards supported etc. I know I could find a archive somewhere, and go through and find what I am looking for, but that would take quite a long time. What is needed is a real "vic" web page, with a list of all the different versions. -- Malcolm Caldwell - Network Supervisor Email:malcolm@it.ntu.edu.au Information Technology Support Ph: +61 8 89466631 Northern Territory University,Darwin Fax: +61 8 89466630 CASUARINA 0909 Australia From rem-conf Mon Nov 30 17:15:40 1998 From rem-conf-request@es.net Mon Nov 30 17:15:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkeIi-0000Rv-00; Mon, 30 Nov 1998 17:08:24 -0800 Received: from f91.hotmail.com (hotmail.com) [207.82.250.197] by mail1.es.net with smtp (Exim 1.81 #2) id 0zkeIh-0000Rd-00; Mon, 30 Nov 1998 17:08:23 -0800 Received: (qmail 13623 invoked by uid 0); 1 Dec 1998 01:07:22 -0000 Message-ID: <19981201010722.13622.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Mon, 30 Nov 1998 17:07:21 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: nschneid@hotmail.com, jdrosen@dnrc.bell-labs.com Cc: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 30 Nov 1998 17:07:21 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Yes, I agree that jitter control and adaptive playout buffers are a good >thing. But, I don't see why this is an argument for throwing away >timestamps. Let me put my argument of throwing out timestamps into context. When multiplexing multiple sessions, it is a requirement to retain enough information to recreate the necessary elements of the real-time protocol. One solution discussed in mux_issues was to retain the entire timestamp. As we all know, efficiency is more often than not an issue (especially with small payloads as in voice), and header reduction is greatly appreciated. Thus, the proposal for timestamp offsets was introduced, to represent an individual timestamp as an offset to the group RTP timestamp. The problem with this, arises when/if individual calls do not arrive at consistant intervals to the multiplexing engine (i.e. over a packet switched network, rather than a TDM.) Then the offset becomes very difficult to calculate appropriately, if at all. The original information must be retained. Since the sequence numbers are typically smaller than the timestamp offsets, it might be better to retain the sequence number rather than the timestamp information. Once again, this is only appropriate if the timestamps increase monotonicly. So my theory was to replace 'timestamps offsets' as a header optimization technique with the use sequence numbers. Regards, Neal A. Schneider ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com