From rem-conf Tue Jun 01 16:04:35 1999 From rem-conf-request@es.net Tue Jun 01 16:04:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10oxRh-0005nw-00; Tue, 1 Jun 1999 15:55:45 -0700 Received: from mail.nps.navy.mil [131.120.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 10oxRe-0005nl-00; Tue, 1 Jun 1999 15:55:43 -0700 Received: from nps.navy.mil (acoustic.stl.nps.navy.mil [131.120.178.143]) by mail.nps.navy.mil (8.9.3/8.9.3) with ESMTP id PAA17722; Tue, 1 Jun 1999 15:57:04 -0700 (PDT) Message-ID: <375464E5.62550239@nps.navy.mil> Date: Tue, 01 Jun 1999 15:55:34 -0700 From: Don Brutzman Organization: Naval Postgraduate School X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Baugher, Mark" CC: AVT working group , Francisco Afonso Subject: Re: draft-ietf-avt-mib-05.txt question: MIB in XML? References: Content-Type: multipart/mixed; boundary="------------69346C5FC5979537A7FF3EE3" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------69346C5FC5979537A7FF3EE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Baugher, Mark" wrote: > > Don > I don't think this is within the scope of the RTP MIB. > There is a list for general discussion of MIB-related > issues at mibs-request@ops.ietf.org - though I'm not > sure it is an SMI or SNMP issue, properly considered > > Mark Thanks for the redirect, very helpful. Though not sure if we have time to go there yet... Someday. If anyone is interested, read on, otherwise hit D now. :) To provide at least a clue about what we're looking at, here are Francisco's document type definition (.dtd) and example recording files, including one marked up in XML that complies with the dtd. So it is a verbose but rigorous data-recording format that has lots of benefits regarding correctness, tools etc. Caveat: this is probably pretty buggy stuff, though it does pass XML well-formed & validity checks. So far, manually created. More XML info available at http://www.w3.org/XML/ Caveat 2: be careful diving in, we haven't found the bottom yet! > > -----Original Message----- > > From: Don Brutzman [mailto:brutzman@nps.navy.mil] > > Sent: Tuesday, May 18, 1999 3:00 PM > > To: AVT working group > > Subject: draft-ietf-avt-mib-05.txt question: MIB in XML? > > > > > > Apologies if this question is out of scope for the group, > > redirects welcome. > > > > We are beginning to record RTP statistics and are considering XML tags > > for the data format. Does anyone know of work being done > > that might map > > MIB entities to an XML document type definition (DTD)? > > > > Looking downstream: should there be an XML DTD as part of the AVT MIB > > so that such tags are well specified and easily available? > > > > all the best, Don > > -- > > Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 > > work 831.656.2149 > > Monterey California 93943-5000 USA > > fax 831.656.3679 > > Virtual worlds/underwater robots/Internet > > http://web.nps.navy.mil/~brutzman > > -- all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 831.656.2149 Monterey California 93943-5000 USA fax 831.656.3679 Virtual worlds/underwater robots/Internet http://web.nps.navy.mil/~brutzman --------------69346C5FC5979537A7FF3EE3 Content-Type: application/x-unknown-content-type-PFE32; name="RTPMonitor.dtd" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="RTPMonitor.dtd" PCEtLSA8IURPQ1RZUEUgU3RhdCBbIC0tPg0KPCFFTEVNRU5UIFN0YXQgKFJlcG9ydCopID4N CjwhRUxFTUVOVCBSZXBvcnQgKFRpbWUsIFNlc3Npb25UYWJsZSwgU2VuZGVyVGFibGUqLCBS Y3ZyVGFibGUqICkgPg0KPCFFTEVNRU5UIFNlc3Npb25UYWJsZSAoIFRvdGFsUGFydGljaXBh bnRzLCBSZW1vdGVQYXJ0aWNpcGFudHMsIEFjdGl2ZVBhcnRpY2lwYW50cywNCiAgICAgICAg ICAgICAgICAgICAgICAgICBUb3RhbEJ5dGVzUmVjZCwgVG90YWxQYWNrZXRzUmVjZCwgUlRD UFBhY2tldHNSZWNkLCBTUlBhY2tldHNSZWNkLCAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgQmFkUlRQUGFja2V0cywgQmFkUlRDUFBhY2tldHMsIE1hbGZvcm1lZFNSLCBNYWxmb3Jt ZWRSUiwgDQogICAgICAgICAgICAgICAgICAgICAgICAgTWFsZm9ybWVkU0RFUywgTWFsZm9y bWVkQllFLCBMb2NhbENvbGxpc2lvbnMsIFJlbW90ZUNvbGxpc2lvbnMsDQogICAgICAgICAg ICAgICAgICAgICAgICAgUGFja2V0c0xvb3BlZCwgRmFpbGVkVHJhbnNtaXNzaW9uLCBVbmtu b3duUlRDUFR5cGUgKSA+DQo8IUVMRU1FTlQgU2VuZGVyVGFibGUgICggU2VuZGVyQ05BTUUs IFNlbmRlclNTUkMsIExvc3RQRFUsIFByb2Nlc3NlZFBEVSwNCiAgICAgICAgICAgICAgICAg ICAgICAgICBNaXNvcmRlcmVkUERVLCBJbnZhbGlkUERVLCBEdXBsaWNhdGVQRFUgKSA+DQo8 IUVMRU1FTlQgUmN2clRhYmxlICAgICggUmN2ckNOQU1FLCBSY3ZyU1NSQywgUmN2clNSQ1NT UkMsIFJjdnJGcmFjdGlvbkxvc3QsDQogICAgICAgICAgICAgICAgICAgICAgICAgUmN2ckxv c3RQYWNrZXRzLCBSY3ZySml0dGVyICkgPg0KPCFFTEVNRU5UIFRpbWUgICAgICAgICAgICAg ICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFRvdGFsUGFydGljaXBhbnRzICAoI1BDREFUQSkg Pg0KPCFFTEVNRU5UIFJlbW90ZVBhcnRpY2lwYW50cyAoI1BDREFUQSkgPg0KPCFFTEVNRU5U IEFjdGl2ZVBhcnRpY2lwYW50cyAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFRvdGFsQnl0ZXNS ZWNkICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFRvdGFsUGFja2V0c1JlY2QgICAoI1BD REFUQSkgPg0KPCFFTEVNRU5UIFJUQ1BQYWNrZXRzUmVjZCAgICAoI1BDREFUQSkgPg0KPCFF TEVNRU5UIFNSUGFja2V0c1JlY2QgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIEJhZFJU UFBhY2tldHMgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIEJhZFJUQ1BQYWNrZXRzICAg ICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIE1hbGZvcm1lZFNSICAgICAgICAoI1BDREFUQSkg Pg0KPCFFTEVNRU5UIE1hbGZvcm1lZFJSICAgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5U IE1hbGZvcm1lZFNERVMgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIE1hbGZvcm1lZEJZ RSAgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIExvY2FsQ29sbGlzaW9ucyAgICAoI1BD REFUQSkgPg0KPCFFTEVNRU5UIFJlbW90ZUNvbGxpc2lvbnMgICAoI1BDREFUQSkgPg0KPCFF TEVNRU5UIFBhY2tldHNMb29wZWQgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIEZhaWxl ZFRyYW5zbWlzc2lvbiAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFVua25vd25SVENQVHlwZSAg ICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFNlbmRlckNOQU1FICAgICAgICAoI1BDREFUQSkg Pg0KPCFFTEVNRU5UIFNlbmRlclNTUkMgICAgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5U IExvc3RQRFUgICAgICAgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFByb2Nlc3NlZFBE VSAgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIE1pc29yZGVyZWRQRFUgICAgICAoI1BD REFUQSkgPg0KPCFFTEVNRU5UIEludmFsaWRQRFUgICAgICAgICAoI1BDREFUQSkgPg0KPCFF TEVNRU5UIER1cGxpY2F0ZVBEVSAgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFJjdnJD TkFNRSAgICAgICAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFJjdnJTU1JDICAgICAgICAg ICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFJjdnJTUkNTU1JDICAgICAgICAoI1BDREFUQSkg Pg0KPCFFTEVNRU5UIFJjdnJGcmFjdGlvbkxvc3QgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5U IFJjdnJMb3N0UGFja2V0cyAgICAoI1BDREFUQSkgPg0KPCFFTEVNRU5UIFJjdnJKaXR0ZXIg ICAgICAgICAoI1BDREFUQSkgPg0KPCEtLSBdID4gLS0+DQoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQo= --------------69346C5FC5979537A7FF3EE3 Content-Type: text/xml; charset=us-ascii; name="statLastReport.xml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="statLastReport.xml" 2 1 1 132986 494 122 73 0 0 0 0 0 0 0 0 0 0 0 brutzman@131.120.178.33 389773164 0 372 0 0 0 RTPMonitor@nps.navy.mil 3817614594 389773164 0.0 0 308 brutzman@131.120.178.33 389773164 389773164 0.0 1 0 --------------69346C5FC5979537A7FF3EE3 Content-Type: text/plain; charset=us-ascii; name="statLastReportOld.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="statLastReportOld.txt" D1 15:08:08 2 1 1 127707 337 71 42 0 0 0 0 0 0 0 0 0 0 0 D2 brutzman@131.120.178.33 389773164 0 266 0 0 0 D3 RTPMonitor@nps.navy.mil -1771064803 389773164 0.0 0 824 D3 brutzman@131.120.178.33 389773164 389773164 0.0 1 0 --------------69346C5FC5979537A7FF3EE3-- From rem-conf Wed Jun 02 11:38:53 1999 From rem-conf-request@es.net Wed Jun 02 11:38:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pFn2-0006Lr-00; Wed, 2 Jun 1999 11:31:00 -0700 Received: from salamander.eu.fore.com [193.132.138.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 10pFn0-0006KY-00; Wed, 2 Jun 1999 11:30:59 -0700 Received: from fore.com (grass.fore.com [169.144.86.175]) by salamander.eu.fore.com (8.9.1/8.9.1) with ESMTP id TAA08073 for ; Wed, 2 Jun 1999 19:25:04 +0100 (BST) Message-ID: <375577FF.E549F633@fore.com> Date: Wed, 02 Jun 1999 14:29:20 -0400 From: Kamalanand Dasu Organization: Wipro Infotech X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: vic vat and ttl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am running vic v2.7b4 and vat v4.0b2 on NT 4.0. I am having a problem in changing the ttl parameter. No matter waht ttl I specify the multicast packet goes out with the ttl=1. Is this a problem related to this version or am I missing something. I need to multicast accross subets. -Kamal From rem-conf Thu Jun 03 01:03:59 1999 From rem-conf-request@es.net Thu Jun 03 01:03:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pSOi-0003rn-00; Thu, 3 Jun 1999 00:58:44 -0700 Received: from pif.inria.fr [138.96.24.64] (turletti) by mail1.es.net with esmtp (Exim 1.81 #2) id 10pSOh-0003rd-00; Thu, 3 Jun 1999 00:58:43 -0700 Received: from pif.inria.fr by pif.inria.fr (8.8.8/8.8.5) with ESMTP id JAA15126; Thu, 3 Jun 1999 09:58:39 +0200 (MET DST) Message-Id: <199906030758.JAA15126@pif.inria.fr> X-Mailer: exmh version 2.0.2 2/24/98 To: "A. Tawfik" Cc: rem-conf@es.net Subject: Re: RTCP usability In-reply-to: atawfik's message of Wed, 02 Jun 1999 23:59:31 -0300. <199906030259.XAA22219@sun6.math.upei.ca.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jun 1999 09:58:39 +0200 From: Thierry Turletti X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I have a question regarding the MBone IVS application. IVS uses RTP and RTCP. I > have read the article about scalable feedback in IVS by Bolot et al. The article > does not mention RTCP but rather mentions that the salability is done via > probing and the sender elicits feedback from the receivers. These things are not > done by RTCP, so how does IVS use RTCP? IVS is a videoconferencing tool developed a long time ago (first version released in 1992). Firsts versions of IVS used "regular" version 1 of RTCP packets to report back loss rate from the receivers and adapt the coder rate to the network state (see "Videoconferencing on the internet" appeared in ToN, June 1996). The paper you mention (I suppose appeared on Sigcomm'94), describes a "new" experimental feedback control mechanism based on the Ian Wakeman's probing mechanism and implemented in the final version of IVS released around 1995. This scheme use RTCPv1 options to transmit the non-standard information required to estimate for example the number of receivers or the state of the network. > > The second question is related to sender based adaptive application. Which of > the MBone tools: VAT, IVS, NS, NeVoT, RAT use sender based rate adaptive schemes > and if they use the sender based adaptive schemes, do they use RTCP in that? > I don't think that any of VAT, NV, VIC, NeVoT or RAT audio/video conferencing tools use adaptive rate control schemes. IVS uses a sender-based congestion control scheme but the point with such source-based schemes is that they don't handle receiver/network heterogeneity, i.e they can only adapt to the worst receiver or a percentage of congested receivers. To optimize the transmission and satisfy all receivers, hierarchical coding and receiver-based schemes could be efficient (such as RLM developed by Steve McCanne) but unluckily we are still waiting for the corresponding VIC version... Note that putting some intelligence in some routers could also represent an alternative to sender/receiver -based congestion control schemes. Thierry From rem-conf Thu Jun 03 02:03:58 1999 From rem-conf-request@es.net Thu Jun 03 02:03:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pTNw-0004ur-00; Thu, 3 Jun 1999 02:02:00 -0700 Received: from server34a.aitcom.net (ensim.com) [208.234.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 10pTNv-0004uh-00; Thu, 3 Jun 1999 02:01:59 -0700 Received: from ensim.com ([170.1.220.2]) by ensim.com (8.8.8/8.8.5) with ESMTP id FAA15319; Thu, 3 Jun 1999 05:01:55 -0400 Message-ID: <37564586.776F129D@ensim.com> Date: Thu, 03 Jun 1999 02:06:14 -0700 From: Jean Bolot Organization: Ensim X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "A. Tawfik" CC: rem-conf@es.net Subject: Re: RTCP usability References: <199906030259.XAA22219@sun6.math.upei.ca.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "A. Tawfik" wrote: > I have a question regarding the MBone IVS application. IVS uses RTP and RTCP. I > have read the article about scalable feedback in IVS by Bolot et al. The article > does not mention RTCP but rather mentions that the salability is done via > probing and the sender elicits feedback from the receivers. These things are not > done by RTCP, so how does IVS use RTCP? Work on IVS stopped about 3 years ago, and the work you mention took place during the transition of what were then RTPv1 and RTPv2, when one question was whether to use unicast or multicast feedback. So IVS is not the best MBone tool to get a good feel for recent uses of RTCP.... Refer instead to vic or to RendezVous, the successor of IVS at Inria. > The second question is related to sender based adaptive application. Which of > the MBone tools: VAT, IVS, NS, NeVoT, RAT use sender based rate adaptive schemes > and if they use the sender based adaptive schemes, do they use RTCP in that? Of those, I know RAT uses it (as well as Inria's FreePhone tool). We use a TCP-friendly scheme in FreePhone, actually a joint rate/error control scheme. Refer for our recent paper at Infocom for more details ftp://ftp-sop.inria.fr/rodeo/bolot/99.Audio_fec.ps.gz -Jean ------------------------------------------------------------- Jean Bolot, Ensim Corp. Ensim - enabling shared outsourcing of network services From rem-conf Thu Jun 03 03:52:19 1999 From rem-conf-request@es.net Thu Jun 03 03:52:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pV3z-0006D4-00; Thu, 3 Jun 1999 03:49:31 -0700 Received: from dxmint.cern.ch [137.138.26.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 10pV3x-0006Cr-00; Thu, 3 Jun 1999 03:49:30 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch (8.9.3/8.9.3) with SMTP id MAA18356 for ; Thu, 3 Jun 1999 12:48:28 +0200 (MET DST) Received: by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA07876; Thu, 3 Jun 1999 12:48:27 +0200 Message-Id: <199906031048.AA07876@dxcoms.cern.ch> Subject: CERN MBone Announcement: Next ATLAS Plenary Sessions To: rem-conf@es.net (List Mbone-WW) Date: Thu, 3 Jun 1999 12:48:27 +0200 (MET DST) From: "Daniel Davids CERN/CN" X-Mailer: ELM [version 2.4 PL25] 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 CERN is pleased to announce the MBONE broadcast of the ATLAS Physics Plenary Sessions ============================== 8-11 June 1999 Place: CERN Council Chamber and Main Auditorium *** Times are UTC+2 *** Tuesday Afternoon ================= 8 June 1999 14h00 - 17h30 ATLAS Physics Plenary Salle de Conseil Wednesday Whole Day =================== 9 June 1999 09h00 - 17h30 ATLAS Plenary Main Auditorium Thursday Whole Day ================== 10 June 1999 09h00 - 17h30 ATLAS Plenary Main Auditorium Friday Morning ============== 11 June 1999 09h00 - 12h30 ATLAS Plenary Main Auditorium The MBONE Broadcast is Announced via 'sdr' as "CERN ATLAS" The 'vat'&'vic' Applications will be Used with a 'ttl=127' The Sessions will also be Recorded Using the 'wrtp' Application. They can be Downloaded from: "http://sunmed2.cern.ch/cgi-bin/nph-MBone-sessions/" In Case of Questions or Problems Please Contact: "multicast@noc.cern.ch" From rem-conf Thu Jun 03 06:55:00 1999 From rem-conf-request@es.net Thu Jun 03 06:54:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pXtD-0000R7-00; Thu, 3 Jun 1999 06:50:35 -0700 Received: from cepheid.physics.gla.ac.uk [130.209.45.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 10pXtB-0000Qv-00; Thu, 3 Jun 1999 06:50:33 -0700 Received: from a5.ph.gla.ac.uk (a5.ph.gla.ac.uk [130.209.45.103] (may be forged)) by cepheid.physics.gla.ac.uk (8.9.1/8.9.1) with ESMTP id OAA05150; Thu, 3 Jun 1999 14:50:23 +0100 (BST) Received: from localhost (flavell@localhost) by a5.ph.gla.ac.uk (8.8.8/8.8.8) with ESMTP id OAA18046; Thu, 3 Jun 1999 14:50:21 +0100 (BST) Date: Thu, 3 Jun 1999 14:50:20 +0100 (BST) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: Daniel Davids CERN/CN cc: List Mbone-WW Subject: Re: CERN MBone Announcement: Next ATLAS Plenary Sessions In-Reply-To: <199906031048.AA07876@dxcoms.cern.ch> Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 3 Jun 1999, Daniel Davids CERN/CN wrote: > CERN is pleased to announce the MBONE broadcast of the > > ATLAS Physics Plenary Sessions > ============================== > 8-11 June 1999 Friends, Once again it is clear that the sdr packets announcing this session are going missing. I've reported this to CERN on a number of recent occasions and they, and SWITCH, have clearly had a good look, but as yet it seems the problem is not resolved. This means that although the recent sessions themselves have been very good as received here in Glasgow, I have had to start the apps manually by picking up the session parameters from UCSB: http://imj.ucsb.edu/sdr-monitor/ where we currently see that although advertised with ttl 127, only five of the contributing sites have in fact received the announcement. I hope CERN, and Simon at SWITCH, won't resent me going "public" on this, but if anyone can suggest what's going wrong here, I for one would be very grateful. On this occasion I've been running mtrace for a while, and the problematical part of the path is this: 192.65.185.100 mbone-cern.switch.ch | ^ ttl 51 51 pps 1/1 = -- 0 pps v | hop 4 ms 51 pps 1/1 = -- 0 pps 212.1.193.130 ch-ws.ten-155.net | ^ ttl 52 51 pps 0/0 = -- 0 pps v | hop 9 ms 51 pps 0/0 = -- 0 pps 212.1.193.233 212.1.193.35 ws1.de.ten-155.net | ^ ttl 53 526 pps 0/0 = -- 0 pps On recent studies, almost all of the packets go missing on the leg >from mbone-cern.switch.ch; today I can see that one packet managed to get past ch-ws.ten-155.net, but then got dropped at the next leg. None of them have reached me. I gather that before I started looking, one of them must have reached dap@aber.ac.uk, who is on the UCSB list. best regards From rem-conf Thu Jun 03 10:40:07 1999 From rem-conf-request@es.net Thu Jun 03 10:40:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pbP0-00047U-00; Thu, 3 Jun 1999 10:35:38 -0700 Received: from mail.nps.navy.mil [131.120.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 10pbOy-00047K-00; Thu, 3 Jun 1999 10:35:37 -0700 Received: from cs.nps.navy.mil (slippc10.cs.nps.navy.mil [131.120.1.180]) by mail.nps.navy.mil (8.9.3/8.9.3) with ESMTP id KAA19625; Thu, 3 Jun 1999 10:36:54 -0700 (PDT) Message-ID: <3756BCAA.1FE304AE@cs.nps.navy.mil> Date: Thu, 03 Jun 1999 10:34:35 -0700 From: Francisco Afonso X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf , jmf CC: brutzman Subject: RTP MIB implementation with JMF Content-Type: multipart/mixed; boundary="------------3066EA5CF36C6A1836E68F74" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------3066EA5CF36C6A1836E68F74 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are sending a comparison between RTP MIB fields, as proposed in the Internet Draft, and the set of RTP Statistics provided by Sun's Java Media Framework (JMF). It would be great if JMF could provide all necessary fields for creating an RTP MIB application. On the other side, some JMF statistics are good candidates for joining the RTP MIB draft. Comments will be welcome. --------------3066EA5CF36C6A1836E68F74 Content-Type: text/html; charset=iso-8859-1; name="MIBvsJMF.htm" Content-Disposition: inline; filename="MIBvsJMF.htm" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.nps.navy.mil id KAA19625 RTP MIB vs JMF
RTP MIB implementation using Java Media Framew= ork(JMF 2.0)
2 Jun 99
Francisco Afonso (afonso@n= ps.navy.mil) & Don Brutzman (brutzman@nps= .navy.mil)
Naval Postgraduate School
Monterey, California USA

1. Overview and References

This document compares the attributes of the Management Information Base (MIB), defined for managing Real-Time Transport Protocol (RTP) systems, with the existing Java Media Framework set of RTP statistics used by the RTPMonitor.

The RTP MIB is defined in the document "Real-Time Transport Protocol Management Information Base", dated April 12th 1999. It can be found in following URL:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-05.= txt

Java Media Framework (JMF) is a product of SUN and other companies lik= e IBM. The current version is 1.1, but version 2.0 has already been release= d in its early version. Version 1.1 allows only media playback and RTP rece= ption, while version 2.0 provides media capture and RTP transmission. It can be downloaded from the following URL:

http://www.javasoft.com/products/java-media/jmf/index.html

RTPMonitor is a Java application developed by Naval Postgraduate Schoo= l as part of the DIS-Java-VRML and VRTP project= s. It was implemented using Java Media Framework (JMF) version 2.0, and it has the following capabilities:

- presents global session statistics, individual stream statistics and feedback from all participants;
- records the statistics in text files, continuously, in intervals defined by the user;
- plays the received streams (audio and video); and
- participates in the session by sending RTCP packets, if desired. 2. Comparison RTP MIB versus JMF 2.0-based RTPMonitor

RTP MIB was designed for being used with SNMP. The RTP agents running this MIB can be either RTP hosts (end systems) or RTP Monitors. The objec= tive is to collect statistical data about RTP sessions and its streams, for diagnostics and management purposes. Each agent maintains a MIB that can be queried by a Manager. Only the last updated statistic is stored in the MIB.

RTP MIB has basically three tables:

    • a Session Table, that stores general information about each session being monitored;
    • a Sender Table, that stores information about each stream being sent;
    • a Receiver Table, that stores feedback information from receivers about senders.
RTPMonitor is an application that collects RTP statistics and stores them on files for later analysis. It is supposed to store data periodically over the whole duration of the session. The default interval between samp= les is 30 seconds.

RTPMonitor collects three types of data:

    • global statistics: about the whole session (most from class GlobalRecepti= onStats in JMF )
    • stream statistics: about each stream ( most from class RTPReceptionStats in JMF)
    • feedback statistics: about each RR packet ( most from class RTCPFeedback in JMF).
The following tables compare the fields in RTP MIB with the ones in RTPMo= nitor. A comment is provided for each RTP MIB field not implemented in RTPMonito= r. Some MIB fields can not be implemented by RTPMonitor because JMF does not provide such capability.
 

SessionTable
 

RTP MIB
JMF-based RTP Monitor Application
Comments
SessionIndex ( Integer32) =96 an index of the concept= ual row which is for SNMP purposes only and has no relation with any protocol value.
Not applicable.
-
SessionDomain ( TDomain ) =96 the transport layer pro= tocol used for sending or receiving the stream of RTP packets in this session.<= /font>
Not implemented.
 It can be added. 
JMF uses UDP as the transport protocol. Extensibility to other protocols is possible, but not provided. 
SessionRemAddr (Taddress ) =96 the remote destination= transport address on which the RTP data packet is sent and/or received.
Not implemented.
 It can be added. 
In RTP Monitor the session transport address names th= e directory where the files are created and updated.
e.g. session224.2.2.2port44444
SessionLocAddr (Taddress) =96 the local destination t= ransport address on which the stream of data packet is being sent and/or received.=
Not implemented.
 It can be added. 
SessionIfIndex ( InterfaceIndex) =96 this value is se= t to the corresponding value from the Internet Standard MIB. This is the interface that the RTPStream is being sent to or received from.
Not applicable.
-
SessionSenderJoins (Counter32) =96 the number of send= ers that have been observed joined the session since SessionStartTime ( see below).
Not implemented.
 Not part of native JMF statistics. It can be derived in an JMF application by monitoring NewRecvStreamEvents.
SessionReceiverJoins(Counter32) - the number of recei= vers that have been observed joined the session since SessionStartTime &n= bsp;     (see below).
Not implemented.
 Not part of native JMF statistics. It can be derived in an JMF application by searching for new participants in the list of participants managed by RTPSessionManager.
SessionByes (Counter32) =96 a count of RTCP BYE.
Not implemented.
 Not part of native JMF statistics. It can be derived in an JMF application by monitoring ByeEvents.
SessionStartTime (TimeStamp) =96 the value of SysUpTi= me at the time that this row is created.
Not implemented.
 That is the time when the Session Monitoring starts. It can be added to RTPMonitor.
SessionMonitor (ThuthValue) =96 set to true if sender= or receivers in addition to the local RTP System are to be monitored.=
Not applicable.
 In RTPMonitor it is always true.
SessionRowStatus (RowStatus) =96 active when RTP/RTCP= Messages are being sent or received by an RTPSystem. If this row is "notInService" it may be removed after 5 minutes.
Not implemented.
 It can be implemented in RTP Monitor, but without rem= ovals.
Not provided by MIB.
 Time ( hh:mm:ss) =96 time of the report. Needed. Implicit in SNMP?
Not provided by MIB.
 TotalParticipants (int) =96 the total number of parti= cipants attending the session.  Needed. Equals active + passive participants and also remote + local.
Not provided by MIB.
 RemoteParticipants(int) =96 the number of remote part= icipants attending the session. Desirable.
Not provided by MIB.
 ActiveParticipants (int) =96 the number of active par= ticipants (senders) attending the session. Needed.
Not provided by MIB.
 TotalBytesRecd (int) =96 the number of bytes received= in the session, before any validation. Needed for bandwidth calculations.
Not provided by MIB.
 TotalPacketsRecd (int) =96 the total number of RTP an= d RTCP packets received in the session before any packet validation. <= /font>  Needed for comparison of bandwidth versus packe= ts per second performance.
Not provided by MIB.
 RTCPPacketsRecd (int ) =96 the total number of RTCP p= ackets received in the session before any header validation. Desirable.
Not provided by MIB.
 SRPacketsRecd (int) =96 the total number of sender re= ports received in the session.  Desirable.
Not provided by MIB.
 BadRTPPackets (int) =96 the total number of RTP data = packets that failed the RTP header validation check. Desirable.
Not provided by MIB.
 BadRTCPPackets (int) =96 the total number of RTCP pac= kets that failed the RTCP header validation check. Desirable.
Not provided by MIB.
 MalformedSR (int) =96 the total number of invalid sen= der reports due to length inconsistency. Desirable.
Not provided by MIB.
 MalformedRR (int) =96 the total number of invalid rec= eiver reports due to length inconsistency. Desirable.
Not provided by MIB.
 MalformedSDES (int) =96 the total number of invalid S= DES packets due to length inconsistency. Desirable.
Not provided by MIB.
 MalformedBYE (int) =96 the total number of invalid BY= E packets due to length inconsistency. Desirable.
Not provided by MIB.
 LocalCollisions (int) =96 the total number of local c= ollisions (SSRC collisions).  Desirable.
Not provided by MIB.
 RemoteCollisions (int) =96 the total number of remote= collisions (SSRC collisions). Desirable.
Not provided by MIB.
 PacketsLooped (int) =96 the total number of packets l= ooped. Desirable.
Not provided by MIB.
 FailedTransmission (int) =96 the number of packets th= at failed to get transmitted. Desirable.
Not provided by MIB.
 UnknownRTCPType (int) =96 the number of individual RT= CP packets types that were not implemented or not recognized. Desirable.

SenderTable

RTP MIB
JMF-based RTP Monitor Application
Comments
SenderSSRC (Unsigned32) =96 the sender synchronizatio= n source identifier. SenderSSRC (long) Slight type mismatch, but workable.
SenderCNAME (DisplayString) =96 the canonical name of= the sender. SenderCNAME (String )
-
SenderAddress ( Taddress) =96 the unicast transport s= ource address of the sender.
Not provide by JMF.
-
SenderPackets ( Counter64) =96 count of RTP packets s= ent by this sender, or observed by an RTP Monitor, since SenderStartTime. SenderPackets (int) Called ProcessedPDU by JMF =96 number of valid packet= s received from the selected source. Possible type issue. It can overflow.<= /font>
SenderOctets (Counter64) =96 count of RTP octets sent= by this sender or observed by an RTP Monitor, since SenderStartTime.<= /td>
Not provided by JMF.
 JMF only has a corresponding session count.
SenderTool (DisplayString) =96 Name of the applicatio= n program source of the stream.
Not implemented.
 It can be read from JMF RTPSourceDescription object.<= /font>
SRs (Counter32) =96 a counter of the number of RTCP S= ender Reports that have been sent from this sender or observed if the RTP entit= y is a monitor, since SenderStartTime.
Not implemented.
 Not part of native JMF statistics. It can be derived in an JMF application by monitoring RecvSenderReportEvents.
SenderSRTime (TimeStamp) =96 the value of SysUpTime a= t the time that the last SR was received from this sender, in the case of a monitor or receiving host, or sent by this sender, in case of a sending host.
Not provided by JMF.
-
SenderPT ( integer 0..127) =96 static or dynamic payl= oad type from the RTP Header.
Not provided by JMF.
-
SenderStartTime (TimeStamp) =96 the value of SysUpTim= e at the time this row was created.
Not implemented.
 It is the time when the Monitor detected this source. It can be derived by the JMF application.
Not provided by MIB.
 LostPDU (int) =96 the difference between the number o= f packets expected as determined by the RTP sequence number range and the count of packets actually received and validated. Desirable.
Not provided by MIB.
 MisorderedPDU (int) =96 the total number of data pack= ets that came in out of order as per the RTP sequence number. Desirable.
Not provided by MIB.
 InvalidPDU (int) =96 the total number of RTP data pac= kets that have failed to be within an acceptable sequence number range for an established SSRC id. Desirable.
Not provided by MIB.
 DuplicatePDU (int) =96 the total number of RTP data p= ackets that match the sequence number of another already in the input queue. Desirable.

RcvrTable
 
RTP MIB
JMF-based RTP Monitor Application
Comments
RcvrSRCSSRC (Unsigned32) =96 the SSRC of the sender.<= /font> RcvrSRCSSRC (long)  Type issue.
RcvrSSRC (Unsigned32) =96 the SSRC of the receiver. RcvrSSRC (long ) Type issue.
RcvrCNAME (DisplayString) =96 the canonical name of t= he receiver.  RcvrCNAME (String)
-
RcvrAddr (Taddress) =96 the unicast transport address= of the receiver.
Not implemented.
 It can be added.
RcvrRTT (Gauge32) =96 the round trip time measurement= taken by the source of the RTP stream.
Not provided by JMF.
 This value can only be calculated by senders after re= ceiving RTP feedback about their streams. JMF does not provide this statistic. This capability was requested was requested in the jmf-interest mailing list
RcvrLostPackets (Counter64) =96 a count of RTP packet= s lost as observed by this receiver. RcvrLostPackets (long)
-
RcvrJitter (Gauge32) =96 an estimate of delay variati= on as observed by this receiver. RcvrJitter (long ) Type issue.
RcvrTool (DisplayString) =96 the name of the applicat= ion program source of the stream.
Not implemented.
 It can be read from JMF RTPSourceDescription object.<= /font>
RRs (Counter32) =96 a count of the number of RTCP Rec= eiver Reports that have been sent from this receiver since RcvrStartTime.
Not implemented.
 Not part of native JMF statistics. It can be derived in an JMF application by monitoring RecvSenderReportEvents.
RcvrRRTime (TimeStamp) =96 the value of SysUpTime at = the last RTCP Receiver Report was received or sent (in case of the sender).
Not provided by JMF.
 JMF does not provide the time a feedback is received or sent. This capability was requested was requested in the jmf-interest mailing list.
RcvrPT (Integer) =96 static or dynamic payload type f= rom the RTP header.
Not provided by JMF.
-
RcvrPackets (Counter64) =96 count of RTP packets rece= ived by this RTP host since RcvrStartTime.
Not implemented.
 Called ProcessedPDU by JMF =96 number of valid packet= s received from the selected source. Same as SenderPackets in the SenderTab= le.
RcvOctets (Counter64) =96 count of RTP octets receive= d since RcvrStartTime.
Not implemented.
 Not provided by JMF. . Same as SenderOctets in the Se= nderTable.
RcvStartTime (TimeStamp) =96 the value of SysUpTime a= t the time that this row is created.
Not implemented.
 It can be added.

General comment: variable names used in JMF frequently do not match names proposed by the RTP MIB. A name correspondence table would be helpf= ul in JMF.
 

3. Conclusion

Perhaps all these respective design decisions in the draft RTP MIB and the new JMF 2.0 were made for conscious, deliberate reasons. Further work is needed on the MIB and the JMF to resolve these differences.
 
--------------3066EA5CF36C6A1836E68F74-- From rem-conf Thu Jun 03 11:27:32 1999 From rem-conf-request@es.net Thu Jun 03 11:27:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pcAf-0005A6-00; Thu, 3 Jun 1999 11:24:53 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 10pcAf-00059w-00; Thu, 3 Jun 1999 11:24:53 -0700 Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id LAA03830; Thu, 3 Jun 1999 11:24:15 -0700 (PDT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 3 Jun 1999 11:24:14 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB201362E36@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Francisco Afonso'" , rem-conf , jmf Cc: brutzman Subject: RE: RTP MIB implementation with JMF Date: Thu, 3 Jun 1999 11:24:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >From your session table 1)Not provided by MIB. Time ( hh:mm:ss) - time of the report. Needed. Implicit in SNMP? Time of the reports are in the sender/receiver report tables... 2)Not provided by MIB. TotalParticipants (int) - the total number of participants attending the session. Needed. Equals active + passive participants and also remote + local. We argued about whether we should track Sender/Receiver Joins/Byes, as a high watermark, a total count, or a current count. We decided on the counter. Depending on how you want to track "TotalParticipants" it very well may be rtpSessionSenderJoins+rtpSessionReceiverJoins. 3) Not provided by MIB. RemoteParticipants(int) - the number of remote participants attending the session. Desirable. Can simply be the count of receivers in the receiver table 4)Not provided by MIB. ActiveParticipants (int) - the number of active participants (senders) attending the session. Needed. See above 5) Not provided by MIB. TotalBytesRecd (int) - the number of bytes received in the session, before any validation. Needed for bandwidth calculations. rtpRcvrOctets in the receiver table. 6) Not provided by MIB. TotalPacketsRecd (int) - the total number of RTP and RTCP packets received in the session before any packet validation. Needed for comparison of bandwidth versus packets per second performance. rtpRcvrPackets in the receiver table 7) Not provided by MIB. RTCPPacketsRecd (int ) - the total number of RTCP packets received in the session before any header validation. Desirable. Combination of SR/RR counts out of the sender/receiver table. 8)Not provided by MIB. SRPacketsRecd (int) - the total number of sender reports received in the session. Desirable. rtpSenderSR from the sender table. 9) Not provided by MIB. BadRTPPackets (int) - the total number of RTP data packets that failed the RTP header validation check. Desirable. Not available in the MIB 10) Not provided by MIB. BadRTCPPackets (int) - the total number of RTCP packets that failed the RTCP header validation check. Desirable. Not available in the MIB 11) Not provided by MIB. MalformedSR (int) - the total number of invalid sender reports due to length inconsistency. Desirable. Not available in the MIB 12) Not provided by MIB. MalformedRR (int) - the total number of invalid receiver reports due to length inconsistency. Desirable. Not available in the MIB 13) Not provided by MIB. MalformedSDES (int) - the total number of invalid SDES packets due to length inconsistency. Desirable. 14) Not provided by MIB. MalformedBYE (int) - the total number of invalid BYE packets due to length inconsistency. Desirable. 15) Not provided by MIB. LocalCollisions (int) - the total number of local collisions (SSRC collisions). Desirable. 16) Not provided by MIB. RemoteCollisions (int) - the total number of remote collisions (SSRC collisions). Desirable. 17) Not provided by MIB. PacketsLooped (int) - the total number of packets looped. Desirable. 18 ) Not provided by MIB. FailedTransmission (int) - the number of packets that failed to get transmitted. Desirable. 19)Not provided by MIB. UnknownRTCPType (int) - the number of individual RTCP packets types that were not implemented or not recognized. Desirable. Not available in the MIB >From the Sender Table 20) Not provided by MIB. LostPDU (int) - the difference between the number of packets expected as determined by the RTP sequence number range and the count of packets actually received and validated. Desirable. RcvrLostPackets in the Receiver Table 21) Not provided by MIB. MisorderedPDU (int) - the total number of data packets that came in out of order as per the RTP sequence number. Desirable. Not availbe in the MIB... it would have to be in the rcvrTable 22) Not provided by MIB. InvalidPDU (int) - the total number of RTP data packets that have failed to be within an acceptable sequence number range for an established SSRC id. Desirable. Not available in the MIB... It would have to be in the RcvrTable 23) Not provided by MIB. DuplicatePDU (int) - the total number of RTP data packets that match the sequence number of another already in the input queue. Desirable. Not available in the MIB... it would have to be in the Rcvr Table >From these issues it looks like we handle many of them, not necissarily the same way that JMF does. Many of the things that are not included in the MIB are in the catagory of Protocol errors that we decided not to include because they add overhead to the management framework to track and are not necissarily useful in a fully compliant session. I think we can meet all of your "Needed" and many of your "Desired" requests with the current MIB. Bill -----Original Message----- From: Francisco Afonso [mailto:afonso@cs.nps.navy.mil] Sent: Thursday, June 03, 1999 10:35 AM To: rem-conf; jmf Cc: brutzman Subject: RTP MIB implementation with JMF We are sending a comparison between RTP MIB fields, as proposed in the Internet Draft, and the set of RTP Statistics provided by Sun's Java Media Framework (JMF). It would be great if JMF could provide all necessary fields for creating an RTP MIB application. On the other side, some JMF statistics are good candidates for joining the RTP MIB draft. Comments will be welcome. From rem-conf Thu Jun 03 13:01:20 1999 From rem-conf-request@es.net Thu Jun 03 13:01:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10pdce-0006lg-00; Thu, 3 Jun 1999 12:57:52 -0700 Received: from ctral1.vanderbilt.edu [129.59.1.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 10pdcd-0006lW-00; Thu, 3 Jun 1999 12:57:51 -0700 Received: from ci39026-a (ci39026-a.nash1.tn.home.com) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #U3177) with SMTP id <01JBXCM6GO6A8WWLEK@ctrvax.Vanderbilt.Edu> for rem-conf@es.net; Wed, 2 Jun 1999 13:25:46 CDT Date: Wed, 02 Jun 1999 12:44:33 -0500 From: Bezalel Gavish Subject: CFPs ICTEC 99 X-Sender: gavishb@ctrvax.vanderbilt.edu To: (Recipient list suppressed) Message-id: <01JBXCMFCWKK8WWLEK@ctrvax.Vanderbilt.Edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: multipart/mixed; boundary="=====================_928363473==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_928363473==_ Content-Type: text/plain; charset="us-ascii" Enclosed is the Call for Papers for the Second International Conference on Telecommunications and Electronic Commerce. I look forward to receive your contribution Sincerely yours, Bezalel Gavish PS You may receive multiple copies of this message. The reason for it is that you appear on multiple mailing lists. --=====================_928363473==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ICTEC99 cfp1.txt" In response to several requests, the submission deadline for ICTEC99 has been extended to June 15, 1999. Please note that this is a hard deadline. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CALL FOR PAPERS and PANELS Second International Conference on Telecommunications and Electronic Commerce (ICTEC) Nashville, USA, October 6-8, 1999 http://munin.utdallas.edu/atsma/ictec Topics of interest for the conference include (but are not limited to) the following: * Impact of TEC on supply chain, distribution chain management, EDI and IOS * Secure transaction processing methods for EC * The impact of mobility on EC mechanisms * Internet traffic management and analysis * Pricing Internet services * TEC market mechanisms and business models * TEC intermediary roles and their analysis * Electronic payment mechanisms * Economics of TEC * Design and analysis of intranets and extranets * Web Data management * Managing Web-based information services * Effective management of EC transaction servers * Workflow Management issues in TEC * EC developments and challenges in specific industries * Globalization and policy issues in TEC (standards, regulation, property rights, etc.) SUBMISSIONS: Authors should submit an extended abstract of at least 2000 words, or a complete paper, by May 15, 1999 (June 15, 1999). Proposals for panels are also invited. Three hard-copies should be submitted, to an appropriate Regional Coordinator. Electronic submissions are welcome, but must be augmented with at least one hard-copy. Authors of accepted papers will be asked to submit their complete manuscripts to the Conference Manager, Ms. Dru Lundeng, by August 31, 1999 for inclusion in the conference proceedings. Conference Chair: Bezalel Gavish, Vanderbilt University, Nashville, USA Program Committee (Regional Coordinators) EUROPE and AFRICA Asuman Dogac Software R&D Department of Computer Eng. Middle East Tech. Univ. Ankara, Turkey asuman@srdc.metu.edu.tr Eric van Heck School of Management Erasmus University Rotterdam The Netherlands e.heck@fac.fbk.eur.nl Timo Saarinen Helsinki School of Economics Runeberginkatu 14-16 Helsinki FIN-00100 06531 Finland saarinen@hkkk.fi AUSTRALIA and NEW ZEALAND Tony Eyers Dept. of Computer Engg. Univ. of Wollongong Wollongong NSW 2522, Australia tony@elec.uow.edu.au Robyn Lindley School of IT & Computer Science Univ. of Wollongong Wollongong NSW 2522, Australia robyn_lindley@uow.edu.au Ananth Srinivasan Commerce C 512 University of Auckland Private Bag 92019 Auckland, New Zealand a.srinivasan@auckland.ac.nz ASIA Robert Blanning Dept. of Information Systems Univ. of Science and Technology Clear Water Bay, Kowloon, Hong Kong Blannirw@ust.hk Norihisa Komoda Dept. of I.S. Engg. Osaka University Yamadaoka 2-1, Osaka 565-0871, Japan komoda@ise.eng.osaka-u.ac.jp James C. Westland Dept. of Information Systems Univ. of Science and Technology Clear Water Bay, Kowloon, Hong Kong westland@ust.hk NORTH AMERICA and ALL OTHER REGIONS Amit Basu Owen Grad. School of Mgt. Vanderbilt University Nashville, TN 37203, USA Amit.Basu@owen.vanderbilt.edu Ramayya Krishnan Heinz School of Public Policy & Mgt. Carnegie Mellon University Pittsburgh, PA 15215, USA rk2x@cmu.edu Industry Panels and Plenaries Industry Canada Prabir Neogi 300 Slater Street Ottawa, Ont., Canada, K1A 0C8 Neogi.Prabir@ic.gc.ca PROGRAM COMMITTEE MEMBERS Abdullah Al-Dhelaan, King Saud U., Saudi Arabia Kemal Altinkemer, Purdue U., USA Israel Ben-Shaul, Technion, Israel Martin Bichler, U. of Vienna, Austria Imrich Chlamtac, U. T. Dallas, USA H. Michael Chung, Cal State U., USA Anindya Datta, Georgia Tech., USA Amitava Dutta, George Mason U., USA Soumitra Dutta, INSEAD, France Stuart Feldman, IBM Corp., USA Erol Gelenbe, Duke U., USA Sigmund Handelman, IBM Corp., USA Joakim Kalvenes, U.T. Dallas, USA Ajit Kambil, New York U., USA Kalevi Kilkki, Nokia Corp., Finland Wolfgang Klas, U. of Ulm, Germany Akhil Kumar, U. of Colorado, USA Ronald Lee, Erasmus U., Netherlands Ting-Peng Liang, Sun Yat-Sen U., Tiawan Alberto Mendelzon, U. of Toronto, Canada Juzar Motiwalla, Nat. U. of Singapore Rajat Mukherjee, IBM Corp., USA Richard W. Oliver, Vanderbilt U., USA Hasan Pirkul, U. T. Dallas, USA Sara Porat, IBM Corp., Israel Louiqa Raschid, U. of Md., USA Aviel Rubin, AT&T Corp., USA Arie Segev, U.C. Berkeley, USA Avi Silberschatz, Bell Labs., USA Jacob Slonim, Dalhousie U., Canada Sang Son, U. Va., USA Kar Yan Tam, U.S.T., Hong Kong Doug Tygar, UC Berkeley, USA Andrew Whinston, U.T. Austin, USA Chee Sing Yap, Multimedia Dev. Corp., Malaysia Leon Zhao, U.S.T., Hong Kong --=====================_928363473==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 USA Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu --=====================_928363473==_-- From rem-conf Fri Jun 04 13:54:50 1999 From rem-conf-request@es.net Fri Jun 04 13:54:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10q0pE-0004xU-00; Fri, 4 Jun 1999 13:44:24 -0700 Received: from calliope1.fm.intel.com [132.233.247.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 10q0pD-0004xI-00; Fri, 4 Jun 1999 13:44:23 -0700 Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA06678; Fri, 4 Jun 1999 13:44:11 -0700 (PDT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Jun 1999 13:44:11 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB201362E42@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'hmibs@mailbag.intel.com'" , "'rem-conf@es.net'" Cc: "'rspitzer@telogy.com'" , "'tlam@ascend.com'" , "'cpazos@ascend.com'" , "'coronell@ascend.com'" , "'pwang@ascend.com'" , "'Dave Thaler'" Subject: Date: Fri, 4 Jun 1999 13:44:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am wanting to send out a summary of changes we are planning on making to the RTP MIB draft and solicit some input on a couple of key design areas. Thank you David for your review of our draft, all of the typos, clarifications etc. have been added to the draft in question. We have three major points to consider 1) The addition of a "Reverse Lookup Table" to convert address/port pairs into the corresponding rtpSessionIndex 2) A modification to allow more efficient bandwidth aggregation 3) Additional Objects available from the Java Media Framework My comments on these issues are: 1) We will include this table as an OPTIONAL table. Currently many of the H.341 implementers are seeing the need for 1 session for audio 1 session for video in their environment and do not want the added complexity of this table. If the rtpSessionTable is small the overhead of using this table is not worth the implementation overhead. 2) One of the questions that David Thaler wants answered is what is the aggregate RTP Bandwidth from the device. To do this the rtpSenderTable must be read, leading to inefficiencies. There are two ways of optimizing this lookup, one is require hosts to only include bits they are directly sending or receiving if rtpSessionMonitor is set. The other is to include an additional index into the rtpSenderTable and rtpRcvrTable that is a TruthValue rtpSenderIsLocal (or some name close to that). The H.341 community is not interested in having to include 2 rtpSessionEntries to be able to track what the receivers of their bits are receiving (Create one entry for the required Host Mode, Create one entry for the Monitor Mode so they can include the receiver table). The issue that needs to be resolved is the line between complexity in the RTP MIB Agent versus the Management application, and its effect on network management traffic. My current thinking is that calculating total RTP bandwidth for a device belongs as a function of the Management application. I also do not see much of an improvement in the number of roundtrips needed to get the values needed to do the aggregation, especially in the presence of GET-BULK in SNMP v2 and beyond. Additional indexes will add processing time to table handling within the agent therefore slowing the host down. 3) I believe that we have met all of Francisco Needed requirements from the JMF, and no one else has asked for these variables. I do not think adding any of these objects would be a good idea, many implementations will not have access to this information. Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me From rem-conf Fri Jun 04 18:48:06 1999 From rem-conf-request@es.net Fri Jun 04 18:48:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10q5WR-0000H5-00; Fri, 4 Jun 1999 18:45:19 -0700 Received: from smtp13.bellglobal.com [204.101.251.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 10q5WQ-0000Gv-00; Fri, 4 Jun 1999 18:45:18 -0700 Received: from sympatico.ca (ppp8849.on.bellglobal.com [207.236.126.33]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id VAA18835; Fri, 4 Jun 1999 21:46:26 -0400 (EDT) Message-ID: <3758A9FC.1158CEAF@sympatico.ca> Date: Fri, 04 Jun 1999 21:39:24 -0700 From: John Foote Reply-To: john.foote@sympatico.ca Organization: none X-Mailer: Mozilla 4.05 [en]C-SYMPA (Win95; I) MIME-Version: 1.0 To: mbone.cilea.it@sympatico.ca, rem-conf@es.net Subject: Research Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi! I'm looking for recent statistics on the Mbone, e.g. how many people are using it, etc. Can you help? John Foote From rem-conf Sun Jun 06 13:55:00 1999 From rem-conf-request@es.net Sun Jun 06 13:54:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10qjdu-0004PX-00; Sun, 6 Jun 1999 13:35:42 -0700 Received: from sl1.nrh.de [194.231.142.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10qjds-0004PN-00; Sun, 6 Jun 1999 13:35:41 -0700 Received: from bueso.mrc-lmb.cam.ac.uk (zeus.host4u.net [216.71.64.21]) by sl1.nrh.de (8.8.8/8.8.8) with SMTP id AAA10216; Mon, 7 Jun 1999 00:17:29 +0200 Date: Mon, 7 Jun 1999 00:17:29 +0200 From: nqfxltadsm@mrc-lmb.cam.ac.uk Message-Id: <199906062217.AAA10216@sl1.nrh.de> To: waabljzray@aguia.telepar.ufpr.br Subject: Earn $2,000/week in 28 days with FREE 32-pg booklet qymrl X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi. Would you like to know why your ads and emails don't work? This FREE booklet will show you that and more. Learn how to make BIG money on the Internet with "The Insiders' Secrets to Wealth on the Web". You'll discover that it's really easy to make more than $5000 a week...week after week, after week...if you know the secrets. You'll learn them all here...FREE! This booklet holds nothing back! Click the link below right now and download Or print it out without any cost or obligation. Click Here http://www.wisemulesclub.com or AOL users Click Here There's nothing to buy...nothing to do, and it could make you rich! Click the link now! From rem-conf Mon Jun 07 10:51:15 1999 From rem-conf-request@es.net Mon Jun 07 10:51:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10r3OV-0005lX-00; Mon, 7 Jun 1999 10:41:07 -0700 Received: from (rock.gic.gi.com) [198.102.88.4] by mail1.es.net with smtp (Exim 1.81 #2) id 10r3OU-0005kj-00; Mon, 7 Jun 1999 10:41:06 -0700 Received: by rock.gic.gi.com; id NAA03516; Mon, 7 Jun 1999 13:39:13 -0400 Received: from htsmtp.gic.gi.com(168.84.143.23) by rock.gic.gi.com via smap (V4.2) id xma002818; Mon, 7 Jun 99 13:38:16 -0400 Received: from CONVERSION-DAEMON by HtSMTP.GIC.GI.com (PMDF V5.1-7 #23321) id <01JC4CZDCI9C002J7O@HtSMTP.GIC.GI.com> for rem-conf@es.net; Mon, 7 Jun 1999 13:42:01 -0400 (EDT) Received: from xchsrv0.gic.gi.com by HtSMTP.GIC.GI.com (PMDF V5.1-7 #23321) with ESMTP id <01JC4CZC003I002JVY@HtSMTP.GIC.GI.com> for rem-conf@es.net; Mon, 07 Jun 1999 13:41:59 -0400 (EDT) Received: by xchsrv0.gic.gi.com with Internet Mail Service (5.5.2448.0) id ; Mon, 07 Jun 1999 13:38:29 -0400 Content-return: allowed Date: Mon, 07 Jun 1999 13:39:41 -0400 From: "Vetter, Rick (HT-EX)" To: "'rem-conf@es.net'" Message-id: <417C01CA74C0D211B3FE02204840B14A1AC6AB@xchsrv4.gic.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_[ID_EDx/CUQRNsQvxEtUp3Z8/Q]" Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_[ID_EDx/CUQRNsQvxEtUp3Z8/Q] Content-type: text/plain subscribe Rick Vetter General Instrument rvetter@gi.com 215 323 2383 --Boundary_[ID_EDx/CUQRNsQvxEtUp3Z8/Q] Content-type: text/html

subscribe

Rick Vetter
General Instrument
rvetter@gi.com
215 323 2383

--Boundary_[ID_EDx/CUQRNsQvxEtUp3Z8/Q]-- From rem-conf Mon Jun 07 14:18:07 1999 From rem-conf-request@es.net Mon Jun 07 14:18:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10r6dj-0000XV-00; Mon, 7 Jun 1999 14:09:03 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 10r6dh-0000XL-00; Mon, 7 Jun 1999 14:09:01 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 7 Jun 1999 21:12:32 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256789.00740B6B ; Mon, 7 Jun 1999 17:07:30 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: rem-conf@es.net Message-ID: <85256789.00740A3F.00@notes4.nmss.com> Date: Mon, 7 Jun 1999 17:08:36 -0400 Subject: dtmf carriage 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'm wondering how the consensus is emerging on DTMF carriage. Are we leaning more toward an out of band (TCP) method as in H.245, or an inband (UDP) method with redundancy as in ietf-avt-dtmf-01.txt? Also wondering if anyone can think of any common applications involving voice and DTMF intermingled (in the same direction). Thanks. From rem-conf Mon Jun 07 14:29:40 1999 From rem-conf-request@es.net Mon Jun 07 14:29:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10r6um-0001Kq-00; Mon, 7 Jun 1999 14:26:40 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10r6ul-0001Kg-00; Mon, 7 Jun 1999 14:26:39 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA10785; Mon, 7 Jun 1999 17:26:38 -0400 (EDT) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA23335; Mon, 7 Jun 1999 17:26:37 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <375C390D.E45E63C3@cs.columbia.edu> Date: Mon, 07 Jun 1999 17:26:37 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Levens@nmss.com CC: rem-conf@es.net Subject: Re: dtmf carriage References: <85256789.00740A3F.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 Bruce_Levens@nmss.com wrote: > > I'm wondering how the consensus is emerging on DTMF carriage. Are we > leaning more toward an out of band (TCP) method as in H.245, or an > inband (UDP) method with redundancy as in ietf-avt-dtmf-01.txt? Also > wondering if anyone can think of any common applications involving voice > and DTMF intermingled (in the same direction). Thanks. The revised spec draft for the latter should appear later today or tomorrow, depending on the changes Scott Petrack and I still need to work out. IVR and any type of information service (banking, phone course registration, etc.) are obvious examples of mixing the two. Given that the DTMF detection is usually done in the DSP handling the voice bits, doing DTMF in-band seems somewhat easier. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Jun 08 22:56:32 1999 From rem-conf-request@es.net Tue Jun 08 22:56:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10rbCY-0007mE-00; Tue, 8 Jun 1999 22:47:02 -0700 Received: from anchor.cs.colorado.edu [128.138.243.140] by mail1.es.net with esmtp (Exim 1.81 #2) id 10rbCX-0007ly-00; Tue, 8 Jun 1999 22:47:01 -0700 Received: (from evi@localhost) by anchor.cs.colorado.edu (8.9.3/8.9.2) id XAA16604; Tue, 8 Jun 1999 23:45:59 -0600 (MDT) Date: Tue, 8 Jun 1999 23:45:59 -0600 (MDT) From: Evi Nemeth Message-Id: <199906090545.XAA16604@anchor.cs.colorado.edu> To: rem-conf@es.net Subject: usenix technical conference Cc: evi@anchor.cs.colorado.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list the usenix technical conference will be mboned jun 9-11, 9am to 5:30pm, pacific time (gmt-8). see www.usenix.org/events/usenix99 for detailed program. here are the parameters in case you cant see it in sdr. vic 224.2.187.101/59298 vat 224.2.192.144/17856 wb 224.2.138.245/43590 -evi From rem-conf Wed Jun 09 07:09:43 1999 From rem-conf-request@es.net Wed Jun 09 07:09:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10rizU-00041u-00; Wed, 9 Jun 1999 07:06:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10rizS-00041k-00; Wed, 9 Jun 1999 07:06:03 -0700 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Jun 9 10:04:10 EDT 1999 Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA24208; Wed, 9 Jun 1999 10:04:09 -0400 (EDT) Message-ID: <375E73F1.860681D8@cs.columbia.edu> Date: Wed, 09 Jun 1999 10:02:25 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: rem-conf@es.net CC: Scott Petrack , MEGACO@standards.nortelnetworks.com Subject: First cut at DTMF/tones draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've put the PostScript and PDF versions of the merged DTMF and tones draft at http://www.cs.columbia.edu/~hgs/rtp/doc/dtmf/tones.pdf and tones.ps. Scott and I would appreciate your comments. I will turn this into an (ASCII) I-D shortly, barring "you must be crazy" comments. Thanks. From rem-conf Wed Jun 09 08:59:01 1999 From rem-conf-request@es.net Wed Jun 09 08:59:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10rkfP-0005o0-00; Wed, 9 Jun 1999 08:53:27 -0700 Received: from smtprtp.nortelnetworks.com (smtprtp.nortel.com) [192.122.117.66] by mail1.es.net with esmtp (Exim 1.81 #2) id 10rkfN-0005nm-00; Wed, 9 Jun 1999 08:53:25 -0700 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprtp.nortel.com; Wed, 9 Jun 1999 11:51:53 -0400 Received: from zrtpd00x.us.nortel.com ([47.140.224.108]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MMZ21C6N; Wed, 9 Jun 1999 10:51:51 -0500 Received: from americasm01.nt.com (prtpd1gd.us.nortel.com [47.202.36.60]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KBTJ0W7F; Wed, 9 Jun 1999 11:51:50 -0400 Message-ID: <375E8CD2.2E84593D@americasm01.nt.com> Date: Wed, 09 Jun 1999 11:48:34 -0400 From: "Chris Fulmer" Reply-To: "Chris Fulmer" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: rem-conf@es.net, Scott Petrack , megaco@standards.nortelnetworks.com Subject: Re: First cut at DTMF/tones draft References: <375E73F1.860681D8@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 A couple of quick questions/comments: 1. What's the relationship of the line events (section 2.9) and trunk events (section 3.1) to the various signalling-over-IP proposals that are floating around (which I'm not very familiar with, thus the question.)? 2. In particular, I'm not quite sure how or why things such as 'incoming seizure' would be transmitted via RTP -- seems to me that I'd be expecting these to be carried 'higher up', via SIP, MGCP, H.245 or something. 3. The chart on P.11 has 3 columns of numbers. I assume that the second two columns are cadence (on/off) information. It appears that the cadence information did not find its way into the payload format. (I seem to recall it being in the previous tones draft). I generally agree with its removal, because of the difficulty of figuring out the cadence without listening to a long sample to figure it out -- as pointed out in the introduction. 4. WRT the comment in the introduction "When calling a foreign country, the caller generally hears the tones as defined in the country called, rather than those familiar to him": As I understand ISDN, this is not generally how things happen in that environment. For example, if a call is placed from the US to France, and the called party is busy, an indication is sent back to the calling switch, which generates the busy tone, and the overseas call is dropped. I don't rightly know how other tones (ringing, for example) are handled. Not that it matters really -- there isn't any reason why one couldn't implement a system where the tones are generated remotely. So, I'd recommend leaving the comment in, but change the wording so it sounds like a "possible use," recognizing that different RTP users may decide to go the ISDN-style route -- right now it reads more like "this is how it should be done." (even though it doesn't have the 'SHOULD' keyword.) 5. Similarly, I'd suggest that the last paragraph on the first page be modified to read something like "Gateway implementations which send signalling events via RTP SHOULD send both named signals ...." 6. What was the rationale for removing 'Flash' from the DTMF events and adding it to the Line events? It seems to me to logically belong in the DTMF events (even though it's *not* DTMF), for two reasons: -- Apart from 'on hook' and 'off hook', it's the only line event that goes from a terminal to a gateway. -- In the PSTN, it's used much as DTMF is -- as an input device by the user to indicate that the switch should do something. I imagine that in a VoIP environment, the usage would still be similar. 7. Speaking of on- and off- hook, wouldn't transmitting these as line events imply that there was a continual RTP stream being generated from the terminal? I guess that if someone wanted to do this, they could, but I would expect the on- and off- hook messages to generate a message in a different protocol (again, SIP or H.323 or whatever) which caused the RTP stream to be instantiated. 8. I like breaking up the draft into 5 different payload types -- allows implementors the ability to pick-and-choose what they need for their implementation. 9. Section 2.3, at the bottom of the page: "An audio source SHOULD start transmitting event packets as soon as it recognizes an event and every 50 ms thereafter." May I suggest that this should be something like "at intervals of at most 50 ms thereafter." I'm not even sure of the 50ms limit -- seems to me that you'd want the event packets to come out at about the same rate as the audio codec. (as alluded to in 2.6.) 10. 'Duration' for several events is undefined, as they reflect a state transition, for instance the hook signals, seizure, etc... Many thanks! -- C Henning Schulzrinne wrote: > I've put the PostScript and PDF versions of the merged DTMF and tones > draft at http://www.cs.columbia.edu/~hgs/rtp/doc/dtmf/tones.pdf and > tones.ps. Scott and I would appreciate your comments. I will turn this > into an (ASCII) I-D shortly, barring "you must be crazy" comments. > > Thanks. From rem-conf Wed Jun 09 17:39:32 1999 From rem-conf-request@es.net Wed Jun 09 17:39:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10rsnD-0005JW-00; Wed, 9 Jun 1999 17:34:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10rsnC-0005JM-00; Wed, 9 Jun 1999 17:34:02 -0700 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Jun 9 20:33:58 EDT 1999 Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id UAA05836; Wed, 9 Jun 1999 20:33:54 -0400 (EDT) Message-ID: <375F078B.857E9870@cs.columbia.edu> Date: Wed, 09 Jun 1999 20:32:11 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Chris Fulmer CC: rem-conf@es.net, Scott Petrack , megaco@standards.nortelnetworks.com Subject: Re: First cut at DTMF/tones draft References: <375E73F1.860681D8@cs.columbia.edu> <375E8CD2.2E84593D@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Chris Fulmer wrote: > > A couple of quick questions/comments: > > 1. What's the relationship of the line events (section 2.9) and trunk > events (section 3.1) to the various signalling-over-IP proposals that are > floating around (which I'm not very familiar with, thus the question.)? There are several answers to this. I'll name one, hopefully not too controversial: Imagine a "trunk replacement" service, where a T1 carrying voice is to be replaced by an IP span. The voice is coded as G.723.1, channel by channel, and carried as an "RTP trunk" (on-going AVT work on muxing). The signaling (MF, if a digital trunk recovered from the LSB, which wouldn't survive the G.723.1 encoding) is translated to the trunk events. Possibly, DTMF is recognized and carried as a separate payload as well. Yes, one could use SIGTRANS in this case, but my hunch is that the draft at hand would be much simpler to implement for in-band signaling. > > 2. In particular, I'm not quite sure how or why things such as > 'incoming seizure' would be transmitted via RTP -- seems to me that I'd be > expecting these to be carried 'higher up', via SIP, MGCP, H.245 or > something. If true signaling, yes, I'd using "real" signaling as well, as it avoids exposing Internet systems to the historical details of MF signaling, although others might disagree. See previous paragraph. > > 3. The chart on P.11 has 3 columns of numbers. I assume that the > second two columns are cadence (on/off) information. It appears that the > cadence information did not find its way into the payload format. (I seem > to recall it being in the previous tones draft). I generally agree with > its removal, because of the difficulty of figuring out the cadence without > listening to a long sample to figure it out -- as pointed out in the > introduction. Simply missing enumeration (aka as my laziness). To be filled in once we have rough consensus on the approach. > > 4. WRT the comment in the introduction "When calling a foreign country, > the caller generally hears the tones as defined in the country called, > rather than those familiar to him": As I understand ISDN, this is not > generally how things happen in that environment. For example, if a call > is placed from the US to France, and the called party is busy, an > indication is sent back to the calling switch, which generates the busy > tone, and the overseas call is dropped. I don't rightly know how other > tones (ringing, for example) are handled. Not that it matters really -- > there isn't any reason why one couldn't implement a system where the tones > are generated remotely. So, I'd recommend leaving the comment in, but > change the wording so it sounds like a "possible use," recognizing that > different RTP users may decide to go the ISDN-style route -- right now it > reads more like "this is how it should be done." (even though it doesn't > have the 'SHOULD' keyword.) Good point; will be added. > > 5. Similarly, I'd suggest that the last paragraph on the first page be > modified to read something like "Gateway implementations which send > signalling events via RTP SHOULD send both named signals ...." Agreed. > > 6. What was the rationale for removing 'Flash' from the DTMF events and > adding it to the Line events? It seems to me to logically belong in the > DTMF events (even though it's *not* DTMF), for two reasons: > > -- Apart from 'on hook' and 'off hook', it's the only line event that > goes from a terminal to a gateway. > -- In the PSTN, it's used much as DTMF is -- as an input device by the > user to indicate that the switch should do something. I imagine that in a > VoIP environment, the usage would still be similar. I wasn't quite sure where this belonged. Many systems that use DTMF (say, a gateway), will never send this. I'll move it back. > > 7. Speaking of on- and off- hook, wouldn't transmitting these as line > events imply that there was a continual RTP stream being generated from > the terminal? I guess that if someone wanted to do this, they could, but > I would expect the on- and off- hook messages to generate a message in a > different protocol (again, SIP or H.323 or whatever) which caused the RTP > stream to be instantiated. I'm also dubious about on-hook and off-hook as line events. Anybody has a reason why they'd be useful? > > 8. I like breaking up the draft into 5 different payload types -- allows > implementors the ability to pick-and-choose what they need for their > implementation. > > 9. Section 2.3, at the bottom of the page: "An audio source SHOULD > start transmitting event packets as soon as it recognizes an event and > every 50 ms thereafter." May I suggest that this should be something like > "at intervals of at most 50 ms thereafter." I'm not even sure of the 50ms > limit -- seems to me that you'd want the event packets to come out at > about the same rate as the audio codec. (as alluded to in 2.6.) Will be fixed. > > 10. 'Duration' for several events is undefined, as they reflect a state > transition, for instance the hook signals, seizure, etc... This would be how long this condition has persisted so far. > > Many thanks! > > -- > C > > Henning Schulzrinne wrote: > > > I've put the PostScript and PDF versions of the merged DTMF and tones > > draft at http://www.cs.columbia.edu/~hgs/rtp/doc/dtmf/tones.pdf and > > tones.ps. Scott and I would appreciate your comments. I will turn this > > into an (ASCII) I-D shortly, barring "you must be crazy" comments. > > > > Thanks. From rem-conf Thu Jun 10 10:48:52 1999 From rem-conf-request@es.net Thu Jun 10 10:48:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10s8lD-0005vc-00; Thu, 10 Jun 1999 10:37:03 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 10s8l7-0005vR-00; Thu, 10 Jun 1999 10:36:57 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) with SMTP id NAA13343 for ; Thu, 10 Jun 1999 13:36:55 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id NAA12356; Thu, 10 Jun 1999 13:38:09 -0400 Date: Thu, 10 Jun 1999 13:38:09 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199906101738.NAA12356@billings.csb> To: rem-conf@es.net Subject: Re: usenix technical conference X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is anyone seeing any of these sessions (sdr. vic, vat, wb)??? I see nohting here... Cheerio, Rick Rodgers ------- R. P. C. Rodgers, M.D. * rodgers@nlm.nih.gov * (301)496-9305 (voice, fax) CSB, LHNCBC, National Library of Medicine, NIH 8600 Rockville Pike, Bethesda MD 20894 USA http://www.nlm.nih.gov/, search personnel roster for "rodgers" > From rem-conf-request@es.net Wed Jun 9 02:06:17 1999 > Date: Tue, 8 Jun 1999 23:45:59 -0600 (MDT) > From: Evi Nemeth > To: rem-conf@es.net > Subject: usenix technical conference > Cc: evi@anchor.cs.colorado.edu > X-Mailing-List: > X-Loop: rem-conf@es.net > Content-Length: 288 > > the usenix technical conference will be mboned jun 9-11, > 9am to 5:30pm, pacific time (gmt-8). see www.usenix.org/events/usenix99 > for detailed program. here are the parameters in case you cant see it > in sdr. > > vic 224.2.187.101/59298 > vat 224.2.192.144/17856 > wb 224.2.138.245/43590 > > -evi > > From rem-conf Thu Jun 10 11:49:19 1999 From rem-conf-request@es.net Thu Jun 10 11:49:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10s9pJ-00079h-00; Thu, 10 Jun 1999 11:45:21 -0700 Received: from mailer.psc.edu [128.182.58.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10s9pI-00079W-00; Thu, 10 Jun 1999 11:45:20 -0700 Received: from sunshine (sunshine.psc.edu [128.182.61.166]) by mailer.psc.edu (8.8.7/8.8.7/mailer) with SMTP id OAA14611; Thu, 10 Jun 1999 14:45:18 -0400 (EDT) Message-ID: <000e01beb371$61f3da40$a63db680@psc.edu> From: "S.Grant" To: "R. P. Channing Rodgers, M.D." , References: <199906101738.NAA12356@billings.csb> Subject: Re: usenix technical conference Date: Thu, 10 Jun 1999 14:45:15 -0400 Organization: NLANR/NCNE Pittsburgh Supercomputing Center MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm getting video, but rat's not carrying the audio. Shirl Grant NCNE Engineering Services grant@ncne.org NLANR / Pittsburgh Supercomputing Center - ----- Original Message ----- From: R. P. Channing Rodgers, M.D. To: Sent: Thursday, June 10, 1999 1:38 PM Subject: Re: usenix technical conference > > Is anyone seeing any of these sessions (sdr. vic, vat, wb)??? I see > nohting here... > > Cheerio, Rick Rodgers > ------- > R. P. C. Rodgers, M.D. * rodgers@nlm.nih.gov * (301)496-9305 (voice, fax) > CSB, LHNCBC, National Library of Medicine, NIH > 8600 Rockville Pike, Bethesda MD 20894 USA > http://www.nlm.nih.gov/, search personnel roster for "rodgers" > > > > From rem-conf-request@es.net Wed Jun 9 02:06:17 1999 > > Date: Tue, 8 Jun 1999 23:45:59 -0600 (MDT) > > From: Evi Nemeth > > To: rem-conf@es.net > > Subject: usenix technical conference > > Cc: evi@anchor.cs.colorado.edu > > X-Mailing-List: > > X-Loop: rem-conf@es.net > > Content-Length: 288 > > > > the usenix technical conference will be mboned jun 9-11, > > 9am to 5:30pm, pacific time (gmt-8). see www.usenix.org/events/usenix99 > > for detailed program. here are the parameters in case you cant see it > > in sdr. > > > > vic 224.2.187.101/59298 > > vat 224.2.192.144/17856 > > wb 224.2.138.245/43590 > > > > -evi > > > > > From rem-conf Thu Jun 10 12:03:07 1999 From rem-conf-request@es.net Thu Jun 10 12:03:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sA4a-00005W-00; Thu, 10 Jun 1999 12:01:08 -0700 Received: from mailer.psc.edu [128.182.58.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sA4Z-00005L-00; Thu, 10 Jun 1999 12:01:07 -0700 Received: from sunshine (sunshine.psc.edu [128.182.61.166]) by mailer.psc.edu (8.8.7/8.8.7/mailer) with SMTP id OAA04417; Thu, 10 Jun 1999 14:58:35 -0400 (EDT) Message-ID: <003001beb373$3d608820$a63db680@psc.edu> From: "S.Grant" To: "Evi Nemeth" , Cc: References: <199906090545.XAA16604@anchor.cs.colorado.edu> Subject: Re: usenix technical conference Date: Thu, 10 Jun 1999 14:58:34 -0400 Organization: NLANR/NCNE Pittsburgh Supercomputing Center MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Evi, Can you broadcast such that "rat" can hear the sessions? If you're broadcasting with vat, do so with "vat -r". Thanks, Shirl Grant NCNE Engineering Services grant@ncne.org NLANR / Pittsburgh Supercomputing Center - ----- Original Message ----- From: Evi Nemeth To: Cc: Sent: Wednesday, June 09, 1999 1:45 AM Subject: usenix technical conference > the usenix technical conference will be mboned jun 9-11, > 9am to 5:30pm, pacific time (gmt-8). see www.usenix.org/events/usenix99 > for detailed program. here are the parameters in case you cant see it > in sdr. > > vic 224.2.187.101/59298 > vat 224.2.192.144/17856 > wb 224.2.138.245/43590 > > -evi > From rem-conf Thu Jun 10 12:04:22 1999 From rem-conf-request@es.net Thu Jun 10 12:04:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sA7S-0000Fa-00; Thu, 10 Jun 1999 12:04:06 -0700 Received: from m1mail.mediaone.com [169.152.79.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sA7R-00009m-00; Thu, 10 Jun 1999 12:04:05 -0700 Received: from wsimc01.mediaone.com (wsimc01.mediaone.com [169.152.100.174]) by m1mail.mediaone.com (8.8.7/8.8.7) with SMTP id PAA04339 for ; Thu, 10 Jun 1999 15:04:48 -0400 (EDT) Received: from 169.152.100.30 by wsimc01.mediaone.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Thu, 10 Jun 99 15:01:03 -0700 X-Server-Uuid: cda7734f-06b2-11d3-bc59-00805fbb2b22 Received: by exchimc01.mediaone.com with Internet Mail Service ( 5.5.2448.0) id ; Thu, 10 Jun 1999 15:03:02 -0400 Message-ID: From: "Cain, Michael E." To: Subject: RE: usenix technical conference Date: Thu, 10 Jun 1999 15:02:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 1B7EEA1595204-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Interesting. I'm getting audio with rat and an agenda with wb, but have not seen any vido packets. Michael Cain MediaOne Labs Westminster, CO > ---------- > From: S.Grant[SMTP:grant@psc.edu] > Sent: Thursday, June 10, 1999 12:45 PM > To: R. P. Channing Rodgers, M.D.; rem-conf@es.net > Subject: Re: usenix technical conference > > I'm getting video, but rat's not carrying the audio. > > Shirl Grant NCNE Engineering Services > grant@ncne.org NLANR / Pittsburgh Supercomputing Center > > - > > > ----- Original Message ----- > From: R. P. Channing Rodgers, M.D. > To: > Sent: Thursday, June 10, 1999 1:38 PM > Subject: Re: usenix technical conference > > > > > > Is anyone seeing any of these sessions (sdr. vic, vat, wb)??? I see > > nohting here... > > > > Cheerio, Rick Rodgers > > ------- > > R. P. C. Rodgers, M.D. * rodgers@nlm.nih.gov * (301)496-9305 > (voice, fax) > > CSB, LHNCBC, National Library of Medicine, NIH > > 8600 Rockville Pike, Bethesda MD 20894 USA > > http://www.nlm.nih.gov/, search personnel roster for "rodgers" > > > > > > > From rem-conf-request@es.net Wed Jun 9 02:06:17 1999 > > > Date: Tue, 8 Jun 1999 23:45:59 -0600 (MDT) > > > From: Evi Nemeth > > > To: rem-conf@es.net > > > Subject: usenix technical conference > > > Cc: evi@anchor.cs.colorado.edu > > > X-Mailing-List: > > > X-Loop: rem-conf@es.net > > > Content-Length: 288 > > > > > > the usenix technical conference will be mboned jun 9-11, > > > 9am to 5:30pm, pacific time (gmt-8). see > www.usenix.org/events/usenix99 > > > for detailed program. here are the parameters in case you cant see > it > > > in sdr. > > > > > > vic 224.2.187.101/59298 > > > vat 224.2.192.144/17856 > > > wb 224.2.138.245/43590 > > > > > > -evi > > > > > > > > > > From rem-conf Thu Jun 10 13:03:38 1999 From rem-conf-request@es.net Thu Jun 10 13:03:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sB0I-0001uV-00; Thu, 10 Jun 1999 13:00:46 -0700 Received: from stennis.ca.sandia.gov [146.246.243.44] (bmah) by mail1.es.net with esmtp (Exim 1.81 #2) id 10sB0H-0001uL-00; Thu, 10 Jun 1999 13:00:45 -0700 Received: (from bmah@localhost) by stennis.ca.sandia.gov (8.9.3/8.9.3) id NAA27934; Thu, 10 Jun 1999 13:00:35 -0700 (PDT) Message-Id: <199906102000.NAA27934@stennis.ca.sandia.gov> X-Mailer: exmh version 2.1.0 06/10/1999 To: "Cain, Michael E." Cc: rem-conf@es.net Subject: Re: usenix technical conference In-Reply-To: Your message of "Thu, 10 Jun 1999 15:02:55 EDT." From: bmah@CA.Sandia.GOV (Bruce A. Mah) Reply-To: bmah@CA.Sandia.GOV X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Url: http://www.ca.sandia.gov/~bmah/ Mime-Version: 1.0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1995191658P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 1999 13:00:35 -0700 Sender: bmah@stennis.ca.sandia.gov X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --==_Exmh_-1995191658P Content-Type: text/plain; charset=us-ascii If memory serves me right, "Cain, Michael E." wrote: > Interesting. I'm getting audio with rat and an agenda with wb, but have not > seen any vido packets. Just so someone knows that they *are* alive over there, I'm currently receiving video with vic 2.8.1 at 48kbps, no loss (of a blank screen, unfortunately), and I've been listening to the audio for the past day and a half (vat 4.0pre7). wb has two pages on it...the first is miscellaneous graffiti and the second is the second day's schedule. I have control packets from about eight participants in vat. Bruce. --==_Exmh_-1995191658P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN2AZYqjOOi0j7CY9AQEtXAP+OVNi77quMQPX5/a+9+MoTb/xT9sWfUM6 Rph3bVN8XKJ11UDACLp6qV+rFDUbFOuvHYuyXm5xbanGKRx7R+XicbOoh3dlD3bk oNKIvpsl5l0RB7Hhpt7tcyqws/4lqb5SPvidolhijgc3F9SHGJ6koVkl8ZJJbRZz QrFxvBy0+VY= =pDaH -----END PGP MESSAGE----- --==_Exmh_-1995191658P-- From rem-conf Thu Jun 10 16:46:30 1999 From rem-conf-request@es.net Thu Jun 10 16:46:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sEU5-0004ct-00; Thu, 10 Jun 1999 16:43:45 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sEU4-0004cf-00; Thu, 10 Jun 1999 16:43:44 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA29899; Thu, 10 Jun 1999 19:43:18 -0400 (EDT) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA26200; Thu, 10 Jun 1999 19:43:17 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <37604D95.8BCBCA30@cs.columbia.edu> Date: Thu, 10 Jun 1999 19:43:17 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Graeme Gibbs CC: "'rem-conf@es.net'" , Rade Gvozdanovic , Rajakulasingam Raviraj , "'Chaoxin.Qiu@mail.sprint.com'" Subject: Re: Additional Named Signal Events References: <391D82D86F58D111B8250000F805C4D0023526EF@bhari886.europe.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Graeme Gibbs wrote: > > To whoever is editting/championing "RTP Payloads for Telephone Signal > Events" > > Firstly I have not been following the mailing list so apologies if this > topic is old & cold. > > Basically I believe this draft would benefit from the addition of 2 extra > Named Signal Events ie > 2100Hz tones (ITU G.164)& > 2100Hz tone with Phase reversals (ITU G.165) The draft (at http://www.cs.columbia.edu/~hgs/rtp/doc/dtmf/tones.pdf) currently contains CED in the 'fax' set. CED appears to be a 2,100 Hz tone, so it covers the G.164 case. Is a special G.164 version of this tone needed or will this do? Also, I've tentatively added a 2,100 Hz tone with phase reversals into the fax set. Does this tone have a common name? > > Rationale: > These tones, while not used by traditional TDM switches per se, are used by > echo cancellers within the TDM network to turn off echo cancellation for > calls carrying modems & faxes. > Certain carriers may wish to build telephony over IP transit networks, > where, at least initially, modem/faxes are carried transparently as G.711 > (64kbit/s) packets over IP > (yes I know this amounts to data over voice over data, but it may be some > period before all gateways support all modulation techniques, and carriers > must provide equivalence to current Public Switched Telephone Network from > Day 1). Modems/faxes sending such tones would expect both the intervening IP > network and prior/subsequent echo cancellers in PSTN to moderate their > behaviour accordingly. > > Take a scenario where the VOIP gateways are running voice calls as > compressed to G.729, with silence suppression and echo cancellation, and > such a 2100Hz tone is detected > The local GW must: Upspeed to 64 kbit/s & turn off silence suppression, and > echo cancellation > The remote GW must also: Upspeed to 64 kbit/s & turn off silence > suppression, and echo cancellation > The tone must be propagated back into the PSTN by remote GW > > 2100Hz tones will not reliably propagate through G.729, therefore if the > system relied on passing this tone in-band, the near-end modem would have > to detect tone , decide to upspeed (maybe local CAC decisions), and then > execute upspeeding before far end GW can begin to detect tones in the stream > from the IP network- this may take too long. This method also relies on > codec that can receive one codec type and transmit in another (desirable BUT > not always the case) > However if the near-end GW were to send a Named Signal Event once it had > detected the tone, this would allow CAC and upspeeding to occur in parallel, > together with a correct tone being enforced to the PSTN > > Any replies, please mail direct to me as I do not subscribe to avt list -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Jun 10 17:21:04 1999 From rem-conf-request@es.net Thu Jun 10 17:21:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sF1n-0005U5-00; Thu, 10 Jun 1999 17:18:35 -0700 Received: from sd-exchange.nuera.com (exchangesvr.nuera.com) [204.216.240.106] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sF1m-0005Tr-00; Thu, 10 Jun 1999 17:18:34 -0700 Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Jun 1999 17:17:33 -0700 Message-ID: From: "Fox, Mike" To: Henning Schulzrinne , Graeme Gibbs Cc: "'rem-conf@es.net'" Subject: RE: Additional Named Signal Events Date: Thu, 10 Jun 1999 17:17:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Perhaps the ANS signal designation of the 2100 Hz answer tone from V.25 would be a more common signal name. A bar over ANS indicates the phase reversed signal. Mike Fox -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Thursday, June 10, 1999 4:43 PM To: Graeme Gibbs Cc: 'rem-conf@es.net'; Rade Gvozdanovic; Rajakulasingam Raviraj; 'Chaoxin.Qiu@mail.sprint.com' Subject: Re: Additional Named Signal Events Graeme Gibbs wrote: > > To whoever is editting/championing "RTP Payloads for Telephone Signal > Events" > > Firstly I have not been following the mailing list so apologies if this > topic is old & cold. > > Basically I believe this draft would benefit from the addition of 2 extra > Named Signal Events ie > 2100Hz tones (ITU G.164)& > 2100Hz tone with Phase reversals (ITU G.165) The draft (at http://www.cs.columbia.edu/~hgs/rtp/doc/dtmf/tones.pdf) currently contains CED in the 'fax' set. CED appears to be a 2,100 Hz tone, so it covers the G.164 case. Is a special G.164 version of this tone needed or will this do? Also, I've tentatively added a 2,100 Hz tone with phase reversals into the fax set. Does this tone have a common name? > > Rationale: > These tones, while not used by traditional TDM switches per se, are used by > echo cancellers within the TDM network to turn off echo cancellation for > calls carrying modems & faxes. > Certain carriers may wish to build telephony over IP transit networks, > where, at least initially, modem/faxes are carried transparently as G.711 > (64kbit/s) packets over IP > (yes I know this amounts to data over voice over data, but it may be some > period before all gateways support all modulation techniques, and carriers > must provide equivalence to current Public Switched Telephone Network from > Day 1). Modems/faxes sending such tones would expect both the intervening IP > network and prior/subsequent echo cancellers in PSTN to moderate their > behaviour accordingly. > > Take a scenario where the VOIP gateways are running voice calls as > compressed to G.729, with silence suppression and echo cancellation, and > such a 2100Hz tone is detected > The local GW must: Upspeed to 64 kbit/s & turn off silence suppression, and > echo cancellation > The remote GW must also: Upspeed to 64 kbit/s & turn off silence > suppression, and echo cancellation > The tone must be propagated back into the PSTN by remote GW > > 2100Hz tones will not reliably propagate through G.729, therefore if the > system relied on passing this tone in-band, the near-end modem would have > to detect tone , decide to upspeed (maybe local CAC decisions), and then > execute upspeeding before far end GW can begin to detect tones in the stream > from the IP network- this may take too long. This method also relies on > codec that can receive one codec type and transmit in another (desirable BUT > not always the case) > However if the near-end GW were to send a Named Signal Event once it had > detected the tone, this would allow CAC and upspeeding to occur in parallel, > together with a correct tone being enforced to the PSTN > > Any replies, please mail direct to me as I do not subscribe to avt list -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Jun 10 18:56:57 1999 From rem-conf-request@es.net Thu Jun 10 18:56:56 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sGWx-0006ku-00; Thu, 10 Jun 1999 18:54:51 -0700 Received: from sd-exchange.nuera.com (exchangesvr.nuera.com) [204.216.240.106] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sGWv-0006kk-00; Thu, 10 Jun 1999 18:54:49 -0700 Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Jun 1999 18:53:49 -0700 Message-ID: From: "Fox, Mike" To: Henning Schulzrinne , Graeme Gibbs Cc: "'rem-conf@es.net'" Subject: RE: Additional Named Signal Events Date: Thu, 10 Jun 1999 18:53:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I just looked at T.30 in section 4.1.1 it designates the Called terminal identification (CED) answer tone, a continuous 2100 Hz * 15 Hz tone. In section 4.1.2 it specifies the optional procedures of V.8 using the ANSam defined in V.8. In section 6.1 for V.34 Recommendations, the spec uses the ANSam signal from V.8. The V.8 Modified answer tone ANSam is a sinewave signal at 2100 * 1 Hz with phase reversals at an interval of 450 * 25 ms, amplitude-modulated by a sinewave at 15 * 0.1 Hz. In V.25 the signals are called ANS, and ANS(with a bar on top). If there was to be a vote, I would pick ANS and ANSam for the signal indications. When the 2100 is detected the ANS is indicated, and if the phase reversal is detected a ANSam signal is indicated until the ANSam signal goes away. Best regards, Mike Fox Nuera Communications From rem-conf Thu Jun 10 19:41:11 1999 From rem-conf-request@es.net Thu Jun 10 19:41:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sHEi-00003x-00; Thu, 10 Jun 1999 19:40:04 -0700 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sHEh-00003m-00; Thu, 10 Jun 1999 19:40:03 -0700 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id TAA17388; Thu, 10 Jun 1999 19:36:18 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 11 Jun 1999 02:40:02 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with SMTP id TAA22222; Thu, 10 Jun 1999 19:39:46 -0700 (PDT) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id TAA28401; Thu, 10 Jun 1999 19:40:01 -0700 Received: from ferdin-pc (ferdin-pc.eng.ascend.com [192.168.19.177]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id WAA19132; Thu, 10 Jun 1999 22:39:59 -0400 (EDT) Message-Id: <3.0.3.32.19990610223753.009dcb90@basset.eng.ascend.com> X-Sender: ferdin@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 10 Jun 1999 22:37:53 -0400 To: "Fox, Mike" , Henning Schulzrinne , Graeme Gibbs From: Fatih Erdin Subject: RE: Additional Named Signal Events Cc: "'rem-conf@es.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 06:53 PM 6/10/99 -0700, Fox, Mike wrote: >Hi, >I just looked at T.30 in section 4.1.1 it designates the Called terminal >identification (CED) answer tone, a continuous 2100 Hz * 15 Hz tone. In >section 4.1.2 it specifies the optional procedures of V.8 using the ANSam >defined in V.8. >In section 6.1 for V.34 Recommendations, the spec uses the ANSam signal from >V.8. > >The V.8 Modified answer tone ANSam is a sinewave signal at 2100 * 1 Hz with >phase reversals at an interval of 450 * 25 ms, amplitude-modulated by a >sinewave at 15 * 0.1 Hz. > >In V.25 the signals are called ANS, and ANS(with a bar on top). > >If there was to be a vote, I would pick ANS and ANSam for the signal >indications. When the 2100 is detected the ANS is indicated, and if the >phase reversal is detected a ANSam signal is indicated until the ANSam >signal goes away. But in this case, the calling terminal can not distinguish whether the called terminal is V.32 (sends /ANS, 2100Hz with phase reversal as answer tone) or V.34 (ANSam, 2100Hz + PR + AM) and thinks it as V.34, even though it's V.32 actually. I think they all should be indicated separately: ANS, /ANS and ANSam (even Cre for V.8bis devices. CRe consists of a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400ms followed by a single tone at 400 Hz for 100 ms). Regards, Fatih Erdin Ascend Communications > >Best regards, >Mike Fox >Nuera Communications > > > From rem-conf Fri Jun 11 07:49:52 1999 From rem-conf-request@es.net Fri Jun 11 07:49:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sSXR-0006JU-00; Fri, 11 Jun 1999 07:44:09 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10sSXP-0006JG-00; Fri, 11 Jun 1999 07:44:08 -0700 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jun 11 10:43:07 EDT 1999 Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA29589; Fri, 11 Jun 1999 10:43:05 -0400 (EDT) Message-ID: <37612015.ACE1C021@cs.columbia.edu> Date: Fri, 11 Jun 1999 10:41:25 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Fatih Erdin CC: "Fox, Mike" , Graeme Gibbs , "'rem-conf@es.net'" Subject: Re: Additional Named Signal Events References: <3.0.3.32.19990610223753.009dcb90@basset.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Fatih Erdin wrote: > > > > But in this case, the calling terminal can not distinguish whether the > called terminal is V.32 (sends /ANS, 2100Hz with phase reversal as answer > tone) or V.34 (ANSam, 2100Hz + PR + AM) and thinks it as V.34, even though > it's V.32 actually. According to V.8 and V.25, ANSam is a sinewave signal at 2100 Hz with phase reversals at 450 ms, and amplitude-modulated. V.32 uses ANS (no phase reversals), from what I can tell. I don't see a separate /ANS signal mentioned in the V.32 spec. Can somebody point me to the section. (V.32 does mention that it uses the V.25 startup procedure.) From rem-conf Fri Jun 11 08:44:17 1999 From rem-conf-request@es.net Fri Jun 11 08:44:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sTRZ-0007Nk-00; Fri, 11 Jun 1999 08:42:09 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sTRY-0007NJ-00; Fri, 11 Jun 1999 08:42:08 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 4D2094CE18; Fri, 11 Jun 1999 11:42:07 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA19058; Fri, 11 Jun 1999 11:42:06 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id LAA16894; Fri, 11 Jun 1999 11:42:05 -0400 (EDT) Message-Id: <199906111542.LAA16894@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: grant@psc.edu Subject: Re: usenix technical conference Cc: evi@anchor.cs.colorado.edu, rem-conf@es.net References: <199906090545.XAA16604@anchor.cs.colorado.edu> <003001beb373$3d608820$a63db680@psc.edu> Date: Fri, 11 Jun 1999 08:42:04 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Shirl, I think it's a multicast problem rather than an application problem that's causing you to not get the audio. The multicast had some trouble on Wednesday because it was singly-homed to the vBNS and the vBNS was experiencing MSDP session flaps to the rest of the world due to an apparent IOS bug. Dave Meyer kindly added a tunnel to AS10888 at PAIX so we should have much better connectivity for Thursday and Friday. If you're still having trouble, perhaps you could try an mtrace? mtrace mbone.conference.usenix.org 224.2.192.144 for the audio, or mtrace mbone.conference.usenix.org 224.2.187.101 for the video. Bill From rem-conf Fri Jun 11 12:50:46 1999 From rem-conf-request@es.net Fri Jun 11 12:50:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sXBx-0002Jq-00; Fri, 11 Jun 1999 12:42:17 -0700 Received: from sd-exchange.nuera.com (exchangesvr.nuera.com) [204.216.240.106] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sXBw-0002Je-00; Fri, 11 Jun 1999 12:42:16 -0700 Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Jun 1999 12:41:16 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE037A38@SD_EXCHANGE> From: "Fox, Mike" To: Henning Schulzrinne , Fatih Erdin Cc: "Fox, Mike" , Graeme Gibbs , "'rem-conf@es.net'" Subject: RE: Additional Named Signal Events Date: Fri, 11 Jun 1999 12:41:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I think Fatih is correct ( I would like to change my vote ) in that ANS, /ANS, and ANSam (even /ANSam) are different signals. If a modem using the V.25 procedures would like to disable the echo cancellers and suppressors it will emit ANS /ANS ANS /ANS ( V32bis 6.2) ... For a modem using V.8 answer procedures it may emit ANSam, /ANSam, ANSam ... to disable echo cancellers and suppressors. In V.8, section 7.2 the modem may emit ANSam without phase reversals if the echo cancellers need not be disabled ( I do not know if any products do this... ). So do the signal indication packets look like: Procedure: indications (time -->) 1. V.25+V.8 ANS, ANS, ANS... 2. V.25 ( EC disable ) ANS..., /ANS..., ANS..., /ANS... 3. V.8 ANSam, ANSam,.... 3. V.8 (EC disable ) ANSam..., /ANSam..., ANSam..., /ANSam... Also V.8 section 7.2 notes that the DCE needs to distinguish ANSam from ANS. This will probably add some delay and complexity to some implementations of ANS detectors. Best regards, Mike Nuera Communications -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, June 11, 1999 7:41 AM To: Fatih Erdin Cc: Fox, Mike; Graeme Gibbs; 'rem-conf@es.net' Subject: Re: Additional Named Signal Events Fatih Erdin wrote: > > > > But in this case, the calling terminal can not distinguish whether the > called terminal is V.32 (sends /ANS, 2100Hz with phase reversal as answer > tone) or V.34 (ANSam, 2100Hz + PR + AM) and thinks it as V.34, even though > it's V.32 actually. According to V.8 and V.25, ANSam is a sinewave signal at 2100 Hz with phase reversals at 450 ms, and amplitude-modulated. V.32 uses ANS (no phase reversals), from what I can tell. I don't see a separate /ANS signal mentioned in the V.32 spec. Can somebody point me to the section. (V.32 does mention that it uses the V.25 startup procedure.) From rem-conf Fri Jun 11 12:50:46 1999 From rem-conf-request@es.net Fri Jun 11 12:50:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sXEd-0002KK-00; Fri, 11 Jun 1999 12:45:03 -0700 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10sXEc-0002KA-00; Fri, 11 Jun 1999 12:45:02 -0700 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id MAA28815; Fri, 11 Jun 1999 12:41:16 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 11 Jun 1999 19:45:01 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with SMTP id MAA07994; Fri, 11 Jun 1999 12:44:45 -0700 (PDT) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id MAA22238; Fri, 11 Jun 1999 12:45:00 -0700 Received: from ferdin-pc (ferdin-pc.eng.ascend.com [192.168.19.177]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id PAA06171; Fri, 11 Jun 1999 15:44:57 -0400 (EDT) Message-Id: <3.0.3.32.19990611154252.009ac1a0@basset.eng.ascend.com> X-Sender: ferdin@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 11 Jun 1999 15:42:52 -0400 To: Henning Schulzrinne From: Fatih Erdin Subject: Re: Additional Named Signal Events Cc: "Fox, Mike" , Graeme Gibbs , "'rem-conf@es.net'" In-Reply-To: <37612015.ACE1C021@cs.columbia.edu> References: <3.0.3.32.19990610223753.009dcb90@basset.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:41 AM 6/11/99 -0400, Henning Schulzrinne wrote: >Fatih Erdin wrote: >> >> >> >> But in this case, the calling terminal can not distinguish whether the >> called terminal is V.32 (sends /ANS, 2100Hz with phase reversal as answer >> tone) or V.34 (ANSam, 2100Hz + PR + AM) and thinks it as V.34, even though >> it's V.32 actually. > >According to V.8 and V.25, ANSam is a sinewave signal at 2100 Hz with >phase reversals at 450 ms, and amplitude-modulated. > >V.32 uses ANS (no phase reversals), from what I can tell. I don't see a >separate /ANS signal mentioned in the V.32 spec. Can somebody point me >to the section. (V.32 does mention that it uses the V.25 startup >procedure.) > You're right, V.32 spec doesn't clearly mention ANS (with a bar on top) with phase reversals (what I meant with /ANS was ANS with a bar on top, 2100 Hz with phase reversals). Since V.32 is duplex modem, the line (voice) echo cancellers on the path should be disabled. The echo canceller disabler tone has phase reversals according to G.165, section 4 (the plain 2100 Hz disables the echo suppressors only). I've also changed the modulation type to V.32 of my modem and observed the phase reversals in the answer tone. Regards, Fatih Erdin Ascend Communications > > ************************************************************** Fatih Erdin tel : (732) 578-3113 Senior DSP/Software Engineer fax : (732) 578-3131 Ascend Communications, Inc. email : fatih.erdin@ascend.com http://www.ascend.com ************************************************************** From rem-conf Fri Jun 11 14:50:14 1999 From rem-conf-request@es.net Fri Jun 11 14:50:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sZ7j-0004oz-00; Fri, 11 Jun 1999 14:46:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10sZ7i-0004op-00; Fri, 11 Jun 1999 14:46:03 -0700 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jun 11 17:44:14 EDT 1999 Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA08206; Fri, 11 Jun 1999 17:43:43 -0400 (EDT) Message-ID: <376182AB.4739EF7A@cs.columbia.edu> Date: Fri, 11 Jun 1999 17:42:03 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Fatih Erdin CC: Graeme Gibbs , "'rem-conf@es.net'" Subject: Re: Additional Named Signal Events References: <3.0.3.32.19990610223753.009dcb90@basset.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've updated the DTMF/tones/events payload draft according to the suggestions received. If I missed something, please let me know. One change made was a change from the name "fax" to "data", since this seems more appropriate for the current collection of signals. From rem-conf Fri Jun 11 15:05:11 1999 From rem-conf-request@es.net Fri Jun 11 15:05:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10sZNt-0005ee-00; Fri, 11 Jun 1999 15:02:45 -0700 Received: from stennis.ca.sandia.gov [146.246.243.44] (bmah) by mail1.es.net with esmtp (Exim 1.81 #2) id 10sZNs-0005eT-00; Fri, 11 Jun 1999 15:02:44 -0700 Received: (from bmah@localhost) by stennis.ca.sandia.gov (8.9.3/8.9.3) id PAA04009; Fri, 11 Jun 1999 15:02:37 -0700 (PDT) Message-Id: <199906112202.PAA04009@stennis.ca.sandia.gov> X-Mailer: exmh version 2.1.0 06/10/1999 To: Bill Fenner Cc: grant@psc.edu, evi@anchor.cs.colorado.edu, rem-conf@es.net Subject: Re: usenix technical conference In-Reply-To: Your message of "Fri, 11 Jun 1999 08:42:04 PDT." <199906111542.LAA16894@windsor.research.att.com> From: bmah@CA.Sandia.GOV (Bruce A. Mah) Reply-To: bmah@CA.Sandia.GOV X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Url: http://www.ca.sandia.gov/~bmah/ Mime-Version: 1.0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-298410366P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 11 Jun 1999 15:02:37 -0700 Sender: bmah@stennis.ca.sandia.gov X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --==_Exmh_-298410366P Content-Type: text/plain; charset=us-ascii If memory serves me right, Bill Fenner wrote: > The multicast had some trouble > on Wednesday because it was singly-homed to the vBNS and the vBNS was > experiencing MSDP session flaps to the rest of the world due to an apparent > IOS bug. Dave Meyer kindly added a tunnel to AS10888 at PAIX so we should > have much better connectivity for Thursday and Friday. > > If you're still having trouble, perhaps you could try an mtrace? > mtrace mbone.conference.usenix.org 224.2.192.144 for the audio, or > mtrace mbone.conference.usenix.org 224.2.187.101 for the video. Bill, et al-- I was having (for the most part) pretty good reception the last couple of days. Now I'm receiving video but no audio. I'm starting to suspect an application or user problem because I'm continuing to get control packets on the audio session, just no data. For kicks, I've appended an mtrace on the audio and video multicast addresses. Personally, for me, it's not critically important that "someone" (indefinite third-person) fix this problem, but I'm providing this info for anyone who can use it. Bruce. Mtrace from 209.179.127.5 to 146.246.243.44 via group 224.2.192.144 Querying full reverse path... 0 stennis.ca.sandia.gov (146.246.243.44) -1 con243.ca.sandia.gov (146.246.243.254) PIM/Special thresh^ 0 -2 snl-outnet.ca.sandia.gov (146.246.250.254) PIM/Special thresh^ 0 -3 esnetatm-outnetfddi.llnl.gov (192.188.35.16) PIM/Special thresh^ 32 -4 lbl-mcp2p-llnl.es.net (198.129.78.125) PIM/Special thresh^ 0 -5 ames2-mcp2p-lbl.es.net (134.55.33.2) PIM/BGP4+ thresh^ 64 -6 ? (198.9.201.254) PIM/BGP4+ thresh^ 0 -7 pao5.pao4.verio.net (198.9.200.1) PIM/Special thresh^ 0 Reached RP/Core -8 mbone.conference.usenix.org (209.179.127.5) DVMRP thresh^ 64 -9 mbone.conference.usenix.org (209.179.127.5) Round trip time 58 ms; total ttl of 68 required. Waiting to accumulate statistics...Results after 10 seconds: Source Response Dest Overall Packet Statistics For Traffic From 209.179.127.5 224.0.1.32 Packet 209.179.127.5 To 224.2.192.144 v __/ rtt 61 ms Rate Lost/Sent = Pct Rate 209.179.127.5 mbone.conference.usenix.org v ^ ttl 65 23 pps 0/2 = -- 0 pps 129.250.16.158 198.9.200.1 pao5.pao4.verio.net Reached RP/Core v ^ ttl 65 147 pps 0/2 = -- 0 pps 198.9.200.2 198.9.201.254 ? v ^ ttl 65 386 pps 0/2 = -- 0 pps 198.9.201.13 134.55.33.2 ames2-mcp2p-lbl.es.net v ^ ttl 68 404 pps 0/2 = -- 0 pps 134.55.33.1 198.129.78.125 lbl-mcp2p-llnl.es.net v ^ ttl 68 413 pps 0/2 = -- 0 pps 198.129.78.126 192.188.35.16 esnetatm-outnetfddi.llnl.gov v ^ ttl 68 56 pps 0/2 = -- 0 pps 192.188.35.3 146.246.250.254 snl-outnet.ca.sandia.gov v ^ ttl 68 46 pps 0/2 = -- 0 pps 146.246.250.252 146.246.243.254 con243.ca.sandia.gov v \__ ttl 68 26 pps ?/2 0 pps 146.246.243.44 146.246.243.44 Receiver Query Source Mtrace from 209.179.127.5 to 146.246.243.44 via group 224.2.187.101 Querying full reverse path... 0 stennis.ca.sandia.gov (146.246.243.44) -1 con243.ca.sandia.gov (146.246.243.254) PIM/Special thresh^ 0 -2 snl-outnet.ca.sandia.gov (146.246.250.254) PIM/Special thresh^ 0 -3 esnetatm-outnetfddi.llnl.gov (192.188.35.16) PIM/Special thresh^ 32 -4 lbl-mcp2p-llnl.es.net (198.129.78.125) PIM/Special thresh^ 0 -5 ames2-mcp2p-lbl.es.net (134.55.33.2) PIM/BGP4+ thresh^ 64 -6 ? (198.9.201.254) PIM/BGP4+ thresh^ 0 -7 pao5.pao4.verio.net (198.9.200.1) PIM/Special thresh^ 0 Reached RP/Core -8 mbone.conference.usenix.org (209.179.127.5) DVMRP thresh^ 64 -9 mbone.conference.usenix.org (209.179.127.5) Round trip time 56 ms; total ttl of 68 required. Waiting to accumulate statistics...Results after 10 seconds: Source Response Dest Overall Packet Statistics For Traffic From 209.179.127.5 224.0.1.32 Packet 209.179.127.5 To 224.2.187.101 v __/ rtt 481 ms Rate Lost/Sent = Pct Rate 209.179.127.5 mbone.conference.usenix.org v ^ ttl 65 19 pps 0/189 = 0% 18 pps 129.250.16.158 198.9.200.1 pao5.pao4.verio.net Reached RP/Core v ^ ttl 65 158 pps 0/189 = 0% 18 pps 198.9.200.2 198.9.201.254 ? v ^ ttl 65 404 pps 0/189 = 0% 18 pps 198.9.201.13 134.55.33.2 ames2-mcp2p-lbl.es.net v ^ ttl 68 387 pps -1/189 = 0% 18 pps 134.55.33.1 198.129.78.125 lbl-mcp2p-llnl.es.net v ^ ttl 68 422 pps 7/190 = 3% 19 pps 198.129.78.126 192.188.35.16 esnetatm-outnetfddi.llnl.gov v ^ ttl 68 39 pps 0/183 = 0% 18 pps 192.188.35.3 146.246.250.254 snl-outnet.ca.sandia.gov v ^ ttl 68 33 pps 0/183 = 0% 18 pps 146.246.250.252 146.246.243.254 con243.ca.sandia.gov v \__ ttl 68 21 pps ?/183 18 pps 146.246.243.44 146.246.243.44 Receiver Query Source --==_Exmh_-298410366P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN2GHfajOOi0j7CY9AQHvHQP/eTApQN1KvbH5xLEx06kqx3Dj6jEOb5I6 MUlOgGZYPdw+KXlOo5yIRCcXnwxCdu5DYHAGflj5IZBVxsUhl6dCl0lqJ6AH+pHu IYU/OJdyHvlNCClKnHpp8XIQXBXREHbvLZKA7fIUUEfaTm+zxPLEyVRtW8N7Eykh PjnvdNVnu58= =9hCV -----END PGP MESSAGE----- --==_Exmh_-298410366P-- From rem-conf Mon Jun 14 08:52:27 1999 From rem-conf-request@es.net Mon Jun 14 08:52:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10tYj2-00000x-00; Mon, 14 Jun 1999 08:32:40 -0700 Received: from tnint06.telogy.com [209.116.120.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10tYj1-00000k-00; Mon, 14 Jun 1999 08:32:39 -0700 Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Jun 1999 11:32:37 -0400 Message-ID: <61891BA043DED21180920090273F173802E71D@argentina.telogy.com> From: Roy Spitzer To: 'Henning Schulzrinne' , Fatih Erdin Cc: "Fox, Mike" , Graeme Gibbs , "'rem-conf@es.net'" , Zoran Mladenovic Subject: RE: Additional Named Signal Events Date: Mon, 14 Jun 1999 11:32:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We at Telogy Networks, Inc. believe there is some confusion here. Our modem expert offers this explanation. There is a confusion between V.8 and V.25 with the modulation mode (V.32 or V.34 or V.90). With V.32 modems, one of the major problems was lack of specified automoding procedure (how you fall back to V.22, V.22bis etc.). People realized the need to do it up front (during the standardization of V.34), in the very first phase of handshake. That is how V.8 was created. As a means to distinguish V.8 capable modem, from non-V.8 modems (or modems that typically, but not necessarily comply with V.25), ANSam was used. During the standardization process, special attention was given to the fact that all installed network devices need to continue functioning properly in the presence of ANSam (i.e. echo cancellers in particular). Now, noting prevents modem manufacturers to manufacture V.32 modem, with the V.8 handshake up front. Most, if not all, of V.32 designs are old designs and consequently they support V.25 only. As far as discussion going on, I am not sure exactly what was the point. V.8 does not specifically mention ANSam w/o phase reversals, although in some cases (fax for example), it might be beneficial to have network echo cancellers present. In my opinion, V.8 does not exclude ANSam w/o phase reversals either. Regards, Roy Roy Spitzer Telogy Networks, Inc. Phone: (301) 515-6531 20250 Century Blvd. Fax: (301) 515-7954 Germantown, MD 20874 Email: rspitzer@telogy.com -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Friday, June 11, 1999 10:41 AM To: Fatih Erdin Cc: Fox, Mike; Graeme Gibbs; 'rem-conf@es.net' Subject: Re: Additional Named Signal Events Fatih Erdin wrote: > > > > But in this case, the calling terminal can not distinguish whether the > called terminal is V.32 (sends /ANS, 2100Hz with phase reversal as answer > tone) or V.34 (ANSam, 2100Hz + PR + AM) and thinks it as V.34, even though > it's V.32 actually. According to V.8 and V.25, ANSam is a sinewave signal at 2100 Hz with phase reversals at 450 ms, and amplitude-modulated. V.32 uses ANS (no phase reversals), from what I can tell. I don't see a separate /ANS signal mentioned in the V.32 spec. Can somebody point me to the section. (V.32 does mention that it uses the V.25 startup procedure.) From rem-conf Mon Jun 14 18:07:01 1999 From rem-conf-request@es.net Mon Jun 14 18:06:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10thcE-0006gR-00; Mon, 14 Jun 1999 18:02:14 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10thcD-0006gD-00; Mon, 14 Jun 1999 18:02:13 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA07142; Mon, 14 Jun 1999 21:01:48 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA25036; Mon, 14 Jun 1999 21:01:47 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3765A5FB.306B41BE@cs.columbia.edu> Date: Mon, 14 Jun 1999 21:01:47 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net CC: Scott Petrack , Terry G Lyons Subject: DTMF draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Since there seems to be general interest in moving this draft along quickly, I'd like to make sure that the one technical change made to the DTMF part receives proper comment at this stage. Previously, the DTMF digit extended (logically) backward in time. For example, a timestamp of 1000 and a duration of 50 meant that the digit started at 950 and continued until 1000. Unfortunately, this contradicts the definition of timestamps in the RTP spec, which refer to the "first sample". We don't have samples here, but it makes more sense to have time "move forward" as for all other media types, so that if we send both audio and DTMF, the same timestamp refers to the same position in time. This makes playout algorithms work naturally. The only effect of this change seems to be that you get multiple DTMF packets with the same timestamp (and increasing duration), but that seems harmless. Comments are appreciated. Since the general discussion seems to have subsided a bit, I will submit the draft as an I-D by mid-week. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Jun 14 21:46:04 1999 From rem-conf-request@es.net Mon Jun 14 21:46:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10tl3a-0001kB-00; Mon, 14 Jun 1999 21:42:42 -0700 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 10tl3W-0001ju-00; Mon, 14 Jun 1999 21:42:40 -0700 Received: from accordion (acsys-temp1.anu.edu.au [150.203.20.65]) by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id OAA11242; Tue, 15 Jun 1999 14:41:57 +1000 (EST) Message-Id: <3.0.32.19990615144202.00a54210@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 15 Jun 1999 14:42:07 +1000 To: mbone@isi.edu, multicast@apan.net, multicast-eng@apan.net From: Markus Buchhorn Subject: Global Graphical Session Directory Monitor Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All By stomping on the shoulders of giants (Kevin Almeroth and Peter Parnes) I've finally built something I drew up nearly 5 years ago :-) http://mbone.au.apan.net/MSDL MSDL is a worldwide session directory monitor, using input from Almeroth sites (sdr-plugin) and mSD sites (Parnes Java code) and some mSD-clones around the globe, together with some bodgy geography and suspect Perl code to produce a (geo+)graphical log of global (ttl >= 127) session advertisements on the MBONE over the last 24 hours. At this stage it shows around 50 sites in 3 regions (Asia Pacific, North America, Europe), with a graph of the total count of sessions over the last 24 hours at 15 minute intervals (where appropriate). Graphs are displayed in a semi-geographically-correct fashion, so that you can eyeball regions with problems. Each graph is itself a link to a high-resolution graph, plus any others at the same "site" (city). See the top page for details. It does not yet show connectivity between sites, nor view-ability on a per-session basis. The latter I am working on right now. The former is harder... This is distinctly v1.0 code, and is bound to contain bugs. :-) I'd appreciate any comments, suggestions, bug reports, etc. At the bottom of the main page you will see my current ToDo list. I'd also appreciate any 'ground-truth' data, i.e. if your site is shown do you actually see the number of sessions I attribute to you. If you'd like to see your site involved, I'd suggest either installing mSD and letting me know, or installing Kevin Almeroth's sdr-plugin and I will automatically pick you up. The latter also increases Kevin's sample size, so I would recommend that (even though I personally prefer mSD's approach :-)). Or do both ! A heartfelt "Thank you" to Kevin and Peter for their great efforts/code, without which I'd still be at the drawing board. Cheers, Markus Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Tue Jun 15 07:04:10 1999 From rem-conf-request@es.net Tue Jun 15 07:04:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ttlT-0006ka-00; Tue, 15 Jun 1999 07:00:35 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ttlS-0006kQ-00; Tue, 15 Jun 1999 07:00:34 -0700 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id HAA23109 for ; Tue, 15 Jun 1999 07:00:32 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id HAA25674 for rem-conf@es.net; Tue, 15 Jun 1999 07:00:22 -0700 (PDT) Date: Tue, 15 Jun 1999 07:00:22 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199906151400.HAA25674@jackson.cs.ucsb.edu> To: rem-conf@es.net Subject: Re: Global Graphical Session Directory Monitor X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>If you'd like to see your site involved, I'd suggest either installing mSD >>and letting me know, or installing Kevin Almeroth's sdr-plugin and I will >>automatically pick you up. The latter also increases Kevin's sample size, >>so I would recommend that (even though I personally prefer mSD's approach >>:-)). Or do both ! Let me encourage a few more people to join the sdr-monitor effort. If you are running a recent version of sdr on a unix platform the sdr-plugin takes two seconds to install and the data will help tremendously. Check us out at http://imj.ucsb.edu/sdr-monitor/global/ -Kevin From rem-conf Tue Jun 15 16:44:12 1999 From rem-conf-request@es.net Tue Jun 15 16:44:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10u2kq-0005Bu-00; Tue, 15 Jun 1999 16:36:32 -0700 Received: from sd-exchange.nuera.com (exchangesvr.nuera.com) [204.216.240.106] by mail1.es.net with esmtp (Exim 1.81 #2) id 10u2kp-0005BB-00; Tue, 15 Jun 1999 16:36:31 -0700 Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Jun 1999 16:19:05 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE037AC0@SD_EXCHANGE> From: "Fox, Mike" To: Henning Schulzrinne , Scott.Petrack@metatel.com Cc: rem-conf@es.net Subject: RE: DTMF draft Date: Tue, 15 Jun 1999 16:18:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Henning and Scott, I was just going over the June 99 issue of Computer Telephony where four VOIP products were tested in a "Branch Office VoIP Gateway Shootout!". I think there is a better spec. is better mentality in equipment buyers, and every vendor would like to have the fewest DTMF failures when tested on a congested network. It appears that one product implements an error corrected channel for DTMF, and in doing so achieves a significantly better DTMF transmission performance than the other products. I think that all of the other products use some sort of a redundancy scheme. I am raising the question of if perhaps a more "reliable" channel can be *optionally* constructed using the RTP tones payload format. A possible mechanism would be to optimize the redundancy mechanism by allowing full duplex connection of the RTP tones to ACK the receipt of each RTP tones packet back toward the source. This way the source can then efficiently remove or maintain the redundant information in the transmission. I hate to open this can of worms again, but the basis of much of the redundancy and reliability discussions in the VOIP Forum and rem-conf did not anticipate that specific test scenarios would be used to compare equipment. Best regards, Mike Fox From rem-conf Tue Jun 15 17:06:21 1999 From rem-conf-request@es.net Tue Jun 15 17:06:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10u3BI-00061Q-00; Tue, 15 Jun 1999 17:03:52 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10u3BC-000611-00; Tue, 15 Jun 1999 17:03:47 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA09838; Tue, 15 Jun 1999 20:03:33 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA13552; Tue, 15 Jun 1999 20:03:32 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3766E9D3.FAD92E70@cs.columbia.edu> Date: Tue, 15 Jun 1999 20:03:31 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Fox, Mike" CC: Scott.Petrack@metatel.com, rem-conf@es.net Subject: Re: DTMF draft References: <613A6A6A3F09D3118F5C00508B2C24FE037AC0@SD_EXCHANGE> 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: > > Hi Henning and Scott, > I was just going over the June 99 issue of Computer Telephony where four > VOIP products were tested in a "Branch Office VoIP Gateway Shootout!". I > think there is a better spec. is better mentality in equipment buyers, and > every vendor would like to have the fewest DTMF failures when tested on a > congested network. It appears that one product implements an error corrected > channel for DTMF, and in doing so achieves a significantly better DTMF > transmission performance than the other products. I think that all of the > other products use some sort of a redundancy scheme. > > I am raising the question of if perhaps a more "reliable" channel can be > *optionally* constructed using the RTP tones payload format. The current scheme is already rather reliable. In the case of an auto-dialer dialing a standard xxx xxx-xxxx number, you would end up sending every digit between three and ten times. If you want to add true NACK-based reliability, you could fall back to RFC 2032, Section 5.2.2. > > A possible mechanism would be to optimize the redundancy mechanism by > allowing full duplex connection of the RTP tones to ACK the receipt of each > RTP tones packet back toward the source. This way the source can then > efficiently remove or maintain the redundant information in the > transmission. > > I hate to open this can of worms again, but the basis of much of the > redundancy and reliability discussions in the VOIP Forum and rem-conf did > not anticipate that specific test scenarios would be used to compare > equipment. > > Best regards, > Mike Fox -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Jun 15 19:20:47 1999 From rem-conf-request@es.net Tue Jun 15 19:20:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10u5GB-00008S-00; Tue, 15 Jun 1999 19:17:03 -0700 Received: from renown.concentric.net (renown.cnchost.com) [207.155.248.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10u5GA-00008I-00; Tue, 15 Jun 1999 19:17:02 -0700 Received: from ts006d37.cht-ma.concentric.net (ts006d37.cht-ma.concentric.net [206.173.20.49]) by renown.cnchost.com (8.9.3/) id WAA23622; Tue, 15 Jun 1999 22:16:56 -0400 (EDT) [ConcentricHost SMTP Relay 1.5] Date: Tue, 15 Jun 1999 22:18:43 -0400 (EDT) From: Scott Petrack To: "Fox, Mike" cc: Henning Schulzrinne , rem-conf@es.net Subject: RE: DTMF draft In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FE037AC0@SD_EXCHANGE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The bit rate is so low that you can do a lot of things with this scheme. Since packets tend to get lost in bursts, delaying some packets just a little bit helped a lot in certain cases, and so did layering (so that the DTMF stream is actually sent over radically different paths in the Internet between the two endpoints). There was a time when I was playing with some RTCP receiver reports which reported about a specific payload format, so that the receiver could report some specific statistics about the receipt of the DTMF payload. Although it looked sort of promising, I never finished and closed on the whole issue of "if I send enough DTMF to get a statistically useful sample, then the statistics are very similar to the ordinary receiver reports for the whole stream." If any one else has done this sort of stuff in the context of layered codecs, I'd be sort of curious to know. Thinking of the DTMF payload as working together with the audio payload in a layered codec scheme, I would be very surprised if you would get DTMF transmission that is worse than the PSTN. explicit ACKS and such is a terrible thing to do to a realtime bitstream. Scott On Tue, 15 Jun 1999, Fox, Mike wrote: > Hi Henning and Scott, > I was just going over the June 99 issue of Computer Telephony where four > VOIP products were tested in a "Branch Office VoIP Gateway Shootout!". I > think there is a better spec. is better mentality in equipment buyers, and > every vendor would like to have the fewest DTMF failures when tested on a > congested network. It appears that one product implements an error corrected > channel for DTMF, and in doing so achieves a significantly better DTMF > transmission performance than the other products. I think that all of the > other products use some sort of a redundancy scheme. > > I am raising the question of if perhaps a more "reliable" channel can be > *optionally* constructed using the RTP tones payload format. > > A possible mechanism would be to optimize the redundancy mechanism by > allowing full duplex connection of the RTP tones to ACK the receipt of each > RTP tones packet back toward the source. This way the source can then > efficiently remove or maintain the redundant information in the > transmission. > > I hate to open this can of worms again, but the basis of much of the > redundancy and reliability discussions in the VOIP Forum and rem-conf did > not anticipate that specific test scenarios would be used to compare > equipment. > > Best regards, > Mike Fox > > From rem-conf Wed Jun 16 09:30:01 1999 From rem-conf-request@es.net Wed Jun 16 09:30:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uITu-0000NE-00; Wed, 16 Jun 1999 09:24:06 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10uITt-0000N4-00; Wed, 16 Jun 1999 09:24:06 -0700 Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by dirty; Wed Jun 16 12:22:32 EDT 1999 Received: from dnrc.bell-labs.com (bombay [135.180.160.73]) by sea.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id MAA24396; Wed, 16 Jun 1999 12:19:36 -0400 (EDT) Message-ID: <3767CEE9.35BA321C@dnrc.bell-labs.com> Date: Wed, 16 Jun 1999 12:20:57 -0400 From: Sanjoy Paul Organization: Bell Laboratories X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, int-serv@ISI.EDU, isadsoc@fokus.gmd.de, itc@ieee.org, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qosws@dstc.edu.au, qos-iso@mci.org.uk, rem-conf@es.net, reres@laas.fr, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org Subject: IEEE Network Magazine Special Issue on Multicasting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks: the deadline for IEEE Network Special Issue on Multicasting is coming up (July 1). You may take an additional week for submission given that INFOCOM deadline is also July 1. You may find the details of the announcement and submission procedure at http://www.comsoc.org/socstr/techcom/ntwrk/special/cfp-paul.html Looking forward to your submissions. Regards, Sanjoy Paul From rem-conf Wed Jun 16 15:28:40 1999 From rem-conf-request@es.net Wed Jun 16 15:28:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uO7t-0004Vv-00; Wed, 16 Jun 1999 15:25:45 -0700 Received: from cr480472-a.slnt1.on.wave.home.com (server.mindstep.com) [24.112.33.138] by mail1.es.net with smtp (Exim 1.81 #2) id 10uO7r-0004Vi-00; Wed, 16 Jun 1999 15:25:43 -0700 Received: (qmail 24859 invoked from network); 16 Jun 1999 22:24:42 -0000 Received: from pm6100.local.mindstep.com (HELO ?192.168.55.3?) (192.168.55.3) by local.mindstep.com with SMTP; 16 Jun 1999 22:24:42 -0000 Delivered-To: patrick@mindstep.com Received: (qmail 24516 invoked from network); 16 Jun 1999 19:48:48 -0000 Received: from gateway.mitel.ca (HELO pong.gandalf.com) (198.53.180.130) by cr480472-a.slnt1.on.wave.home.com with SMTP; 16 Jun 1999 19:48:48 -0000 Received: from mindstep.com (localhost) by pong.gandalf.com (4.1/SMI-4.1) id AA00602; Wed, 16 Jun 99 15:47:15 EDT Sender: pbf@mindstep.com Message-Id: <3767FF43.F07CFA90@mindstep.com> Date: Wed, 16 Jun 1999 15:47:15 -0400 From: Patrick Bihan-Faou Reply-To: patrick@mindstep.com Organization: MindStep Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: rem-conf@es.net Subject: Questions about the recommended FEC protection operation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UIDL: 7f321b62c4f178077aa16d716f56a497 Old-Status: RO X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I went back about a year in the archive for the mailing list, and I have not seen any discussion about the "protection operation" described in "draft-ietf-avt-fec-05.txt". Maybe I am missing the point completely, but it seems to me that there are some major problems with the recommended protection operation. I have included its description at the end of the message. The problem I see is that: - the 2 version bits from the original RTP packet beeing protected are dropped - only 3 out of the 4 bits of the CC field of the original RTP packet are kept. I can not see any justification for that, but I can find a lot of arguments against these 2 points. First, which 3 out of the 4 bits of the CC field should be kept ? Why not include the 4 of them ? Why insisting on discarding the version field ? The obvious results of these choices to me is that almost the entire original RTP packet has to be shifted by 3 bits in order to produce something that complies with the recommended protection operation. It seems to me that this requires a lot of work for no benefits at all since the RTP packets have to be padded to 4 bytes boundaries anyway. I can understand that there is no need to protect the version field since the value never changes, but it seems that shifting everything is a lot of trouble just to not transmit 2 bits that don't change (and in the process add 2 padding bits anyway). Maybe I am missing the point completely, and if it is the case, please let me know what I missed! Thanks for you attention, Patrick. >From "draft-ietf-avt-fec-05.txt" page 8: 8 Protection Operation The protection operation involves taking a variety of fields from the various headers, appending the payloads, appending the whole thing together, padding zeroes, and then computing the FEC across the resulting binary block. The result is then placed into the FEC packet. The following procedure MUST be followed for the protection opera- tion. For each media packet to be protected, a binary array is gen- erated by appending the following fields together: o Padding Bit (1 bit) o Extension Bit (1 bit) o CC bits (3 bits) o Marker bit (1 bit) o Payload Type (7 bits) o Timestamp (32 bits) o Natural binary representation of the length of the CSRC List plus padding plus payload plus extension of the media packet (16 bits) o CSRC List (if CC is 1), else null (variable) o Header Extension (if X is 1), else null (variable) o the payload (variable) o Padding, if present (variable) Note that the padding bit forms the most significant bit of the binary array. >From RFC 1889 page 10 5.1 RTP Fixed Header Fields The RTP header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- et les Shadoks pompaient... From rem-conf Wed Jun 16 18:44:01 1999 From rem-conf-request@es.net Wed Jun 16 18:44:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uR7z-0006wi-00; Wed, 16 Jun 1999 18:38:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10uR7y-0006wY-00; Wed, 16 Jun 1999 18:38:02 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Wed Jun 16 21:37:35 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.215]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA18295; Wed, 16 Jun 1999 21:37:33 -0400 (EDT) Message-ID: <37685184.2FD71A0C@dnrc.bell-labs.com> Date: Wed, 16 Jun 1999 21:38:12 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: patrick@mindstep.com CC: rem-conf@es.net Subject: Re: Questions about the recommended FEC protection operation References: <3767FF43.F07CFA90@mindstep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Patrick Bihan-Faou wrote: > > The problem I see is that: > - the 2 version bits from the original RTP packet beeing protected are > dropped This is on purpose. If the version were included in the protection operation, the value written into the V field in the FEC packet would not likely be 2. The version is used for many RTP validity checks. As such, I believe its important to keep it as 2. Since the version does not change from packet to packet in a session, there is nothing gained by recovering it. > - only 3 out of the 4 bits of the CC field of the original RTP packet > are kept. This is an error. Its been corrected. It should, of course, read 4 bits everywhere. Thanks for pointing it out. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Jun 16 21:00:38 1999 From rem-conf-request@es.net Wed Jun 16 21:00:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uTHH-0000pf-00; Wed, 16 Jun 1999 20:55:47 -0700 Received: from nefeli.forthnet.gr [193.92.150.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10uTHF-0000ny-00; Wed, 16 Jun 1999 20:55:46 -0700 Received: from 8849bvd34314 (assinik.ath.forthnet.gr [193.92.136.196]) by nefeli.forthnet.gr (8.8.5/8.8.5) with SMTP id OAA17315; Wed, 16 Jun 1999 14:43:06 +0300 (EET DST) Message-Id: <3.0.2.32.19990616144040.00910a10@popper.forthnet.gr> X-Sender: ASSINIK.ATH.FORTHNET.GR@popper.forthnet.gr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Wed, 16 Jun 1999 14:40:40 +0100 To: assinik@unipi.gr From: Nikitas Assimakopoulos Subject: JASS Journal - Call for Papers Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------------------------------------------------------------------------- We apologize if you receive this message more than once. ------------------------------------------------------------------------- JOURNAL OF APPLIED SYSTEMS STUDIES Methodologies and Applications for Systems Approaches [ JASS ] http://www.unipi.gr/jass/ CALL FOR PAPERS Topics of interest to JASS include : =B7 Applications of cybernetics using the viable system model =B7 Applications of interactive planning methodology =B7 Applications of soft systems methodology =B7 Applied cybernetics in medicine =B7 Applied living systems =B7 Applied sociocybernetics =B7 Cognitive patterns =B7 Complex systems =B7 Conceptual systemic models =B7 Control systems =B7 Critical systems thinking =B7 Culture of peace =B7 Decision support systems =B7 Dynamical systems approaches =B7 Electronic service systems (Internet, Intranet, Extranet, Deltanet) =B7 Human-centered systems =B7 Human-computer interaction =B7 Intelligent systems engineering =B7 Intelligent tutoring systems =B7 Knowledge based systems =B7 Law systems =B7 Multimedia systems =B7 Problem structuring approaches =B7 Project management using systemic approaches =B7 Religious systems =B7 Semiotic approaches =B7 Social systems design =B7 Systemic metaphors =B7 Systemic reengineering =B7 Systems - metasystems and decisions - metadecisions =B7 Systems and design education =B7 Systems approaches for information systems =B7 Systems thinking for total quality management =B7 Total systems intervention =B7 Virtual communities There is no time limit for the submission of papers. From rem-conf Thu Jun 17 05:09:12 1999 From rem-conf-request@es.net Thu Jun 17 05:09:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uati-0006Nh-00; Thu, 17 Jun 1999 05:03:58 -0700 Received: from cr480472-a.slnt1.on.wave.home.com (server.mindstep.com) [24.112.33.138] by mail1.es.net with smtp (Exim 1.81 #2) id 10uath-0006NK-00; Thu, 17 Jun 1999 05:03:57 -0700 Received: (qmail 26334 invoked from network); 17 Jun 1999 12:02:56 -0000 Received: from pm6100.local.mindstep.com (HELO ?192.168.55.3?) (192.168.55.3) by local.mindstep.com with SMTP; 17 Jun 1999 12:02:56 -0000 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Thu, 17 Jun 1999 08:02:56 -0400 Subject: Re: Questions about the recommended FEC protection operation From: "Patrick Bihan-Faou" To: Jonathan Rosenberg CC: rem-conf@es.net Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Jonathan Rosenberg wrote: > > Patrick Bihan-Faou wrote: >> >> The problem I see is that: >> - the 2 version bits from the original RTP packet beeing protected are >> dropped > > This is on purpose. If the version were included in the protection > operation, the value written into the V field in the FEC packet would > not likely be 2. The version is used for many RTP validity checks. As > such, I believe its important to keep it as 2. Since the version does > not change from packet to packet in a session, there is nothing gained > by recovering it. > Of course I am not arguing the fact that there is little gained in "protecting" a value that never changes, neither do I contest that having the version field set to 2 is necessary. My point is that by forcing this field out of the protected data set, forces the ENTIRE original RTP packet to be shifted by 2 bits. Then since we are sending an integral number of BYTES, these two bits are going to be added at the end of the data set and are likely to contain another totally useless value as far as the protection operation goes. So my point is that I do not understand why 1. we should shift X bytes by 2 bits 2. add 2 bits of padding 3. compute the protection function 4. transmit the protection RTP packet then 5. execute the recovery function on the received protection packet 6. shift the resulting byte array by 2 bits 7. add the version field with the value 2 back. It looks to me that operation 1 and 2 as well as 6 and 7 are unnecessary considering that we are not even saving on the bandwidth used on the internet, increase the computational requirements, and maybe the memory requirement on the end units of the RTP session. Furthermore I could argue that by leaving the version field in there, you may enable protection of future versions of RTP with an RTP/RTCP version 2 session. However I do not consider that as a good point... So the question (in my mind) remains unanswered. Thanks for your help! Patrick. -- Patrick Bihan-Faou, email: patrick.bihan-faou@mindstep.com MindStep Corporation tel: (613) 526 5062 fax: (613) 526 2417 web: www.mindstep.com From rem-conf Thu Jun 17 08:24:24 1999 From rem-conf-request@es.net Thu Jun 17 08:24:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10udvK-00012I-00; Thu, 17 Jun 1999 08:17:50 -0700 Received: from tnint06.telogy.com [209.116.120.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10udvI-000128-00; Thu, 17 Jun 1999 08:17:48 -0700 Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id ; Thu, 17 Jun 1999 11:17:39 -0400 Message-ID: <61891BA043DED21180920090273F173802E737@argentina.telogy.com> From: Roy Spitzer To: 'Henning Schulzrinne' , rem-conf@es.net Cc: Scott Petrack , MEGACO@standards.nortelnetworks.com, Ed Morgan , Mihai Sirbu , Zoran Mladenovic , Frank Fruth Subject: RE: First cut at DTMF/tones draft Date: Thu, 17 Jun 1999 11:17:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning, I apologize for my late comments. I applaud the reuse of the current RTP definitions for DTMF. The application of the same technique for supervisory signaling is desirable. 1. The problem I have is that VoIP and the use of RTP is fast becoming an international set of procedures. To be compatible with the differing encoding of supervisory signaling, the prime emphasis should be towards creating a standard set of supervisory signal (event) names as discussed in section 5. The translation of these names becomes a function of the Media Gateway. These name could translate to standard country encodings or custom audio response messages. This need not be known by the generator of the signal (event). 2. Item 1 is fine when there is a translation of the signal (event). For the cases when there is no translation of the signal (event) the associated tones may be used. But this may cause confusion at the destination end since that combination of tones may already be assigned to another signal(event). The other alternative is to drop those signals on the floor. Obviously, there if there is no translation table, all signals would be dropped on the floor. The other alternative is to use the local signal translation if present, used the associated tones when not present, and drop unknown signals on the floor only when local signal translation is present. Please comment on this. 3. To support V.34 Modems and V.34 FAX phase reversal needs as either a parameter to CED or as distinguishable event. 4. I am confused about the meaning of the events * V.21 Channel 1, "0" * V.21 Channel 1, "1" * V.21 Channel 2, "0" * V.21 Channel 2, "1" 5. Is V.21 flag indication available? Regards, Roy Roy Spitzer Telogy Networks, Inc. Phone: (301) 515-6531 20250 Century Blvd. Fax: (301) 515-7954 Germantown, MD 20874 Email: rspitzer@telogy.com -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, June 09, 1999 10:02 AM To: rem-conf@es.net Cc: Scott Petrack; MEGACO@standards.nortelnetworks.com Subject: First cut at DTMF/tones draft I've put the PostScript and PDF versions of the merged DTMF and tones draft at http://www.cs.columbia.edu/~hgs/rtp/doc/dtmf/tones.pdf and tones.ps. Scott and I would appreciate your comments. I will turn this into an (ASCII) I-D shortly, barring "you must be crazy" comments. Thanks. From rem-conf Thu Jun 17 13:52:05 1999 From rem-conf-request@es.net Thu Jun 17 13:52:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uj2Q-0004ks-00; Thu, 17 Jun 1999 13:45:30 -0700 Received: from imo17.mx.aol.com [198.81.17.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10uj2P-0004kU-00; Thu, 17 Jun 1999 13:45:29 -0700 Received: from TECemail@aol.com (2613) by imo17.mx.aol.com (IMOv20) id kZHLa08017; Thu, 17 Jun 1999 16:41:29 -0400 (EDT) From: TECemail@aol.com Message-ID: Date: Thu, 17 Jun 1999 16:41:29 EDT Subject: The Education Coalition (TEC) Newsletter To: carole@oxford.school.nz, Ggrath@msg.pacbell.com, Jesimin@pacbell.com, kjoffe@us.pmc-vacc.com, cannings@pepperdine.edu, garnell@phoebus.com, pinb@idx.com.au, tonipick@pldi.net, Rem-Conf@es.net, LFroese@tenet.edu, Bill.Callahan@uni.edu, leungec@rpi.edu MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: AOL for Macintosh sub 46 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Education Coalition (TEC) Newsletter An update to keep our business associates, and partners informed about TEC= =92s=20 activities in educational technology and distributed learning. For further=20 information, visit our website at TECWeb.org or call 949-369-3867.=20 TEC Newsletter June 1999 Contents:=20 Dr. Lane key speaker at KPMG Peat Marwick Summit Conference Dr. Carla Lane, Executive Director of TEC, was invited by the internationall= y=20 renowned business consulting firm, KPMG Peat Marwick, to be a key presenter=20 at their three-day "21st Century Summit Conference" in Boca Raton, Florida.=20 Considered an expert in the area of educational technologies and learning=20 styles, Dr. Lane addressed 200 top industry leaders and their alliance=20 partners on the topic of distributed learning and how the use of learning=20 styles and multiple intelligences increases the impact of learning in=20 mediated courses. TEC Personal Learning Model BETA Nears Completion Providing course material in a student=92s preferred learning style offers=20 quicker, better learning with a higher retention rate. The question becomes=20 how to ascertain learning styles for online courses. To meet this need, TEC,=20 in partnership with Performance Learning Systems of Nevada City, California,=20 is developing the Personal Learning Model (PLM); the PLM is an online=20 learning styles/ multiple intelligences (LS/MI) assessment that will=20 determine a student=92s preferred learning style and secondary learning mode= s. The PLM is not a "paper-and-pencil" type test; rather it will be a series of=20 tasks and problems to solve in a virtual environment. The responses will be=20 tracked and built into a LS/MI profile. The profile is tagged, stored in a=20 database, and passed to an online course so material can be presented in the=20 preferred learning style. PLM adheres to the Educause/Information Management=20 System (IMS) standards, and utilizes object-oriented, reusable learning=20 objects.=20 The PLM, developed in Asymetrix software, is nearing completion and we are=20 pleased to announce that BETA testing on the software will commence shortly.=20 Online Cosmetic Surgery Training Utilizes 3-D Interactive Simulation=20 TEC is currently working with Dr. James Fulton, co-developer of Retin-A, and=20 renown cosmetic/plastic surgeon in Newport Beach, California, to develop=20 web-based training for his bleeding-edge (no pun intended! ) practices. The=20 courses will be offered to physicians throughout the world. The training=20 utilizes a virtual-reality product from Eon Reality, Inc., which allows user= s=20 to manipulate and practice surgical techniques on a 3-D interactive=20 simulation of a person after watching Dr. Fulton perform a training session=20 online. TEC foresees terrific potential for the Eon software to be used in=20 any training that requires hands-on manipulation of objects, and/or is aimin= g=20 to reach the kinesthetic learner. =20 TEAMS Project Evaluation: Los Angeles County Office of Education =20 TEAMS Distance Learning brings exemplary learning opportunities to K-8=20 students, teachers, and parents across the United States through nationally=20 televised satellite broadcasts and the Internet. Learners use instructional=20 technologies to access a combination of the best features of time-dependent=20 (synchronous) video-based instruction along with time-independent=20 (asynchronous) computer access to multimedia and the Internet.=20 TEAMS is now the largest satellite distance learning provider of instruction=20 for the elementary grades in the United States. Over 140,000 students and=20 4,000 teachers from 20 states plus the District of Columbia receive direct=20 student instruction and professional development transmitted via satellite=20 >from the ETN studio facilities at the Los Angeles County Office of Education= .=20 TEAMS Distance Learning has won eleven national awards for program=20 excellence, and is highly regarded in the educational community for its=20 unique learning design which provides hands-on motivational instruction for=20 students and long term professional development for teachers. TEC conducted=20 the largest research study ever conducted on a distance learning program an= d=20 surveyed thousands of TEAMS participants over a four year period. This surve= y=20 of teachers and students demonstrated conclusively that this distance=20 learning program significantly improves instruction in the elementary and=20 middle school grades. TEC is proud to be named the evaluator for the project=20 for the eighth year. TEAMS is funded in part by Star Schools legislation through the U.S.=20 Department of Education's Office of Educational Research and Improvement=20 (O.E.R.I.). Web site http://teams.lacoe.edu/ Mountain Plains Distance Learning Partnership=20 Mountain Plains Distance Learning Partnership focuses on the needs of the=20 Native American population in the vast intermountain region which it=20 services. This partnership of four states is developing an electronic,=20 virtual campus employing a two-way audio and visual interactive connection=20 using fully scaleable high speed digital ATM microwave technology, electroni= c=20 transmission and receiving classrooms, and computer-assisted instructional=20 programming centers. Teachers are empowered to design and deliver interactiv= e=20 multimedia curricula to remote communities for K-14 students and adults usin= g=20 a comprehensive training model and multimedia curriculum strategies. =20 The project provides services in Utah, Wyoming, Colorado, and Montana. TEC=20 is moving into the third year as the project=92s evaluator and was the=20 evaluator on the Four Corners Project for three years prior to the next Star=20 Schools funding round. TEC conducted the on-site evaluation in April. The project is funded by Star Schools legislation through the U.S. Departmen= t=20 of Education=92s Office of Educational Research and Improvement (O.E.R.I.). =20 Check out the web site at http://stars-cwc.cwc.whecn.edu/ San Bernardino Student and Teacher Excellence Project (STEP) Evaluation San Bernardino County is one of the few areas in the US selected to offer it= s=20 students accelerated science and math programs based on material from NASA.=20 TEC, chosen as the evaluator of this innovative program with its winning use=20 of technology in the classroom, is working closely with the STEP staff to=20 provide total educational improvement through the integration of staff=20 development, curriculum development, home access, evaluation and technology/=20 infrastructure support. The project is built on the belief that educational=20 improvement is not a function of a single intervention, but a system of=20 interventions. TEC has completed the research design and survey instruments=20 and will conduct site surveys for four days in June. =20 High quality curriculum development is a project emphasis. Project STEP =20 targets highly focused math and science concepts and explore these concepts=20 in depth. It follows the recommendations of the Third International=20 Mathematics and Science Study (TIMSS) and the National Science Standards=20 that, "more emphasis should be placed on studying a few fundamental science=20 concepts" and limit the number of topics covered at each grade level. NASA resources are invaluable in helping students see the relevance of math=20 and science in the real world. Each Project STEP unit of study is=20 results-driven with a rigorous application activity, based on NASA project=20 resources, embedded into the curriculum. Learning progresses from=20 understanding to application, and then to application in dynamic,=20 unpredictable situations. Instruction emphasizes "doing" rather than just=20 "knowing". In collaboration with the Jet Propulsion Laboratory and the Dreyden Flight=20 Center, teachers are involved in wide variety of professional development=20 activities. Professional development activities are a key feature of the=20 STEP project with a full-time mentor teacher assigned at each project school= .=20 This commitment to on-going multi-strategy professional development supports=20 networks of teachers at the site, regional, and county levels. Web site at http://step.k12.ca.us Oakland Unified School District Core Values Project Evaluation The Oakland Unified School District received a California state Challenge=20 grant 1998. TEC has been named the evaluator and recently completed a=20 weeklong site visit for the evaluation. The Core Values Projects addresses four identified needs of its 10,694 middl= e=20 school students: They don=92t think critically or historically. They are not=20 proficient readers, writers, and speakers. They are not presented with=20 opportunities to work within a constructivist approach to learning. They do=20 not systematically use technology tools to support academic progress.=20 However, the adoption of curriculum embedded assessments has allowed Oakland=20 to go beyond measuring failure to design a data-driven program for middle=20 schools that is at the heart of this proposal.=20 The project incorporates a linked progression of content, technology skills=20 and habits of mind that move students from investigating the past to taking=20 an active citizenship role to address current community problems. To develop=20 these skills students have access to networked, multi-media research pods an= d=20 the instruction based on their usage. Professional development for teachers=20 within the LA/SS/ELD content areas connects technology, curriculum and=20 classroom practice to ensure progress in student achievement, curriculum=20 development and technology integration. Teachers are collaborating with U.C.=20 Berkeley and the Oakland Museum to create on-line resources to address=20 specific needs in the LA/SS/ELD curriculum. Schools will recruit and train=20 staff from community based organizations, technology volunteers and parents=20 to be "community service project partners," increase classroom support, and=20 continue networking classes. Teachers have "just-in-time" on-site technical=20 assistance. The district's 24 hour educational cable channel, Web page,=20 videoconferencing, and School Calling system extend staff development and th= e=20 instructional day, give access to enriched learning resources, and improve=20 home-school communications.=20 Using Project-Based Learning Strategies, OUSD Core Values students: *=09Work in Cooperative Groups- students build knowledge collaboratively,=20 encountering multiple perspectives. *=09Read and Write for Understanding- students analyze and synthesize=20 information; record reactions, thoughts, and feelings; clarify and organize=20 information using a wide variety of writing activities. *=09Use Inquiry Learning Methods- challenging problem solving and=20 research tasks that require higher-order thinking skills and multiple=20 abilities, and student ownership of work in heterogeneous groupings. *=09Use Technology as a Tool- for research, communication, and=20 production; content comes first, supported by uses of technology; students=20 are communicators and authors. *=09Demonstrate Content Knowledge- students are challenged to demonstrate=20 their knowledge and skills in various modalities and media: performance,=20 portfolio, and presentation. To Support Project-Based Learning strategies, OUSDCore Values Teachers: 1.=09Plan for and use Spiraling- topics and information build outwardly=20 and sequentially from the basic to the complex, and Scaffolding- support=20 students in ways that enable dependent success, moving towards independent=20 success 2.=09Use Standard English Proficiency (SEP) and Sheltered Instructional=20 Strategies- appeal to Diverse Learning Populations, Second Language Learners= ,=20 and Multiple Abilities, as well as instructional strategies which support an= d=20 strengthen under-prepared students. 3.=09Facilitate Group Work- tap into abilities and strengths of others,=20 develop skills communally while working with a variety of people; requires=20 teacher and student management of time and facilities. 4.=09Receive Professional Development- address best teaching practices,=20 classroom management, lesson design, meeting new teachers' needs and the new=20 needs of experienced teachers. 5.=09Use Curriculum-Embedded and Alternative, Authentic Assessments-=20 portfolio, performance, exhibition. Check out the web site at http://www.ousd.k12.ca.us/cv/ Seeking New DL Solutions: TeleCon East=20 The TeleCon East (Washington, DC, March) and TeleCon West (Anahaim, CA, Oct = )=20 conferences are super-charged shows that feature cutting-edge technologies,=20 and the opportunity to network with others focused on using technology to=20 enhance learning. The TeleCon East conference has been reconfigured to be=20 the world=92s LEADING conference in Distance Learning and, as chairs and=20 producers of the TeleCon shows, TEC is seeking examples of brand-new distanc= e=20 learning applications and products. Contact us so we can spotlight your=20 solutions ! =09 Dr. Carla Lane is co-chairing the TeleCon East show with Shirley Davis,=20 Director, Learning Innovations, PBS Adult Learning Service, who is the=20 current president of the United States Distance Learning Association (USDLA)=20 and Dr. Jolly Holden who is USDLA president-elect and Chief Learning=20 Strategist Spacenet , Inc TEC Online Courses=20 Too busy to attend a sit-down class after working all day? Join other busy=20 professionals who want to stay current in the latest trends in educational=20 technologies - enroll in a TEC online course. Customized courses are=20 available when five or more people enroll from the same organization. =20 The following courses are currently being offered: Introduction to Distributed Learning - 15 hours - asynchronous online and=20 audio conferencing - $89 An overview of the online learning environment, products, and learning model= s=20 used in presenting online education to users in diverse locations. Includes=20 the characteristics of a good candidate for online courses.=20 Using Technology to Address Learning Styles - 15 hours - asynchronous onlin= e=20 and audio-conferencing- $89 =20 For all the years since Socrates, most teachers and trainers have presented=20 information to trainees or students in one format=97lecture. However, studi= es=20 has shown that presenting information to students in their preferred learnin= g=20 style provides a learning impact more quickly, with learning easier to=20 retrieve, easier to apply, and more deeply understood. Acquire an overview o= f=20 how to addresses learning styles in online courses.=20 TEC courses are facilitated by Dr. Lane and Joanne Carle-Accornero,=20 developers and instructors for numerous online programs including UCLA, UC=20 Berkeley, and the University of Phoenix Online.=20 Course sections will have limited enrollments! For more information and to=20 enroll, call 949-369-3867. =20 TECWeb.org Tel: 949-369-3867 Fax: 949-369-3865 From rem-conf Thu Jun 17 17:28:12 1999 From rem-conf-request@es.net Thu Jun 17 17:28:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10umRw-0007V5-00; Thu, 17 Jun 1999 17:24:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10umRu-0007Uv-00; Thu, 17 Jun 1999 17:24:02 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jun 17 20:23:33 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.17]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA00617; Thu, 17 Jun 1999 20:23:30 -0400 (EDT) Message-ID: <376991AA.4E7FB66C@dnrc.bell-labs.com> Date: Thu, 17 Jun 1999 20:24:10 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Patrick Bihan-Faou CC: rem-conf@es.net Subject: Re: Questions about the recommended FEC protection operation References: <199906171203.IAA04603@zubin.dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Patrick Bihan-Faou wrote: > > > This is on purpose. If the version were included in the protection > > operation, the value written into the V field in the FEC packet would > > not likely be 2. The version is used for many RTP validity checks. As > > such, I believe its important to keep it as 2. Since the version does > > not change from packet to packet in a session, there is nothing gained > > by recovering it. > > > > Of course I am not arguing the fact that there is little gained in > "protecting" a value that never changes, neither do I contest that having > the version field set to 2 is necessary. My point is that by forcing this > field out of the protected data set, forces the ENTIRE original RTP packet > to be shifted by 2 bits. Then since we are sending an integral number of > BYTES, these two bits are going to be added at the end of the data set and > are likely to contain another totally useless value as far as the protection > operation goes. You don't send the data generated by the protection operation. It contains a portion of the header (note the SN is missing too) and the body. In any case, the specification describes the operation. Its implementation is up to you. You could just XOR the packets together and then overwrite the fields not protected (like the SN and version) with the correct values. The spec does say that you MUST follow the procedure listed. In fact, this should be a MAY, and it should say you can use any other procedure with the same results. I've changed this for the next rev. Thanks, Jonathan R. > > So my point is that I do not understand why > 1. we should shift X bytes by 2 bits > 2. add 2 bits of padding > 3. compute the protection function > 4. transmit the protection RTP packet > > then > 5. execute the recovery function on the received protection packet > 6. shift the resulting byte array by 2 bits > 7. add the version field with the value 2 back. > > It looks to me that operation 1 and 2 as well as 6 and 7 are unnecessary > considering that we are not even saving on the bandwidth used on the > internet, increase the computational requirements, and maybe the memory > requirement on the end units of the RTP session. > > Furthermore I could argue that by leaving the version field in there, you > may enable protection of future versions of RTP with an RTP/RTCP version 2 > session. However I do not consider that as a good point... > > So the question (in my mind) remains unanswered. > > Thanks for your help! > > Patrick. > > -- > Patrick Bihan-Faou, email: patrick.bihan-faou@mindstep.com > MindStep Corporation tel: (613) 526 5062 > fax: (613) 526 2417 > web: www.mindstep.com -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Fri Jun 18 07:30:51 1999 From rem-conf-request@es.net Fri Jun 18 07:30:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uzXM-00076p-00; Fri, 18 Jun 1999 07:22:32 -0700 Received: from newgate.mitel.com (Mitel.COM) [198.53.180.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10uzXI-00076b-00; Fri, 18 Jun 1999 07:22:30 -0700 Received: from Software.Mitel.COM (software.mitel.com [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id KAA17645; Fri, 18 Jun 1999 10:21:26 -0400 (EDT) Received: from woodr (woodr@woodr.cae.mitel.com [134.199.88.78]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with SMTP id KAA03544; Fri, 18 Jun 1999 10:21:25 -0400 (EDT) Sender: woodr@Mitel.COM Message-ID: <376A55E5.31C@mitel.com> Date: Fri, 18 Jun 1999 10:21:25 -0400 From: Robert Wood Organization: Mitel Corporation X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/715) MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com, rem-conf@es.net Subject: RTP multiplexing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, has any motion occured on the issue of RTP multiplexing? [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ From rem-conf Fri Jun 18 07:37:03 1999 From rem-conf-request@es.net Fri Jun 18 07:37:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10uzk8-0007Jq-00; Fri, 18 Jun 1999 07:35:44 -0700 Received: from sandbox.ca [134.117.100.128] by mail1.es.net with smtp (Exim 1.81 #2) id 10uzk7-0007Jg-00; Fri, 18 Jun 1999 07:35:43 -0700 Received: from isdn8.sandbox.ca by SandBox.ca (NX5.67e/NX3.0M) id AA17374; Fri, 18 Jun 99 10:05:38 -0400 From: "Patrick Bihan-Faou" To: "Jonathan Rosenberg" Cc: Subject: Re: Questions about the recommended FEC protection operation Date: Fri, 18 Jun 1999 10:42:16 -0400 Message-Id: <01beb998$c2a7d8a0$0b01a8c0@olivier.sandbox.ca> 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.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg wrote: >Patrick Bihan-Faou wrote: >> >> > This is on purpose. If the version were included in the protection >> > operation, the value written into the V field in the FEC packet would >> > not likely be 2. The version is used for many RTP validity checks. As >> > such, I believe its important to keep it as 2. Since the version does >> > not change from packet to packet in a session, there is nothing gained >> > by recovering it. >> > >> >> Of course I am not arguing the fact that there is little gained in >> "protecting" a value that never changes, neither do I contest that having >> the version field set to 2 is necessary. My point is that by forcing this >> field out of the protected data set, forces the ENTIRE original RTP packet >> to be shifted by 2 bits. Then since we are sending an integral number of >> BYTES, these two bits are going to be added at the end of the data set and >> are likely to contain another totally useless value as far as the protection >> operation goes. > >You don't send the data generated by the protection operation. It >contains a portion of the header (note the SN is missing too) and the >body. ??? I must really be missing something here. What do you mean by "you don't send the data generated by the protection opertation" ? You do send the resulting XOR of the selected packets you want to protect right ? Anyway, once again I am comming back to that issue, and I will until I get it (i.e. somebody gives me a reasonable reason). I understand that one may not want to send/protect unecessay data. No problem with that. I just don't agree to take it to an extreme where NOT doing so (sending unecessary / redundant data) requires a lot of additional computing power. So I will reformulate my question: - the version field which is 2 bits long is excluded from the protection mechanism, right ? - the bit field on which the XOR operation is carried is "continuous" (i.e. not unused bits / padding bits in the middle), right ? - removing 2 bits from the beginning of the bits field to be protected implies that ALL the subsequent bits have to be shifted, right ? If you answered YES to these three questions, then I will maintain that removing the version field is a questionable design decision. How many systems deal (address) with memory at the bit level ? If you are going to eliminate an integral number of bytes (as with the SN field), then I don't have any problem (even though I may argue that these days saving less than a multiple of 4 bytes is questionable). My objection is that the spec implies that you can deal with memory at the bit level where these days it is usually easier to deal with memory in 1/2/4 byte(s) units. In other words: what are you saving by eliminating 2 bits ? How much is it going to cost ? Is it worth it ? These are really the questions that I am looking answers for to stop ranting ;-). >In any case, the specification describes the operation. Its >implementation is up to you. You could just XOR the packets together and >then overwrite the fields not protected (like the SN and version) with >the correct values. The spec does say that you MUST follow the procedure >listed. In fact, this should be a MAY, and it should say you can use any >other procedure with the same results. I've changed this for the next >rev. > Well I don't have a problem with the MUST. I do not think that it would be a very good idea to have everybody implement something radically different. One of the purpose of these documents is to have compatible implementations... Thanks, Patrick (the 2 bits guy). -- Patrick Bihan-Faou, email: patrick.bihan-faou@mindstep.com MindStep Corporation tel: (613) 526 5062 fax: (613) 526 2417 web: www.mindstep.com From rem-conf Fri Jun 18 09:15:00 1999 From rem-conf-request@es.net Fri Jun 18 09:15:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10v1Dy-0001s8-00; Fri, 18 Jun 1999 09:10:38 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10v1Dx-0001ry-00; Fri, 18 Jun 1999 09:10:37 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Jun 1999 17:10:33 +0100 To: rem-conf@es.net Subject: Working group last call on SSRC sampling draft Date: Fri, 18 Jun 1999 17:10:32 +0100 Message-ID: <3224.929722232@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a two week working group last call on the Sampling of the Group Membership in RTP draft (draft-ietf-avt-rtpsample-04.txt). If no comments requiring changes are received in the next two weeks (by 2nd July), this draft will be submitted for publication as an experimental RFC. Colin From rem-conf Fri Jun 18 11:12:04 1999 From rem-conf-request@es.net Fri Jun 18 11:12:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10v357-0003ek-00; Fri, 18 Jun 1999 11:09:37 -0700 Received: from pita.cisco.com [171.71.68.13] by mail1.es.net with esmtp (Exim 1.81 #2) id 10v355-0003eQ-00; Fri, 18 Jun 1999 11:09:35 -0700 Received: from localhost (dwing@localhost) by pita.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA18029; Fri, 18 Jun 1999 11:07:54 -0700 (PDT) Date: Fri, 18 Jun 1999 11:07:54 -0700 (PDT) From: Dan Wing To: Robert Wood cc: iptel@lists.research.bell-labs.com, rem-conf@es.net Subject: Re: RTP multiplexing In-Reply-To: <376A55E5.31C@mitel.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 Fri, 18 Jun 1999 10:21 -0400, Robert Wood wrote: We have a new proposal I have been editing which will be submitted as an I-D shortly. I will also publish it on our FTP site as I expect the I-D publishing delay is getting large as we approach the I-D submission cutoff date. -Dan Wing > Hi, has any motion occured on the issue > of RTP multiplexing? > > [\] Robert Wood > > The St. Lawrence river - fresh, warm, visible diving. > > mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ > From rem-conf Fri Jun 18 13:33:56 1999 From rem-conf-request@es.net Fri Jun 18 13:33:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10v5I3-0005Pk-00; Fri, 18 Jun 1999 13:31:07 -0700 Received: from (freyja.GNSconsulting.com) [209.32.58.253] by mail1.es.net with esmtp (Exim 1.81 #2) id 10v5I1-0005PY-00; Fri, 18 Jun 1999 13:31:06 -0700 Received: by freyja.gnsconsulting.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Jun 1999 15:30:48 -0500 Message-ID: From: "David E. Taylor" To: "'rem-conf@es.net'" Subject: URGENT!!! Date: Fri, 18 Jun 1999 15:30:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEB9C9.72CD045A" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEB9C9.72CD045A Content-Type: text/plain How do I regiester my Internet Multicast? I have a live show to broadcast tomarrow. I can cast on my local net, but need to register a time and put it on MBONE. Thanks. David Taylor, MCSE CCA 218-590-3531 218-722-8231 ------_=_NextPart_001_01BEB9C9.72CD045A Content-Type: text/html Content-Transfer-Encoding: quoted-printable URGENT!!!

How do I regiester my Internet Multicast?  I = have a live show to broadcast tomarrow. I can cast on my local net, but = need to register a time and put it on MBONE.

Thanks.

David Taylor, MCSE CCA
218-590-3531
218-722-8231

------_=_NextPart_001_01BEB9C9.72CD045A-- From rem-conf Fri Jun 18 13:35:34 1999 From rem-conf-request@es.net Fri Jun 18 13:35:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10v5Lv-0005X6-00; Fri, 18 Jun 1999 13:35:07 -0700 Received: from 98ab8dc7.ipt.aol.com (255.255.255.255.) [152.171.141.199] by mail1.es.net with smtp (Exim 1.81 #2) id 10v5Lo-0005W8-00; Fri, 18 Jun 1999 13:35:05 -0700 From: To: Message-Id: <419.436329.55899329bigen@flashmail.com> Subject: ENTREPRENEURS WANTED! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Fri, 18 Jun 1999 13:35:05 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Our Company is rapidly expanding in many local & worldwide markets and is seeking several motivated individuals who are willing to dedicate a minimum of 10-hours each week working from home. If you are serious about owning Your Own Business, similar to a Franchise, that has a Simple & Proven "Blueprint for Success", Call our Toll-Free 24-hour Hotline Today! SERIOUS INQUIRIES ONLY! 1-888-248-1529 To be removed from our list,simply click reply, type remove, then send From rem-conf Fri Jun 18 13:44:12 1999 From rem-conf-request@es.net Fri Jun 18 13:44:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10v5Tz-0006wK-00; Fri, 18 Jun 1999 13:43:27 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 10v5Tw-0006wA-00; Fri, 18 Jun 1999 13:43:26 -0700 Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA24016; Fri, 18 Jun 1999 13:43:19 -0700 (PDT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Jun 1999 13:42:51 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB201362E92@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'David E. Taylor'" , "'rem-conf@es.net'" Subject: RE: URGENT!!! Date: Fri, 18 Jun 1999 13:42:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is the answer to your question Using SDR, or similar announcement tool, create a session advertisement to you out to the mbone ? Or is your question How do I connect my local network into the Mbone so other people can get multicast that I am sending out ? I fear that if it is the second you won't make tomorrow Bill -----Original Message----- From: David E. Taylor [mailto:DavidT@GNSconsulting.com] Sent: Friday, June 18, 1999 1:31 PM To: 'rem-conf@es.net' Subject: URGENT!!! How do I regiester my Internet Multicast? I have a live show to broadcast tomarrow. I can cast on my local net, but need to register a time and put it on MBONE. Thanks. David Taylor, MCSE CCA 218-590-3531 218-722-8231 From rem-conf Fri Jun 18 22:29:05 1999 From rem-conf-request@es.net Fri Jun 18 22:29:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10vCx9-0002tN-00; Fri, 18 Jun 1999 21:42:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10vCx7-0002tD-00; Fri, 18 Jun 1999 21:42:01 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sat Jun 19 00:41:43 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.230]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA14745; Sat, 19 Jun 1999 00:41:40 -0400 (EDT) Message-ID: <376B1FAA.C6C73320@dnrc.bell-labs.com> Date: Sat, 19 Jun 1999 00:42:18 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Patrick Bihan-Faou CC: rem-conf@es.net Subject: Re: Questions about the recommended FEC protection operation References: <01beb998$c2a7d8a0$0b01a8c0@olivier.sandbox.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Patrick Bihan-Faou wrote: > > >You don't send the data generated by the protection operation. It > >contains a portion of the header (note the SN is missing too) and the > >body. > > ??? > > I must really be missing something here. What do you mean by "you don't send > the data generated by the protection opertation" ? You do send the resulting > XOR of the selected packets you want to protect right ? I'm sorry. This sentence really doesn't make sense. Let me try again. The data in the protection array is not a complete or correctly formatted RTP packet. Besides the missing version number, the SN is not covered by the operation. There is also a length value that is protected, which is not present in the RTP packet but IS covered by the protection operation. So, the protection array cannot be simply transmitted, even if we added the version back in. But, see my further comments below on a way to do this anyway. > >In any case, the specification describes the operation. Its > >implementation is up to you. You could just XOR the packets together and > >then overwrite the fields not protected (like the SN and version) with > >the correct values. The spec does say that you MUST follow the procedure > >listed. In fact, this should be a MAY, and it should say you can use any > >other procedure with the same results. I've changed this for the next > >rev. > > > > Well I don't have a problem with the MUST. I do not think that it would be a > very good idea to have everybody implement something radically different. > One of the purpose of these documents is to have compatible > implementations... No, you miss the point. My statement above was that you can implement this in any other way, so long as THE RESULT IS THE SAME AS IF YOU HAD FOLLOWED THE SPECIFIED ALGORITHM. Thus interoperability is guaranteed. So, given this, let me suggest an implementation which meets exactly your non-shifting criteria. For simplicities sake, consider here a "mini RTP packet" with three fields, A, B, and C, instead of the ones normally used in RTP. A is 2 bits, B is 3 bits, and C is 3 bits. An FEC packet has B always set to 001, but the A and C fields are protected using the same basic algorithm described by the protection operation in the FEC spec. This means you would take A, append C, xor this with the other A+C fields, and then place the first 2 bits into the A field in the FEC packet, and the next 3 bits into the last three bits of the FEC packet. This has the same shift problem you describe: the protection is over 5 bits, not 8. OK - heres an alternate implementation. Take the packets being protected, and just xor them together as a single byte - fields A,B, and C. The result is a one byte packet with the A and C values the same as the resulting FEC packet from the operation in the previous paragraph. Of course, B is wrong. No problem. Set it to 001. The result is then the same FEC packet as above. Since the result is the same, we have interoperability. So, in the case of real RTP, don't shift. Include the version in the xor operation (the SN too while you're at it). Then, overwrite these in the output with the correct v and SN values. You'll need to do the length computation separately. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Jun 19 19:08:10 1999 From rem-conf-request@es.net Sat Jun 19 19:08:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10vWnc-000237-00; Sat, 19 Jun 1999 18:53:32 -0700 Received: from cr480472-a.slnt1.on.wave.home.com (server.mindstep.com) [24.112.33.138] by mail1.es.net with smtp (Exim 1.81 #2) id 10vWna-00022b-00; Sat, 19 Jun 1999 18:53:30 -0700 Received: (qmail 37115 invoked from network); 20 Jun 1999 01:52:29 -0000 Received: from pm6100.local.mindstep.com (HELO ?192.168.55.3?) (192.168.55.3) by local.mindstep.com with SMTP; 20 Jun 1999 01:52:29 -0000 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Sat, 19 Jun 1999 21:52:33 -0400 Subject: Re: Questions about the recommended FEC protection operation From: "Patrick Bihan-Faou" To: Jonathan Rosenberg CC: rem-conf@es.net Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list All right now I get it! Thank you (Jonathan Rosenberg) for your patience and explenations. I was under the impression that the resulting XOR of the protection bit field was the payload of the RTP packet transmitted. My mistake! BUt again thanks for making that clear. Sorry for the bother. Patrick. -- Et les Shadoks pompaient... From rem-conf Sun Jun 20 18:25:07 1999 From rem-conf-request@es.net Sun Jun 20 18:25:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10vsjq-0001Uc-00; Sun, 20 Jun 1999 18:19:06 -0700 Received: from iiserv.iis.sinica.edu.tw [140.109.20.250] by mail1.es.net with esmtp (Exim 1.81 #2) id 10vsjo-0001US-00; Sun, 20 Jun 1999 18:19:04 -0700 Received: from hoho.iis.sinica.edu.tw (hoho [140.109.20.202]) by iiserv.iis.sinica.edu.tw (8.8.8/8.7.5) with SMTP id JAA11883; Mon, 21 Jun 1999 09:25:37 +0800 (CST) Received: from localhost by hoho.iis.sinica.edu.tw (4.1/SMI-4.1) id AA02730; Mon, 21 Jun 99 09:19:07 CST Date: Mon, 21 Jun 1999 09:19:07 +0800 (CST) From: Jan-Ming Ho X-Sender: hoho@hoho To: rem-conf@es.net Cc: Sheng-Hsiung Huang , chinfu@iis.sinica.edu.tw, Chia-Hui Wang , Lih-Hsiang Chen , feng@iis.sinica.edu.tw Subject: request for Mbone feed Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are representing Taiwan to seek for Mbone feed to our Academic Network, Taiwan Academic Network, or TANET for short. We had long been suffering a low bandwidth connecting to international internet traffic. But, we recently upgrade our connection to the US by a T3 lease line. We appreciate it very much if we could have any institute here to provide us with permanent MBONE feed. We will run a permanent mbone root for the academic family including universities in Taiwan. We are also willing to transit this MBONE traffic to nearby countries based on the availability of physical connections and bandwidth. Thank you for your attention with Best Regards, Jan-Ming Ho, PhD Associate Editor, IEEE Transaction on Multimedia Research Fellow (O) 886-2-2788-3799 x1803 IIS, Academis Sinica (F) 886-2-2788-3799 x1606, 886-2-2782-4814 Nankang, Taipei email: hoho@iis.sinica.edu.tw Taiwan URL: http://www.iis.sinica.edu.tw/~hoho http://www.iis.sinica.edu.tw/CCL http://twstudy.sinica.edu.tw ============================================================================== From rem-conf Mon Jun 21 08:08:02 1999 From rem-conf-request@es.net Mon Jun 21 08:08:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w5VA-0006JB-00; Mon, 21 Jun 1999 07:56:48 -0700 Received: from host212-140-123-107.host.btclick.com (hotmail.com) [212.140.123.107] by mail1.es.net with smtp (Exim 1.81 #2) id 10w5V4-0006J1-00; Mon, 21 Jun 1999 07:56:43 -0700 From: To: rem-conf@es.net Subject: E-Commerce Conference - Wembley 1999 Date: Mon, 21 Jun 1999 15:56:35 Message-Id: <252.454668.595850@unknown> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="====================5453515:56====" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --====================5453515:56==== Content-Type: text/plain; charset="us-ascii" E-Commerce - the future - how? Find attached a brochure and application to join the forthcoming e-commerce exhibition being held at Wembley in July 1999. Don't get left behind come and find out what, how and why e-commerce can help your business create MORE BUSINESS. If this message has reached you by mistake please accept our apologies you will not receive another email as this is a one send campaign. Thank you for your time please enjoy the attached information. --====================5453515:56==== Content-Type: application/octet-stream; name="telezip.ZIP" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="telezip.ZIP" UEsDBBQAAAAIAJJi1SbTQptRCBsAAAB+AAAUAAAAVGVsb2dlbmljMiBGSU5B TC5kb2PsWwlwHNWZfqNjZiQxlm87+OABspHNeBjJOmwtYa3LloUlGVvYHAa2 NdOS2p7plnt6LAtCFrYIa7KESmzvLlBUEfCa2lqqiDkSdisBYshSCyxHuAoI EJwF79auoARlMD6w9vvf6271jEYI7BCTKr2pr/vd73//9f430rz04pT37nnw zAMsK13E8tmJ4SLm99T5gDqnMJmxC+26E8PDw1S1HBieSH9WaXDvfraKFQUh uqlPuJJFKmBs5yzGJrGuzV2bb3vztjfZqFRUMJPNr2Rs8GGfwM5po/t40/Bw 6bh5J10lnu/b6kdvb36s93TPDJ/7x3/PxXt6gLEyT/27sxmbn8fYmoAsj/c+ P5j7vQfzYBq2d7Ysf5U30XH8TMYOwayGQJyJ8jOon8FGJ2ffznrZ6bygEOKY 9D1jr/tOkXxn89PZn5Oo/DtPvTMu+03zb/eNnie7vMdePztly2k8uXv5TYno uKxghJ7qSYz9Ae9bZkt+ZI8/2eSs5+xnWUDqHz/vs2v2/Ovjvux97CmS3vNH GDcze7LTljrVhNGj6losFVprqilVt1KB5iWNRpJXRqPRUIuWsAydtxiWmgjz jWqyK6EOhDp702Yqrgzwimqrl7emE8gtX748VM+p0jJ4Wo+rZspS9Di3elXe nbbSphoIrO9TlS1o4Kv1WCIdV+uWhFpVU00O8I2KqatmqFGzBnhzXLMME4uo 6BdX+1Q8dCvUpvSqKaymDCgmPtsUHVW60qPpPbxJM9UYDaqv4KtMI90XajV6 db7SABGYtk0xt6gWdWw09FQ6AcKs0EbDTMT7QO/aNY2h9Zba16vqHD1NLYmp m9OmAWpFzchYyzQSCUzYXr++qf4SLjuFVinmAG9Q9C2pXBQJVmDqJpVv1CyL N2wIhDp0wZdM9oVFXVzr7gZPdIurCTVJ8kC1YvEYKLc0K22pfJcQUFI1Y+ru MDdMvqvTVOK06jZNEZOs1rFtXbXQ3K8lErxL5V1gS0+vBen0qOhiRkKherRQ 711rTWNnajcnce3CLilvdKNJw9pqrFc3oCMD7kzqdiWp6WqcazpPkLxVM5kK 85TBB4w0T6ImCSmjtdswk+gWV2NaSgP5HBXUx8Rmkn2KPnBeylYNIob3mUrM 0mJKYgwt2qyYPYYeRnXCiG3hfdBJ3dLQPSlEBBK6NXRNGYm0heUwn7FNoxnC XN0GAXQnDPDRu36Yj6g6T/Ua/SmxBVqsXxkAUaSD4ALkOEAcGeE7tqua27SY Kleh7VFVLG1Cg8M8ofaALiEyU9F0oi3p6hHVWWqPpqYEx/vVLp7SINa4mtJ6 9AhvBrFhvqvF6CcmjKaaY29SAXdzSEjd3pcwTDUe5grkA5kYukocFORrWNmR OAQIdduaVlOCPbS2oqf60ZBSU0JAYd6lpCCxdB/axZJObzTBFqRIFcldJbYl TFu0sEHalsjGLGwDNYkUL9eEkVNTXCWGWGpqUdhe1pkqwRNpPdZLtBqcFtyi G/0JNd5DHE7HernCMRDE0zSQADarmsROrJQmFoNeMBTL2NzsS4AcniJHgyFh 3qukuA7xm9Bc6IBjBUK1BKdMA9N2qaBGjXAQAQXvU0xLGoBgJExMJxOFjsRA uWJB78DtvoRKi5NQEirER73RpsR6wUET8hVyJlbFjViaLDkSCPBQyKNy67y9 muxeobX1l7c1t3fytubOlo6mEOe8nPPGXhWygBbFib4BBX6YtGPEffM1Vpxn pHL5IsfEsYiegl/xSsVRJ11JqoucZaBImsUbFTNex+uT6vYLNmgp5YI2hfxo DLVcNyK8PCvxb20Kjd/lG0vN2/s0+I0mKL6scFgFoojBvUYCSggfSGavkBuk xmtyJjTUx2JGGscCicsjgZDboMTjOMFTWVRky0qOKV/d7Tlpuk1oZBdUqX/R mGPs6f60DF1rpKCMRlxwRtIRCFSgrsn2KKH1aVMwxEmZBCMAUD3N2btpNbp4 p2Yl3OGZHQKVcCjOSnycpcZbbdRaWe2hQKDD7FF0mJtwB57WdpqTnNtmzGGJ OUZav5pA1uIYxKRJ4RV5l2GIt2eW+pzKMyqV50hjUZCrr9102rUoV7cQnGmd baU2qONKZfuoWjjxNhxydXLg6G3KFAjU8w31nTjrthkUKjgBFEXZ8jDGGeqc d+T66dDxnhyREA3POCXI/a5q4LXRGr68trqaR6uyzoAIdir9OsZFeDv6L62q jlYvj3qPnlCosaN9ZfO65vbGZt7U3Fm/es360Ibm9kubL2iq72yu42OE+Djh OAVF3nuBcy0I8zYtHt+O40FXt1Og6TRAgYl2HNfrLcSp6SRfyOvJVBZFuOD5 +VVVvDy6iFcsq+DLcS5Go7VLI2KdGIkOXOkVCynwdMmkEZesQOyjGxaXB5oM Ry0xRBduDQzvVnGmr1Pj6RgdyWTEmTNQcCDCAkT9it6DTkIqVtYGI3ACMqbJ kKCRtqWo4sx3bYqW15wgSQQ78Ou4rWgJcWYLV0uBzhpDj6OH0d0N1YiEmvWt ac1EFFPH18rAwnHnFNWpTitxNWuThvQaIs7NVgWwRK4TEbcXCs8a4EMaTOVa TcQ/o/m/bGmU11ZW1NC9ok1DHN8K75OiruglOtVW8BqoXdXypZURaR05xteG GhVQl0gIRmBXGUUZx8ioi9c6CuZw11S7KT4TEu1Ooy4h+AB2xnHxGLGFWC9u BCqpx56K6mgE6kbWY6oWxWmexVAiRekS4lf7LFXcJ0xV6UZQE+Hr0132zSol heV0gq6THVlaEmpkSwUTqXV8tSXuOZhRV2Mgji6AdLnBnClasUsdMOxbS0ze Gp14ckRaJEolAQrcbkKpZBFr2hEvlXDH6DEV3DwioQxnsFJV64SZZISb0Hqy jT1Lq5YjSE2nILFI9QK+AdsptwwLZrinqiIaiS5bxBFMu8G5NDgaHDO2EX0y 0CVO4vZimCLIh2iglL3iXkr3VVN0h6tQZSCPwJyYqhugw9tXWIKQpUdznbhY +jq+kpoR2zqe0BpjY/G0qzoyQrdUpzvd8yjMbunYyDs7+LrmVavXdzavCzUM fImiSk++XnUFJgP6rCCerivS3GMyFIekYjJaFnGxc+2xjLpsMwzzqgoE8BoG wgOsMxTcHqRZhnn7xkq+tL49Elrr3CMhn3Uq3S5HtJcUTVrMAIqJBEliLJt1 6zPMFKKFiJLplDCDbiOBWA87xHyZW3a82MhuHYHQ0mLj4YxtY8WujAsGtNp2 gdwc2UbEEQkuNyF5l7FZLm+2kqWu980g48vvPJGQuOB02us7gjSEqxfxMk7A mppaHJa1VWTS7mG0EVdbWBndbMQlKcwraqK4AWmxLQm13zDi8JOQVT/dADPE dfkVvHy9YdoxRU10SbRmSWX1olDG5anRuRfKDebQFEMftVeobmj87+wm0kSa SBNpIk2kiTSRTikVMDYNmA6cBawAGoAtQBK4HrgT+BfgReAN4CgQKGSsBmgC FCANbAP+GrgR+DnwBPA08C5wHCj0M1YMTAFmAjuAOwOMPUZ/WQbeAXYEGbsF KCtibAGwDEgCOrAV+B5wPbAT2AXcC+wF7gN+B7wNnFHMWAhYChz9/JPBDwbZ 26+5n98+95vnHsfnFw/gg/dv6fP4c/ezvXfvvfuOv79NfARrQkWb89nWoYbF eY2tZSwg3lNZcXXwRjs7kp/ryUfB1MbW6YyVNiz2U6ajlbFLWkU5z1uWI0QX FnJGT2cti33FIyUWQJ4y1KOGqoupNFmWLlrssyvsGYqIVHcGUWJuHpTlNywu keUSKteS/Es88q8G2oCELf8bgNs8OvCYRw8+8OjCbI8+dGTpxDHgqFfnTrnw TtDznx5/3KlPf+GtMQt2yof5lPnmieesMl/ePyRY4euzy2ZPZplgAsHXgyxv 9/DmohfmF71ewO7ABzLLL/NhNPvOqcr/yNfQAfIB34PNXw9837b/W4A7gIeA IWAefMB84G3bH1wJX7AJ2Aqkgb8NjvgI8gmG7RdMjz8ogt2/B6RLGHsS+Ayo OANrAA8Dvwbm4Z51PvBD4O+AW4EvRDr2hZ2OHPnii5E8SuIh85Q5dvjw4U8+ /J//evfNV1987un9v3r0oQcy5RTI9/kDx4eHi/J9hcX+oJvrcXNpN/eym/s9 cjTyPbdG+cLJ3eXmXnJz8044uYfc3C3DTm7IzdF/e+VBAnk+H8vL97ECqm1w 5OLIIpv/p8Lr415mHPEWMlq+wcLb3kLGf7BlFF71Fv5UtH3NJG12xUKyfjxP 3vrzz6OR0oewmXRGVgPNwO+BBOTXBzwK7AfeBQ4An9qynQG5LgLuBx702NQj wC+Al4C3gA+Bw8Ak2NVsYD7Agb8AmoErARW4DviBxwbvAPYAjwL7gYPAcbJN IDCJsQuARuBKwAA+Bg4DU0uxIWAWcCYwB+DAOUA5EAaWAFGgAqgBmoBNwFXA 1cCHwBGgZDJiCGAWcC6wANgxBTEHcAVO/V7gJuBmYNE0+LZDx4YO4TN4aFC8 Dw69J96H3PdBeg6iA56iZvCQ6DwoiwffevXgyy+8/CxATz+OfhzhzC+jADqz 87zRhTc6KLZDEervjUYCWVELYpkC9v3MWAbd1o7nE58EguBvE9APnAH+1Hp4 djcwaPPuc5t/xLv34/kjupvx38UnU/hNi+efEU95trEL73sL+72FX51Ey6Ns VBo5eb32nJ9xmmtkz37Ybi7Y9nzp5FlnO/YsRs75yuP9zLd7mEbnYfSMU5Hx Dtse9sEGXoMuvg4cBPJn4MwAtJmMWcBTwJpZjP0Y+Mks+X/FRz8d+r+DB95+ 47VXXnrl+f946vF/e2Tf/ffdc9c/7vzRjptuHM23bzAV+q//XJ643//cOSuf dHMXH3Fyd7q5vW7uB0edXMkxJ1fu5pYdk/Mud2uuds/0R9zz+2b31Kb/Fpa5 GYKumeL5qn1uF/qrjsr5qt1Vr3RzN7u5Oe5q7W7uh27uJTfnBy1s3qnK8WRO vgODxSOFjCP6ZI71rzjmMW/hl+w0J/rZxHyvyeZX+caz+tuHL5885+xRMfzX svzbh+dIy7fP/1I6v6qnSdnvB94CPvTowQe2Lnxk60PQ1ol7bL1IAdfZuvGy rR+XZevIUfoc+uiozHxkl8dl0kQ6tTTWtxMUT9ixxey57Kx9bAnf9953z973 08JzgHN//NPCMmDBvvFXmEh/7mkqW8SK4Y6uZKXi1yqUqnDD+Hg4j97Mz9qZ wUyWZApLoEyee9o/xdl0oIQ1LPY1ts5myZaiArYCs+BmiTdOMdbCVIyIM43p rIdxVoHaINr9IuaZxsSXWnPZxS1zWUdrHrsEYHUYTTPU5ZyhUsyQJ2fwTWLy CzBncBXiKBpblXPsUjE2X47NC7pLLoMbpVHLco6qEqMK5Kj8ElrRpTXCCsXI SM6R1agtxGfFwgKMb2ydCer9on9lzv41or8f/QtZgNUQb9yfiFzI6ld8MnyP +LXdTNaEkd0Ym4Y0LIxci7wJ9IhnH+tF3UpITEerN0XYiVKH3gCrx9pxjFBZ Ch+SaimkyiBV+nYJ67Oo7O+LitYGrGawGNvCtmJlA3Oron4ym3RTr68UoN9S nei4l03xwdnQntlq1smamTNfmWg921dmt3ZgJ9R6BpPfiBaCrYXsHNGrwneO oLIRKyXxUe3d5LMLg8OsXPSp95ULCiQ/iI8a+mhi586aF4k9dPkuQk1pzp6c rUEuJWafxGYw2onDB9JHGr/OV/cl4ztRS9ZBtMxkI2MXsstW3Mu2+hYy0qFm 9CDZKFhLExz3M/HtLVtsy2Uxo1+Ltdh2Mtu2kxJpJ1HYSRnNKfsutPtKi/iO bREB2TdHP6n9Z9raH3Bsj7gt+p1j95P6PsfW93zqR3ITfcrsPlKz5wrNtmea zkb1kvo8z9Zn0QtxZlRI7oDQqSC7GJwbYF3gI2lwXPDYns9RB7ZJzPuJb5PQ lLVCY7tdf2QJPaSRC9hZLPQ0Z8X/nn9dYEXJZ5N+OfWGmTVnHpv30NnbFqxw U5a2SZ305ZUJeazHjCSlhNDtoNuLs42Q5JQ8bveysLoh7Jb0rFraCul2nrSV TuyqD3P0o58mKDRZtp6HpZ7nhdFSAn51sjZoIseTeLEFNtYnVoO+Nyz2Szrr BZ1BtkH00fDssmmV2t5uy6AdmMyuZUtgtYbgEVkRx7Pb9g1SX0vANUSQZXE/ ec5SrCWk5Hq4Fnu+FiAk5uvE2L6cMy2kmRaONVMTa1jhY2ZeEyPfR1TFwSNp O9uF7RWz81zbmclEaMJIRTta/ZjCTwdMcBm7HLP/Td4ywc0m4Y/SrneQvJNc K2dLmriPJBjAaPnNAf02FQpFJiN+o0zxM333RfEvxaj0o1f6m4L4UV+B/L6a vhuh+xG144rE6OetdDObZfehuzO14eokftGHa/HQMrGaf4jmwUEjztRzmQz4 CSTDFWz+x5MFHYIadsMNN7DDRAKO4KGdjHLBoaA94NwCmjh/KCoWKBgqF/VF Q/JXupkpjxWLcURcod2/gRGBst6Hevg5KHHJEG4f7AnfZKz1nE+Q4ROHXT79 avIv831i7SlDBTYVzk976fhfwkSIwB5k8suPd5j84oT+iJGHztAaNgtIAluB fwYpDxTKPwc+AzwLPA8s9MMlALdiyduB2hLGvgs8BTwPNIH9FwNtwDrgKiAO 7ADbfwLcB/zM/vriP4EXgDeAPsjhWmAv8ACwFLJbDlwKXANowFYgDLlVAhZw rf113q3Aw8BjwBTseS6wm95wY6cLlC7Fvi8H7sT+7gEWYV8/A/4b+5gzVdIY gIvPxPAwqXQIJrcOR/4VOJKbkeNABM96PCtxyNbBzfaLgy0Oo+rH8bRJHN1t cLib0CstXMg6GFoM723CoZH5pmBwVHIcQrZJVmL+fjipLd9yCs6yKWgTc2bP IWlRRQDUI+o0tNPMvWhNov7bvbv5J7m7uOh5emZe+kfkWm4aKBCLT+zuJHcX ZJsrPy08cWBw7nBp9oex/60emrr518HKXG3P/9UDfPfNn8zP1TZcOXvJpP7J d+Vq2zzjs9rjT3W/mqttVcvPV5a9uPKV0W0+9gd+UeeJrbvvyNVWW6ZferV1 17O52nzC68pnRsKxW3rT/7d3daFxVFH4zOzMZpNoWCOmTUvjKq2N1Gx28+eG oiYlW00xP02qEREqNtZoqZsmESsi5KHaIkIrClYINA8qgiJiAr6VgMUnhQgW 61tBH3zwoZS+9MGu57v3zjTd7Mlmog8W7xfuzuyd+ebcme/OZM6Ze2aX3btO nL1xz/fsAk44KmybrsCY90PGshuHm1uJMZkIGTmPGW5FRk9tyJj3mRGryEjW hYxEFTO8iozLyZAxmWCGX5Hx9d0h41I1M+IVGbMNIaOnlhlVFRnDjSHj8zuY kTAMR2RICsoMSUGZISkoMyQFZYakoMyQFJQZkoIyQ1JQZkgKxiIrKDMkBWWG pKDMkBSUGZKCMkNSUGZICsoMSUGZISnoRVZQZkgKygxJQZkhKSgzJAVlhqSg zJAUlBmSgjJDUtCNrKDMkBSUGZKCMkNSUGZICsoMSUGZISkoMyQFZYak4KbV 61OijIJD+xzavw9X6W+vROMlmIfwfmGDvFevYJ1isdy7rIo9zqxDUz6p8kfN VUILMY8YB6YY3+QmzeoIVQwjltGDaBPfHjac4Ta5bjzme74b81aMS1EIDuYB vsnFDfA0pWiQEL/DDXNBRRoRU+7k7bDQvuM63Ef8YEBKYBaYxcco31IfVXFN PC9pf0BZr417LiBa7zUxPXDycWXJCWBWWWVpgBCHRIxPRxxTbBsxuRkVYe5e 51bG+Gjp6NkMu7S9XPNYp2pzVazadX3XE9uM+Pxrqt1wT4KjxkcqfuaWHirx 9yjuS8qRZlZ4pFgoz/VOBo+jDM6Z6QFu6YTRhWi33ksqQZm91M9agmcuOEL3 84l+LHFqM9Ey25pQzfr43a53UA4/1/WZbsDPrh4F5hA6p0exJOLlx7l2Ux1q 0RGajKkdpbtqEQGfxpeqFmmRBWvLQMJGFdtv5PITn9OnV2q6AWg1i8V6872m jIs7bZat5Tqvtez2w40i+nTJqUb6HL389rmr14cmkl+8n6BdOxd+ZVEI52i9 WX6W9FGdJ32OL5J+w94S6UvzJSL1/lAEh3GW4BqfMBvHlXmz2dZ2RweWexw8 SyB60kGEn+gZB0oQjTsqak2TPGV/X71dEJ2B/yuomPwpR7fjd0+fidjGzSRh XadObq7DPLa1Z6T32f78SGoknepNcx8I1+H60nm0fVC9rYpSa/HRhjbSHLRr 4OVDU4XpwuGZ1FhhajyVS2dIPR0PoOa3H7nQvHjeUfOPzuXx5sCV8zHTFkxx JcIUVyN7obGwsLCwsLCwsLCwsLCIAsn/R4178ceLc+mtyQ8+Yv//oetfYfye X1L3BDunnvHT4adOkvHRSccCTpCOBbxHOhbwIemxdHOkw8SfkPbXvyTt0yOG AN8ZA8swpu4C6W3/QDom8Bvd6uvrWGKr9oePa78Y8TlME2aK6BGmC3cmlC0y NstNm5J6myUxBAwDhFmYxG6oN7lS4Jwz/iQKo5AZU32INOkIafvfkT4mv5jv WIa4x8Hh/r6Djz/V3xe2+ukXp/AqOLU2top3CIe73cvTQS5vUjd1UDub66A8 dVGWWqiNv6O2hb9lqY+XtfD3dl6e57kM/+W4dNJe/uvgNTr4r4veUs3GviEs k0tn0u0dWd6LbCaoy2Zas9nW7i7MkYWFhYWFhYWFhYWFhcXtB/ipcCzheQbe JhxcPPOGJwrnDz4q/GH43/DF8fwbPj78dfjyeIYPnx3JRsiPg98O3x45cBi9 gd8H3Ur61xa3kXY07+WS4nIfaX8dOXLIjdtBpPJWd3JpNlzkxu7igmxJJJ9h nEUraT8by5HUhxxXJKUhPxXZpw9zyZnlf3HZbeaDYqGBEW4FlT+ZV6kfSDOJ ggbynWBb6EPxah1LWtKL9+Kj5+S1068vnHfmF/c/jzENj5AZlMXIqvFcQSZr dNSRq+yj32JakcDYwuWFbXp+TI2YG1+VArNebFHv07v5u7cVCQZNbXrq06iy elRl9b5B/Wx9ZYZzkNEuoZnt44jj3F2v/QfxYUZT+av2PFp7cub4R9l/5LgH 9h2T5T9JQ9wLXlmLVhb1fPWKah+IbknGRuz/m/gn9tF37fXw/wuH1Y/V6D5U eu3G/++SMWzBjxSqe4KBUdRxlTqZMZ8OlqdzdK37m2Pl+5zFfwd/A1BLAQIU ABQAAAAIAJJi1SbTQptRCBsAAAB+AAAUAAAAAAAAAAAAIAC2gQAAAABUZWxv Z2VuaWMyIEZJTkFMLmRvY1BLBQYAAAAAAQABAEIAAAA6GwAAAAA= --====================5453515:56====-- From rem-conf Mon Jun 21 08:55:27 1999 From rem-conf-request@es.net Mon Jun 21 08:55:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w6Nq-0007Iz-00; Mon, 21 Jun 1999 08:53:18 -0700 Received: from mailer.psc.edu [128.182.58.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10w6No-0007IZ-00; Mon, 21 Jun 1999 08:53:16 -0700 Received: from sunshine (sunshine.psc.edu [128.182.61.166]) by mailer.psc.edu (8.8.7/8.8.7/mailer) with SMTP id LAA07646 for ; Mon, 21 Jun 1999 11:53:11 -0400 (EDT) Message-ID: <024b01bebbfe$28b6aba0$a63db680@psc.edu> From: "S.Grant" To: Subject: What can be done? Date: Mon, 21 Jun 1999 11:52:58 -0400 Organization: NLANR/NCNE Pittsburgh Supercomputing Center MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list What can be done about the volume of spam sent to this list? Can the list posts be restricted to only those subscribed? At this point, I'm ready to unsub due to the volume of spam. Does anyone else here have any ideas? Thanks for listening. Shirl Grant NLANR Engineering Services grant@ncne.org NCNE / Pittsburgh Supercomputing Center - From rem-conf Mon Jun 21 09:57:12 1999 From rem-conf-request@es.net Mon Jun 21 09:57:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w7KY-0000qe-00; Mon, 21 Jun 1999 09:53:58 -0700 Received: from tardis.acs.ohio-state.edu [128.146.116.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 10w7KX-0000qU-00; Mon, 21 Jun 1999 09:53:57 -0700 Received: from stargate.acs.ohio-state.edu (stargate.acs.ohio-state.edu [128.146.226.8]) by tardis.acs.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA09462; Mon, 21 Jun 1999 12:53:55 -0400 (EDT) Received: from localhost (rdixon@localhost) by stargate.acs.ohio-state.edu (8.9.1b+Sun/8.9.1) with ESMTP id MAA01893; Mon, 21 Jun 1999 12:53:54 -0400 (EDT) Date: Mon, 21 Jun 1999 12:53:53 -0400 (EDT) From: Bob Dixon To: "S.Grant" cc: rem-conf@es.net Subject: Re: What can be done? In-Reply-To: <024b01bebbfe$28b6aba0$a63db680@psc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I agree completely. This has been discussed here before, but the problem remains. The amount of spam I get which is related to my subscription to this list is huge. On Mon, 21 Jun 1999, S.Grant wrote: > What can be done about the volume of spam sent to this list? Can the > list posts be restricted to only those subscribed? At this point, I'm > ready to unsub due to the volume of spam. > > Does anyone else here have any ideas? > > Thanks for listening. > > Shirl Grant NLANR Engineering Services > grant@ncne.org NCNE / Pittsburgh Supercomputing Center > > - > > > > Robert S. Dixon Voice 614-292-1638 Chief Research Engineer Fax 614-292-7081 Office of the CIO Lab 614-292-7425 Ohio State University Email Bob_Dixon@osu.edu 1971 Neil Ave, room 451 Video 128.146.199.85 Columbus, OH 43210 From rem-conf Mon Jun 21 10:06:35 1999 From rem-conf-request@es.net Mon Jun 21 10:06:35 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w7Ve-0001UY-00; Mon, 21 Jun 1999 10:05:26 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 10w7VY-0001Tc-00; Mon, 21 Jun 1999 10:05:25 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 21 Jun 1999 17:09:20 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256797.005DB095 ; Mon, 21 Jun 1999 13:03:20 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: Henning Schulzrinne , Scott.Petrack@metatel.com cc: rem-conf@es.net Message-ID: <85256797.005DAF5C.00@notes4.nmss.com> Date: Mon, 21 Jun 1999 13:04:38 -0400 Subject: inband dtmf/tones proposal 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 Is it your intention in the new Schulzrinne/Petrack proposal that the inband dtmf/tone rtp packets could overlap in time with voice rtp packets? A receiver/decoder would then receive a udp packet containing "voice / encoded tone" as well as a udp packet covering some or all of the same time interval with a dtmf/tone message. This is my reading of the proposal and I see no problem with it. It is also in line with H.245's out of band method. More importantly: Is it your intention also that the redundancy must be applied to all packets: voice as well as dtmf/tones? It is hard to imagine how it could work otherwise because it would be difficult to determine that a dtmf/tone packet was missing. This requirement could add a lot of overhead however. Also, the redundancy adds some latency. For the dtmf/tones this is not such a huge problem, but for the voice it might be, especially as the quality/Bandwidth of the Internet connections improve. Hence, if there is some way to operate the protocol with redundancy applied only to the dtmf/tone packets, it could be important. From rem-conf Mon Jun 21 10:06:36 1999 From rem-conf-request@es.net Mon Jun 21 10:06:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w7Vo-0001Uv-00; Mon, 21 Jun 1999 10:05:36 -0700 Received: from mailer.psc.edu [128.182.58.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10w7Vn-0001Uj-00; Mon, 21 Jun 1999 10:05:36 -0700 Received: from sunshine (sunshine.psc.edu [128.182.61.166]) by mailer.psc.edu (8.8.7/8.8.7/mailer) with SMTP id NAA10658; Mon, 21 Jun 1999 13:05:34 -0400 (EDT) Message-ID: <027b01bebc08$450ea320$a63db680@psc.edu> From: "S.Grant" To: "Bob Dixon" Cc: References: Subject: Re: What can be done? Date: Mon, 21 Jun 1999 13:05:31 -0400 Organization: NLANR/NCNE Pittsburgh Supercomputing Center MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I agree completely. This has been discussed here before, but the problem > remains. The amount of spam I get which is related to my subscription to > this list is huge. I maintin a list that was getting hit alot too. I changed it over to a subscriber posting only list. It was a PITA for a little bit. I have another list of 'approved' posting addresses, and this is where I out people who post that may be subscribed via a local reflector. After the first couple of weeks it settled down. It was worth it. All spam gets bounced to me as a reminder of the Good Thing I did. :^) I really don't want to unsubscribe to this list, but I cannot deal with all the spam. -Shirl From rem-conf Mon Jun 21 10:12:10 1999 From rem-conf-request@es.net Mon Jun 21 10:12:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w7bd-0002WX-00; Mon, 21 Jun 1999 10:11:37 -0700 Received: from www.wombo.com (wombo.com) [199.108.92.215] by mail1.es.net with esmtp (Exim 1.81 #2) id 10w7bb-0002Tm-00; Mon, 21 Jun 1999 10:11:35 -0700 Received: from cs.columbia.edu (194.188.251.230) by wombo.com with ESMTP (Eudora Internet Mail Server 1.1.2); Mon, 21 Jun 1999 10:13:29 -0700 Message-ID: <376EC7B1.63DF8992@cs.columbia.edu> Date: Mon, 21 Jun 1999 19:16:01 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Dixon CC: "S.Grant" , rem-conf@es.net Subject: Re: What can be done? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If the list owner cannot help, my only suggestion is to adopt the convention that all messages to this group must have "RTP" in their subject line. List subscribers could then filter the messages appropriately. (:-) Bob Dixon wrote: > > I agree completely. This has been discussed here before, but the problem > remains. The amount of spam I get which is related to my subscription to > this list is huge. > > On Mon, 21 Jun 1999, S.Grant wrote: > > > What can be done about the volume of spam sent to this list? Can the > > list posts be restricted to only those subscribed? At this point, I'm > > ready to unsub due to the volume of spam. > > > > Does anyone else here have any ideas? > > > > Thanks for listening. > > > > Shirl Grant NLANR Engineering Services > > grant@ncne.org NCNE / Pittsburgh Supercomputing Center > > > > - > > > > > > > > > > Robert S. Dixon Voice 614-292-1638 > Chief Research Engineer Fax 614-292-7081 > Office of the CIO Lab 614-292-7425 > Ohio State University Email Bob_Dixon@osu.edu > 1971 Neil Ave, room 451 Video 128.146.199.85 > Columbus, OH 43210 From rem-conf Mon Jun 21 10:18:14 1999 From rem-conf-request@es.net Mon Jun 21 10:18:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w7h5-0003W5-00; Mon, 21 Jun 1999 10:17:15 -0700 Received: from www.wombo.com (wombo.com) [199.108.92.215] by mail1.es.net with esmtp (Exim 1.81 #2) id 10w7h3-0003VQ-00; Mon, 21 Jun 1999 10:17:14 -0700 Received: from cs.columbia.edu (194.188.251.230) by wombo.com with ESMTP (Eudora Internet Mail Server 1.1.2); Mon, 21 Jun 1999 10:19:18 -0700 Message-ID: <376EC90E.5011D8AC@cs.columbia.edu> Date: Mon, 21 Jun 1999 19:21:50 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Levens@nmss.com CC: Henning Schulzrinne , Scott.Petrack@metatel.com, rem-conf@es.net Subject: Re: inband dtmf/tones proposal References: <85256797.005DAF5C.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 Bruce_Levens@nmss.com wrote: > > Is it your intention in the new Schulzrinne/Petrack proposal that the > inband dtmf/tone rtp packets could overlap in time with voice rtp packets? Yes, I believe the draft points this out somewhere. > > A receiver/decoder would then receive a udp packet containing "voice / > encoded tone" as well as a udp packet covering some or all of the same > time interval with a dtmf/tone message. This is my reading of the > proposal and I see no problem with it. It is also in line with H.245's out > of band method. > > More importantly: > Is it your intention also that the redundancy must be applied to all > packets: voice as well as dtmf/tones? No, definitely not. There are other redundancy schemes, including the one in the draft, but using low bit-rate codecs, not repetition, as well as FEC, to handle regular audio packets. > It is hard to imagine how it could work otherwise because it would be > difficult to determine that a dtmf/tone packet was missing. This The RTP sequence number tells you if packets (audio or DTMF) are missing. To provide some protection against missing the last part of the last digit, it is transmitted repeatedly (three times). I guess I don't understand the concern exactly. > requirement could add a lot of overhead however. Also, the redundancy > adds some latency. For the dtmf/tones this is not such a huge problem, but > for the voice it might be, especially as the quality/Bandwidth of > the Internet connections improve. Hence, if there is some way to operate > the protocol with redundancy applied only to the dtmf/tone > packets, it could be important. From rem-conf Mon Jun 21 11:05:36 1999 From rem-conf-request@es.net Mon Jun 21 11:05:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w8Pv-0004xF-00; Mon, 21 Jun 1999 11:03:35 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 10w8Pt-0004x5-00; Mon, 21 Jun 1999 11:03:33 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 21 Jun 1999 18:07:32 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256797.00630ECE ; Mon, 21 Jun 1999 14:01:58 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: Henning Schulzrinne cc: Scott.Petrack@metatel.com, rem-conf@es.net Message-ID: <85256797.00630D3A.00@notes4.nmss.com> Date: Mon, 21 Jun 1999 14:03:14 -0400 Subject: Re: inband dtmf/tones proposal 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 take it then that you mean for the rtp sequence numbers for dtmf/tone to wriggle into the sequence for voice. For example if the audio stream would have resulted in the following: Time: 0 30mS 60mS 90mS RTP Seq number: 0 1 2 3 And we detect a tone at around 70 mS which we want to insert into the stream, we would give it RTP Seq number 3 (wriggled in), and give the 90 mS voice packet RTP Seq number 4 (bumped up from 3), and then maybe give a "repeat" of the DTMF/TONE packet at around time 100 mS sequence number 5, etc.? If we do that, then we still don't know whether a missing RTP sequence number applies to DTMF/Tone or to VOICE. In my example above, if we miss seq. #3 then we lost a DTMF/Tone packet, and if we miss seq. #4 then we lost a VOICE packet. Or have I missed something? From rem-conf Mon Jun 21 11:15:33 1999 From rem-conf-request@es.net Mon Jun 21 11:15:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10w8ab-0005fj-00; Mon, 21 Jun 1999 11:14: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 10w8aZ-0005fC-00; Mon, 21 Jun 1999 11:14:36 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 21 Jun 1999 18:18:34 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256797.00640E7A ; Mon, 21 Jun 1999 14:12:53 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: Henning Schulzrinne cc: Scott.Petrack@metatel.com, rem-conf@es.net Message-ID: <85256797.00640DDC.00@notes4.nmss.com> Date: Mon, 21 Jun 1999 14:14:13 -0400 Subject: Re: inband dtmf/tones proposal 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 take it then that you mean for the rtp sequence numbers for dtmf/tone to wriggle into the sequence for voice. For example if the audio stream would have resulted in the following: Time: 0 30mS 60mS 90mS RTP Seq number: 0 1 2 3 And we detect a tone at around 70 mS which we want to insert into the stream, we would give it RTP Seq number 3 (wriggled in), and give the 90 mS voice packet RTP Seq number 4 (bumped up from 3), and then maybe give a "repeat" of the DTMF/TONE packet at around time 100 mS sequence number 5, etc.? If we do that, then we still don't know whether a missing RTP sequence number applies to DTMF/Tone or to VOICE. In my example above, if we miss seq. #3 then we lost a DTMF/Tone packet, and if we miss seq. #4 then we lost a VOICE packet. Or have I missed something? Perhaps the voice and dtmf/tone information are piggybacked together in the same rtp packet. Then it would work but this would contradict your answer to my first question in the previous email. From rem-conf Mon Jun 21 13:36:50 1999 From rem-conf-request@es.net Mon Jun 21 13:36:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wAlZ-00000c-00; Mon, 21 Jun 1999 13:34:05 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10wAlX-00000Q-00; Mon, 21 Jun 1999 13:34:03 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jun 21 16:33:34 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.248.62]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA05286 for ; Mon, 21 Jun 1999 16:33:32 -0400 (EDT) Message-ID: <376EA1C6.823AB577@dnrc.bell-labs.com> Date: Mon, 21 Jun 1999 16:34:14 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: Updated FEC draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I've submitted an updated FEC draft to the archives. Until it appears, you can find a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-fec-06.txt The only changes were a cleanup of the Figures and a new mechanism for SDP signaling. The mechanism in the last draft had compatibility issues. This version uses the fmtp parameter to convey the FEC information, so its backwards compatible, if a little ugly. I'd rather have working and ugly than not working. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Jun 21 14:53:49 1999 From rem-conf-request@es.net Mon Jun 21 14:53:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wBys-0001bI-00; Mon, 21 Jun 1999 14:51:54 -0700 Received: from tnint06.telogy.com [209.116.120.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wByq-0001b8-00; Mon, 21 Jun 1999 14:51:53 -0700 Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Jun 1999 17:51:51 -0400 Message-ID: <61891BA043DED21180920090273F173802E73D@argentina.telogy.com> From: Roy Spitzer To: 'Henning Schulzrinne' , "'rem-conf@es.net'" Cc: 'Scott Petrack' , "'MEGACO@standards.nortelnetworks.com'" , Ed Morgan , Mihai Sirbu , Zoran Mladenovic , Frank Fruth Subject: RE: First cut at DTMF/tones draft Date: Mon, 21 Jun 1999 17:51:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning, This is a resend of an earlier message since I received no reply. Regards, Roy Roy Spitzer Telogy Networks, Inc. Phone: (301) 515-6531 20250 Century Blvd. Fax: (301) 515-7954 Germantown, MD 20874 Email: rspitzer@telogy.com -----Original Message----- From: Roy Spitzer Sent: Thursday, June 17, 1999 11:18 AM To: 'Henning Schulzrinne'; rem-conf@es.net Cc: Scott Petrack; MEGACO@standards.nortelnetworks.com; Ed Morgan; Mihai Sirbu; Zoran Mladenovic; Frank Fruth Subject: RE: First cut at DTMF/tones draft Henning, I apologize for my late comments. I applaud the reuse of the current RTP definitions for DTMF. The application of the same technique for supervisory signaling is desirable. 1. The problem I have is that VoIP and the use of RTP is fast becoming an international set of procedures. To be compatible with the differing encoding of supervisory signaling, the prime emphasis should be towards creating a standard set of supervisory signal (event) names as discussed in section 5. The translation of these names becomes a function of the Media Gateway. These name could translate to standard country encodings or custom audio response messages. This need not be known by the generator of the signal (event). 2. Item 1 is fine when there is a translation of the signal (event). For the cases when there is no translation of the signal (event) the associated tones may be used. But this may cause confusion at the destination end since that combination of tones may already be assigned to another signal(event). The other alternative is to drop those signals on the floor. Obviously, there if there is no translation table, all signals would be dropped on the floor. The other alternative is to use the local signal translation if present, used the associated tones when not present, and drop unknown signals on the floor only when local signal translation is present. Please comment on this. 3. To support V.34 Modems and V.34 FAX phase reversal needs as either a parameter to CED or as distinguishable event. 4. I am confused about the meaning of the events * V.21 Channel 1, "0" * V.21 Channel 1, "1" * V.21 Channel 2, "0" * V.21 Channel 2, "1" 5. Is V.21 flag indication available? Regards, Roy Roy Spitzer Telogy Networks, Inc. Phone: (301) 515-6531 20250 Century Blvd. Fax: (301) 515-7954 Germantown, MD 20874 Email: rspitzer@telogy.com -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, June 09, 1999 10:02 AM To: rem-conf@es.net Cc: Scott Petrack; MEGACO@standards.nortelnetworks.com Subject: First cut at DTMF/tones draft I've put the PostScript and PDF versions of the merged DTMF and tones draft at http://www.cs.columbia.edu/~hgs/rtp/doc/dtmf/tones.pdf and tones.ps. Scott and I would appreciate your comments. I will turn this into an (ASCII) I-D shortly, barring "you must be crazy" comments. Thanks. From rem-conf Mon Jun 21 17:13:50 1999 From rem-conf-request@es.net Mon Jun 21 17:13:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wEA3-0003Nx-00; Mon, 21 Jun 1999 17:11:35 -0700 Received: from mmlab.snu.ac.kr [147.46.114.112] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wEA1-0003Nn-00; Mon, 21 Jun 1999 17:11:33 -0700 Received: from gold ([147.46.14.38]) by mmlab.snu.ac.kr (8.9.1b+Sun/8.9.1) with SMTP id JAA22265; Tue, 22 Jun 1999 09:09:34 +0900 (KST) Message-ID: <001701bebc43$19045e60$260e2e93@apan.snu.ac.kr> From: "Yung Yi" To: "Jonathan Rosenberg" Cc: , References: <376EA1C6.823AB577@dnrc.bell-labs.com> Subject: Re: Updated FEC draft Date: Tue, 22 Jun 1999 09:05:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SGkgSm9uYXRoYW4uDQpJbiBwYWdlIDEzLA0KDQpJbiBTZWN0aW9uIFsxMC4gRXhhbXBsZV0sDQp0 aGUgdGhpcmQgbGluZSAiUGFja2V0IHggdXNlcyBwYXlsb2FkIHR5cGUgMTEsIGFuZCBwYWNrZXQg eCB1c2VzIHBheWxvYWQgdHlwZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXg0KIDE4 LiIgc2hvdWxkIGJlIGNvcnJlY3RlZCB0byAiUGFja2V0IHggdXNlcyBwYXlsb2FkIHR5cGUgMTEs IGFuZCBwYWNrZXQgeSB1c2VzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIF5eDQogcGF5bG9hZCB0eXBlIDE4LiIsIEkgdGhpbmsuDQoNCkFtIEkg cmlnaHQ/DQoNCnlpeXVuZ0BtbWxhYi5zbnUuYWMua3INCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206IEpvbmF0aGFuIFJvc2VuYmVyZyA8amRyb3NlbkBkbnJjLmJlbGwtbGFi cy5jb20+DQpUbzogPHJlbS1jb25mQGVzLm5ldD4NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjIsIDE5 OTkgNTozNCBBTQ0KU3ViamVjdDogVXBkYXRlZCBGRUMgZHJhZnQNCg0KDQo+IEZvbGtzLA0KPiAN Cj4gSSd2ZSBzdWJtaXR0ZWQgYW4gdXBkYXRlZCBGRUMgZHJhZnQgdG8gdGhlIGFyY2hpdmVzLiBV bnRpbCBpdCBhcHBlYXJzLA0KPiB5b3UgY2FuIGZpbmQgYSBjb3B5IGF0Og0KPiANCj4gaHR0cDov L3d3dy5jcy5jb2x1bWJpYS5lZHUvfmpkcm9zZW4vcGFwZXJzL2RyYWZ0LWlldGYtYXZ0LWZlYy0w Ni50eHQNCj4gDQo+IFRoZSBvbmx5IGNoYW5nZXMgd2VyZSBhIGNsZWFudXAgb2YgdGhlIEZpZ3Vy ZXMgYW5kIGEgbmV3IG1lY2hhbmlzbSBmb3INCj4gU0RQIHNpZ25hbGluZy4gVGhlIG1lY2hhbmlz bSBpbiB0aGUgbGFzdCBkcmFmdCBoYWQgY29tcGF0aWJpbGl0eSBpc3N1ZXMuDQo+IFRoaXMgdmVy c2lvbiB1c2VzIHRoZSBmbXRwIHBhcmFtZXRlciB0byBjb252ZXkgdGhlIEZFQyBpbmZvcm1hdGlv biwgc28NCj4gaXRzIGJhY2t3YXJkcyBjb21wYXRpYmxlLCBpZiBhIGxpdHRsZSB1Z2x5LiBJJ2Qg cmF0aGVyIGhhdmUgd29ya2luZyBhbmQNCj4gdWdseSB0aGFuIG5vdCB3b3JraW5nLg0KPiANCj4g LUpvbmF0aGFuIFIuDQo+IC0tIA0KPiBKb25hdGhhbiBELiBSb3NlbmJlcmcgICAgICAgICAgICAg ICAgICAgICAgIEx1Y2VudCBUZWNobm9sb2dpZXMNCj4gTWVtYmVyIG9mIFRlY2huaWNhbCBTdGFm ZiAgICAgICAgICAgICAgICAgICAxMDEgQ3Jhd2ZvcmRzIENvcm5lciBSZC4NCj4gSGlnaCBTcGVl ZCBOZXR3b3JrcyBSZXNlYXJjaCAgICAgICAgICAgICAgICBIb2xtZGVsLCBOSiAwNzczMw0KPiBG QVg6ICg3MzIpIDgzNC01Mzc5ICAgICAgICAgICAgICAgICAgICAgICAgIFJtLiA0Qy01MjYNCj4g RU1BSUw6IGpkcm9zZW5AYmVsbC1sYWJzLmNvbQ0KPiBVUkw6IGh0dHA6Ly93d3cuY3MuY29sdW1i aWEuZWR1L35qZHJvc2VuDQo+IA0KPiANCg== From rem-conf Mon Jun 21 20:48:06 1999 From rem-conf-request@es.net Mon Jun 21 20:48:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wHWD-0005H5-00; Mon, 21 Jun 1999 20:46:41 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wHWC-0005Gn-00; Mon, 21 Jun 1999 20:46:41 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Jun 1999 21:45:47 -0600 Message-ID: <18A6A966D2B7D211AEDE0090273CE1BA28CB19@el-postino.s-vision.com> From: Forrest Blair To: "S.Grant" , rem-conf@es.net Subject: RE: What can be done? Date: Mon, 21 Jun 1999 21:45:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Every four weeks or so have the list request a reply from each subscriber to stay on the list. I suspect most spammers ignore reply mail - especially those marked with REMOVE in the subject line. This would probably filter out a fair share of the spam. Here is a possible transaction: The list sends me a message with REMOVE >FROM LIST in the subject line. In the body is a note indicating that a subscription timeout has occurred and I should send a reply with a subject line of "continue". Maybe this will spark other ideas. Forrest Blair Sorenson Vision, Inc. -----Original Message----- From: S.Grant [SMTP:grant@psc.edu] Sent: Monday, June 21, 1999 9:53 AM To: rem-conf@es.net Subject: What can be done? What can be done about the volume of spam sent to this list? Can the list posts be restricted to only those subscribed? At this point, I'm ready to unsub due to the volume of spam. Does anyone else here have any ideas? Thanks for listening. Shirl Grant NLANR Engineering Services grant@ncne.org NCNE / Pittsburgh Supercomputing Center - From rem-conf Mon Jun 21 20:48:06 1999 From rem-conf-request@es.net Mon Jun 21 20:48:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wHTf-0005GL-00; Mon, 21 Jun 1999 20:44:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10wHTe-0005GB-00; Mon, 21 Jun 1999 20:44:02 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jun 21 23:42:23 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.26]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA08773; Mon, 21 Jun 1999 23:42:21 -0400 (EDT) Message-ID: <376F0645.208F9244@dnrc.bell-labs.com> Date: Mon, 21 Jun 1999 23:43:01 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Yung Yi CC: rem-conf@es.net, mrtp@mmlab.snu.ac.kr Subject: Re: Updated FEC draft References: <376EA1C6.823AB577@dnrc.bell-labs.com> <001701bebc43$19045e60$260e2e93@apan.snu.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Right. Thanks. -Jonathan R. Yung Yi wrote: > > Hi Jonathan. > In page 13, > > In Section [10. Example], > the third line "Packet x uses payload type 11, and packet x uses payload type > ^^ > 18." should be corrected to "Packet x uses payload type 11, and packet y uses > ^^ > payload type 18.", I think. > > Am I right? > > yiyung@mmlab.snu.ac.kr > > ----- Original Message ----- > From: Jonathan Rosenberg > To: > Sent: Tuesday, June 22, 1999 5:34 AM > Subject: Updated FEC draft > > > Folks, > > > > I've submitted an updated FEC draft to the archives. Until it appears, > > you can find a copy at: > > > > http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-fec-06.txt > > > > The only changes were a cleanup of the Figures and a new mechanism for > > SDP signaling. The mechanism in the last draft had compatibility issues. > > This version uses the fmtp parameter to convey the FEC information, so > > its backwards compatible, if a little ugly. I'd rather have working and > > ugly than not working. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg Lucent Technologies > > Member of Technical Staff 101 Crawfords Corner Rd. > > High Speed Networks Research Holmdel, NJ 07733 > > FAX: (732) 834-5379 Rm. 4C-526 > > EMAIL: jdrosen@bell-labs.com > > URL: http://www.cs.columbia.edu/~jdrosen > > > > -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Jun 21 21:21:30 1999 From rem-conf-request@es.net Mon Jun 21 21:21:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wI2o-0006oL-00; Mon, 21 Jun 1999 21:20:22 -0700 Received: from mail-gw.pacbell.net [206.13.28.25] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wI2n-0006oB-00; Mon, 21 Jun 1999 21:20:21 -0700 Received: from [192.168.0.1] (ppp-206-170-7-68.rdcy01.pacbell.net [206.170.7.68]) by mail-gw.pacbell.net (8.9.3/8.9.3) with SMTP id VAA04905; Mon, 21 Jun 1999 21:20:03 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jun 1999 21:20:15 -0700 To: Forrest Blair , "S.Grant" , rem-conf@es.net From: Ari Ollikainen Subject: RE: What can be done? Cc: rem-conf-request@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 9:45 PM 6/21/99, Forrest Blair wrote: >Every four weeks or so have the list request a reply from each subscriber to >stay on the list. I suspect most spammers ignore reply mail - especially >those marked with REMOVE in the subject line. This would probably filter >out a fair share of the spam. > >Here is a possible transaction: The list sends me a message with REMOVE >FROM LIST in the subject line. In the body is a note indicating that a >subscription timeout has occurred and I should send a reply with a subject >line of "continue". > >Maybe this will spark other ideas. > Uhhhh...as the list former and former maintainer (:^)) of the rem-conf list, I suggest that you direct such suggestions to BOTH rem-conf-request@es.net AND postmaster@es.net perhaps that will either get some useful movement in filtering and/or list re-organization...OR get ESnet to look for a new listowner/maintainer... As to Henning's suggestion of prefixing message subject lines with "RTP", I humbly suggest that RTP isn't the ONLY topic of discussion on the rem-conf list. [rem-conf] might be a useful prefix, however... My apologies for adding to the noise. OLTECO Ari Ollikainen P.O. BOX 3688 Networking Architecture and Technology Stanford, CA Ari@OLTECO.com 94309-3688 415.517.3519 From rem-conf Mon Jun 21 23:39:31 1999 From rem-conf-request@es.net Mon Jun 21 23:39:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wKBF-0000Wu-00; Mon, 21 Jun 1999 23:37:13 -0700 Received: from relay9.uu.net [192.48.96.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wKBD-0000Wk-00; Mon, 21 Jun 1999 23:37:11 -0700 Received: from neserve0.corp.us.uu.net by relay9.UU.NET with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQgura17623; Tue, 22 Jun 1999 02:37:37 -0400 (EDT) Received: by neserve0.corp.us.uu.net id QQguqy25183; Tue, 22 Jun 1999 02:04:04 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: What can be done? In-Reply-To: <18A6A966D2B7D211AEDE0090273CE1BA28CB19@el-postino.s-vision.com> from Forrest Blair at "Jun 21, 1999 9:45:43 pm" To: fblair@s-vision.com (Forrest Blair) Date: Tue, 22 Jun 1999 02:04:04 -0400 (EDT) Cc: grant@psc.edu, rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL43 (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 yah right. Forrest Blair said: > Every four weeks or so have the list request a reply from each subscriber to > stay on the list. I suspect most spammers ignore reply mail - especially > those marked with REMOVE in the subject line. This would probably filter > out a fair share of the spam. > > Here is a possible transaction: The list sends me a message with REMOVE > FROM LIST in the subject line. In the body is a note indicating that a > subscription timeout has occurred and I should send a reply with a subject > line of "continue". > > Maybe this will spark other ideas. > > Forrest Blair > Sorenson Vision, Inc. > > -----Original Message----- > From: S.Grant [SMTP:grant@psc.edu] > Sent: Monday, June 21, 1999 9:53 AM > To: rem-conf@es.net > Subject: What can be done? > > What can be done about the volume of spam sent to this list? Can > the > list posts be restricted to only those subscribed? At this point, > I'm > ready to unsub due to the volume of spam. > > Does anyone else here have any ideas? > > Thanks for listening. > > Shirl Grant NLANR Engineering Services > grant@ncne.org NCNE / Pittsburgh Supercomputing > Center > > - > > > > From rem-conf Mon Jun 21 23:45:28 1999 From rem-conf-request@es.net Mon Jun 21 23:45:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wKIt-00010j-00; Mon, 21 Jun 1999 23:45:07 -0700 Received: from www.wombo.com (wombo.com) [199.108.92.215] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wKIs-00010Y-00; Mon, 21 Jun 1999 23:45:06 -0700 Received: from cs.columbia.edu (194.188.251.231) by wombo.com with ESMTP (Eudora Internet Mail Server 1.1.2); Mon, 21 Jun 1999 23:46:55 -0700 Message-ID: <376F8657.86535B90@cs.columbia.edu> Date: Tue, 22 Jun 1999 08:49:27 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Roy Spitzer CC: "'rem-conf@es.net'" , 'Scott Petrack' , "'MEGACO@standards.nortelnetworks.com'" , Ed Morgan , Mihai Sirbu , Zoran Mladenovic , Frank Fruth Subject: Re: First cut at DTMF/tones draft References: <61891BA043DED21180920090273F173802E73D@argentina.telogy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > 1. The problem I have is that VoIP and the use of RTP is fast becoming > an international set of procedures. To be compatible with the differing > encoding of supervisory signaling, the prime emphasis should be towards > creating a standard set of supervisory signal (event) names as discussed in > section 5. The translation of these names becomes a function of the Media > Gateway. These name could translate to standard country encodings or custom > audio response messages. This need not be known by the generator of the > signal (event). Not sure whether this paragraph is agreeing or disagreeing with the current approach... > 2. Item 1 is fine when there is a translation of the signal (event). > For the cases when there is no translation of the signal (event) the > associated tones may be used. But this may cause confusion at the > destination end since that combination of tones may already be assigned to > another signal(event). The other alternative is to drop those signals on > the floor. Obviously, there if there is no translation table, all signals > would be dropped on the floor. The other alternative is to use the local > signal translation if present, used the associated tones when not present, > and drop unknown signals on the floor only when local signal translation is > present. Please comment on this. As far as I know (and have been able to tell from the ITU collection of national tones), while the same signal ("busy", "congestion", etc.) has different tone representations in different countries, I don't think that the same tone sequence means different things in different countries. Even if there was this ambiguity, RTP would be no worse than the current situation in the circuit-switched phone world. The choice between using tones and signal names depends a bit on who's listening (tourist at payphone calling home vs. subscriber calling foreign country). Why shouldn't this be left to the implementor, depending on what they see is being most useful to their customer base? > 3. To support V.34 Modems and V.34 FAX phase reversal needs as either a > parameter to CED or as distinguishable event. I'm afraid I can't parse this sentence. I thought we had discussed on this list the various permutations of ANS: just tone, amplitude modulated and with phase reversal. Is there another variation? > 4. I am confused about the meaning of the events > * V.21 Channel 1, "0" > * V.21 Channel 1, "1" > * V.21 Channel 2, "0" > * V.21 Channel 2, "1" > 5. Is V.21 flag indication available? V.21 is a 300 b/s modem protocol, "0" means a zero bit, "1" a phone bit. The channels are the ones from and to the originator, respectively. I don't know what you mean by "flag indication". Henning From rem-conf Tue Jun 22 10:50:47 1999 From rem-conf-request@es.net Tue Jun 22 10:50:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wUUH-0006B3-00; Tue, 22 Jun 1999 10:37:33 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wUUF-00069l-00; Tue, 22 Jun 1999 10:37:31 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10148; Tue, 22 Jun 1999 13:36:27 -0400 (EDT) Message-Id: <199906221736.NAA10148@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-fec-06.txt Date: Tue, 22 Jun 1999 13:36:27 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for Generic Forward Error Correction Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fec-06.txt Pages : 22 Date : 21-Jun-99 This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the pay- load and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-fec-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-fec-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-fec-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990621144734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990621144734.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jun 22 12:26:16 1999 From rem-conf-request@es.net Tue Jun 22 12:26:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wW59-0007dg-00; Tue, 22 Jun 1999 12:19:43 -0700 Received: from sharewave.com (eagle.hq.sharewave.com) [208.240.180.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wW58-0007dW-00; Tue, 22 Jun 1999 12:19:42 -0700 Received: by EAGLE with Internet Mail Service (5.0.1458.49) id ; Tue, 22 Jun 1999 12:16:05 -0700 Message-ID: From: Deepak Srinivasan To: "'rem-conf@es.net'" Cc: Greg Parks , Herman Chao Subject: RTP - Payload Differentiation Date: Tue, 22 Jun 1999 12:16:03 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are seeking more information on RTP Payload Type classification and valid Payload Types. Please advise us on where we can get more information on this issue. Thanks Deepak From rem-conf Tue Jun 22 14:52:48 1999 From rem-conf-request@es.net Tue Jun 22 14:52:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wYPo-0001eB-00; Tue, 22 Jun 1999 14:49:12 -0700 Received: from tnint06.telogy.com [209.116.120.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wYPn-0001e1-00; Tue, 22 Jun 1999 14:49:11 -0700 Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Jun 1999 17:49:06 -0400 Message-ID: <61891BA043DED21180920090273F173802E741@argentina.telogy.com> From: Roy Spitzer To: 'Henning Schulzrinne' Cc: "'rem-conf@es.net'" , 'Scott Petrack' , "'MEGACO@standards.nortelnetworks.com'" , Ed Morgan , Mihai Sirbu , Zoran Mladenovic , Frank Fruth Subject: RE: First cut at DTMF/tones draft Date: Tue, 22 Jun 1999 17:49:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning, Comments below. Regards, Roy Roy Spitzer Telogy Networks, Inc. Phone: (301) 515-6531 20250 Century Blvd. Fax: (301) 515-7954 Germantown, MD 20874 Email: rspitzer@telogy.com -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, June 22, 1999 8:49 AM To: Roy Spitzer Cc: 'rem-conf@es.net'; 'Scott Petrack'; 'MEGACO@standards.nortelnetworks.com'; Ed Morgan; Mihai Sirbu; Zoran Mladenovic; Frank Fruth Subject: Re: First cut at DTMF/tones draft > 1. The problem I have is that VoIP and the use of RTP is fast becoming > an international set of procedures. To be compatible with the differing > encoding of supervisory signaling, the prime emphasis should be towards > creating a standard set of supervisory signal (event) names as discussed in > section 5. The translation of these names becomes a function of the Media > Gateway. These name could translate to standard country encodings or custom > audio response messages. This need not be known by the generator of the > signal (event). Not sure whether this paragraph is agreeing or disagreeing with the current approach... Roy> I am agreeing with the approach but I want the document to explicitly state that both the event name and the associated tone map are mandatory in each tone event message. > 2. Item 1 is fine when there is a translation of the signal (event). > For the cases when there is no translation of the signal (event) the > associated tones may be used. But this may cause confusion at the > destination end since that combination of tones may already be assigned to > another signal(event). The other alternative is to drop those signals on > the floor. Obviously, there if there is no translation table, all signals > would be dropped on the floor. The other alternative is to use the local > signal translation if present, used the associated tones when not present, > and drop unknown signals on the floor only when local signal translation is > present. Please comment on this. As far as I know (and have been able to tell from the ITU collection of national tones), while the same signal ("busy", "congestion", etc.) has different tone representations in different countries, I don't think that the same tone sequence means different things in different countries. Even if there was this ambiguity, RTP would be no worse than the current situation in the circuit-switched phone world. The choice between using tones and signal names depends a bit on who's listening (tourist at payphone calling home vs. subscriber calling foreign country). Why shouldn't this be left to the implementor, depending on what they see is being most useful to their customer base? Roy> I have a two part response to question. 1. In order that this feature to be available, the local MG must somehow determine whether tones should or should not go through the translation table. For fixed subscriber to phone definition, this can easily be done with a configuration of the local MG. For a pay phone environment, there must be some MG/MGC dialogues to determine which option should be chosen. The associated events have not yet been defined in MEGACO. 2. Vendor cannot choose to implement this feature unless the interface is either standardized or there is a bilateral agreement between the vendor of the MG and the vendor or the MGC. > 3. To support V.34 Modems and V.34 FAX phase reversal needs as either a > parameter to CED or as distinguishable event. I'm afraid I can't parse this sentence. I thought we had discussed on this list the various permutations of ANS: just tone, amplitude modulated and with phase reversal. Is there another variation? Roy> Non-V.34 FAX is tone, amplitude modulated, without phase reversal V.34 FAX is tone, amplitude modulated, with phase reversal I thought the intention was to support both in the future. > 4. I am confused about the meaning of the events > * V.21 Channel 1, "0" > * V.21 Channel 1, "1" > * V.21 Channel 2, "0" > * V.21 Channel 2, "1" > 5. Is V.21 flag indication available? V.21 is a 300 b/s modem protocol, "0" means a zero bit, "1" a phone bit. The channels are the ones from and to the originator, respectively. Roy> FAX is only transmitted only on V.21 channel 2. It is a half duplex protocol. I do not understand the use of the events described in item 4. Please give an example of their use. I don't know what you mean by "flag indication". Roy> V.21 flags are a sequence of "7E" bytes. This is similar the HDLC flag detection. Henning From rem-conf Tue Jun 22 21:29:25 1999 From rem-conf-request@es.net Tue Jun 22 21:29:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10webG-0005iu-00; Tue, 22 Jun 1999 21:25:26 -0700 Received: from anchor.cs.colorado.edu [128.138.243.140] by mail1.es.net with esmtp (Exim 1.81 #2) id 10webF-0005iC-00; Tue, 22 Jun 1999 21:25:25 -0700 Received: (from evi@localhost) by anchor.cs.colorado.edu (8.9.3/8.9.2) id WAA08156; Tue, 22 Jun 1999 22:24:22 -0600 (MDT) Date: Tue, 22 Jun 1999 22:24:22 -0600 (MDT) From: Evi Nemeth Message-Id: <199906230424.WAA08156@anchor.cs.colorado.edu> To: rem-conf@es.net Subject: INET99 broadcast Cc: evi@anchor.cs.colorado.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list the plenary sessions from the INET99 conference in san jose, california this week will be broadcast on the mbone. there are 3 plenary sessions, wednesday and thursday 8:30-10:30 and friday 10:30-12:30, june 23-25. all times are pacific daylight time. the detailed contents of each day are listed in the white board. session is advertised thru sdr, but just in case: audio 224.2.196.221/30158 video 224.2.132.98/65332 wb 224.2.135.162/37788 session for wednesday includes the dedication of inet'99 and the jon postel award, by vint cerf, chairman of the board of the internet society. the keynote address on wednesday is by irving wladawsky-berger, ibm. -evi evi nemeth, assoc prof computer science dept university of colorado boulder, co 80309-0430 From rem-conf Wed Jun 23 05:47:54 1999 From rem-conf-request@es.net Wed Jun 23 05:47:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wmK6-0002jO-00; Wed, 23 Jun 1999 05:40:14 -0700 Received: from mailer.psc.edu [128.182.58.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wmK5-0002jE-00; Wed, 23 Jun 1999 05:40:13 -0700 Received: from sunshine (sunshine.psc.edu [128.182.61.166]) by mailer.psc.edu (8.8.7/8.8.7/mailer) with SMTP id IAA26982 for ; Wed, 23 Jun 1999 08:40:12 -0400 (EDT) Message-ID: <03f801bebd75$83866980$a63db680@psc.edu> From: "S.Grant" To: Subject: About all the spam Date: Wed, 23 Jun 1999 08:40:02 -0400 Organization: NLANR/NCNE Pittsburgh Supercomputing Center MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I received this reply: > We are aware of the spam problem and will be looking at > ways of addressing it in the next few months. > So I will be unsubscribing until some (distant) future date. Shirl Grant NLANR Engineering Services grant@ncne.org NCNE / Pittsburgh Supercomputing Center - From rem-conf Wed Jun 23 10:10:28 1999 From rem-conf-request@es.net Wed Jun 23 10:10:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wqUj-0005nX-00; Wed, 23 Jun 1999 10:07:29 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wqUi-0005mX-00; Wed, 23 Jun 1999 10:07:28 -0700 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA23824; Wed, 23 Jun 1999 10:05:55 -0700 (PDT) Date: Wed, 23 Jun 1999 10:10:55 -0700 (Pacific Daylight Time) From: Stephen Casner To: "S.Grant" cc: rem-conf@es.net Subject: Re: About all the spam In-Reply-To: <03f801bebd75$83866980$a63db680@psc.edu> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 23 Jun 1999, S.Grant wrote: > I received this reply: > > > We are aware of the spam problem and will be looking at > > ways of addressing it in the next few months. > > > > > So I will be unsubscribing until some (distant) future date. Sorry to hear that. I have reached the conclusion that to control spam one must install a filter at the receiving endpoint because much of the spam is individually addressed. Then the same filters can be applied to the messages sent to mailing lists as well. Over time I have been building up a set of procmail recipies that do a pretty good job of separating out the spam. Some still leaks through. Granted, there are some systematic steps that the list operator can take, and I presume that is what the reply above is about. However, some of the spam filtering has to be a judgement call, and I prefer to have those messages go to another mailbox where I can scan the headers when I have time to see if any mail I care about was incorrectly diverted. The list operator can't handle that function without human intervention (or more AI than I trust). -- Steve From rem-conf Wed Jun 23 13:28:45 1999 From rem-conf-request@es.net Wed Jun 23 13:28:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10wtXz-0000G4-00; Wed, 23 Jun 1999 13:23:03 -0700 Received: from tesla.comm.utoronto.ca (tesla.comm.toronto.edu) [128.100.11.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10wtXy-0000Fp-00; Wed, 23 Jun 1999 13:23:02 -0700 Received: from riemann.comm (riemann.comm [128.100.11.18]) by tesla.comm.toronto.edu (8.9.0/8.9.0) with ESMTP id QAA00417 for ; Wed, 23 Jun 1999 16:21:22 -0400 (EDT) From: Hassan Naser Received: (from hnaser@localhost) by riemann.comm (8.9.0/8.9.0) id QAA27102 for rem-conf@es.net; Wed, 23 Jun 1999 16:21:12 -0400 (EDT) Message-Id: <199906232021.QAA27102@riemann.comm> Subject: any pointer to MGCP docs? To: rem-conf@es.net Date: Wed, 23 Jun 1999 16:21:11 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Could someone kindly give me a pointer to the MGCP (Media Gateway Control Protocol) documents? Thanks Hassan Naser Univ. of Toronto From rem-conf Thu Jun 24 09:09:29 1999 From rem-conf-request@es.net Thu Jun 24 09:09:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xByO-0002Th-00; Thu, 24 Jun 1999 09:03:32 -0700 Received: from illustrious.concentric.net (illustrious.cnchost.com) [207.155.252.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xByK-0002TR-00; Thu, 24 Jun 1999 09:03:28 -0700 Received: from [192.168.10.5] (ts019d03.cht-ma.concentric.net [206.173.29.159]) by illustrious.cnchost.com id MAA15614; Thu, 24 Jun 1999 12:03:19 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Date: Thu, 24 Jun 1999 12:05:07 -0400 (EDT) From: Scott Petrack To: Roy Spitzer cc: "'Henning Schulzrinne'" , "'rem-conf@es.net'" , "'MEGACO@standards.nortelnetworks.com'" , Ed Morgan , Mihai Sirbu , Zoran Mladenovic , Frank Fruth Subject: RE: First cut at DTMF/tones draft In-Reply-To: <61891BA043DED21180920090273F173802E741@argentina.telogy.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 I'd like to stress that the draft simply gives a set of RTP payload formats for transporting certain kinds of audio and signals. There are many applications which need this facility, not just MEGACO. If MEGACO decides that its application requires that redundancy be done a certain way (for example that both the event payload type and the tones payload type be used always), well, that is MEGACO's prerogative, but this shoud not affect the AVT draft. In the "vanilla RTP" application, two payloads have been given for transmitting a certain kind of information in real-time, and they are related in the sense that it is possible to use one as a redundant payload for the other. The information in the two payloads are not identical, but this is no different from the way in which the information in hifi encoded audio is not really the same as the information in the "same" audio encoded via some low-bitrate codec. If some particular application (like Megaco) wants to use these RTP payload types in a particular way, great. But this doesn't need to constrain other applications. Scott On Tue, 22 Jun 1999, Roy Spitzer wrote: > Henning, > > Comments below. > > Regards, > Roy > > Roy Spitzer Telogy Networks, Inc. > Phone: (301) 515-6531 20250 Century Blvd. > Fax: (301) 515-7954 Germantown, MD 20874 > Email: rspitzer@telogy.com > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, June 22, 1999 8:49 AM > To: Roy Spitzer > Cc: 'rem-conf@es.net'; 'Scott Petrack'; > 'MEGACO@standards.nortelnetworks.com'; Ed Morgan; Mihai Sirbu; Zoran > Mladenovic; Frank Fruth > Subject: Re: First cut at DTMF/tones draft > > > 1. The problem I have is that VoIP and the use of RTP > is fast becoming > > an international set of procedures. To be compatible with > the differing > > encoding of supervisory signaling, the prime emphasis > should be towards > > creating a standard set of supervisory signal (event) > names as discussed in > > section 5. The translation of these names becomes a > function of the Media > > Gateway. These name could translate to standard country > encodings or custom > > audio response messages. This need not be known by the > generator of the > > signal (event). > > Not sure whether this paragraph is agreeing or disagreeing > with the > current approach... > > Roy> I am agreeing with the approach but I want the > document to explicitly state that both the event name and the associated > tone map are mandatory in each tone event message. > > > 2. Item 1 is fine when there is a translation of the > signal (event). > > For the cases when there is no translation of the signal > (event) the > > associated tones may be used. But this may cause > confusion at the > > destination end since that combination of tones may > already be assigned to > > another signal(event). The other alternative is to drop > those signals on > > the floor. Obviously, there if there is no translation > table, all signals > > would be dropped on the floor. The other alternative is > to use the local > > signal translation if present, used the associated tones > when not present, > > and drop unknown signals on the floor only when local > signal translation is > > present. Please comment on this. > > As far as I know (and have been able to tell from the ITU > collection of > national tones), while the same signal ("busy", > "congestion", etc.) has > different tone representations in different countries, I > don't think > that the same tone sequence means different things in > different > countries. Even if there was this ambiguity, RTP would be no > worse than > the current situation in the circuit-switched phone world. > > The choice between using tones and signal names depends a > bit on who's > listening (tourist at payphone calling home vs. subscriber > calling > foreign country). Why shouldn't this be left to the > implementor, > depending on what they see is being most useful to their > customer base? > > Roy> I have a two part response to question. > 1. In order that this feature to be available, the local MG must > somehow determine whether tones should or should not go through the > translation table. For fixed subscriber to phone definition, this can > easily be done with a configuration of the local MG. For a pay phone > environment, there must be some MG/MGC dialogues to determine which option > should be chosen. The associated events have not yet been defined in > MEGACO. > 2. Vendor cannot choose to implement this feature unless the interface > is either standardized or there is a bilateral agreement between the vendor > of the MG and the vendor or the MGC. > > > > 3. To support V.34 Modems and V.34 FAX phase reversal > needs as either a > > parameter to CED or as distinguishable event. > > I'm afraid I can't parse this sentence. I thought we had > discussed on > this list the various permutations of ANS: just tone, > amplitude > modulated and with phase reversal. Is there another > variation? > > Roy> Non-V.34 FAX is tone, amplitude modulated, without > phase reversal > V.34 FAX is tone, amplitude modulated, with phase > reversal > I thought the intention was to support both in the future. > > > 4. I am confused about the meaning of the events > > * V.21 Channel 1, "0" > > * V.21 Channel 1, "1" > > * V.21 Channel 2, "0" > > * V.21 Channel 2, "1" > > 5. Is V.21 flag indication available? > > V.21 is a 300 b/s modem protocol, "0" means a zero bit, "1" > a phone bit. > The channels are the ones from and to the originator, > respectively. > > Roy> FAX is only transmitted only on V.21 channel 2. It > is a half duplex protocol. I do not understand the use of the events > described in item 4. Please give an example of their use. > > I > don't know what you mean by "flag indication". > > Roy> V.21 flags are a sequence of "7E" bytes. This is > similar the HDLC flag detection. > > Henning > From rem-conf Thu Jun 24 20:14:27 1999 From rem-conf-request@es.net Thu Jun 24 20:14:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xMLS-0000vh-00; Thu, 24 Jun 1999 20:08:02 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10xMLR-0000vX-00; Thu, 24 Jun 1999 20:08:01 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Jun 24 23:07:15 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.222]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA17824; Thu, 24 Jun 1999 23:07:14 -0400 (EDT) Message-ID: <3772F28B.6678375B@dnrc.bell-labs.com> Date: Thu, 24 Jun 1999 23:07:55 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net CC: Markus Hofmann , Jorg Nonnenmacher Subject: new draft on feedback for multicast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Some colleagues and I have put together an Internet draft that talks about the problem of feedback for multicast. Its basically a taxonomy of the various mechanisms that can be applied for sending feedback on multicast reception. We believe this taxonomy is useful for both rmt (reliable multicast transport) and avt. For rmt, it outlines the options for a feedback building block, and for avt, options for an alternate profile for RTCP (which was discussed at the last meeting). The draft is an individual submission, and will appear in the archives shortly. Until then, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-hnrs-rmt-avt-feedback-00.txt Comments welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jun 24 23:27:50 1999 From rem-conf-request@es.net Thu Jun 24 23:27:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xPP8-000385-00; Thu, 24 Jun 1999 23:24:02 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10xPP7-00037t-00; Thu, 24 Jun 1999 23:24:01 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Jun 25 02:23:32 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.222]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id CAA18732 for ; Fri, 25 Jun 1999 02:23:31 -0400 (EDT) Message-ID: <3773208C.6BAD94FA@dnrc.bell-labs.com> Date: Fri, 25 Jun 1999 02:24:12 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: Updated RTCP conformance draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I've just submitted an updated draft on RTCP conformance testing. This draft includes several more tests: * collision detection * random and uniform distribution of SSRC * reducing the minimum interval for senders in high bandwidth sessions * timing out participants The first three were agreed upon at the last meeting. I decided to add the fourth since I think its useful as well. The draft should appear in the archives shortly. Until then, you can pick up a copy from: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-rtcptest-01.txt Comments welcome as always. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Fri Jun 25 07:25:53 1999 From rem-conf-request@es.net Fri Jun 25 07:25:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xWhl-0000GZ-00; Fri, 25 Jun 1999 07:11:45 -0700 Received: from pilgrim.cisco.com [171.69.204.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xWhk-0000EV-00; Fri, 25 Jun 1999 07:11:44 -0700 Received: from TP600-95-IMG.cisco.com ([171.69.210.246]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA06385 for ; Fri, 25 Jun 1999 10:10:41 -0400 (EDT) Message-Id: <4.1.19990625100722.03d605a0@pilgrim.cisco.com> X-Sender: bdavie@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 25 Jun 1999 10:11:05 -0400 To: rem-conf@es.net From: Bruce Davie Subject: Draft of possible interest Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have revised the draft on Integrated Services in the Presence of Compressible Flows that I presented at the last IETF meeting and submitted it to the IETF. For the impatient, there is a copy at ftp://ftpeng.cisco.com/bdavie/draft-ietf-intserv-compress-00.txt This has some relevance to RTP header compression. We hope to move it ahead on the standards track after the Oslo meeting. Please send any comments to me and the int-serv list (int-serv@isi.edu). Bruce Davie From rem-conf Fri Jun 25 07:50:58 1999 From rem-conf-request@es.net Fri Jun 25 07:50:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xX9W-0000vx-00; Fri, 25 Jun 1999 07:40:26 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10xX9V-0000vn-00; Fri, 25 Jun 1999 07:40:25 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 25 Jun 1999 15:40:11 +0100 To: rem-conf@es.net Subject: AVT agenda Date: Fri, 25 Jun 1999 15:40:11 +0100 Message-ID: <5078.930321611@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, A reminder that those wishing to present in the AVT sessions in Oslo should contact me and Steve as soon as possible. We've currently had requests from the following: RTP Payload for AAC audio (Civanlar) RTP Payload for real-time pointers (Civanlar) RTP Payload for MPEG-4 with Scaleable & Flexible Error Resiliency (Wesner) Header compression for RTP/UDP/IP over cellular links (Degermark) Multiplexing header-compressed RTP over PPP (Pazhyannur) Tunneled Compressed RTP (Koren) RTP payload for virtual worlds (Stewart) Cheers, Colin From rem-conf Fri Jun 25 08:07:53 1999 From rem-conf-request@es.net Fri Jun 25 08:07:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xXOO-0001gH-00; Fri, 25 Jun 1999 07:55:48 -0700 Received: from host212-140-120-17.host.btclick.com (hotmail.com) [212.140.120.17] by mail1.es.net with smtp (Exim 1.81 #2) id 10xXOJ-0001fu-00; Fri, 25 Jun 1999 07:55:44 -0700 From: To: rem-conf@es.net Subject: E-Commerce Conference - Wembley 1999 Date: Fri, 25 Jun 1999 15:55:33 Message-Id: <195.208842.479748@unknown> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="====================5453515:55====" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --====================5453515:55==== Content-Type: text/plain; charset="us-ascii" e-commerce the future - how ? Find attached a brochure and application to join the forthcoming e-commerce exhibition being held at Wembley in July 1999. Don't get left behind come and find out, how and why e-commerce can help your business create more business. If this message has reached you by mistake then please accept our apologies - you will not receive another email as this is a one send campaign. Thank you for your time, please enjoy the attached information. --====================5453515:55==== Content-Type: application/octet-stream; name="telezip.ZIP" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="telezip.ZIP" UEsDBBQAAAAIAJJi1SbTQptRCBsAAAB+AAAUAAAAVGVsb2dlbmljMiBGSU5B TC5kb2PsWwlwHNWZfqNjZiQxlm87+OABspHNeBjJOmwtYa3LloUlGVvYHAa2 NdOS2p7plnt6LAtCFrYIa7KESmzvLlBUEfCa2lqqiDkSdisBYshSCyxHuAoI EJwF79auoARlMD6w9vvf6271jEYI7BCTKr2pr/vd73//9f430rz04pT37nnw zAMsK13E8tmJ4SLm99T5gDqnMJmxC+26E8PDw1S1HBieSH9WaXDvfraKFQUh uqlPuJJFKmBs5yzGJrGuzV2bb3vztjfZqFRUMJPNr2Rs8GGfwM5po/t40/Bw 6bh5J10lnu/b6kdvb36s93TPDJ/7x3/PxXt6gLEyT/27sxmbn8fYmoAsj/c+ P5j7vQfzYBq2d7Ysf5U30XH8TMYOwayGQJyJ8jOon8FGJ2ffznrZ6bygEOKY 9D1jr/tOkXxn89PZn5Oo/DtPvTMu+03zb/eNnie7vMdePztly2k8uXv5TYno uKxghJ7qSYz9Ae9bZkt+ZI8/2eSs5+xnWUDqHz/vs2v2/Ovjvux97CmS3vNH GDcze7LTljrVhNGj6losFVprqilVt1KB5iWNRpJXRqPRUIuWsAydtxiWmgjz jWqyK6EOhDp702Yqrgzwimqrl7emE8gtX748VM+p0jJ4Wo+rZspS9Di3elXe nbbSphoIrO9TlS1o4Kv1WCIdV+uWhFpVU00O8I2KqatmqFGzBnhzXLMME4uo 6BdX+1Q8dCvUpvSqKaymDCgmPtsUHVW60qPpPbxJM9UYDaqv4KtMI90XajV6 db7SABGYtk0xt6gWdWw09FQ6AcKs0EbDTMT7QO/aNY2h9Zba16vqHD1NLYmp m9OmAWpFzchYyzQSCUzYXr++qf4SLjuFVinmAG9Q9C2pXBQJVmDqJpVv1CyL N2wIhDp0wZdM9oVFXVzr7gZPdIurCTVJ8kC1YvEYKLc0K22pfJcQUFI1Y+ru MDdMvqvTVOK06jZNEZOs1rFtXbXQ3K8lErxL5V1gS0+vBen0qOhiRkKherRQ 711rTWNnajcnce3CLilvdKNJw9pqrFc3oCMD7kzqdiWp6WqcazpPkLxVM5kK 85TBB4w0T6ImCSmjtdswk+gWV2NaSgP5HBXUx8Rmkn2KPnBeylYNIob3mUrM 0mJKYgwt2qyYPYYeRnXCiG3hfdBJ3dLQPSlEBBK6NXRNGYm0heUwn7FNoxnC XN0GAXQnDPDRu36Yj6g6T/Ua/SmxBVqsXxkAUaSD4ALkOEAcGeE7tqua27SY Kleh7VFVLG1Cg8M8ofaALiEyU9F0oi3p6hHVWWqPpqYEx/vVLp7SINa4mtJ6 9AhvBrFhvqvF6CcmjKaaY29SAXdzSEjd3pcwTDUe5grkA5kYukocFORrWNmR OAQIdduaVlOCPbS2oqf60ZBSU0JAYd6lpCCxdB/axZJObzTBFqRIFcldJbYl TFu0sEHalsjGLGwDNYkUL9eEkVNTXCWGWGpqUdhe1pkqwRNpPdZLtBqcFtyi G/0JNd5DHE7HernCMRDE0zSQADarmsROrJQmFoNeMBTL2NzsS4AcniJHgyFh 3qukuA7xm9Bc6IBjBUK1BKdMA9N2qaBGjXAQAQXvU0xLGoBgJExMJxOFjsRA uWJB78DtvoRKi5NQEirER73RpsR6wUET8hVyJlbFjViaLDkSCPBQyKNy67y9 muxeobX1l7c1t3fytubOlo6mEOe8nPPGXhWygBbFib4BBX6YtGPEffM1Vpxn pHL5IsfEsYiegl/xSsVRJ11JqoucZaBImsUbFTNex+uT6vYLNmgp5YI2hfxo DLVcNyK8PCvxb20Kjd/lG0vN2/s0+I0mKL6scFgFoojBvUYCSggfSGavkBuk xmtyJjTUx2JGGscCicsjgZDboMTjOMFTWVRky0qOKV/d7Tlpuk1oZBdUqX/R mGPs6f60DF1rpKCMRlxwRtIRCFSgrsn2KKH1aVMwxEmZBCMAUD3N2btpNbp4 p2Yl3OGZHQKVcCjOSnycpcZbbdRaWe2hQKDD7FF0mJtwB57WdpqTnNtmzGGJ OUZav5pA1uIYxKRJ4RV5l2GIt2eW+pzKMyqV50hjUZCrr9102rUoV7cQnGmd baU2qONKZfuoWjjxNhxydXLg6G3KFAjU8w31nTjrthkUKjgBFEXZ8jDGGeqc d+T66dDxnhyREA3POCXI/a5q4LXRGr68trqaR6uyzoAIdir9OsZFeDv6L62q jlYvj3qPnlCosaN9ZfO65vbGZt7U3Fm/es360Ibm9kubL2iq72yu42OE+Djh OAVF3nuBcy0I8zYtHt+O40FXt1Og6TRAgYl2HNfrLcSp6SRfyOvJVBZFuOD5 +VVVvDy6iFcsq+DLcS5Go7VLI2KdGIkOXOkVCynwdMmkEZesQOyjGxaXB5oM Ry0xRBduDQzvVnGmr1Pj6RgdyWTEmTNQcCDCAkT9it6DTkIqVtYGI3ACMqbJ kKCRtqWo4sx3bYqW15wgSQQ78Ou4rWgJcWYLV0uBzhpDj6OH0d0N1YiEmvWt ac1EFFPH18rAwnHnFNWpTitxNWuThvQaIs7NVgWwRK4TEbcXCs8a4EMaTOVa TcQ/o/m/bGmU11ZW1NC9ok1DHN8K75OiruglOtVW8BqoXdXypZURaR05xteG GhVQl0gIRmBXGUUZx8ioi9c6CuZw11S7KT4TEu1Ooy4h+AB2xnHxGLGFWC9u BCqpx56K6mgE6kbWY6oWxWmexVAiRekS4lf7LFXcJ0xV6UZQE+Hr0132zSol heV0gq6THVlaEmpkSwUTqXV8tSXuOZhRV2Mgji6AdLnBnClasUsdMOxbS0ze Gp14ckRaJEolAQrcbkKpZBFr2hEvlXDH6DEV3DwioQxnsFJV64SZZISb0Hqy jT1Lq5YjSE2nILFI9QK+AdsptwwLZrinqiIaiS5bxBFMu8G5NDgaHDO2EX0y 0CVO4vZimCLIh2iglL3iXkr3VVN0h6tQZSCPwJyYqhugw9tXWIKQpUdznbhY +jq+kpoR2zqe0BpjY/G0qzoyQrdUpzvd8yjMbunYyDs7+LrmVavXdzavCzUM fImiSk++XnUFJgP6rCCerivS3GMyFIekYjJaFnGxc+2xjLpsMwzzqgoE8BoG wgOsMxTcHqRZhnn7xkq+tL49Elrr3CMhn3Uq3S5HtJcUTVrMAIqJBEliLJt1 6zPMFKKFiJLplDCDbiOBWA87xHyZW3a82MhuHYHQ0mLj4YxtY8WujAsGtNp2 gdwc2UbEEQkuNyF5l7FZLm+2kqWu980g48vvPJGQuOB02us7gjSEqxfxMk7A mppaHJa1VWTS7mG0EVdbWBndbMQlKcwraqK4AWmxLQm13zDi8JOQVT/dADPE dfkVvHy9YdoxRU10SbRmSWX1olDG5anRuRfKDebQFEMftVeobmj87+wm0kSa SBNpIk2kiTSRTikVMDYNmA6cBawAGoAtQBK4HrgT+BfgReAN4CgQKGSsBmgC FCANbAP+GrgR+DnwBPA08C5wHCj0M1YMTAFmAjuAOwOMPUZ/WQbeAXYEGbsF KCtibAGwDEgCOrAV+B5wPbAT2AXcC+wF7gN+B7wNnFHMWAhYChz9/JPBDwbZ 26+5n98+95vnHsfnFw/gg/dv6fP4c/ezvXfvvfuOv79NfARrQkWb89nWoYbF eY2tZSwg3lNZcXXwRjs7kp/ryUfB1MbW6YyVNiz2U6ajlbFLWkU5z1uWI0QX FnJGT2cti33FIyUWQJ4y1KOGqoupNFmWLlrssyvsGYqIVHcGUWJuHpTlNywu keUSKteS/Es88q8G2oCELf8bgNs8OvCYRw8+8OjCbI8+dGTpxDHgqFfnTrnw TtDznx5/3KlPf+GtMQt2yof5lPnmieesMl/ePyRY4euzy2ZPZplgAsHXgyxv 9/DmohfmF71ewO7ABzLLL/NhNPvOqcr/yNfQAfIB34PNXw9837b/W4A7gIeA IWAefMB84G3bH1wJX7AJ2Aqkgb8NjvgI8gmG7RdMjz8ogt2/B6RLGHsS+Ayo OANrAA8Dvwbm4Z51PvBD4O+AW4EvRDr2hZ2OHPnii5E8SuIh85Q5dvjw4U8+ /J//evfNV1987un9v3r0oQcy5RTI9/kDx4eHi/J9hcX+oJvrcXNpN/eym/s9 cjTyPbdG+cLJ3eXmXnJz8044uYfc3C3DTm7IzdF/e+VBAnk+H8vL97ECqm1w 5OLIIpv/p8Lr415mHPEWMlq+wcLb3kLGf7BlFF71Fv5UtH3NJG12xUKyfjxP 3vrzz6OR0oewmXRGVgPNwO+BBOTXBzwK7AfeBQ4An9qynQG5LgLuBx702NQj wC+Al4C3gA+Bw8Ak2NVsYD7Agb8AmoErARW4DviBxwbvAPYAjwL7gYPAcbJN IDCJsQuARuBKwAA+Bg4DU0uxIWAWcCYwB+DAOUA5EAaWAFGgAqgBmoBNwFXA 1cCHwBGgZDJiCGAWcC6wANgxBTEHcAVO/V7gJuBmYNE0+LZDx4YO4TN4aFC8 Dw69J96H3PdBeg6iA56iZvCQ6DwoiwffevXgyy+8/CxATz+OfhzhzC+jADqz 87zRhTc6KLZDEervjUYCWVELYpkC9v3MWAbd1o7nE58EguBvE9APnAH+1Hp4 djcwaPPuc5t/xLv34/kjupvx38UnU/hNi+efEU95trEL73sL+72FX51Ey6Ns VBo5eb32nJ9xmmtkz37Ybi7Y9nzp5FlnO/YsRs75yuP9zLd7mEbnYfSMU5Hx Dtse9sEGXoMuvg4cBPJn4MwAtJmMWcBTwJpZjP0Y+Mks+X/FRz8d+r+DB95+ 47VXXnrl+f946vF/e2Tf/ffdc9c/7vzRjptuHM23bzAV+q//XJ643//cOSuf dHMXH3Fyd7q5vW7uB0edXMkxJ1fu5pYdk/Mud2uuds/0R9zz+2b31Kb/Fpa5 GYKumeL5qn1uF/qrjsr5qt1Vr3RzN7u5Oe5q7W7uh27uJTfnBy1s3qnK8WRO vgODxSOFjCP6ZI71rzjmMW/hl+w0J/rZxHyvyeZX+caz+tuHL5885+xRMfzX svzbh+dIy7fP/1I6v6qnSdnvB94CPvTowQe2Lnxk60PQ1ol7bL1IAdfZuvGy rR+XZevIUfoc+uiozHxkl8dl0kQ6tTTWtxMUT9ixxey57Kx9bAnf9953z973 08JzgHN//NPCMmDBvvFXmEh/7mkqW8SK4Y6uZKXi1yqUqnDD+Hg4j97Mz9qZ wUyWZApLoEyee9o/xdl0oIQ1LPY1ts5myZaiArYCs+BmiTdOMdbCVIyIM43p rIdxVoHaINr9IuaZxsSXWnPZxS1zWUdrHrsEYHUYTTPU5ZyhUsyQJ2fwTWLy CzBncBXiKBpblXPsUjE2X47NC7pLLoMbpVHLco6qEqMK5Kj8ElrRpTXCCsXI SM6R1agtxGfFwgKMb2ydCer9on9lzv41or8f/QtZgNUQb9yfiFzI6ld8MnyP +LXdTNaEkd0Ym4Y0LIxci7wJ9IhnH+tF3UpITEerN0XYiVKH3gCrx9pxjFBZ Ch+SaimkyiBV+nYJ67Oo7O+LitYGrGawGNvCtmJlA3Oron4ym3RTr68UoN9S nei4l03xwdnQntlq1smamTNfmWg921dmt3ZgJ9R6BpPfiBaCrYXsHNGrwneO oLIRKyXxUe3d5LMLg8OsXPSp95ULCiQ/iI8a+mhi586aF4k9dPkuQk1pzp6c rUEuJWafxGYw2onDB9JHGr/OV/cl4ztRS9ZBtMxkI2MXsstW3Mu2+hYy0qFm 9CDZKFhLExz3M/HtLVtsy2Uxo1+Ltdh2Mtu2kxJpJ1HYSRnNKfsutPtKi/iO bREB2TdHP6n9Z9raH3Bsj7gt+p1j95P6PsfW93zqR3ITfcrsPlKz5wrNtmea zkb1kvo8z9Zn0QtxZlRI7oDQqSC7GJwbYF3gI2lwXPDYns9RB7ZJzPuJb5PQ lLVCY7tdf2QJPaSRC9hZLPQ0Z8X/nn9dYEXJZ5N+OfWGmTVnHpv30NnbFqxw U5a2SZ305ZUJeazHjCSlhNDtoNuLs42Q5JQ8bveysLoh7Jb0rFraCul2nrSV TuyqD3P0o58mKDRZtp6HpZ7nhdFSAn51sjZoIseTeLEFNtYnVoO+Nyz2Szrr BZ1BtkH00fDssmmV2t5uy6AdmMyuZUtgtYbgEVkRx7Pb9g1SX0vANUSQZXE/ ec5SrCWk5Hq4Fnu+FiAk5uvE2L6cMy2kmRaONVMTa1jhY2ZeEyPfR1TFwSNp O9uF7RWz81zbmclEaMJIRTta/ZjCTwdMcBm7HLP/Td4ywc0m4Y/SrneQvJNc K2dLmriPJBjAaPnNAf02FQpFJiN+o0zxM333RfEvxaj0o1f6m4L4UV+B/L6a vhuh+xG144rE6OetdDObZfehuzO14eokftGHa/HQMrGaf4jmwUEjztRzmQz4 CSTDFWz+x5MFHYIadsMNN7DDRAKO4KGdjHLBoaA94NwCmjh/KCoWKBgqF/VF Q/JXupkpjxWLcURcod2/gRGBst6Hevg5KHHJEG4f7AnfZKz1nE+Q4ROHXT79 avIv831i7SlDBTYVzk976fhfwkSIwB5k8suPd5j84oT+iJGHztAaNgtIAluB fwYpDxTKPwc+AzwLPA8s9MMlALdiyduB2hLGvgs8BTwPNIH9FwNtwDrgKiAO 7ADbfwLcB/zM/vriP4EXgDeAPsjhWmAv8ACwFLJbDlwKXANowFYgDLlVAhZw rf113q3Aw8BjwBTseS6wm95wY6cLlC7Fvi8H7sT+7gEWYV8/A/4b+5gzVdIY gIvPxPAwqXQIJrcOR/4VOJKbkeNABM96PCtxyNbBzfaLgy0Oo+rH8bRJHN1t cLib0CstXMg6GFoM723CoZH5pmBwVHIcQrZJVmL+fjipLd9yCs6yKWgTc2bP IWlRRQDUI+o0tNPMvWhNov7bvbv5J7m7uOh5emZe+kfkWm4aKBCLT+zuJHcX ZJsrPy08cWBw7nBp9oex/60emrr518HKXG3P/9UDfPfNn8zP1TZcOXvJpP7J d+Vq2zzjs9rjT3W/mqttVcvPV5a9uPKV0W0+9gd+UeeJrbvvyNVWW6ZferV1 17O52nzC68pnRsKxW3rT/7d3daFxVFH4zOzMZpNoWCOmTUvjKq2N1Gx28+eG oiYlW00xP02qEREqNtZoqZsmESsi5KHaIkIrClYINA8qgiJiAr6VgMUnhQgW 61tBH3zwoZS+9MGu57v3zjTd7Mlmog8W7xfuzuyd+ebcme/OZM6Ze2aX3btO nL1xz/fsAk44KmybrsCY90PGshuHm1uJMZkIGTmPGW5FRk9tyJj3mRGryEjW hYxEFTO8iozLyZAxmWCGX5Hx9d0h41I1M+IVGbMNIaOnlhlVFRnDjSHj8zuY kTAMR2RICsoMSUGZISkoMyQFZYakoMyQFJQZkoIyQ1JQZkgKxiIrKDMkBWWG pKDMkBSUGZKCMkNSUGZICsoMSUGZISnoRVZQZkgKygxJQZkhKSgzJAVlhqSg zJAUlBmSgjJDUtCNrKDMkBSUGZKCMkNSUGZICsoMSUGZISkoMyQFZYak4KbV 61OijIJD+xzavw9X6W+vROMlmIfwfmGDvFevYJ1isdy7rIo9zqxDUz6p8kfN VUILMY8YB6YY3+QmzeoIVQwjltGDaBPfHjac4Ta5bjzme74b81aMS1EIDuYB vsnFDfA0pWiQEL/DDXNBRRoRU+7k7bDQvuM63Ef8YEBKYBaYxcco31IfVXFN PC9pf0BZr417LiBa7zUxPXDycWXJCWBWWWVpgBCHRIxPRxxTbBsxuRkVYe5e 51bG+Gjp6NkMu7S9XPNYp2pzVazadX3XE9uM+Pxrqt1wT4KjxkcqfuaWHirx 9yjuS8qRZlZ4pFgoz/VOBo+jDM6Z6QFu6YTRhWi33ksqQZm91M9agmcuOEL3 84l+LHFqM9Ey25pQzfr43a53UA4/1/WZbsDPrh4F5hA6p0exJOLlx7l2Ux1q 0RGajKkdpbtqEQGfxpeqFmmRBWvLQMJGFdtv5PITn9OnV2q6AWg1i8V6872m jIs7bZat5Tqvtez2w40i+nTJqUb6HL389rmr14cmkl+8n6BdOxd+ZVEI52i9 WX6W9FGdJ32OL5J+w94S6UvzJSL1/lAEh3GW4BqfMBvHlXmz2dZ2RweWexw8 SyB60kGEn+gZB0oQjTsqak2TPGV/X71dEJ2B/yuomPwpR7fjd0+fidjGzSRh XadObq7DPLa1Z6T32f78SGoknepNcx8I1+H60nm0fVC9rYpSa/HRhjbSHLRr 4OVDU4XpwuGZ1FhhajyVS2dIPR0PoOa3H7nQvHjeUfOPzuXx5sCV8zHTFkxx JcIUVyN7obGwsLCwsLCwsLCwsLCIAsn/R4178ceLc+mtyQ8+Yv//oetfYfye X1L3BDunnvHT4adOkvHRSccCTpCOBbxHOhbwIemxdHOkw8SfkPbXvyTt0yOG AN8ZA8swpu4C6W3/QDom8Bvd6uvrWGKr9oePa78Y8TlME2aK6BGmC3cmlC0y NstNm5J6myUxBAwDhFmYxG6oN7lS4Jwz/iQKo5AZU32INOkIafvfkT4mv5jv WIa4x8Hh/r6Djz/V3xe2+ukXp/AqOLU2top3CIe73cvTQS5vUjd1UDub66A8 dVGWWqiNv6O2hb9lqY+XtfD3dl6e57kM/+W4dNJe/uvgNTr4r4veUs3GviEs k0tn0u0dWd6LbCaoy2Zas9nW7i7MkYWFhYWFhYWFhYWFhcXtB/ipcCzheQbe JhxcPPOGJwrnDz4q/GH43/DF8fwbPj78dfjyeIYPnx3JRsiPg98O3x45cBi9 gd8H3Ur61xa3kXY07+WS4nIfaX8dOXLIjdtBpPJWd3JpNlzkxu7igmxJJJ9h nEUraT8by5HUhxxXJKUhPxXZpw9zyZnlf3HZbeaDYqGBEW4FlT+ZV6kfSDOJ ggbynWBb6EPxah1LWtKL9+Kj5+S1068vnHfmF/c/jzENj5AZlMXIqvFcQSZr dNSRq+yj32JakcDYwuWFbXp+TI2YG1+VArNebFHv07v5u7cVCQZNbXrq06iy elRl9b5B/Wx9ZYZzkNEuoZnt44jj3F2v/QfxYUZT+av2PFp7cub4R9l/5LgH 9h2T5T9JQ9wLXlmLVhb1fPWKah+IbknGRuz/m/gn9tF37fXw/wuH1Y/V6D5U eu3G/++SMWzBjxSqe4KBUdRxlTqZMZ8OlqdzdK37m2Pl+5zFfwd/A1BLAQIU ABQAAAAIAJJi1SbTQptRCBsAAAB+AAAUAAAAAAAAAAAAIAC2gQAAAABUZWxv Z2VuaWMyIEZJTkFMLmRvY1BLBQYAAAAAAQABAEIAAAA6GwAAAAA= --====================5453515:55====-- From rem-conf Fri Jun 25 08:54:29 1999 From rem-conf-request@es.net Fri Jun 25 08:54:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xYGC-0003mg-00; Fri, 25 Jun 1999 08:51:24 -0700 Received: from smtprich.nortel.com [192.135.215.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xYGA-0003mV-00; Fri, 25 Jun 1999 08:51:23 -0700 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Fri, 25 Jun 1999 10:50:52 -0500 Received: from zrtpd00x.us.nortel.com ([47.140.224.108]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NTG1SS63; Fri, 25 Jun 1999 10:50:51 -0500 Received: from americasm01.nt.com (prtpd1gd.us.nortel.com [47.202.36.60]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NMSV17CS; Fri, 25 Jun 1999 11:50:50 -0400 Message-ID: <3773A4BC.9A106116@americasm01.nt.com> Date: Fri, 25 Jun 1999 11:48:12 -0400 From: "Chris Fulmer" Reply-To: "Chris Fulmer" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: AVT agenda References: <5078.930321611@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 What's the DTMF-over-RTP status? -- C Colin Perkins wrote: > Hi, > > A reminder that those wishing to present in the AVT sessions in Oslo should > contact me and Steve as soon as possible. We've currently had requests from > the following: > > RTP Payload for AAC audio (Civanlar) > RTP Payload for real-time pointers (Civanlar) > RTP Payload for MPEG-4 with Scaleable & Flexible Error Resiliency (Wesner) > Header compression for RTP/UDP/IP over cellular links (Degermark) > Multiplexing header-compressed RTP over PPP (Pazhyannur) > Tunneled Compressed RTP (Koren) > RTP payload for virtual worlds (Stewart) > > Cheers, > Colin From rem-conf Fri Jun 25 09:26:21 1999 From rem-conf-request@es.net Fri Jun 25 09:26:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xYkA-0004gp-00; Fri, 25 Jun 1999 09:22:22 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xYk8-0004gf-00; Fri, 25 Jun 1999 09:22:20 -0700 Received: from ksat22 (ksat22.rus.uni-stuttgart.de [129.69.13.26]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with SMTP id SAA03755; Fri, 25 Jun 1999 18:21:49 +0200 (MET DST) env-from (wesner@rus.uni-stuttgart.de) From: "Stefan Wesner" To: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, Cc: "Jerome. Vieron" , "COMIQS" , "'Karine. Renout" , "Michael. Speer" , "Anders Klemets (Exchange)" Subject: Updated draft on RTP Payload Format for MPEG-4 with Scaleable and Flexible Error Resiliency Date: Fri, 25 Jun 1999 18:21:22 +0200 Message-ID: <003f01bebf26$c3cc4840$1a0d4581@ksat22.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've just submitted an updated draft on RTP Payload Format for MPEG-4 with Scaleable and Flexible Error Resiliency draft-guillemot-genrtp-01.txt The document contains beside a new general section on MPEG-4 an improved section on how to handle forward error correction within the proposed format. Additionally a section on how to handle SL-PDUs rather than plain MPEG-4 AUs and some modifications in the payload format in order to reduce the overhead has been added. Comments welcome ! Kind regards, Stefan Wesner. The draft should appear in the archives shortly. Until then, you can pick up a copy from: http://www-ks.rus.uni-stuttgart.de/PKB/Publications/draft-guillemot-genrtp-0 1.txt From rem-conf Fri Jun 25 09:50:00 1999 From rem-conf-request@es.net Fri Jun 25 09:49:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xZ9L-0005h7-00; Fri, 25 Jun 1999 09:48:23 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10xZ9K-0005gw-00; Fri, 25 Jun 1999 09:48:22 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 25 Jun 1999 17:48:18 +0100 To: rem-conf@es.net Subject: RTP interoperability statement and testing strategy Date: Fri, 25 Jun 1999 17:48:18 +0100 Message-ID: <5870.930329298@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I've just submitted two new internet drafts: an RTP interoperability statement and a testing strategy. The interoperability statement is a first attempt to enumerate the things we need to demonstrate in order to move RTP to draft standard. The testing strategy draft provides a set of tests which one might use whilst performing that demonstration, and is the counterpart to Jonathan's RTCP testing draft. Until they appear in the archives you can retrieve these drafts from http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-avt-rtp-interop-00.txt http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-avt-rtptest-00.txt Cheers, Colin From rem-conf Fri Jun 25 12:53:55 1999 From rem-conf-request@es.net Fri Jun 25 12:53:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xbzW-0000TS-00; Fri, 25 Jun 1999 12:50:26 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xbzV-0000TI-00; Fri, 25 Jun 1999 12:50:25 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id F1F914CE1B for ; Fri, 25 Jun 1999 15:50:24 -0400 (EDT) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA16739; Fri, 25 Jun 1999 15:50:23 -0400 (EDT) Message-ID: <039a01bebf43$ed147ed0$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: Cc: "Glenn L. Cash" Subject: draft on RTP payload format for pointer Date: Fri, 25 Jun 1999 15:50:07 -0400 Organization: AT&T Labs - Research MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have just posted a draft describing an RTP payload format for transmitting real-time pointers. If you want to take a look at it before it becomes available on the regular web site, it is available at: http://www.research.att.com/~mrc/draft-civanlar-pointer.txt or http://www.research.att.com/~mrc/draft-civanlar-pointer.ps As always, comments are welcome. Best regards. ------------------------------------------------------------ ----------- M. Reha Civanlar Technology Leader, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf Fri Jun 25 13:34:59 1999 From rem-conf-request@es.net Fri Jun 25 13:34:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xcdn-0001Xr-00; Fri, 25 Jun 1999 13:32:03 -0700 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xcdl-0001Xh-00; Fri, 25 Jun 1999 13:32:01 -0700 Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-green.research.att.com (Postfix) with ESMTP id C1F121E00A for ; Fri, 25 Jun 1999 16:32:00 -0400 (EDT) Received: from research.att.com (mathias@descant [135.207.17.202]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id QAA20012 for ; Fri, 25 Jun 1999 16:30:49 -0400 (EDT) Sender: mathias@research.att.com Message-ID: <3773E6EB.AFB4CB75@research.att.com> Date: Fri, 25 Jun 1999 16:30:35 -0400 From: Mathias Kretschmer Organization: AT&T Labs Research X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP Payload Format for MPEG-2 AAC Streams Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've just submitted a first draft on RTP Payload Format for MPEG-2 AAC Streams draft-ietf-avt-rtp-mpeg2aac-01.txt Comments are welcome! Regards, Mathias Kretschmer From rem-conf Fri Jun 25 13:38:42 1999 From rem-conf-request@es.net Fri Jun 25 13:38:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xcjt-00023t-00; Fri, 25 Jun 1999 13:38:21 -0700 Received: from karna.vayu.net [204.152.189.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xcjs-0001pn-00; Fri, 25 Jun 1999 13:38:20 -0700 Received: from leda (204.152.189.30) by karna.vayu.net (Worldmail 1.3.167); 25 Jun 1999 13:35:12 -0700 From: "Jerry Scharf" To: "M. Reha Civanlar" , Cc: "Glenn L. Cash" Subject: RE: draft on RTP payload format for pointer Date: Fri, 25 Jun 1999 13:38:00 -0700 Message-ID: <002e01bebf4a$9d7c0b70$1ebd98cc@leda.vayu.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-reply-to: <039a01bebf43$ed147ed0$4683cf87@research.att.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have several comments about this draft. First, there are pointing devices with more than two buttons, even if Windows does not believe it. The mouse indicator should be able to indicate multiple buttons and button chords. Second, the assumption that the transmitted media that the pointer is to combined with is integer pixel based is not necessarily a good one. In particular, were you to have 3D vector system such as GL or PHIGS, there is no direct relation from viewbox on the sender to pixels on the receiver. It is nominal in such systems to represent pointer position as a fraction from 0 to 1 in both x and y directions. Since this will work for presentations as well, I would recommend positive fixed point numbers between 0 and 1, with the same right and down semantics of the pixel model. The receiver than takes the received numbers and multiplies it by the number of pixels of height and width the display has been scaled to, and the desired mapping is maintained within one pixel. I would think that 12 bits per direction would be sufficient. This would also allow a few more bits for representing mouse buttons. Also, if mouse button presses are important to send, then you have to make some attempt to protect against packet drops. Perhaps the logic in the DTMF draft would be overkill and perhaps not, but including the mouse functionality without any attempt to protect it seems bad. jerry From rem-conf Fri Jun 25 13:44:43 1999 From rem-conf-request@es.net Fri Jun 25 13:44:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10xcpS-0002l4-00; Fri, 25 Jun 1999 13:44:06 -0700 Received: from pita.cisco.com [171.71.68.13] by mail1.es.net with esmtp (Exim 1.81 #2) id 10xcpR-0002f6-00; Fri, 25 Jun 1999 13:44:05 -0700 Received: from localhost (dwing@localhost) by pita.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA09230; Fri, 25 Jun 1999 13:43:04 -0700 (PDT) Date: Fri, 25 Jun 1999 13:43:04 -0700 (PDT) From: Dan Wing To: rem-conf@es.net cc: Stephen Casner , c.perkins@cs.ucl.ac.uk Subject: I-D: Tunneled multiplexed Compressed RTP ("TCRTP") Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I just submitted "Tunneled multiplexed Compressed RTP ("TCRTP")", draft-wing-avt-tcrtp-00.txt, to the Internet-Drafts editor. Abstract This document describes a mechanism which improves the end-to-end bandwidth utilization of RTP streams over an IP network by compressing the UDP and RTP headers and allowing the packets of multiple RTP streams to be multiplexed into one IP packet. This new protocol is useful in low-bandwidth environments, such as dialup modems, ISDN, cellular, and G.Lite which wish to reduce the encapsulation overhead of normal RTP packets through the entire network. The protocol provides mechanisms to ensure synchronization at certain points to reduce the requirement for the receiver to communicate synchronization loss to the sender. As the I-D publishing process is usually quite backlogged near the cutoff date, I have also made it available on our FTP server if you would like to review it before it is published as an Internet Draft: ftp://ftp-eng.cisco.com/dwing/tcrtp.txt We have requested a time slot to present this document to the Audio/Video Transport WG in Oslo. Comments on the document are appreciated. Thank you, -Dan Wing dwing@cisco.com +1 408 525 5314 From rem-conf Sat Jun 26 16:11:42 1999 From rem-conf-request@es.net Sat Jun 26 16:11:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10y1Ug-0004c7-00; Sat, 26 Jun 1999 16:04:18 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10y1Uf-0004bx-00; Sat, 26 Jun 1999 16:04:17 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA06725; Sat, 26 Jun 1999 19:04:13 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA14136; Sat, 26 Jun 1999 19:04:12 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <37755C69.F0098132@cs.columbia.edu> Date: Sat, 26 Jun 1999 19:04:09 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Roy Spitzer CC: "'rem-conf@es.net'" , "'Scott Petrack'" , "'MEGACO@standards.nortelnetworks.com'" , Ed Morgan , Mihai Sirbu , Zoran Mladenovic , Frank Fruth Subject: Re: First cut at DTMF/tones draft References: <61891BA043DED21180920090273F173802E741@argentina.telogy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Roy Spitzer wrote: > > > Roy> I am agreeing with the approach but I want the > document to explicitly state that both the event name and the associated > tone map are mandatory in each tone event message. I don't see why the specification should mandate this. It makes sense in many applications, but maybe not all. > > Roy> I have a two part response to question. > 1. In order that this feature to be available, the local MG must > somehow determine whether tones should or should not go through the > translation table. For fixed subscriber to phone definition, this can > easily be done with a configuration of the local MG. For a pay phone > environment, there must be some MG/MGC dialogues to determine which option > should be chosen. The associated events have not yet been defined in > MEGACO. This is outside the scope of an RTP/AVT draft, which is ignorant of Megaco. > 2. Vendor cannot choose to implement this feature unless the interface > is either standardized or there is a bilateral agreement between the vendor > of the MG and the vendor or the MGC. Again, a Megaco issue. > > Roy> Non-V.34 FAX is tone, amplitude modulated, without > phase reversal > V.34 FAX is tone, amplitude modulated, with phase > reversal > I thought the intention was to support both in the future. I had forgotten to list the events in the table, even though they are described in the preceding text. There's now /ANS, /ANSam, ANS and ANSam, which should cover all bases. > Roy> FAX is only transmitted only on V.21 channel 2. It > is a half duplex protocol. I do not understand the use of the events > described in item 4. Please give an example of their use. Other modem/negotiation standards seem to use V.21 in both directions, so there seems to be no harm in including it. > > I > don't know what you mean by "flag indication". > > Roy> V.21 flags are a sequence of "7E" bytes. This is > similar the HDLC flag detection. Do we really want to include all possible modem bit patterns here? Just asking... > > Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Sun Jun 27 08:23:51 1999 From rem-conf-request@es.net Sun Jun 27 08:23:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yGgc-0002W0-00; Sun, 27 Jun 1999 08:17:38 -0700 Received: from galaxy.uci.agh.edu.pl (uci.agh.edu.pl) [149.156.96.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yGga-0002Vj-00; Sun, 27 Jun 1999 08:17:36 -0700 Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id RAA11855; Sun, 27 Jun 1999 17:13:07 +0200 (MET DST) Received: from madzia.kt.agh.edu.pl by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA21417; Sun, 27 Jun 1999 17:11:06 +0200 Received: by madzia.kt.agh.edu.pl (SMI-8.6/SMI-SVR4) id RAA12436; Sun, 27 Jun 1999 17:11:02 +0200 Date: Sun, 27 Jun 1999 17:11:02 +0200 From: pach@saturn.kt.agh.edu.pl (Andrzej Pach) Message-Id: <199906271511.RAA12436@madzia.kt.agh.edu.pl> Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND To: nm-australia@amazon.postech.ac.k Subject: Broadband Access Conference (BAC'99), Preliminary Program Cc: nmkorea@amazon.postech.ac.kr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Prelimary Program of Broadband Access Conference (BAC'99) is available on web page: http://bac99.kt.agh.edu.pl You may register now! The conference addresses a full spectrum of issues related to a residential access - from signal level, through network architectures and their life cycle costs up to live field trial description. The conference will help incumbent operators to determine their own technology migration path to the broadband forefront that will match their current status and prospected market niches. The conference programme is organised in five streamed sessions: * Digital Subscriber Line * Wireless Local Loop * Services for Home & Office * Architectures, Traffic & Cost Modelling * IP Migration towards the User From rem-conf Sun Jun 27 23:16:15 1999 From rem-conf-request@es.net Sun Jun 27 23:16:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yUYI-0007YJ-00; Sun, 27 Jun 1999 23:05:58 -0700 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yUYF-0007Xn-00; Sun, 27 Jun 1999 23:05:56 -0700 Received: from accordion (acsys-temp1.anu.edu.au [150.203.20.65]) by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id QAA24206; Mon, 28 Jun 1999 16:05:12 +1000 (EST) Message-Id: <3.0.32.19990628160524.0099a8b0@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 28 Jun 1999 16:05:29 +1000 To: Jan-Ming Ho , rem-conf@es.net, jj@startap.net From: Markus Buchhorn Subject: Re: request for Mbone feed Cc: Sheng-Hsiung Huang , chinfu@iis.sinica.edu.tw, Chia-Hui Wang , Lih-Hsiang Chen , feng@iis.sinica.edu.tw Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 09:19 21/06/99 +0800, Jan-Ming Ho wrote: > >We are representing Taiwan to seek for Mbone feed to our Academic Network, >Taiwan Academic Network, or TANET for short. We had long been suffering >a low bandwidth connecting to international internet traffic. But, we >recently upgrade our connection to the US by a T3 lease line. We >appreciate it very much if we could have any institute here to provide >us with permanent MBONE feed. We will run a permanent mbone root for >the academic family including universities in Taiwan. We are also >willing to transit this MBONE traffic to nearby countries based on the >availability of physical connections and bandwidth. Since Taiwan/TANet now has a direct connection to the STARTAP in Chicago I'd suggest getting an MBONE feed from there - contact John Jamison (jj@startap.net), who may or may not be the right person, (sorry John! :-)) but should be able to point you to the right person. APAN and SingaREN also get their MBONE feeds off the vBNS through STARTAP. Cheers, Markus >Jan-Ming Ho, PhD >Associate Editor, IEEE Transaction on Multimedia >Research Fellow (O) 886-2-2788-3799 x1803 >IIS, Academis Sinica (F) 886-2-2788-3799 x1606, 886-2-2782-4814 >Nankang, Taipei email: hoho@iis.sinica.edu.tw >Taiwan URL: http://www.iis.sinica.edu.tw/~hoho > http://www.iis.sinica.edu.tw/CCL > http://twstudy.sinica.edu.tw > >=========================================================================== === > > > > > Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Mon Jun 28 01:44:14 1999 From rem-conf-request@es.net Mon Jun 28 01:44:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yWym-0001MX-00; Mon, 28 Jun 1999 01:41:28 -0700 Received: from telecom.sinica.edu.tw [140.109.13.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yWyk-0001MN-00; Mon, 28 Jun 1999 01:41:27 -0700 Received: from sinica.edu (slip129-37-20-249.ga.us.ibm.net [129.37.20.249]) by telecom.sinica.edu.tw (8.8.5/8.8.5) with ESMTP id QAA13967; Mon, 28 Jun 1999 16:47:51 +0800 Message-ID: <377734C5.B4CC3BB2@sinica.edu> Date: Mon, 28 Jun 1999 16:39:33 +0800 From: Kenny Huang Organization: Academia Sinica X-Mailer: Mozilla 4.08 [en] (Win98; I) MIME-Version: 1.0 To: Markus Buchhorn CC: Jan-Ming Ho , rem-conf@es.net, jj@startap.net, Sheng-Hsiung Huang , chinfu@iis.sinica.edu.tw, Chia-Hui Wang , Lih-Hsiang Chen , feng@iis.sinica.edu.tw, jj@startap.net, "ªL®Ú½å" Subject: Re: request for Mbone feed References: <3.0.32.19990628160524.0099a8b0@acsys.anu.edu.au> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by telecom.sinica.edu.tw id QAA13967 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear ALL and JJ, I met JJ at the STARTAP Advisory Committee and briefed the mbone issue to him already. Ken Lin at NCHC (a00khl00@nchc.gov.tw) will be the primary contact in Taiwan. Please contact Ken Lin for=20 mbone implementation, and keep me in the communication loop. Regards --=20 Kenny Huang =B6=C0=B3=D3=B6=AF Tel 886-2-2789-9= 492 Head, Communication & Network Services Fax 886-2-2783-6444 Academia Sinica huangk@sinica.edu.tw http://www.sinica.edu.tw Markus Buchhorn wrote: >=20 > At 09:19 21/06/99 +0800, Jan-Ming Ho wrote: > > > >We are representing Taiwan to seek for Mbone feed to our Academic Netw= ork, > >Taiwan Academic Network, or TANET for short. We had long been sufferi= ng > >a low bandwidth connecting to international internet traffic. But, we > >recently upgrade our connection to the US by a T3 lease line. We > >appreciate it very much if we could have any institute here to provide > >us with permanent MBONE feed. We will run a permanent mbone root for > >the academic family including universities in Taiwan. We are also > >willing to transit this MBONE traffic to nearby countries based on the > >availability of physical connections and bandwidth. >=20 > Since Taiwan/TANet now has a direct connection to the STARTAP in Chicag= o > I'd suggest getting an MBONE feed from there - contact John Jamison > (jj@startap.net), who may or may not be the right person, (sorry John! = :-)) > but should be able to point you to the right person. APAN and SingaREN = also > get their MBONE feeds off the vBNS through STARTAP. >=20 > Cheers, > Markus >=20 > >Jan-Ming Ho, PhD > >Associate Editor, IEEE Transaction on Multimedia > >Research Fellow (O) 886-2-2788-3799 x1803 > >IIS, Academis Sinica (F) 886-2-2788-3799 x1606, 886-2-2782-= 4814 > >Nankang, Taipei email: hoho@iis.sinica.edu.tw > >Taiwan URL: http://www.iis.sinica.edu.tw/~h= oho > > http://www.iis.sinica.edu.tw/CC= L > > http://twstudy.sinica.edu.tw > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > =3D=3D=3D > > > > > > > > > > > Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62= 798810 > email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62= 798602 > Australian National University, Canberra 0200, Australia |Mobile: 0417 = 281429 From rem-conf Mon Jun 28 05:43:31 1999 From rem-conf-request@es.net Mon Jun 28 05:43:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yaaL-0003Su-00; Mon, 28 Jun 1999 05:32:29 -0700 Received: from smtp-out2.bellatlantic.net [199.45.39.157] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yaaK-0003Sk-00; Mon, 28 Jun 1999 05:32:28 -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 IAA10192; Mon, 28 Jun 1999 08:36:03 -0400 (EDT) Message-ID: <37776BA1.8018C832@cs.columbia.edu> Date: Mon, 28 Jun 1999 08:33:37 -0400 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: confctrl@isi.edu, rem-conf@es.net CC: Jeff Pulver Subject: Second SIP bake-off Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The second SIP bake-off will take place at pulver.com (Melville, NY, on Long Island near NYC) on August 5th and 6th. Details can be found at http://www.pulver.com/sip/ or through the SIP page at http://www.cs.columbia.edu/sip. The emphasis of this second bake-off is on more advanced SIP functionality, for example, proxying, security and CANCEL. We will also likely target basic RTP interoperability for testing at the event. Details on available hardware and software will be made available later, but you might want to send a note to Jeff Pulver if you anticipate needing more than just Ethernet jacks. Thanks to Jeff Pulver for hosting the event. Henning From rem-conf Mon Jun 28 06:19:13 1999 From rem-conf-request@es.net Mon Jun 28 06:19:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ybHC-0004QM-00; Mon, 28 Jun 1999 06:16:46 -0700 Received: from smtp-out1.bellatlantic.net [199.45.39.156] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ybHB-0004QC-00; Mon, 28 Jun 1999 06:16:45 -0700 Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id JAA18485 for ; Mon, 28 Jun 1999 09:15:40 -0400 (EDT) Message-ID: <377775FF.FD93B6A9@cs.columbia.edu> Date: Mon, 28 Jun 1999 09:17:51 -0400 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.5 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP CN payload type: 13 or 19; payload types actually in use Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Currently, the new profile draft has the comfort noise RTP payload type at 19. However, the VoIP Forum Interoperability agreement put it at 13, since the profile had listed it as unassigned. Previously, VSC (a proprietary Vocaltec codec) was at 13. Thus, the question: - Is anybody who *has* to use static payload types still using either 13 for VSC or 19 for CN? If there are no objections, we would move CN to 13, since a more widely published document has had it there for a while. This might also be a good opportunity to gather evidence as to which static payload types and, in general, RTP payload formats people actually use. This will be a necessary step as we move towards Draft Standard status for RTP and the profile. Thus, please send me this information. I will then include it on the RTP implementations page (unless it is secret for some reason). This provides another illustration why static payload types are a bad idea. End of soapbox. Thanks. Henning From rem-conf Tue Jun 29 04:35:29 1999 From rem-conf-request@es.net Tue Jun 29 04:35:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yvxM-0000Tc-00; Tue, 29 Jun 1999 04:21:40 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yvxL-0000TK-00; Tue, 29 Jun 1999 04:21:39 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08367; Tue, 29 Jun 1999 07:20:35 -0400 (EDT) Message-Id: <199906291120.HAA08367@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-dv-video-00.txt Date: Tue, 29 Jun 1999 07:20:35 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for DV Format Video Author(s) : K. Kobayashi, A. Ogawa, S. Casner, C. Borman Filename : draft-ietf-avt-dv-video-00.txt Pages : 13 Date : 28-Jun-99 This document specifies the packetization scheme for encapsulating the digital video data streams defined by the HD Digital VCR Conference, commonly known as 'DV', into a payload format for the Real-Time Transport Protocol (RTP). The RTP payload format specified in this document supports three quality levels of digital video identified as SD-VCR, HD-VCR and SDL-VCR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-video-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-dv-video-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-dv-video-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990628150708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dv-video-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dv-video-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990628150708.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jun 29 04:35:29 1999 From rem-conf-request@es.net Tue Jun 29 04:35:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yvvE-0000Ss-00; Tue, 29 Jun 1999 04:19:28 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yvvC-0000SO-00; Tue, 29 Jun 1999 04:19:26 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08320; Tue, 29 Jun 1999 07:18:22 -0400 (EDT) Message-Id: <199906291118.HAA08320@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtcptest-01.txt Date: Tue, 29 Jun 1999 07:18:22 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Conformance Tests for RTP Scalability Algorithms Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtcptest-01.txt Pages : 14 Date : 28-Jun-99 This document defines a set of tests that can be run on an RTP imple- mentation to determine the level of conformance with the various sca- lability algorithms defined in the draft version of RTP. These tests do not require access to internal implementations, and use black box testing techniques to determine compliance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcptest-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcptest-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcptest-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990628150629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcptest-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcptest-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990628150629.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jun 29 04:35:29 1999 From rem-conf-request@es.net Tue Jun 29 04:35:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yvvo-0000TA-00; Tue, 29 Jun 1999 04:20:04 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yvvn-0000Sa-00; Tue, 29 Jun 1999 04:20:03 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08333; Tue, 29 Jun 1999 07:19:00 -0400 (EDT) Message-Id: <199906291119.HAA08333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-interop-00.txt Date: Tue, 29 Jun 1999 07:18:59 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-rtp-interop-00.txt Pages : 5 Date : 28-Jun-99 It is required to demonstrate interoperability of RTP implementations in order to move the RTP specification to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-interop-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-interop-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-interop-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990628150653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-interop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-interop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990628150653.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jun 29 08:42:49 1999 From rem-conf-request@es.net Tue Jun 29 08:42:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10yzyJ-0005PZ-00; Tue, 29 Jun 1999 08:38:55 -0700 Received: from pimout1-ext.prodigy.net (pimout1-int.prodigy.net) [207.115.58.53] by mail1.es.net with esmtp (Exim 1.81 #2) id 10yzyI-0005PP-00; Tue, 29 Jun 1999 08:38:54 -0700 Received: from epgrace (PHLAB203-41.splitrock.net [209.156.76.144]) by pimout1-int.prodigy.net (8.8.5/8.8.5) with SMTP id LAA125210 for ; Tue, 29 Jun 1999 11:38:45 -0400 Message-Id: <3.0.6.32.19990629113644.007ae4e0@pop.prodigy.net> X-Sender: gracea@pop.prodigy.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 29 Jun 1999 11:36:44 -0400 To: rem-conf@es.net From: Andrew Grace Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ---- Andrew Grace gracea@prodigy.net From rem-conf Tue Jun 29 23:13:36 1999 From rem-conf-request@es.net Tue Jun 29 23:13:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zDZa-0004Su-00; Tue, 29 Jun 1999 23:10:18 -0700 Received: from (server1.car-pi.es) [195.76.38.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zDZY-0004Sk-00; Tue, 29 Jun 1999 23:10:17 -0700 Received: from ANGORU ([195.235.10.66]) by server1.car-pi.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NV5HKWNP; Wed, 30 Jun 1999 08:10:53 +0200 Message-ID: <04d401bec2f9$7a954240$420aebc3@angoru> From: "ANGORU" To: Subject: MARKETING Date: Wed, 30 Jun 1999 07:48:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C4_01BEC2CC.E7B70200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_02C4_01BEC2CC.E7B70200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DIRECCIONES INFORMATIZADAS PARA MARKETING FICHEROS INTERNACIONALES ACTUALIZADOS 98/99 SOLICITE PRUEBA GRATUITA 936365223- fax. 936646051 angoru@car-pi.es angoru@teleline.es www.car-pi.es/angoru/ ------=_NextPart_000_02C4_01BEC2CC.E7B70200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
DIRECCIONES INFORMATIZADAS = PARA=20 MARKETING
FICHEROS INTERNACIONALES ACTUALIZADOS=20 98/99
 
SOLICITE PRUEBA=20 GRATUITA
 
936365223- fax. = 936646051
angoru@car-pi.es
angoru@teleline.es
www.car-pi.es/angoru/
------=_NextPart_000_02C4_01BEC2CC.E7B70200-- From rem-conf Wed Jun 30 04:40:48 1999 From rem-conf-request@es.net Wed Jun 30 04:40:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zIar-0006sr-00; Wed, 30 Jun 1999 04:31:57 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zIaq-0006sI-00; Wed, 30 Jun 1999 04:31:56 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13198; Wed, 30 Jun 1999 07:30:52 -0400 (EDT) Message-Id: <199906301130.HAA13198@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtptest-00.txt Date: Wed, 30 Jun 1999 07:30:51 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Testing Strategies Author(s) : C. Perkins Filename : draft-ietf-avt-rtptest-00.txt Pages : 9 Date : 29-Jun-99 This memo describes a possible testing strategy for RTP implementations and is intended as an aid to implementors. It does not specify a standard of any kind. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtptest-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtptest-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtptest-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990629141710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtptest-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtptest-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629141710.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Jun 30 06:14:08 1999 From rem-conf-request@es.net Wed Jun 30 06:14:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zK8E-0000Gm-00; Wed, 30 Jun 1999 06:10:30 -0700 Received: from newmm.ccf.auth.gr [155.207.99.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zK8B-0000Gc-00; Wed, 30 Jun 1999 06:10:28 -0700 Received: from csd.auth.gr (pieria.csd.auth.gr [155.207.128.5]) by newmm.ccf.auth.gr (8.9.1a/8.9.1) with ESMTP id PAA24418; Wed, 30 Jun 1999 15:56:37 +0300 (EET DST) Message-ID: <377A15AF.242E8BC7@csd.auth.gr> Date: Wed, 30 Jun 1999 16:03:43 +0300 From: Helen Karatza Reply-To: karatza@csd.auth.gr Organization: Department of Informatics X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: osimcast , sc6wg4 , comswtc , multicomm , isadsoc , ieee_rtc_list , enternet , sigmedia , commsoft , modern-heuristics , vli , vss , wakamiya , wan , wei , wenpin , xuc , xue , yamah , yang , yhchoi , yhlee , ykim , yokotani , zhang , zhao , zheng , zit , znati , hzhang , ckobryn , bomsig , adtf , mof , tc , ptc , dtc , ab , mof-rtf , odp , dbworld , JavaCORBA , ISWORLD , comsoc-chapters , comsoc-gicb , "comsoc.tac" , ctc-members , end2end-interest , f-troup , fokus-user , g-troup , giga , hipparch , ieeetcpc , itc , rem-conf , "sb.all" , tccc , xtp-relay , dawit , tareen , boykin1 , tawfig , jadhai , masaru , tudball , ksj , cheming , sowmya , desai , karatza@csd.auth.gr Subject: 33rd Annual Simulation Symposium Content-Type: multipart/mixed; boundary="------------A8D62C01DB93C8DC44881D3B" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------A8D62C01DB93C8DC44881D3B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------A8D62C01DB93C8DC44881D3B Content-Type: text/plain; charset=us-ascii; name="simconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="simconf.txt" * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Call for Papers * * * * 33rd Annual Simulation Symposium * * Sheraton City Hotel * * Washington D.C. * * * * April 16-20, 2000 * * * * Sponsored by: * * * * The Society for Computer Simulation (SCS) * * * * In cooperation with: * * * * The IEEE Computer Society * * * * ACM (Association for Computing Machinery) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The Annual Simulation Symposium is a forum for the exchange of ideas, techniques, and applications among practitioners of simulation in industry, government, and academia. This international Symposium is the oldest continuously operating conference/symposium dedicated to simulation. The paper sessions are designed to promote discussion of concepts, methodology, and results between authors and the audience. The structure of the Symposium also provides for a degree of collegiality and continuity in the discussions of the various topics presented during the week. In recent years, the Symposium has provided a forum for traditional simulation topics in discrete-event, continuous, digital, and analog simulation. Along with the traditional subjects, this year's Symposium is seeking papers in the following topical areas: o Simulation of Multiprocessor Architectures o VLSI Circuit Simulators o Simulation Languages, Tools, and Environments o Object-Oriented Simulation o Simulation of Distributed Systems and Databases o Simulation of Parallel Processing Systems o Simulation based Performance Analysis o Animations/Virtual Reality o Advances in Simulation Methodology and Practices o Network Modeling and Simulation o Simulation of Multimedia Applications and Systems o Parallel and Distributed Simulation o Artificial Intelligence in Simulation o Neural Network Models and Simulation o Web-based Modeling and Simulation General Chair Program Committee Chair Prof. Taieb F. Znati Prof. Helen Karatza Computer Science Department Department of Informatics University of Pittsburgh Aristotle University of Thessaloniki Pittsburgh, PA 15260 54006 Thessaloniki, Greece Tel. : (412) 624-8417 Tel. : (31) 997974 Fax. : (412) 624-8854 Fax. : (31) 996360 Email: znati@cs.pitt.edu Email: karatza@csd.auth.gr PAPER SUBMISSION: Please send five (5) copies of a complete paper by September 24, 1999 to: Professor Helen Karatza Important Dates Department of Informatics Paper Submission Deadline : 9/24/99 Aristotle University of Thessaloniki Acceptance Notification : 11/15/99 54006 Thessaloniki, Greece Camera-Ready Paper : 1/8/2000 Papers can also be submitted electronically to karatza@csd.auth.gr or via anonymous ftp to ftp.auth.gr/incoming/ssymp33 by October 1st, 1999. Submitted files must be either in dvi or PostScript format with all figures and tables included, as created on Unix systems by: cat paper.ps | compress | uuencode paper.ps.Z > paper.uue or in most other environments by the `print to file' command with the PostScript output format option. All submissions will be fully refereed for accuracy, technical content, and relevance. Papers should be no longer than 20 double-spaced pages. Please include full name, affiliation, address, phone number, and email address of each author and designate the author who is to be contacted. Authors will receive the reviewers' comments and will be given a chance to respond to these reviews. Authors' replies will be taken into consideration in the final paper selection decision. Accepted papers will appear in the Symposium's Proceedings which will be published by the IEEE Computer Society. The Ira M. Kay Memorial Prize of $500 will be awarded to the best paper presented at the Symposium. Authors of top papers will also be encouraged to submit a follow-on paper for publication in the SCS Journals. Only papers which have not been previously published or presented should be submitted. Authors must obtain employer, client, or government releases prior to submitting the final manuscript. PROGRAM COMMITTEE Taieb Znati, General Chair, University of Pittsburg (znati@cs.pitt.edu) Helen Karatza, Program Chair, Aristotle University of Thessaloniki (karatza@csd.auth.gr) Dimetri Avresky, Boston University (avresky@bu.edu) Simonetta Balsamo, University of Udine (balsamo@dimi.uniud.it, balsamo@di.unipi.it) Sujata Banerjee, University of Pittsburgh (sujata@icarus.lis.pitt.edu) Felix Breitenecker, Technical University of Vienna (fbreiten@email.tuwien.ac.at) Wai Chen, Telcordia Technologies (wchen@research.telcordia.com) Patrick W. Dowd, University of Maryland at College Park (dowd@eng.umd.edu) Alois Ferscha, Institut Fuer Angewandte Informatik (ferscha@ani.univie.ac.at) Paul A. Fishwick, University of Florida (fishwick@cise.ufl.edu) Richard Fujimoto, Georgia Institute Of Technology (fujimoto@cc.gatech.edu) Michael Green, Univ. of California at Irvine (green@ece.uci.edu) Mohsen Guizani, University of West Florida (guizanim@umkc.edu) Omar Hammami, The University of Aizu, Japan (hammami@u-aizu.ac.jp) David Kaeli, Northeastern University (kaeli@ece.neu.edu) Enrqiue V. Kortright, Nicholls State University (ek@reality.nich.edu) Karen Panetta Lentz, Tufts University (karen@eecs.tufts.edu) Jason Yi-Bing Lin, Natl. Chiao Tung University, Taiwan, ROC (liny@csie.nctu.edu.tw) Wayne M. Loucks, University of Waterloo (Wayne.Loucks@uwaterloo.ca) Robert Macredie, Brunel University, UK (Robert.Macredie@brunel.ac.uk) John A. Miller, University of Georgia (jam@pollux.cs.uga.edu) Philippe Mussi, Inria Sophia Antipolis (mussi@sophia.inria.fr) Tuncer Oren, University of Ottawa and Tubitak-Marmara Research Center, Informatics Institute (oren@csi.uottawa.ca, tuncer@mam.gov.tr) Vernon Rego, Purdue University (rego@cs.purdue.edu) William H. Sanders, University of Illinois (whs@crhc.uiuc.edu) Robert Simon, George Mason University (simon@cs.gmu.edu) Gary S. H. Tan, National University of Singapore (gtan@comp.nus.edu.sg) TEO Yong Meng, National University of Singapore (teoym@comp.nus.edu.sg) Stephen J. Turner, University of Exeter (S.J.Turner@exeter.ac.uk) Philip A. Wilsey, University of Cincinnati (philip.wilsey@uc.edu) Shambhu J. Upadhyaya, State University of New York at Buffalo (shambhu@eng.buffalo.edu) Bernard Zeigler, University of Arizona (zeigler@ece.arizona.edu) George Zobrist, University of Misouri-Rolla (zobrist@umr.edu) FURTHER INFORMATION: For additional information, please contact or send mail to either Prof. Karatza (karatza@csd.auth.gr) or Prof. Taieb Znati (znati@cs.pitt.edu). Updated conference announcement and information are accessible at the symposium home page at http://www.csd.auth.gr/ssymp33. --------------A8D62C01DB93C8DC44881D3B-- From rem-conf Wed Jun 30 06:27:47 1999 From rem-conf-request@es.net Wed Jun 30 06:27:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zKNy-00014i-00; Wed, 30 Jun 1999 06:26:46 -0700 Received: from newmm.ccf.auth.gr [155.207.99.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zKNw-00014K-00; Wed, 30 Jun 1999 06:26:44 -0700 Received: from csd.auth.gr (pieria.csd.auth.gr [155.207.128.5]) by newmm.ccf.auth.gr (8.9.1a/8.9.1) with ESMTP id QAA26093; Wed, 30 Jun 1999 16:17:51 +0300 (EET DST) Message-ID: <377A1AA9.372D7538@csd.auth.gr> Date: Wed, 30 Jun 1999 16:24:58 +0300 From: Helen Karatza Reply-To: karatza@csd.auth.gr Organization: Department of Informatics X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: osimcast , sc6wg4 , comswtc , multicomm , isadsoc , ieee_rtc_list , enternet , sigmedia , commsoft , modern-heuristics , ckobryn , bomsig , adtf , mof , tc , ptc , dtc , ab , mof-rtf , odp , dbworld , JavaCORBA , ISWORLD , comsoc-chapters , comsoc-gicb , "comsoc.tac" , ctc-members , end2end-interest , f-troup , fokus-user , g-troup , giga , hipparch , ieeetcpc , itc , rem-conf , "sb.all" , tccc , xtp-relay , karatza@csd.auth.gr Subject: 33rd Annual Simulation Symposium Content-Type: multipart/mixed; boundary="------------4002EE02CFE5625AC5E6BBA7" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------4002EE02CFE5625AC5E6BBA7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------4002EE02CFE5625AC5E6BBA7 Content-Type: text/plain; charset=us-ascii; name="simconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="simconf.txt" * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Call for Papers * * * * 33rd Annual Simulation Symposium * * Sheraton City Hotel * * Washington D.C. * * * * April 16-20, 2000 * * * * Sponsored by: * * * * The Society for Computer Simulation (SCS) * * * * In cooperation with: * * * * The IEEE Computer Society * * * * ACM (Association for Computing Machinery) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The Annual Simulation Symposium is a forum for the exchange of ideas, techniques, and applications among practitioners of simulation in industry, government, and academia. This international Symposium is the oldest continuously operating conference/symposium dedicated to simulation. The paper sessions are designed to promote discussion of concepts, methodology, and results between authors and the audience. The structure of the Symposium also provides for a degree of collegiality and continuity in the discussions of the various topics presented during the week. In recent years, the Symposium has provided a forum for traditional simulation topics in discrete-event, continuous, digital, and analog simulation. Along with the traditional subjects, this year's Symposium is seeking papers in the following topical areas: o Simulation of Multiprocessor Architectures o VLSI Circuit Simulators o Simulation Languages, Tools, and Environments o Object-Oriented Simulation o Simulation of Distributed Systems and Databases o Simulation of Parallel Processing Systems o Simulation based Performance Analysis o Animations/Virtual Reality o Advances in Simulation Methodology and Practices o Network Modeling and Simulation o Simulation of Multimedia Applications and Systems o Parallel and Distributed Simulation o Artificial Intelligence in Simulation o Neural Network Models and Simulation o Web-based Modeling and Simulation General Chair Program Committee Chair Prof. Taieb F. Znati Prof. Helen Karatza Computer Science Department Department of Informatics University of Pittsburgh Aristotle University of Thessaloniki Pittsburgh, PA 15260 54006 Thessaloniki, Greece Tel. : (412) 624-8417 Tel. : (31) 997974 Fax. : (412) 624-8854 Fax. : (31) 996360 Email: znati@cs.pitt.edu Email: karatza@csd.auth.gr PAPER SUBMISSION: Please send five (5) copies of a complete paper by September 24, 1999 to: Professor Helen Karatza Important Dates Department of Informatics Paper Submission Deadline : 9/24/99 Aristotle University of Thessaloniki Acceptance Notification : 11/15/99 54006 Thessaloniki, Greece Camera-Ready Paper : 1/8/2000 Papers can also be submitted electronically to karatza@csd.auth.gr or via anonymous ftp to ftp.auth.gr/incoming/ssymp33 by October 1st, 1999. Submitted files must be either in dvi or PostScript format with all figures and tables included, as created on Unix systems by: cat paper.ps | compress | uuencode paper.ps.Z > paper.uue or in most other environments by the `print to file' command with the PostScript output format option. All submissions will be fully refereed for accuracy, technical content, and relevance. Papers should be no longer than 20 double-spaced pages. Please include full name, affiliation, address, phone number, and email address of each author and designate the author who is to be contacted. Authors will receive the reviewers' comments and will be given a chance to respond to these reviews. Authors' replies will be taken into consideration in the final paper selection decision. Accepted papers will appear in the Symposium's Proceedings which will be published by the IEEE Computer Society. The Ira M. Kay Memorial Prize of $500 will be awarded to the best paper presented at the Symposium. Authors of top papers will also be encouraged to submit a follow-on paper for publication in the SCS Journals. Only papers which have not been previously published or presented should be submitted. Authors must obtain employer, client, or government releases prior to submitting the final manuscript. PROGRAM COMMITTEE Taieb Znati, General Chair, University of Pittsburg (znati@cs.pitt.edu) Helen Karatza, Program Chair, Aristotle University of Thessaloniki (karatza@csd.auth.gr) Dimetri Avresky, Boston University (avresky@bu.edu) Simonetta Balsamo, University of Udine (balsamo@dimi.uniud.it, balsamo@di.unipi.it) Sujata Banerjee, University of Pittsburgh (sujata@icarus.lis.pitt.edu) Felix Breitenecker, Technical University of Vienna (fbreiten@email.tuwien.ac.at) Wai Chen, Telcordia Technologies (wchen@research.telcordia.com) Patrick W. Dowd, University of Maryland at College Park (dowd@eng.umd.edu) Alois Ferscha, Institut Fuer Angewandte Informatik (ferscha@ani.univie.ac.at) Paul A. Fishwick, University of Florida (fishwick@cise.ufl.edu) Richard Fujimoto, Georgia Institute Of Technology (fujimoto@cc.gatech.edu) Michael Green, Univ. of California at Irvine (green@ece.uci.edu) Mohsen Guizani, University of West Florida (guizanim@umkc.edu) Omar Hammami, The University of Aizu, Japan (hammami@u-aizu.ac.jp) David Kaeli, Northeastern University (kaeli@ece.neu.edu) Enrqiue V. Kortright, Nicholls State University (ek@reality.nich.edu) Karen Panetta Lentz, Tufts University (karen@eecs.tufts.edu) Jason Yi-Bing Lin, Natl. Chiao Tung University, Taiwan, ROC (liny@csie.nctu.edu.tw) Wayne M. Loucks, University of Waterloo (Wayne.Loucks@uwaterloo.ca) Robert Macredie, Brunel University, UK (Robert.Macredie@brunel.ac.uk) John A. Miller, University of Georgia (jam@pollux.cs.uga.edu) Philippe Mussi, Inria Sophia Antipolis (mussi@sophia.inria.fr) Tuncer Oren, University of Ottawa and Tubitak-Marmara Research Center, Informatics Institute (oren@csi.uottawa.ca, tuncer@mam.gov.tr) Vernon Rego, Purdue University (rego@cs.purdue.edu) William H. Sanders, University of Illinois (whs@crhc.uiuc.edu) Robert Simon, George Mason University (simon@cs.gmu.edu) Gary S. H. Tan, National University of Singapore (gtan@comp.nus.edu.sg) TEO Yong Meng, National University of Singapore (teoym@comp.nus.edu.sg) Stephen J. Turner, University of Exeter (S.J.Turner@exeter.ac.uk) Philip A. Wilsey, University of Cincinnati (philip.wilsey@uc.edu) Shambhu J. Upadhyaya, State University of New York at Buffalo (shambhu@eng.buffalo.edu) Bernard Zeigler, University of Arizona (zeigler@ece.arizona.edu) George Zobrist, University of Misouri-Rolla (zobrist@umr.edu) FURTHER INFORMATION: For additional information, please contact or send mail to either Prof. Karatza (karatza@csd.auth.gr) or Prof. Taieb Znati (znati@cs.pitt.edu). Updated conference announcement and information are accessible at the symposium home page at http://www.csd.auth.gr/ssymp33. --------------4002EE02CFE5625AC5E6BBA7-- From rem-conf Wed Jun 30 06:35:42 1999 From rem-conf-request@es.net Wed Jun 30 06:35:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zKWP-0001ia-00; Wed, 30 Jun 1999 06:35:29 -0700 Received: from newmm.ccf.auth.gr [155.207.99.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zKWN-0001iL-00; Wed, 30 Jun 1999 06:35:28 -0700 Received: from csd.auth.gr (pieria.csd.auth.gr [155.207.128.5]) by newmm.ccf.auth.gr (8.9.1a/8.9.1) with ESMTP id QAA26950; Wed, 30 Jun 1999 16:29:31 +0300 (EET DST) Message-ID: <377A1D66.29D7F0@csd.auth.gr> Date: Wed, 30 Jun 1999 16:36:38 +0300 From: Helen Karatza Reply-To: karatza@csd.auth.gr Organization: Department of Informatics X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: karatza , osimcast , sc6wg4 , comswtc , multicomm , isadsoc , ieee_rtc_list , enternet , sigmedia , commsoft , modern-heuristics , ckobryn , bomsig , adtf , mof , tc , ptc , dtc , ab , mof-rtf , odp , dbworld , JavaCORBA , ISWORLD , comsoc-chapters , comsoc-gicb , "comsoc.tac" , ctc-members , end2end-interest , f-troup , fokus-user , g-troup , giga , hipparch , ieeetcpc , itc , rem-conf , "sb.all" , tccc , xtp-relay , karatza@csd.auth.gr Subject: 33rd Annual Simulation Symposium Content-Type: multipart/mixed; boundary="------------70CDAE2AF9F503EFE45FA229" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------70CDAE2AF9F503EFE45FA229 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------70CDAE2AF9F503EFE45FA229 Content-Type: text/plain; charset=us-ascii; name="simconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="simconf.txt" * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Call for Papers * * * * 33rd Annual Simulation Symposium * * Sheraton City Hotel * * Washington D.C. * * * * April 16-20, 2000 * * * * Sponsored by: * * * * The Society for Computer Simulation (SCS) * * * * In cooperation with: * * * * The IEEE Computer Society * * * * ACM (Association for Computing Machinery) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The Annual Simulation Symposium is a forum for the exchange of ideas, techniques, and applications among practitioners of simulation in industry, government, and academia. This international Symposium is the oldest continuously operating conference/symposium dedicated to simulation. The paper sessions are designed to promote discussion of concepts, methodology, and results between authors and the audience. The structure of the Symposium also provides for a degree of collegiality and continuity in the discussions of the various topics presented during the week. In recent years, the Symposium has provided a forum for traditional simulation topics in discrete-event, continuous, digital, and analog simulation. Along with the traditional subjects, this year's Symposium is seeking papers in the following topical areas: o Simulation of Multiprocessor Architectures o VLSI Circuit Simulators o Simulation Languages, Tools, and Environments o Object-Oriented Simulation o Simulation of Distributed Systems and Databases o Simulation of Parallel Processing Systems o Simulation based Performance Analysis o Animations/Virtual Reality o Advances in Simulation Methodology and Practices o Network Modeling and Simulation o Simulation of Multimedia Applications and Systems o Parallel and Distributed Simulation o Artificial Intelligence in Simulation o Neural Network Models and Simulation o Web-based Modeling and Simulation General Chair Program Committee Chair Prof. Taieb F. Znati Prof. Helen Karatza Computer Science Department Department of Informatics University of Pittsburgh Aristotle University of Thessaloniki Pittsburgh, PA 15260 54006 Thessaloniki, Greece Tel. : (412) 624-8417 Tel. : (31) 997974 Fax. : (412) 624-8854 Fax. : (31) 996360 Email: znati@cs.pitt.edu Email: karatza@csd.auth.gr PAPER SUBMISSION: Please send five (5) copies of a complete paper by September 24, 1999 to: Professor Helen Karatza Important Dates Department of Informatics Paper Submission Deadline : 9/24/99 Aristotle University of Thessaloniki Acceptance Notification : 11/15/99 54006 Thessaloniki, Greece Camera-Ready Paper : 1/8/2000 Papers can also be submitted electronically to karatza@csd.auth.gr or via anonymous ftp to ftp.auth.gr/incoming/ssymp33 by October 1st, 1999. Submitted files must be either in dvi or PostScript format with all figures and tables included, as created on Unix systems by: cat paper.ps | compress | uuencode paper.ps.Z > paper.uue or in most other environments by the `print to file' command with the PostScript output format option. All submissions will be fully refereed for accuracy, technical content, and relevance. Papers should be no longer than 20 double-spaced pages. Please include full name, affiliation, address, phone number, and email address of each author and designate the author who is to be contacted. Authors will receive the reviewers' comments and will be given a chance to respond to these reviews. Authors' replies will be taken into consideration in the final paper selection decision. Accepted papers will appear in the Symposium's Proceedings which will be published by the IEEE Computer Society. The Ira M. Kay Memorial Prize of $500 will be awarded to the best paper presented at the Symposium. Authors of top papers will also be encouraged to submit a follow-on paper for publication in the SCS Journals. Only papers which have not been previously published or presented should be submitted. Authors must obtain employer, client, or government releases prior to submitting the final manuscript. PROGRAM COMMITTEE Taieb Znati, General Chair, University of Pittsburg (znati@cs.pitt.edu) Helen Karatza, Program Chair, Aristotle University of Thessaloniki (karatza@csd.auth.gr) Dimetri Avresky, Boston University (avresky@bu.edu) Simonetta Balsamo, University of Udine (balsamo@dimi.uniud.it, balsamo@di.unipi.it) Sujata Banerjee, University of Pittsburgh (sujata@icarus.lis.pitt.edu) Felix Breitenecker, Technical University of Vienna (fbreiten@email.tuwien.ac.at) Wai Chen, Telcordia Technologies (wchen@research.telcordia.com) Patrick W. Dowd, University of Maryland at College Park (dowd@eng.umd.edu) Alois Ferscha, Institut Fuer Angewandte Informatik (ferscha@ani.univie.ac.at) Paul A. Fishwick, University of Florida (fishwick@cise.ufl.edu) Richard Fujimoto, Georgia Institute Of Technology (fujimoto@cc.gatech.edu) Michael Green, Univ. of California at Irvine (green@ece.uci.edu) Mohsen Guizani, University of West Florida (guizanim@umkc.edu) Omar Hammami, The University of Aizu, Japan (hammami@u-aizu.ac.jp) David Kaeli, Northeastern University (kaeli@ece.neu.edu) Enrqiue V. Kortright, Nicholls State University (ek@reality.nich.edu) Karen Panetta Lentz, Tufts University (karen@eecs.tufts.edu) Jason Yi-Bing Lin, Natl. Chiao Tung University, Taiwan, ROC (liny@csie.nctu.edu.tw) Wayne M. Loucks, University of Waterloo (Wayne.Loucks@uwaterloo.ca) Robert Macredie, Brunel University, UK (Robert.Macredie@brunel.ac.uk) John A. Miller, University of Georgia (jam@pollux.cs.uga.edu) Philippe Mussi, Inria Sophia Antipolis (mussi@sophia.inria.fr) Tuncer Oren, University of Ottawa and Tubitak-Marmara Research Center, Informatics Institute (oren@csi.uottawa.ca, tuncer@mam.gov.tr) Vernon Rego, Purdue University (rego@cs.purdue.edu) William H. Sanders, University of Illinois (whs@crhc.uiuc.edu) Robert Simon, George Mason University (simon@cs.gmu.edu) Gary S. H. Tan, National University of Singapore (gtan@comp.nus.edu.sg) TEO Yong Meng, National University of Singapore (teoym@comp.nus.edu.sg) Stephen J. Turner, University of Exeter (S.J.Turner@exeter.ac.uk) Philip A. Wilsey, University of Cincinnati (philip.wilsey@uc.edu) Shambhu J. Upadhyaya, State University of New York at Buffalo (shambhu@eng.buffalo.edu) Bernard Zeigler, University of Arizona (zeigler@ece.arizona.edu) George Zobrist, University of Misouri-Rolla (zobrist@umr.edu) FURTHER INFORMATION: For additional information, please contact or send mail to either Prof. Karatza (karatza@csd.auth.gr) or Prof. Taieb Znati (znati@cs.pitt.edu). Updated conference announcement and information are accessible at the symposium home page at http://www.csd.auth.gr/ssymp33. --------------70CDAE2AF9F503EFE45FA229-- From rem-conf Wed Jun 30 10:17:55 1999 From rem-conf-request@es.net Wed Jun 30 10:17:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zNty-0004LX-00; Wed, 30 Jun 1999 10:12:02 -0700 Received: from mumrik.nada.kth.se [130.237.226.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zNtw-0004LL-00; Wed, 30 Jun 1999 10:12:00 -0700 Received: from localhost (nv91-tob@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with ESMTP id TAA23491 for ; Wed, 30 Jun 1999 19:11:57 +0200 (MET DST) Date: Wed, 30 Jun 1999 19:11:57 +0200 (MET DST) From: =?ISO-8859-1?Q?Tobias_=D6brink?= To: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-dv-video-00.txt In-Reply-To: <199906291120.HAA08367@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mumrik.nada.kth.se id TAA23491 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I read through draft-ietf-avt-dv-video-00.txt and have some comments and questions that might be worthwhile discussing. In section 4.1 RTP header usage: Timestamp: 32-bit 90 kHz timestamp representing the time at which the first data in the frame was sampled. =20 This statement may lead to the conclusion that the sampling time for the first frame (maybe obtained from the CIP header as described in appendix A) should be used as the initial value of the timestamp field. To avoid unneccessary confusion I would like to add the following paragraph from the new RTP draft: The initial value of the timestamp SHOULD be random, as for the sequence number. In section 4.2 DV data encapsulation into RTP payload: Therefore, if VAUX/AAUX information is not transmitted in the stream, the equivalent parameters essential to playout MUST be provided by some out of band means beyond the scope of this document. : : : Therefore, if the RTP receiver is feeding the DV stream to a device that requires AAUX information and VAUX DIF blocks, the receiver MUST be able to generate AAUX within audio DIF blocks and VAUX DIF blocks for the device using the parameters provided out of band. I interpret this as, to comply with the spec, the receiver implementation MUST retrieve, by some unknown out-of-band-mechanism, the information needed to recreate the VAUX and AAUX DIF blocks.=20 If that's the case won't we end up with non-interoperable implementations using proprietary out-of-band-mechanisms?=20 Maybe we should at least state a default out-of-band-mechanism as a minimal requirement that have to be used by all implementations. The dynamic payload type assignment using SDP in section 5 comes to mind. In section 5.2 SDP description for bundled stream:=20 The audio format parameter seems quite detailed. How to find out the=20 values for those parameters if you're about to announce a session in sdr or writing a SDP-file for a program that haven't yet started? Aren't there any standardized combinations of those parameters?=20 At least , and the number of channels=20 only can occur in a few different combinations. Maybe the same applies to some of the other parameters as well? /Tobias .........................................................................= ... Tobias =D6brink Grad. Stud. Dept. of Teleinformatics, KTH Phone numbers: Paper mail address: +46 8 752 14 75 (IT, work) KTH-ELECTRUM/204 +46 8 751 17 93 (Fax) S-164 40 Kista Sweden E-mail: tobias@it.kth.se URL: http://www.it.kth.se/~nv91-tob/