] /opt/SUNWsvpab/collinfo /opt/SUNWsvpab/socat [ verifying class ] ## Executing postinstall script. Adding AnswerBook Collections with command: /usr/lib/ab2/bin/ab2admin -o install -n SUNWsvpab -d /opt/SUNWsvpab/collinfo Added : SunVideo Plus Collection Restarting the server /usr/lib/ab2/bin/ab2admin -o stop /usr/lib/ab2/bin/ab2admin -o start Installation of was successful. Processing package instance from SunVTS Sun Video Plus test module (sparc) 2.1.1,REV=1999.09.17 Copyright 1999 Sun Microsystems, Inc. All rights reserved. Using as the package base directory. ## Processing package information. ## Processing system information. 3 package pathnames are already properly installed. ## Verifying package dependencies. WARNING: The package "SunVideo Plus PCI Card Device Driver." is a prerequisite package and should be installed. WARNING: The package "Online Validation Test Suite" is a prerequisite package and should be installed. Do you want to continue with the installation of [y,n,?] y ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. This package contains scripts which will be executed with super-user permission during the process of installing this package. Do you want to continue with the installation of [y,n,?] y Installing SunVTS Sun Video Plus test module as ## Installing part 1 of 1. /opt/SUNWvts/bin/o1k_dma.ref /opt/SUNWvts/bin/o1ktest /opt/SUNWvts/bin/o1ktest_info.o /opt/SUNWvts/bin/sparcv9/o1ktest_info.o /opt/SUNWvts/bin/testadd /opt/SUNWvts/bin/testrm /opt/SUNWvts/lib/locale/C/LC_MESSAGES/o1ktest.msg [ verifying class ] ## Executing postinstall script. /usr/ccs/bin/nm: /opt/SUNWvts/bin/vtsinfo.so: No such file or directory o1ktest_info.o is in vtsinfo.a, and testprobe_o1ktest in vtsinfo.so. o1ktest is added to SunVTS. Installation of was successful. The following packages are available: 1 SUNWo1kpu SunVideo Plus Runtime Support Software (sparc) 1.3,REV=1.3.1 2 SUNWopi OPI Runtime Library Package (sparc) 2.2,REV=2.2.0 3 SUNWopi1k SunVideoPlus OPI Runtime Package (sparc) 2.2,REV=2.2.0 4 SUNWsvpab SunVideo Plus Collection (all) 188.2.4 5 SUNWvtsvp SunVTS Sun Video Plus test module (sparc) 2.1.1,REV=1999.09.17 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: q -------------------------------------------------------------------------------- Output from "cd ../../Solaris_2.6/Packages; pkgadd -d ." command: bil[root]csh:63>pkgadd -d . The following packages are available: 1 SUNWo1kpd.u SunVideo Plus PCI Card Device Driver. (sparc.sun4u) 1.3,REV=2.3.1 2 SUNWo1kpx SunVideo Plus XIL-1.3 Runtime Support Software (sparc) 5.6,REV=1.3.0 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: Processing package instance from SunVideo Plus PCI Card Device Driver. (sparc.sun4u) 1.3,REV=2.3.1 Copyright 1999 Sun Microsystems, Inc. All rights reserved. Copyright (c) 1999 MultiMedia Access Corporation - Osprey Technologies Inc. All Rights Reserved. This product and related documentation is protected by copyright laws and international treaties. No part of this product or related documentation may be reproduced, distributed, or decompiled in any form by any means without prior written authorization of MultiMedia Access Corporation. Unauthorized reproduction or distribution of this program, or any part of it, may result in severe civil and criminal penalties, and will be prosecuted to the maximum extent possible under the law. MMAC reserves the right to change any products herein at any time and without notice. MMAC does not assume any liability arising from the application or use of this product, except as expressly agreed to in writing by MMAC. Use and purchase of this product does not convey a license under any patent rights, copyrights, trademark rights, or any other intellectual property rights of MMAC, Sun Microsystems, or others. Sun, Sun Microsystems, Solaris, SunOS, OpenWindows, XView, VideoPix and SunVideo are trademarks or registered trademarks of Sun Microsystems, Inc. All other product names mentioned herein are the trademarks of their respective owners. ## Executing checkinstall script. Using as the package base directory. ## Processing package information. ## Processing system information. 6 package pathnames are already properly installed. ## Verifying package dependencies. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. This package contains scripts which will be executed with super-user permission during the process of installing this package. Do you want to continue with the installation of [y,n,?] y Installing SunVideo Plus PCI Card Device Driver. as ## Executing preinstall script. removing old drivers Looking for and Removing old device entries ## Installing part 1 of 1. /etc/init.d/o1k-config /etc/opt/SUNWo1kp/dbm/o1kctl_0 /etc/opt/SUNWo1kp/dbm/o1kctl_1 /etc/opt/SUNWo1kp/dbm/o1kctl_2 /etc/opt/SUNWo1kp/dbm/o1kctl_3 /etc/opt/SUNWo1kp/dbm/o1kctl_4 /etc/opt/SUNWo1kp/dbm/o1kctl_5 /etc/opt/SUNWo1kp/dbm/o1kctl_6 /etc/opt/SUNWo1kp/dbm/o1kctl_7 /etc/opt/SUNWo1kp/dbm/o1kctl_t0 /etc/opt/SUNWo1kp/dbm/o1kctl_t1 /etc/opt/SUNWo1kp/dbm/o1kctl_t2 /etc/opt/SUNWo1kp/dbm/o1kctl_t3 /etc/opt/SUNWo1kp/dbm/o1kctl_t4 /etc/opt/SUNWo1kp/dbm/o1kctl_t5 /etc/opt/SUNWo1kp/dbm/o1kctl_t6 /etc/opt/SUNWo1kp/dbm/o1kctl_t7 /kernel/drv/o1k /kernel/drv/o1k.conf [ verifying class ] /etc/rc2.d/S93o1k-config [ verifying class ] ## Executing postinstall script. compatible: 'pci1061,3' + 'pciclass,048000' Found o1k Based Hardware Adding driver now... Could not unlink /dev/dsk/c1t5d0s0 because: No such file or directory Installation of was successful. Processing package instance from SunVideo Plus XIL-1.3 Runtime Support Software (sparc) 5.6,REV=1.3.0 Copyright 1999 Sun Microsystems, Inc. All rights reserved. Copyright (c) 1999 MultiMedia Access Corporation - Osprey Technologies Inc. All Rights Reserved. This product and related documentation is protected by copyright laws and international treaties. No part of this product or related documentation may be reproduced, distributed, or decompiled in any form by any means without prior written authorization of MultiMedia Access Corporation. Unauthorized reproduction or distribution of this program, or any part of it, may result in severe civil and criminal penalties, and will be prosecuted to the maximum extent possible under the law. MMAC reserves the right to change any products herein at any time and without notice. MMAC does not assume any liability arising from the application or use of this product, except as expressly agreed to in writing by MMAC. Use and purchase of this product does not convey a license under any patent rights, copyrights, trademark rights, or any other intellectual property rights of MMAC, Sun Microsystems, or others. Sun, Sun Microsystems, Solaris, SunOS, OpenWindows, XView, VideoPix and SunVideo are trademarks or registered trademarks of Sun Microsystems, Inc. All other product names mentioned herein are the trademarks of their respective owners. ## Executing checkinstall script. XIL 1.3 is available on system... Using as the package base directory. ## Processing package information. ## Processing system information. 7 package pathnames are already properly installed. ## Verifying package dependencies. ## Verifying disk space requirements. ## Checking for conflicts with packages already installed. ## Checking for setuid/setgid programs. This package contains scripts which will be executed with super-user permission during the process of installing this package. Do you want to continue with the installation of [y,n,?] y Installing SunVideo Plus XIL-1.3 Runtime Support Software as ## Installing part 1 of 1. /usr/openwin/lib/xil/devhandlers/xilCompute_CellBMMACo1k.so.2 /usr/openwin/lib/xil/devhandlers/xilCompute_H261MMACo1k.so.2 /usr/openwin/lib/xil/devhandlers/xilCompute_JpegMMACo1k.so.2 /usr/openwin/lib/xil/devhandlers/xilCompute_Mpeg1MMACo1k.so.2 /usr/openwin/lib/xil/devhandlers/xilCompute_UYVYMMACo1k.so.2 /usr/openwin/lib/xil/devhandlers/xilIO_MMACo1k.so.2 /usr/openwin/lib/xil/locale/C/LC_MESSAGES/xilIO_MMACo1k.mo [ verifying class ] [ verifying class ] Installation of was successful. The following packages are available: 1 SUNWo1kpd.u SunVideo Plus PCI Card Device Driver. (sparc.sun4u) 1.3,REV=2.3.1 2 SUNWo1kpx SunVideo Plus XIL-1.3 Runtime Support Software (sparc) 5.6,REV=1.3.0 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: q -------------------------------------------------------------------------------- From rem-conf Thu Apr 13 12:07:14 2000 From rem-conf-request@es.net Thu Apr 13 12:07:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12fovG-0002wk-00; Thu, 13 Apr 2000 12:05:02 -0700 Received: from dnsserver.altitude.fr (frida.normandnet.fr) [195.7.102.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 12fovE-0002sk-00; Thu, 13 Apr 2000 12:05:01 -0700 Received: from AIVP-EG (195.7.97.35 [195.7.97.35]) by frida.normandnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 2RGPGMH0; Thu, 13 Apr 2000 12:52:27 +0200 Reply-To: infos@aivp.net From: "Infos - AIVP" To: aivp@es.net Subject: 7a Conferencia Internacional Ciudades y Puertos Date: Thu, 13 Apr 2000 12:15:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: promo.conference@aivp.net Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 7a Conferencia Internacional Ciudades y Puertos 7th International Conference Cities & Ports 6-9 november 2000 Marseille (France) ===== Del 6 al 9 del pr�ximo mes de noviembre, los responsables del desarrollo urbano y portuario de las ciudades mar�timas y fluviales de todo el mundo se dan cita en Marsella (Francia) para la 7� Conferencia Internacional de las Ciudades y Puertos organizada por la Asociaci�n Internacional Ciudades y Puertos. (AIVP). Se esperan en Marsella a m�s de 500 delegados representantes de las ciudades portuarias de m�s de 50 pa�ses para discutir e intercambiar sus experiencias sobre la puesta en marcha de un desarrollo sostenible de las plazas portuarias. �Le interesa este reto? �Le concierne este encuentro? Sin ning�n compromiso de su parte, le proponemos mantenerle informado de forma gratuita sobre la evoluci�n del programa de esta conferencia > enviando un mensaje a : listees.conference@aivp.net con la palabra SUBSCRIBE en el objeto del mensaje (mailto:listees.conference@aivp.net?subject=SUBSCRIBE) > via nuestro website http://www.aivp.com/7conf/formes.asp ===== Urban and port development authorities for coastal and river cities from throughout the entire world will be meeting in Marseilles (France), from the 6th to the 9th of November next, for the 7th Cities and Ports (IACP) International Conference. More than 500 delegates representing the port cities of more than 50 countries are expected in Marseilles to debate and exchange views regarding the implementation of sustainable development in port areas. This challenge is of interest to you ? This meeting concerns you ? We propose, without any committment on your behalf, to keep you informed free of charge of the programme development of this conference > by sending a message to : listegb.conference@aivp.net with SUBSCRIBE as subject (mailto:listegb.conference@aivp.net?subject=SUBSCRIBE) >or via our website http://www.aivp.com/7conf/formgb.asp From rem-conf Thu Apr 13 12:07:20 2000 From rem-conf-request@es.net Thu Apr 13 12:07:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12fosD-0002kg-00; Thu, 13 Apr 2000 12:01:53 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 12fosB-0002jh-00; Thu, 13 Apr 2000 12:01:51 -0700 Received: from billings.nlm.nih.gov (billings [130.14.31.31]) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) with ESMTP id PAA16938; Thu, 13 Apr 2000 15:01:44 -0400 (EDT) Received: (from rodgers@localhost) by billings.nlm.nih.gov (8.8.8+Sun/8.8.8) id PAA18007; Thu, 13 Apr 2000 15:01:44 -0400 (EDT) Date: Thu, 13 Apr 2000 15:01:44 -0400 (EDT) From: "R. P. Channing Rodgers, M.D." Message-Id: <200004131901.PAA18007@billings.nlm.nih.gov> To: mbone@isi.edu, rem-conf@es.net Subject: sunforuym and "Directory server" software for conferencing? Cc: aronson@billings.nlm.nih.gov, K.Hasler@cs.ucl.ac.uk, O.Hodson@cs.ucl.ac.uk X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, A brief follow-on question. Sunforum (and other) teleconferencing software refer to "directory servers" such as the ones at: ils.microsoft.com ils1.microsoft.com, ..., ils9.microsoft.com ils.four11.com ils.business.four11.com ils.family.four11.com I have never been able to successfully connect to any of these from sunforum, but whether it is because they are too busy, incompatible, require some kind of authentication, it's unclear. I assume that these servers are doing soe H.323-related activities such as port assignment, as well as keeping you on a list of folks who are currently available to conference with. Does anyone know of (preferably freely available) server software, for the creation of a local service of this type? Thanks and Cheerio, Rick Rodgers From rem-conf Fri Apr 14 00:41:21 2000 From rem-conf-request@es.net Fri Apr 14 00:41:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12g0Ta-00049e-00; Fri, 14 Apr 2000 00:25:14 -0700 Received: from jenny.panasonic.de [194.221.52.13] by mail1.es.net with esmtp (Exim 1.81 #2) id 12g0TY-00047C-00; Fri, 14 Apr 2000 00:25:12 -0700 Received: from panasonic.de ([192.129.34.60]) by jenny.panasonic.de (Sun Internet Mail Server sims.4.0.2000.01.27.13.16.p5) with ESMTP id <0FSZ0086ZWK9GT@jenny.panasonic.de> for rem-conf@es.net; Fri, 14 Apr 2000 09:24:09 +0200 (MET DST) Date: Fri, 14 Apr 2000 09:27:07 +0200 From: Carsten Burmeister Subject: Multiple selective retransmissions To: rem-conf@es.net Message-id: <38F6C84B.15F957AA@panasonic.de> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, we gave a short presentation in Adelaide about selective retransmissions in RTP. We described mainly the content of the I-D: "RTP Payload Type Format to Enable Selective Retransmissions", which can be found at: http://www.pel.panasonic.de/ietf/docs/draft-miyazaki-avt-rtp-selret-00.txt http://www.pel.panasonic.de/ietf/docs/draft-miyazaki-avt-rtp-selret-00.ps In discussions after the meeting we got the impression that we have not stated clear enough the need for the additional header field "SNHP". We think this kind of field is necessary to do multiple selective retransmissions. We prepared some figures, which should explain this in greater detail. This figures can be found under the following URL: http://www.pel.panasonic.de/ietf/docs/Clarification_of_SNHP.ppt http://www.pel.panasonic.de/ietf/docs/Clarification_of_SNHP.ps The increased performance of video streaming applications over wireless links, using this field, are shown by the means of simulations in the I-D. Any comments are welcome.... Carsten From rem-conf Fri Apr 14 13:45:14 2000 From rem-conf-request@es.net Fri Apr 14 13:45:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12gCms-0005Tr-00; Fri, 14 Apr 2000 13:33:58 -0700 Received: from mickey.ee.pdx.edu [131.252.208.42] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12gCmq-0005PW-00; Fri, 14 Apr 2000 13:33:57 -0700 Received: from chip.ee.pdx.edu (videoc@chip.ee.pdx.edu [131.252.221.60]) by mickey.ee.pdx.edu (8.9.1/8.9.1) with ESMTP id NAA12458; Fri, 14 Apr 2000 13:24:59 -0700 (PDT) From: Video Compression Workshop Received: (from videoc@localhost) by chip.ee.pdx.edu (8.8.6/8.8.5) id NAA17874; Fri, 14 Apr 2000 13:04:56 -0700 (PDT) Date: Fri, 14 Apr 2000 13:04:56 -0700 (PDT) Message-Id: <200004142004.NAA17874@chip.ee.pdx.edu> To: videoc@ee.pdx.edu Subject: Video Compression Short Course in Portland 8/7-12/2000 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Subject: Video Compression Short Course in Portland 8/7-12/2000 4 & 1/2 Days (August 7 - 12, 2000) in Portland Oregon on IMAGE AND VIDEO COMPRESSION: FUNDAMENTALS, STANDARDS, AND APPLICATIONS Featured: Majid Rabbani - Eastman Kodak M. Ibrahim Sezan - Sharp Labs. of America Thomas Gardos - Intel Corporation Organized by Fu Li Portland State University, Portland, Oregon, USA please visit http://www.ee.pdx.edu/~compress Contact Don Mueller at Telephone: (503) 725-3806 Facsimile: (503) 725-3807 Email: donm@eas.pdx.edu Comprehensive Coverage on JPEG-2000, MPEG -4 and -7, and H.26x Standards! With Latest Technology Demos Seats limited. Please register today! From rem-conf Mon Apr 17 01:09:11 2000 From rem-conf-request@es.net Mon Apr 17 01:09:09 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 12h6Jg-0004kp-00; Mon, 17 Apr 2000 00:51:32 -0700 Received: from abdccc6a.ipt.aol.com ([171.220.204.106] helo=area51.japannet.com) by mail2.es.net with smtp (Exim 1.92 #1) id 12h6Jc-0004kf-00; Mon, 17 Apr 2000 00:51:29 -0700 From: Subject: We Have Answers for YOU Date: Mon, 17 Apr 2000 00:11:17 Message-Id: <665.735308.759563@area51.japannet.com> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Are you interested in refinancing your existing mortgage, Paying off bills, Consolidating debt, Doing home improvements, or Purchasing a big ticket item? Are you interested in Purchasing a new home or are you a First time homebuyer? If so, we have ANSWERS for YOU even if you have poor credit. For more information please reply:jdarby002@earthlink.net ------------------------------------------------------------ Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter cannot be considered "spam" as long as we include: 1) contact information (see above); and, 2) the way to be removed >from future mailings (see below). To be removed from this list, please mail to: jdarby001@earthlink.net with 'remove' in subject line and you will be removed from our list. ------------------------------------------------------------ From rem-conf Mon Apr 17 07:13:33 2000 From rem-conf-request@es.net Mon Apr 17 07:13:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12hCBg-0001h6-00; Mon, 17 Apr 2000 07:07:40 -0700 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 12hCBe-0001gJ-00; Mon, 17 Apr 2000 07:07:38 -0700 Received: from super.du.uab.ericsson.se (root@super.du.uab.ericsson.se [134.138.176.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA27183 for ; Mon, 17 Apr 2000 16:07:33 +0200 (MET DST) Received: from martell.du.uab.ericsson.se (mml@martell [134.138.176.69]) by super.du.uab.ericsson.se (8.10.0/8.10.0/erix-1.7) with ESMTP id e3HE7Fv00021 for ; Mon, 17 Apr 2000 16:07:15 +0200 (MET DST) Received: by martell.du.uab.ericsson.se (8.10.0/client-1.7) id e3HE7Fs01966; Mon, 17 Apr 2000 16:07:15 +0200 (MET DST) Message-ID: <14587.6803.75296.499527@gargle.gargle.HOWL> Date: Mon, 17 Apr 2000 16:07:15 +0200 (MET DST) From: Matthias.Lang@ericsson.com To: rem-conf@es.net Subject: How to pack multiple GSM frames into one RTP packet X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Apologies if this has come up before, I've searched and not found an answer. How do you pack two GSM frames into one RTP packet? A GSM frame is 260 bits (32.5 octets) long. Method #1: Since a single GSM frame is transmitted as 33 octets, i.e. the frame plus a nybble of padding, two GSM frames should be transmitted in 66 octets. This is what RAT does. Method #2: Since a single GSM frame is really 32.5 octets, two GSM frames should be transmitted as 65 octets. This is what another implementation I've seen does. Maybe RFC1890 could say something like RTP payloads with frames which do not end on octet boundaries should (must?) be zero-padded to the next octet boundary. This applies even when several frames are transmitted in one packet. I note that this may cause problems for G.728. I don't know. Maybe it should say the opposite, i.e. that no padding is allowed except at the end of the packet. This has nothing to do with RTP padding. I can think of efficient software and hardware codec implementations either way. Comments? Matthias From rem-conf Mon Apr 17 09:03:09 2000 From rem-conf-request@es.net Mon Apr 17 09:03:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12hDxB-0003b4-00; Mon, 17 Apr 2000 09:00:49 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 12hDx9-0003au-00; Mon, 17 Apr 2000 09:00:48 -0700 Received: from cabo2 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id SAA26327; Mon, 17 Apr 2000 18:00:42 +0200 (MET DST) From: "Dr. Carsten Bormann" To: , Subject: RE: How to pack multiple GSM frames into one RTP packet Date: Mon, 17 Apr 2000 18:00:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <14587.6803.75296.499527@gargle.gargle.HOWL> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Method #1: Since a single GSM frame is transmitted as 33 octets, i.e. > the frame plus a nybble of padding, two GSM frames should be > transmitted in 66 octets. This is what RAT does. This is also what the current draft standards document says: http://search.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.txt, section 4.5.8.1: In the GSM packing used by RTP, the bits SHALL be packed beginning from the most significant bit. Every 160 sample GSM frame is coded into one 33 octet (264 bit) buffer. Every such buffer begins with a 4 bit signature (0xD), followed by the MSB encoding of the fields of the frame. The first octet thus contains 1101 in the 4 most significant bits (0-3) and the 4 most significant bits of F1 (0-3) in the 4 least significant bits (4-7). The second octet contains the 2 least significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so on. Note that this is the document that is intended to supersede RFC1890. Gruesse, Carsten PS.: And I apologize for having my hand in designing it that way 8 years ago... From rem-conf Mon Apr 17 09:52:49 2000 From rem-conf-request@es.net Mon Apr 17 09:52:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12hEk7-0004kR-00; Mon, 17 Apr 2000 09:51:23 -0700 Received: from dsl-berson.isi.edu (qos.isi.edu) [128.9.16.247] by mail1.es.net with esmtp (Exim 1.81 #2) id 12hEk5-0004kH-00; Mon, 17 Apr 2000 09:51:21 -0700 Received: from localhost (berson@localhost) by qos.isi.edu (8.9.3/8.9.3) with ESMTP id JAA02165 for ; Mon, 17 Apr 2000 09:51:20 -0700 X-Authentication-Warning: qos.isi.edu: berson owned process doing -bs Date: Mon, 17 Apr 2000 09:51:19 -0700 (PDT) From: To: rem-conf@es.net Subject: Re: We Have Answers for YOU In-Reply-To: <665.735308.759563@area51.japannet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Mon, 17 Apr 2000 jdarby001@earthlink.net wrote: > Are you interested in refinancing your existing mortgage, Paying > off bills, Consolidating debt, Doing home improvements, or > Purchasing a big ticket item? > > Are you interested in Purchasing a new home or are you a First > time homebuyer? If so, we have ANSWERS for YOU even if you have > poor credit. > > For more information please reply:jdarby002@earthlink.net > > ------------------------------------------------------------ > Under Bill s.1618 TITLE III passed by the 105th U.S. Congress > this letter cannot be considered "spam" as long as we include: 1) > contact information (see above); and, 2) the way to be removed > from future mailings (see below). > > To be removed from this list, please mail to: > jdarby001@earthlink.net with 'remove' in > subject line and you will be removed from our list. > ------------------------------------------------------------ They are apparently using some spamming software that tosses in the ``signature'' at the bottom. Anyway, they are lying about s.1618 and I include the relevant portion (Section 301) below. BTW, I am not sure if this has become law. Regards, Steve S.1618 Anti-slamming Amendments Act (Passed by the Senate) TITLE III--SPAMMING SEC. 301. REQUIREMENTS RELATING TO TRANSMISSIONS OF UNSOLICITED COMMERCIAL ELECTRONIC MAIL. (a) INFORMATION TO BE INCLUDED IN TRANSMISSIONS- (1) IN GENERAL- A person who transmits an unsolicited commercial electronic mail message shall cause to appear in each such electronic mail message the information specified in paragraph (2). (2) COVERED INFORMATION- The following information shall appear at the beginning of the body of an unsolicited commercial electronic mail message under paragraph (1): (A) The name, physical address, electronic mail address, and telephone number of the person who initiates transmission of the message. (B) The name, physical address, electronic mail address, and telephone number of the person who created the content of the message, if different from the information under subparagraph (A). (C) A statement that further transmissions of unsolicited commercial electronic mail to the recipient by the person who initiates transmission of the message may be stopped at no cost to the recipient by sending a reply to the originating electronic mail address with the word `remove' in the subject line. (b) ROUTING INFORMATION- All Internet routing information contained within or accompanying an electronic mail message described in subsection (a) must be accurate, valid according to the prevailing standards for Internet protocols, and accurately reflect message routing. (c) EFFECTIVE DATE- The requirements in this section shall take effect 30 days after the date of enactment of this Act. From rem-conf Tue Apr 18 02:28:12 2000 From rem-conf-request@es.net Tue Apr 18 02:28:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12hU8n-0005x7-00; Tue, 18 Apr 2000 02:17:53 -0700 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 12hU8l-0005wn-00; Tue, 18 Apr 2000 02:17:51 -0700 Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id LAA07759 for ; Tue, 18 Apr 2000 11:17:45 +0200 (MET DST) Received: from era.ericsson.se (rcur34ip54.ericsson.se [147.214.34.54]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id LAA05680 for ; Tue, 18 Apr 2000 11:17:42 +0200 (MET DST) Message-ID: <38FC281F.C872FB9A@era.ericsson.se> Date: Tue, 18 Apr 2000 11:17:20 +0200 From: Magnus Westerlund Organization: Ericsson Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello! I have two questions regarding RTP. The first one concerns the initialization of the variable avg_rtcp_size. draft-ietf-avt-rtp-new-07 section 6.3.2 says: Upon joining the session, the participant initializes tp to 0, tc to 0, senders to 0, pmembers to 1, members to 1, we_sent to false, rtcp_bw to the specified fraction of the session bandwidth, initial to true, and --> avg_rtcp_size to the size of the very first packet constructed by the application. <-- Is it not more reasonable to initialize avg_rtcp_size to a size that it is probable that the first RTCP packet will have? I think the current text is to unspecified and hard to interpret. The second question is about section 6.3.5 Timing Out an SSRC. Is there a reason why the time out interval is set to M*Td and not to the M latest RTCP transmission interval? You could save the need of a last active timer for each member and instead use a much smaller status variable counting how many periods since last active. Is there no problem with premature timing out of users when you have many users leaving a session, especially if they do not send BYE message? Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericssson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se From rem-conf Tue Apr 18 10:36:06 2000 From rem-conf-request@es.net Tue Apr 18 10:36:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12hbpV-0002X9-00; Tue, 18 Apr 2000 10:30:29 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12hbpU-0002Wz-00; Tue, 18 Apr 2000 10:30:28 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id KAA24557; Tue, 18 Apr 2000 10:29:50 -0700 Message-Id: <3.0.3.32.20000418103000.0090a5f0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 18 Apr 2000 10:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/19 Multicast Debugging -- Mark Handley, AT&T Center for Internet Research at ICSI (ACIRI) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Multicast Debugging Wednesday April 19, 2000 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Mark Handley AT&T Center for Internet Research at ICSI (ACIRI) Network topologies can be complex, and the application and control traffic can create a 'chemistry' of loads and flows that leads to unanticipated network congestion and application failure. This session will provide network engineers valuable information on debugging congestion, misconfiguration, application failure to help keep networks and content delivery reliable. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Apr 20 03:25:50 2000 From rem-conf-request@es.net Thu Apr 20 03:25:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iDox-0006y1-00; Thu, 20 Apr 2000 03:04:27 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12iDov-0006xr-00; Thu, 20 Apr 2000 03:04:25 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id FAA22113; Thu, 20 Apr 2000 05:58:20 -0400 (EDT) Message-ID: <38FED5D7.4F182ABF@sknetworks.com> Date: Thu, 20 Apr 2000 03:03:03 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: casner@cisco.com CC: rem-conf@es.net Subject: RTP payload types in draft-ietf-avt-profile-new-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Steve et al, Have you considered assigning more RTP payload types to options of G.723 and G.729 with and without VAD support? G.723.1 5.3k vs. 6.3k ? As it is, vendors must choose to support all or no options of these codecs to ensure interoperability. Cisco's current SIP implementation, which appears mostly compliant with the IETF draft, leaves room for interoperability issues with other vendors because it can support subsets of these codec types. (I summarized the details below) -Scott Keagy ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= ################################################################## IOS version: 12.1(1)T (c3640-p7-mz_121-1_T.bin) Feature: SIP/2.0 user agent Problem Description: Cisco's interpretation of RTP payload types may not be consistent with other vendors, which may impact SIP interoperability. For example, "draft-ietf-avt-profile-new-08.txt" (Jan 14, 2000) indicates RTP PT=4 corresponds with G.723.1, including the 5.3kbps, 6.3kbps, and Annex A VAD options. Cisco may indicate a media capability of G.723.1 to other vendors, when it really only means G.723.1 @ 6.3kbps without Annex A. Other vendors may justifiably assume that the Cisco router supports all options of G.723.1, and send RTP packets with G.723.1 @5.3kbps and Annex A VAD. This scenario would fail if the router is not configured for all of the options of G.723.1. Cisco is over- advertising media capabilities. But there is no method for Cisco to only advertise certain options of these codecs- it's either all or nothing. The RTP payload types should accomodate this. A similar problem exists with the G.729 payload type for RTP. !!The following IOS configuration for codecs........ voice class codec 1 codec preference 1 g711alaw codec preference 2 g711ulaw codec preference 3 g723ar53 codec preference 4 g723ar63 codec preference 5 g723r53 codec preference 6 g723r63 codec preference 7 g726r16 codec preference 8 g726r24 codec preference 9 g726r32 codec preference 10 g728 codec preference 11 g729br8 codec preference 12 g729r8 !!Results in this capabilities advertisement (from a SIP INVITE).... m=audio 20864 RTP/AVP 8 0 65535 65535 65535 4 2 65535 65535 15 65535 18 !!Note the 65535 for codecs that Cisco does not deem to be included as standard RTP PTs. From rem-conf Thu Apr 20 07:12:09 2000 From rem-conf-request@es.net Thu Apr 20 07:12:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iHaT-0001m1-00; Thu, 20 Apr 2000 07:05:45 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12iHaR-0001lr-00; Thu, 20 Apr 2000 07:05:43 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA11634; Thu, 20 Apr 2000 10:05:30 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <38FF0EAA.EF2249C@cs.columbia.edu> Date: Thu, 20 Apr 2000 10:05:30 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Scott Keagy CC: casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt References: <38FED5D7.4F182ABF@sknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I agree that having separate names for the different rates would be a good idea. Note, however, that RTP no longer assigns fixed numerical payload type values to codecs but relies on SDP or similar protocols to map names to numbers. Thus, Cisco's implementation seems to take a short-cut (to put it politely) in that regard, but Steve might be in a position to educate his colleagues.... Scott Keagy wrote: > > Steve et al, > > Have you considered assigning more RTP payload types to options of G.723 > and G.729 with and without VAD support? G.723.1 5.3k vs. 6.3k ? As it > is, vendors must choose to support all or no options of these codecs to > ensure interoperability. Cisco's current SIP implementation, which > appears mostly compliant with the IETF draft, leaves room for > interoperability issues with other vendors because it can support > subsets of these codec types. > > (I summarized the details below) > > -Scott Keagy > > ======================================================= > Scott Keagy, CCIE #3985 > Senior Networking Consultant > SK Networks, Inc. mailto:scott@sknetworks.com > ======================================================= > > ################################################################## > IOS version: 12.1(1)T (c3640-p7-mz_121-1_T.bin) > Feature: SIP/2.0 user agent > > Problem Description: > > Cisco's interpretation of RTP payload types may not be consistent with > other vendors, which may impact SIP interoperability. > > For example, "draft-ietf-avt-profile-new-08.txt" (Jan 14, 2000) > indicates RTP PT=4 corresponds with G.723.1, including the 5.3kbps, > 6.3kbps, and Annex A VAD options. > > Cisco may indicate a media capability of G.723.1 to other vendors, when > it really only means G.723.1 @ 6.3kbps without Annex A. Other vendors > may justifiably assume that the Cisco router supports all options of > G.723.1, and send RTP packets with G.723.1 @5.3kbps and Annex A VAD. > This scenario would fail if the router is not configured for all of the > options of G.723.1. Cisco is over- advertising media capabilities. But > there is no method for Cisco to only advertise certain options of these > codecs- it's either all or nothing. The RTP payload types should > accomodate this. > > A similar problem exists with the G.729 payload type for RTP. > > !!The following IOS configuration for codecs........ > > voice class codec 1 > codec preference 1 g711alaw > codec preference 2 g711ulaw > codec preference 3 g723ar53 > codec preference 4 g723ar63 > codec preference 5 g723r53 > codec preference 6 g723r63 > codec preference 7 g726r16 > codec preference 8 g726r24 > codec preference 9 g726r32 > codec preference 10 g728 > codec preference 11 g729br8 > codec preference 12 g729r8 > > !!Results in this capabilities advertisement (from a SIP INVITE).... > > m=audio 20864 RTP/AVP 8 0 65535 65535 65535 4 2 65535 65535 15 65535 18 > > !!Note the 65535 for codecs that Cisco does not deem to be included as > standard RTP PTs. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Apr 20 08:01:52 2000 From rem-conf-request@es.net Thu Apr 20 08:01:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iIR2-0002pr-00; Thu, 20 Apr 2000 08:00:04 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12iIR1-0002pK-00; Thu, 20 Apr 2000 08:00:03 -0700 Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Thu, 20 Apr 2000 15:57:37 +0100 Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id QAA06476; Thu, 20 Apr 2000 16:00:51 +0100 Message-Id: <200004201500.QAA06476@csperkins.demon.co.uk> To: Henning Schulzrinne cc: Scott Keagy , casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt In-Reply-To: Message from Henning Schulzrinne of "Thu, 20 Apr 2000 10:05:30 EDT." <38FF0EAA.EF2249C@cs.columbia.edu> Date: Thu, 20 Apr 2000 16:00:51 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The codecs in question have static payload type assignments in the revised a/v profile. It may be worth specifying SDP parameters, such that these codecs - with the revised parameters - can be mapped to a dynamic payload type. Colin --> Henning Schulzrinne writes: >I agree that having separate names for the different rates would be a >good idea. Note, however, that RTP no longer assigns fixed numerical >payload type values to codecs but relies on SDP or similar protocols to >map names to numbers. Thus, Cisco's implementation seems to take a >short-cut (to put it politely) in that regard, but Steve might be in a >position to educate his colleagues.... > >Scott Keagy wrote: >> >> Steve et al, >> >> Have you considered assigning more RTP payload types to options of G.723 >> and G.729 with and without VAD support? G.723.1 5.3k vs. 6.3k ? As it >> is, vendors must choose to support all or no options of these codecs to >> ensure interoperability. Cisco's current SIP implementation, which >> appears mostly compliant with the IETF draft, leaves room for >> interoperability issues with other vendors because it can support >> subsets of these codec types. >> >> (I summarized the details below) >> >> -Scott Keagy >> >> ======================================================= >> Scott Keagy, CCIE #3985 >> Senior Networking Consultant >> SK Networks, Inc. mailto:scott@sknetworks.com >> ======================================================= >> >> ################################################################## >> IOS version: 12.1(1)T (c3640-p7-mz_121-1_T.bin) >> Feature: SIP/2.0 user agent >> >> Problem Description: >> >> Cisco's interpretation of RTP payload types may not be consistent with >> other vendors, which may impact SIP interoperability. >> >> For example, "draft-ietf-avt-profile-new-08.txt" (Jan 14, 2000) >> indicates RTP PT=4 corresponds with G.723.1, including the 5.3kbps, >> 6.3kbps, and Annex A VAD options. >> >> Cisco may indicate a media capability of G.723.1 to other vendors, when >> it really only means G.723.1 @ 6.3kbps without Annex A. Other vendors >> may justifiably assume that the Cisco router supports all options of >> G.723.1, and send RTP packets with G.723.1 @5.3kbps and Annex A VAD. >> This scenario would fail if the router is not configured for all of the >> options of G.723.1. Cisco is over- advertising media capabilities. But >> there is no method for Cisco to only advertise certain options of these >> codecs- it's either all or nothing. The RTP payload types should >> accomodate this. >> >> A similar problem exists with the G.729 payload type for RTP. >> >> !!The following IOS configuration for codecs........ >> >> voice class codec 1 >> codec preference 1 g711alaw >> codec preference 2 g711ulaw >> codec preference 3 g723ar53 >> codec preference 4 g723ar63 >> codec preference 5 g723r53 >> codec preference 6 g723r63 >> codec preference 7 g726r16 >> codec preference 8 g726r24 >> codec preference 9 g726r32 >> codec preference 10 g728 >> codec preference 11 g729br8 >> codec preference 12 g729r8 >> >> !!Results in this capabilities advertisement (from a SIP INVITE).... >> >> m=audio 20864 RTP/AVP 8 0 65535 65535 65535 4 2 65535 65535 15 65535 18 >> >> !!Note the 65535 for codecs that Cisco does not deem to be included as >> standard RTP PTs. > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Apr 20 09:40:40 2000 From rem-conf-request@es.net Thu Apr 20 09:40:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iJy0-0004LW-00; Thu, 20 Apr 2000 09:38:12 -0700 Received: from iris.ctd.comsat.com [134.133.40.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 12iJxz-0004LM-00; Thu, 20 Apr 2000 09:38:11 -0700 Received: from campos by iris.ctd.comsat.com with local (Exim 2.12 #8) id 12iJwX-00070s-00; Thu, 20 Apr 2000 12:36:41 -0400 From: Simao Campos To: Colin Perkins Cc: Henning Schulzrinne , Scott Keagy , casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt In-Reply-To: <200004201500.QAA06476@csperkins.demon.co.uk> References: <38FF0EAA.EF2249C@cs.columbia.edu> <200004201500.QAA06476@csperkins.demon.co.uk> 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: multipart/mixed; boundary="Multipart_Thu_Apr_20_12:36:41_2000-1" Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 20 Apr 2000 12:36:41 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --Multipart_Thu_Apr_20_12:36:41_2000-1 Content-Type: text/plain; charset=US-ASCII Dear all, Please note that for G.723.1, the same payload type is used for both bitrates and for the silence removal (SID) mode, since the bitrate is indicated in the first two bits of the bitstream. To avoid further confusion, you might consider amending draft-ietf-avt-profile-new-??.{txt,ps} to include a diagram showing the bit packaging for the G.723.1 modes. Please find attached such a description, in ASCII format. I hope you find it useful. Cheers, Simao. --Multipart_Thu_Apr_20_12:36:41_2000-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="pack-g723.1.txt" Content-Transfer-Encoding: base64 --Multipart_Thu_Apr_20_12:36:41_2000-1-- From rem-conf Thu Apr 20 10:53:52 2000 From rem-conf-request@es.net Thu Apr 20 10:53:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iL4D-0005dr-00; Thu, 20 Apr 2000 10:48:41 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12iL4C-0005dh-00; Thu, 20 Apr 2000 10:48:40 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id NAA12558; Thu, 20 Apr 2000 13:42:30 -0400 (EDT) Message-ID: <38FF429E.F87E3DC3@sknetworks.com> Date: Thu, 20 Apr 2000 10:47:10 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Simao Campos CC: Colin Perkins , Henning Schulzrinne , casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt References: <38FF0EAA.EF2249C@cs.columbia.edu> <200004201500.QAA06476@csperkins.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Simao, I agree that it is possible for a receiver to determine which version of G.723.1 it is receiving, but the RTP payload type leaves ambiguity for *advertising* which versions of G.723.1 a machine supports. As an example, I indicated that Cisco routers do not necessarily support all options of G.723.1 (or all options may not be configured), but they will advertise in a SIP INVITE that they support G.723.1. The receiver of such an invite will assume by the IETF draft that all options are supported, which leads to confusion during the media establishment: 1) Cisco router's SIP INVITE: "I understand G.723.1" 2) Other vendor's 200 OK: "Great, G.723.1 it is" 3) (session established, other router sends G.723.1 @5.3k w/ Annex A) 4) Cisco router complains: "Wait, actually I meant G.7236.3k w/o Annex A) It would be better to avoid the ambiguity up front than to deal with this as an error condition after the media is already established. -Scott Simao Campos wrote: > Dear all, > > Please note that for G.723.1, the same payload type is used for both > bitrates and for the silence removal (SID) mode, since the bitrate is > indicated in the first two bits of the bitstream. > > To avoid further confusion, you might consider amending > draft-ietf-avt-profile-new-??.{txt,ps} to include a diagram showing > the bit packaging for the G.723.1 modes. Please find attached such a > description, in ASCII format. I hope you find it useful. > > Cheers, > Simao. > > ------------------------------------------------------------------------ > Name: pack-g723.1.txt > pack-g723.1.txt Type: Plain Text (text/plain) > Encoding: base64 -- ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= From rem-conf Thu Apr 20 11:07:09 2000 From rem-conf-request@es.net Thu Apr 20 11:07:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iLL2-0006OX-00; Thu, 20 Apr 2000 11:06:04 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12iLL0-0006OH-00; Thu, 20 Apr 2000 11:06:02 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id OAA16266; Thu, 20 Apr 2000 14:00:10 -0400 (EDT) Message-ID: <38FF46C2.B3AE223F@sknetworks.com> Date: Thu, 20 Apr 2000 11:04:50 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt References: <38FED5D7.4F182ABF@sknetworks.com> <38FF0EAA.EF2249C@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 So should an SDP advertisement for all G.723.1 options look like this? m=audio 20864 RTP/AVP 4 4 4 4 a=rtpmap 4 G723/5.3 a=rtpmap 4 G723/6.3 a=rtpmap 4 G723/5.3/A a=rtpmap 4 G723/6.3/A Henning Schulzrinne wrote: > I agree that having separate names for the different rates would be a > good idea. Note, however, that RTP no longer assigns fixed numerical > payload type values to codecs but relies on SDP or similar protocols to > map names to numbers. Thus, Cisco's implementation seems to take a > short-cut (to put it politely) in that regard, but Steve might be in a > position to educate his colleagues.... > > Scott Keagy wrote: > > > > Steve et al, > > > > Have you considered assigning more RTP payload types to options of G.723 > > and G.729 with and without VAD support? G.723.1 5.3k vs. 6.3k ? As it > > is, vendors must choose to support all or no options of these codecs to > > ensure interoperability. Cisco's current SIP implementation, which > > appears mostly compliant with the IETF draft, leaves room for > > interoperability issues with other vendors because it can support > > subsets of these codec types. > > > > (I summarized the details below) > > > > -Scott Keagy > > > > ======================================================= > > Scott Keagy, CCIE #3985 > > Senior Networking Consultant > > SK Networks, Inc. mailto:scott@sknetworks.com > > ======================================================= > > > > ################################################################## > > IOS version: 12.1(1)T (c3640-p7-mz_121-1_T.bin) > > Feature: SIP/2.0 user agent > > > > Problem Description: > > > > Cisco's interpretation of RTP payload types may not be consistent with > > other vendors, which may impact SIP interoperability. > > > > For example, "draft-ietf-avt-profile-new-08.txt" (Jan 14, 2000) > > indicates RTP PT=4 corresponds with G.723.1, including the 5.3kbps, > > 6.3kbps, and Annex A VAD options. > > > > Cisco may indicate a media capability of G.723.1 to other vendors, when > > it really only means G.723.1 @ 6.3kbps without Annex A. Other vendors > > may justifiably assume that the Cisco router supports all options of > > G.723.1, and send RTP packets with G.723.1 @5.3kbps and Annex A VAD. > > This scenario would fail if the router is not configured for all of the > > options of G.723.1. Cisco is over- advertising media capabilities. But > > there is no method for Cisco to only advertise certain options of these > > codecs- it's either all or nothing. The RTP payload types should > > accomodate this. > > > > A similar problem exists with the G.729 payload type for RTP. > > > > !!The following IOS configuration for codecs........ > > > > voice class codec 1 > > codec preference 1 g711alaw > > codec preference 2 g711ulaw > > codec preference 3 g723ar53 > > codec preference 4 g723ar63 > > codec preference 5 g723r53 > > codec preference 6 g723r63 > > codec preference 7 g726r16 > > codec preference 8 g726r24 > > codec preference 9 g726r32 > > codec preference 10 g728 > > codec preference 11 g729br8 > > codec preference 12 g729r8 > > > > !!Results in this capabilities advertisement (from a SIP INVITE).... > > > > m=audio 20864 RTP/AVP 8 0 65535 65535 65535 4 2 65535 65535 15 65535 18 > > > > !!Note the 65535 for codecs that Cisco does not deem to be included as > > standard RTP PTs. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= From rem-conf Thu Apr 20 13:56:50 2000 From rem-conf-request@es.net Thu Apr 20 13:56:48 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 12iNuv-0007k8-00; Thu, 20 Apr 2000 13:51:17 -0700 Received: from igate.nuera.com ([204.216.240.98] helo=sd_exchange.nuera.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 12iNuu-0007iX-00; Thu, 20 Apr 2000 13:51:16 -0700 Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id <2HSJFZH9>; Thu, 20 Apr 2000 13:49:43 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F2E3E@sd_exchange.nuera.com> From: "Fox, Mike" To: Henning Schulzrinne , Colin Perkins Cc: rem-conf@es.net Subject: Question regarding SDP and MIME codec registration... Date: Thu, 20 Apr 2000 13:49:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Nuera has a voice codec which encodes 64K PCM into one of 3 data rates, 7.47, 8.0, and 9.6 Kbps. We would like to register it with IANA in the Audio/Vendor tree as vnd.nuera.ecelp. Our intention is that the data rates are explicitly indicated as required parameters. So the MIME registration description will have the following: Required parameters : one of 7470, 8000, or 9600. And that the SDP RFC convention of: a=rtpmap: /[/] would be met with the following SDP. a=rtpmap:100 vnd.nuera.ecelp/7470. Would this correct? Suggestions welcome. Best regards, Mike Fox Nuera Communications. From rem-conf Thu Apr 20 14:32:24 2000 From rem-conf-request@es.net Thu Apr 20 14:32:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iOXW-0001uf-00; Thu, 20 Apr 2000 14:31:10 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12iOXV-0001uV-00; Thu, 20 Apr 2000 14:31:09 -0700 Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Thu, 20 Apr 2000 22:28:40 +0100 Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id WAA13758; Thu, 20 Apr 2000 22:21:30 +0100 Message-Id: <200004202121.WAA13758@csperkins.demon.co.uk> To: Scott Keagy cc: Henning Schulzrinne , casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt In-Reply-To: Message from Scott Keagy of "Thu, 20 Apr 2000 11:04:50 PDT." <38FF46C2.B3AE223F@sknetworks.com> Date: Thu, 20 Apr 2000 22:21:30 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Scott Keagy writes: >So should an SDP advertisement for all G.723.1 options look like this? > > m=audio 20864 RTP/AVP 4 4 4 4 > a=rtpmap 4 G723/5.3 > a=rtpmap 4 G723/6.3 > a=rtpmap 4 G723/5.3/A > a=rtpmap 4 G723/6.3/A If it's acceptable to have implementations which only support some varients, then a scheme like this makes sense (although the chosen payload type number should be different for each). Colin From rem-conf Thu Apr 20 14:49:40 2000 From rem-conf-request@es.net Thu Apr 20 14:49:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iOoZ-0002dU-00; Thu, 20 Apr 2000 14:48:47 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12iOoY-0002dA-00; Thu, 20 Apr 2000 14:48:46 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Apr 2000 22:46:22 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: rem-conf@es.net cc: Scott Keagy Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt In-reply-to: Your message of "Thu, 20 Apr 2000 03:03:03 PDT." <38FED5D7.4F182ABF@sknetworks.com> Date: Thu, 20 Apr 2000 22:46:14 +0100 Message-ID: <20736.956267174@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There is no need to specify support for 5.3 and 6.3 kbit/s on the grounds of capability in advertisements. The summary on page 3 of ITU Recommendation G.723.1 (03/96) states: "Both rates are a mandatory part of the encoder and decoder. It is possible to switch between the two rates at any frame boundary". Applications that do not support both modes should simply not advertise G.723.1. There is a policy issue regarding bandwidth usage or acceptable audio quality. A clarification of preferred formats would be useful; the default (first) encoding type in SDP probably suffices with the 5.3/6.3 mode explicitly advertised. Support for G.723.1 Annex A is optional, but the consequences of mis-advertisement are minor when the contents of the annex are considered. Annex A describes a voice activity detection (VAD) algorithm and a comfort noise generation (CNG) algorithm. VAD can be removed from consideration as there is no information transmitted from the sender to receiver about what type of VAD algorith is employed. The VAD algorithm is specified because there are useful measures in the encoding stages for judging whether a period is silence or not. When CNG is active an additional frame type, 4 bytes small, is sent to describe the sound of silence at the end of talkspurts and as the power spectrum of the silence changes above a threshold. If the sender supports CNG and the receiver does not, the receiver will discard these frames when it inspects frame type present in the first octet of each frame (which it has to do because a G.723.1 encoder is permitted to change between 5.3 and 6.3 kbit/s at any frame boundary). A receiver might not support CNG, but know that a CNG frame is 4 bytes and therefore be able to fragment compound CNG+audio packets. In terms of cost CNG data computation is neglible relative to the encoding process and the amount of wasted bandwith is small under normal circumstances. G.729 is different because the frame type is not included within each frame and several distinct frame types exist between the original recommendation and it's annexes (audio at 6.4, 8, and 11.8 kbit/s, and CNG). Distinct payload identifiers must be advertised and negotiated for each of the available encodings as receivers cannot decode the data otherwise. - Orion. Orion Hodson =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Research Student Networked Multimedia Research Group Tel: ++(0)20 7679 3704 Department of Computer Science Fax: ++(0)20 7387 1397 University College London, Gower Street, London, WC1E 6BT, UK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- <38FED5D7.4F182ABF@sknetworks.com>Scott Keagy writes: > Steve et al, > > Have you considered assigning more RTP payload types to options of G.723 > and G.729 with and without VAD support? G.723.1 5.3k vs. 6.3k ? As it > is, vendors must choose to support all or no options of these codecs to > ensure interoperability. Cisco's current SIP implementation, which > appears mostly compliant with the IETF draft, leaves room for > interoperability issues with other vendors because it can support > subsets of these codec types. > > (I summarized the details below) > > -Scott Keagy > > ======================================================= > Scott Keagy, CCIE #3985 > Senior Networking Consultant > SK Networks, Inc. mailto:scott@sknetworks.com > ======================================================= > > > ################################################################## > IOS version: 12.1(1)T (c3640-p7-mz_121-1_T.bin) > Feature: SIP/2.0 user agent > > Problem Description: > > Cisco's interpretation of RTP payload types may not be consistent with > other vendors, which may impact SIP interoperability. > > For example, "draft-ietf-avt-profile-new-08.txt" (Jan 14, 2000) > indicates RTP PT=4 corresponds with G.723.1, including the 5.3kbps, > 6.3kbps, and Annex A VAD options. > > Cisco may indicate a media capability of G.723.1 to other vendors, when > it really only means G.723.1 @ 6.3kbps without Annex A. Other vendors > may justifiably assume that the Cisco router supports all options of > G.723.1, and send RTP packets with G.723.1 @5.3kbps and Annex A VAD. > This scenario would fail if the router is not configured for all of the > options of G.723.1. Cisco is over- advertising media capabilities. But > there is no method for Cisco to only advertise certain options of these > codecs- it's either all or nothing. The RTP payload types should > accomodate this. > > A similar problem exists with the G.729 payload type for RTP. > > > !!The following IOS configuration for codecs........ > > voice class codec 1 > codec preference 1 g711alaw > codec preference 2 g711ulaw > codec preference 3 g723ar53 > codec preference 4 g723ar63 > codec preference 5 g723r53 > codec preference 6 g723r63 > codec preference 7 g726r16 > codec preference 8 g726r24 > codec preference 9 g726r32 > codec preference 10 g728 > codec preference 11 g729br8 > codec preference 12 g729r8 > > !!Results in this capabilities advertisement (from a SIP INVITE).... > > m=audio 20864 RTP/AVP 8 0 65535 65535 65535 4 2 65535 65535 15 65535 18 > > !!Note the 65535 for codecs that Cisco does not deem to be included as > standard RTP PTs. > > From rem-conf Thu Apr 20 15:07:18 2000 From rem-conf-request@es.net Thu Apr 20 15:07:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iP4x-0003U4-00; Thu, 20 Apr 2000 15:05:43 -0700 Received: from babbage.csee.usf.edu [131.247.3.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12iP4w-0003Tu-00; Thu, 20 Apr 2000 15:05:42 -0700 Received: from kjc (kjc [131.247.3.42]) by babbage.csee.usf.edu (8.9.3/8.9.3) with ESMTP id SAA02477; Thu, 20 Apr 2000 18:02:26 -0400 (EDT) Message-Id: <4.2.0.58.20000420180548.00c0a740@babbage.csee.usf.edu> X-Sender: christen@babbage.csee.usf.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 20 Apr 2000 18:07:06 -0400 To: xtp-relay@cs.concordia.ca From: Ken Christensen Subject: Call for Paper - Local Computer Networks (LCN) 2000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS LCN 2000 The 25th Annual IEEE Conference on Local Computer Networks November 8 - 10, 2000 Embassy Suites USF, Tampa, Florida http://www.ieeelcn.org Sponsored by the IEEE Computer Society with support from GTE Data Services, Paradyne Corporation, and the University of South Florida College of Engineering. Important dates: ---------------- Paper submission: May 19, 2000 Notification of acceptance: July 14, 2000 Camera-ready copy due: August 18, 2000 General Information: -------------------- The IEEE LCN conference is the premier conference on leading edge and practical computer networking. The emphasis of this conference is on practical solutions to important problems in computer networking. During the 25 years of this conference, we have moved from problems in the local network to problems in the global Internet and World Wide Web. Our unique approach stimulates a workshop environment and enables an effective interchange among researchers, users, and product developers. We encourage you to submit original papers describing research results or practical solutions. Paper topics include, but are not limited to: - Local Area Networks - Home Networks - Wireless Networks - Storage Area Networks - Optical Networks - Realtime Networks - Active Networks - ATM - Gigabit Ethernet - LAN/WAN Internetworking - DSL Technologies - Network Management - Network Security - Network Reliability - Multicasting - Enabling QoS in High-Speed Networks - Always On / Always Connected - Internet / Intranet - Anything-over-IP - IP-over-Anything - Performance Evaluation - Protocol Design and Validation Authors are invited to submit full or short papers for presentation at the conference. Full papers should present novel perspectives on computer networking within the general scope of the conference topics listed above and may be up to 10 camera-ready pages in length. Short papers are an opportunity to present preliminary or interim results and are limited to 2 camera-ready pages in length. All papers will be reviewed by a minimum of three reviewers. A best paper award will be presented. Several student travel scholarships will be available courtesy of the LCN corporate supporters. All submitted papers must include title, complete contact information for all authors, abstract, and keywords on the cover page. The correspondence author must be clearly identified. Paper Submission Instructions: ------------------------------ Email one postscript version of your manuscript to the program chair at christen@csee.usf.edu. Alternatively, send five hard copies via postal mail to: Dr. Kenneth J. Christensen Department of Computer Science and Engineering 4202 East Fowler Avenue, ENB 118 University of South Florida Tampa, FL 33620 Tutorials: ---------- LCN 2000 will begin with one full day of tutorials. Individuals interested in giving a tutorial should contact the Tutorials Chair (Garry Kessler at kessler@symquest.com). LCN 2000 Committee: ------------------- General Chair: F. Huebner, AT&T (fhuebner@att.com) Program Chairs: K. Christensen, USF (christen@csee.usf.edu) P. Martini, Univ. of Bonn (martini@informatik.uni-bonn.de) IEEE Liaison: J. Bumblis, Seagate (Joseph_R_Bumblis@notes.seagate.com) Finance Chair: K. Prasad, UMass-Lowell (Kanti_Prasad@uml.edu) Tutorials Chair: G. Kessler, SymQuest (kessler@symquest.com) Panels Chairs: J. W. Atwood, Concordia (bill@cs.concordia.ca) T. Strayer, BBN (strayer@bbn.com) Arrangements Chairs: K. Christensen, USF (christen@csee.usf.edu) R. Sankar, USF (sankar@csee.usf.edu) Webmaster: G. Kessler, SymQuest (kessler@symquest.com) Overseas Advisors: S. Jha, UNSW, (Australia) (sjha@cse.unsw.edu.au) P. Martini, Univ of Bonn, (Europe) (martini@informatik.uni-bonn.de) Standing Committee: M. McKee, Bowling Green E. Nolley, Strategic Growth H. Salwen, OpenRoute --- From rem-conf Thu Apr 20 15:17:25 2000 From rem-conf-request@es.net Thu Apr 20 15:17:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iPFa-0004Gn-00; Thu, 20 Apr 2000 15:16:42 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12iPFY-0004Gd-00; Thu, 20 Apr 2000 15:16:41 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id SAA13894; Thu, 20 Apr 2000 18:10:42 -0400 (EDT) Message-ID: <38FF817A.439D9E68@sknetworks.com> Date: Thu, 20 Apr 2000 15:15:22 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: Henning Schulzrinne , casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt References: <200004202121.WAA13758@csperkins.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Two questions: 1) Does SDP allow any RTP payload type to be dynamically defined, or only those in the "dynamic" range 96-127 ? 2) If SDP can re-redefine the payload types, then isn't this an inefficient way of using SDP & RTP for standard codecs ? The RTP payload field is not adding value in this scheme, and extra lines are required in the SDP description. (yeah SDP bandwidth is neglible compared to media, but it's the thought that counts). (Also, point noted by Orion re: G.723 & G.729; these questions of RTP payload and SDP usage are still relevant in the case of G.729). -Scott Colin Perkins wrote: > --> Scott Keagy writes: > >So should an SDP advertisement for all G.723.1 options look like this? > > > > m=audio 20864 RTP/AVP 4 4 4 4 > > a=rtpmap 4 G723/5.3 > > a=rtpmap 4 G723/6.3 > > a=rtpmap 4 G723/5.3/A > > a=rtpmap 4 G723/6.3/A > > If it's acceptable to have implementations which only support some > varients, then a scheme like this makes sense (although the chosen > payload type number should be different for each). > > Colin From rem-conf Fri Apr 21 07:38:39 2000 From rem-conf-request@es.net Fri Apr 21 07:38:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ieS3-0005su-00; Fri, 21 Apr 2000 07:30:35 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12ieS1-0005sk-00; Fri, 21 Apr 2000 07:30:33 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA02900; Fri, 21 Apr 2000 10:30:23 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <390065FF.468820F4@cs.columbia.edu> Date: Fri, 21 Apr 2000 10:30:23 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fox, Mike" CC: Colin Perkins , rem-conf@es.net Subject: Re: Question regarding SDP and MIME codec registration... References: <613A6A6A3F09D3118F5C00508B2C24FE7F2E3E@sd_exchange.nuera.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Fox, Mike" wrote: > > Nuera has a voice codec which encodes 64K PCM into one of 3 data > rates, 7.47, 8.0, and 9.6 Kbps. We would like to register it with IANA in > the Audio/Vendor tree as vnd.nuera.ecelp. Our intention is that the data > rates are explicitly indicated as required parameters. So the MIME > registration description will have the following: > > Required parameters : one of 7470, 8000, or 9600. > > And that the SDP RFC convention of: > > a=rtpmap: /[/ parameters>] > > would be met with the following SDP. > > a=rtpmap:100 vnd.nuera.ecelp/7470. > > Would this correct? > Suggestions welcome. Sounds about right. Would be useful to include some amount of detail in the IANA registration (e.g., whether the format itself is described somewhere - I suspect not...) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Fri Apr 21 07:58:01 2000 From rem-conf-request@es.net Fri Apr 21 07:58:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ierM-0006h9-00; Fri, 21 Apr 2000 07:56:44 -0700 Received: from iris.ctd.comsat.com [134.133.40.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 12ierK-0006gn-00; Fri, 21 Apr 2000 07:56:43 -0700 Received: from campos by iris.ctd.comsat.com with local (Exim 2.12 #8) id 12ieqH-0000g5-00; Fri, 21 Apr 2000 10:55:37 -0400 From: Simao Campos To: Henning Schulzrinne Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt In-Reply-To: <390069DF.807B4C56@cs.columbia.edu> References: <38FF0EAA.EF2249C@cs.columbia.edu> <200004201500.QAA06476@csperkins.demon.co.uk> <390069DF.807B4C56@cs.columbia.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid cc: rem-conf@es.net, simao@ctd.comsat.com 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: Fri, 21 Apr 2000 10:55:37 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning, I have attached now as plain text. Also re-sending to rem-conf, in case someone also missed it. Regards, Simao. ------------------ > From: Henning Schulzrinne > Sender: hgs@cs.columbia.edu > To: Simao Campos > Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt > Date: Fri, 21 Apr 2000 10:46:55 -0400 > > Your email attachment was empty. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > PACKETIZATION FOR G.723.1 AT 6.3 KBIT/S 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * | LPC |ACL0 | | | | | |0 0|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2|0 1 2 3 4 5| | | 0 1 2 3 4 5 6 7 8 9 0 1 2 3| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 4 5 6 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |ACL| ACL2 |ACL| GAIN0 | GAIN1 | | | 1 | | 3 | | | |6|0 1|0 1 2 3 4 5 6|0 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7| | | | | | 0 1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 7 8 9 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | GAIN2 | GAIN3 | GRID | | | | | | |8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3| | 0 1| 0 1| 0 1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 1 9 0 1 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*| MSBPOS |POS0 |POS| |*| | | 1 | |0|0 1 2 3 4 5 6 7 8 9 1 1 1|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1|0 1| | | 0 1 2| 0 1 2 3 4 5| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 1 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |POS1 |POS2 |POS3 | | | | | |2 3 4 5 6 7 8 9 1 1 1 1|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1|0 1 2 3| | 0 1 2 3| 0 1 2 3 4 5| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 1 1 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |PSIG0 |PSIG1 |PSIG2 |PSIG3 | | | | | | | |4 5 6 7 8 9 1 1 1 1|0 1 2 3 4 5|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4| | 0 1 2 3| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTES: (*) Bits 0 and 1 are always "0 0" for the G.723.1 operation at 6.3 kbit/s. (**) Bit 96 is set to '0' PACKETIZATION FOR G.723.1 AT 5.3 KBIT/S 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * | LPC |ACL0 | | | | | |1 0|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2|0 1 2 3 4 5| | | 0 1 2 3 4 5 6 7 8 9 0 1 2 3| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 4 5 6 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |ACL| ACL2 |ACL| GAIN0 | GAIN1 | | | 1 | | 3 | | | |6|0 1|0 1 2 3 4 5 6|0 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7| | | | | | 0 1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 7 8 9 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | GAIN2 | GAIN3 | GRID | | | | | | |8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3| | 0 1| 0 1| 0 1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 1 9 0 1 2 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |POS0 |POS1 |POS2 | | | | | |0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7| | 0 1| 0 1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 1 1 2 3 4 5 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |POS2 |POS3 |PSIG0 |PSIG1 |PSIG2 |PSIG3 | | | | | | | | |8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3| | 0 1|2 0 1| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTE: (*) Bits 0 and 1 are always "1 0" respectively for the G.723.1 operation at 5.3 kbit/s. PACKETIZATION FOR G.723.1 SID FRAMES 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * | LPC |GAIN | | | | | |0 1|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2|0 1 2 3 4 5| | | 0 1 2 3 4 5 6 7 8 9 0 1 2 3| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From rem-conf Fri Apr 21 08:50:43 2000 From rem-conf-request@es.net Fri Apr 21 08:50:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12iffV-0000FA-00; Fri, 21 Apr 2000 08:48:33 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12iffT-0000Eh-00; Fri, 21 Apr 2000 08:48:31 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA06989; Fri, 21 Apr 2000 11:48:27 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3900784B.ACB282ED@cs.columbia.edu> Date: Fri, 21 Apr 2000 11:48:27 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fox, Mike" , Colin Perkins , rem-conf@es.net Subject: Re: Question regarding SDP and MIME codec registration... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I should have read Mike's message more carefully - what I said is wrong, as are the other examples given for SDP selection of codecs provided earlier by others. Note that the SDP parameter is the *clock* rate, not the bit rate. This parameter is included to allow receivers that do not understand the details of the encoding to deal with RTP/RTCP information measured in clock samples. (For example, an RTP recorder doesn't need to understand the media encoding, but needs to know what the clock rate is so that it can play back the recorded data without the network jitter.) For all G.723 and G.729 varieties, the clock (sampling) rate is 8000 Hz. Thus, different versions of the codec need to be labeled and cannot be distinguished by the clock rate parameter. Thus, the rtpmap format would be something like a=rtpmap:100 vnd.nuera.ecelp7470/8000 Using the third parameter (as in vnd.nuera.ecelp/8000/7470) for the bit rate is probably not a good idea since this parameter is reserved for the number of audio channels. RFC 2327 also says explicitly "Codec-specific parameters should be added in other attributes." I would also argue that using the third parameter for the bit rate complicates implementations, as they now have to look in three places to create a table entry. Encoding it as part of the name seems easier, particularly given that the number of rates seems to be small. Hope this clarifies things. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Fri Apr 21 09:13:42 2000 From rem-conf-request@es.net Fri Apr 21 09:13:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ig36-000127-00; Fri, 21 Apr 2000 09:12:56 -0700 Received: from adsl-63-196-11-252.dsl.snfc21.pacbell.net (hazard.aciri.org) [63.196.11.252] by mail1.es.net with esmtp (Exim 1.81 #2) id 12ig34-00011x-00; Fri, 21 Apr 2000 09:12:54 -0700 Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id JAA13377; Fri, 21 Apr 2000 09:12:36 -0700 (PDT) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Henning Schulzrinne cc: "Fox, Mike" , Colin Perkins , rem-conf@es.net Subject: Re: Question regarding SDP and MIME codec registration... In-reply-to: Your message of "Fri, 21 Apr 2000 11:48:27 EDT." <3900784B.ACB282ED@cs.columbia.edu> Date: Fri, 21 Apr 2000 09:12:36 -0700 Message-ID: <13375.956333556@hazard.aciri.org> Sender: mjh@aciri.org X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >For all G.723 and G.729 varieties, the clock (sampling) rate is 8000 Hz. >Thus, different versions of the codec need to be labeled and cannot be >distinguished by the clock rate parameter. Thus, the rtpmap format would >be something like > >a=rtpmap:100 vnd.nuera.ecelp7470/8000 > >Using the third parameter (as in vnd.nuera.ecelp/8000/7470) for the bit >rate is probably not a good idea since this parameter is reserved for >the number of audio channels. RFC 2327 also says explicitly >"Codec-specific parameters should be added in other attributes." Note that there is also a b= field in SDP specifically for specifying bandwidths. Cheers, Mark From rem-conf Fri Apr 21 10:16:16 2000 From rem-conf-request@es.net Fri Apr 21 10:16:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12igzN-0002Cw-00; Fri, 21 Apr 2000 10:13:09 -0700 Received: from sdn-ar-001ohcincp308.dialsprint.net (opera) [168.191.25.46] by mail1.es.net with smtp (Exim 1.81 #2) id 12igzJ-0002Cc-00; Fri, 21 Apr 2000 10:13:06 -0700 From: opera4@earthlink.net To: Subject: Best New Trade Show Display by Opera Portables, Inc. adv Date: Fri, 21 Apr 2000 13:08:56 -0400 X-Sender: opera4@earthlink.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that as much eye-popping as they are eye catching. Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision. If you use displays, you really owe it to yourself to check out our stuff! go to http://www.semblance7.net Opera Portables, Inc. All removes honored at http://www.semblance7.net/removes.htm From rem-conf Sun Apr 23 11:02:58 2000 From rem-conf-request@es.net Sun Apr 23 11:02:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jQX6-0003qY-00; Sun, 23 Apr 2000 10:51:00 -0700 Received: from (rhed.co.cr) [206.153.32.50] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12jQX2-0003qO-00; Sun, 23 Apr 2000 10:50:57 -0700 Received: from area51.japannet.com (slip-32-100-250-231.ny.us.prserv.net [32.100.250.231]) by rhed.co.cr (8.8.7/8.8.7) with SMTP id LAA20649; Sun, 23 Apr 2000 11:25:59 -0600 From: rotbart@banet.net Subject: We Have Answers for Your Business Date: Sun, 23 Apr 2000 10:10:14 Message-Id: <14.134488.559830@area51.japannet.com> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We can list your website in all major Search Engines and achieve Top 30 positions. GUARANTEED! If people cannot find your business in the first 10 to 30 matches of a search, then submitting was a waste of time. The best advertising dollars you can spend on the Web are in achieving search engine rankings. There are several reasons: 1. Nearly everyone (95% of Internet users) begins their Web travels at a major search engine. 2. Anyone finding your site on a search engine is someone who was specifically looking for your company, product or service. That makes them much more likely to buy something than if they'd clicked on a banner ad out of idle curiosity. 3. Third party studies have proven that search engines provide better results than most other forms of Web advertising. We key on the following major search engines: Yahoo-AltaVista-WebCrawler-Lycos-Excite-iwon-Looksmart- AskJeeves-AOL Search-Netscape-HotBot-MSN-Infoseek-Snap- Google-Northern Light-Open Directory-Findwhat-Magellan-Goto And 600 more. Our goal is to list your website in all major search engines and achieve Top 30 positions. GUARANTEED! We are not one of those companies offering submission service to 1550 search engines without any guarantee. That is a waste of money and time for you. For more information please email to: sendmeinfo@earthlink.net with the subject: Send me more information Or call: Nick Velez 1-718-583-3134 Monday-Friday >From 10:00 AM to 6:00 PM Eastern Time ------------------------------------------------------------ Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter cannot be considered "spam" as long as we include: 1) contact information (see above); and, 2) the way to be removed >from future mailings (see below). To be removed from this list, please mail to: rotbart@banet.net with 'remove' in subject line and you will be removed from our list. ------------------------------------------------------------ From rem-conf Sun Apr 23 14:45:50 2000 From rem-conf-request@es.net Sun Apr 23 14:45:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jU9X-0006Nq-00; Sun, 23 Apr 2000 14:42:55 -0700 Received: from (redball.dynamicsoft.com) [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 12jU9V-0006Ng-00; Sun, 23 Apr 2000 14:42:53 -0700 Received: from dynamicsoft.com (1Cust81.tnt1.freehold.nj.da.uu.net [63.17.113.81]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA08393; Sun, 23 Apr 2000 17:43:35 -0400 (EDT) Message-ID: <3903708A.5884E240@dynamicsoft.com> Date: Sun, 23 Apr 2000 17:52:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Keagy CC: Colin Perkins , Henning Schulzrinne , casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt References: <200004202121.WAA13758@csperkins.demon.co.uk> <38FF817A.439D9E68@sknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scott Keagy wrote: > > Two questions: > > 1) Does SDP allow any RTP payload type to be dynamically defined, > or only those in the "dynamic" range 96-127 ? This is not an SDP issue so much as an RTP issue. The new rfc1890 says: > This profile reserves payload type numbers in the range 96-127 > exclusively for dynamic assignment. Applications SHOULD first use > values in this range for dynamic payload types. Those applications > which need to define more than 32 dynamic payload types MAY bind > codes below 96, in which case it is RECOMMENDED that unassigned > payload type numbers be used first. However, the statically assigned > payload types are default bindings and MAY be dynamically bound to > new encodings if needed. Redefining payload types below 96 may cause > incorrect operation if an attempt is made to join a session without > obtaining session description information that defines the dynamic > payload types. so, you are allowed to do this, although mostly as a last resort. > > 2) If SDP can re-redefine the payload types, then isn't this an inefficient > > way of using SDP & RTP for standard codecs ? The RTP payload field is > not > adding value in this scheme, and extra lines are required in the SDP > description. > (yeah SDP bandwidth is neglible compared to media, but it's the thought > that counts). Huh? Of course you still need to have this. The payload type is needed in the RTP to allow for the type to vary on the fly during the session. This is essential for useful application of comfort noise codecs and of the avt-tones mechanisms, both of which cause an on the fly change. You still need the number in SDP so the other side knows what codec is associated with which RTP payload type number. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Mon Apr 24 08:57:23 2000 From rem-conf-request@es.net Mon Apr 24 08:57:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jl6o-0000qk-00; Mon, 24 Apr 2000 08:49:14 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12jl6n-0000qa-00; Mon, 24 Apr 2000 08:49:13 -0700 Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Mon, 24 Apr 2000 16:44:55 +0100 Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id QAA23980; Mon, 24 Apr 2000 16:41:06 +0100 Message-Id: <200004241541.QAA23980@csperkins.demon.co.uk> To: Henning Schulzrinne cc: Mark Handley , rem-conf@es.net Subject: Re: Question regarding SDP and MIME codec registration... In-Reply-To: Message from Henning Schulzrinne of "Fri, 21 Apr 2000 13:23:00 EDT." <39008E74.27ECC4B6@cs.columbia.edu> Date: Mon, 24 Apr 2000 16:41:06 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [...rem-conf added back to the cc list...] --> Henning Schulzrinne writes: >Mark Handley wrote: >> This wasn't obvious to me from the previous messages in this thread. >> I agree that b= isn't useful for negotiation. Yet another case where >> SDP falls short because it doesn't have a grouping mechanism for >> parameters of formats. > >Yes, we are definitely reaching the limits of the protocol. > >> >> There seem to be several alternatives >> >> a=rtpmap:100 vnd.nuera.ecelp7470/8000 >> >> a=rtpmap:100 vnd.nuera.ecelp;bps=7470/8000 >> >> a=rtpmap:100 vnd.nuera.ecelp/8000 >> a=fmtp:100 bps=7470 >> >> The first overloads the MIME subtype. The second overloads the format >> name, by encoding a MIME parameter in it when used with SDP (SDP won't >> care - it's just a token) but the MIME registration is clean. The >> last doesn't overload anything, but may not satisfy them that it's a >> required parameter. > >None of them are great, I agree. Among the bunch, the second one is >probably the least bad, in my view. (2327 doesn't say anything about >what's legal in an 'encoding name', so that anything except a / would >work. It's not really a token, in the strict sense, since tokens can't >contain semicolons.) The MIME registration for the standard codecs in the a/v profile (draft-ietf-avt-rtp-mime-02.txt) uses the third option, with a statement that some parameters are required. Colin >I don't think the third one would work as it now requires that the >negotiation code goes fishing elsewhere. You'd end up with something >like > >a=rtpmap:100 vnd.nuera.ecelp/8000 >a=rtpmap:101 vnd.nuera.ecelp/8000 >a=rtpmap:102 vnd.nuera.ecelp/8000 > >a=fmtp:100 bps=7470 >a=fmtp:101 bps=8000 >a=fmtp:102 bps=9600 > >which is likely to be very confusing. > > > > > >> >> None of these really seem all that satisfactory, but I can't think of >> any other good alternatives. >> >> Cheers, >> Mark > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Apr 24 13:31:18 2000 From rem-conf-request@es.net Mon Apr 24 13:31:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jpP8-0004Ta-00; Mon, 24 Apr 2000 13:24:26 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12jpP6-0004TQ-00; Mon, 24 Apr 2000 13:24:24 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id QAA07515; Mon, 24 Apr 2000 16:18:17 -0400 (EDT) Message-ID: <3904AD18.42DBB33D@sknetworks.com> Date: Mon, 24 Apr 2000 13:22:48 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Colin Perkins , Henning Schulzrinne , casner@cisco.com, rem-conf@es.net Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt References: <200004202121.WAA13758@csperkins.demon.co.uk> <38FF817A.439D9E68@sknetworks.com> <3903708A.5884E240@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks for the clarification- I overlooked tones & comfort noise. The only issues I have left are vendor-specific :^) -Scott Jonathan Rosenberg wrote: > Scott Keagy wrote: > > > > Two questions: > > > > 1) Does SDP allow any RTP payload type to be dynamically defined, > > or only those in the "dynamic" range 96-127 ? > > This is not an SDP issue so much as an RTP issue. The new rfc1890 says: > > > This profile reserves payload type numbers in the range 96-127 > > exclusively for dynamic assignment. Applications SHOULD first use > > values in this range for dynamic payload types. Those applications > > which need to define more than 32 dynamic payload types MAY bind > > codes below 96, in which case it is RECOMMENDED that unassigned > > payload type numbers be used first. However, the statically assigned > > payload types are default bindings and MAY be dynamically bound to > > new encodings if needed. Redefining payload types below 96 may cause > > incorrect operation if an attempt is made to join a session without > > obtaining session description information that defines the dynamic > > payload types. > > so, you are allowed to do this, although mostly as a last resort. > > > > > 2) If SDP can re-redefine the payload types, then isn't this an inefficient > > > > way of using SDP & RTP for standard codecs ? The RTP payload field is > > not > > adding value in this scheme, and extra lines are required in the SDP > > description. > > (yeah SDP bandwidth is neglible compared to media, but it's the thought > > that counts). > > Huh? Of course you still need to have this. The payload type is needed > in the RTP to allow for the type to vary on the fly during the session. > This is essential for useful application of comfort noise codecs and of > the avt-tones mechanisms, both of which cause an on the fly change. You > still need the number in SDP so the other side knows what codec is > associated with which RTP payload type number. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= From rem-conf Mon Apr 24 13:31:18 2000 From rem-conf-request@es.net Mon Apr 24 13:31:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jpUQ-0004X4-00; Mon, 24 Apr 2000 13:29:54 -0700 Received: from (mailout2.hananet.net) [210.220.163.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 12jpUO-0004We-00; Mon, 24 Apr 2000 13:29:52 -0700 Received: from thrunet.thrunet.com ([211.44.129.33]) by mailout2.hananet.net (Netscape Messaging Server 4.15) with SMTP id FTJFH900.X4O for ; Tue, 25 Apr 2000 05:27:09 +0900 From: �� To: rem-conf@es.net Cc: Subject: ��,�Ͼ� ��Ȱȸȭ �� mailing service �ȳ�!! Date: Tue, 25 Apr 00 05:25:35 Ÿ�̺�� ǥ�ؽ� MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AD_2000_PART_BOUNDARY_19990606 Message-ID: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --AD_2000_PART_BOUNDARY_19990606 Content-Type: text/plain Content-Transfer-Encoding: 7Bit �� ޾ƺ�� ,�Ͼ� ��Ȱȸȭ ��. �� Ӣ� 2000.04.25(ȭ) �즡 �� 2 ȸ �߼�(ȭ,��) �߼�. "Dad, I don't want to go to school today." said the boy. "Why not, son?" "Well, one of the chickens on the school farm died last week and we had chicken soup for lunch the next day. And three days ago one of the pigs died and we had roast pork the next day,,,." "But why don't you want to go today?" "Because the English teacher died yesterday!" "....." "�ƺ�, �� б� �� Ⱦ�." �ϰ� �ҳ�� ߴ�. "�� ?" "��ֿ� �б� ��忡�� ׾��µ� �� Ծ��. �׸�� 3�� ׾��µ� �� Ұ��⸦ �Ծ��,,,." "�׷�� б�� Ⱦ�?" "�� ư��̴� ��!" "....." �� Ѹ�� (2000.04.25(ȭ)) ��I felt on top of the world �즡�� (��-��) �߼�. �� ϸ� �� 翬��. ��, � �� κ�� [�� ! �� ְ��]�� մϴ�. �̿� �� Ÿ�� ǥ�� 'on top of the world'��ϴ�. on top of the world�� ϸ� [�� ⿡]�� ǹ��̸� I felt on top of the world. �� (�� ⿡ �ִ� ��̾��.) ��, (�� Ҵ�)�� մϴ�. �� (�� Ҿ�)�� ǹ̷� I felt good. �� ϱ� ��쳪 �� ǥ�� ˰� �� ǥ�� ſ��. �� on top of the world�� ⿡ �ִ� ��. �׷��ٸ� out of this world ��? �� ϰ�� ʰ� wonderful[�ٻ��], fantastic[ȯ��]�̶� ��̿��. A: I heard you were engaged to Marian. B: Actually, I was. A: Oh, really? So, how did you feel on the night of your engagement? B: I felt like I was on top of the world. A: �޸��Ȱ� ��ȥ�Ѵٰ� ��µ�. B: �� ̹� �߾�. A: ��, ��̾�? �׷�,��ȥ�� ׳� �㿡 �� ��? B: �� ̾��. �� Ѹ�� Ͼ�(2000.04.25(ȭ))�즡�� 3 ȸ �߼�(��,��,��) �߼�. �Ͼ� �� ·� �� Ǿ� �ֽ��ϴ�. ----------------------------------------------------------------------- ======================================================================= �ȳ��ϼ��? �� ȭ�� ̿��ؼ� �� 1:1�� ܱ�� н�� ִ� �� Online korea �Ŷ�� մϴ�. �� ˼��մϴ�. �ε� �ʱ׷�� 뼭��...... �� ȸ�翡�� Ȱ ȸȭ�� ִ� ��Ƽ�� п�� (��-��), �� Ȱ�� ʿ�� Ȱȸȭ �� 徿�� 帮�� ־��. �� Ʒ�� ǿ�� ޾ƺ�� Ͻô� �� olk@olk.co.kr �� "yes"�� mail�� ֽø� �ȴ�ϴ�. �׸��, �� ȭ �ܱ�� ǰ� �ñ��Ͻ� �е�� ½ù��Ǣµ� �� ǽ��ϰ� �� û�� ּ��. �� ù�� û �� www.d-day.co.kr �� Ͻ� �� "��ǼҰ�"�� Ŭ��ϽŴ�� "��ǽ�û"�� ø� �ù��Ǹ� ��û�Ͻ� �� ־��. ��ȭ 02-588-0510 ��ε� ��û�� ִ�ϴ�. �ƹ��ɷ� �� н�� ȸȭ �Ƿ� �� Ǿ�� մϴ�. ��մϴ�. ��ʿ�� ٸ� �� ˼��մϴ�. --AD_2000_PART_BOUNDARY_19990606-- From rem-conf Mon Apr 24 13:58:24 2000 From rem-conf-request@es.net Mon Apr 24 13:58:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jprM-00061g-00; Mon, 24 Apr 2000 13:53:36 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12jprK-00061V-00; Mon, 24 Apr 2000 13:53:35 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA02154 for ; Mon, 24 Apr 2000 16:53:33 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3904B44D.3567AE9A@cs.columbia.edu> Date: Mon, 24 Apr 2000 16:53:33 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: G.723.1 & G.729 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I don't have much hope, but just in case: Is there source or Unix (any flavor) object code for either G.723.1 or G.729 **other than the slow-as-molasses ITU code** for internal research use? (I'm aware of the patent issues.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Apr 24 14:07:20 2000 From rem-conf-request@es.net Mon Apr 24 14:07:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jq4K-0006uX-00; Mon, 24 Apr 2000 14:07:00 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12jq4J-0006uN-00; Mon, 24 Apr 2000 14:06:59 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA03257; Mon, 24 Apr 2000 17:06:55 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3904B76F.650146F6@cs.columbia.edu> Date: Mon, 24 Apr 2000 17:06:55 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: Mark Handley , rem-conf@es.net Subject: Re: Question regarding SDP and MIME codec registration... References: <200004241541.QAA23980@csperkins.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > >> a=rtpmap:100 vnd.nuera.ecelp/8000 > >> a=fmtp:100 bps=7470 > >> > >> The first overloads the MIME subtype. The second overloads the format > >> name, by encoding a MIME parameter in it when used with SDP (SDP won't > >> care - it's just a token) but the MIME registration is clean. The > >> last doesn't overload anything, but may not satisfy them that it's a > >> required parameter. > > > >None of them are great, I agree. Among the bunch, the second one is > >probably the least bad, in my view. (2327 doesn't say anything about > >what's legal in an 'encoding name', so that anything except a / would > >work. It's not really a token, in the strict sense, since tokens can't > >contain semicolons.) > > The MIME registration for the standard codecs in the a/v profile > (draft-ietf-avt-rtp-mime-02.txt) uses the third option, with a > statement that some parameters are required. > Hmm. I still think this is a really bad idea. draft-ietf-avt-rtp-mime-02.txt doesn't really mention parameters that are necessary to do media type and capability negotiation. None of the registrations included describe this case that a single MIME type describes two different encodings (L16 does, but the parameter, the clock rate, is part of the rtpmap parameter). I think this should be fixed before it's too late. This should only affect a few encodings. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Apr 24 20:59:48 2000 From rem-conf-request@es.net Mon Apr 24 20:59:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jwOt-0003t9-00; Mon, 24 Apr 2000 20:52:39 -0700 Received: from prognet.com [205.219.198.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 12jwOs-0003sz-00; Mon, 24 Apr 2000 20:52:38 -0700 Received: from jeffa_laptop ([172.23.100.152]) by prognet.com (8.9.2/8.9.0) with ESMTP id UAA29616; Mon, 24 Apr 2000 20:52:52 -0700 (PDT) Message-Id: <4.2.0.58.20000424203610.044ccdc0@mail.real.com> X-Sender: jeffa@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 24 Apr 2000 20:51:56 -0700 To: Henning Schulzrinne , Colin Perkins From: Jeff Ayars Subject: Re: Question regarding SDP and MIME codec registration... Cc: Mark Handley , rem-conf@es.net In-Reply-To: <3904B76F.650146F6@cs.columbia.edu> References: <200004241541.QAA23980@csperkins.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 05:06 PM 4/24/00 -0400, Henning Schulzrinne wrote: >Colin Perkins wrote: > > > > > >> a=rtpmap:100 vnd.nuera.ecelp/8000 > > >> a=fmtp:100 bps=7470 > > >> > > > > The MIME registration for the standard codecs in the a/v profile > > (draft-ietf-avt-rtp-mime-02.txt) uses the third option, with a > > statement that some parameters are required. > > > >Hmm. I still think this is a really bad idea. >draft-ietf-avt-rtp-mime-02.txt doesn't really mention parameters that >are necessary to do media type and capability negotiation. None of the >registrations included describe this case that a single MIME type >describes two different encodings (L16 does, but the parameter, the >clock rate, is part of the rtpmap parameter). I think this should be >fixed before it's too late. This should only affect a few encodings. > Using fmtp is how I would have expected it to be done. I think using the rtpmap part is a interop nightmare. What about RFC 2361? If I want to send Microsoft G.723 from a .wav file to a player that played audio using ACM codecs I think m= audio 0 RTP/AVP 101 a=rtpmap: 101 vnd.wav/22050/1 a=fmtp: 101 codec=42 is the right way to do it. JEff From rem-conf Mon Apr 24 21:23:20 2000 From rem-conf-request@es.net Mon Apr 24 21:23:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12jwrr-0004nm-00; Mon, 24 Apr 2000 21:22:35 -0700 Received: from (mail.valuepost.net) [203.197.38.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12jwrp-0004na-00; Mon, 24 Apr 2000 21:22:33 -0700 Received: from localhost ([192.168.2.18]) by mail.valuepost.net (8.9.3/8.9.3) with ESMTP id JAA22248; Tue, 25 Apr 2000 09:40:20 +0530 Message-Id: <200004250410.JAA22248@mail.valuepost.net> From: "healingcare" To: "uk-email12" Date: Tue, 25 Apr 2000 09:44:52 +0550 Subject: ARTHRITIS - NOW DRUGS FREE CURE!!! Reply-To: healing_id@yahoo.co.UK MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__8154813_35092.06" X-Priority: 3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a Multipart MIME message. ------=_NextPart_000_001__8154813_35092.06 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.valuepost.net id JAA22248 NOW PAIN RELIEF AND GREATER MOBILITY CAN BE REALITY=20 If you are suffering from arthritis or any other acute or chronic pain re= lated condition, you have just taken the first step towards a better qual= ity of life. OUR PROMISE TO YOU!! We guarantee that if you use ACE as specified in our instruction manual y= ou will have pain relief and increased mobility in just a few weeks, or i= n some cases days. ACE's patented formula of currents and frequencies, ta= ke the body out of protection mode and into healing mode, giving prolonge= d pain relief and increased mobility.=20 UNIQUE If you've tried everything else you must try ACE which is now being recom= mended by doctors and hospitals world-wide - it is an approved medical de= vice. The original price of this valuable instrument is is =A3245, but as= a special case you can get this for =A3199 including tax and delivery.=20 To know more about Acehealing Machine and to place order just type the following address:=20 http://members.rediff.com/carehealth/ace.htm We are health related site and have new and unique products.=20 - Thank you. ------=_NextPart_000_001__8154813_35092.06 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1MYW5ndWFnZSIg Y29udGVudD0iZW4tdXMiPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIj4NCjxtZXRhIG5hbWU9IkdF TkVSQVRPUiIgY29udGVudD0iTWljcm9zb2Z0IEZyb250UGFnZSA0LjAiPg0KPG1ldGEgbmFt ZT0iUHJvZ0lkIiBjb250ZW50PSJGcm9udFBhZ2UuRWRpdG9yLkRvY3VtZW50Ij4NCjx0aXRs ZT5OT1cgUEFJTiBSRUxJRUYgQU5EIEdSRUFURVIgTU9CSUxJVFkgQ0FOIEJFIFJFQUxJVFkm bmJzcDsgSWYgeW91IGFyZQ0Kc3VmZmVyaW5nIGZyb20gYXJ0aHJpdGlzIG9yIGFueSBvdGhl ciBhY3V0ZSBvciBjaHJvbmljIHBhaW4gcmVsYXRlZDwvdGl0bGU+DQo8L2hlYWQ+DQoNCjxi b2R5Pg0KDQo8ZGl2IGFsaWduPSJjZW50ZXIiPg0KICA8Y2VudGVyPg0KICA8dGFibGUgYm9y ZGVyPSIwIj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjkwJSIgdmFsaWduPSJ0b3Ai IGFsaWduPSJjZW50ZXIiIGJvcmRlcmNvbG9ybGlnaHQ9IiNGRkZGRkYiIGJvcmRlcmNvbG9y ZGFyaz0iIzAwMDAwMCI+DQogICAgICAgIDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJ2 ZXJkYW5hLGFyaWFsLGhlbHZldGljYSIgc2l6ZT0iMyIgY29sb3I9IiM4MDAwMDAiPjxiPk5P VyBQQUlOIFJFTElFRiBBTkQgR1JFQVRFUiBNT0JJTElUWSBDQU4gQkUgUkVBTElUWTwvYj48 L2ZvbnQ+DQogICAgICAgIDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJ2ZXJkYW5hLGFy aWFsLGhlbHZldGljYSIgc2l6ZT0iMiI+SWYgeW91IGFyZSBzdWZmZXJpbmcgZnJvbSBhcnRo cml0aXMgb3IgYW55IG90aGVyIGFjdXRlIG9yIGNocm9uaWMgcGFpbiByZWxhdGVkIGNvbmRp dGlvbiwgeW91IGhhdmUganVzdCB0YWtlbiB0aGUgZmlyc3Qgc3RlcCB0b3dhcmRzIGEgYmV0 dGVyIHF1YWxpdHkgb2YgbGlmZS48YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0K ICAgICAgICA8Yj5PVVIgUFJPTUlTRSBUTyBZT1UhITwvYj48YnI+DQogICAgICAgIDxicj4N CiAgICAgICAgV2UgZ3VhcmFudGVlIHRoYXQgaWYgeW91IHVzZSBBQ0UgYXMgc3BlY2lmaWVk IGluIG91ciBpbnN0cnVjdGlvbiBtYW51YWwgeW91IHdpbGwgaGF2ZSBwYWluIHJlbGllZiBh bmQgaW5jcmVhc2VkIG1vYmlsaXR5IGluIGp1c3QgYSBmZXcgd2Vla3MsIG9yIGluDQogICAg ICAgIHNvbWUgY2FzZXMgZGF5cy4gQUNFJ3MgcGF0ZW50ZWQgZm9ybXVsYSBvZiBjdXJyZW50 cyBhbmQgZnJlcXVlbmNpZXMsIHRha2UgdGhlIGJvZHkgb3V0IG9mIHByb3RlY3Rpb24gbW9k ZSBhbmQgaW50bw0KICAgICAgICBoZWFsaW5nIG1vZGUsIGdpdmluZyBwcm9sb25nZWQgcGFp biByZWxpZWYgYW5kIGluY3JlYXNlZCBtb2JpbGl0eS48L2ZvbnQ+DQogICAgICAgIDxwIGFs aWduPSJsZWZ0Ij48Yj48Zm9udCBjb2xvcj0iIzgwMDAwMCIgZmFjZT0idmVyZGFuYSxhcmlh bCxoZWx2ZXRpY2EiIHNpemU9IjIiPlVOSVFVRTwvZm9udD48L2I+PGZvbnQgZmFjZT0idmVy ZGFuYSxhcmlhbCxoZWx2ZXRpY2EiIHNpemU9IjIiPjxicj4NCiAgICAgICAgPGJyPg0KICAg ICAgICBJZiB5b3UndmUgdHJpZWQgZXZlcnl0aGluZyBlbHNlIHlvdSBtdXN0IHRyeSBBQ0Ug d2hpY2ggaXMgbm93IGJlaW5nIHJlY29tbWVuZGVkIGJ5DQogICAgICAgIGRvY3RvcnMgYW5k IGhvc3BpdGFscyB3b3JsZC13aWRlIC0gaXQgaXMgYW4gYXBwcm92ZWQgbWVkaWNhbCBkZXZp Y2UuIFRoZQ0KICAgICAgICBvcmlnaW5hbCBwcmljZSBvZiB0aGlzIHZhbHVhYmxlIGluc3Ry dW1lbnQgaXMgaXMgozI0NSwgYnV0IGFzIGEgc3BlY2lhbA0KICAgICAgICBjYXNlIHlvdSBj YW4gZ2V0IHRoaXMgZm9yIKMxOTkgaW5jbHVkaW5nIHRheCBhbmQgZGVsaXZlcnkuJm5ic3A7 PGJyPg0KICAgICAgICA8YnI+DQogICAgICAgIFRvIGtub3cgbW9yZSBhYm91dCBBY2VoZWFs aW5nIE1hY2hpbmUgYW5kIHRvIHBsYWNlIG9yZGVyPGJyPg0KICAgICAgICA8Yj48YSBocmVm PSJodHRwOi8vbWVtYmVycy5yZWRpZmYuY29tL2NhcmVoZWFsdGgvYWNlLmh0bSI+SnVzdA0K ICAgICAgICBjbGljayBIZXJlPC9hPjwvYj48YnI+DQogICAgICAgIDxicj4NCiAgICAgICAg b3IganVzdCB0eXBlIHRoZSBmb2xsb3dpbmcgYWRkcmVzczo8L2ZvbnQ+DQogICAgICAgIDxw IGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJ2ZXJkYW5hLGFyaWFsLGhlbHZldGljYSIgY29s b3I9IiM4MDAwMDAiIHNpemU9IjIiPmh0dHA6Ly9tZW1iZXJzLnJlZGlmZi5jb20vY2FyZWhl YWx0aC9hY2UuaHRtPC9mb250Pg0KICAgICAgICA8cCBhbGlnbj0ibGVmdCI+PGZvbnQgc2l6 ZT0iMiI+PGZvbnQgZmFjZT0idmVyZGFuYSxhcmlhbCxoZWx2ZXRpY2EiPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQogICAgICAgIFdlIGFyZSBoZWFsdGggcmVsYXRlZCBzaXRlIGFu ZCBoYXZlIG5ldyBhbmQgdW5pcXVlIHByb2R1Y3RzIC0gaG93ZXZlciwgaWYgeW91DQogICAg ICAgIGRvIG5vdCB3aXNoIHRvIHJlY2VpdmUgYW55IG1vcmUgZS1tYWlscyBmcm9tIHVzIC0g cGxlYXNlPC9mb250PiAgIDx1PjxiPjxmb250IGZhY2U9InZlcmRhbmEsYXJpYWwsaGVsdmV0 aWNhIiBjb2xvcj0iIzAwMDBGRiI+PGEgaHJlZj0ibWFpbHRvOmNhcmVob21lX2lkQHlhaG9v LmNvLnVrIj5jbGljayBoZXJlPC9hPjwvZm9udD48L2I+PC91PjwvZm9udD4NCiAgICAgICAg PHAgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9InZlcmRhbmEsYXJpYWwsaGVsdmV0aWNhIiBz aXplPSIyIj48YnI+DQogICAgICAgIC0gVGhhbmsgeW91LjwvZm9udD48L3RkPg0KICAgIDwv dHI+DQogIDwvdGFibGU+DQogIDwvY2VudGVyPg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9o dG1sPg0K ------=_NextPart_000_001__8154813_35092.06-- From rem-conf Tue Apr 25 06:44:46 2000 From rem-conf-request@es.net Tue Apr 25 06:44:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12k5Zu-0002WD-00; Tue, 25 Apr 2000 06:40:38 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12k5Zs-0002W3-00; Tue, 25 Apr 2000 06:40:36 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA06880; Tue, 25 Apr 2000 09:40:26 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3905A04A.CCF590A7@cs.columbia.edu> Date: Tue, 25 Apr 2000 09:40:26 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Ayars CC: Colin Perkins , Mark Handley , rem-conf@es.net Subject: Re: Question regarding SDP and MIME codec registration... References: <200004241541.QAA23980@csperkins.demon.co.uk> <4.2.0.58.20000424203610.044ccdc0@mail.real.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jeff Ayars wrote: > > At 05:06 PM 4/24/00 -0400, Henning Schulzrinne wrote: > >Colin Perkins wrote: > > > > > > > > >> a=rtpmap:100 vnd.nuera.ecelp/8000 > > > >> a=fmtp:100 bps=7470 > > > >> > > > > > > The MIME registration for the standard codecs in the a/v profile > > > (draft-ietf-avt-rtp-mime-02.txt) uses the third option, with a > > > statement that some parameters are required. > > > > > > >Hmm. I still think this is a really bad idea. > >draft-ietf-avt-rtp-mime-02.txt doesn't really mention parameters that > >are necessary to do media type and capability negotiation. None of the > >registrations included describe this case that a single MIME type > >describes two different encodings (L16 does, but the parameter, the > >clock rate, is part of the rtpmap parameter). I think this should be > >fixed before it's too late. This should only affect a few encodings. > > > > Using fmtp is how I would have expected it to be done. I think using the > rtpmap part is a interop nightmare. What about RFC > 2361? If I want to send Microsoft G.723 from a .wav file to a player that > played audio using ACM codecs I think > > m= audio 0 RTP/AVP 101 > a=rtpmap: 101 vnd.wav/22050/1 > a=fmtp: 101 codec=42 > > is the right way to do it. I disagree. This is an implementation nightmare, since now the negotiation code (which is often not the media agent) has to be aware of all the possible codecs and their parameters that influence interoperability. As long as I have names, I can easily export a table of capabilities from the media agent, without having to grope through assorted fmtp's. If two codecs are different and not distinguishable at the bit-level (such as G.723.1) and are usable independently (unlike G.723.1, where the claim is that the ITU protocol police will pull you over if you support 5.6 kb/s without supporting 6.3 kb/s), they deserve different names, even though they might be lumped together in the same "marketing" name. They have different bit patterns, different software for decoding it - thus, for all technical purposes, they are different (albeit technically related) codecs. If (to cite a recent example) Nuera had chosen to name their codecs Alpha, Beta and Gamma, we wouldn't hesitate a moment to register them under different names, even though they might share some fundamental principles of audio signal compression. Also, I don't think that using Wave codec names is the right solution, as it is heavily OS dependent. Designation of codec 42 is meaningless to those not running ACM. We have codec names, such as G.729, that are standardized and widely recognized, with appropriate payload formats. Note that codec 42 makes no sense since it does not describe the payload format itself, just a file format. In all but trivial cases (like mu-law), these are not likely to be the same. > > JEff -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Apr 25 07:37:37 2000 From rem-conf-request@es.net Tue Apr 25 07:37:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12k6Qx-0003fK-00; Tue, 25 Apr 2000 07:35:27 -0700 Received: from (h1-server.gdfi.com) [212.208.177.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 12k6Qu-0003fA-00; Tue, 25 Apr 2000 07:35:25 -0700 To: rem-conf@es.net From: position.Offers.USA@Freelance.com Subject: Freelance.com Message-ID: Date: Tue, 25 Apr 2000 16:22:06 +0200 X-MIMETrack: Serialize by Router on H1 Server/Sea'nergie(Release 5.0.2c (Intl)|2 February 2000) at 25/04/2000 16:22:06 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 Madam, Sir, We noted your e-mail at the internet address "http://www.cis.ohio-state.edu/htbin/rfc/rfc2032.html" Everyone knows that finding the right projects can be a full time job! That's why Freelance.com is dedicated to Independent Professionals. We = are there to promote your skills and your career. To you, this service is f= ree and requires no exclusivity. Freelance.com is the only global Web-based service that introduces its clients to Independent Professionals by using the world's most accurate= selection and customer-care technology ? real people. To achieve this, = we are creating a sales network of Account Managers in all major cities ac= ross North America. This network will help you to find the most interesting projects in IT consulting, engineering, web media and telecom with Fort= une 1000 and Internet companies. We are dedicated to Independent Profession= als locally, nationally and world-wide.Visit our web site at http://www.freelance.com to find out more about our services. You will find at your disposal: - A list of available projects; - Contact information for the Account Manager nearest you; - Confidential online resume registration forms; - How to send us your resume - Other vital Independent Professional services (accounting, training, insurance,=A0 internet=A0 links, networking...); - Our mailing list registration, to receive a daily e-mail listing of n= ew projects which match your skills. Don't=A0 hesitate=A0 to contact us if you have questions or comments. Do tell other Independent Professionals about us!Wishing you all the be= st with your career as an Independent Professional, Yann Marteil General Manager Americas =A0 ----------------------------------------------------------- FREELANCE.COM=A0=A0 The global source of projects, information and serv= ices for Independent Professionals, Fortune 1000 and Internet companies. Freelance.com 75 Maiden Lane, suite 507 New York, NY 10038 Tel : 212 402 68 68 - Fax : 212 402 68 69 http://www.freelance.com ContactUSA@freelance.com ----------------------------------------------------------- We are fully aware that this document has been mailed without your requ= est. We apologize if you are not concerned by this message. If you don't reply with us you won't receive anything from us again.= From rem-conf Tue Apr 25 09:06:31 2000 From rem-conf-request@es.net Tue Apr 25 09:06:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12k7nO-0005NK-00; Tue, 25 Apr 2000 09:02:42 -0700 Received: from sticky.graham.com [209.219.63.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 12k7nN-0005N9-00; Tue, 25 Apr 2000 09:02:41 -0700 Received: from goldfinch.graham.com (earth.graham.com [209.219.63.56]) by sticky.graham.com (8.8.8/8.8.8/GTS) with ESMTP id JAA11737; Tue, 25 Apr 2000 09:02:29 -0700 (PDT) Message-Id: <4.3.1.0.20000425090551.00a7cf00@yoyodyne.graham.com> X-Sender: ashok@yoyodyne.graham.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 25 Apr 2000 09:07:15 -0700 To: Henning Schulzrinne From: Ashok Yerneni Subject: Information about SAP and SDP protocols... Cc: Jeff Ayars , Colin Perkins , Mark Handley , rem-conf@es.net In-Reply-To: <3905A04A.CCF590A7@cs.columbia.edu> References: <200004241541.QAA23980@csperkins.demon.co.uk> <4.2.0.58.20000424203610.044ccdc0@mail.real.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Where do I get detailed information about these protocols. Is there a public domain library that implements these protocols? thanks, Ashok Ashok Yerneni (408) 366 8001,x501 VP of Engineering (408) 366 8004(fax) Graham Technology Solutions ashok@graham.com 20823 Stevens Creek Blvd, www.graham.com Cupertino, CA 95014-2111. From rem-conf Tue Apr 25 10:04:26 2000 From rem-conf-request@es.net Tue Apr 25 10:04:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12k8iw-0006r6-00; Tue, 25 Apr 2000 10:02:10 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12k8iv-0006qw-00; Tue, 25 Apr 2000 10:02:09 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id KAA19519; Tue, 25 Apr 2000 10:01:49 -0700 Message-Id: <3.0.3.32.20000425100242.00ae2cf0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 25 Apr 2000 10:02:42 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/26 Integrating Timing into XML Documents -- Patrick Schmitz, Microsoft Bay Area Research Center Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Integrating Timing into XML Documents Wednesday April 26, 2000, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Patrick Schmitz Microsoft Bay Area Research Center Growing interest in SMIL underscores the importance of a common language to describe timing and synchronization in documents. SMIL 1 defined syntax and semantics for a basic multimedia language. This was an important first step, but does not allow authors to use the timing semantics with other languages, like HTML and CSS. Authors need to be able to describe timing for wide range of documents, and to combine the semantics of timing and sync with other existing tools and semantics that are in common use, such as CSS. In addition, they need the flexibility to accommodate different editing/authoring scenarios and constraints. We need to provide a common model for timing so that authors are not forced to learn and remember different models for different document types or different authoring scenarios. In addition, where different syntactic approaches are available (e.g. to address different authoring scenarios), it is important to allow authors to combine the different approaches in a straightforward manner. This talk will describe three approaches to the integration of timing and synchronization with XML languages. I will describe the current work in SMIL Boston to support the integration of SMIL with HTML/CSS, as well as other applications and future work. I will also describe a proposed framework for combining the approaches. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Apr 25 10:28:35 2000 From rem-conf-request@es.net Tue Apr 25 10:28:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12k97L-00005o-00; Tue, 25 Apr 2000 10:27:23 -0700 Received: from (redball.dynamicsoft.com) [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 12k97K-00005d-00; Tue, 25 Apr 2000 10:27:22 -0700 Received: from dynamicsoft.com (1Cust29.tnt3.freehold.nj.da.uu.net [63.25.172.29]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA13177; Tue, 25 Apr 2000 13:28:21 -0400 (EDT) Message-ID: <3905D7BE.5D8DF5A7@dynamicsoft.com> Date: Tue, 25 Apr 2000 13:37:02 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ashok Yerneni CC: Henning Schulzrinne , Jeff Ayars , Colin Perkins , Mark Handley , rem-conf@es.net Subject: Re: Information about SAP and SDP protocols... References: <200004241541.QAA23980@csperkins.demon.co.uk> <4.2.0.58.20000424203610.044ccdc0@mail.real.com> <4.3.1.0.20000425090551.00a7cf00@yoyodyne.graham.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SAP: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-06.txt SDP: rfc2327, http://www.ietf.org/rfc/rfc2327.txt -Jonathan R. Ashok Yerneni wrote: > > Where do I get detailed information about these protocols. Is there a > public domain > library that implements these protocols? > > thanks, > > Ashok > Ashok Yerneni (408) 366 8001,x501 > VP of Engineering (408) 366 8004(fax) > Graham Technology Solutions ashok@graham.com > 20823 Stevens Creek Blvd, www.graham.com > Cupertino, CA 95014-2111. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Tue Apr 25 12:23:50 2000 From rem-conf-request@es.net Tue Apr 25 12:23:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kArO-000256-00; Tue, 25 Apr 2000 12:19:02 -0700 Received: from prognet.com [205.219.198.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kArM-00024w-00; Tue, 25 Apr 2000 12:19:00 -0700 Received: from jeffa_laptop ([172.23.100.152]) by prognet.com (8.9.2/8.9.0) with ESMTP id MAA15161; Tue, 25 Apr 2000 12:19:01 -0700 (PDT) Message-Id: <4.2.0.58.20000425114040.03ea4960@mail.real.com> X-Sender: jeffa@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 25 Apr 2000 12:18:23 -0700 To: Henning Schulzrinne From: Jeff Ayars Subject: Re: Question regarding SDP and MIME codec registration... Cc: Colin Perkins , Mark Handley , rem-conf@es.net In-Reply-To: <3905A04A.CCF590A7@cs.columbia.edu> References: <200004241541.QAA23980@csperkins.demon.co.uk> <4.2.0.58.20000424203610.044ccdc0@mail.real.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Comments inline... At 09:40 AM 4/25/00 -0400, Henning Schulzrinne wrote: >Jeff Ayars wrote: > > > > At 05:06 PM 4/24/00 -0400, Henning Schulzrinne wrote: > > >Colin Perkins wrote: > > > > > > > > > > > >> a=rtpmap:100 vnd.nuera.ecelp/8000 > > > > >> a=fmtp:100 bps=7470 > > > > >> > > > > > > > > The MIME registration for the standard codecs in the a/v profile > > > > (draft-ietf-avt-rtp-mime-02.txt) uses the third option, with a > > > > statement that some parameters are required. > > > > > > > > > >Hmm. I still think this is a really bad idea. > > >draft-ietf-avt-rtp-mime-02.txt doesn't really mention parameters that > > >are necessary to do media type and capability negotiation. None of the > > >registrations included describe this case that a single MIME type > > >describes two different encodings (L16 does, but the parameter, the > > >clock rate, is part of the rtpmap parameter). I think this should be > > >fixed before it's too late. This should only affect a few encodings. > > > > > > > Using fmtp is how I would have expected it to be done. I think using the > > rtpmap part is a interop nightmare. What about RFC > > 2361? If I want to send Microsoft G.723 from a .wav file to a player that > > played audio using ACM codecs I think > > > > m= audio 0 RTP/AVP 101 > > a=rtpmap: 101 vnd.wav/22050/1 > > a=fmtp: 101 codec=42 > > > > is the right way to do it. > >I disagree. This is an implementation nightmare, since now the >negotiation code (which is often not the media agent) has to be aware of >all the possible codecs and their parameters that influence >interoperability. As long as I have names, I can easily export a table >of capabilities from the media agent, without having to grope through >assorted fmtp's. So you are saying that it's your wish that a=fmtp in SDP be explicitly excluded from consideration during any format negotiation phase? I can see that makes it easier. >If two codecs are different and not distinguishable at the bit-level >(such as G.723.1) and are usable independently (unlike G.723.1, where >the claim is that the ITU protocol police will pull you over if you >support 5.6 kb/s without supporting 6.3 kb/s), they deserve different >names, even though they might be lumped together in the same "marketing" >name. They have different bit patterns, different software for decoding >it - thus, for all technical purposes, they are different (albeit >technically related) codecs. If (to cite a recent example) Nuera had >chosen to name their codecs Alpha, Beta and Gamma, we wouldn't hesitate >a moment to register them under different names, even though they might >share some fundamental principles of audio signal compression. This is why in draft-ietf-avt-profile-new-08.txt the G.726 bitrates/bitdepths are nudged in the direction of G726-16, G726-24, G726-32, and G726-40? >Also, I don't think that using Wave codec names is the right solution, >as it is heavily OS dependent. Designation of codec 42 is meaningless to >those not running ACM. We have codec names, such as G.729, that are >standardized and widely recognized, with appropriate payload formats. >Note that codec 42 makes no sense since it does not describe the payload >format itself, just a file format. In all but trivial cases (like >mu-law), these are not likely to be the same. I don't know that Wave codec names necessarily implies any OS dependency. Sure the codec name is defined for a particular OS but the codec may exist on multiple platforms - Indio by Intel, Cenepac by Supermac. There is a standard that registers a mime type for these codecs - RFC 2361. It uses parameters to the general mime type to identify the encoding type. Are you suggesting that SDP not support announcing sessions that use codecs defined in RFC 2361? From RFC 2361: "The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications." So RFC 2361 isn't tied to a file format, but to the codec - the data type. Or are you saying that every data type needs an explicit mime type registered for it's RTP payload format so if I wanted to send Cenepac via RTP I would need to register a new mime type, different from video/vnd.avi; codec=CVID, for to send it via RTP and that as above, I should include the codec in the mime name instead of as a parameter? JEff From rem-conf Tue Apr 25 18:43:05 2000 From rem-conf-request@es.net Tue Apr 25 18:43:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kGiy-0006TI-00; Tue, 25 Apr 2000 18:34:44 -0700 Received: from smtp-out2.bellatlantic.net [199.45.39.157] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kGix-0006T8-00; Tue, 25 Apr 2000 18:34:43 -0700 Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id VAA15397; Tue, 25 Apr 2000 21:34:31 -0400 (EDT) Message-ID: <390647D9.713680C4@cs.columbia.edu> Date: Tue, 25 Apr 2000 21:35:21 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Ayars CC: Colin Perkins , Mark Handley , rem-conf@es.net Subject: Re: Question regarding SDP and MIME codec registration... References: <200004241541.QAA23980@csperkins.demon.co.uk> <4.2.0.58.20000424203610.044ccdc0@mail.real.com> <4.2.0.58.20000425114040.03ea4960@mail.real.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > So you are saying that it's your wish that a=fmtp in SDP be explicitly > excluded from consideration during any format negotiation phase? I can see > that makes it easier. Yes, fmtp should be used to *configure* a codec, but not to decide whether it's compatible. In my implementation model, the SIP agent (say) would simply pass down the fmtp content to the media agent, completely oblivious what it means. It simply gathers the advertised receive capabilities = codecs A, B, C, D (from the m and rtpmap lines) and, for example, pops up a GUI panel of the sort after subtracting the codecs that it doesn't know anything about: "The caller can receive audio A, B, C (suitably non-techie descriptions). Which ones do you want to use?" and then configures the media agent. At that point, the GUI part can easily handle codecs that it has never heard about, as long as it is given a simple list of names describing the media agent capabilities. > This is why in draft-ietf-avt-profile-new-08.txt the G.726 > bitrates/bitdepths are nudged in the direction of G726-16, G726-24, > G726-32, and G726-40? Yes, although I have to admit that the recent discussion has emphasized the need for this even more. > > >Also, I don't think that using Wave codec names is the right solution, > >as it is heavily OS dependent. Designation of codec 42 is meaningless to > >those not running ACM. We have codec names, such as G.729, that are > >standardized and widely recognized, with appropriate payload formats. > >Note that codec 42 makes no sense since it does not describe the payload > >format itself, just a file format. In all but trivial cases (like > >mu-law), these are not likely to be the same. > > I don't know that Wave codec names necessarily implies any OS > dependency. Sure the codec name is defined for a particular OS but the > codec may exist on multiple platforms - Indio by Intel, Cenepac by > Supermac. There is a standard that registers a mime type for these codecs > - RFC 2361. It uses parameters to the general mime type to identify the > encoding type. > > Are you suggesting that SDP not support announcing sessions that use codecs > defined in RFC 2361? > > From RFC 2361: > > "The purpose of this paper is to establish a mechanism by which codecs > registered within Microsoft's WAVE and AVI Registries may be referenced > within the IANA Namespace by Internet applications." > > So RFC 2361 isn't tied to a file format, but to the codec - the data type. > > Or are you saying that every data type needs an explicit mime type > registered for it's RTP payload format so if I wanted to send Cenepac via > RTP I would need to register a new mime type, different from video/vnd.avi; > codec=CVID, for to send it via RTP and that as above, I should include the > codec in the mime name instead of as a parameter? Yes, as discussed in the RTP MIME registration document, just having a file format description is not sufficient for RTP transport. We can now do one of two things: - make sure that there's an interoperable RTP packetization for each of the video/vnd.avi codecs (probably a useful exercise) - map these to the 'explicit' RTP codec names where possible to avoid the former. > > JEff From rem-conf Wed Apr 26 04:43:18 2000 From rem-conf-request@es.net Wed Apr 26 04:43:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kQ4W-0004L7-00; Wed, 26 Apr 2000 04:33:36 -0700 Received: from smtp1.libero.it [193.70.192.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kQ4T-0004Kp-00; Wed, 26 Apr 2000 04:33:34 -0700 Received: from host (151.14.101.129) by smtp1.libero.it; 26 Apr 2000 13:31:05 +0200 Message-ID: <000f01bfaf73$a0c61860$fe00000a@host.localhost> From: "Paolo" To: "IETF" Subject: New Proto Date: Wed, 26 Apr 2000 13:36:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BFAF84.62EE6E00" 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_000C_01BFAF84.62EE6E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I'm new to this mailing list. My name is Paolo Possanzini and I'm from Italy. I'm working to a new protocol to see Video On InterNet. I works with = UDP.=20 I need someone to help me to talk about it. I'm interested to your = opinion on my Idea. I'm sorry for my bad english. Bye ------=_NextPart_000_000C_01BFAF84.62EE6E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello, I'm new to this mailing = list.

My name is Paolo Possanzini and I'm = from=20 Italy.

I'm working to a new protocol to see = Video On=20 InterNet. I works with UDP.

I need someone to help me to talk about = it. I'm=20 interested to your opinion on my Idea.

I'm sorry for my bad = english.

Bye

------=_NextPart_000_000C_01BFAF84.62EE6E00-- From rem-conf Wed Apr 26 07:33:36 2000 From rem-conf-request@es.net Wed Apr 26 07:33:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kSoI-0006RB-00; Wed, 26 Apr 2000 07:29:02 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kSoG-0006R1-00; Wed, 26 Apr 2000 07:29:00 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA18901; Wed, 26 Apr 2000 10:28:58 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3906FD2A.306F713E@cs.columbia.edu> Date: Wed, 26 Apr 2000 10:28:58 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Art Yerkes , rem-conf@es.net Subject: Re: G723 References: <3906FA31.B8533A68@genxnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Art Yerkes wrote: > > For G.723, http://www.cwi.nl/ftp/audio/ccitt-adpcm.tar.gz. These > sources come from sun. Not sure if they're any faster, though. Thanks for all the responses. A brief summary: - The ITU floating point code for G.729 is significantly faster than the fixed-point code. Decoding takes about 8% of a SPARC Ultra CPU, encoding about a third. - The term G.723 is the subject of endless confusion. The source cited above is the "old" G.723. The RTP profile explains it thusly: "Note: In 1990, ITU-T Recommendation G.721 was merged with Recommendation G.723 into ITU-T Recommendation G.726. Thus, G726-32 designates the same algorithm as G721 in RFC 1890." Most people (myself included) seem to use the term G.723 now for what's more precisely called G.723.1, the 5.3/6.3 kb/s codec. Thanks again. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 26 07:39:37 2000 From rem-conf-request@es.net Wed Apr 26 07:39:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kSw9-0006lm-00; Wed, 26 Apr 2000 07:37:09 -0700 Received: from wodc7-1.corprelay.mail.uu.net [192.48.96.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kSw9-0006la-00; Wed, 26 Apr 2000 07:37:09 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQimpe26429; Wed, 26 Apr 2000 14:37:08 GMT Received: by neserve0.corp.us.uu.net id QQimpe04856; Wed, 26 Apr 2000 10:37:02 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: audio coverage of space shuttle mission STS-101 To: mbone@isi.edu Date: Wed, 26 Apr 2000 10:36:57 -0400 (EDT) CC: rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Out of curiosity, is anybody interested in mp3 streams of shuttle audio during space missions? _J From rem-conf Wed Apr 26 08:05:31 2000 From rem-conf-request@es.net Wed Apr 26 08:05:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kTLm-0000OP-00; Wed, 26 Apr 2000 08:03:38 -0700 Received: from iris.ctd.comsat.com [134.133.40.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kTLl-0000OF-00; Wed, 26 Apr 2000 08:03:37 -0700 Received: from campos by iris.ctd.comsat.com with local (Exim 2.12 #8) id 12kTKW-0002ij-00; Wed, 26 Apr 2000 11:02:20 -0400 From: Simao Campos To: Art Yerkes Cc: Henning Schulzrinne , rem-conf@es.net Subject: Re: G723 In-Reply-To: <3906FD2A.306F713E@cs.columbia.edu> References: <3906FA31.B8533A68@genxnet.com> <3906FD2A.306F713E@cs.columbia.edu> 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: Wed, 26 Apr 2000 11:02:20 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Art, Yes, G.723 is a "vacant" recommendation number now. For a short period of time, experts referred to the 6.3/5.3 kb/s ACELP/MP-LPC ITU codec as G.723, but this was quickly changed to G.723.1, to avoid confusion with the 24, 40 kb/s ADPCM G.723 spec. So any "modern" reference to G.723 has been to actually designate G.723.1. Do you feel we need more clear text on that regard in RTP profile? BTW, the code from Sun in ccitt-adpcm.tar.gz does not process the ITU test vectors correctly, hence it cannot be claimed to comply to the ITU Standard (Note for newbies: the ITU-T was formerly known as CCITT). The code in the ITU Software Tool Library does, and runs very fast on today's CPUs. Simao. >>>>> "Henning" == Henning Schulzrinne writes: Henning> Art Yerkes wrote: >> >> For G.723, http://www.cwi.nl/ftp/audio/ccitt-adpcm.tar.gz. These >> sources come from sun. Not sure if they're any faster, though. Henning> Thanks for all the responses. A brief summary: Henning> - The ITU floating point code for G.729 is significantly faster than the Henning> fixed-point code. Decoding takes about 8% of a SPARC Ultra CPU, encoding Henning> about a third. Henning> - The term G.723 is the subject of endless confusion. The source cited Henning> above is the "old" G.723. The RTP profile explains it thusly: Henning> "Note: In 1990, ITU-T Recommendation G.721 was merged with Henning> Recommendation Henning> G.723 into ITU-T Recommendation G.726. Thus, G726-32 designates the same Henning> algorithm as G721 in RFC 1890." Henning> Most people (myself included) seem to use the term G.723 now for what's Henning> more precisely called G.723.1, the 5.3/6.3 kb/s codec. Henning> Thanks again. Henning> -- Henning> Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 26 09:24:04 2000 From rem-conf-request@es.net Wed Apr 26 09:24:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kUXd-0001u8-00; Wed, 26 Apr 2000 09:19:57 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12kUXc-0001ty-00; Wed, 26 Apr 2000 09:19:56 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id JAA24421; Wed, 26 Apr 2000 09:08:09 -0700 Message-Id: <3.0.3.32.20000426090000.00af1120@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 26 Apr 2000 09:00:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/26 SMIL/XML ... -- Patrick Schmitz, Microsoft Bay Area Research Center Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar SMIL/XML ... Wednesday April 26, 2000 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Patrick Schmitz Microsoft Bay Area Research Center Growing interest in SMIL underscores the importance of a common language to describe timing and synchronization in documents. SMIL 1 defined syntax and semantics for a basic multimedia language. This was an important first step, but does not allow authors to use the timing semantics with other languages, like HTML and CSS. Authors need to be able to describe timing for wide range of documents, and to combine the semantics of timing and sync with other existing tools and semantics that are in common use, such as CSS. In addition, they need the flexibility to accommodate different editing/authoring scenarios and constraints. We need to provide a common model for timing so that authors are not forced to learn and remember different models for different document types or different authoring scenarios. In addition, where different syntactic approaches are available (e.g. to address different authoring scenarios), it is important to allow authors to combine the different approaches in a straightforward manner. This talk will describe three approaches to the integration of timing and synchronization with XML languages. I will describe the current work in SMIL Boston to support the integration of SMIL with HTML/CSS, as well as other applications and future work. I will also describe a proposed framework for combining the approaches. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Wed Apr 26 10:43:44 2000 From rem-conf-request@es.net Wed Apr 26 10:43:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kVkm-0003WI-00; Wed, 26 Apr 2000 10:37:36 -0700 Received: from silver.kpnqwest.fi [193.64.226.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kVkk-0003W8-00; Wed, 26 Apr 2000 10:37:34 -0700 Received: from kpnqwest.fi (localhost.eunet.fi [127.0.0.1]) by silver.kpnqwest.fi (8.9.3/8.9.2) with ESMTP id UAA71577; Wed, 26 Apr 2000 20:38:16 +0300 (EEST) (envelope-from pete@kpnqwest.fi) Sender: pete@silver.kpnqwest.fi Message-ID: <39072988.44677606@kpnqwest.fi> Date: Wed, 26 Apr 2000 20:38:16 +0300 From: Petri Helenius Organization: KPNQwest Finland Oy X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en,fi MIME-Version: 1.0 To: Jeremy Hall CC: mbone@ISI.EDU, rem-conf@es.net Subject: Re: audio coverage of space shuttle mission STS-101 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jeremy Hall wrote: > > Hi, > > Out of curiosity, is anybody interested in mp3 streams of shuttle audio > during space missions? > Would this be accompanied with MPEG-1,MPEG-2 or MPEG-4 video? Pete From rem-conf Wed Apr 26 11:19:39 2000 From rem-conf-request@es.net Wed Apr 26 11:19:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kWKm-0004dI-00; Wed, 26 Apr 2000 11:14:48 -0700 Received: from dnai.com [207.181.194.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kWKl-0004az-00; Wed, 26 Apr 2000 11:14:47 -0700 Received: from hariv (cougar.chiplogic.com [216.15.52.34]) by dnai.com (8.9.3/8.9.3) with SMTP id LAA64912 for ; Wed, 26 Apr 2000 11:13:47 -0700 (PDT) Message-ID: <012101bfafaa$9ba75880$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: Subject: Echo Cancellers Date: Wed, 26 Apr 2000 11:09:47 -0700 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.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am interested in knowing what kind of echo cancellers do we require in typical VoIP applications. Is there a requirement for delays greater than 64msecs? Regards Hari From rem-conf Wed Apr 26 12:10:00 2000 From rem-conf-request@es.net Wed Apr 26 12:09:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kXAa-0006Yz-00; Wed, 26 Apr 2000 12:08:20 -0700 Received: from lukla.sun.com [192.18.98.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kXAY-0006Yp-00; Wed, 26 Apr 2000 12:08:18 -0700 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01322 for ; Wed, 26 Apr 2000 13:08:07 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA28931 for ; Wed, 26 Apr 2000 12:08:06 -0700 (PDT) Received: from valathar (valathar [129.146.122.176]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA28985; Wed, 26 Apr 2000 12:08:05 -0700 (PDT) Date: Wed, 26 Apr 2000 12:08:06 -0700 (PDT) From: "Michael F. Speer" Reply-To: "Michael F. Speer" Subject: Sun Announces a Streaming Media Solution To: rem-conf@es.net Cc: speer@valathar.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Below is 2 URL's announcing a RTSP/RTP streaming solution from Sun. One URL is the press release and the other is a pointer to where one can find a try and buy URL. http://www.sun.com/smi/Press/sunflash/2000-04/sunflash.20000410.2.html http://www.sun.com/storage/ Regards, Michael From rem-conf Wed Apr 26 12:45:12 2000 From rem-conf-request@es.net Wed Apr 26 12:45:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kXhV-00002R-00; Wed, 26 Apr 2000 12:42:21 -0700 Received: from wodc7-2.corprelay.mail.uu.net [192.48.96.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kXhU-00002G-00; Wed, 26 Apr 2000 12:42:20 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQimpy10560; Wed, 26 Apr 2000 19:42:19 GMT Received: by neserve0.corp.us.uu.net id QQimpy29744; Wed, 26 Apr 2000 15:42:15 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: audio coverage of space shuttle mission STS-101 In-Reply-To: <39072988.44677606@kpnqwest.fi> from Petri Helenius at "Apr 26, 2000 08:38:16 pm" To: Petri Helenius Date: Wed, 26 Apr 2000 15:42:10 -0400 (EDT) CC: Jeremy Hall , mbone@ISI.EDU, rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list not by me. :) In the new year, Petri Helenius wrote: > Jeremy Hall wrote: > > > > Hi, > > > > Out of curiosity, is anybody interested in mp3 streams of shuttle audio > > during space missions? > > > Would this be accompanied with MPEG-1,MPEG-2 or MPEG-4 video? > > Pete > From rem-conf Wed Apr 26 12:51:11 2000 From rem-conf-request@es.net Wed Apr 26 12:51:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kXoh-0000aC-00; Wed, 26 Apr 2000 12:49:47 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kXoe-0000Zk-00; Wed, 26 Apr 2000 12:49:45 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id PAA15901; Wed, 26 Apr 2000 15:43:43 -0400 (EDT) Message-ID: <390747F8.BA10F60B@sknetworks.com> Date: Wed, 26 Apr 2000 12:48:08 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hari Krishna Vuppaladhadiam CC: rem-conf@es.net Subject: Re: Echo Cancellers References: <012101bfafaa$9ba75880$03000004@hariv.domain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I think there is a good application for high-delay echo cancellers. Consider the following scenarios: --------------- or ----------- or ---- Typical echo cancellers at the edge of the VoIP network (e.g. Cisco routers) only provide 32 msec of coverage. If a hop-off tail circuit has a round-trip delay that exceeds the coverage of the echo canceller (on the outbound edge of the VoIP network), then the additional delay of the VoIP network (100 msec or more usually) exacerbates the echo problem. This is an intractable problem without the use of echo cancellers that have longer coverage ability. -Scott Hari Krishna Vuppaladhadiam wrote: > > Hi, > I am interested in knowing what kind of echo cancellers do we require in > typical VoIP applications. Is there a requirement for delays greater than > 64msecs? > > Regards > Hari -- ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= From rem-conf Wed Apr 26 13:30:05 2000 From rem-conf-request@es.net Wed Apr 26 13:30:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kYLv-0001xd-00; Wed, 26 Apr 2000 13:24:07 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 12kYLt-0001xO-00; Wed, 26 Apr 2000 13:24:06 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 26 Apr 2000 15:22:35 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 852568CD.007009C6 ; Wed, 26 Apr 2000 16:23:45 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Kevin_Bruemmer@nmss.com To: Scott Keagy cc: Hari Krishna Vuppaladhadiam , rem-conf@es.net Message-ID: <852568CD.00700871.00@notes4.nmss.com> Date: Wed, 26 Apr 2000 16:23:43 -0400 Subject: Re: Echo Cancellers 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 Scott: Thanks for you input to the group on this subject. There seems to be a considerable amount of misunderstanding about echo control with VoIP networks. I repeat a label your networks below to make some points of discussion: Case 1: --------------- Case 2: ----------- Case 3: ---- In case 1, user A has a four-wire connection to the network and user B also has a four-wire connection to the network. That is - unless somewhere in the mobile network or in the PSTN there is some two wire circuits. Unless user A is using a poor quality speakerphone, there should be no need for any echo cancellation at all. for case 2, there should also be no need for any echo cancellers unless, again, the PSTN has been poorly engineered and has two-wire connections somewhere. For case 3, it the right side of the network has a Media Gateway. At some point to the right of that gateway there will be a two-four wire hybrid which will be the source of an echo. The echo would be user a "talker echo". Therefore, the media gateway has ther responsibility of echo cancelling this echo. This is typicaly short - as in certainly less than 20 msec. It is true - that the longer the VoIP network delay, the better the echo canceller in the network must work. This is why it is important for VoIP networks to manage their delay downwards as much as possible. To do otherwise causes a) the media gateway echo canceller to "work harder" than it should have to and b) cause conversational double-talking that is subjectively annoying even when the echo control is perfect. The basic misimpression that I see all too often is that people believe that "station side" or subscriber equipment echo cancellers need to be deployed at the subscriber or user's equipment. This is, for the most part, untrue. If it turns out to be true, someone architected their network poorly. Echo cancellers with long tail coverage are an expensive commitment to poor network design. If I recall correctly, even with normal characteristic impedances in cable (free space is faster) a tail circuit across the country will not exceed 20 msecs. Kevin Scott Keagy on 04/26/2000 03:48:08 PM To: Hari Krishna Vuppaladhadiam cc: rem-conf@es.net (bcc: Kevin Bruemmer/Natural MicroSystems/US) Subject: Re: Echo Cancellers I think there is a good application for high-delay echo cancellers. Consider the following scenarios: --------------- or ----------- or ---- Typical echo cancellers at the edge of the VoIP network (e.g. Cisco routers) only provide 32 msec of coverage. If a hop-off tail circuit has a round-trip delay that exceeds the coverage of the echo canceller (on the outbound edge of the VoIP network), then the additional delay of the VoIP network (100 msec or more usually) exacerbates the echo problem. This is an intractable problem without the use of echo cancellers that have longer coverage ability. -Scott Hari Krishna Vuppaladhadiam wrote: > > Hi, > I am interested in knowing what kind of echo cancellers do we require in > typical VoIP applications. Is there a requirement for delays greater than > 64msecs? > > Regards > Hari -- ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= From rem-conf Wed Apr 26 15:01:42 2000 From rem-conf-request@es.net Wed Apr 26 15:01:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kZpa-00041a-00; Wed, 26 Apr 2000 14:58:50 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kZpX-00041K-00; Wed, 26 Apr 2000 14:58:48 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id RAA13861; Wed, 26 Apr 2000 17:52:43 -0400 (EDT) Message-ID: <39076634.4635F228@sknetworks.com> Date: Wed, 26 Apr 2000 14:57:08 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin_Bruemmer@nmss.com CC: Hari Krishna Vuppaladhadiam , rem-conf@es.net Subject: Re: Echo Cancellers References: <852568CD.00700871.00@notes4.nmss.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Kevin et al, feel free to correct me if I'm wrong in the details below.... I added more details to the diagrams to clarify what we're talking about. ITU Echo Canceller Requirements ------------------------------- ITU-T Recommendation G.131 "Control of Talker Echo" (section 4.1) states the following: "In general, it is recommended that the active echo control devices shall be deployed on all connections which exceed the total one-way talker echo transmission path time of 25 ms." This implies that public phone networks may not provide echo cancellation for tail-end hop-off circuits that have up to 50 msec round-trip latency. Where echo originates --------------------- Impedance mismatches at 2-wire/4-wire hybrids (transitions from 2-wire to 4-wire circuits) can cause signal reflections. The likely spots where these hybrids can cause problems for VoIP hop-off scenarios are illustrated below. Carrier equipment may not be optimally tuned, or customer equipment may not be optimally tuned. In addition to these spots, acoustic echoes may occur from the destination speaker/mic equipment (i.e. speakerphone or cheap telephone handset). I submit as proof that not all networks are ideally designed, that I frequently call residential locations in India from the U.S. I here my own echo on at least half of the conversations, which implies that some telco central offices in India have poor hybrid terminations. What a company can do about it ------------------------------- Given the ITU recommendations that support a carrier's right to not employ echo cancellers in medium-delay networks (i.e. up to 50 msec round-trip), a company employing a VoIP solution has no recourse to block the echo other than to use echo cancellers with high delay coverage, as illustrated below. A given company can't fix the network problems for different calling destinations (i.e. adjust the impedance coupling at the hybrid to increase the return loss), but it can take personal action to defend the voice quality experienced by its employees. Note that this is an enterprise-centric approach to the problem. A carrier-centric approach might be to negotiate with the remote telco to fix the problem, so that the local carrier does not get stuck with the echo-canceller bill. So high delay echo cancellers may be useful for low-end and enterprise products, but not for carrier products. Also note that up to 64 msec is sufficient given that all networks are designed according to ITU spec. ==== : 4-wire circuit ---- : 2-wire circuit ************************************************************************** ||===== || || ============----- ^ ^ | | | | | (signal from A reflected here) | (High delay echo canceller needed here) ************************************************************************** ==========------- ^ ^ | | | | | (signal from A reflected here) | (High delay echo canceller needed here) *************************************************************************** -Scott Kevin_Bruemmer@nmss.com wrote: > > Scott: > > Thanks for you input to the group on this subject. There seems to be a > considerable amount of misunderstanding about echo control with VoIP networks. > I repeat a label your networks below to make some points of discussion: > > Case 1: > --------------- > > Case 2: > > ----------- > > Case 3: > > ---- > > In case 1, user A has a four-wire connection to the network and user B also has > a four-wire connection to the network. That is - unless somewhere in the mobile > network or in the PSTN there is some two wire circuits. Unless user A is using > a poor quality speakerphone, there should be no need for any echo cancellation > at all. > > for case 2, there should also be no need for any echo cancellers unless, again, > the PSTN has been poorly engineered and has two-wire connections somewhere. > > For case 3, it the right side of the network has a Media Gateway. At some point > to the right of that gateway there will be a two-four wire hybrid which will be > the source of an echo. The echo would be user a "talker echo". Therefore, the > media gateway has ther responsibility of echo cancelling this echo. This is > typicaly short - as in certainly less than 20 msec. It is true - that the > longer the VoIP network delay, the better the echo canceller in the network must > work. This is why it is important for VoIP networks to manage their delay > downwards as much as possible. To do otherwise causes a) the media gateway echo > canceller to "work harder" than it should have to and b) cause conversational > double-talking that is subjectively annoying even when the echo control is > perfect. > > The basic misimpression that I see all too often is that people believe that > "station side" or subscriber equipment echo cancellers need to be deployed at > the subscriber or user's equipment. This is, for the most part, untrue. If it > turns out to be true, someone architected their network poorly. Echo cancellers > with long tail coverage are an expensive commitment to poor network design. > > If I recall correctly, even with normal characteristic impedances in cable (free > space is faster) a tail circuit across the country will not exceed 20 msecs. > > Kevin > > Scott Keagy on 04/26/2000 03:48:08 PM > > To: Hari Krishna Vuppaladhadiam > cc: rem-conf@es.net (bcc: Kevin Bruemmer/Natural MicroSystems/US) > Subject: Re: Echo Cancellers > > I think there is a good application for high-delay echo cancellers. > Consider the following scenarios: > > --------------- > or > ----------- > or > ---- > > Typical echo cancellers at the edge of the VoIP network (e.g. Cisco > routers) only provide 32 msec of coverage. If a hop-off tail circuit has > a round-trip delay that exceeds the coverage of the echo canceller (on > the outbound edge of the VoIP network), then the additional delay of the > VoIP network (100 msec or more usually) exacerbates the echo problem. > > This is an intractable problem without the use of echo cancellers that > have longer coverage ability. > > -Scott > > Hari Krishna Vuppaladhadiam wrote: > > > > Hi, > > I am interested in knowing what kind of echo cancellers do we require in > > typical VoIP applications. Is there a requirement for delays greater than > > 64msecs? > > > > Regards > > Hari > > -- > ======================================================= > Scott Keagy, CCIE #3985 > Senior Networking Consultant > SK Networks, Inc. mailto:scott@sknetworks.com > ======================================================= -- ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= From rem-conf Wed Apr 26 15:24:49 2000 From rem-conf-request@es.net Wed Apr 26 15:24:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kaB8-0004xj-00; Wed, 26 Apr 2000 15:21:06 -0700 Received: from dnai.com [207.181.194.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kaB7-0004vP-00; Wed, 26 Apr 2000 15:21:05 -0700 Received: from hariv (cougar.chiplogic.com [216.15.52.34]) by dnai.com (8.9.3/8.9.3) with SMTP id PAA64843; Wed, 26 Apr 2000 15:19:21 -0700 (PDT) Message-ID: <01c001bfafcc$ea59b500$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: "Scott Keagy" , Cc: Subject: Re: Echo Cancellers Date: Wed, 26 Apr 2000 15:12:19 -0700 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.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I see in many of the company websites of VoIP specifying Echo cancellers (ITU-G.165/G.168) standards. When it comes to delay it goes upto 128 msecs. Now I understand a case where Mobile networks is involved, one can find larger delays. It takes lot of MIPS to run Echo cancellers for larger delays. Where do I get information regarding the DELAY? And also the necessity of an Echo canceller for say a residential gateway or an enterprise gateway? Hari -----Original Message----- From: Scott Keagy To: Kevin_Bruemmer@nmss.com Cc: Hari Krishna Vuppaladhadiam ; rem-conf@es.net Date: Wednesday, April 26, 2000 2:58 PM Subject: Re: Echo Cancellers >Kevin et al, > >feel free to correct me if I'm wrong in the details below.... > >I added more details to the diagrams to clarify what we're talking >about. > > > >ITU Echo Canceller Requirements >------------------------------- > >ITU-T Recommendation G.131 "Control of Talker Echo" (section 4.1) states >the following: >"In general, it is recommended that the active echo control devices >shall be deployed on all connections which exceed the total one-way >talker echo transmission path time of 25 ms." > >This implies that public phone networks may not provide echo >cancellation for tail-end hop-off circuits that have up to 50 msec >round-trip latency. > > >Where echo originates >--------------------- >Impedance mismatches at 2-wire/4-wire hybrids (transitions from 2-wire >to 4-wire circuits) can cause signal reflections. The likely spots where >these hybrids can cause problems for VoIP hop-off scenarios are >illustrated below. Carrier equipment may not be optimally tuned, or >customer equipment may not be optimally tuned. In addition to these >spots, acoustic echoes may occur from the destination speaker/mic >equipment (i.e. speakerphone or cheap telephone handset). > >I submit as proof that not all networks are ideally designed, that I >frequently call residential locations in India from the U.S. I here my >own echo on at least half of the conversations, which implies that some >telco central offices in India have poor hybrid terminations. > > >What a company can do about it >------------------------------- >Given the ITU recommendations that support a carrier's right to not >employ echo cancellers in medium-delay networks (i.e. up to 50 msec >round-trip), a company employing a VoIP solution has no recourse to >block the echo other than to use echo cancellers with high delay >coverage, as illustrated below. A given company can't fix the network >problems for different calling destinations (i.e. adjust the impedance >coupling at the hybrid to increase the return loss), but it can take >personal action to defend the voice quality experienced by its >employees. > >Note that this is an enterprise-centric approach to the problem. A >carrier-centric approach might be to negotiate with the remote telco to >fix the problem, so that the local carrier does not get stuck with the >echo-canceller bill. So high delay echo cancellers may be useful for >low-end and enterprise products, but not for carrier products. Also note >that up to 64 msec is sufficient given that all networks are designed >according to ITU spec. > > >==== : 4-wire circuit >---- : 2-wire circuit > >************************************************************************** > ||=====C> > || > || >============-----B> > ^ ^ > | | > | | > | (signal from A reflected here) > | > (High delay echo canceller needed here) > >************************************************************************** > >==========------- > ^ ^ > | | > | | > | (signal from A reflected here) > | > (High delay echo canceller needed here) > >*************************************************************************** > >-Scott > >Kevin_Bruemmer@nmss.com wrote: >> >> Scott: >> >> Thanks for you input to the group on this subject. There seems to be a >> considerable amount of misunderstanding about echo control with VoIP networks. >> I repeat a label your networks below to make some points of discussion: >> >> Case 1: >> --------------- >> >> Case 2: >> >> ----------- >> >> Case 3: >> >> ---- >> >> In case 1, user A has a four-wire connection to the network and user B also has >> a four-wire connection to the network. That is - unless somewhere in the mobile >> network or in the PSTN there is some two wire circuits. Unless user A is using >> a poor quality speakerphone, there should be no need for any echo cancellation >> at all. >> >> for case 2, there should also be no need for any echo cancellers unless, again, >> the PSTN has been poorly engineered and has two-wire connections somewhere. >> >> For case 3, it the right side of the network has a Media Gateway. At some point >> to the right of that gateway there will be a two-four wire hybrid which will be >> the source of an echo. The echo would be user a "talker echo". Therefore, the >> media gateway has ther responsibility of echo cancelling this echo. This is >> typicaly short - as in certainly less than 20 msec. It is true - that the >> longer the VoIP network delay, the better the echo canceller in the network must >> work. This is why it is important for VoIP networks to manage their delay >> downwards as much as possible. To do otherwise causes a) the media gateway echo >> canceller to "work harder" than it should have to and b) cause conversational >> double-talking that is subjectively annoying even when the echo control is >> perfect. >> >> The basic misimpression that I see all too often is that people believe that >> "station side" or subscriber equipment echo cancellers need to be deployed at >> the subscriber or user's equipment. This is, for the most part, untrue. If it >> turns out to be true, someone architected their network poorly. Echo cancellers >> with long tail coverage are an expensive commitment to poor network design. >> >> If I recall correctly, even with normal characteristic impedances in cable (free >> space is faster) a tail circuit across the country will not exceed 20 msecs. >> >> Kevin >> >> Scott Keagy on 04/26/2000 03:48:08 PM >> >> To: Hari Krishna Vuppaladhadiam >> cc: rem-conf@es.net (bcc: Kevin Bruemmer/Natural MicroSystems/US) >> Subject: Re: Echo Cancellers >> >> I think there is a good application for high-delay echo cancellers. >> Consider the following scenarios: >> >> --------------- >> or >> ----------- >> or >> ---- >> >> Typical echo cancellers at the edge of the VoIP network (e.g. Cisco >> routers) only provide 32 msec of coverage. If a hop-off tail circuit has >> a round-trip delay that exceeds the coverage of the echo canceller (on >> the outbound edge of the VoIP network), then the additional delay of the >> VoIP network (100 msec or more usually) exacerbates the echo problem. >> >> This is an intractable problem without the use of echo cancellers that >> have longer coverage ability. >> >> -Scott >> >> Hari Krishna Vuppaladhadiam wrote: >> > >> > Hi, >> > I am interested in knowing what kind of echo cancellers do we require in >> > typical VoIP applications. Is there a requirement for delays greater than >> > 64msecs? >> > >> > Regards >> > Hari >> >> -- >> ======================================================= >> Scott Keagy, CCIE #3985 >> Senior Networking Consultant >> SK Networks, Inc. mailto:scott@sknetworks.com >> ======================================================= > >-- >======================================================= > Scott Keagy, CCIE #3985 > Senior Networking Consultant > SK Networks, Inc. mailto:scott@sknetworks.com >======================================================= From rem-conf Thu Apr 27 00:29:08 2000 From rem-conf-request@es.net Thu Apr 27 00:29:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kibZ-0002qt-00; Thu, 27 Apr 2000 00:20:57 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12kibX-0002qi-00; Thu, 27 Apr 2000 00:20:55 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Apr 2000 08:20:16 +0100 To: Scott Keagy cc: Hari Krishna Vuppaladhadiam , rem-conf@es.net Subject: Re: Echo Cancellers In-reply-to: Your message of "Wed, 26 Apr 2000 12:48:08 PDT." <390747F8.BA10F60B@sknetworks.com> Date: Thu, 27 Apr 2000 08:20:19 +0100 Message-ID: <1246.956820019@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <390747F8.BA10F60B@sknetworks.com>, Scott Keagy typed: >>Typical echo cancellers at the edge of the VoIP network (e.g. Cisco >>routers) only provide 32 msec of coverage. If a hop-off tail circuit has >>a round-trip delay that exceeds the coverage of the echo canceller (on >>the outbound edge of the VoIP network), then the additional delay of the >>VoIP network (100 msec or more usually) exacerbates the echo problem. >>This is an intractable problem without the use of echo cancellers that >>have longer coverage ability. Scott well a well engineered path from London to San Francisco consistently has a delay of around 150ms.... (see below) - i dont see why someone cant think a bit about echo cancellors for this.....references would be interesting on why it is "intractable" - is it only if the delay is also highly variable (the path below has low delay variance - probably lower than a lot of paths with lower e2e delays by about an order of magnitude) j. 1 cisco (128.16.6.150) 1.290 ms 0.822 ms 0.774 ms 2 cisco-pb (128.40.14.245) 1.037 ms 1.005 ms 0.931 ms 3 10.0.121.5 (10.0.121.5) 1.091 ms 1.116 ms 0.943 ms 4 128.40.255.153 (128.40.255.153) 1.011 ms 0.978 ms 0.961 ms 5 atmr-ulcc.lmn.net.uk (194.83.100.62) 2.442 ms 2.072 ms 2.861 ms 6 146.97.255.65 (146.97.255.65) 2.888 ms 3.083 ms 3.552 ms 7 us-gw2.ja.net (128.86.1.242) 2.644 ms 4.118 ms 4.282 ms 8 193.62.157.10 (193.62.157.10) 77.606 ms 78.305 ms 76.007 ms 9 ny-pop.i2.ja.net (193.62.157.2) 76.505 ms 77.377 ms 77.356 ms 10 clev-nycm.abilene.ucaid.edu (198.32.8.29) 91.581 ms 91.423 ms 91.912 ms 11 ipls-clev.abilene.ucaid.edu (198.32.8.25) 97.521 ms 97.082 ms 97.209 ms 12 kscy-ipls.abilene.ucaid.edu (198.32.8.5) 106.739 ms 106.723 ms 106.687 ms 13 denv-kscy.abilene.ucaid.edu (198.32.8.13) 117.296 ms 117.093 ms 117.063 m s 14 scrm-denv.abilene.ucaid.edu (198.32.8.1) 139.592 ms 140.627 ms 138.953 ms 15 BERK--abilene.POS.calren2.net (198.32.249.41) 142.507 ms 142.512 ms 142.5 65 ms 16 pos1-0.inr-000-eva.Berkeley.EDU (128.32.0.89) 142.498 ms 142.269 ms 142.5 63 ms 17 pos5-0-0.inr-002-eva.Berkeley.EDU (128.32.0.74) 139.891 ms 139.231 ms 139 .991 ms 18 fast9-0-0.inr-010-cory.Berkeley.EDU (128.32.0.42) 140.512 ms 141.192 ms 1 40.178 ms 19 f1-0.inr-181-soda.Berkeley.EDU (128.32.120.181) 144.808 ms 143.865 ms 144 .345 ms 20 router1.ICSI.Berkeley.EDU (192.150.186.2) 146.302 ms 145.192 ms 146.140 m s 21 www.aciri.org (192.150.187.11) 146.306 ms 153.327 ms 146.852 ms From rem-conf Thu Apr 27 07:08:14 2000 From rem-conf-request@es.net Thu Apr 27 07:08:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kokX-0006SC-00; Thu, 27 Apr 2000 06:54:37 -0700 Received: from alc119.alcatel.be (relay1.alcatel.be) [195.207.101.119] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kokU-0006Rz-00; Thu, 27 Apr 2000 06:54:34 -0700 Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.9.1a/8.9.1) with ESMTP id PAA19631; Thu, 27 Apr 2000 15:52:57 +0200 (MET DST) Received: from alcatel.be (bt00rd [138.203.66.122]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id PAA22286; Thu, 27 Apr 2000 15:53:03 +0200 (MET DST) Message-ID: <3908461A.20C74993@alcatel.be> Date: Thu, 27 Apr 2000 15:52:26 +0200 From: Bart Van Doorselaer Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jon Crowcroft CC: Scott Keagy , Hari Krishna Vuppaladhadiam , rem-conf@es.net Subject: Re: Echo Cancellers References: <1246.956820019@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 Let us not confuse near-end and far-end echo canceling. Assume a PSTN-GW-IP-GW-PSTN scenario. If you only provide near-end echo cancelling you only have to take into account low delays (i.e. mainly the transmission delay in the PSTN between the hybrid and the gateway - which is about 5 microseconds per km). In that case, it is of course a prerequisite to provide near-end echo cancelling on both gateways (and how do you guarantee that?) If you want to provide far-end echo cancelling as well, the more-than-100-ms assumption will be realistic indeed. Bart Jon Crowcroft wrote: > In message <390747F8.BA10F60B@sknetworks.com>, Scott Keagy typed: > > >>Typical echo cancellers at the edge of the VoIP network (e.g. Cisco > >>routers) only provide 32 msec of coverage. If a hop-off tail circuit has > >>a round-trip delay that exceeds the coverage of the echo canceller (on > >>the outbound edge of the VoIP network), then the additional delay of the > >>VoIP network (100 msec or more usually) exacerbates the echo problem. > > >>This is an intractable problem without the use of echo cancellers that > >>have longer coverage ability. > > Scott > > well a well engineered path from London to San Francisco consistently > has a delay of around 150ms.... (see below) - i dont see why someone > cant think a bit about echo cancellors for this.....references would > be interesting on why it is "intractable" - is it only if the delay is > also highly variable (the path below has low delay variance - probably > lower than a lot of paths with lower e2e delays by about an order of > magnitude) > > j. -- ____________________ Bart Van Doorselaer \ / _______________________________________________\ /____ \ / Research Engineer \ ALCATEL / DN2 Network Strategy Group Tel : +32 3 240 86 41 Francis Wellesplein 1 Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium _____________________________________________________\ /__________ mailto:Bart.Van_Doorselaer@alcatel.be \ / \/ From rem-conf Thu Apr 27 07:29:15 2000 From rem-conf-request@es.net Thu Apr 27 07:29:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kpGO-0007Nt-00; Thu, 27 Apr 2000 07:27:32 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 12kpGL-0007Nj-00; Thu, 27 Apr 2000 07:27:30 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 27 Apr 2000 09:25:58 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 852568CE.004F6691 ; Thu, 27 Apr 2000 10:27:16 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Kevin_Bruemmer@nmss.com To: Jon Crowcroft cc: Scott Keagy , Hari Krishna Vuppaladhadiam , rem-conf@es.net Message-ID: <852568CE.004F667E.00@notes4.nmss.com> Date: Thu, 27 Apr 2000 10:27:18 -0400 Subject: Re: Echo Cancellers 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 Jon: Unless I misunderstand what you are saying below, you should confuse the end-end delay of an entire connection with what coverage the echo canceller must have. The network echo canceller (G.165/G.168 definition) should cancel the echo as reflected on the far end. In other words, the echo canceller's responsibility is to cancel the talker echo at or near the two-four wire hybrid at the listener's end of the connection. Kevin Jon Crowcroft on 04/27/2000 03:20:19 AM To: Scott Keagy cc: Hari Krishna Vuppaladhadiam , rem-conf@es.net (bcc: Kevin Bruemmer/Natural MicroSystems/US) Subject: Re: Echo Cancellers In message <390747F8.BA10F60B@sknetworks.com>, Scott Keagy typed: >>Typical echo cancellers at the edge of the VoIP network (e.g. Cisco >>routers) only provide 32 msec of coverage. If a hop-off tail circuit has >>a round-trip delay that exceeds the coverage of the echo canceller (on >>the outbound edge of the VoIP network), then the additional delay of the >>VoIP network (100 msec or more usually) exacerbates the echo problem. >>This is an intractable problem without the use of echo cancellers that >>have longer coverage ability. Scott well a well engineered path from London to San Francisco consistently has a delay of around 150ms.... (see below) - i dont see why someone cant think a bit about echo cancellors for this.....references would be interesting on why it is "intractable" - is it only if the delay is also highly variable (the path below has low delay variance - probably lower than a lot of paths with lower e2e delays by about an order of magnitude) j. 1 cisco (128.16.6.150) 1.290 ms 0.822 ms 0.774 ms 2 cisco-pb (128.40.14.245) 1.037 ms 1.005 ms 0.931 ms 3 10.0.121.5 (10.0.121.5) 1.091 ms 1.116 ms 0.943 ms 4 128.40.255.153 (128.40.255.153) 1.011 ms 0.978 ms 0.961 ms 5 atmr-ulcc.lmn.net.uk (194.83.100.62) 2.442 ms 2.072 ms 2.861 ms 6 146.97.255.65 (146.97.255.65) 2.888 ms 3.083 ms 3.552 ms 7 us-gw2.ja.net (128.86.1.242) 2.644 ms 4.118 ms 4.282 ms 8 193.62.157.10 (193.62.157.10) 77.606 ms 78.305 ms 76.007 ms 9 ny-pop.i2.ja.net (193.62.157.2) 76.505 ms 77.377 ms 77.356 ms 10 clev-nycm.abilene.ucaid.edu (198.32.8.29) 91.581 ms 91.423 ms 91.912 ms 11 ipls-clev.abilene.ucaid.edu (198.32.8.25) 97.521 ms 97.082 ms 97.209 ms 12 kscy-ipls.abilene.ucaid.edu (198.32.8.5) 106.739 ms 106.723 ms 106.687 ms 13 denv-kscy.abilene.ucaid.edu (198.32.8.13) 117.296 ms 117.093 ms 117.063 m s 14 scrm-denv.abilene.ucaid.edu (198.32.8.1) 139.592 ms 140.627 ms 138.953 ms 15 BERK--abilene.POS.calren2.net (198.32.249.41) 142.507 ms 142.512 ms 142.5 65 ms 16 pos1-0.inr-000-eva.Berkeley.EDU (128.32.0.89) 142.498 ms 142.269 ms 142.5 63 ms 17 pos5-0-0.inr-002-eva.Berkeley.EDU (128.32.0.74) 139.891 ms 139.231 ms 139 .991 ms 18 fast9-0-0.inr-010-cory.Berkeley.EDU (128.32.0.42) 140.512 ms 141.192 ms 1 40.178 ms 19 f1-0.inr-181-soda.Berkeley.EDU (128.32.120.181) 144.808 ms 143.865 ms 144 .345 ms 20 router1.ICSI.Berkeley.EDU (192.150.186.2) 146.302 ms 145.192 ms 146.140 m s 21 www.aciri.org (192.150.187.11) 146.306 ms 153.327 ms 146.852 ms From rem-conf Thu Apr 27 07:57:05 2000 From rem-conf-request@es.net Thu Apr 27 07:57:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kpeR-0000Sy-00; Thu, 27 Apr 2000 07:52:23 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 12kpeJ-0000Sl-00; Thu, 27 Apr 2000 07:52:20 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 27 Apr 2000 09:50:44 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 852568CE.0051A9DB ; Thu, 27 Apr 2000 10:51:58 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Kevin_Bruemmer@nmss.com To: Bart Van Doorselaer cc: Jon Crowcroft , Scott Keagy , Hari Krishna Vuppaladhadiam , rem-conf@es.net Message-ID: <852568CE.0051A7E2.00@notes4.nmss.com> Date: Thu, 27 Apr 2000 10:51:56 -0400 Subject: Re: Echo Cancellers 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 Bart: As far as I know, ETSI TIPHON, VoIP Forum ( IMTC) and the new ITU G.799 require the use of echo canceller on gateways. All the gateway vendors that I am aware of have network echo cancellers in them. If you sell a gateway without it, nobody in their right mind should buy it. In general - I believe that if an application needs a 20 msec echo canceller they either have a wireless application or something else is wrong. For wireless applications, the longest that I have heard as a requirement is 60 msecs. People are over-spec'ing echo canceller out of ignorance, not out of real need. Do you agree? Kevin, Bart Van Doorselaer on 04/27/2000 09:52:26 AM To: Jon Crowcroft cc: Scott Keagy , Hari Krishna Vuppaladhadiam , rem-conf@es.net (bcc: Kevin Bruemmer/Natural MicroSystems/US) Subject: Re: Echo Cancellers Let us not confuse near-end and far-end echo canceling. Assume a PSTN-GW-IP-GW-PSTN scenario. If you only provide near-end echo cancelling you only have to take into account low delays (i.e. mainly the transmission delay in the PSTN between the hybrid and the gateway - which is about 5 microseconds per km). In that case, it is of course a prerequisite to provide near-end echo cancelling on both gateways (and how do you guarantee that?) If you want to provide far-end echo cancelling as well, the more-than-100-ms assumption will be realistic indeed. Bart Jon Crowcroft wrote: > In message <390747F8.BA10F60B@sknetworks.com>, Scott Keagy typed: > > >>Typical echo cancellers at the edge of the VoIP network (e.g. Cisco > >>routers) only provide 32 msec of coverage. If a hop-off tail circuit has > >>a round-trip delay that exceeds the coverage of the echo canceller (on > >>the outbound edge of the VoIP network), then the additional delay of the > >>VoIP network (100 msec or more usually) exacerbates the echo problem. > > >>This is an intractable problem without the use of echo cancellers that > >>have longer coverage ability. > > Scott > > well a well engineered path from London to San Francisco consistently > has a delay of around 150ms.... (see below) - i dont see why someone > cant think a bit about echo cancellors for this.....references would > be interesting on why it is "intractable" - is it only if the delay is > also highly variable (the path below has low delay variance - probably > lower than a lot of paths with lower e2e delays by about an order of > magnitude) > > j. -- ____________________ Bart Van Doorselaer \ / _______________________________________________\ /____ \ / Research Engineer \ ALCATEL / DN2 Network Strategy Group Tel : +32 3 240 86 41 Francis Wellesplein 1 Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium _____________________________________________________\ /__________ mailto:Bart.Van_Doorselaer@alcatel.be \ / \/ From rem-conf Thu Apr 27 10:48:30 2000 From rem-conf-request@es.net Thu Apr 27 10:48:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ksHx-0002d0-00; Thu, 27 Apr 2000 10:41:21 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12ksHv-0002cq-00; Thu, 27 Apr 2000 10:41:19 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id KAA29855; Thu, 27 Apr 2000 10:29:17 -0700 Message-Id: <3.0.3.32.20000427103000.00afac90@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 27 Apr 2000 10:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 5/3 Design and Evaluations of Multimedia Proxy Caching Mechanisms for the Internet -- Reza Rejaie, AT&T Labs - Research Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Design and Evaluations of Multimedia Proxy Caching Mechanisms for the Internet Wednesday May 3, 2000 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Reza Rejaie AT&T Labs - Research Most of the existing Internet multimedia streaming applications are based on the client-server architecture. This architecture has two major limitations: 1) The quality of delivered streams is limited to the bottleneck bandwidth between the server and the client. Thus a client with a high bandwidth local connectivity may receive low quality streams due to a remote bottleneck. 2) Its scalability is limited, in that it is difficult to support a large number of concurrent high quality sessions due to network and server load. Multimedia proxy caching (MCaching) is a natural extension of the client-server architecture that addresses both limitations simultaneously. The idea is to cache popular streams with appropriate quality at a proxy close to interested clients. Thus the proxy can effectively enhance the delivered quality and improve scalability by significantly reducing the load on the network and the server. In this talk, we address the design and performance evaluations of MCaching mechanisms. First the design of an efficient MCaching mechanism for layered-encoded streams is outlined. We observe that in addition to cache efficiency (measured by hit ratio), MCaching introduces the notion of ``quality'' for delivered streams as a new dimension to Web caching. Thus performance of MCaching mechanisms should be collectively evaluated along both dimensions caching efficiency and delivered quality. We identify a fundamental tradeoff between these two dimensions. Our simulation results show that our proposed MCaching design can adaptively exploit this tradeoff to improve overall performance whereas simple extension of current Web caching schemes can only enhance the performance along one dimension. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Apr 27 13:22:28 2000 From rem-conf-request@es.net Thu Apr 27 13:22:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kuhf-0004kS-00; Thu, 27 Apr 2000 13:16:03 -0700 Received: from hartman.adgrafix.com [208.230.141.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kuhc-0004k7-00; Thu, 27 Apr 2000 13:16:01 -0700 Received: from sknetworks.com (skaul-isdn.cisco.com [171.70.242.22]) by hartman.adgrafix.com (8.9.3/8.9.3) with ESMTP id QAA08533; Thu, 27 Apr 2000 16:09:10 -0400 (EDT) Message-ID: <39089F61.6A9671A8@sknetworks.com> Date: Thu, 27 Apr 2000 13:13:21 -0700 From: Scott Keagy Organization: SK Networks, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin_Bruemmer@nmss.com CC: Bart Van Doorselaer , Jon Crowcroft , Hari Krishna Vuppaladhadiam , rem-conf@es.net Subject: Re: Echo Cancellers References: <852568CE.0051A7E2.00@notes4.nmss.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Distance between New York, NY and : San Diego, CA = 3914 km ====> 39.14 msec round trip San Francisco, CA = 4156 km ====> 41.56 msec " " Seattle, WA = 3884 km ====> 38.84 msec " " These times assume fiber spread "as the crow flies" and no switching/regeneration delays. An international company with a single U.S. office in one of these cities (or any city on either coast) will have problems with VoIP tail-end hop-off to other major population centers in the U.S. The engineering solution says, "why don't they just centrally locate their office in Chicago?" Echo cancellers seems like a funny reason to relocate a business though. -Scott Kevin_Bruemmer@nmss.com wrote: > > Bart: > > As far as I know, ETSI TIPHON, VoIP Forum ( IMTC) and the new ITU G.799 require > the use of echo canceller on gateways. All the gateway vendors that I am aware > of have network echo cancellers in them. If you sell a gateway without it, > nobody in their right mind should buy it. > > In general - I believe that if an application needs a 20 msec echo canceller > they either have a wireless application or something else is wrong. For > wireless applications, the longest that I have heard as a requirement is 60 > msecs. People are over-spec'ing echo canceller out of ignorance, not out of > real need. > > Do you agree? > > Kevin, > > Bart Van Doorselaer on 04/27/2000 09:52:26 AM > > To: Jon Crowcroft > cc: Scott Keagy , Hari Krishna Vuppaladhadiam > , rem-conf@es.net (bcc: Kevin Bruemmer/Natural > MicroSystems/US) > Subject: Re: Echo Cancellers > > Let us not confuse near-end and far-end echo canceling. > > Assume a PSTN-GW-IP-GW-PSTN scenario. > > If you only provide near-end echo cancelling you only have to take into account > low delays (i.e. mainly the transmission delay in the PSTN between the hybrid > and the gateway - which is about 5 microseconds per km). > In that case, it is of course a prerequisite to provide near-end echo > cancelling on both gateways (and how do you guarantee that?) > > If you want to provide far-end echo cancelling as well, the more-than-100-ms > assumption will be realistic indeed. > > Bart > > Jon Crowcroft wrote: > > > In message <390747F8.BA10F60B@sknetworks.com>, Scott Keagy typed: > > > > >>Typical echo cancellers at the edge of the VoIP network (e.g. Cisco > > >>routers) only provide 32 msec of coverage. If a hop-off tail circuit has > > >>a round-trip delay that exceeds the coverage of the echo canceller (on > > >>the outbound edge of the VoIP network), then the additional delay of the > > >>VoIP network (100 msec or more usually) exacerbates the echo problem. > > > > >>This is an intractable problem without the use of echo cancellers that > > >>have longer coverage ability. > > > > Scott > > > > well a well engineered path from London to San Francisco consistently > > has a delay of around 150ms.... (see below) - i dont see why someone > > cant think a bit about echo cancellors for this.....references would > > be interesting on why it is "intractable" - is it only if the delay is > > also highly variable (the path below has low delay variance - probably > > lower than a lot of paths with lower e2e delays by about an order of > > magnitude) > > > > j. > > -- > ____________________ > Bart Van Doorselaer \ / > _______________________________________________\ /____ > \ / > Research Engineer \ ALCATEL / > DN2 Network Strategy Group > Tel : +32 3 240 86 41 Francis Wellesplein 1 > Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium > _____________________________________________________\ /__________ > mailto:Bart.Van_Doorselaer@alcatel.be \ / > \/ -- ======================================================= Scott Keagy, CCIE #3985 Senior Networking Consultant SK Networks, Inc. mailto:scott@sknetworks.com ======================================================= From rem-conf Thu Apr 27 13:37:03 2000 From rem-conf-request@es.net Thu Apr 27 13:37:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kv0m-0005Za-00; Thu, 27 Apr 2000 13:35:48 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 12kv0j-0005ZD-00; Thu, 27 Apr 2000 13:35:47 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 27 Apr 2000 15:34:14 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 852568CE.00711A30 ; Thu, 27 Apr 2000 16:35:22 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: Scott Keagy cc: Kevin_Bruemmer@nmss.com, Bart Van Doorselaer , Jon Crowcroft , Hari Krishna Vuppaladhadiam , rem-conf@es.net Message-ID: <852568CE.00711951.00@notes4.nmss.com> Date: Thu, 27 Apr 2000 16:35:22 -0400 Subject: Re: Echo Cancellers 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 believe that you are assuming that the company has only one gateway. Generally, each location will have a gateway. Do you agree? From rem-conf Thu Apr 27 13:42:10 2000 From rem-conf-request@es.net Thu Apr 27 13:42:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kv6P-000673-00; Thu, 27 Apr 2000 13:41:37 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 12kv6J-00066h-00; Thu, 27 Apr 2000 13:41:37 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 27 Apr 2000 15:40:00 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 852568CE.0071A2AF ; Thu, 27 Apr 2000 16:41:12 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: rem-conf@es.net Message-ID: <852568CE.0071A1FE.00@notes4.nmss.com> Date: Thu, 27 Apr 2000 16:41:13 -0400 Subject: Re: Echo Cancellers 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 ---------------------- Forwarded by Bruce Levens/Natural MicroSystems/US on 04/27/2000 04:46 PM --------------------------- Bruce Levens 04/27/2000 04:40 PM To: Scott Keagy cc: Subject: Re: Echo Cancellers (Document link: Bruce Levens' Mail) Or perhaps you are implying that the company is located on the west coast and calls a gateway (via PSTN) in NY to reach its international offices, instead of having a gateway on the west coast. From rem-conf Thu Apr 27 14:31:44 2000 From rem-conf-request@es.net Thu Apr 27 14:31:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12kvqs-0007QN-00; Thu, 27 Apr 2000 14:29:38 -0700 Received: from dnai.com [207.181.194.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 12kvqq-0007Q7-00; Thu, 27 Apr 2000 14:29:36 -0700 Received: from hariv (cougar.chiplogic.com [216.15.52.34]) by dnai.com (8.9.3/8.9.3) with SMTP id OAA10854 for