From rem-conf Thu May 01 14:33:51 1997 
From rem-conf-request@tmpmail.es.net Thu May 01 14:33:51 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wN3LL-00031D-00; Thu, 1 May 1997 14:24:47 -0700
Date: Thu, 1 May 1997 15:24:42 -0600 (MDT)
From: Evi Nemeth <evi@rupertsberg.cs.colorado.edu>
Message-Id: <199705012124.PAA03007@rupertsberg.cs.colorado.edu>
To: rem-conf@es.net
Subject: mbone: CS Colloquium, May 8, U.Colorado, Mike Schwartz @Home
Cc: evi@rupertsberg.cs.colorado.edu
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

University of Colorado, Computer Science Colloquium
May 8, 1997, 3:15 - 4:15 pm

Scalable Internet Service: The @Home Network Architecture
	Michael F. Schwartz, @Home Network

@Home Network delivers high-speed information services to homes and
businesses using the cable television infrastructure.  Service is delivered
over the "last mile" using coaxial links and cable modems, plus SONET
(fiber optic) regional links.  At the wide area @Home is a tier one
Internet service provider, peering at the major Internet Network Access
Points.  For scalability, the network architecture includes widely
distributed caching and replication, as well as the ability to support
multicast, differentiated levels of service quality, and a 7x24 network
operations center with visibility into the entire distributed
infrastructure.  @Home also acts as a content aggregator, working with
content providers to replicate content onto @Home servers.

In this talk I will discuss @Home's vision, network architecture, and
service design principles.




From rem-conf Thu May 01 15:44:11 1997 
From rem-conf-request@tmpmail.es.net Thu May 01 15:44:11 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wN4Y2-0003PU-00; Thu, 1 May 1997 15:41:58 -0700
Date: Thu, 1 May 1997 15:41:52 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Message-Id: <199705012241.PAA06345@ruby.cisco.com>
To: rem-conf@es.net
Subject: Question on vat
X-Sun-Charset: US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I am trying to run vat on Solaris x86. The sound card driver (sbpro) complains 
that vat is trying to open the device for PLAY and RECORD. The man page on
sbpro says that the device can support only one stream at any time. I really
need vat to play the audio stream and do not need the recording capability.

Is there any way to tell vat not to open the card for record mode?

Mahesh Jethanandani

|\/\/\/|                              |      mahesh@cisco.com
|  \  /|   LIFE'S COMPLEX - IT HAS    |      Cisco Systems Inc.
| (o)(o)   REAL & IMAGINARY PARTS     |      170 West Tasman Drive
C      _)                             |      San Jose, CA 95134
| \___|                               |	     (408) 527-8230
 |   /   All Std. Disclaimers apply.  |      (408) 527-8254(fax)




From rem-conf Thu May 01 19:48:26 1997 
From rem-conf-request@tmpmail.es.net Thu May 01 19:48:25 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wN8Ih-0004DC-00; Thu, 1 May 1997 19:42:23 -0700
Date: Thu, 1 May 1997 19:25:51 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
cc: rem-conf@es.net
Subject: Re: Reconsideration and the plateau effect
In-Reply-To: <970425102238.ZM10854@arrakis>
Message-ID: <Pine.WNT.3.95.970501192519.-140931T-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Jonathan,

Sorry for the delayed response.

> The plateau effect is purely an artifact of the step join abstraction.
> As the join process becomes more sloped, or even jagged, both the height
> of the initial spike and the duration of this plateau (they are linearly
> related) disappear.

I agree that the perfect step-join abstraction is unrealistic.  I wish
I could predict the future well enough to know how close the realistic
scenarios may be.

> (See our Columbia University Technical
> Report, "Scaling Feedback to Very Large Groups"; an I-D is coming soon
> with the same content).

I look forward to seeing that report or I-D.  Your presentation in
Memphis was very well done, but this is complicated enough that one
needs to be able to read and think.

> There is also the practical issue of time; given the speed with which we
> want to move to draft standard, the time required to develop, simulate,
> implement, and test new algorithms doesn't fit into the schedule.

While I agree that we'd like to move quickly, one possible reading of
this paragraph is that "we don't have time to get it right".  I don't
think you meant that, and I'm not saying what you've proposed is
wrong, but I do think we need to make sure that the algorithm we put
in the spec is as much right as we know how to do.

> So, given that we feel the plateau effect is not likely to show up in
> real systems, and that other algorithms which do not exhibit it are more
> complex and potentially antisocial, and our time constraints, we feel
> that unconditional reconsideration remains the best solution.

I wonder what antisocial means here.

I think there are still some details of the algorithm that may need
refinement.  Using unconditional reconsideration affects the
steady-state percentage; should we increase the percentage to
compensate?  If we did, what effect would that have on the
convergence?

The algorithm also needs to be specified to the level of detail as the
current algorithm, i.e., including a reference implementation in the
appendix.
							-- Steve




From rem-conf Thu May 01 20:13:29 1997 
From rem-conf-request@tmpmail.es.net Thu May 01 20:13:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wN8ll-0004Wn-00; Thu, 1 May 1997 20:12:25 -0700
Date: Thu, 1 May 1997 19:46:14 -0700 ()
From: Stephen Casner <casner@precept.com>
To: rem-conf@es.net
Subject: Please review draft-ietf-avt-mpeg-new-00.txt
In-Reply-To: <9704301019.aa11809@ietf.org>
Message-ID: <Pine.WNT.3.95.970501192943.-140931U-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

To the AVT working group:

At the San Jose and Memphis IETFs, Reha Civanlar gave presentations
identifying the need to extend the RTP MPEG payload format to allow
the packet loss resilience mechanisms to work for MPEG2 in addition to
MPEG1.  The proposed changes have now been posted as an Internet-Draft
updating the RFC:

       Title     : RTP Payload Format for MPEG1/MPEG2 Video                
       Author(s) : D. Hoffman, G. Fernando, V. Goyal, R. Civanlar
       Filename  : draft-ietf-avt-mpeg-new-00.txt
       Pages     : 15
       Date      : 04/29/1997

The changed sections are 3.4 (including 3.4.1) and Appendix 1.  Please
review these changes.  If there are no comments in two weeks, then I
will request IESG Last Call for re-publication as a new RFC, still at
Proposed Standard status.
							-- Steve




From rem-conf Fri May 02 11:23:40 1997 
From rem-conf-request@tmpmail.es.net Fri May 02 11:23:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wNMsY-0006e4-00; Fri, 2 May 1997 11:16:22 -0700
Date: Fri, 2 May 1997 11:16:19 -0700
Message-Id: <199705021816.LAA07254@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

                Berkeley Multimedia and Graphics Seminar 
          (Wednesday May 7, 1997 12:30-2:00 PDT 405 Soda Hall) 

        "Toward a Common Infrastructure for Digital Media Middleware"

                                Steve McCanne 
                                U.C. Berkeley 

Although real-time multimedia streams like audio and video are now integral
data types in modern programming environments, no commonly accepted
programming model for "multimedia networking" exists within the research
community. We believe this lack of common practice impedes our collective
progress because it prevents disparate research groups from easily
leveraging each other's work. In this talk, I will propose a solution to
this problem that combines the best features of a number of existing
toolkits --- Berkeley's Continuous Media Toolkit (CMT), MIT's VuSystem, and
the LBL/UCB Bone tools --- into a fine-grained, extensible, and
high-performance toolkit. I'll describe the convergence of these three
toolkits into a common programming infrastructure, and if time permits,
outline a number of ongoing research projects that leverage our new toolkit.
--------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu




From rem-conf Sat May 03 13:42:22 1997 
From rem-conf-request@tmpmail.es.net Sat May 03 13:42:21 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wNlRG-0002ir-00; Sat, 3 May 1997 13:29:50 -0700
From: Sassan Pejhan <sassan@Sarnoff.COM>
Date: Sat, 3 May 1997 16:26:28 -0400
Message-Id: <199705032026.QAA13130@section05>
To: rem-conf@es.net
Subject: Audio/Video sequences?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: oTDUA9lB/AC8NpGJfK2U8g==
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Are there any sites where I could download Video *and* corresponding audio
sequences (preferrably CIF/QCIF formats for the video)?

Thanks in advance,
Sassan



From rem-conf Sun May 04 13:14:39 1997 
From rem-conf-request@tmpmail.es.net Sun May 04 13:14:37 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wO7Y8-0006Gk-00; Sun, 4 May 1997 13:06:24 -0700
Date: Sun, 4 May 1997 13:22:42 -0400 (EDT)
From: kevin@cc.gatech.edu (Kevin C. Almeroth)
Message-Id: <199705041722.NAA11593@flora.cc.gatech.edu>
To: rem-conf@es.net
Subject: N+I Broadcast Schedule...
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


The schedule for the broadcast of events from the 1997 Las Vegas
Networld+Interop Show has been mostly finalized.  Basically we will
be broadcasting a few things on Monday, May 5th and then most of the
day on Tuesday, May 6th through Thursday, May 7th.  See
http://www.cc.gatech.edu/computing/Telecomm/interop/ for the specific
schedule and pointers to abstracts and session information.

Additional sessions may be added (like the MBone BOF) depending on
resource availability.  Check the schedule page for the latest changes.

Below is the latest and greatest.

-Kevin Almeroth



1997 Las Vegas Networld+Interop Broadcast Schedule

----------------------------------------------------------------------------

Monday, May 5, 1997

Kim Polese, CEO, Marimba

   * Time: 16:00 GMT, 09:00 PDT, 12:00 EDT (Duration: 1:00)

David House, Chairman, President, and CEO, Bay Networks Inc.

   * Time: 00:45 GMT, 17:45 PDT, 20:45 EDT (Duration: 1:00)

----------------------------------------------------------------------------

Tuesday, May 6, 1997

Tom Lyons, CTO and Founder, Ipsilon Networks Inc.

   * Time: 16:00 GMT, 09:00 PDT, 12:00 EDT (Duration: 1:00)

Wireless & Wireline -- Broadband Wireless MAN Emerging Technologies

   * Time: 17:15 GMT, 10:15 PDT, 13:15 EDT (Duration: 1:30)

Wireless & Wireline -- My First Cable Modem

   * Time: 21:00 GMT, 14:00 PDT, 17:00 EDT (Duration: 1:30)

----------------------------------------------------------------------------

Wednesday, May 7, 1997

Engineer Conference -- Traffic Performance and Engineering of IP Networks

   * Time: 17:00 GMT, 10:00 PDT, 13:00 EDT (Duration: 2:00)

Engineer Conference -- Evolution of Broadband Access Technologies and
Systems (Part I)

   * Time: 20:30 GMT, 13:30 PDT, 16:30 EDT (Duration: 2:00)

Engineer Conference -- Evolution of Broadband Access Technologies and
Systems (Part II)

   * Time: 23:00 GMT, 16:00 PDT, 19:00 EDT (Duration: 2:00)

----------------------------------------------------------------------------

Thursday, May 8, 1997

Eric Schmidt, Chairman and CEO, Novell Inc.

   * Time: 16:00 GMT, 09:00 PDT, 12:00 EDT (Duration: 1:00)

Engineer Conference -- Advances in Wireless and Satellite Acess Technologies

   * Time: 17:00 GMT, 10:00 PDT, 13:00 EDT (Duration: 2:00)

Engineer Conference -- Advanced IP Networks

   * Time: 20:30 GMT, 13:30 PDT, 16:30 EDT (Duration: 2:00)

Engineer Conference -- Video Over Enterprise Networks

   * Time: 23:00 GMT, 16:00 PDT, 19:00 EDT (Duration: 2:00)

----------------------------------------------------------------------------




From rem-conf Mon May 05 14:54:12 1997 
From rem-conf-request@tmpmail.es.net Mon May 05 14:54:11 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wOVIO-0003oG-00; Mon, 5 May 1997 14:27:44 -0700
From: Deb Agarwal <deba@george.lbl.gov>
Message-Id: <199705052127.OAA12755@george.lbl.gov>
Subject: A new videoconference control tool
To: rem-conf@es.net
Date: Mon, 5 May 1997 14:27:39 -0700 (PDT)
Cc: mperry@george.lbl.gov (Marcia Perry)
Reply-To: DAAgarwal@lbl.gov
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1170
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi everyone,

We in the Imaging and Distributed Computing Group of Lawrence Berkeley 
National Lab, as part of the Spectro-Microscopy Collaboratory project
(LabWeb), have developed confcntlr.   Confcntlr is a new mbone tool
that allows easier access to and remote control of the video and
audio portions of a videoconference.  It is meant to be run with
vic and vat.  

We've been using confcntlr within the LabWeb project and have found it
useful for its graphic user interface and communication system that
allows users to easily set parameters for the video and audio, start/stop
local and remote video and audio sessions, and change settings while a
session is running.  Confcntlr eliminates the need to "babysit" the
computer at a site that is conducting an experiment and transmitting its
video and audio over the network.   

If you're interested in trying this tool, the beta version (v.3) is
available from our web site:  
	http://www-itg.lbl.gov/mbone/confcntlr

Thanks,
Deb Agarwal (DAAgarwal@lbl.gov)
Marcia Perry  (mperry@george.lbl.gov)
MS50B-2239                                   phone :(510)486-7078
Lawrence Berkeley National Lab  
Berkeley, CA 94720




From rem-conf Mon May 05 16:07:39 1997 
From rem-conf-request@tmpmail.es.net Mon May 05 16:07:39 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wOWpb-0004Rz-00; Mon, 5 May 1997 16:06:07 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Mon, 5 May 1997 16:03:28 -0700 (PDT)
Message-Id: <199705052303.QAA15814@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Outside In
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	Outside In
Date:        
	May 06, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org

Description:        
	                                           The award-winning computer animation                                             Outside In explains the amazing                                             discovery, made by Steve Smale in                                             1957, that a sphere can be turned inside                                             out by means of smooth motions and                                             self intersections, without cutting or                                             tearing. It convincingly demonstrates                                             how valuable visualization can be in the                                             communication of mathematics.                                              info: m1@msri.org 









mbone broadcast schedule http://www.msri.org/mbone



From rem-conf Mon May 05 16:07:41 1997 
From rem-conf-request@tmpmail.es.net Mon May 05 16:07:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wOWqg-0004SG-00; Mon, 5 May 1997 16:07:14 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Mon, 5 May 1997 16:06:47 -0700 (PDT)
Message-Id: <199705052306.QAA15848@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Not Knot
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	Not Knot
Date:        
	May 07, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org

Description:        
	                                           Not Knot is a guided tour into                                             computer-animated hyperbolic space. It                                             proceeds from the world of knots to                                             their complementary spaces -- what's                                             not a knot. Profound theorems of recent                                             mathematics show that most known                                             complements carry the structure of                                             hyperbolic geometry, a geometry in                                             which the sum of three angles of a                                             triangle always is less than 180 degrees.                                               info: m1@msri.org  









mbone broadcast schedule http://www.msri.org/mbone



From rem-conf Tue May 06 09:43:02 1997 
From rem-conf-request@tmpmail.es.net Tue May 06 09:43:01 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wOnBx-0000ou-00; Tue, 6 May 1997 09:34:17 -0700
From: Scott_Petrack@vocaltec.com
X-Lotus-FromDomain: VOCALTEC
To: rem-conf@es.net
cc: Gur@vocaltec.com
Message-ID: <4225648F.005F146C.00@maskit1.vocaltec.co.il>
Date: Tue, 6 May 1997 19:30:48 +0200
Subject: RTP payload format defined for GSM
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list






Scott Petrack
05/06/97 07:30 PM

Is there a definition of the RTP payload format for GSM? What is its status
right now?
Does it have VAD defined?

Thanks,

Scott Petrack





From rem-conf Tue May 06 10:54:42 1997 
From rem-conf-request@tmpmail.es.net Tue May 06 10:54:42 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wOoLz-0001JT-00; Tue, 6 May 1997 10:48:43 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <336F6EAF.7D29@cs.columbia.edu>
Date: Tue, 06 May 1997 13:47:27 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott_Petrack@vocaltec.com
CC: rem-conf@es.net, Gur@vocaltec.com
Subject: Re: RTP payload format defined for GSM
References: <4225648F.005F146C.00@maskit1.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Scott_Petrack@vocaltec.com wrote:
> 
> Scott Petrack
> 05/06/97 07:30 PM
> 
> Is there a definition of the RTP payload format for GSM? What is its status
> right now?

Been in RFC 1890, is in the current draft (with some clarifications, but
no changes), no technical changes suggested so far.

> Does it have VAD defined?

Not as far as I know, although I seem to recall that the "real" GSM for
mobile phones does use VAD.

> 
> Thanks,
> 
> Scott Petrack

-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs



From rem-conf Tue May 06 13:02:52 1997 
From rem-conf-request@tmpmail.es.net Tue May 06 13:02:51 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wOqN7-00023n-00; Tue, 6 May 1997 12:58:01 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Scott_Petrack@vocaltec.com, rem-conf@es.net, Gur@vocaltec.com
Subject: Re: RTP payload format defined for GSM
In-reply-to: Your message of "Tue, 06 May 1997 13:47:27 EDT." <336F6EAF.7D29@cs.columbia.edu>
Date: Tue, 06 May 1997 20:55:12 +0100
Message-ID: <4847.862948512@cs.ucl.ac.uk>
From: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

In message <336F6EAF.7D29@cs.columbia.edu>, Henning Schulzrinne writes:
> Scott_Petrack@vocaltec.com wrote:
> > 
> > Scott Petrack
> > 05/06/97 07:30 PM
> > 
> > Is there a definition of the RTP payload format for GSM? What is its status
> > right now?
> 
> Been in RFC 1890, is in the current draft (with some clarifications, but
> no changes), no technical changes suggested so far.
> 
> > Does it have VAD defined?
> 

GSM VAD is specified in GSM 06.32 (available from ETSI).  It is an
energy thresholding algorithm with some (expensive) filtering to avoid
noise being classified as speech.  Unless you're audio tool is
designed for mobile environments it is overkill.  Energy thresholding
with some simple rules based on Brady's papers will do very nicely.

I'm not sure it makes sense to specify it in the AVT profile as it
applies to the receiver only.

Orion
---
Orion Hodson
Computer Science, University College London, 
Gower Street, London, WC1E 6BT, UK.






From rem-conf Wed May 07 01:37:41 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 01:37:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wP1x0-0004Tw-00; Wed, 7 May 1997 01:19:50 -0700
From: Scott_Petrack@vocaltec.com
X-Lotus-FromDomain: VOCALTEC
To: O.Hodson@cs.ucl.ac.uk
cc: schulzrinne@cs.columbia.edu, rem-conf@es.net, Gur_Kimchi@vocaltec.com
Message-ID: <C2256490.0029F4D4.00@maskit1.vocaltec.co.il>
Date: Wed, 7 May 1997 11:16:02 +0200
Subject: Re: RTP payload format defined for GSM
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list






Scott Petrack
05/07/97 11:16 AM

The VAD of GSM applies to the sender, I believe. You describe it yourself.
For each GSM frame produced at the sender, the sender can decide:

a .to send the frame,
b. to send a "silence desciption frame" (SID) instead, which contains
parameters used to update the noise generation in the receiver
c. not to send anything at all

Of course you're right that you can tell if it's an SID frame by looking at
the bits (the excitation is 0 and you put in some random noise). But one
could imagine tagging the SIDs.

Also, do the MBONE tools ever send several GSM frames in a single RTP
packet? (In which case I suppose that one assumes that the frames are
consecutive in time, and the timestamp refers to the start of the group of
frames)

If MBONE tools send each GSM frame in a separate packet, then it must be
hard to fit a GSM stream even on 28.8 dialup link if there is no silence
(as usually happens in Israeli conversations ;-)).

Thanks,
Scott


-------- On 05/06/97 08:55 PM CET  O.Hodson @ cs.ucl.ac.uk  wrote:



In message <336F6EAF.7D29@cs.columbia.edu>, Henning Schulzrinne writes:
> Scott_Petrack@vocaltec.com wrote:
> >
> > Scott Petrack
> > 05/06/97 07:30 PM
> >
> > Is there a definition of the RTP payload format for GSM? What is its
status > > right now?
>
> Been in RFC 1890, is in the current draft (with some clarifications, but
> no changes), no technical changes suggested so far.
>
> > Does it have VAD defined?
>

GSM VAD is specified in GSM 06.32 (available from ETSI).  It is an
energy thresholding algorithm with some (expensive) filtering to avoid
noise being classified as speech.  Unless you're audio tool is
designed for mobile environments it is overkill.  Energy thresholding
with some simple rules based on Brady's papers will do very nicely.

I'm not sure it makes sense to specify it in the AVT profile as it
applies to the receiver only.

Orion
---
Orion Hodson
Computer Science, University College London,
Gower Street, London, WC1E 6BT, UK.







From rem-conf Wed May 07 03:49:28 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 03:49:28 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wP489-0005MT-00; Wed, 7 May 1997 03:39:29 -0700
To: Scott_Petrack@vocaltec.com
cc: rem-conf@es.net
Subject: Re: RTP payload format defined for GSM
In-reply-to: Your message of "Wed, 07 May 1997 11:16:02 +0200." <C2256490.0029F4D4.00@maskit1.vocaltec.co.il>
Date: Wed, 07 May 1997 11:39:00 +0100
Message-ID: <2260.863001540@cs.ucl.ac.uk>
From: Orion Hodson <O.Hodson@cs.ucl.ac.uk>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> The VAD of GSM applies to the sender, I believe. You describe it yourself.

yes it does :-) typo.

> For each GSM frame produced at the sender, the sender can decide:
> 
> a .to send the frame,
> b. to send a "silence desciption frame" (SID) instead, which contains
> parameters used to update the noise generation in the receiver
> c. not to send anything at all

The decision to send an SID does come from the VAD spec, but the SID
is specified elsewhere (GSM 06.12 I think).  Neither VAD or SID is
currently in the GSM code used in the Mbone tools.  There's still some
work to be done in noise modelling in multiway conferences.

> Of course you're right that you can tell if it's an SID frame by looking at
> the bits (the excitation is 0 and you put in some random noise). But one
> could imagine tagging the SIDs.

Yes.  

> Also, do the MBONE tools ever send several GSM frames in a single RTP
> packet? (In which case I suppose that one assumes that the frames are
> consecutive in time, and the timestamp refers to the start of the group of
> frames)
> 

Yes.  You just set the packet size to 40/80/160 ms to do this.  If you
wanted to get around this you could pack them as redundant encodings.

> If MBONE tools send each GSM frame in a separate packet, then it must be
> hard to fit a GSM stream even on 28.8 dialup link if there is no silence
> (as usually happens in Israeli conversations ;-)).
 
ah...time for a 33.6 upgrade :-)

regards

Orion








From rem-conf Wed May 07 04:50:41 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 04:50:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wP5A9-0005ml-00; Wed, 7 May 1997 04:45:37 -0700
Message-Id: <199705071145.NAA21146@www45.inria.fr>
To: rem-conf@es.net
From: Philipp Hoschka <hoschka@w3.org>
Subject: Transmission from Cannes Film Festival
Date: Wed, 07 May 1997 13:45:08 +0200
Sender: Philipp.Hoschka@sophia.inria.fr
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


As last year, we'll multicast raw footage (interviews) from the Cannes 
Film Festival on the MBone.

Transmissions are scheduled every day from 5 until 7 Cannes time,
11 am to 1 pm east coast time, and 8 am to 10 am west coast time.

However, check sdr first to see whether the time has changed
for a particular day.

Note that this transmission will use redundant audio coding,
so you need either rat or fphone to receive it - vat won't work.

For more info, see
http://www.inria.fr/rodeo/personnel/hoschka/CannesCast97.html

-Philipp Hoschka

----------------------------------------------------------------------
   Philipp Hoschka
   WWW: http://www.w3.org/people/hoschka
				  |   World Wide Web Consortium
				  |   INRIA
   hoschka@sophia.inria.fr        |   2004, Route des Lucioles, BP 93
   Tel:(+33) 4 93 65 79 84        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 4 93 65 77 65        |   France
----------------------------------------------------------------------



From rem-conf Wed May 07 04:59:43 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 04:59:42 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wP5N0-00063x-00; Wed, 7 May 1997 04:58:54 -0700
Date: Wed, 7 May 1997 07:51:09 -0400
From: "H. DO-DUY" <106025.3357@compuserve.com>
Subject: Vat under WIN95
To: Vat mailing list <rem-conf@es.net>
Message-ID: <199705070758_MC2-1616-3D95@compuserve.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi,

I'm a french student in Aeronautics, and i'm working on a system of voice
communication via ethernet. I use
2 pentiums with 10/100Mb ethernet cards, and AWE64 Full-Duplex Audio-cards.
I'm under WINDOWS 95.
        I would like, if it is possible, to re-use a part of the Vat
sources in order to make my project. The problem is that i don't want to
use Tcl/Tk, and then i've got to adapt the tcl/tk interface and code in
Windows-based interface. I use Microsoft Visual C++ 4.2 with MFC. 

        The main problem i've got is when i try to reproduce calls from C++
Code  to Tcl procedures. Please confirm me that when tou call a Tcl
Procedure by Tcl.evalf("....."), the execution is done 'in parallel' so the
C code goes on while Tcl code executes.

I've got an other problem : In the Vat documentation, it's said that "When
there's audio data available to read, 
the Tk event handler calls the virtual Audio::Dispatch". Please could you
explain me where the call is done, and how you test if audio data is
available. How could i simulate that in C++ ?

I hope you will be able to help me with those problems.

Thanks a lot


Rodolphe PETIT
Toulouse , 7/05/97
e-mail : E-mail : 106025.3357@compuserve.com



From rem-conf Wed May 07 08:48:58 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 08:48:57 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wP8t9-0007Iw-00; Wed, 7 May 1997 08:44:19 -0700
From: Scott_Petrack@vocaltec.com
X-Lotus-FromDomain: VOCALTEC
To: O.Hodson@cs.ucl.ac.uk
cc: rem-conf@es.net
Message-ID: <C2256490.004FD403.00@maskit1.vocaltec.co.il>
Date: Wed, 7 May 1997 18:38:19 +0200
Subject: Re: RTP payload format defined for GSM
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list






Scott Petrack
05/07/97 06:38 PM

I forgot the most important thing - could give me a reference to the "Brady
papers" you mentioned. If there are URLs that'd be great.

Also, some pointers to papers about noise in multiparty conferences would
be very interesting to me.

("Noise in multiparty conferences" is of course a very timely topic to
discuss these days ;-))

Scott





From rem-conf Wed May 07 09:13:13 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 09:13:12 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wP9JW-0007hA-00; Wed, 7 May 1997 09:11:34 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <3370A965.4D4B@cs.columbia.edu>
Date: Wed, 07 May 1997 12:10:13 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Scott_Petrack@vocaltec.com
CC: O.Hodson@cs.ucl.ac.uk, rem-conf@es.net
Subject: Re: RTP payload format defined for GSM
References: <C2256490.004FD403.00@maskit1.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Scott_Petrack@vocaltec.com wrote:
> 
> Scott Petrack
> 05/07/97 06:38 PM
> 
> I forgot the most important thing - could give me a reference to the "Brady
> papers" you mentioned. If there are URLs that'd be great.

See http://www.cs.columbia.edu/~hgs/netbib to search for Brady. These
papers were published in the 1960s; I doubt you'll find these in
electronic form. However, every decent library should carry BSTJ.



From rem-conf Wed May 07 11:39:49 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 11:39:48 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPBRY-0000aX-00; Wed, 7 May 1997 11:28:00 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Wed, 7 May 1997 11:27:39 -0700 (PDT)
Message-Id: <199705071827.LAA16854@hille.msri.org>
To: rem-conf@es.net
From: david <david@msri.org>
Reply-to: david@msri.org
Subject: Minimal TV
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	Minimal TV
Date:        
	May 08, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	david@msri.org

URL:         
	http://www.msri.org/Computing/SGP/

Description:        
	 This videotape of animations of minimal surfaces and other extremal  surfaces was made in 1992 for the simultaneous occasions of the second  MSRI workshop on Geometric Analysis and Computer Graphics and the  500th anniversary of the voyage of Columbus. Assembled by David  Hoffman and David Oliver from the archives of the Geometry Analysis  Numerics and Graphics (<a href="http://www.gang.umass.edu/">GANG</a>),  it features the work of many mathematicians. Most of the graphics  were done by Jim Hoffman. For more details and other animations, see  the pages of the (<a href="http://www.msri.org/Computing/SGP/">Scientific Graphics Project /a>) at (<ahref="http://www.msri.org/">MSRI</a>).  









mbone broadcast schedule http://www.msri.org/mbone



From rem-conf Wed May 07 18:17:04 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 18:17:03 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPHjQ-0001n9-00; Wed, 7 May 1997 18:10:52 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <33712817.506E@cs.columbia.edu>
Date: Wed, 07 May 1997 21:10:47 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: voip-tech@vocaltec.com, rem-conf@es.net
Subject: DTMF Draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Based on recent discussions, I put together a first draft for a revised
DTMF payload type. This is not yet an 'official' I-D; in particular, the
file name of the draft may change.

Find it at http://www.cs.columbia.edu/~hgs/rtp/drafts.html

Comments are welcome.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs



From rem-conf Wed May 07 19:48:37 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 19:48:36 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPJAI-0002CY-00; Wed, 7 May 1997 19:42:42 -0700
Date: Wed, 7 May 1997 21:46:47 -0500
From: "Milind M. Buddhikot" <milind@dworkin.wustl.edu>
Message-Id: <199705080246.VAA12308@dworkin.wustl.edu>
To: rem-conf@es.net
Subject: FINAL ANNOUNCEMENT:A few slots still open for registration
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi:

This is your last chance to register for NOSSDAV97.
Note that attendance is limited to only 80 attendees and 
we have only a few slots open. So act now, if you want to register.

Thanks

Milind
------------------------x Announcement x------------------------------


                 The 7th International Workshop on
  Network and Operating System Support for Digital Audio and Video 

                          NOSSDAV'97

                    St. Louis, Missouri, USA

                         May 19-21, 1997


Registrations for NOSSDAV'97 are now being accepted.

The 7th International Workshop on Network and Operating Systems Support
for Digital Audio and Video (NOSSDAV 97) is the international workshop
concerned with state of the art technology in networking and operating
system support for multimedia systems.  For seven years, NOSSDAV has
proven to be an outstanding forum for researchers involved in building
innovative multimedia systems, networks and applications on both the
research and industrial front. Other topics that will be examined include
"middleware" for multimedia, media toolkits, mobile communications,
Virtual Reality (VR), real-time systems, software agents, digital libraries,
and other digital media besides audio and video.

A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions.  Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.

A sample of the  sessions to be held at the workshop include:
	Multicast for Multimedia
	Networking: Packet Scheduling and Integrated Services
	Multimedia-on-Demand (MOD) Servers and Services
	Smoothing and Scaling on Endsystems
	Mobility and Wireless
	Operating System Optimizations
	Middleware for Multimedia

To maintain the atmosphere of a small intense workshop, attendance is
once again being limited to 80.

Spots at the workshop are being reserved for one author per paper and
Program Committee members until April 10th. All other registration requests
will be accepted on a first come first served basis. After April 10th any
other requests that previously could not be immediately accepted will be
confirmed if space is available.

Presenting Authors and PC Members should register as soon as possible!!

On line registration and workshop program information can be accessed
>from the NOSSDAV97 web page:
	http://www.arl.wustl.edu/arl/NOSSDAV97/

The workshop will be held at Innsbrook Estates. Located approximately 45
minutes from the St. Louis airport, Innsbrook Estates has everything you
would like in a resort: 18-hole golf course, 18-hole miniature
course, swimming pool, a 150 acre lake, sailing, fishing,
swimming, sand beaches, fitness center, lighted tennis courts,
volleyball courts, horse back riding, full conference facilities, etc.


Send inquiries to:

	NOSSDAV97@arl.wustl.edu


	ATTN: NOSSDAV97
	Department of Computer Science/ARL
	Campus Box 1045
	Washington University
	One Brookings Drive
	St. Louis MO 63130, USA

	Tele: 1 314 935 7534
	Fax: 1 314 935 7302



                                 NOSSDAV '97
                                  Schedule

 Sunday, May 18, 1997

 16:00-19:00 Conference Registration
 19:00-21:30 Informal Dinner ???

 Monday, May 19, 1997

 7:30-8:30   Breakfast Buffet
 8:30-9:00   Introductions and Welcome

                  Christopher I. Byrnes
                       Dean of the School of Engineering and Applied
                       Science
                       Washington University

                  Workshop Chairs
                       Guru Parulkar
                       John DeHart

 9:00-10:30  Session I "Multimedia-on-Demand (MOD) Servers and Services"
                  Session Chair: Derek McAuley, Univ of Glasgow, UK

                * Design and Implementation of Video Server for Mixed-rate
                  Streams
                       J. Nishikawa, I. Okabayashi, Y. Mori, S. Sasaki, M.
                       Migita, Y. Obayashi, S. Furuya and K. Kaneko.
                       Matsushita Electric Industrial Co.
                * Random RAIDs with Selective Exploitation of Redundancy
                  for High Performance Video Servers
                       Y. Birk. Technion - Israel Inst. of Technology.
                * Efficient Striping Techniques for Multimedia File Servers
                       P. Shenoy, and H. Vin. University of Texas.

 10:30-11:00 Break
 11:00-12:30 Session II "Middleware for Multimedia Applications"
                  Session Chair: Steve McCanne

		* Toward a Common Infrastructure for
		  Multimedia-Networking Middleware  
			S. McCanne et al, 
			University of California,Berkeley 

                * An Extensible Framework for RTP-based Multimedia
		  Applications
			John Du, Dave Putzolu, Intel Corporation

                * Network Filters for Active Movie
			Mike Clark, Thomas Pfenning, Microsoft

 12:30-13:30 Lunch
 13:30-15:00 Session III "Networking"
                  Session Chair: KK Ramakrishnan, AT&T Research

                * A Comprehensive Multimedia Control Architecture for the
                  Internet
                       H. Schulzrinne. Columbia University.
                * Environments for Active Networks
                       R. Sharma, S. Keshav, M. Wu and L. Wu. Cornell
                       Univeristy.
                * WANDS: Wide-Area Network Delay Simulator
                       M. Borella & A. Sears. DePaul University.

SHORT PAPER:
                * A Virtual Network Service for Integrated-Services
                  Internetworks
                       L. Delgrossi and Domenico Ferrari. Unversita
                       Cattolica.

 15:00-15:30 Break
 15:30-17:00 Session IV "Operating System Optimizations"
                  Session Chair: Hide Tokuda, Keio Univ, Japan

                * Evaluation of Data Passing and Scheduling Avoidance
                       J. Brustoloni and P. Steenkiste. Carnegie Mellon
                       University.
                * User-Safe Devices for True End-to-End QoS
                       I. Pratt. University of Cambridge.
                * A Fresh Approach to File System Quality of Service
                       P. Barham. University of Cambridge.

 17:00-18:00 Break
 18:00-20:00 Banquet
 20:00-21:00 PC/Planning Meeting

 Tuesday, May 20, 1997

 7:30-8:30   Breakfast Buffet
 8:30-10:00  Session V "Mobility and Wireless"
                  Session Chair: Doug Shepherd, University of Lancaster, UK

                * Mobile Filters: Delivering Scaled Media to Mobile Devices
                       A. Balachandran and A. Campbell
                * System Support for Mobile Multimedia Applications
                       Inouye, Cen, Walpole
                * On Quality of Service in Mobile Wireless Networks
                       M. Srivastava, P. Mishra

 10:00-10:30 Break
 10:30-12:00 Session VI "Multicast"
                  Session Chair: Dan Swinehart, Xerox PARC

                * Layered Video Multicast with Retransmission (LVRM):
                  Evaluation of Error Recovery Schemes
                       X. Li and M. Ammar. Georgia Institute of Technology.
                       S. Paul and P. Pancha. Bell Laboratories.
                * Thin Streams: An Architecture for Multicasting Layered
                  Video
                       L. Wu, R. Sharma and B. Smith. Cornell University.
                * Resilient Multicast Support for Continuous Media
                  Applications
                       R. Xu, A. Myers, H. Zhang, R. Yavatkar. Carnegie
                       Mellon University and Intel.

 12:00-13:00 Lunch
 13:00-15:00 Session VII "Short Papers and A Long Panel Session:
		          Traffic Management"

                  Session Chair: Domenico Ferrari, Universita` Cattolica, Italy 
                * Service Aggregation Through Rate Adaptation Using a
                  Single Storage Format
                       Krishnan and Little
                * Practical Experience with a Smoothing Algorithm for Video
                  Streaming
                       F. Miller, X. Mei, T. Lam, K. Zhang, and S.
                       Tripathi. University of Maryland.
                * Randomized Token Buckets: Reducing the Buffers Required
                  in Multiplexors
                       J. A. Fingerhut and G. Varghese. Washington
                       University.

 15:00-16:30 Break
 16:30-23:59 Excursion (To Cardinals Baseball Game)

 Wednesday, May 21, 1997

 8:00-9:00   Breakfast Buffet
 9:00-10:30  Session VIII "Smoothing, Scaling, etc on Endsystems"
                  Session Chair: Bernhard Plattner, ETH, Zurich

                * The Performance of Two Dimensional Media Scaling for
                  Internet Videoconferencing: Experiments with ProShare(TM)
                  on the Internet
                       P. Nee, K. Jeffay and G. Danneels. University of
                       North Carolina.
                * Online Smoothing of Live, Variable-Bit-Rate Video
                       J. Rexford. AT&T Research Laboratories.
                       S. Sen, K. Dey, J. Kurose, J. Stankovic, D. Towsley.
                       University of Massachusetts.
                       W. Feng. Ohio State University.
                * Adaptive Middleware for Mobile Multimedia Applications
                       G. Blair, G. Coulson, N. Davies, P. Robin and T.
                       Fitzpatrick.Lancaster University.

 10:30-11:00 Break
 11:00-12:30 Session IX "Networking: Packet Scheduling, Integrated Service"
                  Session Chair: Hui Zhang, CMU

                * Fair Airport Scheduling Algorithms
                       P. Goyal and H. Vin. University of Texas.
                * Hierarchical Relative Error Scheduler: An Efficient
                  Traffic Shaper for Packet Switching Networks
                       A. Charny. Digital Electric Company.
                * Understanding TCP Dynamics in an Integrated Services
                  Internet
                       W. Feng, D. Kandlur, D. Saha and K. Shin. IBM.

 12:30-13:30 Lunch
             Workshop ends

----------------------------------------------------------------------------
nossdav97@arl.wustl.edu




From rem-conf Wed May 07 20:42:07 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 20:42:06 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPK2A-0002b8-00; Wed, 7 May 1997 20:38:22 -0700
Message-ID: <33714B37.5528@mitre.org>
Date: Wed, 07 May 1997 23:40:39 -0400
From: David Green <dwg@mitre.org>
Organization: The MITRE Corporation
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: Video capture card for NT 4.0 and Vic 2.8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Does anyone have direct experience (positive or negative)
getting VIC 2.8 to work on NT 4.0 with the following capture
cards?

 - Diamond Stealth64 Video 2001 TV?

 - Trident Providia 9682?

 - Matrox Mystique plus Rainbow Runner Studio?

 - Any other video capture card?

Again, the NT 4 support is important here.

If you respond directly to me, I'll summarize what I hear.

Thanks.

David Green
The MITRE Corporation
dwg@mitre.org




From rem-conf Wed May 07 21:17:45 1997 
From rem-conf-request@tmpmail.es.net Wed May 07 21:17:44 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPKaw-0002vl-00; Wed, 7 May 1997 21:14:18 -0700
Message-ID: <3371514E.1B35@ctr.columbia.edu>
Date: Thu, 08 May 1997 00:06:38 -0400
From: "Andrew T. Campbell" <campbell@ctr.columbia.edu>
Organization: Center for Telecommunications Research, Columbia University
X-Mailer: Mozilla 2.01 (WinNT; I)
MIME-Version: 1.0
To: rem-conf@es.net
CC: campbell@ctr.columbia.edu
Subject: Hot QOS Workshop: Advance Program
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sirius.ctr.columbia.edu 
                      id AAA04007
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

-
                A D V A N C E    P R O G R A M

        IFIP 5th International Workshop on Quality of Service

                          IWQOS'97

           - Building QOS into Distributed Systems -

                  Columbia University, New York

                       May 21-23, 1997

             http://comet.ctr.columbia.edu/iwqos97/


The objective of the IFIP 5th International Workshop on Quality
of Service (IWQOS) is to bring together researchers and
practitioners working in all facets of QOS research. While many
workshops and conferences offer technical sessions on the topic
of QOS,  none other than  IWQOS provides a single track workshop
dedicated to QOS research.

We think we have a great technical program lined
up for you this year. The program reflects our desire to hear
about new ideas, experimental results, controversial QOS
subjects and perspectives on where we are and where we are=20
going.

IWQOS=9297 is designed to be an interactive workshop and
not a =91sit and listen=92 conference. To reflect that goal,
technical sessions include long and short papers followed
by a thirty minute panel discussion of topics raised during
the session.

THE PROGRAM AT A GLANCE:

--------------------------------------------------
Wednesday May 21, 1997
--------------------------------------------------
1  Keynote address
   "Programming Telecommunications Networks"
   Aurel A. Lazar
     =20
2  Mobile Communications
   Session Chair: Mahmound Nagshineh

3  Traffic Management
   Session Chair: Ed Knightly

4  QOS Routing
   Session Chair: Mischa Schwartz

5  QoS and Video Systems
   Session Chair: Alexandros Eleftheriadis

6  Reception and Demos

--------------------------------------------------
Thursday May 22, 1997
--------------------------------------------------

7  QoS Management
   Session Chair: Andreas Vogel

8  Panel I: "QOS for Distributed Object Computing Middleware
   - Fact or Fiction?"
   Chair and Organizer: Douglas C. Schmidt

9  Workshop Invited Paper "Quality of Service: Where are we ?"
   R. Steinmetz and L. C. Wolf

10 Distributed Object Computing
   Session Chair: Douglas Schmidt

11 Advanced Reservation
   Session Chair: Hideyuki Tokuda

12 Workshop banquet and boat cruise around the Big Apple

--------------------------------------------------
Friday  May 23, 1997
--------------------------------------------------

13 QOS-based Transport Protocols
   Session Chair: Steve Pink
=20
14 Panel II: Reservations about Reservations
   Chair and Organizer: Henning G. Schulzrinne

15 QoS Mapping
   Session Chair: Jean-Peirre Huaux

16 QoS Adaptation
   Session Chair: Klara Nahrstedt

--------------------------------------------------

REGISTRATION INFORMATION

For on line registration, workshop information and technical
program details click on:
        =20
   http://comet.ctr.columbia.edu/iwqos97/


DETAILED PROGRAM:

----------------------------------------------------------------
----
                 Wednesday Day 1 : 21 May 1997

----------------------------------------------------------------
----

        8:50-9:00 am  Workshop Welcome

                      Andrew T. Campbell, Columbia University
                      Klara Nahrstedt, University of Illinois at
                      Urbana-Champaign

        9:00-10:00 am Keynote Address

                      "Programming Telecommunications Networks",
                      Aurel A. Lazar, Columbia University, USA

        10:30-12:30pm Technical Session 1 - Mobile=20
Communications

                      Session Chair: Mahmound Nagshineh, IBM,=20
USA

                      Long Paper Presentations

                           Adaptive Service in Mobile Computing
                           Environments
                           S. Lu, K.-W. Lee and V. Bharghavan
                           University of Illinois at Urbana-
                           Champaign, USA

                           Quality of Service Support in a=20
Mobile
                           Environment: An Approach Based on=20
Tuple
                           Spaces
                           G. Blair, N.Davies, A. Friday and=20
S.Wade
                           (Lancaster University, UK)

                      Short Paper Presentations

                           IPv6 + Mobile-IP + MRSVP =3D Internet=20
Cellular
                           Phone ?
                           B. R. Badrinath and A. K. Talukdar=20
(Rutgers
                           University, USA)

                           QoS Challenges for Next Generation=20
Mobile
                           Middleware
                           A. T. Campbell (Columbia University,=20
USA)

                           Link Error Impact on MPEG Video over=20
Wireless
                           Broadband Networks
                           J. G.- Castellanos (Columbia=20
University, USA)
                           and M. Naghshineh (IBM, USA)

                           QoS Support for Mobile Computing
                           S. Pope and P. Webster (Olivetti &=20
Oracle
                           Research Lab, UK)

                      Session Panel Discussion

        12:30-1:30pm                        L u n c h

        1:30-3:00pm   Technical Session 2 - Traffic Management

                      Session Chair: Ed Knightly, Rice=20
University, USA

                      Long Paper Presentations

                           Worst Case Arrivals of Leaky
                           Bucket Constrained Sources:
                           The Myth of the On-Off source
                           P. Oechslin (University College of
                           London, UK)

                           Guaranteeing Multiple Cell Loss=20
Classes in
                           Shared ATM Output Buffer
                           H. Lee (Korea Telecom, Korea)

                           Comprehensive Queueing Analysis for a=20
Partial
                           Buffer System with Discrete Markovian=20
Arrival
                           Processes
                           D. Becker (Aachen University of=20
Technology,
                           Germany)

                      Short Paper Presentation

                           Real-Time Estimation of the Link=20
Capacity in
                           Multimedia Networks
                           P. Maryni (University of Genoa,=20
Italy) and G.
                           Pacifici (IBM,USA)

                      Session Panel Discussion

        3:15-4:15pm   Technical Session 3 - QOS Routing

                      Session Chair: Mischa Schwartz,
                      Columbia University,USA

                      Long Paper Presentation

                           Quality of Service Routing for=20
Traffic with
                           Performance Guarantees
                           Q. Ma and P. Steenkiste (Carnegie=20
Mellon
                           University, USA)

                      Short Paper Presentation

                           QoS Based Multicast Routing for=20
Multimedia
                           Communications
                           S. Verma, R. K. Pankaj and A.=20
Leon-Garcia
                           (University of Toronto, Canada)

                      Session Panel Discussion

        4:30-6:00pm   Technical Session 4 - QoS and Video=20
Systems

                      Session Chair: Alexandros Eleftheriadis,=20
Columbia
                      University, USA

                      Long Paper Presentations

                           Supporting Multiple-tier QoS in a=20
Video
                           Bridging Application
                           R. Koodli, and C. M. Krishna=20
(University of
                           Massachusetts, USA)

                           Playout Management of Interactive=20
Video - an
                           Adaptive Approach
                           S. K. Jha, P. A. Wright and M. Fry
                           University of Technology, Sydney,=20
Australia

                      Short Paper Presentations

                           A Temporal QoS based CPU Scheduling=20
Model for
                           Multimedia Applications in General=20
Purpose
                           Operating Systems
                           D. B. Waldegg (Telecom Bretagne,=20
France)

                           Adaptive Video Applications for=20
Non-QoS
                           Networks, S. Jacobs and A.=20
Eleftheriadis
                           Columbia University, USA

                      Session Panel Discussion

        6:00-8:00     Reception and Demos

--------------------------------------------------------------
                         Thursday Day 2: 22 May 1997
--------------------------------------------------------------

   8:30-10:15am Technical Session 5 - QoS Management

                Session Chair: Andreas Vogel, Visgenic Corp.,=20
USA

                Long Paper Presentations

                     Integrated CPU and Network I/O QoS=20
Management in an
                     Endsystem
                     K. Lakshman, R. Yavatkar and R. Finkel=20
(Intel, USA)

                     Service-Tailored QoS Management in High=20
Performance
                     Networks
                     R. Bless, M. Jacob and C. Schmidt=20
(University of
                     Karlsruhe, Germany)

                Short Paper Presentations

                     Application Design for Cooperative QoS=20
Management
                     S. Fischer, M.-V. O. M. Salem and G. v.=20
Bochmann
                     (University of Montreal, Canada)

                     On the Specification of End-to-End QoS=20
Control
                     J. B. de Meer (GMD FOKUS, Germany)

                     Using attribute-managed storage to achieve=20
QoS
                     E. Borowsky, R. Golding, A. Merchant,
                     L. Schreier, E. Shriver, M. Spasojevic
                     and J. Wilkes (Hewlett-Packard
                     Laboratories, USA)

                Session Panel Discussion

   10:30-12:00m Panel I - QOS for Distributed Object Computing
                Middleware - Fact or Fiction ?

                Chair: Douglas C. Schmidt, Washington=20
University, USA

                Panelists:
                Max Ott, NEC, USA
                Guru Parulkar, Washington U., USA
                Rolf Stadler, Columbia U., USA
                Andreas Vogel, Visigenic, USA

   12:00-1:00pm                          L u n c h

   1:00-2:00pm  Invited Speaker
                Quality of Service: Where are we ?
                R. Steinmetz and L. C. Wolf
                (Darmstadt University, Germany)

   2:15-4:00pm  Technical Session 6 - Distributed Object=20
Computing

                Session Chair: Douglas Schmidt, Washington=20
University at
                St. Louis, USA

                Long Paper Presentations

                     Integrating QoS Restrictions into the=20
Process of
                     Service Selection
                     C. Linnhoff-Popien and D. Thissen (Aachen
                     University of Technology, Germany)

                     Quality of Service (QoS) in Communication=20
APIs
                     W. Almesberger (EPFL DI-LRC, Switzerland),=20
S.
                     Sasyan (Hewlett Packard, France) and S.=20
Wright (
Fujitsu
                     Network Communications, France)

                Short Paper Presentations

                     Managing Systemic Meta-Data for Creating
                     QoS-Adaptive CORBA Applications
                     J. A. Zinky and D. E. Bakken (BBN Systems=20
and
                     Technologies, USA)

                     Support Components for Quality of Service=20
in
                     Distributed Environments: Monitoring=20
Service
                     D. A. Reed and K. J. Turner (University of
                     Sterling, UK)

                     A QoS Configuration System for Distributed
                     Applications
                     A. Smith and A. Grace (Distributed Systems
                     Group, BT Laboratories, UK)

                Session Panel Discussion

   4:15-5:15pm  Technical Session 7 - Advanced Reservation

                Session Chair: Hideyuki Tokuda, Keio University,=20
Japan

                Long Paper Presentations

                     Sharing Resources through Advance=20
Reservation
                     Agents
                     O. Schelen & S. Pink (Swedish Institute of
                     Computer Science, Sweden)

                     Providing a Scalable Video-on-Demand System=20
using
                     Future Reservation of Resources and=20
Multicast
                     Communications
                     A. Hafid (Computer Research Institute of=20
Montreal,
                     Canada)

                Session Panel Discussion

   7.30-10.30  Workshop Banquet and Cruise around the Big Apple
=20
----------------------------------------------------------------
-----
                          Friday Day 3: 23 May 1997
----------------------------------------------------------------
-----

   9:00-10:30am  Technical Session 8 - QOS-based Transport=20
Protocols

                 Session Chair: Steven Pink, Swedish Institute
                 of Computer Science, Sweden

                 Long Paper Presentations

                      QoS Mapping between User's Preference and
                      Bandwidth Control for Video Transport
                      K. Fukuda, N. Wakamiya, M. Murata and H.=20
Miyahara
                      (Osaka University, Japan)

                      On End-to-End QoS Mapping
                      J.-F. Huard and A. A. Lazar (Columbia=20
University,
                      USA)

                 Short Paper Presentations

                      Transport QoS over Unreliable Networks: No
                      Guarantees, No Free Lunch!
                      P. Conrad, P. Amer, E. Golden, S. Iren, R.=20
Marasli
                      and A. Caro (University of Delaware, USA)

                      QoS-Based Transport
                      G. Mapp and S. Hodges (Olivetti & Oracle=20
Research
                      Lab, UK)

                 Session Panel Discussion

   10:45-12:00pm Panel II - Reservations about Reservations

                 Chair: Henning G. Schulzrinne, Columbia=20
University, USA

                 Panelists:
                 Fred Baker, CISCO, USA
                 Jon Crowcroft, UCL, UK
                 Roch Guerin, IBM, USA
                 Lixa Zhang, UCLA, USA

   12:00-1:00pm                           L u n c h

   1:00-2:30pm   Technical Session 9 - QoS Mapping

                 Session Chair: Jean-Peirre Huaux, EPFL,=20
Switzerland

                 Long Paper Presentations

                      Simplified Method for Session Coordination=20
Using
                      Multi-level QOS Specification and=20
Translation
                      N. Nishio and H. Tokuda (Keio University,=20
Japan)

                      Quantitative QoS-Mapping: A Unifying=20
Approach
                      H. Knoche and H. de Meer (University of=20
Hamburg,
                      Germany)

                 Short Paper Presentations

                      QoS Translation and Admission Control for
                      MPEG Video
                      K. Kim and K. Nahrstedt (University of=20
Illinois at
                      Urbana-Champaign, USA)

                      Towards Specifying QoS-Enabling Software
                      Architectures
                      V. Issarny, C. Bidan, F. Leleu and T.=20
Saridakis
                      (IRISA/INRIA, France)

                 Session Panel Discussion

   2:45-4:15pm   Technical Session 10 - QoS Adaptation

                 Session Chair: Klara Nahrstedt, University of=20
Illionis
                 AT Urbana-Champaign, USA

                 Long Paper Presentations

                      Terminal QoS of Adaptive Applications and=20
its
                      Analytical Computation
                      P. Moghe and A. Kalavade (Bell-Labs, USA)

                      End-to-End Quality of Service Control=20
Using
                      Adaptive Applications
                      D. Sisalem (GMD FOKUS, Germany)

                 Short Paper Presentations

                      Adaptive QoS and in Multimedia Systems
                      M. Ott, G. Michelitsch, D. Reininger and=20
G.
                      Welling (NEC, USA)

                      A Dynamic QoS Adaptation for Networked=20
Virtual
                      Reality
                      S. Oh, H. Sugano, S. Shimojo, H. Miyahara=20
(Osaka
                      University, Japan), K. Fujikawa (Nara=20
Institute of
                      Science and Technology, Japan), T.=20
Matsuura (Osaka
                      City University, Japan),=20
M.Arikawa(Hiroshima City
                      University, Japan)

                      Predictable File Access Latency for=20
Multimedia
                      D. Revel, C. Cowan, D. McNamee,
                      C. Pu and J. Walpole
                      (Oregan State Institute, USA)

                 Session Panel Discussion

--
Andrew T. Campbell =20
http://comet.ctr.columbia.edu/~campbell
Wireless Media Systems Project=20
http://comet.ctr.columbia.edu/wireless



From rem-conf Thu May 08 14:41:12 1997 
From rem-conf-request@tmpmail.es.net Thu May 08 14:41:11 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPahB-0006Le-00; Thu, 8 May 1997 14:25:49 -0700
Message-Id: <199705082123.OAA02417@tikal.synopsys.com>
To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org
Cc: bigmac@baylisa.org
Subject: BayLISA May 15: "Global NT Infrastructure in the Real World"
Date: Thu, 08 May 1997 14:23:12 -0700
From: Bryan McDonald <bigmac@Synopsys.COM>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


The BayLISA group meets monthly to discuss topics of interest to systems
and network administrators.  The meetings are free and open to the public.
Please feel free to redistribute this meeting announcement.
 
BayLISA holds monthly meetings on the third Thursday of each month at
7:30 PM PST.  We meet at Cisco Building J in San Jose, on Tasman Drive near
First street. See www.baylisa.org for more information.  The meetings are also
broadcast via MBONE.

Schedule
--------

May 15, 1997: "Global NT Infrastructure in the Real World"
              Xev Gittler & Christopher Rouland, Lehman Brothers 

[Schedule subject to change]
 
For further information on BayLISA, check out our web site:
http://www.baylisa.org/
 
To get further information on the meeting location, you can also ftp it from
 
        ftp.baylisa.org:/BayLISA/location
 
For any other information, please send email to:
 
        info@baylisa.org
 
If you have any questions, please contact me or the info alias listed above.

===============================================================================
Bryan McDonald                                          bigmac@baylisa.org
President						president@baylisa.org
BayLISA							http://www.baylisa.org
===============================================================================



From rem-conf Thu May 08 14:41:16 1997 
From rem-conf-request@tmpmail.es.net Thu May 08 14:41:15 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPalm-0006N8-00; Thu, 8 May 1997 14:30:34 -0700
Message-ID: <01BC5BBC.89FD2820@mikent.nuera.com>
From: "Michael W. Fox" <mfox@nuera.com>
To: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>
Cc: "rem-conf@es.net" <rem-conf@es.net>, 
    "voip-tech@vocaltec.com" <voip-tech@vocaltec.com>
Subject: RE: DTMF Draft
Date: Thu, 8 May 1997 14:31:35 -0700
Encoding: 10 TEXT
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Another comment regarding DTMF ...

I think that some redundancy of the coding of the last digit is required. 
Perhaps sending a digits total duration information in at least three 
packets should be required.

Mike Fox
Nuera Communications






From rem-conf Fri May 09 03:19:23 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 03:19:22 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPmfe-0000ls-00; Fri, 9 May 1997 03:13:02 -0700
Posted-Date: Thu, 8 May 1997 23:00:23 +0200
From: Benking Heiner <BENKING@faw.uni-ulm.de>
To: 2IN97 <2IN97@prism.uvsq.fr>, congres <congres@prism.uvsq.fr>
Subject: Re: 21N97
Date: Thu, 08 May 97 13:50:00 PDT
Message-ID: <3372B117@pc.faw.uni-ulm.de>
Encoding: 179 TEXT
X-Mailer: Microsoft Mail V3.0
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



 ----------
> Von: 2IN97
> An: congres
> Betreff: 21N97
> Datum: Mittwoch, 5. M{rz 1997 12:48
>
> I have just received part of a message about a call for papers but the
> important part is missing. Would you send the message again, please?
>
> Regards,
>
> Niall O'Loughlin
>
>
empty rooms in mental flats - looking for locomotion?
in the last line you find some sources and orientation for this message

maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group 
list !??

                              Heiner BENKING


re: SHARING MENTAL HOMES - a  QUEST for more   MENTAL MOBILITY


here an up-date and maybe a starter in form of a message just needed to send 
somewhere

          Heiner Benking

_-_

Dear list members,
I try to bridge two lists, as the topics are too close
and it gets boring always getting a grip or grasp and then letting go..
                                   Heiner

> ----------
> Von: owner-debono
> An: DEBONO
> Betreff: Creativity and Rods & Cones
> Datum: Mittwoch, 7. Mai 1997 11:48
>
>  In a message dated 97-05-06 11:01:15 EDT, you write:
>
> << ... Have you ever noticed how night vision works.  Part of your mind 
picks
> up clear images on the periphery of your line of sight, but when you shift
> your focus to where the image was, it loses its definition. I think
> creativity works a little like this:  it occurs on the edge of our line of
> sight.  If we're not too focussed on what we're looking at, we notice the
> creative image and try to bring it into focus, but if we persist in 
peering
> straight ahead, we fail to notice that we even "saw" something "off to the
> side"... I apologize if this musing is self-indulgent and thank you for 
the
> provocation. >>
>
> Metaphors are the furnishings of our mental home.  Thank you for making a
> very insightful addition to my decor, although I can really only see this
> item peripherally, I guess.
>
> Adam Hansen
> The Generativity Group

 ----------
> Von: list
> An: unis
> Cc: ThomasM451
> Betreff: Re: simple language & Korea
> Datum: Mittwoch, 7. Mai 1997 23:30
>
> In a message dated 97-05-07 16:17:07 EDT, you write:
>
> <<
>  In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
>
>  <<  I admitted up front that I knew nothing about Korea, except that they
>   are about to go to war again. What I am asking is not for "ideal"
>  situations, but fundamental situations.  (this is the second time simple 
language has
>   been mistaken for idealistic language, interesting)  The foundation for 
my
>   "fantasy" is simply the principle of a loving relationship - mutual 
synergy.
>
>
>  Hello:
>  If the language of  form requires us to frame a discussion through a
>  particular lense, then we would need to agree to the form/lense up-front. 
We
>  would also be able to predict all the unconscious variables that would
> surely  'come up' into our field of awareness, as a result of framing such 
a
>  discussion..........and without saying much more its clear to me why many
>  theorists state there is no such thing as com-unication, let alone 
'simple
>  language'!
>
>  My admittedlly incomplete appreciation of Stytematics has me feeling like 
we
>  are in all the forms at once. .....

_____________________________________________
BEGIN OF MESSAGE:

Hi,

Well I think our mental homes are 'not in order'. We try with precision, 
forcing focus on the specifics, but camouflage the whole' as Steve Kurtz 
once wrote, but not daring to look for the context, the relations and 
connections. As Kant was looking with his carcateristica universalis, i call 
it an 'organizing glass' into the inner structure (remember Alice in 
WONDERLAND) we can at least build a conceptual house of knowledge, beyond 
languages, if we restrict ourselves !!  to the general overview, the birds 
eye.
The result is that we can suddenly see and get awe as we grasp how little we 
know !! See wholeness and worldview discussion and the recent work on:
Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).

I think this focussing on words, as some lists do, can work in coherent 
groups, but the moment you jump over the fence, you are lost, as the 
NOMINALISTS, go for 'exact words' their code, in a hierarchical order, 
knowledge trees. My position is absolutely to the contrary, I am a 
CONCEPTUALIST, looking for 'concepts in their context' and try to move, 
merge and transform along and across scales.

We have, if we ever want to bridge 'schools' and mental territories have to 
see the deeper connections. The mind's eye pondering above shows the way!

I would like to show that Einstein was pondering also about words:

The word or the language, written or spoken,
do not seem to have any impact (role)
in the mechanism of my line of thought.
The mental building blocks of thinking
are certain signs/symbols and more or less clear pictures,
which can be reproduced and combined at will (according desire/wish?)

                              Albert Einstein

maybe someone can help with the best words !?? as I only have a German 
version:

               Das Wort oder die Sprache, geschrieben oder gesprochen,
               scheinen im Mechanismus meines Gedankenablaufes
               }berhaupt keine Rolle zu spielen.
               Die psychischen Grundelemente des Denkens
               sind bestimmte Zeichen und mehr oder weniger klare Bilder,
               die  nach Wunsch  reproduziert und kombiniert werden k|nnen.

                              Albert Einstein


I would like to sum up by saying that I profit most by learning the style 
and the class of the different lists, my English is not good enough to 
discuss with any one of you 'seriously' (I appreciate the braod wandwith 
personal aprach anyway!)

but I can tell you that we are all very close, but are typically not aware 
of it, all living in our private MENTAL HOMES, in cocoons, and ponder about 
details...

As I like to share and feel that I live in some mental homes in parallel (my 
cognitive panorama) you are most welcome to visit and move in...

warmely

Heiner
http://www.uia.org/uiadocs/spatialm.htm
http://www.newciv.org/ISSS_Primer/seminrva.html
http://heri.cicv.fr/council/speeches/benkingtxt.html
http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm






From rem-conf Fri May 09 03:46:18 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 03:46:18 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPnAb-00016M-00; Fri, 9 May 1997 03:45:01 -0700
Message-Id: <01BC5C6D.59268AA0@indus.dlib.com>
From: Joerg Mueller <jpm@zuno.com>
To: 'Benking Heiner' <BENKING@faw.uni-ulm.de>, 2IN97 <2IN97@prism.uvsq.fr>, 
    congres <congres@prism.uvsq.fr>
Subject: RE: 21N97
Date: Fri, 9 May 1997 11:37:16 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi,

whoever is responsible for this list, PLEASE remove me from it. I am not interested at all in receiving that crap.

Thanks

-- joerg

 ----------
> Von: 2IN97
> An: congres
> Betreff: 21N97
> Datum: Mittwoch, 5. M{rz 1997 12:48
>
> I have just received part of a message about a call for papers but the
> important part is missing. Would you send the message again, please?
>
> Regards,
>
> Niall O'Loughlin
>
>
empty rooms in mental flats - looking for locomotion?
in the last line you find some sources and orientation for this message

maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group 
list !??

                              Heiner BENKING


re: SHARING MENTAL HOMES - a  QUEST for more   MENTAL MOBILITY


here an up-date and maybe a starter in form of a message just needed to send 
somewhere

          Heiner Benking

_-_

Dear list members,
I try to bridge two lists, as the topics are too close
and it gets boring always getting a grip or grasp and then letting go..
                                   Heiner

> ----------
> Von: owner-debono
> An: DEBONO
> Betreff: Creativity and Rods & Cones
> Datum: Mittwoch, 7. Mai 1997 11:48
>
>  In a message dated 97-05-06 11:01:15 EDT, you write:
>
> << ... Have you ever noticed how night vision works.  Part of your mind 
picks
> up clear images on the periphery of your line of sight, but when you shift
> your focus to where the image was, it loses its definition. I think
> creativity works a little like this:  it occurs on the edge of our line of
> sight.  If we're not too focussed on what we're looking at, we notice the
> creative image and try to bring it into focus, but if we persist in 
peering
> straight ahead, we fail to notice that we even "saw" something "off to the
> side"... I apologize if this musing is self-indulgent and thank you for 
the
> provocation. >>
>
> Metaphors are the furnishings of our mental home.  Thank you for making a
> very insightful addition to my decor, although I can really only see this
> item peripherally, I guess.
>
> Adam Hansen
> The Generativity Group

 ----------
> Von: list
> An: unis
> Cc: ThomasM451
> Betreff: Re: simple language & Korea
> Datum: Mittwoch, 7. Mai 1997 23:30
>
> In a message dated 97-05-07 16:17:07 EDT, you write:
>
> <<
>  In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
>
>  <<  I admitted up front that I knew nothing about Korea, except that they
>   are about to go to war again. What I am asking is not for "ideal"
>  situations, but fundamental situations.  (this is the second time simple 
language has
>   been mistaken for idealistic language, interesting)  The foundation for 
my
>   "fantasy" is simply the principle of a loving relationship - mutual 
synergy.
>
>
>  Hello:
>  If the language of  form requires us to frame a discussion through a
>  particular lense, then we would need to agree to the form/lense up-front. 
We
>  would also be able to predict all the unconscious variables that would
> surely  'come up' into our field of awareness, as a result of framing such 
a
>  discussion..........and without saying much more its clear to me why many
>  theorists state there is no such thing as com-unication, let alone 
'simple
>  language'!
>
>  My admittedlly incomplete appreciation of Stytematics has me feeling like 
we
>  are in all the forms at once. .....

_____________________________________________
BEGIN OF MESSAGE:

Hi,

Well I think our mental homes are 'not in order'. We try with precision, 
forcing focus on the specifics, but camouflage the whole' as Steve Kurtz 
once wrote, but not daring to look for the context, the relations and 
connections. As Kant was looking with his carcateristica universalis, i call 
it an 'organizing glass' into the inner structure (remember Alice in 
WONDERLAND) we can at least build a conceptual house of knowledge, beyond 
languages, if we restrict ourselves !!  to the general overview, the birds 
eye.
The result is that we can suddenly see and get awe as we grasp how little we 
know !! See wholeness and worldview discussion and the recent work on:
Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).

I think this focussing on words, as some lists do, can work in coherent 
groups, but the moment you jump over the fence, you are lost, as the 
NOMINALISTS, go for 'exact words' their code, in a hierarchical order, 
knowledge trees. My position is absolutely to the contrary, I am a 
CONCEPTUALIST, looking for 'concepts in their context' and try to move, 
merge and transform along and across scales.

We have, if we ever want to bridge 'schools' and mental territories have to 
see the deeper connections. The mind's eye pondering above shows the way!

I would like to show that Einstein was pondering also about words:

The word or the language, written or spoken,
do not seem to have any impact (role)
in the mechanism of my line of thought.
The mental building blocks of thinking
are certain signs/symbols and more or less clear pictures,
which can be reproduced and combined at will (according desire/wish?)

                              Albert Einstein

maybe someone can help with the best words !?? as I only have a German 
version:

               Das Wort oder die Sprache, geschrieben oder gesprochen,
               scheinen im Mechanismus meines Gedankenablaufes
               }berhaupt keine Rolle zu spielen.
               Die psychischen Grundelemente des Denkens
               sind bestimmte Zeichen und mehr oder weniger klare Bilder,
               die  nach Wunsch  reproduziert und kombiniert werden k|nnen.

                              Albert Einstein


I would like to sum up by saying that I profit most by learning the style 
and the class of the different lists, my English is not good enough to 
discuss with any one of you 'seriously' (I appreciate the braod wandwith 
personal aprach anyway!)

but I can tell you that we are all very close, but are typically not aware 
of it, all living in our private MENTAL HOMES, in cocoons, and ponder about 
details...

As I like to share and feel that I live in some mental homes in parallel (my 
cognitive panorama) you are most welcome to visit and move in...

warmely

Heiner
http://www.uia.org/uiadocs/spatialm.htm
http://www.newciv.org/ISSS_Primer/seminrva.html
http://heri.cicv.fr/council/speeches/benkingtxt.html
http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm







From rem-conf Fri May 09 04:31:31 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 04:31:30 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPnlk-0001Sx-00; Fri, 9 May 1997 04:23:24 -0700
Sender: Yoan.Adida@masi.ibp.fr
Message-ID: <3373067F.3E400605@masi.ibp.fr>
Date: Fri, 09 May 1997 13:11:59 +0200
From: Yoan ADIDA <adida@masi.ibp.fr>
X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.1.23 i586)
MIME-Version: 1.0
To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
Subject: REMOVE
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi,

could you please remove me from the mailing-list.

I never asked to get into it.

-- 
Adida Yoan

	"Honni soit qui manigance , bien mal acquis ne profite qu'apres"
			-- Coluche



From rem-conf Fri May 09 04:35:30 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 04:35:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPnvs-0001hY-00; Fri, 9 May 1997 04:33:52 -0700
Message-Id: <199705091120.NAA16335@mohican.cc.uit.no>
X-Authentication-Warning: mohican.cc.uit.no: svenn owned process doing -bs
X-Mailer: exmh version 2.0gamma 1/27/96
To: Joerg Mueller <jpm@zuno.com>
cc: 'Benking Heiner' <BENKING@faw.uni-ulm.de>, 2IN97 <2IN97@prism.uvsq.fr>, 
    congres <congres@prism.uvsq.fr>, svenn@cc.uit.no
Subject: Re: 21N97
In-reply-to: Your message of "Fri, 09 May 1997 11:37:16 METDST." <01BC5C6D.59268AA0@indus.dlib.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 May 1997 13:19:40 +0200
From: Svenn Hanssen <Svenn.Agnar.Hanssen@cc.uit.no>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I concur!!!

-Svenn

> Hi,
> 
> whoever is responsible for this list, PLEASE remove me from it. I am not interested at all in receiving that crap.
> 
> Thanks
> 
> -- joerg
> 
>  ----------
> > Von: 2IN97
> > An: congres
> > Betreff: 21N97
> > Datum: Mittwoch, 5. M{rz 1997 12:48
> >
> > I have just received part of a message about a call for papers but the
> > important part is missing. Would you send the message again, please?
> >
> > Regards,
> >
> > Niall O'Loughlin
> >
> >
> empty rooms in mental flats - looking for locomotion?
> in the last line you find some sources and orientation for this message
> 
> maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group 
> list !??
> 
>                               Heiner BENKING
> 
> 
> re: SHARING MENTAL HOMES - a  QUEST for more   MENTAL MOBILITY
> 
> 
> here an up-date and maybe a starter in form of a message just needed to send 
> somewhere
> 
>           Heiner Benking
> 
> _-_
> 
> Dear list members,
> I try to bridge two lists, as the topics are too close
> and it gets boring always getting a grip or grasp and then letting go..
>                                    Heiner
> 
> > ----------
> > Von: owner-debono
> > An: DEBONO
> > Betreff: Creativity and Rods & Cones
> > Datum: Mittwoch, 7. Mai 1997 11:48
> >
> >  In a message dated 97-05-06 11:01:15 EDT, you write:
> >
> > << ... Have you ever noticed how night vision works.  Part of your mind 
> picks
> > up clear images on the periphery of your line of sight, but when you shift
> > your focus to where the image was, it loses its definition. I think
> > creativity works a little like this:  it occurs on the edge of our line of
> > sight.  If we're not too focussed on what we're looking at, we notice the
> > creative image and try to bring it into focus, but if we persist in 
> peering
> > straight ahead, we fail to notice that we even "saw" something "off to the
> > side"... I apologize if this musing is self-indulgent and thank you for 
> the
> > provocation. >>
> >
> > Metaphors are the furnishings of our mental home.  Thank you for making a
> > very insightful addition to my decor, although I can really only see this
> > item peripherally, I guess.
> >
> > Adam Hansen
> > The Generativity Group
> 
>  ----------
> > Von: list
> > An: unis
> > Cc: ThomasM451
> > Betreff: Re: simple language & Korea
> > Datum: Mittwoch, 7. Mai 1997 23:30
> >
> > In a message dated 97-05-07 16:17:07 EDT, you write:
> >
> > <<
> >  In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
> >
> >  <<  I admitted up front that I knew nothing about Korea, except that they
> >   are about to go to war again. What I am asking is not for "ideal"
> >  situations, but fundamental situations.  (this is the second time simple 
> language has
> >   been mistaken for idealistic language, interesting)  The foundation for 
> my
> >   "fantasy" is simply the principle of a loving relationship - mutual 
> synergy.
> >
> >
> >  Hello:
> >  If the language of  form requires us to frame a discussion through a
> >  particular lense, then we would need to agree to the form/lense up-front. 
> We
> >  would also be able to predict all the unconscious variables that would
> > surely  'come up' into our field of awareness, as a result of framing such 
> a
> >  discussion..........and without saying much more its clear to me why many
> >  theorists state there is no such thing as com-unication, let alone 
> 'simple
> >  language'!
> >
> >  My admittedlly incomplete appreciation of Stytematics has me feeling like 
> we
> >  are in all the forms at once. .....
> 
> _____________________________________________
> BEGIN OF MESSAGE:
> 
> Hi,
> 
> Well I think our mental homes are 'not in order'. We try with precision, 
> forcing focus on the specifics, but camouflage the whole' as Steve Kurtz 
> once wrote, but not daring to look for the context, the relations and 
> connections. As Kant was looking with his carcateristica universalis, i call 
> it an 'organizing glass' into the inner structure (remember Alice in 
> WONDERLAND) we can at least build a conceptual house of knowledge, beyond 
> languages, if we restrict ourselves !!  to the general overview, the birds 
> eye.
> The result is that we can suddenly see and get awe as we grasp how little we 
> know !! See wholeness and worldview discussion and the recent work on:
> Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).
> 
> I think this focussing on words, as some lists do, can work in coherent 
> groups, but the moment you jump over the fence, you are lost, as the 
> NOMINALISTS, go for 'exact words' their code, in a hierarchical order, 
> knowledge trees. My position is absolutely to the contrary, I am a 
> CONCEPTUALIST, looking for 'concepts in their context' and try to move, 
> merge and transform along and across scales.
> 
> We have, if we ever want to bridge 'schools' and mental territories have to 
> see the deeper connections. The mind's eye pondering above shows the way!
> 
> I would like to show that Einstein was pondering also about words:
> 
> The word or the language, written or spoken,
> do not seem to have any impact (role)
> in the mechanism of my line of thought.
> The mental building blocks of thinking
> are certain signs/symbols and more or less clear pictures,
> which can be reproduced and combined at will (according desire/wish?)
> 
>                               Albert Einstein
> 
> maybe someone can help with the best words !?? as I only have a German 
> version:
> 
>                Das Wort oder die Sprache, geschrieben oder gesprochen,
>                scheinen im Mechanismus meines Gedankenablaufes
>                }berhaupt keine Rolle zu spielen.
>                Die psychischen Grundelemente des Denkens
>                sind bestimmte Zeichen und mehr oder weniger klare Bilder,
>                die  nach Wunsch  reproduziert und kombiniert werden k|nnen.
> 
>                               Albert Einstein
> 
> 
> I would like to sum up by saying that I profit most by learning the style 
> and the class of the different lists, my English is not good enough to 
> discuss with any one of you 'seriously' (I appreciate the braod wandwith 
> personal aprach anyway!)
> 
> but I can tell you that we are all very close, but are typically not aware 
> of it, all living in our private MENTAL HOMES, in cocoons, and ponder about 
> details...
> 
> As I like to share and feel that I live in some mental homes in parallel (my 
> cognitive panorama) you are most welcome to visit and move in...
> 
> warmely
> 
> Heiner
> http://www.uia.org/uiadocs/spatialm.htm
> http://www.newciv.org/ISSS_Primer/seminrva.html
> http://heri.cicv.fr/council/speeches/benkingtxt.html
> http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm
> 
> 
> 
> 





From rem-conf Fri May 09 04:54:23 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 04:54:22 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPoDD-00025C-00; Fri, 9 May 1997 04:51:47 -0700
Date: Fri, 9 May 1997 07:52:18 -0400
Message-Id: <9705091152.AA06002@notesgw1.cc.bellcore.com>
To: "Michael W. Fox" <mfox@nuera.com>
Cc: 'Henning Schulzrinne' <schulzrinne@cs.columbia.edu>, 
    "rem-conf@es.net" <rem-conf@es.net>, 
    "voip-tech@vocaltec.com" <voip-tech@vocaltec.com>
From: "Michael A. Ramalho" <mramalho@notes.cc.bellcore.com>
Subject: RE: DTMF Draft
Mime-Version: 1.0
Content-Type: Text/Plain
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Yet another small comment regarding DTMF ...

I agree with Mike Fox's comment below (although more than 3 would
probably be sent anyway due to the DTMF duration). Also, looking at the
duration field and its maximum representation of 2.55 seconds, it appears
just slightly too short a duration. For example, many calling card scenarios
allow one to hit the # button for two seconds to make another call
without hanging up. I hold it for longer than 2 seconds because experience
tells me that longer is better (sometimes the system is slow to act and
misses my que if I only hold it for 2 seconds). Given the accuracy of
human time guesstimation, I'd suggest another bit (or other format to
accommodate up to about 4 seconds).

Michael Ramalho
VoIP QoS subcommittee facilitator
Belllcore

To: schulzrinne @ cs.columbia.edu ("'Henning Schulzrinne'") @ smtp
cc: rem-conf @ es.net ("rem-conf@es.net") @ smtp, voip-tech @ vocaltec.com 
("voip-tech@vocaltec.com") @ smtp 
From: mfox @ nuera.com ("Michael W. Fox") @ smtp
Date: 05/08/97 02:31:35 PM
Subject: RE: DTMF Draft

Another comment regarding DTMF ...

I think that some redundancy of the coding of the last digit is required. 
Perhaps sending a digits total duration information in at least three 
packets should be required.

Mike Fox
Nuera Communications



 




From rem-conf Fri May 09 05:20:58 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 05:20:57 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPoeU-0002Ur-00; Fri, 9 May 1997 05:19:58 -0700
Date: Fri, 9 May 1997 13:42:34 +0100 (WET DST)
From: Romain Bigeard <bigeard@comte.univ-fcomte.fr>
X-Sender: bigeard@comte
Cc: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
Subject: Re: REMOVE
In-Reply-To: <3373067F.3E400605@masi.ibp.fr>
Message-Id: <Pine.SOL.3.96.970509134131.18931A-100000@comte>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Please Remove me from this mailing list. Il have better things to do than
to read that crap !


***************************************************
Romain Bigeard
Laboratoire d'Informatique de Besancon
16 Route de Gray 25030 Besancon Cedex FRANCE
Tel : +(33) 3 81 66 64 60 Fax : +(33) 3 81 66 64 50
***************************************************




From rem-conf Fri May 09 05:22:06 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 05:22:06 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPogS-0002eV-00; Fri, 9 May 1997 05:22:00 -0700
From: silberz@ladl.jussieu.fr
Message-Id: <199705091310.AA24339@ ladl.jussieu.fr>
Date: Fri, 9 May 1997 14:09:47 +0100
Apparently-To: BENKING@faw.uni-ulm.de
Apparently-To: congres@prism.uvsq.fr
Apparently-To: 2IN97@prism.uvsq.fr
Bcc:
To: rem-conf@tmpmail.es.net
Subject: Unidentified subject!
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

>From silberz Fri May  9 14:09:45 1997
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
Received: by NeXT.Mailer (1.118.2.RR)
From: Max Silberztein <silberz>
Date: Fri,  9 May 97 14:09:45 +0100
To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
Subject: REMOVE
References: <199705091148.NAA02310@teco11a.teco.uni-karlsruhe.de>

Please remove me from the mailing-list NOW.
I never asked to get into it.



From rem-conf Fri May 09 05:28:43 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 05:28:43 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPomY-00034f-00; Fri, 9 May 1997 05:28:18 -0700
Date: Fri, 9 May 1997 08:28:15 -0400
Message-Id: <199705091228.IAA04162@orca.umcs.maine.edu>
From: Roy Turner <rmt@umcs.maine.edu>
To: silberz@ladl.jussieu.fr
Cc: rem-conf@tmpmail.es.net
Subject: Unidentified subject!
In-Reply-To: <199705091310.AA24339@ ladl.jussieu.fr>
References: <199705091310.AA24339@ ladl.jussieu.fr>
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
Reply-To: rmt@umcs.maine.edu (Roy M. Turner)
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


For those of you wanting off the list (which does seem to have lots of noise
on it recently), here are the instructions you should have gotten when you
subscribed: 

   You have been added to the rem-conf@es.net mailing list. Here is some 
   information about the list:

   1) The rem-conf mailing list is used for IETF Remote Conferencing.

   2) To UNSUBSCRIBE from the rem-conf mailing list, send email to
      rem-conf-request@es.net.

   3) To SUBSCRIBE to the rem-conf mailing list, send email to
      rem-conf-request@es.net. 

   4) Please do not send subscribe or unsubscribe requests directly to
      the list address, rem-conf@es.net. This address is used only for
      discussions related to the purpose of the mailing list (see #1). 

-------
Roy M. Turner, Assistant Professor () E-mail: rmt@umcs.maine.edu               
Department of Computer Science     () WWW:    http://cdps.umcs.maine.edu/~rmt  
5752 Neville Hall                  () Phone:  (207)581-3909                    
University of Maine                () FAX:    (207)581-4977                    
Orono, ME 04469-5752               () I use Lisp because I know C, C++, Ada,...



From rem-conf Fri May 09 05:34:27 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 05:34:26 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPoqO-0003L0-00; Fri, 9 May 1997 05:32:16 -0700
Date: Fri, 9 May 97 19:49:01 SIN
Message-ID: <vines.+T+8+ewkQnB@mail-gw.singtel.com>
X-Priority: 3 (Normal)
To: 2IN97 <2IN97@prism.uvsq.fr>, congres <congres@prism.uvsq.fr>
From: seow yoke kong <Seow=Yoke=Kong%MLEO%ML@singtel.com>
Subject: Unsubscribe
X-Incognito-SN: 435
X-Incognito-Format: VERSION=2.01a ENCRYPTED=NO
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Unsubscribe y.seow@ieee.org
-------------
Original Text
>From Joerg Mueller <jpm@zuno.com>, on 5/9/97 11:37 AM:
To: "'Benking Heiner'" <BENKING@faw.uni-ulm.de>, "2IN97" 
<2IN97@prism.uvsq.fr>, "congres" <congres@prism.uvsq.fr>

Hi,
whoever is responsible for this list, PLEASE remove me from it. I am not 
interested at all in receiving that crap.

Thanks

-- joerg

 ----------
> Von: 2IN97
> An: congres
> Betreff: 21N97
> Datum: Mittwoch, 5. M{rz 1997 12:48
>
> I have just received part of a message about a call for papers but the
> important part is missing. Would you send the message again, please?
>
> Regards,
>
> Niall O'Loughlin
>
>
empty rooms in mental flats - looking for locomotion?
in the last line you find some sources and orientation for this message

maybe a starter for some exchange on the CLUB OF BUDAPEST discussion group 
list !??

                              Heiner BENKING


re: SHARING MENTAL HOMES - a  QUEST for more   MENTAL MOBILITY


here an up-date and maybe a starter in form of a message just needed to 
send 
somewhere

          Heiner Benking

_-_

Dear list members,
I try to bridge two lists, as the topics are too close
and it gets boring always getting a grip or grasp and then letting go..
                                   Heiner

> ----------
> Von: owner-debono
> An: DEBONO
> Betreff: Creativity and Rods & Cones
> Datum: Mittwoch, 7. Mai 1997 11:48
>
>  In a message dated 97-05-06 11:01:15 EDT, you write:
>
> << ... Have you ever noticed how night vision works.  Part of your mind 
picks
> up clear images on the periphery of your line of sight, but when you 
shift
> your focus to where the image was, it loses its definition. I think
> creativity works a little like this:  it occurs on the edge of our line 
of
> sight.  If we're not too focussed on what we're looking at, we notice the
> creative image and try to bring it into focus, but if we persist in 
peering
> straight ahead, we fail to notice that we even "saw" something "off to 
the
> side"... I apologize if this musing is self-indulgent and thank you for 
the
> provocation. >>
>
> Metaphors are the furnishings of our mental home.  Thank you for making a
> very insightful addition to my decor, although I can really only see this
> item peripherally, I guess.
>
> Adam Hansen
> The Generativity Group

 ----------
> Von: list
> An: unis
> Cc: ThomasM451
> Betreff: Re: simple language & Korea
> Datum: Mittwoch, 7. Mai 1997 23:30
>
> In a message dated 97-05-07 16:17:07 EDT, you write:
>
> <<
>  In a message dated 97-05-07 02:07:35 EDT, Tom wrote:
>
>  <<  I admitted up front that I knew nothing about Korea, except that 
they
>   are about to go to war again. What I am asking is not for "ideal"
>  situations, but fundamental situations.  (this is the second time simple 
language has
>   been mistaken for idealistic language, interesting)  The foundation for 
my
>   "fantasy" is simply the principle of a loving relationship - mutual 
synergy.
>
>
>  Hello:
>  If the language of  form requires us to frame a discussion through a
>  particular lense, then we would need to agree to the form/lense 
up-front. 
We
>  would also be able to predict all the unconscious variables that would
> surely  'come up' into our field of awareness, as a result of framing 
such 
a
>  discussion..........and without saying much more its clear to me why 
many
>  theorists state there is no such thing as com-unication, let alone 
'simple
>  language'!
>
>  My admittedlly incomplete appreciation of Stytematics has me feeling 
like 
we
>  are in all the forms at once. .....

_____________________________________________
BEGIN OF MESSAGE:

Hi,

Well I think our mental homes are 'not in order'. We try with precision, 
forcing focus on the specifics, but camouflage the whole' as Steve Kurtz 
once wrote, but not daring to look for the context, the relations and 
connections. As Kant was looking with his carcateristica universalis, i 
call 
it an 'organizing glass' into the inner structure (remember Alice in 
WONDERLAND) we can at least build a conceptual house of knowledge, beyond 
languages, if we restrict ourselves !!  to the general overview, the birds 
eye.
The result is that we can suddenly see and get awe as we grasp how little 
we 
know !! See wholeness and worldview discussion and the recent work on:
Inviting and Sharing VIEWS, thoughts, adn Voices (available on request).

I think this focussing on words, as some lists do, can work in coherent 
groups, but the moment you jump over the fence, you are lost, as the 
NOMINALISTS, go for 'exact words' their code, in a hierarchical order, 
knowledge trees. My position is absolutely to the contrary, I am a 
CONCEPTUALIST, looking for 'concepts in their context' and try to move, 
merge and transform along and across scales.

We have, if we ever want to bridge 'schools' and mental territories have to 
see the deeper connections. The mind's eye pondering above shows the way!

I would like to show that Einstein was pondering also about words:

The word or the language, written or spoken,
do not seem to have any impact (role)
in the mechanism of my line of thought.
The mental building blocks of thinking
are certain signs/symbols and more or less clear pictures,
which can be reproduced and combined at will (according desire/wish?)

                              Albert Einstein

maybe someone can help with the best words !?? as I only have a German 
version:

               Das Wort oder die Sprache, geschrieben oder gesprochen,
               scheinen im Mechanismus meines Gedankenablaufes
               }berhaupt keine Rolle zu spielen.
               Die psychischen Grundelemente des Denkens
               sind bestimmte Zeichen und mehr oder weniger klare Bilder,
               die  nach Wunsch  reproduziert und kombiniert werden k|nnen.

                              Albert Einstein


I would like to sum up by saying that I profit most by learning the style 
and the class of the different lists, my English is not good enough to 
discuss with any one of you 'seriously' (I appreciate the braod wandwith 
personal aprach anyway!)

but I can tell you that we are all very close, but are typically not aware 
of it, all living in our private MENTAL HOMES, in cocoons, and ponder about 
details...

As I like to share and feel that I live in some mental homes in parallel 
(my 
cognitive panorama) you are most welcome to visit and move in...

warmely

Heiner
http://www.uia.org/uiadocs/spatialm.htm
http://www.newciv.org/ISSS_Primer/seminrva.html
http://heri.cicv.fr/council/speeches/benkingtxt.html
http://aztlan.mty.itesm.mx/budapest/view/vl002p03.htm




+



From rem-conf Fri May 09 05:38:51 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 05:38:51 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPowW-0003dX-00; Fri, 9 May 1997 05:38:36 -0700
Date: Fri, 9 May 1997 08:37:12 -0400 (EDT)
From: Bernie Doehner <bad@uhf.wireless.net>
To: rmt@maine.edu
cc: sliberz@ladl.jussieu.fr, rem-conf@es.net
Subject: Unidentified subject! - wrong mailing list??
Message-ID: <Pine.BSF.3.95.970509083334.9821A-100000@uhf.wdc.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Excuse me rmt, but what do lists:

2IN97@prism.uvsq.fr, congres@prism.uvsq.fr

have to do with rem-conf@es.net?

I remmember quite well subscribing to this to rem-conf. I NEVER subscribed
to these other two lists and have no idea what they are, nor how to
unsubscribe, nor should I have to worry about how one unsubscribes.

/bad


---------- Forwarded message ----------
Date: Fri, 9 May 1997 14:09:47 +0100
From: silberz@ladl.jussieu.fr
To: rem-conf@tmpmail.es.net
Subject: Unidentified subject!

>From silberz Fri May  9 14:09:45 1997
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
Received: by NeXT.Mailer (1.118.2.RR)
From: Max Silberztein <silberz>
Date: Fri,  9 May 97 14:09:45 +0100
To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
Subject: REMOVE
References: <199705091148.NAA02310@teco11a.teco.uni-karlsruhe.de>

Please remove me from the mailing-list NOW.
I never asked to get into it.





From rem-conf Fri May 09 07:03:21 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 07:03:21 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPqBZ-0004VC-00; Fri, 9 May 1997 06:58:13 -0700
Message-Id: <199705091230.OAA05441@donald.fokus.gmd.de >
To: Svenn Hanssen <Svenn.Agnar.Hanssen@cc.uit.no>
cc: Joerg Mueller <jpm@zuno.com>, 'Benking Heiner' <BENKING@faw.uni-ulm.de>, 
    2IN97 <2IN97@prism.uvsq.fr>, congres <congres@prism.uvsq.fr>, 
    svenn@cc.uit.no
Subject: Re: 21N97
In-reply-to: Your message of "Fri, 09 May 1997 13:19:40 +0200." <199705091120.NAA16335@mohican.cc.uit.no>
Date: Fri, 09 May 1997 14:30:14 +0200
From: Dorgham Sisalem <sisalem@fokus.gmd.de>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

would the responsible for this list arrange for a seperate way to delete
the peopole from this list. I do not really want to receive all the delete me
messages and surely not the "I concur" ones in reply. I do not know who is responsible for this mess but who ever it is please fix it quickly. I already received more than 15 mails today from this list on which I DID NOT ASK TO GET ON. So 

remove me as well

	Dorgham



From rem-conf Fri May 09 07:11:32 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 07:11:31 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPqNW-0004tu-00; Fri, 9 May 1997 07:10:34 -0700
Date: Fri, 9 May 1997 14:58:11 +0100
From: annemari@mcg.gla.ac.uk (Anne Marie Fleming)
Message-Id: <199705091358.OAA12614@kestrel.mcg.gla.ac.uk>
To: rem-conf@es.net, mbone@ISI.EDU
Subject: JENC8 -multicast
X-Sun-Charset: US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Title: 		JENC8 - 8th Joint European Networking Conference

Dates:  	Monday 12th May until Thursday 15th May 
		For multicast schedule see http://www.mcg.gla.ac.uk/jenc/

Contact:  	annemari@mcg.gla.ac.uk
        
Conference URL: http://www.terena.nl/conf/JENC8.html


Description: 	JENC8  (Edinburgh, Scotland) 

"DIVERSITY AND INTEGRATION: THE NEW EUROPEAN NETWORKING LANDSCAPE"

1997 will mark an important development for the European networking community,
namely the final deregulation steps of much of the European telecommunication
infrastructure. In parallel, Europe is witnessing an explosion of demand for 
network services and innovative distributed applications. 

A large number of corresponding projects and pre-competitive development effortsare currently underway, in order to strengthen the European position in a 
global, competitive and deregulated environment.

In this context, and building on the established tradition of previous JENCs, 
JENC8 will be focused on the effects of these changes and developments for 
researchers, NETWORK AND SERVICE PROVIDERS and commercial users, considering 
technical, economical and political issues, as well as user support, training 
and educational matters.

JENC8 will be THE EUROPEAN FORUM to get up-to-date information, to debate and 
assess the new deregulated telecommunication environment in Europe, new leading-
edge applications, and the network/internetwork support infrastructure which is 
currently being developed.



From rem-conf Fri May 09 07:24:41 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 07:24:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPqZF-0005FJ-00; Fri, 9 May 1997 07:22:41 -0700
Message-Id: <v02110100af98d6dfc938@[130.237.14.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 9 May 1997 15:28:59 +0200
To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
From: bjorn@it.kth.se ( =?iso-8859-1?Q?Bj=F6rn?= Pehrson)
Subject: remove please!
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Could you please remove me from these mailing-lists.









From rem-conf Fri May 09 07:32:31 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 07:32:30 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPqiM-0005Xa-00; Fri, 9 May 1997 07:32:06 -0700
From: Nizar.Abdallah@masi.ibp.fr (Nizar ABDALLAH)
Message-Id: <199705091336.PAA04362@cao-vlsi.ibp.fr>
Subject: REMOVE
To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
Date: Fri, 9 May 1997 15:36:23 +0200 (MET DST)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Please Remove me from the mailing list

-- 



From rem-conf Fri May 09 08:49:43 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 08:49:42 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPrnu-0006BR-00; Fri, 9 May 1997 08:41:54 -0700
To: Dorgham Sisalem <sisalem@fokus.gmd.de>, rem-conf-request@tmpmail.es.net, 
    postmaster@prism.uvsq.fr
cc: 2IN97@prism.uvsq.fr, rem-conf@es.net
Reply-To: hks@nic.funet.fi
Subject: Re: 21N97
In-reply-to: Your message of Fri, 09 May 1997 14:30:14 +0200. <199705091230.OAA05441@donald.fokus.gmd.de>
Date: Fri, 09 May 1997 18:41:09 +0300
From: Harri Salminen <hks@nic.funet.fi>
Message-Id: <19970509154114Z562-508+179@nic.funet.fi>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


DON'T PANIC

as they say in the Hitchhiker's guide to the galaxy... Sending remove
me etc. messages to the mailing lists sometimes might just cause a
self feeding chaos...

To me it seems like somehow two mailing lists have got
connected togerher since there's no mention of the rem-conf list in the
To: or cc: field of the messages and they still come to the list rem-conf.

The mailing list software seems to remove Reveived: headers so it's
hard to say what really happens. It could just be some kind of
error in configuring some list (2IN97 sounds like a mailing list for some
conference to me) or perhaps even a personal mail filter which isn't
helped by these chaotic remove me messages to the list which should go to
the -request address anyway. 

As a public warning I'd like to point out that recently there has been
increased activity by some malicious people who use some kind of
program to subscribe their victims to many open mailing lists at once
with forged addresses. I don't think this is the case with rem-conf
yet though. The only remedy in addition of manually maintaining lists
is to enable a confirmation request feature in LISTSERV or majordomo to
prevent the subscription from succeeding. 

In any case, when you seem to have been added to some mailing list
without your will, PLEASE figure out the address of the list and then
send the offending piece of mail with Received: headers intact to the
listname-request (or owner-listname or postmaster) address and NOT to
the list.  E.g. in this message the -request address can be seen in the
Return-Path: field. 


Harri Salminen
FUNET listserv & MICE-NSC & NIC.FUNET.FI coordinator

Ps. I wonder when we are going to get clashes of two MBONE conferences
accidentally getting same multicast groups and then people shouting
each other out from the group ;-)

> Return-Path: rem-conf-request@tmpmail.es.net
> Received: from NO-IDENT-SERVICE@mail1.es.net (port 26828 [198.128.3.181]) by nic.funet.fi with SMTP id <344-29928>; Fri, 9 May 1997 17:05:14 +0300
> Received: from list by mail1.es.net with local (Exim 1.61 #3)
> 	id 0wPqBZ-0004VC-00; Fri, 9 May 1997 06:58:13 -0700
> Message-Id: <199705091230.OAA05441@donald.fokus.gmd.de>
> To:	Svenn Hanssen <Svenn.Agnar.Hanssen@cc.uit.no>
> cc:	Joerg Mueller <jpm@zuno.com>, 'Benking Heiner' <BENKING@faw.uni-ulm.de>, 2IN97 <2IN97@prism.uvsq.fr>, congres <congres@prism.uvsq.fr>, svenn@cc.uit.no
> Subject: Re: 21N97
> In-reply-to: Your message of "Fri, 09 May 1997 13:19:40 +0200." <199705091120.NAA16335@mohican.cc.uit.no>
> Date:	Fri, 09 May 1997 14:30:14 +0200
> From:	Dorgham Sisalem <sisalem@fokus.gmd.de>
> X-Mailing-List: <rem-conf@tmpmail.es.net> 
> X-Loop: rem-conf@tmpmail.es.net
> Precedence: list
> Return-Path: <rem-conf-request@tmpmail.es.net>
> 
> would the responsible for this list arrange for a seperate way to delete
> the peopole from this list. I do not really want to receive all the delete me
> messages and surely not the "I concur" ones in reply. I do not know who is responsible for this mess but who ever it is please fix it quickly. I already received more than 15 mails today from this list on which I DID NOT ASK TO GET ON. So 
> 
> remove me as well
> 
> 	Dorgham




From rem-conf Fri May 09 09:58:11 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 09:58:10 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPsw1-0006kG-00; Fri, 9 May 1997 09:54:21 -0700
Message-Id: <9705091620.AA27880@w20-575-37.MIT.EDU>
To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
Subject: REMOVE
Date: Fri, 09 May 1997 12:20:49 EDT
From: Shiva Sean Sandy <sssandy@MIT.EDU>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

please remove me form this list
thank you



From rem-conf Fri May 09 10:35:50 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 10:35:50 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPtYh-00078u-00; Fri, 9 May 1997 10:34:19 -0700
Date: Fri, 9 May 1997 19:04:12 +0200 (MET DST)
From: Christer Palm <palm@admin.kth.se>
Reply-To: Christer Palm <palm@admin.kth.se>
To: 2IN97 <2IN97@prism.uvsq.fr>, congres <congres@prism.uvsq.fr>
Subject: REMOVE ME NOW
Message-ID: <Pine.SUN.3.96.970509190242.28325A-100000@othello.admin.kth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Please remove me from the mailing-list. NOW! I never asked to get into it.

--
Christer Palm                          E-mail:      palm@admin.kth.se
Network Manager                        
Technical Services                     Telephone:   +46-8-7907234
Royal Institute of Technology          Mobilephone: 070-5121738
S-100 44 Stockholm (Sweden)            Fax:         +46-8-102510






From rem-conf Fri May 09 10:40:32 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 10:40:31 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPteT-0007OB-00; Fri, 9 May 1997 10:40:17 -0700
Message-ID: <c=US%a=_%p=UTMCK%l=UTMCK_NT_HEN-970509164040Z-13939@msexch1.mc.utk.edu>
From: "Schaffer, Gregory J." <GSchaffe@mc.utk.edu>
To: 'Svenn Hanssen' <Svenn.Agnar.Hanssen@cc.uit.no>, 
    'Dorgham Sisalem' <sisalem@fokus.gmd.de>
Cc: 'Joerg Mueller' <jpm@zuno.com>, 'Benking Heiner' <BENKING@faw.uni-ulm.de>, 
    '2IN97' <2IN97@prism.uvsq.fr>, 'congres' <congres@prism.uvsq.fr>, 
    "'svenn@cc.uit.no'" <svenn@cc.uit.no>
Subject: RE: 21N97
Date: Fri, 9 May 1997 12:40:40 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I second the notion...what is this list about anyway?  

>----------
>From: 	Dorgham Sisalem[SMTP:sisalem@fokus.gmd.de]
>Sent: 	Friday, May 09, 1997 8:30 AM
>To: 	Svenn Hanssen
>Cc: 	Joerg Mueller; 'Benking Heiner'; 2IN97; congres; svenn@cc.uit.no
>Subject: 	Re: 21N97 
>
>would the responsible for this list arrange for a seperate way to delete
>the peopole from this list. I do not really want to receive all the delete me
>messages and surely not the "I concur" ones in reply. I do not know who is
>responsible for this mess but who ever it is please fix it quickly. I already
>received more than 15 mails today from this list on which I DID NOT ASK TO
>GET ON. So 
>
>remove me as well
>
>	Dorgham
>



From rem-conf Fri May 09 10:49:33 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 10:49:33 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPtk5-0007d9-00; Fri, 9 May 1997 10:46:05 -0700
Message-ID: <1B2056104081CF11914400805F68CC1704123C25@RED-05-MSG.dns.microsoft.com>
From: Karoly Somogyvari <karolys@MICROSOFT.com>
To: "'2IN97@prism.uvsq.fr'" <2IN97@prism.uvsq.fr>, 
    "'congres@prism.uvsq.fr'" <congres@prism.uvsq.fr>, 
    "'BENKING@faw.uni-ulm.de'" <BENKING@faw.uni-ulm.de>
Subject: RE: REMOVE
Date: Fri, 9 May 1997 10:04:26 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

My impression is that someone has played a little game with these
mailing lists last night. (I never wanted to be on these lists either.)
I think the owners of the lists should remove everybody from the list
who has been added during the last day.


> -----Original Message-----
> From:	Kevin Dunlap [SMTP:KevinD@metainfo.com]
> Sent:	Friday, May 09, 1997 8:19 AM
> To:	'2IN97@prism.uvsq.fr'; 'congres@prism.uvsq.fr';
> 'BENKING@faw.uni-ulm.de'
> Subject:	RE: REMOVE
> 
> Remove the IETF mailing list from these other mailing lists.
> 
> -Kevin
> 
> 
> >-----Original Message-----
> >From:	Hans-Werner Gellersen [SMTP:hwg@teco.uni-karlsruhe.de]
> >Sent:	Friday, May 09, 1997 4:48 AM
> >To:	2IN97@prism.uvsq.fr; congres@prism.uvsq.fr;
> BENKING@faw.uni-ulm.de
> >Subject:	Re: REMOVE
> >
> >Please remove me from the mailing-list NOW.
> >I never asked to get into it.



From rem-conf Fri May 09 10:52:14 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 10:52:14 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPtne-0007g3-00; Fri, 9 May 1997 10:49:46 -0700
From: adam@research.bell-labs.com
Message-Id: <199705091628.SAA08081@shiva.jussieu.fr>
Date: Fri, 9 May 97 12:07 EDT
To: 2IN97@prism.uvsq.fr, BENKING@faw.uni-ulm.de, congres@prism.uvsq.fr
Subject: Unidentified subject!
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Subject: REMOVE

REMOVE

ASAP!




From rem-conf Fri May 09 10:56:41 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 10:56:41 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPtss-0000LE-00; Fri, 9 May 1997 10:55:10 -0700
Date: Fri, 09 May 1997 12:25:34 -0500 (EST)
From: PRCHOP@qucdnee.ee.queensu.ca
Subject: REMOVE
To: congres@prism.uvsq.fr
Message-id: <01IINZ3U9NMW9FM72C@qucdnee.ee.QueensU.CA>
Old-X-Envelope-to: congres@prism.uvsq.FR
X-VMS-To: IN%"congres@prism.uvsq.FR"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	Please remove me from your mailing list.



From rem-conf Fri May 09 11:03:58 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 11:03:58 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPtzC-0000bU-00; Fri, 9 May 1997 11:01:42 -0700
Sender: explorer@kechara.flame.org
To: Joerg Mueller <jpm@zuno.com>
Cc: 'Benking Heiner' <BENKING@faw.uni-ulm.de>, 2IN97 <2IN97@prism.uvsq.fr>, 
    congres <congres@prism.uvsq.fr>, postmaster@prism.uvsq.fr
Subject: Re: 21N97
References: <01BC5C6D.59268AA0@indus.dlib.com>
From: Michael Graff <explorer@flame.org>
Date: 09 May 1997 12:26:58 -0400
In-Reply-To: Joerg Mueller's message of Fri, 9 May 1997 11:37:16 +0100
Message-ID: <v6g1vwboh9.fsf@kechara.flame.org>
Lines: 15
X-Mailer: Gnus v5.4.37/Emacs 19.34
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Joerg Mueller <jpm@zuno.com> writes:

> whoever is responsible for this list, PLEASE remove me from it.
> I am not interested at all in receiving that crap.

It appears someone is an idiot and added tcplw@bsdi.com to some other
list.

This was in the header:

Return-Path: <tcplw-relay@external.BSDI.COM>

Someone fix this, please!

--Michael



From rem-conf Fri May 09 11:10:18 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 11:10:18 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPu7F-0000v5-00; Fri, 9 May 1997 11:10:01 -0700
From: Lisa Guo <lguo@cube.engr.sgi.com>
Message-Id: <9705090947.ZM3728@cube.engr.sgi.com>
Date: Fri, 9 May 1997 09:47:34 -0700
In-Reply-To: Joerg Mueller <jpm@zuno.com> "RE: 21N97" (May 9, 11:37am)
References: <01BC5C6D.59268AA0@indus.dlib.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: 'Benking Heiner' <BENKING@faw.uni-ulm.de>, 2IN97 <2IN97@prism.uvsq.fr>, 
    congres <congres@prism.uvsq.fr>
Subject: Re: 21N97
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Please remove me from the list.

Lisa



From rem-conf Fri May 09 11:18:49 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 11:18:49 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPuEX-0001DO-00; Fri, 9 May 1997 11:17:33 -0700
Message-ID: <c=US%a=_%p=FCG%l=FCGMAIL4-970509164044Z-15273@fcgmail4.fcgnet.com>
From: "Kern, Mark" <mkern@fcgnet.com>
To: "'2IN97@prism.uvsq.fr'" <2IN97@prism.uvsq.fr>, 
    "'congres@prism.uvsq.fr'" <congres@prism.uvsq.fr>, 
    "'BENKING@faw.uni-ulm.de'" <BENKING@faw.uni-ulm.de>
Subject: remove
Date: Fri, 9 May 1997 09:40:44 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

for those of you who are in the same boat I am in, and did not subscribe
to this list, I would recommend doing what I am now doing and send your
removal requests to root@prism.uvsq.fr and root@faw.uni-ulm.de and
hopefully those admins will become annoyed enough to remove us.



From rem-conf Fri May 09 11:19:56 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 11:19:56 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPuGk-0001O6-00; Fri, 9 May 1997 11:19:50 -0700
Date: Fri, 9 May 1997 11:49:49 -0400
From: debbie@bellcore.com (Deborah G Schmitt)
Message-Id: <199705091549.LAA20790@hip7.bellcore.com>
To: 2IN97@prism.uvsq.fr, BENKING@faw.uni-ulm.de, bjorn@it.kth.se, 
    congres@prism.uvsq.fr
Subject: Re: remove please!
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Please remove me as well..




From rem-conf Fri May 09 11:24:34 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 11:24:34 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPuKs-0001lY-00; Fri, 9 May 1997 11:24:06 -0700
Date: Fri, 9 May 1997 13:24:04 -0500
Message-Id: <199705091824.NAA23277@achilles.ctd.anl.gov>
To: rem-conf@es.net
Subject: Re: remove
From: "Jeffrey S. Curtis" <curtis@anl.gov>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

}for those of you who are in the same boat I am in, and did not subscribe
}to this list, I would recommend doing what I am now doing and send your
}removal requests to root@prism.uvsq.fr and root@faw.uni-ulm.de and
}hopefully those admins will become annoyed enough to remove us.

It's awfully hard to remove yourself from a list that you're not on.

Free clue #1 to everyone who keeps sending these annoying "remove me
>from this list!" messages: learn how to read mail headers! If your
MUA strips them, get a new MUA!

Free clue #2: you shouldn't ever send such a request to the list
itself anyway.

You all have two choices if you want to get off the "2IN97" et al.
mailing lists.  You can either figure out who's in charge of that
list and tell him/her to remove rem-conf and other lists from
their list, or you can unsubscribe from rem-conf itself (and please
go reread clue #2 above before flooding rem-conf with more
unsubscribe requests).

Jeff
-- 
Jeffrey S. Curtis                      | Internetwork Manager
Argonne National Laboratory            | Email: curtis@anl.gov
9700 South Cass Avenue, ECT-221        | Voice: 630/252-1789
Argonne, IL 60439                      | Fax:   630/252-9689



From rem-conf Fri May 09 11:30:50 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 11:30:50 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPuQ2-00022s-00; Fri, 9 May 1997 11:29:26 -0700
Date: Fri, 9 May 1997 12:29:29 -0400 (EDT)
From: Robert E Lamm <cync@world.std.com>
To: Dorgham Sisalem <sisalem@fokus.gmd.de>
Cc: Svenn Hanssen <Svenn.Agnar.Hanssen@cc.uit.no>, Joerg Mueller <jpm@zuno.com>, 
    'Benking Heiner' <BENKING@faw.uni-ulm.de>, 2IN97 <2IN97@prism.uvsq.fr>, 
    congres <congres@prism.uvsq.fr>, svenn@cc.uit.no
Subject: Re: 21N97
In-Reply-To: <199705091230.OAA05441@donald.fokus.gmd.de >
Message-Id: <Pine.SGI.3.95.970509122903.16687E-100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


What is this list about?


-Bob Lamm
 CYNC Corp.
 Brookline, MA USA

On Fri, 9 May 1997, Dorgham Sisalem wrote:

> would the responsible for this list arrange for a seperate way to delete
> the peopole from this list. I do not really want to receive all the delete me
> messages and surely not the "I concur" ones in reply. I do not know who is responsible for this mess but who ever it is please fix it quickly. I already received more than 15 mails today from this list on which I DID NOT ASK TO GET ON. So 
> 
> remove me as well
> 
> 	Dorgham
> 




From rem-conf Fri May 09 12:00:04 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 12:00:04 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPus1-0002V6-00; Fri, 9 May 1997 11:58:21 -0700
Message-ID: <01BC5C91.E411DB00@apocalypse.teleeducation.nb.ca>
From: Dwight Spencer <spencer@teleeducation.nb.ca>
To: "'Kern, Mark'" <mkern@fcgnet.com>, 
    "'2IN97@prism.uvsq.fr'" <2IN97@prism.uvsq.fr>, 
    "'congres@prism.uvsq.fr'" <congres@prism.uvsq.fr>, 
    "'BENKING@faw.uni-ulm.de'" <BENKING@faw.uni-ulm.de>
Cc: "'rem-conf@es.net'" <rem-conf@es.net>
Subject: RE: remove
Date: Fri, 9 May 1997 15:58:50 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Folks, by now the list owners and system admins know there is a
problem, and are working to fix it, now please, stop posting
all these "remove me too" messages long enough for the maintainers
to try to find out what happened and clean up the lists.

dwight s.  (originally only on rem-conf@es.net)
==
dwight spencer				phone:  506 444 5389
internet services manager			fax:    506 444 4232
spencer@teleeducation.nb.ca

TeleEducation NB, 500 Beaverbrook Court,
Fredericton, NB, Canada, E3B 5H1

-----Original Message-----
From:	Kern, Mark [SMTP:mkern@fcgnet.com]
Sent:	Friday, May 09, 1997 1:41 PM
To:	'2IN97@prism.uvsq.fr'; 'congres@prism.uvsq.fr'; 'BENKING@faw.uni-ulm.de'
Subject:	remove

for those of you who are in the same boat I am in, and did not subscribe
to this list, I would recommend doing what I am now doing and send your
removal requests to root@prism.uvsq.fr and root@faw.uni-ulm.de and
hopefully those admins will become annoyed enough to remove us.





From rem-conf Fri May 09 12:35:56 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 12:35:56 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPvQH-00034B-00; Fri, 9 May 1997 12:33:45 -0700
From: Joe Metzger <metzger@scl.ameslab.gov>
Message-Id: <9705091433.ZM20131@ender.scl.ameslab.gov>
Date: Fri, 9 May 1997 14:33:37 -0500
Organization: ESnet
X-Phone: (515)294-1939
X-Fax: (515)294-4491
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: rem-conf@es.net
Subject: Recent Mailing list problems.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hello,
I am one of the Postmasters at ES.net responsible for the REM-CONF
mailing list.  As you all are aware, somebody has subscribed rem-conf to
at least one other list.  This has caused a flurry of email that is
annoying lots of people.

WHAT I HAVE DONE:
-----------------
I have send mail to root, postmaster, list-request & list for the 21N97
list.  This list appears to be hosted in France and it is Friday night.
 It does not appear to be an automated list. Therefore, I don't expect to
any responses until next Monday.

I will also be implementing a filter so I can easily black list sites and
prevent them from submitting messages to rem-conf (If I ever finish
reading email about this problem).

What YOU SHOULD DO:
-------------------
NOTHING!  I have received over a hundred complaints, suggestions and
poorly formed unsubscribe requests today already.  Several of people have
sent unsubscribe requests, suggestions on how to solve the problem etc.
to the list as well.  I would ask for your patience and for you to just
delete extranious rem-conf mail for today and Monday.


Current Status of rem-conf:
Rem-conf currently has about 1157 subscribers at ESnet.  Of those at
least 80 are links to other rem-conf exploders at other sites.  I suspect
the actual number of receipents is between 1500 and 2000 people.

Rem-conf was a manually maintained list up until a month or so ago.  Now
it is running on a modified version of the Smartlist mailing list
package. If you want to unsubscribe, please send a single message to
rem-conf@es.net with a subject line of "unsubscribe" or with a single
body line of "unsubscribe your@email.address".

There is now a digested version of rem-conf available.  The digested list
is sent out about once a week (sooner if there is lots of activity).  The
digest contains a list of the subjects of this weeks messages and Mime
attached versions of all the messages.  If you want to subscribe to the
digested list send a message to rem-conf-digest-request@es.net.  The
subject or body of the message should contain:
"subscribe your@email.address".


*************************************************************************
* Joe Metzger                          Ames Office: (515)294-1939       *
* Computer Systems Engineer            LBNL Office: (510)486-5740       *
* Network Information Services Group   metzger@es.net                   *
* ESnet, Lawrence Berkeley Laboratory  314 Wilhelm, ISU, Ames IA, 50011 *
*************************************************************************



From rem-conf Fri May 09 14:01:23 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 14:01:23 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPwkI-0003y3-00; Fri, 9 May 1997 13:58:30 -0700
Message-Id: <9705092058.AA03420@merckx.graphics.cornell.edu>
From: Hurf Sheldon <hurf@graphics.cornell.edu>
Subject: Question re:PHC show @ Cornell
To: sysadms@cornell.edu, rem-conf@tmpmail.es.net
Date: Fri, 9 May 1997 16:58:23 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length:        381
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Folks,
Sent by a friend, it is a good question - I assume NPR would
NOT want this done but who knows for sure?

> 	Is Cornell planning on doing a webcast of the Prarie Home
> Companion?  It might be a first.  Or some sort of Cu-SeeMe thing?  After
> all,  this being a supercomputing- leading-edge facility at an institution
> which has made this area  known around the world.
> 




From rem-conf Fri May 09 15:38:15 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 15:38:15 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPyEU-0004ip-00; Fri, 9 May 1997 15:33:46 -0700
Date: Fri, 9 May 1997 14:10:33 +0200 (MET DST)
From: Rogelio Lozano <Rogelio.Lozano@hds.utc.fr>
Message-Id: <199705091210.OAA02224@asterix.gi.utc>
To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de, 
    adida@masi.ibp.fr
Subject: Re: REMOVE
X-Sun-Charset: US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



Whoever is (i)rresponsible for the list

Please remove me from the list. And please do not create lists
like that adding e-mail addresses at random. It make us all losse
precious time.

Rogelio Lozano




> From 2in97@prism.uvsq.fr Fri May  9 13:23 MET 1997
> Sender: Yoan.Adida@masi.ibp.fr
> Date: Fri, 09 May 1997 13:11:59 +0200
> From: Yoan ADIDA <adida@masi.ibp.fr>
> X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.1.23 i586)
> MIME-Version: 1.0
> To: 2IN97@prism.uvsq.fr, congres@prism.uvsq.fr, BENKING@faw.uni-ulm.de
> Subject: REMOVE 
> X-Priority: 3 (Normal)
> Content-Transfer-Encoding: 7bit
> 
> Hi,
> 
> could you please remove me from the mailing-list.
> 
> I never asked to get into it.
> 
> -- 
> Adida Yoan
> 
> 	"Honni soit qui manigance , bien mal acquis ne profite qu'apres"
> 			-- Coluche
> 



From rem-conf Fri May 09 15:50:54 1997 
From rem-conf-request@tmpmail.es.net Fri May 09 15:50:53 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wPyUE-000531-00; Fri, 9 May 1997 15:50:02 -0700
Message-ID: <c=US%a=_%p=MetaInfo%l=LEGO-970509151922Z-1532@lego.metainfo.com>
From: Kevin Dunlap <KevinD@MetaInfo.com>
To: "'2IN97@prism.uvsq.fr'" <2IN97@prism.uvsq.fr>, 
    "'congres@prism.uvsq.fr'" <congres@prism.uvsq.fr>, 
    "'BENKING@faw.uni-ulm.de'" <BENKING@faw.uni-ulm.de>
Subject: RE: REMOVE
Date: Fri, 9 May 1997 08:19:22 -0700
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
Encoding: 13 TEXT
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Remove the IETF mailing list from these other mailing lists.

-Kevin


>-----Original Message-----
>From:	Hans-Werner Gellersen [SMTP:hwg@teco.uni-karlsruhe.de]
>Sent:	Friday, May 09, 1997 4:48 AM
>To:	2IN97@prism.uvsq.fr; congres@prism.uvsq.fr; BENKING@faw.uni-ulm.de
>Subject:	Re: REMOVE
>
>Please remove me from the mailing-list NOW.
>I never asked to get into it.



From rem-conf Sat May 10 10:47:36 1997 
From rem-conf-request@tmpmail.es.net Sat May 10 10:47:35 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wQG7m-0003U5-00; Sat, 10 May 1997 10:40:02 -0700
Date: Sat, 10 May 1997 13:39:42 -0400
From: rodgers@nlm.nih.gov (R. P. C. Rodgers)
Message-Id: <199705101739.NAA11725@billings.csb>
To: sysadms@cornell.edu, rem-conf@tmpmail.es.net, hurf@graphics.cornell.edu
Subject: Re: Question re:PHC show @ Cornell
X-Sun-Charset: US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


> From hurf@graphics.cornell.edu Fri May  9 17:04:13 1997
> From: Hurf Sheldon <hurf@graphics.cornell.edu>
> 
> Folks,
> Sent by a friend, it is a good question - I assume NPR would
> NOT want this done but who knows for sure?
> 
> > 	Is Cornell planning on doing a webcast of the Prarie Home
> > Companion?  It might be a first.  Or some sort of Cu-SeeMe thing?  After

Actually, NPR probably couldn't care less.  Prairie Home Companion
comes from not from NPR but from PRI (Public Radio International).



From rem-conf Mon May 12 08:13:31 1997 
From rem-conf-request@tmpmail.es.net Mon May 12 08:13:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wQwSB-0004ey-00; Mon, 12 May 1997 07:51:55 -0700
From: anand@ece.iisc.ernet.in (SVR Anand)
Message-Id: <9705121451.AA03509@ece.iisc.ernet.in>
Subject: AGC, echo cancellation in VAT
To: rem-conf@es.net
Date: Mon, 12 May 97 20:21:14 GMT+5:30
X-Mailer: ELM [version 2.3 PL11]
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi,

	Can someone give me references on the theoretical aspects of the VAT's
implementation that deals with audio echo cancellation, and AGC ?

Thanks.

Regards
Anand.




From rem-conf Tue May 13 12:15:05 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 12:15:04 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRMoG-0002Ed-00; Tue, 13 May 1997 12:00:28 -0700
Date: Tue, 13 May 1997 14:59:13 -0400 (EDT)
From: Russell Doyen <rdoyen@epfl2.epflbalto.org>
To: rem-conf@tmpmail.es.net
Subject: Mbone newbie help
Message-Id: <Pine.SV4.3.91.970513143134.27015A-100000@epfl2>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 1902
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Greetings,

     I was asked to setup an mbone session for JENC8 in Edinburgh.  I 
have never setup an mbone session before, so I have been poking around 
the www.mbone.com pages, and subscribed to mbone-na and rem-conf lists.

     I have the Win95 version of VIC.  I have 24 Ascend 4004, 4000, and 
1600 routers.  Lots of PL50's and PL75's too.  I also have several SUN 
1000's, 20's, and 5's.  The SUN's are on the current Solaris with patches.

     I set one of my routers for Multicast.Forwarding=yes.  I don't have 
the info for a Multicast Profile= ???.  I don't have another router to 
point to for the multicast.  Can someone tell me how to get this router 
on the mbone backbone?

     My routers are the backbone routers for all the libraries in 
Maryland, and some of the K-12 and community colleges.  I think many of 
my users would appreciate access to the mbone.

     Can someone give me the IP/Port for the Win95 software to point to?

     I appreciate any help with this.

     This is a traceroute from one of my systems to Yahoo for info as to 
my placement on the Internet:

traceroute to www.yahoo.com (204.71.177.72), 30 hops max, 0 byte packets
 1  epfl-cisco.epflbalto.org (192.188.199.1)  0 ms  0 ms  0 ms
 2  baltimore-cr1.bbnplanet.net (192.221.74.65)  20 ms  0 ms  10 ms
 3  baltimore1-cr1.bbnplanet.net (4.0.250.129)  10 ms  10 ms  0 ms
 4  washdc1-br2.bbnplanet.net (4.0.2.53)  10 ms  10 ms  10 ms
 5  washdc1-br1.bbnplanet.net (4.0.2.125)  10 ms  0 ms  10 ms
 6  core6-hssi6-0.Washington.mci.net (206.157.77.217)  30 ms  30 ms  30 ms
 7  bordercore2-loopback.Bloomington.mci.net (166.48.176.1)  70 ms  70 
ms  70 ms
 8  internet-connection.Bloomington.mci.net (166.48.177.254)  90 ms  80 
ms  100
ms
 9  core1-fe4-0.MV.isi.net (206.251.1.1)  100 ms  100 ms  110 ms
10  www7.yahoo.com (204.71.177.72)  90 ms  100 ms  90 ms      

Russell Doyen
Sailor Network Engineer




From rem-conf Tue May 13 13:27:11 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 13:27:11 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRO6E-0002nM-00; Tue, 13 May 1997 13:23:06 -0700
Message-ID: <01BC5FA0.D148B360@titanium>
From: Jason Coombs <jasonc@science.org>
To: "'Hurf Sheldon'" <hurf@graphics.cornell.edu>
Cc: "rem-conf@tmpmail.es.net" <rem-conf@tmpmail.es.net>
Subject: RE: Question re:PHC show @ Cornell
Date: Tue, 13 May 1997 13:23:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Greetings.

Go to: http://www.mpr.org

Minnesota Public Radio is the producer of A Prairie Home Companion
and you'll find what you're looking for on their Web site.

Regards,

Jason Coombs
Scientist, SCIENCE.ORG
http://www.science.org/jasonc/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAzH47i4AAAEEAKjzazn04nZvnPQo/Rj+O026OyDi6kw6Rvl13YcfjgiaE76t
qU0COmWDpDLtDgrYSosDRwFdIPJuo4esXhUfgpWFEF2BXTqO+r9sKV9A3VBKGP3A
wXMhcSZH7PQR96KMPlLEl/DoQa9KfcUPfb3stf2UfNrOmaYyZEfm6QRcLcyhAAUR
tCFKYXNvbiBDb29tYnMgPGphc29uY0BzY2llbmNlLm9yZz6JAJUDBRAx+O6bR+bp
BFwtzKEBARp0A/wKb3WAhILkc30bOhvxrMab50iUYWPQaJObrBpQc3CsbCartFZe
Xf5LStYtBrjXNlW+r0yJVn0ETE3MHDLE2wEWGiuEIpGcXYMaigajxAI+RuIxdK5c
Xx4BM/7vKIhvFHEHvBKVP35xeJK2r9lAa0RQGp05I3t81T9EuumBg/StrA==
=aUAR
-----END PGP PUBLIC KEY BLOCK-----

-----Original Message-----
From:	Hurf Sheldon [SMTP:hurf@graphics.cornell.edu]
Sent:	Friday, May 09, 1997 1:58 PM
To:	sysadms@cornell.edu; rem-conf@tmpmail.es.net
Subject:	Question re:PHC show @ Cornell

Folks,
Sent by a friend, it is a good question - I assume NPR would
NOT want this done but who knows for sure?

> 	Is Cornell planning on doing a webcast of the Prarie Home
> Companion?  It might be a first.  Or some sort of Cu-SeeMe thing?  After
> all,  this being a supercomputing- leading-edge facility at an institution
> which has made this area  known around the world.
> 






From rem-conf Tue May 13 13:41:36 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 13:41:36 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wROKU-0003AA-00; Tue, 13 May 1997 13:37:50 -0700
From: John Hawkinson <jhawk@bbnplanet.com>
Message-Id: <199705132037.QAA18955@all-purpose-gunk.near.net>
Subject: Re: Mbone newbie help
To: rdoyen@epfl2.epflbalto.org (Russell Doyen)
Date: Tue, 13 May 1997 16:37:34 -0400 (EDT)
Cc: rem-conf@es.net
In-Reply-To: <Pine.SV4.3.91.970513143134.27015A-100000@epfl2> from "Russell Doyen" at May 13, 97 02:59:13 pm
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: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

>      I have the Win95 version of VIC.  I have 24 Ascend 4004, 4000, and 
> 1600 routers.  Lots of PL50's and PL75's too.  I also have several SUN 
> 1000's, 20's, and 5's.  The SUN's are on the current Solaris with patches.
> 
>      I set one of my routers for Multicast.Forwarding=yes.  I don't have 
> the info for a Multicast Profile= ???.  I don't have another router to 
> point to for the multicast.  Can someone tell me how to get this router 
> on the mbone backbone?

I don't know anything about Ascend's multicast configuration -- in
order for you to connect to the MBone, however, you need to
get in touch with your ISP and get an MBone tunnel -- thus,
you should send mail to mbone@bbnplanet.com.

You'll need to terminate this tunnel in something -- presumably
you'd like to do so in one of your Ascends, but you may need
to check with them to see if that is even possible (?). If not,
you can run mrouted on one of your Solaris machines.

--jhawk



From rem-conf Tue May 13 17:47:13 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 17:47:12 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRSAM-0004MO-00; Tue, 13 May 1997 17:43:38 -0700
Date: Tue, 13 May 1997 20:43:34 -0400 (EDT)
From: kevin@cc.gatech.edu (Kevin C. Almeroth)
Message-Id: <199705140043.UAA19651@flora.cc.gatech.edu>
To: rem-conf@es.net
Subject: IETF and IMJ
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


   Just a quick announcement that I've started to add some of the Memphis
IETF sessions to the IMJ.  Right now I've got the two AVT sessions, and the 
Multicast WWW BOF.  Also, there is a whole new set of Turner content.

   I'm planning to add most of the rest of the IETF sessions that were
recorded by Evi Nemeth (thanks Evi!!!) but not for a couple days since
I'm out of town.  If anyone has anything in particular that they would
like to see ASAP, send me mail and I'll give it priority when I get back.

   I've included the original IMJ announcement just in case there is
anybody out there who hasn't heard about it.  :-)

-Kevin Almeroth


---------------------------------------------------------------------------
              Announcing the Interactive Multimedia Jukebox


   At one point on the MBone list there was a discussion of what on-demand
servers exist or are being developed.  Well, I'd like to announce our 
version called the Interactive Multimedia Jukebox (IMJ).

  The IMJ web page is a request and scheduling interface for the playout 
of content over the MBone.  CONTENT IS ENCODED SO THAT IT CAN BE RECEIVED
WITH THE LATEST VERSIONS OF VIC AND VAT (ANY PLATFORM).

   The IMJ page is located at http://imj.gatech.edu.  Information about 
the IMJ including general info, a postscript version of a paper about the 
IMJ, how-to-use information, and how it was implemented can be found at 
http://www.cc.gatech.edu/computing/Telecomm/IMJ/.

   Some quick additional information about the IMJ is included below:


IMJ Audio/Video
-----------------
   The IMJ uses the WWW to submit requests which are then scheduled
for playout on the MBone.  Right now we are offering three channels:
Channels 1 and 2 are being broadcast at a TTL of 127.  Channel 3 is
for internal testing and has a a TTL of 15.  Each channel provides 
DVI-2 audio and 128 Kbps H.261 video.  The encoding was done using 
Henning Schulzrinne's rtpplay and rtpdump.

Scheduling
----------
   Program scheduling uses a set of criteria to decide on which channel
to schedule a program.  The current set of criteria are listed just
below the interactive schedule.  We are exploring lots of different
options.

Content
-------
   We have been working on the jukebox paradigm with Turner Broadcasting,
and as a result of their interest they have agreed to let us broadcast
content on the MBone.  I am particularly excited about this aspect because
of their help and interest in investigating new applications on the Internet.

   The plan is to add a new set of content about every two weeks.  When this 
happens, the old content will be moved to the secondary request menu for two 
weeks.  The old-old stuff will be removed.  Hopefully I'll be able to 
advertise on the MBone list when the new stuff is available.

Development Platform
--------------------
   As is mentioned in the paper on the IMJ information page we are using
the IMJ as a platform for a variety of research issues including
providing interactivity, supporting multiple heterogeneous streams,
video server organization, tracking usage, program scheduling, and
pricing.

Acknowledgments
----------------
   In addition to Turner Broadcasting, several other groups have made the
IMJ possible.  The GT Broadband Telecommunications Center sponsored much 
of the research and some of the equipment, and GT Office of Information 
Technology offered technical assistance and additional equipment.


Please send me any feedback or suggestions.  Thanks.

-Kevin Almeroth




From rem-conf Tue May 13 19:48:28 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 19:48:26 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRU2f-0004uL-00; Tue, 13 May 1997 19:43:49 -0700
Date: Tue, 13 May 1997 19:29:19 -0700 ()
From: Stephen Casner <casner@precept.com>
To: rem-conf@es.net
cc: Fred Baker <fred@cisco.com>
Subject: Real-Time Transport Protocol MIB Review
Message-ID: <Pine.WNT.3.95.970513192349.-352951L-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Fred Baker has graciously assisted the AVT working group by reviewing
the RTP MIB.  Per his request below, I am forwarding his review to the
WG mailing list.  My reply will be in a message to follow.

							-- Steve

Date: Mon, 5 May 1997 09:20:18 -0700
From: Fred Baker <fred@cisco.com>
Subject: Real-Time Transport Protocol MIB Review

On behalf of the Network Management Directorate, I am looking at

>                  Real-Time Transport Protocol
>                  Management Information Base
>                <draft-ietf-avt-rtp-mib-00.txt>
>
>                         March 24, 1997
> managing Real-Time Transport Protocol Systems [1].  Comments
> should be made to the IETF Audio/Video Transport Working Group.

First comment: I was unable to determine from the internet draft what
mailing list comments on this MIB should go to (it is the AVT WG, but the
mailto URL is not in the document). Please forward these comments to the
relevant list.

Second comment: I note that three authors are listed on the draft, but only
one in each of the two MODULE-IDENTITY statements. It's up to you, but I
should think you'd want all three listed, as compilable schemas generally
omit the RFC from which the MIB is extracted.

> 4.1.1  An "RTP Session" is defined by an IP address and a pair of
> transport-layer port numbers, this is a "Session Address".  There
> is one Session Address for a multicast session and two for unicast.

If it uses port numbers, it seems to me that it should use both IP
Addresses; if not both IP Addresses, then it should not be both ports. The
port number is essentially as extention of the IP Address to identify a
process (perhaps a listening process).

>4.1.2 An "RTP Data Stream" is a sequence of packets sent to the
>even-numbered port of the RTP Session when UDP is used to transport
>the RTP data. Data streams are uniquely identified within an RTP
>Session by "SSRC" attributes.

And what on God's green earth might an SSRC be? Is there a reference,
perhaps, that defines this term? Would this by the Synchronization Source
Identifier described (not very well) in draft-rao-rtsp-00.txt? And tell me,
is it more understandable to say "SSRC Attribute" or "Synchronization
Source Identifier."? You might reference section 3.2, Set Transport, of
that document, where SSRC is defined in this manner:

	SSRC: 32 bits

	Identifies the synchronization source to be associated with the
	data. This can be used for de-multiplexing by the client of data
	received on the same port.

> The attribute, state and statistical information of the components
> described in section 4.1 compose the column objects of the tables.
> Since there are 1:N mappings between some of the components, a
> more structured and efficient representation would create separate
> tables for some of the components, such as a Session table, and this
> would make some streams table columns redundant (i.e., obtainable
> through a join).  The two-table model is proposed here for the sake
> of simplicity in the management entity and management application.

>         rtpEgSentPackets OBJECT-TYPE
>                 SYNTAX          Counter32
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Count statistic of packets sent from this SSRC."
>                 ::= { rtpEgEntry 6}
>
>         rtpEgSentOctets OBJECT-TYPE
>                 SYNTAX          Counter32
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Count statistic of octets sent from this SSRC."
>                 ::= { rtpEgEntry 7 }

Wouldn't it be simpler/more understandable to say "The number of
packets/octets sent from this SSRC"?

In RFC 1902, there is a requirement that the MIB describe, for each counter
or set of counters, when counting starts. I think the requirement is
brain-dead - show me a counter in any MIB that doesn't start counting when
the column containing it is created - but you're supposed to say either in
the description of the Table OBJECT-TYPE or in each Counter32 in the MIB
"... since the creation of the column of objects". So I would make both of
these read "The number of packets/octets sent from this SSRC since the
creation of the data stream."

7.1.6.  Counter32

   The Counter32 type represents a non-negative integer which
   monotonically increases until it reaches a maximum value of 2^32-1
   (4294967295 decimal), when it wraps around and starts increasing
   again from zero.

   Counters have no defined "initial" value, and thus, a single value of
   a Counter has (in general) no information content.  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type.
   If such other times can occur, for example, the creation of an object
   instance at times other than re-initialization, then a corresponding
   object should be defined with a SYNTAX clause value of TimeStamp (a
   textual convention defined in [3]) indicating the time of the last
   discontinuity.

   The value of the MAX-ACCESS clause for objects with a SYNTAX clause
   value of Counter32 is either "read-only" or "accessible-for-notify".

   A DEFVAL clause is not allowed for objects with a SYNTAX clause value
   of Counter32.

>         rtpEgTool OBJECT-TYPE
>                 SYNTAX          OCTET STRING (SIZE(1..128))
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "State variable names the tool sourcing the stream."
>                 ::= { rtpEgEntry 8 }

In what sense is this a "state variable"? If it were a state variable, I
would expect it to enumerate the states it might take, and in some sense
define them.

	INTEGER { closed(1), opening(2), established(3), closing(4) }
	DESCRIPTION
	  "This variable describes the states of the RTP FSM."
	REFERENCE
	  "Section 19.272 of the Real Time Transport Protocol."

Should this not read "the name of the tool sourcing the stream", and have
the syntax DisplayString? RFC 1903 has a full definition of a
DisplayString, but in general it means "Ascii Text", and any OCTET STRING
that contains ASCII text is generally a DisplayString. Here are the first
couple of lines.

DisplayString::= TEXTUAL-CONVENTION
    DISPLAY-HINT "255a"
    STATUS       current
    DESCRIPTION
            "Represents textual information taken from the NVT ASCII
            character set, as defined in pages 4, 10-11 of RFC 854.
	    ....

>         rtpEgInactiveTime   OBJECT-TYPE
>                 SYNTAX          Gauge32
>                 UNITS           "milliseconds"
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Elapsed time since last stream packet."
>                 ::= { rtpEgEntry 9 }

Hmmmmmmmmmmmmmmmmmmmmm. <hand scratches stubbly beard...>

As a general rule, SNMP MIBs have tried to avoid information which was
ephemeral in nature. This item seems ephemeral. If you had a timestamp, it
could be understood in reference to other timestamps, and a simple
difference would give you the period of time you are seeking. But making
the object produce a period of time - well, time since when? When I read
this value, how much time has elapsed between the time the GET succeeded
and the time the NMS received the GET RESPONSE containing the value? Is the
amount of time since the last packet 13 milliseconds, or is it 13
milliseconds plus an intervening 51 milliseconds that it took to get
through a router's congested queue en route back to me? Or was that 151
milliseconds? Are you certain that another packet didn't arrive while I
wasn't looking?

I would have expected that it would have the semantics "time of the last
packet, measured in <time units> past some epoch". RFC 1903's TimeStamp
Textual Convention would give you a way to read the time of the last packet
received, and the MIB-II object sysUpTime out give you the current value;
the difference is the time since the last packet in 10 millisecond units.
If what you are trying to obtain is that, I would suggest that encoding.

TimeStamp ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "The value of the sysUpTime object at which a specific
            occurrence happened.  The specific occurrence must be
            defined in the description of any object defined using this
            type."
    SYNTAX       TimeTicks

If you really need a Time Interval here, I would suggest using RFC 1903's
TimeInterval Textual Convention as the Syntax:

TimeInterval ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "A period of time, measured in units of 0.01 seconds."
    SYNTAX       INTEGER (0..2147483647)

>        rtpInLocalSSRC OBJECT-TYPE
>                 SYNTAX          INTEGER(1..4294967295)
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Identifies receiver/participant."
>                 ::= { rtpInEntry 3}

I'm probably showing my ignorance here. Identifies it in what way? Where
would I find the send of words that "SSRC" is supposed to expand to?
Perhaps a REFERENCE clause would be in order on this. In saaid Reference
clause, please do not say "reference [1] section 3.2 SET TRANSPORT", as the
MIB is often divorced from its surrounding text. Rather, make it be "Real
Time Transport Protocol, Section 3.2, SET Transport."

By the way, since I have run off and found that text, I have a comment on
the RTP Spec: put paragraph numbers on these blooming messages! It would be
easier to reference "Section 3.2.3" than referencing the sub-head under
section 3.2. And I suspect that there is something in a Synchronization
Source that is worth identifying further than a footnote in an identifier
in a message - one can apparently multiplex several synchronizing source's
data streams onto a single UDP port, and the semantics of that should be a
tad more obvious. Does a synchronization source correspond to a physical
microphone or video codec? Might a transmission source have stereo
microphones mixed in its audio stream? Is this about separating the "left",
"right", and "woofer"? How is this really used, quite apart from jargon
about "attributes" and "16 bit numbers"?

>        rtpInPT OBJECT-TYPE
>                 SYNTAX          INTEGER(1..128)
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Payload Type state variable."
>                 ::= { rtpInEntry 5 }

State Variable? For what state machine? I think this is a payload type. I
think the payload types should also be enumerated:

		SYNTAX { NewURL(1), GotoURL(2) }

and given a reference

		REFERENCE
		  "Real Time Streaming Protocol(RTSP) Section 3.3"

>
>         rtpInRemoteCNAME OBJECT-TYPE
>                 SYNTAX          OCTET STRING (SIZE(1..128))
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "attribute uniquely identifies receiver/participant."
>                 ::= { rtpInEntry 6 }

DisplayString? Isn't this "The name of the receiver or participant"? Would
a receiver have a different name with respect to each session he receives?
It seems (and here I show great ignorance) that if the remoteAddr is the IP
address of the sender this receiver is listening to, and remotePort is the
source port that remote sender is using, RemoteCNAME would be the remote
sender's name, on a session received at this receiver. What am I missing
here?

>        rtpInFracLost OBJECT-TYPE
>                 SYNTAX          Gauge32
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Statistic identifies the fraction of lost packets in
>                 the receive stream relative to the total packets."
>                 ::= { rtpInEntry 9 }

suggestion: this encoding, while intuitive, is too limiting in utility.
Fraction as measured over what interval? The whole session? The past 5
seconds since I changed the encoding to reduce packet rate? Can I have
three meters running simultaneously showing both?

I'd suggest keep a count of packets received and a count of packets known
to have been lost. The sum is nominally the number of packets the sender
sent. The fraction lost is therefore

	  (Delta InLostPackets)
   ---------------------------------------
   (Delta InLostPackets + Delta InPackets)

over the time interval that the network manager chooses to use. The network
management station can select any interval it likes, and three viewing
network management applications - or three plots on the same graph - can
use three different intervals if it suits them.

>
>        rtpInLostPackets OBJECT-TYPE
>                 SYNTAX          Counter32
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Statistic identifies the total number of packets
>                 lost from the receive stream."

Number lost since when? See previous note on counters...

>        rtpInTool OBJECT-TYPE
>                 SYNTAX          OCTET STRING (SIZE(1..128))
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "optional tool identifier state variable."
>                 ::= { rtpInEntry 12 }

"The name of the tool". Why is this optional? If implementation of the
object is not optional (if "optional" means "name will be displayed if I
know it"), in what way is *the*object* optional? Would it be better to say

	"the name of the originating tool if known. If unknown, the object
	 returns a string which contains zero octets."

ASCII Text is DisplayString.

>         rtpInInactiveTime   OBJECT-TYPE
>                 SYNTAX          Gauge32
>                 UNITS           "milliseconds"
>                 MAX-ACCESS      read-only
>                 STATUS          current
>                 DESCRIPTION
>                 "Elapsed time since last stream packet."
>                 ::= { rtpInEntry 13 }

TimeStamp or TimeInterval, as in the Eg table.

>         rtpSystemCompliance MODULE-COMPLIANCE
>                 STATUS          current
>                 DESCRIPTION     "All objects are mandatory with the
>                                  the exceptions listed below."
>                 MODULE RTP-SYSTEM
>                 MANDATORY-GROUPS { rtpSystemGroup }
>                 OBJECT rtpInPT
>                         MIN-ACCESS  not-accessible
>                         DESCRIPTION "This object is not always
>                                      obtainable, and is optional"
>                 OBJECT rtpInTool
>                         MIN-ACCESS  not-accessible
>                         DESCRIPTION "This object is not always
>                                      obtainable, and is optional"
>                 OBJECT rtpEgPT
>                         MIN-ACCESS  not-accessible
>                         DESCRIPTION "This object is not always
>                                      obtainable, and is optional"
>                 OBJECT rtpEgTool
>                         MIN-ACCESS  not-accessible
>                         DESCRIPTION "This object is not always
>                                      obtainable, and is optional"

I'm not sure this is the best way to handle this. "Optional", in a
compliance statement, means that someone doesn't have to implement the
object. If you don't have to implement the object, I would prefer you
didn't define it, because you have to assume that the typical
implementation will not. But I think you don't mean that - I think you mean
"if I don't know the answer, I am going to answer "noSuchObject" in
response to a GET, but if I do know the answer, I will answer with the
name." That is not optional implementation (the meaning of "optional" in a
compliance statement), it is reporting that you only sometimes have a scrap
of information. Knowing that you don't know and saying so in some cases,
and reporting a value in others, requires the object to in fact have been
implemented. If I understand what you're asking for, these objects are not
optional.

>         rtpSessionIf OBJECT-TYPE
>                 SYNTAX          OCTET STRING (SIZE(4..16))
>                 MAX-ACCESS      read-create
>                 STATUS          current
>                 DESCRIPTION
>                 "The local interface network address where RTP
>                 data packets are sent and received for session."
>                 ::= { rtpSessionEntry 4}

How do you handle unnumbered interfaces? Do you use the RouterId? Would it
be better to have two objects - one the IP Address or RouterId, and one the
ifIndex of the interface?

>         rtpSessionOwner OBJECT-TYPE
>                 SYNTAX          OCTET STRING(SIZE(64))
>                 MAX-ACCESS      read-create
>                 STATUS          current
>                 DESCRIPTION
>                 "This manager created the session.  Other managers
>                 wishing to monitor the session defined by the tuple
>                 <session-net-addr, session-port, interface>, cannot do
>
>                 so until this manager destroys the particular row; these
>                 semantics are forced by the 1:1 mapping of the row index
>                 to the session tuple enforced by rtpSessionIndexTable."
>                 ::= { rtpSessionEntry 5 }

What this *says* is that two network managers may not simultaneously
monitor the same set of objects at the same time. I would not suggest
designing it that way - find a way that two managers can view the same set
of objects at any time, and apply whatever color of glasses are necessary
to produce it's viewpoint.

>         rtpSessionRowStatus OBJECT-TYPE
>                 SYNTAX          RowStatus
>                 MAX-ACCESS      read-create
>                 STATUS          current
>                 DESCRIPTION
>                 "Session entries can be created by a manager."
>                 ::= { rtpSessionEntry 6}

I think we all agree that network managers can create a session. Your
Description doesn't address the questions that the Textual Convention
indicates it needs to. I would suggest that you re-read RFC 1903 pages 6-17
(the DESCRIPTION of the RowStatus Textual Convention, and make sure the
points it raises are covered. For example, the objects here are read-create
- which may only be written during row creation, and which are adjustable
later?


>        rtpSessionIndexValue  OBJECT-TYPE
>                 SYNTAX	      INTEGER(1..65535)
>                 MAX-ACCESS    read-only
>                 STATUS        current
>                 DESCRIPTION
>                 "Instance of rtpSessionIndex corresponds 1:1 with
>                 {rtpSessionAddr,rtpSessionPort,rtpSessionIf}."
>                 ::= { rtpSessionIndexEntry 1 }

In this case, I would not expect to find addresses or ports anywhere else.
Define the session index, and then use it everywhere. This can help a lot
with the size of your OIDs, and therefore the amount of information that
GET-BULK can put into a single SNMP GET RESPONSE.


>                 MANDATORY-GROUPS { rtpISGroup }
>                 OBJECT rtpSessionAddr
>                         MIN-ACCESS  read-only
>                         DESCRIPTION "This is useful even if the agent
>                                     chooses not support create access."
>                 OBJECT rtpSessionPort
>                         MIN-ACCESS  read-only
>                         DESCRIPTION "This is useful even if the agent
>                                     chooses not support create access."
>                 OBJECT rtpSessionIf
>                         MIN-ACCESS  read-only
>                         DESCRIPTION "This is useful even if the agent
>                                     chooses not support create access."
>                 OBJECT rtpSessionOwner
>                         MIN-ACCESS  read-only
>                         DESCRIPTION "This is useful even if the agent
>                                     chooses not support create access."
>                 OBJECT rtpSessionRowStatus
>                         MIN-ACCESS  not-accessible
>                         DESCRIPTION "Not needed when Addr, Port, and If
>                                     cannot be created by manager."

If you're going to make these optional, I would suggest telling me when I
need to implement them read-only, not that they are useful even if I don't
do SETs. If you don't implement SETs, I would suggest that implementation
of RowStatus is indeed optional.

The IESG will require a security section. I would suggest that it read
something like this:

    In most cases, MIBs are not themselves security risks; If SNMP Security
    is operating as intended, the use of a MIB to change the configuration
    of a system is a tool, not a threat. For a threat analysis of SNMP
    Security, see RFC ZZZZ.

Ask the O&M ADs, or Russ Mundy, what Security Analysis RFC you should
reference.

I need to run this through SMICng; I'll send you whatever comments it comes
up with. One that I expect it to report is that you import RowStatus to the
first module and don't use it.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
				Calvin and Hobbes (Bill Watterson)






From rem-conf Tue May 13 21:27:17 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 21:27:16 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRVce-0005SR-00; Tue, 13 May 1997 21:25:04 -0700
Date: Tue, 13 May 1997 21:04:34 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Fred Baker <fred@cisco.com>
cc: mbaugher@ideal.jf.intel.com, John_Du@ccm.jf.intel.com, snaudus@usrva.com, 
    scott bradner <sob@harvard.edu>, allyn romanow <allyn.romanow@eng.sun.com>, 
    Mike O'Dell <mo@uunet.uu.net>, John Curran <jcurran@bbnplanet.com>, 
    rem-conf@es.net
Subject: Re: Real-Time Transport Protocol MIB Review
In-Reply-To: <v03007813af93b926bd67@[171.69.128.118]>
Message-ID: <Pine.WNT.3.95.970513210314.-352951M-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Fred,

Thanks for your prompt review of the RTP MIB, and apologies for my
slow response.  I've included my replies to some of your questions
below, but I expect the draft authors will reply with more details.

							-- Steve

> > 4.1.1  An "RTP Session" is defined by an IP address and a pair of
> > transport-layer port numbers, this is a "Session Address".  There
> > is one Session Address for a multicast session and two for unicast.
> 
> If it uses port numbers, it seems to me that it should use both IP
> Addresses; if not both IP Addresses, then it should not be both ports. The
> port number is essentially as extention of the IP Address to identify a
> process (perhaps a listening process).

RTP uses an even/odd port pair for the parallel RTP data and RTCP
control packet streams.  The port pair can be identified by the first
(even) port.


You had comments in a couple of places about "SSRC":

> >Data streams are uniquely identified within an RTP
> >Session by "SSRC" attributes.
> 
> And what on God's green earth might an SSRC be? Is there a reference,
> perhaps, that defines this term?

The SSRC (synchronization source) and SSRC identifier are defined in
the RTP spec, RFC 1889, to which this MIB applies:

   Synchronization source (SSRC): The source of a stream of RTP packets,
        identified by a 32-bit numeric SSRC identifier carried in the
        RTP header so as not to be dependent upon the network address.
        All packets from a synchronization source form part of the same
        timing and sequence number space, so a receiver groups packets
        by synchronization source for playback. Examples of
        synchronization sources include the sender of a stream of
        packets derived from a signal source such as a microphone or a
        camera, or an RTP mixer (see below). A synchronization source
        may change its data format, e.g., audio encoding, over time. The
        SSRC identifier is a randomly chosen value meant to be globally
        unique within a particular RTP session (see Section 8). A
        participant need not use the same SSRC identifier for all the
        RTP sessions in a multimedia session; the binding of the SSRC
        identifiers is provided through RTCP (see Section 6.4.1).  If a
        participant generates multiple streams in one RTP session, for
        example from separate video cameras, each must be identified as
        a different SSRC.

> >        rtpInLocalSSRC OBJECT-TYPE
> >                 SYNTAX          INTEGER(1..4294967295)
> >                 MAX-ACCESS      read-only
> >                 STATUS          current
> >                 DESCRIPTION
> >                 "Identifies receiver/participant."
> >                 ::= { rtpInEntry 3}
> 
> I'm probably showing my ignorance here. Identifies it in what way? Where
> would I find the send of words that "SSRC" is supposed to expand to?

As stated in the definition above, the SSRC is bound to a set of words
(the CNAME) via an RTCP packet.  The MIB does imply this binding in
that the SSRC and CNAME appear next to each other in the tables.
Perhaps some words stating this relationship would be appropriate in
the MIB document, though of course one also does not want to repeat
the whole RTP spec.

> Perhaps a REFERENCE clause would be in order on this. In saaid Reference
> clause, please do not say "reference [1] section 3.2 SET TRANSPORT", as the
> MIB is often divorced from its surrounding text. Rather, make it be "Real
> Time Transport Protocol, Section 3.2, SET Transport."
>
> By the way, since I have run off and found that text, I have a comment on
> the RTP Spec: put paragraph numbers on these blooming messages! It would be
> easier to reference "Section 3.2.3" than referencing the sub-head under
> section 3.2. And I suspect that there is something in a Synchronization
> Source that is worth identifying further than a footnote in an identifier
> in a message - one can apparently multiplex several synchronizing source's
> data streams onto a single UDP port, and the semantics of that should be a
> tad more obvious. 

None of the references in this MIB should be to RTSP, which is a
control protocol that can employ RTP as one option for transport of
the data stream being controlled.  "SET TRANSPORT" is not an RTP
notion.  I'm not sure just which text you found; the definition of
SSRC above is in Section 3 of the RTP spec (RFC 1889) which defines a
collection of terms.  Do you think that each of those terms should be
numbered?

> Does a synchronization source correspond to a physical
> microphone or video codec? Might a transmission source have stereo
> microphones mixed in its audio stream? Is this about separating the "left",
> "right", and "woofer"? How is this really used, quite apart from jargon
> about "attributes" and "16 bit numbers"?

The synchronization source is the source of a stream of packets.  It
may well correspond to a microphone whose signal has passed through an
audio codec.  A stereo signal could be sent as two separate data
streams identified by different SSRC id's, but stereo sound is
normally sent with interleaved samples.


> >                 "Elapsed time since last stream packet."
> >                 ::= { rtpEgEntry 9 }
> 
> Hmmmmmmmmmmmmmmmmmmmmm. <hand scratches stubbly beard...>
> 
> As a general rule, SNMP MIBs have tried to avoid information which was
> ephemeral in nature. This item seems ephemeral. If you had a timestamp, it
> could be understood in reference to other timestamps, and a simple
> difference would give you the period of time you are seeking.

This seems like a good policy in general.  But putting in a timestamp
is only meaningful if the SNMP querier has the same time reference.
That is, if the timestamp was relative to the "system time", then one
would need to fetch that reference, too, and subtract.  Transit delays
could introduce a lot of error.  In this case, one is trying to
determine if milliseconds or seconds have elapsed since the last
packet, so the elapsed time makes sense to me.


> >        rtpInFracLost OBJECT-TYPE
> >                 SYNTAX          Gauge32
> >                 MAX-ACCESS      read-only
> >                 STATUS          current
> >                 DESCRIPTION
> >                 "Statistic identifies the fraction of lost packets in
> >                 the receive stream relative to the total packets."
> >                 ::= { rtpInEntry 9 }
> 
> suggestion: this encoding, while intuitive, is too limiting in utility.
> Fraction as measured over what interval? The whole session? The past 5
> seconds since I changed the encoding to reduce packet rate? Can I have
> three meters running simultaneously showing both?

The loss statistics returned in RTCP Receiver Reports include a
"fraction lost in the last reporting interval".  The participants use
a distributed algorithm to scale to the same interval based on the
number of participants.  That interval may need to be added to the
MIB.

> I'd suggest keep a count of packets received and a count of packets known
> to have been lost. The sum is nominally the number of packets the sender
> sent. The fraction lost is therefore
> 
> 	  (Delta InLostPackets)
>    ---------------------------------------
>    (Delta InLostPackets + Delta InPackets)
> 
> over the time interval that the network manager chooses to use. The network
> management station can select any interval it likes, and three viewing
> network management applications - or three plots on the same graph - can
> use three different intervals if it suits them.

This is the way the primary loss statistics work in RTCP Receiver
Reports, except that the numbers are roughly the number lost and the
the number transmitted.  The numbers are absolute, not deltas, so that
deltas can be calculated for any pair of reports (covering the desired
time interval) to make a calculation similar to what you've shown.
The (redundant) loss fraction is carried in the RTCP Receiver Report
to allow a less accurate measure of loss when only one report has been
received, e.g. because the interval is long.


Thanks for your review.
							-- Steve




From rem-conf Tue May 13 21:36:01 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 21:36:01 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRVmr-0005lv-00; Tue, 13 May 1997 21:35:37 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v03007818af9eee1e2d52@[171.69.128.118]>
In-Reply-To: <Pine.WNT.3.95.970513210314.-352951M-100000@oak.precept.com>
References: <v03007813af93b926bd67@[171.69.128.118]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 13 May 1997 21:34:35 -0700
To: Stephen Casner <casner@precept.com>
From: Fred Baker <fred@cisco.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: mbaugher@ideal.jf.intel.com, John_Du@ccm.jf.intel.com, snaudus@usrva.com, 
    scott bradner <sob@harvard.edu>, allyn romanow <allyn.romanow@eng.sun.com>, 
    Mike O'Dell <mo@uunet.uu.net>, John Curran <jcurran@bbnplanet.com>, 
    rem-conf@es.net
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 9:04 PM -0700 5/13/97, Stephen Casner wrote:
>> If it uses port numbers, it seems to me that it should use both IP
>> Addresses; if not both IP Addresses, then it should not be both ports. The
>> port number is essentially as extention of the IP Address to identify a
>> process (perhaps a listening process).
>
>RTP uses an even/odd port pair for the parallel RTP data and RTCP
>control packet streams.  The port pair can be identified by the first
>(even) port.

Hmm. I am aware of the port number coupling. I had no idea from what the
MIB said that said coupling was what I was looking at. I would suggest
clarifying the language. I have to say that, throughout the MIB, the
language was as obscure as any document I have ever read.

>The SSRC (synchronization source) and SSRC identifier are defined in
>the RTP spec, RFC 1889, to which this MIB applies:
>
>   Synchronization source (SSRC): The source of a stream of RTP packets,
>        identified by a 32-bit numeric SSRC identifier carried in the
>        RTP header so as not to be dependent upon the network address.
>        All packets from a synchronization source form part of the same
>        timing and sequence number space, so a receiver groups packets
>        by synchronization source for playback. Examples of
>        synchronization sources include the sender of a stream of
>        packets derived from a signal source such as a microphone or a
>        camera, or an RTP mixer (see below). A synchronization source
>        may change its data format, e.g., audio encoding, over time. The
>        SSRC identifier is a randomly chosen value meant to be globally
>        unique within a particular RTP session (see Section 8). A
>        participant need not use the same SSRC identifier for all the
>        RTP sessions in a multimedia session; the binding of the SSRC
>        identifiers is provided through RTCP (see Section 6.4.1).  If a
>        participant generates multiple streams in one RTP session, for
>        example from separate video cameras, each must be identified as
>        a different SSRC.

OK, a REFERENCE clause pointing to that is in order.

>As stated in the definition above, the SSRC is bound to a set of words
>(the CNAME) via an RTCP packet.  The MIB does imply this binding in
>that the SSRC and CNAME appear next to each other in the tables.
>Perhaps some words stating this relationship would be appropriate in
>the MIB document, though of course one also does not want to repeat
>the whole RTP spec.

yes on both counts. even a REFERENCE clause would suffice.

>None of the references in this MIB should be to RTSP, which is a
>control protocol that can employ RTP as one option for transport of
>the data stream being controlled.  "SET TRANSPORT" is not an RTP
>notion.  I'm not sure just which text you found; the definition of
>SSRC above is in Section 3 of the RTP spec (RFC 1889) which defines a
>collection of terms.  Do you think that each of those terms should be
>numbered?

I was looking (wrongly) at RTSP, and it lists a bunch of messages in
section 3.2. I was commenting on those messages.

>> Does a synchronization source correspond to a physical
>> microphone or video codec? Might a transmission source have stereo
>> microphones mixed in its audio stream? Is this about separating the "left",
>> "right", and "woofer"? How is this really used, quite apart from jargon
>> about "attributes" and "16 bit numbers"?
>
>The synchronization source is the source of a stream of packets.  It
>may well correspond to a microphone whose signal has passed through an
>audio codec.  A stereo signal could be sent as two separate data
>streams identified by different SSRC id's, but stereo sound is
>normally sent with interleaved samples.

those words would be good ones to find somewhere, either in 1889 or the
MIB. Probably in 1889 and REFERENCEd in the MIB.

>This seems like a good policy in general.  But putting in a timestamp
>is only meaningful if the SNMP querier has the same time reference.

like sysUpTime?

>That is, if the timestamp was relative to the "system time", then one
>would need to fetch that reference, too, and subtract.  Transit delays
>could introduce a lot of error.  In this case, one is trying to
>determine if milliseconds or seconds have elapsed since the last
>packet, so the elapsed time makes sense to me.

you can get the timestamp and sysUpTime in the same GET (a GET can GET as
many objects as you like), so the difference issue doesn't wash. the thing
is, timestamps can also be compared to each other. I can definitivesly say,
for example, if it is advancing; from elapsed time, I can make an
inference, but the inference also has holes in it.

>The loss statistics returned in RTCP Receiver Reports include a
>"fraction lost in the last reporting interval".  The participants use
>a distributed algorithm to scale to the same interval based on the
>number of participants.  That interval may need to be added to the
>MIB.

OK, I can see that. Can you see my point, however? The question from a
network management station is not "what number was last reported in RTCP",
it's "OK, I futzed with something, am I still losing packets? If so, at
what rate? Is it better or worse?" Don't think of this is terms of reading
the numbers that RTCP last produced, think in terms of "I am a network
manager, some idiot is screaming on the phone that RTCP is reporting
badness, and I want to do something about it. How can I tell what the
effect of my actions are?"

The purpose of a MIB, I frequently tell people, is to instrument a protocol
defined in some other document - in this case, 1889. I'm going to add a
phrase to that - "so that a network management station can have an
independent view of the network, and manage it."

>This is the way the primary loss statistics work in RTCP Receiver
>Reports, except that the numbers are roughly the number lost and the
>the number transmitted.  The numbers are absolute, not deltas, so that
>deltas can be calculated for any pair of reports (covering the desired
>time interval) to make a calculation similar to what you've shown.
>The (redundant) loss fraction is carried in the RTCP Receiver Report
>to allow a less accurate measure of loss when only one report has been
>received, e.g. because the interval is long.

That's not at all clear from the MIB. If they're absolute, why can't this
be a Counter32 (monotonically increasing until the wrap point, where it
wraps) instead of a Gauge32 (jumps up and down all over the place,
representing the reading of a "dial" at whatever time it happens to have
been read)?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
				Calvin and Hobbes (Bill Watterson)





From rem-conf Tue May 13 23:25:05 1997 
From rem-conf-request@tmpmail.es.net Tue May 13 23:25:04 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRXRK-0006NU-00; Tue, 13 May 1997 23:21:30 -0700
Message-Id: <3.0.32.19970513232716.00683bc8@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 13 May 1997 23:27:18 -0700
To: Fred Baker <fred@cisco.com>
From: Mark Baugher <mbaugher@rdrop.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: Stephen Casner <casner@precept.com>, rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

<bigger>Fred,

  Thanks for reviewing the RTP MIB.  In addition to the changes 

you suggested, there are at least two more that are needed.


  o A "feedback" table that is built on-demand in the sender from

    information gathered from the receiver reports (RR's) will be

    added.  Christian Huitema argued for this in Memphis, and 

    I think people generally agreed with his arguments.

    This issue was raised in discussions with others prior to 

    Memphis: Christian Maciocco thought it might be useful, and

    Karl Auerbach suggested that this table could be created as 

    a side effect to a management SET operation, which is how

    I propose to do it.


  o The indexes will be given a MAX-ACCESS of not-accessible as

    mandated by RFC 1902.


My responses are numbered below, from 1 to 28.  


At 07:34 PM 5/3/97 -0700, Fred Baker wrote:

>

>First comment: I was unable to determine from the internet draft what

>mailing list comments on this MIB should go to (it is the AVT WG, but
the

>mailto URL is not in the document). Please forward these comments to
the

>relevant list.


#1 I'll put the  mailto URL in the document.


>

>Second comment: I note that three authors are listed on the draft, but 

only

>one in each of the two MODULE-IDENTITY statements. It's up to you, but
I

>should think you'd want all three listed, as compilable schemas
generally

>omit the RFC from which the MIB is extracted.


#2 I followed the convention found in a number of MIBs such as IGMP,

IPMRoute, Application Management, and RFC 1907 SNMPv2 MIB where

only the person or persons who edited and compiled the MIB are 

identified rather than the list of authors of the document.

Perkins & McGinnis recommend that "For IETF working groups, the 

technical contacts should include the working group mailing list, 

the chair, and the editor", p 86.  


>

>> 4.1.1  An "RTP Session" is defined by an IP address and a pair of

>> transport-layer port numbers, this is a "Session Address".  There

>> is one Session Address for a multicast session and two for unicast.

>

>If it uses port numbers, it seems to me that it should use both IP

>Addresses; if not both IP Addresses, then it should not be both ports.
The

>port number is essentially as extention of the IP Address to identify 
a

>process (perhaps a listening process).


#3 There's one IP address and two port numbers, RTP and RTCP.  John and

Stan think we should just stick with the RFC definition from Section 
3.2


RTP session: The association among a set of participants

        communicating with RTP. For each participant, the session is

        defined by a particular pair of destination transport addresses

        (one network address plus a port pair for RTP and RTCP). The

        destination transport address pair may be common for all

        participants, as in the case of IP multicast, or may be

        different for each, as in the case of individual unicast 
network

        addresses plus a common port pair.  


>

>>4.1.2 An "RTP Data Stream" is a sequence of packets sent to the

>>even-numbered port of the RTP Session when UDP is used to transport

>>the RTP data. Data streams are uniquely identified within an RTP

>>Session by "SSRC" attributes.

>

>And what on God's green earth might an SSRC be? Is there a reference,

>perhaps, that defines this term? Would this by the Synchronization
Source

>Identifier described (not very well) in draft-rao-rtsp-00.txt? And tell 

me,

>is it more understandable to say "SSRC Attribute" or "Synchronization

>Source Identifier."? You might reference section 3.2, Set Transport, 
of

>that document, where SSRC is defined in this manner:

>

>	SSRC: 32 bits

>

>	Identifies the synchronization source to be associated with the

>	data. This can be used for de-multiplexing by the client of data

>	received on the same port.


#4 I'll make a point of introducing a variable by its complete name 

before using an abbreviation.  


>

>Wouldn't it be simpler/more understandable to say "The number of

>packets/octets sent from this SSRC"?


#5 I'll change it.


>

>In RFC 1902, there is a requirement that the MIB describe, for each 

counter

>or set of counters, when counting starts. I think the requirement is

>brain-dead - show me a counter in any MIB that doesn't start counting
when

>the column containing it is created - but you're supposed to say either
in

>the description of the Table OBJECT-TYPE or in each Counter32 in the
MIB

>"... since the creation of the column of objects". So I would make both
of

>these read "The number of packets/octets sent from this SSRC since the

>creation of the data stream."


#6 I will modify the counter descriptions accordingly.


>

>7.1.6.  Counter32

>

>   The Counter32 type represents a non-negative integer which

>   monotonically increases until it reaches a maximum value of 2^32-1

>   (4294967295 decimal), when it wraps around and starts increasing

>   again from zero.

>

>   Counters have no defined "initial" value, and thus, a single value
of

>   a Counter has (in general) no information content.  Discontinuities

>   in the monotonically increasing value normally occur at re-

>   initialization of the management system, and at other times as

>   specified in the description of an object-type using this ASN.1
type.

>   If such other times can occur, for example, the creation of an
object

>   instance at times other than re-initialization, then a 
corresponding

>   object should be defined with a SYNTAX clause value of TimeStamp (a

>   textual convention defined in [3]) indicating the time of the last

>   discontinuity.

>

>   The value of the MAX-ACCESS clause for objects with a SYNTAX clause

>   value of Counter32 is either "read-only" or 
"accessible-for-notify".

>

>   A DEFVAL clause is not allowed for objects with a SYNTAX clause
value

>   of Counter32.

>

>>         rtpEgTool OBJECT-TYPE

>>                 SYNTAX          OCTET STRING (SIZE(1..128))

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "State variable names the tool sourcing the stream."

>>                 ::= { rtpEgEntry 8 }

>

>In what sense is this a "state variable"? If it were a state variable,
I

>would expect it to enumerate the states it might take, and in some
sense

>define them.

>


#7 I think you are right when you say that "state variable" 

usually refers to enumerations in published MIB's.  I am 

using it to describe an object that takes on values dynamically

as opposed to one that is  static (Perkins & McGinnis describe

objects in these terms in their chapter on MIB design, p. 197).  

Payload Type and Tool are two objects that could be mistaken as 

being static for an RTP session rather than objects that may 

change value dynamically during normal stream operation.  This

is an issue for the object model.  There's no need to keep

"state variable", "attribute" or "statistic"  in the DESCRIPTION

clauses.  They are obviously confusing.


>Should this not read "the name of the tool sourcing the stream", and
have

>the syntax DisplayString? RFC 1903 has a full definition of a

>DisplayString, but in general it means "Ascii Text", and any OCTET
STRING

>that contains ASCII text is generally a DisplayString. Here are the
first

>couple of lines.


#8 Yes, I'll change it.



>>         rtpEgInactiveTime   OBJECT-TYPE

>>                 SYNTAX          Gauge32

>>                 UNITS           "milliseconds"

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "Elapsed time since last stream packet."

>>                 ::= { rtpEgEntry 9 }

>

>Hmmmmmmmmmmmmmmmmmmmmm. <<hand scratches stubbly beard...>

>

>As a general rule, SNMP MIBs have tried to avoid information which was

>ephemeral in nature. This item seems ephemeral. If you had a timestamp,
it

>could be understood in reference to other timestamps, and a simple

>difference would give you the period of time you are seeking. But
making

>the object produce a period of time - well, time since when? When I
read

>this value, how much time has elapsed between the time the GET
succeeded

>and the time the NMS received the GET RESPONSE containing the value? Is 

the

>amount of time since the last packet 13 milliseconds, or is it 13

>milliseconds plus an intervening 51 milliseconds that it took to get

>through a router's congested queue en route back to me? Or was that 
151

>milliseconds? Are you certain that another packet didn't arrive while 
I

>wasn't looking?


#9 This is taken from RFC 1889.

start of RFC 1889 excerpt...

6.2.1 Maintaining the number of session members

[...]


   Once a site has been validated, then if it is later marked inactive

   the state for that site should still be retained and the site should

   continue to be counted in the total number of sites sharing RTCP

   bandwidth for a period long enough to span typical network

   partitions.  This is to avoid excessive traffic, when the partition

   heals, due to an RTCP report interval that is too small. A timeout 
of

   30 minutes is suggested. Note that this is still larger than 5 times

   the largest value to which the RTCP report interval is expected to

   usefully scale, about 2 to 5 minutes.

...so the time scale is on the order of tens of minutes

>

>I would have expected that it would have the semantics "time of the
last

>packet, measured in <<time units> past some epoch". RFC 1903's
TimeStamp

>Textual Convention would give you a way to read the time of the last 

packet

>received, and the MIB-II object sysUpTime out give you the current
value;

>the difference is the time since the last packet in 10 millisecond
units.

>If what you are trying to obtain is that, I would suggest that
encoding.

>

>TimeStamp ::= TEXTUAL-CONVENTION

>    STATUS       current

>    DESCRIPTION

>            "The value of the sysUpTime object at which a specific

>            occurrence happened.  The specific occurrence must be

>            defined in the description of any object defined using 
this

>            type."

>    SYNTAX       TimeTicks

>

>If you really need a Time Interval here, I would suggest using RFC
1903's

>TimeInterval Textual Convention as the Syntax:

>

>TimeInterval ::= TEXTUAL-CONVENTION

>    STATUS       current

>    DESCRIPTION

>            "A period of time, measured in units of 0.01 seconds."

>    SYNTAX       INTEGER (0..2147483647)

>


#10 Is a coupling to SysUpTime really needed given the definition

of InactiveTime given above? 


>>        rtpInLocalSSRC OBJECT-TYPE

>>                 SYNTAX          INTEGER(1..4294967295)

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "Identifies receiver/participant."

>>                 ::= { rtpInEntry 3}

>

>I'm probably showing my ignorance here. Identifies it in what way?
Where

>would I find the send of words that "SSRC" is supposed to expand to?

>Perhaps a REFERENCE clause would be in order on this. In saaid
Reference

>clause, please do not say "reference [1] section 3.2 SET TRANSPORT", as 

the

>MIB is often divorced from its surrounding text. Rather, make it be
"Real

>Time Transport Protocol, Section 3.2, SET Transport."

>


#11 Maybe I should add SMI REFERENCE clauses here and at a few other 

places in the draft.  For LocalSSRC, the reference is "6.3.2 RR: 

Receiver report RTCP packet" that shows the following diagram.



 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|    RC   |   PT=RR=201   |             length            | 
header

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     SSRC of packet sender                     |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

|                 SSRC_1 (SSRC of first source)                 | 
report

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block

| fraction lost |       cumulative number of packets lost       |   1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|           extended highest sequence number received           |



Note that there are two SSRC's in the RR.  The "SSRC of packet sender" 

refers to the receiver, The second SSRC, labeled SSRC_1 and repeated 

for each report block, is that of the source of the RTP packets.  Thus 
a

"Synchronization Source" may source RTP or RTCP.  We index ingress 

streams by this pair of SSRC's in the RTP MIB.


>By the way, since I have run off and found that text, I have a comment
on

>the RTP Spec: put paragraph numbers on these blooming messages! It would 

be

>easier to reference "Section 3.2.3" than referencing the sub-head 
under

>section 3.2. And I suspect that there is something in a 
Synchronization

>Source that is worth identifying further than a footnote in an
identifier

>in a message - one can apparently multiplex several synchronizing
source's

>data streams onto a single UDP port, and the semantics of that should be
a

>tad more obvious. Does a synchronization source correspond to a
physical

>microphone or video codec? Might a transmission source have stereo

>microphones mixed in its audio stream? Is this about separating the 

"left",

>"right", and "woofer"? How is this really used, quite apart from 
jargon

>about "attributes" and "16 bit numbers"?

>


#12 From Section 3.2 of the RTP spec we have the following definition.


 Synchronization source (SSRC): The source of a stream of RTP packets,

        identified by a 32-bit numeric SSRC identifier carried in the

        RTP header so as not to be dependent upon the network address.

        All packets from a synchronization source form part of the same

        timing and sequence number space, so a receiver groups packets

        by synchronization source for playback. Examples of

        synchronization sources include the sender of a stream of

        packets derived from a signal source such as a microphone or a

        camera, or an RTP mixer (see below). A synchronization source

        may change its data format, e.g., audio encoding, over time. 
The

        SSRC identifier is a randomly chosen value meant to be globally

        unique within a particular RTP session (see Section 8). A

        participant need not use the same SSRC identifier for all the

        RTP sessions in a multimedia session; the binding of the SSRC

        identifiers is provided through RTCP (see Section 6.4.1).  If a

        participant generates multiple streams in one RTP session, for

        example from separate video cameras, each must be identified as

        a different SSRC.


I bet you read this already.  Steve Casner said he was going to post a 

response, so I'll defer to him on the questions you raise here.  When 

we were designing the MIB we also took into account use of the SSRC to 

identify the source of a receiver report, and its use for identifying 

loops that could be introduced by translators as explained in section 8 

of the RTP spec.


>>        rtpInPT OBJECT-TYPE

>>                 SYNTAX          INTEGER(1..128)

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "Payload Type state variable."

>>                 ::= { rtpInEntry 5 }

>

>State Variable? For what state machine? I think this is a payload type.
I

>think the payload types should also be enumerated:

>

>		SYNTAX { NewURL(1), GotoURL(2) }

>


#13 We can't enumerate the payload types since they can be dynamic.

>From section 5.1 of RFC 1889:


payload type (PT): 7 bits

        This field identifies the format of the RTP payload and

        determines its interpretation by the application. A profile

        specifies a default static mapping of payload type codes to

        payload formats. Additional payload type codes may be defined

        dynamically through non-RTP means (see Section 3). An initial

        set of default mappings for audio and video is specified in the

        companion profile Internet-Draft draft-ietf-avt-profile, and

        may be extended in future editions of the Assigned Numbers RFC

        [6].  An RTP sender emits a single RTP payload type at any 
given

        time; this field is not intended for multiplexing separate 
media

        streams (see Section 5.2).


>and given a reference

>

>		REFERENCE

>		  "Real Time Streaming Protocol(RTSP) Section 3.3"

>


#14 Here is a rewrite of the  object.


        rtpInPT OBJECT-TYPE

                 SYNTAX          INTEGER(1..128)

                 MAX-ACCESS      read-only

                 STATUS          current

                 DESCRIPTION

                 "The Payload Type of the stream that may assume

                  different values over time."

                 REFERENCE

                  "Real-Time Transport Protocol, Section 5.1"

                 ::= { rtpInEntry 5 }

>>

>>         rtpInRemoteCNAME OBJECT-TYPE

>>                 SYNTAX          OCTET STRING (SIZE(1..128))

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "attribute uniquely identifies 
receiver/participant."

>>                 ::= { rtpInEntry 6 }

>

>DisplayString? Isn't this "The name of the receiver or participant"?
Would


#15  Yes, display string.  We now have a working RTP management entity

and SNMP agent; we have found that we must refine the syntax

and in some cases  use display hints to get what we want from 

browsers on some common network management platforms. I would change

the syntax to the following.  


        rtpInRemoteCNAME OBJECT-TYPE

                 SYNTAX          DisplayString (SIZE(1..256))

                 MAX-ACCESS      read-only

                 STATUS          current

                 DESCRIPTION

                 "The canonical name of the participant who is

                 receiving this RTP stream, unchanging and 

                 unique to the session."

                 REFERENCE

                  "Real-Time Transport Protocol, section 6.4.1"

                 ::= { rtpInEntry 6 }


I also found some inconsistencies on sizes between the MIB and the

spec that we'll fix.


>a receiver have a different name with respect to each session he
receives?

>It seems (and here I show great ignorance) that if the remoteAddr is the 

IP

>address of the sender this receiver is listening to, and remotePort is
the

>source port that remote sender is using, RemoteCNAME would be the
remote

>sender's name, on a session received at this receiver. What am I
missing

>here?

>

>>        rtpInFracLost OBJECT-TYPE

>>                 SYNTAX          Gauge32

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "Statistic identifies the fraction of lost packets 
in

>>                 the receive stream relative to the total packets."

>>                 ::= { rtpInEntry 9 }

>

>suggestion: this encoding, while intuitive, is too limiting in 
utility.

>Fraction as measured over what interval? The whole session? The past 5

>seconds since I changed the encoding to reduce packet rate? Can I have

>three meters running simultaneously showing both?


#16 Every statistic and most other information in the MIB come directly 

>from RTP or RTCP messages.  And these are defined in the spec.   In
fact,

most MIB variables come from RTCP messages, Receiver Reports, Sender 

Reports and SDES.  Fraction lost is defined on page 25 of the RTP spec.

This appears in the Ingress Streams table of the MIB so it refers to a 

single incoming stream for its total duration.  You're right, I am 

supposed to state when counting starts.


>

>I'd suggest keep a count of packets received and a count of packets
known

>to have been lost. The sum is nominally the number of packets the
sender

>sent. The fraction lost is therefore

>

>	  (Delta InLostPackets)

>   ---------------------------------------

>   (Delta InLostPackets + Delta InPackets)

>

>over the time interval that the network manager chooses to use. The 

network

>management station can select any interval it likes, and three viewing

>network management applications - or three plots on the same graph -
can

>use three different intervals if it suits them.

>

>>

>>        rtpInLostPackets OBJECT-TYPE

>>                 SYNTAX          Counter32

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "Statistic identifies the total number of packets

>>                 lost from the receive stream."

>

>Number lost since when? See previous note on counters...


#17 refer to #6


>

>>        rtpInTool OBJECT-TYPE

>>                 SYNTAX          OCTET STRING (SIZE(1..128))

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "optional tool identifier state variable."

>>                 ::= { rtpInEntry 12 }

>

>"The name of the tool". Why is this optional? If implementation of the

>object is not optional (if "optional" means "name will be displayed if
I

>know it"), in what way is *the*object* optional? Would it be better to
say

>

>	"the name of the originating tool if known. If unknown, the object

>	 returns a string which contains zero octets."


#18 Yes, I agree.


>

>ASCII Text is DisplayString.

>

>>         rtpInInactiveTime   OBJECT-TYPE

>>                 SYNTAX          Gauge32

>>                 UNITS           "milliseconds"

>>                 MAX-ACCESS      read-only

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "Elapsed time since last stream packet."

>>                 ::= { rtpInEntry 13 }

>

>TimeStamp or TimeInterval, as in the Eg table.

>


#19  Same as #10 


>>         rtpSystemCompliance MODULE-COMPLIANCE

>>                 STATUS          current

>>                 DESCRIPTION     "All objects are mandatory with the

>>                                  the exceptions listed below."

>>                 MODULE RTP-SYSTEM

>>                 MANDATORY-GROUPS { rtpSystemGroup }

>>                 OBJECT rtpInPT

>>                         MIN-ACCESS  not-accessible

>>                         DESCRIPTION "This object is not always

>>                                      obtainable, and is optional"

>>                 OBJECT rtpInTool

>>                         MIN-ACCESS  not-accessible

>>                         DESCRIPTION "This object is not always

>>                                      obtainable, and is optional"

>>                 OBJECT rtpEgPT

>>                         MIN-ACCESS  not-accessible

>>                         DESCRIPTION "This object is not always

>>                                      obtainable, and is optional"

>>                 OBJECT rtpEgTool

>>                         MIN-ACCESS  not-accessible

>>                         DESCRIPTION "This object is not always

>>                                      obtainable, and is optional"

>

>I'm not sure this is the best way to handle this. "Optional", in a

>compliance statement, means that someone doesn't have to implement the

>object. If you don't have to implement the object, I would prefer you

>didn't define it, because you have to assume that the typical

>implementation will not. But I think you don't mean that - I think you 

mean

>"if I don't know the answer, I am going to answer "noSuchObject" in


#20 Don't you mean "noSuchInstance" rather than noSuchObject?   If the

entity acting as an agent implements the object but there is no value

for it yet, then it returns noSuchInstance (RFC 1905, 4.2.1).

I see your point, however, just because there's no value does not

make the object optional - this is the case for Tool, but that's not 

the case for Payload Type (more below).


>response to a GET, but if I do know the answer, I will answer with the

>name." That is not optional implementation (the meaning of "optional" in
a

>compliance statement), it is reporting that you only sometimes have a 

scrap

>of information. Knowing that you don't know and saying so in some
cases,

>and reporting a value in others, requires the object to in fact have
been

>implemented. If I understand what you're asking for, these objects are
not

>optional.

>


#21 Here's what we intended:  An RTP Monitor may only receive the RTCP 

(it opens a socket on the RTCP port, but not the RTP port, a reasonable 

behavior for an RTP Monitor) so the Payload Type which is carried in 
the

RTP header may not be available to the entity. In this case,  

noSuchObject would be the response I would expect for a Get on the 

Payload Time object when the entity acting as an agent does not 

implement the object.  I don't think noSuchObject is the correct 

response for Tool, since values may exist for one session but not for 

another; one application tool may identify itself but another may 

not.  


In the Tool case, therefore, a MIN-ACCESS is not needed.  I will change 

its compliance.  In the Payload Type case, its compliance

should remain the same, a MIN-ACCESS of not-accessible.  Now there is 

no ambiguity:  If noSuchObject is returned then the entity does not 

implement the object; if noSuchInstance is returned, then the entity 

implements the object but the object does not have a value to be 

returned.


>>         rtpSessionIf OBJECT-TYPE

>>                 SYNTAX          OCTET STRING (SIZE(4..16))

>>                 MAX-ACCESS      read-create

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "The local interface network address where RTP

>>                 data packets are sent and received for session."

>>                 ::= { rtpSessionEntry 4}

>

>How do you handle unnumbered interfaces? Do you use the RouterId? Would
it

>be better to have two objects - one the IP Address or RouterId, and one 

the

>ifIndex of the interface?

>


#22 Yes, I think this is a problem since this object is intended to be 

used for translators, and tunnels may terminate in translators.



>>         rtpSessionOwner OBJECT-TYPE

>>                 SYNTAX          OCTET STRING(SIZE(64))

>>                 MAX-ACCESS      read-create

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "This manager created the session.  Other managers

>>                 wishing to monitor the session defined by the tuple

>>                 <<session-net-addr, session-port, interface>, cannot
do

>>

>>                 so until this manager destroys the particular row;
these

>>                 semantics are forced by the 1:1 mapping of the row
index

>>                 to the session tuple enforced by
rtpSessionIndexTable."

>>                 ::= { rtpSessionEntry 5 }

>

>What this *says* is that two network managers may not simultaneously

>monitor the same set of objects at the same time. I would not suggest

>designing it that way - find a way that two managers can view the same
set

>of objects at any time, and apply whatever color of glasses are
necessary

>to produce it's viewpoint.


#23 I will revisit this.  We will do a MIB implementation for at least

one RTP monitor this summer.  My intent was to make the implementation 

simple.  I now think that restricting an object to a single manager is 
a

poor simplification.


>

>>         rtpSessionRowStatus OBJECT-TYPE

>>                 SYNTAX          RowStatus

>>                 MAX-ACCESS      read-create

>>                 STATUS          current

>>                 DESCRIPTION

>>                 "Session entries can be created by a manager."

>>                 ::= { rtpSessionEntry 6}

>

>I think we all agree that network managers can create a session. Your

>Description doesn't address the questions that the Textual Convention

>indicates it needs to. I would suggest that you re-read RFC 1903 pages
6-

17

>(the DESCRIPTION of the RowStatus Textual Convention, and make sure 
the

>points it raises are covered. For example, the objects here are read-

create

>- which may only be written during row creation, and which are
adjustable

>later?


#24 I will re-write the DESCRIPTION clauses to closely follow RFC 1903

requirements.


>

>

>>        rtpSessionIndexValue  OBJECT-TYPE

>>                 SYNTAX	      INTEGER(1..65535)

>>                 MAX-ACCESS    read-only

>>                 STATUS        current

>>                 DESCRIPTION

>>                 "Instance of rtpSessionIndex corresponds 1:1 with

>>                 {rtpSessionAddr,rtpSessionPort,rtpSessionIf}."

>>                 ::= { rtpSessionIndexEntry 1 }

>

>In this case, I would not expect to find addresses or ports anywhere
else.

>Define the session index, and then use it everywhere. This can help a
lot

>with the size of your OIDs, and therefore the amount of information
that

>GET-BULK can put into a single SNMP GET RESPONSE.

>

>


#25 I spent a fair amount of time considering this issue, and we 
elected

to follow the TCPConnTable approach and select indexes that 

uniquely-identify the conceptual row.  We only reduce the size of the

GET RESPONSE if the manager will not want to retrieve the 

session-address columns when the conceptual row is accessed.  We 
decided

that it is unlikely that columnar information is very useful without 
the

session-address information.  I suppose if queries were to be made for

information without need for the session identification, such as all

the rate values from the egress streams table, then replacing the 

index with an integer might permit a single SNMP GET RESPONSE on 
larger,

RTP intermediate-system tables. I'd like to get the opinion of some

developers of RTP translators or mixers on this question.


>>                 MANDATORY-GROUPS { rtpISGroup }

>>                 OBJECT rtpSessionAddr

>>                         MIN-ACCESS  read-only

>>                         DESCRIPTION "This is useful even if the 
agent

>>                                     chooses not support create
access."

>>                 OBJECT rtpSessionPort

>>                         MIN-ACCESS  read-only

>>                         DESCRIPTION "This is useful even if the 
agent

>>                                     chooses not support create
access."

>>                 OBJECT rtpSessionIf

>>                         MIN-ACCESS  read-only

>>                         DESCRIPTION "This is useful even if the 
agent

>>                                     chooses not support create
access."

>>                 OBJECT rtpSessionOwner

>>                         MIN-ACCESS  read-only

>>                         DESCRIPTION "This is useful even if the 
agent

>>                                     chooses not support create
access."

>>                 OBJECT rtpSessionRowStatus

>>                         MIN-ACCESS  not-accessible

>>                         DESCRIPTION "Not needed when Addr, Port, and
If

>>                                     cannot be created by manager."

>

>If you're going to make these optional, I would suggest telling me when
I

>need to implement them read-only, not that they are useful even if I
don't

>do SETs. If you don't implement SETs, I would suggest that
implementation

>of RowStatus is indeed optional.


#26 okay.  A person designing a translator told me that using a

SET to cause a system to receive RTCP for a particular session

was fine for a monitor, but not desirable for a translator.


>

>The IESG will require a security section. I would suggest that it read

>something like this:

>

>    In most cases, MIBs are not themselves security risks; If SNMP 

Security

>    is operating as intended, the use of a MIB to change the
configuration

>    of a system is a tool, not a threat. For a threat analysis of SNMP

>    Security, see RFC ZZZZ.

>

>Ask the O&M ADs, or Russ Mundy, what Security Analysis RFC you should

>reference.


#27 thanks, I'll do that.


>

>I need to run this through SMICng; I'll send you whatever comments it 

comes

>up with. One that I expect it to report is that you import RowStatus to 

the

>first module and don't use it.


#28 No, it did not complain about that at all


  C:\mibs\smic>type ..\rtp\rtp.inc

  -- rtp.inc is the include file for the RTP MIB

  -- IMPORTS


  #condInclude "rfc1442.inc" -- SNMPv2-SMI

  #condInclude "rfc1443.inc" -- SNMPv2-TC

  #condInclude "rfc1444.inc" -- SNMPv2-CONF

  #condInclude "rfc1213.inc" -- SNMPv2-MIB


  -- MIB module

  #condInclude "rtp.mi2" -- RTP MIB

  #condExcludeModule RTP-SYSTEM 0

  #condExcludeModule RTP-IS 0


  C:\mibs\smic>smicng rtp.inc

  Successful parsing


But I don't import RowStatus nor event SMI-TC in the first module.

You may be looking at the second module.



thanks, Mark

>

>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

=

>The surest sign that intelligent life exists elsewhere in the universe
is

>that it has never tried to contact us.

>				Calvin and Hobbes (Bill Watterson)

>

>

>

</bigger>



From rem-conf Wed May 14 01:20:31 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 01:20:30 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRZBf-0006wk-00; Wed, 14 May 1997 01:13:27 -0700
Date: Wed, 14 May 1997 04:13:15 -0400 (EDT)
From: JoeReback@aol.com
Message-ID: <970514041314_-963028240@emout03.mail.aol.com>
To: rem-conf@es.net
Subject: Re: Mbone newbie help
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Please help me if you can to unsubcribe from this forum.

unsubscribe rem-conf JoeReback@aol.com



From rem-conf Wed May 14 01:22:45 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 01:22:44 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRZFf-0006xV-00; Wed, 14 May 1997 01:17:35 -0700
Date: Wed, 14 May 1997 04:15:06 -0400 (EDT)
From: JoeReback@aol.com
Message-ID: <970514041506_942569456@emout12.mail.aol.com>
To: rem-conf@tmpmail.es.net
Subject:  Help!
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Kindly unsubcribe me from your forum

unsubscribe rem-conf JoeReback@aol.com



From rem-conf Wed May 14 08:26:42 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 08:26:41 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRfql-000172-00; Wed, 14 May 1997 08:20:19 -0700
Message-Id: <9705141519.AA01397@smtpnotes.pictel.com>
To: Rem-Conf <Rem-Conf@es.net>
From: Kaynam Hedayat/PicTel <Kaynam_Hedayat@smtpnotes.pictel.com>
Date: 14 May 97 11:14:43 EDT
Subject: rtpmon
Mime-Version: 1.0
Content-Type: Text/Plain
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Is there a Windows version of rtpmon available anywhere?  Thanks.


Kaynam



From rem-conf Wed May 14 08:30:42 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 08:30:41 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRg0U-0001IS-00; Wed, 14 May 1997 08:30:22 -0700
Message-Id: <3.0.32.19970514082359.006aa798@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 14 May 1997 08:31:32 -0700
To: Stephen Casner <casner@precept.com>, Fred Baker <fred@cisco.com>
From: Mark Baugher <mbaugher@rdrop.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: mbaugher@ideal.jf.intel.com, John_Du@ccm.jf.intel.com, snaudus@usrva.com, 
    scott bradner <sob@harvard.edu>, allyn romanow <allyn.romanow@eng.sun.com>, 
    Mike O'Dell <mo@uunet.uu.net>, John Curran <jcurran@bbnplanet.com>, 
    rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by agora.rdrop.com id 
                      IAA04435
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Fred,
  Thanks for reviewing the RTP MIB.  A previous response to your note=20
was truncated, so I'll break the message in two.  In addition to the=20
changes we'll make that are indicated below, there are at least two more=20
that are needed.

  o A "feedback" table that is built on-demand in the RTP sender from
    information gathered from the receiver reports (RR's) will be
    added.  Christian Huitema argued for this in Memphis, and=20
    I think people generally agreed with his arguments.
    This issue was raised in discussions with others prior to=20
    Memphis: Christian Maciocco thought it might be useful, and
    Karl Auerbach suggested that this table could be created as=20
    a side effect to a management SET operation, which is how
    we propose to do it.

  o The indexes will be given a MAX-ACCESS of not-accessible as
    mandated by RFC 1902.

My responses are numbered below, from 1 to 14.  Items 15 to 28
will be sent in a following message.

At 07:34 PM 5/3/97 -0700, Fred Baker wrote:
>
>First comment: I was unable to determine from the internet draft what
>mailing list comments on this MIB should go to (it is the AVT WG, but th=
e
>mailto URL is not in the document). Please forward these comments to the
>relevant list.

#1 I=92ll put the  mailto URL in the document.

>
>Second comment: I note that three authors are listed on the draft, but=20
only
>one in each of the two MODULE-IDENTITY statements. It's up to you, but I
>should think you'd want all three listed, as compilable schemas generall=
y
>omit the RFC from which the MIB is extracted.

#2 I followed the convention found in a number of MIBs such as IGMP,
IPMRoute, Application Management, and RFC 1907 SNMPv2 MIB where
only the person or persons who edited and compiled the MIB are=20
identified rather than the list of authors of the document.
Perkins & McGinnis recommend that "For IETF working groups, the=20
technical contacts should include the working group mailing list,=20
the chair, and the editor", p 86. =20

>
>> 4.1.1  An "RTP Session" is defined by an IP address and a pair of
>> transport-layer port numbers, this is a "Session Address".  There
>> is one Session Address for a multicast session and two for unicast.
>
>If it uses port numbers, it seems to me that it should use both IP
>Addresses; if not both IP Addresses, then it should not be both ports. T=
he
>port number is essentially as extention of the IP Address to identify a
>process (perhaps a listening process).

#3 There=92s one IP address and two port numbers, RTP and RTCP.  John and
Stan think we should just stick with the RFC definition from Section 3.2

RTP session: The association among a set of participants
        communicating with RTP. For each participant, the session is
        defined by a particular pair of destination transport addresses
        (one network address plus a port pair for RTP and RTCP). The
        destination transport address pair may be common for all
        participants, as in the case of IP multicast, or may be
        different for each, as in the case of individual unicast network
        addresses plus a common port pair. =20

>
>>4.1.2 An "RTP Data Stream" is a sequence of packets sent to the
>>even-numbered port of the RTP Session when UDP is used to transport
>>the RTP data. Data streams are uniquely identified within an RTP
>>Session by "SSRC" attributes.
>
>And what on God's green earth might an SSRC be? Is there a reference,
>perhaps, that defines this term? Would this by the Synchronization Sourc=
e
>Identifier described (not very well) in draft-rao-rtsp-00.txt? And tell=20
me,
>is it more understandable to say "SSRC Attribute" or "Synchronization
>Source Identifier."? You might reference section 3.2, Set Transport, of
>that document, where SSRC is defined in this manner:
>
>	SSRC: 32 bits
>
>	Identifies the synchronization source to be associated with the
>	data. This can be used for de-multiplexing by the client of data
>	received on the same port.

#4 I'll make a point of introducing a variable by its complete name=20
before using an abbreviation. =20

>
>Wouldn't it be simpler/more understandable to say "The number of
>packets/octets sent from this SSRC"?

#5 I=92ll change it.

>
>In RFC 1902, there is a requirement that the MIB describe, for each=20
counter
>or set of counters, when counting starts. I think the requirement is
>brain-dead - show me a counter in any MIB that doesn't start counting wh=
en
>the column containing it is created - but you're supposed to say either =
in
>the description of the Table OBJECT-TYPE or in each Counter32 in the MIB
>"... since the creation of the column of objects". So I would make both =
of
>these read "The number of packets/octets sent from this SSRC since the
>creation of the data stream."

#6 I will modify the counter descriptions accordingly.

>
>7.1.6.  Counter32
>
>   The Counter32 type represents a non-negative integer which
>   monotonically increases until it reaches a maximum value of 2^32-1
>   (4294967295 decimal), when it wraps around and starts increasing
>   again from zero.
>
>   Counters have no defined "initial" value, and thus, a single value of
>   a Counter has (in general) no information content.  Discontinuities
>   in the monotonically increasing value normally occur at re-
>   initialization of the management system, and at other times as
>   specified in the description of an object-type using this ASN.1 type.
>   If such other times can occur, for example, the creation of an object
>   instance at times other than re-initialization, then a corresponding
>   object should be defined with a SYNTAX clause value of TimeStamp (a
>   textual convention defined in [3]) indicating the time of the last
>   discontinuity.
>
>   The value of the MAX-ACCESS clause for objects with a SYNTAX clause
>   value of Counter32 is either "read-only" or "accessible-for-notify".
>
>   A DEFVAL clause is not allowed for objects with a SYNTAX clause value
>   of Counter32.
>
>>         rtpEgTool OBJECT-TYPE
>>                 SYNTAX          OCTET STRING (SIZE(1..128))
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "State variable names the tool sourcing the stream."
>>                 ::=3D { rtpEgEntry 8 }
>
>In what sense is this a "state variable"? If it were a state variable, I
>would expect it to enumerate the states it might take, and in some sense
>define them.
>

#7 I think you are right when you say that "state variable"=20
usually refers to enumerations in published MIB=92s.  I am=20
using it to describe an object that takes on values dynamically
as opposed to one that is  static (Perkins & McGinnis describe
objects in these terms in their chapter on MIB design, p. 197). =20
Payload Type and Tool are two objects that could be mistaken as=20
being static for an RTP session rather than objects that may=20
change value dynamically during normal stream operation.  This
is an issue for the object model.  There's no need to keep
"state variable", "attribute" or "statistic"  in the DESCRIPTION
clauses.  They are obviously confusing relics of discussions that
John, Stan and I had when designing the MIB.

>Should this not read "the name of the tool sourcing the stream", and hav=
e
>the syntax DisplayString? RFC 1903 has a full definition of a
>DisplayString, but in general it means "Ascii Text", and any OCTET STRIN=
G
>that contains ASCII text is generally a DisplayString. Here are the firs=
t
>couple of lines.

#8 Yes, I=92ll change it.


>>         rtpEgInactiveTime   OBJECT-TYPE
>>                 SYNTAX          Gauge32
>>                 UNITS           "milliseconds"
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "Elapsed time since last stream packet."
>>                 ::=3D { rtpEgEntry 9 }
>
>Hmmmmmmmmmmmmmmmmmmmmm. <hand scratches stubbly beard...>
>
>As a general rule, SNMP MIBs have tried to avoid information which was
>ephemeral in nature. This item seems ephemeral. If you had a timestamp, =
it
>could be understood in reference to other timestamps, and a simple
>difference would give you the period of time you are seeking. But making
>the object produce a period of time - well, time since when? When I read
>this value, how much time has elapsed between the time the GET succeeded
>and the time the NMS received the GET RESPONSE containing the value? Is=20
the
>amount of time since the last packet 13 milliseconds, or is it 13
>milliseconds plus an intervening 51 milliseconds that it took to get
>through a router's congested queue en route back to me? Or was that 151
>milliseconds? Are you certain that another packet didn't arrive while I
>wasn't looking?

#9 This is taken from RFC 1889.
start of RFC 1889 excerpt...
6.2.1 Maintaining the number of session members
[...]

   Once a site has been validated, then if it is later marked inactive
   the state for that site should still be retained and the site should
   continue to be counted in the total number of sites sharing RTCP
   bandwidth for a period long enough to span typical network
   partitions.  This is to avoid excessive traffic, when the partition
   heals, due to an RTCP report interval that is too small. A timeout of
   30 minutes is suggested. Note that this is still larger than 5 times
   the largest value to which the RTCP report interval is expected to
   usefully scale, about 2 to 5 minutes.
...so the time scale is on the order of tens of minutes
>
>I would have expected that it would have the semantics "time of the last
>packet, measured in <time units> past some epoch". RFC 1903's TimeStamp
>Textual Convention would give you a way to read the time of the last=20
packet
>received, and the MIB-II object sysUpTime out give you the current value=
;
>the difference is the time since the last packet in 10 millisecond units.
>If what you are trying to obtain is that, I would suggest that encoding.
>
>TimeStamp ::=3D TEXTUAL-CONVENTION
>    STATUS       current
>    DESCRIPTION
>            "The value of the sysUpTime object at which a specific
>            occurrence happened.  The specific occurrence must be
>            defined in the description of any object defined using this
>            type."
>    SYNTAX       TimeTicks
>
>If you really need a Time Interval here, I would suggest using RFC 1903'=
s
>TimeInterval Textual Convention as the Syntax:
>
>TimeInterval ::=3D TEXTUAL-CONVENTION
>    STATUS       current
>    DESCRIPTION
>            "A period of time, measured in units of 0.01 seconds."
>    SYNTAX       INTEGER (0..2147483647)
>

#10 Is a coupling to SysUpTime really needed given the definition
of InactiveTime given above?=20

>>        rtpInLocalSSRC OBJECT-TYPE
>>                 SYNTAX          INTEGER(1..4294967295)
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "Identifies receiver/participant."
>>                 ::=3D { rtpInEntry 3}
>
>I'm probably showing my ignorance here. Identifies it in what way? Where
>would I find the send of words that "SSRC" is supposed to expand to?
>Perhaps a REFERENCE clause would be in order on this. In saaid Reference
>clause, please do not say "reference [1] section 3.2 SET TRANSPORT", as=20
the
>MIB is often divorced from its surrounding text. Rather, make it be "Rea=
l
>Time Transport Protocol, Section 3.2, SET Transport."
>

#11 Maybe I should add SMI REFERENCE clauses here and at a few other=20
places in the draft.  For LocalSSRC, the reference is "6.3.2 RR:=20
Receiver report RTCP packet" that shows the following diagram.


 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=3D2|P|    RC   |   PT=3DRR=3D201   |             length            | h=
eader
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     SSRC of packet sender                     |
+=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+
|                 SSRC_1 (SSRC of first source)                 | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost |       cumulative number of packets lost       |   1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           extended highest sequence number received           |


Note that there are two SSRC=92s in the RR.  The "SSRC of packet sender"=20
refers to the receiver, The second SSRC, labeled SSRC_1 and repeated=20
for each report block, is that of the source of the RTP packets.  Thus a
"Synchronization Source" may source RTP or RTCP.  We index ingress=20
streams by this pair of SSRC=92s in the RTP MIB (coupled with the
session address).

>By the way, since I have run off and found that text, I have a comment o=
n
>the RTP Spec: put paragraph numbers on these blooming messages! It would=
=20
be
>easier to reference "Section 3.2.3" than referencing the sub-head under
>section 3.2. And I suspect that there is something in a Synchronization
>Source that is worth identifying further than a footnote in an identifie=
r
>in a message - one can apparently multiplex several synchronizing source=
's
>data streams onto a single UDP port, and the semantics of that should be=
 a
>tad more obvious. Does a synchronization source correspond to a physical
>microphone or video codec? Might a transmission source have stereo
>microphones mixed in its audio stream? Is this about separating the=20
"left",
>"right", and "woofer"? How is this really used, quite apart from jargon
>about "attributes" and "16 bit numbers"?
>

#12 From Section 3.2 of the RTP spec we have the following definition.

 Synchronization source (SSRC): The source of a stream of RTP packets,
        identified by a 32-bit numeric SSRC identifier carried in the
        RTP header so as not to be dependent upon the network address.
        All packets from a synchronization source form part of the same
        timing and sequence number space, so a receiver groups packets
        by synchronization source for playback. Examples of
        synchronization sources include the sender of a stream of
        packets derived from a signal source such as a microphone or a
        camera, or an RTP mixer (see below). A synchronization source
        may change its data format, e.g., audio encoding, over time. The
        SSRC identifier is a randomly chosen value meant to be globally
        unique within a particular RTP session (see Section 8). A
        participant need not use the same SSRC identifier for all the
        RTP sessions in a multimedia session; the binding of the SSRC
        identifiers is provided through RTCP (see Section 6.4.1).  If a
        participant generates multiple streams in one RTP session, for
        example from separate video cameras, each must be identified as
        a different SSRC.

I bet you read this already.  Steve Casner said he was going to post a=20
response, so I'll defer to him on the questions you raise here.  When=20
we were designing the MIB we also took into account use of the SSRC to=20
identify the source of a receiver report, and its use for identifying=20
loops that could be introduced by translators as explained in section 8=20
of the RTP spec.

>>        rtpInPT OBJECT-TYPE
>>                 SYNTAX          INTEGER(1..128)
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "Payload Type state variable."
>>                 ::=3D { rtpInEntry 5 }
>
>State Variable? For what state machine? I think this is a payload type. =
I
>think the payload types should also be enumerated:
>
>		SYNTAX { NewURL(1), GotoURL(2) }
>

#13 We can=92t enumerate the payload types since they can be dynamic.
>From section 5.1 of RFC 1889:

payload type (PT): 7 bits
        This field identifies the format of the RTP payload and
        determines its interpretation by the application. A profile
        specifies a default static mapping of payload type codes to
        payload formats. Additional payload type codes may be defined
        dynamically through non-RTP means (see Section 3). An initial
        set of default mappings for audio and video is specified in the
        companion profile Internet-Draft draft-ietf-avt-profile, and
        may be extended in future editions of the Assigned Numbers RFC
        [6].  An RTP sender emits a single RTP payload type at any given
        time; this field is not intended for multiplexing separate media
        streams (see Section 5.2).

>and given a reference
>
>		REFERENCE
>		  "Real Time Streaming Protocol(RTSP) Section 3.3"
>

#14 Here is a rewrite of the  object.

        rtpInPT OBJECT-TYPE
                 SYNTAX          INTEGER(1..128)
                 MAX-ACCESS      read-only
                 STATUS          current
                 DESCRIPTION
                 "The Payload Type of the stream that may assume
                  different values over time."
                 REFERENCE
                  "Real-Time Transport Protocol, Section 5.1"
                 ::=3D { rtpInEntry 5 }

continued in a message to follow this one.




From rem-conf Wed May 14 08:33:44 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 08:33:43 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRg2s-0001V3-00; Wed, 14 May 1997 08:32:50 -0700
Message-Id: <3.0.32.19970514083400.006aa798@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 14 May 1997 08:34:02 -0700
To: Stephen Casner <casner@precept.com>, Fred Baker <fred@cisco.com>
From: Mark Baugher <mbaugher@rdrop.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: mbaugher@ideal.jf.intel.com, John_Du@ccm.jf.intel.com, snaudus@usrva.com, 
    scott bradner <sob@harvard.edu>, allyn romanow <allyn.romanow@eng.sun.com>, 
    Mike O'Dell <mo@uunet.uu.net>, John Curran <jcurran@bbnplanet.com>, 
    rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

here are points 15 through 28.
>>
>>         rtpInRemoteCNAME OBJECT-TYPE
>>                 SYNTAX          OCTET STRING (SIZE(1..128))
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "attribute uniquely identifies receiver/participant."
>>                 ::= { rtpInEntry 6 }
>
>DisplayString? Isn't this "The name of the receiver or participant"? Would

#15  Yes, display string.  We now have a working RTP management entity
and agent (on windows); we have found that we must refine the syntax
and in some cases  use display hints to get what we want from 
browsers on some common network management platforms. I would change
the syntax to the following.  

        rtpInRemoteCNAME OBJECT-TYPE
                 SYNTAX          DisplayString (SIZE(1..256))
                 MAX-ACCESS      read-only
                 STATUS          current
                 DESCRIPTION
                 "The canonical name of the participant who is
                 receiving this RTP stream, unchanging and 
                 unique to the session."
                 REFERENCE
                  "Real-Time Transport Protocol, section 6.4.1"
                 ::= { rtpInEntry 6 }

I also found some inconsistencies on sizes between the MIB and the
spec that we'll fix.

>a receiver have a different name with respect to each session he receives?
>It seems (and here I show great ignorance) that if the remoteAddr is the 
IP
>address of the sender this receiver is listening to, and remotePort is the
>source port that remote sender is using, RemoteCNAME would be the remote
>sender's name, on a session received at this receiver. What am I missing
>here?
>
>>        rtpInFracLost OBJECT-TYPE
>>                 SYNTAX          Gauge32
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "Statistic identifies the fraction of lost packets in
>>                 the receive stream relative to the total packets."
>>                 ::= { rtpInEntry 9 }
>
>suggestion: this encoding, while intuitive, is too limiting in utility.
>Fraction as measured over what interval? The whole session? The past 5
>seconds since I changed the encoding to reduce packet rate? Can I have
>three meters running simultaneously showing both?

#16 Every statistic and most other information in the MIB come directly 
>from RTP or RTCP messages.  And these are defined in the spec.   In fact,
most MIB variables come from RTCP messages, Receiver Reports, Sender 
Reports and SDES.  Fraction lost is defined on page 25 of the RTP spec.
This appears in the Ingress Streams table of the MIB so it refers to a 
single incoming stream for its total duration.  You're right, I am 
supposed to state when counting starts.

>
>I'd suggest keep a count of packets received and a count of packets known
>to have been lost. The sum is nominally the number of packets the sender
>sent. The fraction lost is therefore
>
>	  (Delta InLostPackets)
>   ---------------------------------------
>   (Delta InLostPackets + Delta InPackets)
>
>over the time interval that the network manager chooses to use. The 
network
>management station can select any interval it likes, and three viewing
>network management applications - or three plots on the same graph - can
>use three different intervals if it suits them.
>
>>
>>        rtpInLostPackets OBJECT-TYPE
>>                 SYNTAX          Counter32
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "Statistic identifies the total number of packets
>>                 lost from the receive stream."
>
>Number lost since when? See previous note on counters...

#17 refer to #6

>
>>        rtpInTool OBJECT-TYPE
>>                 SYNTAX          OCTET STRING (SIZE(1..128))
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "optional tool identifier state variable."
>>                 ::= { rtpInEntry 12 }
>
>"The name of the tool". Why is this optional? If implementation of the
>object is not optional (if "optional" means "name will be displayed if I
>know it"), in what way is *the*object* optional? Would it be better to say
>
>	"the name of the originating tool if known. If unknown, the object
>	 returns a string which contains zero octets."

#18 Yes, I agree.

>
>ASCII Text is DisplayString.
>
>>         rtpInInactiveTime   OBJECT-TYPE
>>                 SYNTAX          Gauge32
>>                 UNITS           "milliseconds"
>>                 MAX-ACCESS      read-only
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "Elapsed time since last stream packet."
>>                 ::= { rtpInEntry 13 }
>
>TimeStamp or TimeInterval, as in the Eg table.
>

#19  Same as #10 

>>         rtpSystemCompliance MODULE-COMPLIANCE
>>                 STATUS          current
>>                 DESCRIPTION     "All objects are mandatory with the
>>                                  the exceptions listed below."
>>                 MODULE RTP-SYSTEM
>>                 MANDATORY-GROUPS { rtpSystemGroup }
>>                 OBJECT rtpInPT
>>                         MIN-ACCESS  not-accessible
>>                         DESCRIPTION "This object is not always
>>                                      obtainable, and is optional"
>>                 OBJECT rtpInTool
>>                         MIN-ACCESS  not-accessible
>>                         DESCRIPTION "This object is not always
>>                                      obtainable, and is optional"
>>                 OBJECT rtpEgPT
>>                         MIN-ACCESS  not-accessible
>>                         DESCRIPTION "This object is not always
>>                                      obtainable, and is optional"
>>                 OBJECT rtpEgTool
>>                         MIN-ACCESS  not-accessible
>>                         DESCRIPTION "This object is not always
>>                                      obtainable, and is optional"
>
>I'm not sure this is the best way to handle this. "Optional", in a
>compliance statement, means that someone doesn't have to implement the
>object. If you don't have to implement the object, I would prefer you
>didn't define it, because you have to assume that the typical
>implementation will not. But I think you don't mean that - I think you 
mean
>"if I don't know the answer, I am going to answer "noSuchObject" in

#20 Don't you mean "noSuchInstance" rather than noSuchObject?   If the
entity acting as an agent implements the object but there is no value
for it yet, then it returns noSuchInstance (RFC 1905, 4.2.1).
I see your point, however, just because there's no value does not
make the object optional - this is probably the case for Tool, 
but that's not the case for Payload Type (more below).

>response to a GET, but if I do know the answer, I will answer with the
>name." That is not optional implementation (the meaning of "optional" in a
>compliance statement), it is reporting that you only sometimes have a 
scrap
>of information. Knowing that you don't know and saying so in some cases,
>and reporting a value in others, requires the object to in fact have been
>implemented. If I understand what you're asking for, these objects are not
>optional.
>

#21 Here's what we intended:  An RTP Monitor may only receive the RTCP 
(it opens a socket on the RTCP port, but not the RTP port, a reasonable 
behavior for an RTP Monitor) so the Payload Type which is carried in the
RTP header may not be available to the entity. In this case,  
noSuchObject would be the response I would expect for a Get on the 
Payload Time object when the entity acting as an agent does not 
implement the object.  I don't think noSuchObject is the correct 
response for Tool, since values may exist for one session but not for 
another; one application tool may identify itself but another may 
not.  

In the Tool case, therefore, a MIN-ACCESS is not needed.  I will change 
its compliance.  In the Payload Type case, its compliance
should remain the same, a MIN-ACCESS of not-accessible.  Now there is 
no ambiguity:  If noSuchObject is returned then the entity does not 
implement the object; if noSuchInstance is returned, then the entity 
implements the object but the object does not have a value to be 
returned.

>>         rtpSessionIf OBJECT-TYPE
>>                 SYNTAX          OCTET STRING (SIZE(4..16))
>>                 MAX-ACCESS      read-create
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "The local interface network address where RTP
>>                 data packets are sent and received for session."
>>                 ::= { rtpSessionEntry 4}
>
>How do you handle unnumbered interfaces? Do you use the RouterId? Would it
>be better to have two objects - one the IP Address or RouterId, and one 
the
>ifIndex of the interface?
>

#22 Yes, I think this is a problem since this object is intended to be 
used for translators, and tunnels may terminate in translators.


>>         rtpSessionOwner OBJECT-TYPE
>>                 SYNTAX          OCTET STRING(SIZE(64))
>>                 MAX-ACCESS      read-create
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "This manager created the session.  Other managers
>>                 wishing to monitor the session defined by the tuple
>>                 <session-net-addr, session-port, interface>, cannot do
>>
>>                 so until this manager destroys the particular row; these
>>                 semantics are forced by the 1:1 mapping of the row index
>>                 to the session tuple enforced by rtpSessionIndexTable."
>>                 ::= { rtpSessionEntry 5 }
>
>What this *says* is that two network managers may not simultaneously
>monitor the same set of objects at the same time. I would not suggest
>designing it that way - find a way that two managers can view the same set
>of objects at any time, and apply whatever color of glasses are necessary
>to produce it's viewpoint.

#23 I will revisit this.  We will do a MIB implementation for at least
one RTP monitor this summer.  My intent was to make the implementation 
simple.  I now think that restricting an object to a single manager is a
poor simplification.

>
>>         rtpSessionRowStatus OBJECT-TYPE
>>                 SYNTAX          RowStatus
>>                 MAX-ACCESS      read-create
>>                 STATUS          current
>>                 DESCRIPTION
>>                 "Session entries can be created by a manager."
>>                 ::= { rtpSessionEntry 6}
>
>I think we all agree that network managers can create a session. Your
>Description doesn't address the questions that the Textual Convention
>indicates it needs to. I would suggest that you re-read RFC 1903 pages 6-
17
>(the DESCRIPTION of the RowStatus Textual Convention, and make sure the
>points it raises are covered. For example, the objects here are read-
create
>- which may only be written during row creation, and which are adjustable
>later?

#24 I will re-write the DESCRIPTION clauses to closely follow RFC 1903
requirements.

>
>
>>        rtpSessionIndexValue  OBJECT-TYPE
>>                 SYNTAX	      INTEGER(1..65535)
>>                 MAX-ACCESS    read-only
>>                 STATUS        current
>>                 DESCRIPTION
>>                 "Instance of rtpSessionIndex corresponds 1:1 with
>>                 {rtpSessionAddr,rtpSessionPort,rtpSessionIf}."
>>                 ::= { rtpSessionIndexEntry 1 }
>
>In this case, I would not expect to find addresses or ports anywhere else.
>Define the session index, and then use it everywhere. This can help a lot
>with the size of your OIDs, and therefore the amount of information that
>GET-BULK can put into a single SNMP GET RESPONSE.
>
>

#25 I spent a fair amount of time considering this issue, and we elected
to follow the TCPConnTable approach and select indexes that 
uniquely identify the conceptual row.  We only reduce the size of the
GET RESPONSE if the manager will not want to retrieve the 
session-address columns when the conceptual row is accessed.  We decided
that it is unlikely that columnar information is very useful without the
session-address information.  I suppose if queries were to be made for
information without need for the session identification, such as all
the rate values from the egress streams table, then replacing the 
index with an integer might permit a single SNMP GET RESPONSE on larger,
RTP intermediate-system tables. I'd like to get the opinion of some
developers of RTP translators or mixers on this question.

>>                 MANDATORY-GROUPS { rtpISGroup }
>>                 OBJECT rtpSessionAddr
>>                         MIN-ACCESS  read-only
>>                         DESCRIPTION "This is useful even if the agent
>>                                     chooses not support create access."
>>                 OBJECT rtpSessionPort
>>                         MIN-ACCESS  read-only
>>                         DESCRIPTION "This is useful even if the agent
>>                                     chooses not support create access."
>>                 OBJECT rtpSessionIf
>>                         MIN-ACCESS  read-only
>>                         DESCRIPTION "This is useful even if the agent
>>                                     chooses not support create access."
>>                 OBJECT rtpSessionOwner
>>                         MIN-ACCESS  read-only
>>                         DESCRIPTION "This is useful even if the agent
>>                                     chooses not support create access."
>>                 OBJECT rtpSessionRowStatus
>>                         MIN-ACCESS  not-accessible
>>                         DESCRIPTION "Not needed when Addr, Port, and If
>>                                     cannot be created by manager."
>
>If you're going to make these optional, I would suggest telling me when I
>need to implement them read-only, not that they are useful even if I don't
>do SETs. If you don't implement SETs, I would suggest that implementation
>of RowStatus is indeed optional.

#26 okay.  A person designing a translator told me that using a
SET to cause a system to receive RTCP for a particular session
was fine for a monitor, but not desirable for a translator.

>
>The IESG will require a security section. I would suggest that it read
>something like this:
>
>    In most cases, MIBs are not themselves security risks; If SNMP 
Security
>    is operating as intended, the use of a MIB to change the configuration
>    of a system is a tool, not a threat. For a threat analysis of SNMP
>    Security, see RFC ZZZZ.
>
>Ask the O&M ADs, or Russ Mundy, what Security Analysis RFC you should
>reference.

#27 thanks, I'll do that.

>
>I need to run this through SMICng; I'll send you whatever comments it 
comes
>up with. One that I expect it to report is that you import RowStatus to 
the
>first module and don't use it.

#28 No, it did not complain about that at all

  C:\mibs\smic>type ..\rtp\rtp.inc
  -- rtp.inc is the include file for the RTP MIB
  -- IMPORTS

  #condInclude "rfc1442.inc" -- SNMPv2-SMI
  #condInclude "rfc1443.inc" -- SNMPv2-TC
  #condInclude "rfc1444.inc" -- SNMPv2-CONF
  #condInclude "rfc1213.inc" -- SNMPv2-MIB

  -- MIB module
  #condInclude "rtp.mi2" -- RTP MIB
  #condExcludeModule RTP-SYSTEM 0
  #condExcludeModule RTP-IS 0

  C:\mibs\smic>smicng rtp.inc
  Successful parsing

But I don't import RowStatus nor reference SMI-TC in the first module.
You may be looking at the second module.

I appreciate the time you took reviewing the document, and regret it
took me over a week to respond to you.


thanks, Mark
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
>The surest sign that intelligent life exists elsewhere in the universe is
>that it has never tried to contact us.
>				Calvin and Hobbes (Bill Watterson)
>
>
>






From rem-conf Wed May 14 11:53:48 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 11:53:47 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRj6g-0002Xq-00; Wed, 14 May 1997 11:48:58 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v0300781faf9f9b790237@[171.69.128.118]>
In-Reply-To: <3.0.32.19970514082359.006aa798@agora.rdrop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 May 1997 11:48:00 -0700
To: Mark Baugher <mbaugher@rdrop.com>
From: Fred Baker <fred@cisco.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: Stephen Casner <casner@precept.com>, mbaugher@ideal.jf.intel.com, 
    John_Du@ccm.jf.intel.com, snaudus@usrva.com, 
    scott bradner <sob@harvard.edu>, allyn romanow <allyn.romanow@eng.sun.com>, 
    Mike O'Dell <mo@uunet.uu.net>, John Curran <jcurran@bbnplanet.com>, 
    rem-conf@es.net
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 8:31 AM -0700 5/14/97, Mark Baugher wrote:
>Perkins & McGinnis recommend that "For IETF working groups, the
>technical contacts should include the working group mailing list,
>the chair, and the editor", p 86.

was this statement ratified by the SNMP Working Group or the (then) NM Area
Director?

While Dave is clearly an expert on SNMP, I would be careful quoting him as
authoritative. He is not.

>#3 There=EDs one IP address and two port numbers, RTP and RTCP.  John and
>Stan think we should just stick with the RFC definition from Section 3.2

That I have no problem with. The fact that it didn't jump into my brain
shows my ignorance of RTP. But I'd like to see a REFERENCE clause pointing
me to that definition if you don't mind.

>#4 I'll make a point of introducing a variable by its complete name
>before using an abbreviation.

And put a REFERENCE to its definition...

>#7 I think you are right when you say that "state variable"
>usually refers to enumerations in published MIB's.  I am
>using it to describe an object that takes on values dynamically
>as opposed to one that is  static (Perkins & McGinnis describe
>objects in these terms in their chapter on MIB design, p. 197).

As I say, Dave is not authoritative. I think you should write documents
intended to be read by folks throughout the industry using language that is
used throughout the industry. Throughout the industry, a "state variable"
is one which stores the encoded state of a state machine. A variable which
takes its state dynamically is, throughout the industry, a "variable". One
which takes its state statically is a "configuration variable". I'd suggest
that if you want to check me on that, walk through Jones Farm and ask the
programmers. They'll be as ignorant as I when you refer to a character
string read from a passing message as a "state variable."

>#9 This is taken from RFC 1889.

An excellent place for a REFERENCE clause if you're going to keep it. I'll
refer you to my discussion with Steve Casner yesterday. Don't think of
yourself writing a MIB that will return this variable - you can do any
brain-dead thing in the agent. Think in terms of a network manager trying
to do something with the object.

Imagine that you're sitting 500 miles away, and your computational minions
are helping you deal with a situation wherein RTP is not getting from A to
B adequately. The great high pooh-bah is going bonkers because his phone or
video aren't working right, and his secretary is on the phone to get it
fixed now. What do you need to know to fix it? What do you need to know in
order to know that it has been fixed?

If this is only for a timeout, and the timeout is on the order of tens of
minutes, is there a reason for resistance to using standard TC's to
describe the time period?

>#10 Is a coupling to SysUpTime really needed given the definition
>of InactiveTime given above?

I understand *what* you are trying to do (now, although I would never have
gleaned that from the text in the MIB). What I am wondering about is why
you would be unwilling to express it in terms that all other MIBs express
time in? Using, for example, the TimeInterval TC?

>>If you really need a Time Interval here, I would suggest using RFC 1903's
>>TimeInterval Textual Convention as the Syntax:
>>
>>TimeInterval ::=3D TEXTUAL-CONVENTION
>>    STATUS       current
>>    DESCRIPTION
>>            "A period of time, measured in units of 0.01 seconds."
>>    SYNTAX       INTEGER (0..2147483647)
>>

>#13 We can't enumerate the payload types since they can be dynamic.

=46ine, but you can say "these are enumerated and this space is dynamic".
Your published RTP profiles enumerate payload types, and your MIB should
enumerate those values. Good greif, if there aren't agreements on what
these numbers mean, how does RTP communicate? If there are, why can't it go
in the MIB, so that everyone using the MIB doesn't have to go chase it
down? I guarantee that on an NMS, the payload type will read "H.261", not
"27.5".

>#16 Every statistic and most other information in the MIB come directly
>from RTP or RTCP messages.

So you can report to the network manager what RTCP is reporting to the
reciever. Think about it as a network manager, though. What does the
*network* *manager* need to know in order to manage his network?

Go back to my discussion of "over what period of time" and explain to me
why it should not be a Counter32?

>#25 I spent a fair amount of time considering this issue, and we elected
>to follow the TCPConnTable approach and select indexes that
>uniquely identify the conceptual row.

I think we're not communicating. As I understand the rtpSessionIndex table,
it tells me what session index maps to what ordered set of IP Addresses and
UDP Ports (why the interface? If routing changes, and you start receiving
them on another interface, why would this affect your MIB?). My comment was
that given this number, you should be able to reference it in other places
in the MIB, perhaps as an index, and not repeat IP and UDP information.



=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
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
				Calvin and Hobbes (Bill Watterson)





From rem-conf Wed May 14 12:36:03 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 12:36:02 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRjhR-0002v1-00; Wed, 14 May 1997 12:26:57 -0700
Date: Wed, 14 May 1997 12:26:24 -0700 (PDT)
From: "Michael F. Speer" <Michael.Speer@Eng.Sun.COM>
Reply-To: "Michael F. Speer" <Michael.Speer@Eng.Sun.COM>
Subject: PCMCIA Video Capture Cards ...
To: rem-conf@es.net
Cc: Michael.Speer@Eng.Sun.COM
Message-ID: <Roam.SIMC.2.0.6.863637984.12188.speer@valathar >
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Folks:

Does anybody now of any PCMCIA video capture cards that are supported in
Vic?  

Michael




From rem-conf Wed May 14 12:46:46 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 12:46:46 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRjxa-0003BA-00; Wed, 14 May 1997 12:43:38 -0700
From: Arch Mott <arch@cisco.com>
Message-Id: <199705141943.MAA12197@yorkie.cisco.com>
Subject: Re: PCMCIA Video Capture Cards ...
To: Michael.Speer@Eng.Sun.COM
Date: Wed, 14 May 1997 12:43:20 -0700 (PDT)
Cc: rem-conf@es.net
In-Reply-To: <Roam.SIMC.2.0.6.863637984.12188.speer@valathar > from "Michael F. Speer" at May 14, 97 12:26:24 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 457
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Michael F. Speer wrote:
> 
> 
> Folks:
> 
> Does anybody now of any PCMCIA video capture cards that are supported in
> Vic?  
> 
> Michael

 One of the cards mentioned on Isidor's page,

http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic/

 is the NogaTech conference card. I have sorta-kinda made it work, but not
reliably. I've been intending, in my copious spare time, to try to get the
NogaTech tech support guys and Isidor introduced to each other. 

-Arch.



From rem-conf Wed May 14 13:12:00 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 13:11:59 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRkKl-0003T7-00; Wed, 14 May 1997 13:07:35 -0700
Message-ID: <01BC6089.78A11560@apocalypse.teleeducation.nb.ca>
From: Dwight Spencer <spencer@teleeducation.nb.ca>
To: "Michael.Speer@Eng.Sun.COM" <Michael.Speer@Eng.Sun.COM>
Cc: "rem-conf@es.net" <rem-conf@es.net>
Subject: RE: PCMCIA Video Capture Cards ...
Date: Wed, 14 May 1997 17:08:38 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



while it's not a PCMCIA solution, I've had good success with  a Connectix
Quickcam and  Isidor's rebuild of vic.  

Running on a p120 laptop at 8 and  24bit color depths, I was able to 
send video from the quickcam with vic, over a 33.6 modem.

dwight.
==
dwight spencer				phone:  506 444 5389
internet services manager			fax:    506 444 4232
spencer@teleeducation.nb.ca

TeleEducation NB, 500 Beaverbrook Court,
Fredericton, NB, Canada, E3B 5H1

-----Original Message-----
From:	Arch Mott [SMTP:arch@cisco.com]
Sent:	Wednesday, May 14, 1997 4:43 PM
To:	Michael.Speer@Eng.Sun.COM
Cc:	rem-conf@es.net
Subject:	Re: PCMCIA Video Capture Cards ...

Michael F. Speer wrote:
> Does anybody now of any PCMCIA video capture cards that are supported in
> Vic?  

 One of the cards mentioned on Isidor's page,

http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic/

 is the NogaTech conference card. I have sorta-kinda made it work, but not
reliably. I've been intending, in my copious spare time, to try to get the
NogaTech tech support guys and Isidor introduced to each other. 

-Arch.





From rem-conf Wed May 14 15:02:44 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 15:02:44 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRm4y-00053p-00; Wed, 14 May 1997 14:59:24 -0700
Message-Id: <199705142207.PAA11464@icebox.vnd.tek.com>
To: "rem-conf@es.net" <rem-conf@es.net>
Cc: tedb@vnd.tek.com
From: "Ted Brunner 503.627.1317" <ted.brunner@tek.com>
Subject: mbone and firewalls
Date: Wed, 14 May 1997 15:07:18 -0700
Sender: tedb@vnd.tek.com
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Recently my company installed a new sort of firewall.
I learned about it when our MBONE connection went away.
The new firewall will not allow me to do what I had been doing.

I am now looking into how to bring the MBONE back in.
The plan I currently have is to install a proxy machine
with two interfaces, and run mrouted on it.
The external tunnel and the internal tunnel would
meet at this proxy.  I don't know, but would like to learn,
if this is a particularly good or bad thing to do.

Does anyone have some relevant experience they'd be willing
to share, or a pointer to a whitepaper or a discussion
of common techniques.

Thanks
Ted Brunner			Video and Networking Division
				Tektronix
				MS 50-490
ted.brunner@tek.com		14150 SW Karl Braun
503.627.1317			Beaverton OR 97005	
		



From rem-conf Wed May 14 17:25:04 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 17:25:03 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRoHO-0006Ic-00; Wed, 14 May 1997 17:20:22 -0700
Message-Id: <3.0.32.19970514171855.00ac93f8@ibeam.intel.com>
X-Sender: mbaugher@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 14 May 1997 17:18:57 -0700
To: Fred Baker <fred@cisco.com>, Stephen Casner <casner@precept.com>
From: Mark Baugher <mbaugher@mailbox.jf.intel.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: John_Du@ccm.jf.intel.com, snaudus@usrva.com, 
    scott bradner <sob@harvard.edu>, allyn romanow <allyn.romanow@eng.sun.com>, 
    Mike O'Dell <mo@uunet.uu.net>, John Curran <jcurran@bbnplanet.com>, 
    rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 09:34 PM 5/13/97 -0700, Fred Baker wrote:
>
>Hmm. I am aware of the port number coupling. I had no idea from what the
>MIB said that said coupling was what I was looking at. I would suggest
>clarifying the language. I have to say that, throughout the MIB, the
>language was as obscure as any document I have ever read.

We assumed that the person reading the MIB, implementing it, or writing 
an NMS managment application has access to the specifications - RFC 1889
and RFC 1890.  So we did not reproduce a description of the protocol
as this could lead to inconsistencies or misunderstandings.  
We want the RTP spec to be the reference for the protocol, not the RTP 
MIB document. But the RTP port information you mention is in both the 
I-D and the mib file.   Page 3 of the RTP MIB document contains the
following.


 4.1.2 An "RTP Data Stream" is a sequence of packets sent to the
 even-numbered port of the RTP Session when UDP is used to transport
 the RTP data. Data streams are uniquely identified within an RTP 
 Session by "SSRC" attributes.

The port numbers are not necessarily coupled since RTP does not necessarily
run on UDP.  On page 19 this was repeated in the Session port description.

        rtpSessionPort OBJECT-TYPE
                SYNTAX          INTEGER(1..65535)
                MAX-ACCESS      read-create
                STATUS          current
                DESCRIPTION
                "The destination transport-layer port of RTP Session 
                streams; this is the even port of the even-odd pair
                when UDP is used as the transport for RTP streams."
                ::= { rtpSessionEntry 3}

I think the lack of REFERENCES clauses caused you to spend more time 
on your review than should have been necessary.  Do you agree that
the solution is add REFERENCE clauses, not describe details of RTP 
in the DESCRIPTION clauses?
>
[...]

>
>That's not at all clear from the MIB. If they're absolute, why can't this
>be a Counter32 (monotonically increasing until the wrap point, where it
>wraps) instead of a Gauge32 (jumps up and down all over the place,
>representing the reading of a "dial" at whatever time it happens to have
>been read)?


The fraction lost is not monotonically  increasing, from page 25 of RFC 1889:

   fraction lost: 8 bits
        The fraction of RTP data packets from source SSRC_n lost since
        the previous SR or RR packet was sent, expressed as a fixed

So a Gauge32 type is used in the MIB for fraction lost since it will jump
up and down. 

>From page 26 of RFC 1889, the cumulative loss is monotonically increasing:

   cumulative number of packets lost: 24 bits
        The total number of RTP data packets from source SSRC_n that
        have been lost since the beginning of reception. 

A Counter32 is used in the MIB for this object.  There is no REFERENCE 
in these MIB object definitions so this is unclear.
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>The surest sign that intelligent life exists elsewhere in the universe is
>that it has never tried to contact us.
>				Calvin and Hobbes (Bill Watterson)
>
>
>
>



From rem-conf Wed May 14 17:25:29 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 17:25:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRoKw-0006It-00; Wed, 14 May 1997 17:24:02 -0700
Date: Wed, 14 May 1997 16:50:28 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Fred Baker <fred@cisco.com>
cc: Mark Baugher <mbaugher@rdrop.com>, John_Du@ccm.jf.intel.com, 
    snaudus@usrva.com, scott bradner <sob@harvard.edu>, 
    allyn romanow <allyn.romanow@eng.sun.com>, Mike O'Dell <mo@uunet.uu.net>, 
    John Curran <jcurran@bbnplanet.com>, rem-conf@es.net
Subject: Re: Real-Time Transport Protocol MIB Review
In-Reply-To: <v0300781faf9f9b790237@[171.69.128.118]>
Message-ID: <Pine.WNT.3.95.970514164825.-132915G-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Responses to Fred's comments in replies to me and to Mark:

> >The synchronization source is the source of a stream of packets.  It
> >may well correspond to a microphone whose signal has passed through an
> >audio codec.  A stereo signal could be sent as two separate data
> >streams identified by different SSRC id's, but stereo sound is
> >normally sent with interleaved samples.
> 
> those words would be good ones to find somewhere, either in 1889 or the
> MIB. Probably in 1889 and REFERENCEd in the MIB.

I think the first two sentences are covered by the SSRC definition.
The RTP A/V Profile in RFC 1890 discusses multichannel audio.

> >This seems like a good policy in general.  But putting in a timestamp
> >is only meaningful if the SNMP querier has the same time reference.
> 
> like sysUpTime?
...
> you can get the timestamp and sysUpTime in the same GET (a GET can GET as
> many objects as you like), so the difference issue doesn't wash.

I agree that, as in the case of packet loss counting, returning
absolute information is generally better than returning deltas.  I
would not object to the use of a timestamp if a good reference
timestamp is available.  But might there be trouble if sysUpTime is in
the "main" part of the MIB rather than in this application-specific
part?  Given the complexities of subagents, getting both sysUpTime and
this last-packet timestamp might be a problem.  Also, it might be a
problem for the application to have local access to sysUpTime to
calculate the timestamps, or at least in knowing that what it assumes
to be the system up time is the same as the base agent is using to
return sysUpTime.

Your alternate suggestion of experessing the interval in larger units
should also be workable.

> OK, I can see that. Can you see my point, however? The question from a
> network management station is not "what number was last reported in RTCP",
> it's "OK, I futzed with something, am I still losing packets? If so, at
> what rate? Is it better or worse?" Don't think of this is terms of reading
> the numbers that RTCP last produced, think in terms of "I am a network
> manager, some idiot is screaming on the phone that RTCP is reporting
> badness, and I want to do something about it. How can I tell what the
> effect of my actions are?"

Perhaps rtpInFracLost should be removed because, as you say, the
reporting interval is not relevant to the manager querying the MIB.
The manager can query the MIB twice separated by whatever interval is
appropriate, then calculate the loss fraction over that interval as we
were discussing in previous messages.  I don't see the RTCP statistic
"extended highest sequence number" in the MIB.  This needs to be added
in order to allow the loss fraction calculation.

Mark suggested that a new "feedback" table may to be added to the MIB
to report the information received in RTCP Reception Reports.  If so,
then it would make sense to include the loss fraction from that RTCP
report in that section because, if the RTCP interval is long, multiple
queries to the MIB will return the same numbers each time for packets
lost and highest sequence number until another RTCP packet is
received.

> >#13 We can't enumerate the payload types since they can be dynamic.
> 
> Fine, but you can say "these are enumerated and this space is dynamic".
> Your published RTP profiles enumerate payload types, and your MIB should
> enumerate those values. Good greif, if there aren't agreements on what
> these numbers mean, how does RTP communicate? If there are, why can't it go
> in the MIB, so that everyone using the MIB doesn't have to go chase it
> down? I guarantee that on an NMS, the payload type will read "H.261", not
> "27.5".

There is an important point lurking in this question.  Is this a MIB
for RTP in general, or for RTP + A/V Profile?  The payload types are
enumerated in the profile, but in order for the MIB to include that
enumeration I would think there would need to be a profile-specific
section as well as an indication in the main section of which profile
is selected.  Selection of the profile is outside the scope of RTP
itself; it is a session parameter in SDP, where the static and dynamic
payload types are referenced to "RTP/AVP" with "AVP" indicating the
A/V Profile.  The binding of dynamic payload types to encoding names
is also in the session description.  That binding needs to be made
known to the RTP code by some means; it could be returned in
additional MIB objects if that makes sense.  On the other hand, the
authors of this MIB were trying to keep the number of objects from
getting out of hand.
							-- Steve




From rem-conf Wed May 14 17:59:57 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 17:59:56 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRopO-00072J-00; Wed, 14 May 1997 17:55:30 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v03007844afa00ca8a8ca@[171.69.128.118]>
In-Reply-To: <Pine.WNT.3.95.970514164825.-132915G-100000@oak.precept.com>
References: <v0300781faf9f9b790237@[171.69.128.118]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 14 May 1997 17:43:45 -0700
To: Stephen Casner <casner@precept.com>
From: Fred Baker <fred@cisco.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: Mark Baugher <mbaugher@rdrop.com>, John_Du@ccm.jf.intel.com, 
    snaudus@usrva.com, scott bradner <sob@harvard.edu>, 
    allyn romanow <allyn.romanow@eng.sun.com>, Mike O'Dell <mo@uunet.uu.net>, 
    John Curran <jcurran@bbnplanet.com>, rem-conf@es.net
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 4:50 PM -0700 5/14/97, Stephen Casner wrote:
>There is an important point lurking in this question.  Is this a MIB
>for RTP in general, or for RTP + A/V Profile?  The payload types are
>enumerated in the profile, but in order for the MIB to include that
>enumeration I would think there would need to be a profile-specific
>section as well as an indication in the main section of which profile
>is selected.

if it can't manage a real implementation, it's kind of pointless...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
				Calvin and Hobbes (Bill Watterson)





From rem-conf Wed May 14 18:00:01 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 18:00:00 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRopF-00072H-00; Wed, 14 May 1997 17:55:21 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v03007845afa00ceeb93f@[171.69.128.118]>
In-Reply-To: <3.0.32.19970514171855.00ac93f8@ibeam.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 14 May 1997 17:48:45 -0700
To: Mark Baugher <mbaugher@ideal.jf.intel.com>
From: Fred Baker <fred@cisco.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: Stephen Casner <casner@precept.com>, John_Du@ccm.jf.intel.com, 
    snaudus@usrva.com, scott bradner <sob@harvard.edu>, 
    allyn romanow <allyn.romanow@eng.sun.com>, Mike O'Dell <mo@uunet.uu.net>, 
    John Curran <jcurran@bbnplanet.com>, rem-conf@es.net
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 5:18 PM -0700 5/14/97, Mark Baugher wrote:
>We assumed that the person reading the MIB, implementing it, or writing
>an NMS managment application has access to the specifications - RFC 1889
>and RFC 1890.  So we did not reproduce a description of the protocol
>as this could lead to inconsistencies or misunderstandings.

that's generally a good assumption. But the network manager reading the MIB
and putting it into HP Openview may not even have the entire RFC that the
MIB is written in, not to speak of 1889. If you don't point him to the
reference, he doesn't know where to look.

the point is not implementors. The point is people using what implementors
produce to manage their network. MIBs are for managers, not implementors.

>Do you agree that
>the solution is add REFERENCE clauses, not describe details of RTP
>in the DESCRIPTION clauses?

yup

>The fraction lost is not monotonically  increasing, from page 25 of RFC 1889:
>
>   fraction lost: 8 bits
>        The fraction of RTP data packets from source SSRC_n lost since
>        the previous SR or RR packet was sent, expressed as a fixed
>
>So a Gauge32 type is used in the MIB for fraction lost since it will jump
>up and down.

and the time period is ________? and the way a network manager
simultaneously graphs the change in fraction lost over the last hour and
over the last minute is __________?


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The surest sign that intelligent life exists elsewhere in the universe is
that it has never tried to contact us.
				Calvin and Hobbes (Bill Watterson)





From rem-conf Wed May 14 19:21:12 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 19:21:11 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRq8J-000058-00; Wed, 14 May 1997 19:19:07 -0700
Message-Id: <199705150223.LAA26408@nanotsu.kobe-u.ac.jp>
To: "Michael F. Speer" <Michael.Speer@Eng.Sun.COM>
cc: rem-conf@es.net
Reply-To: oka@nanotsu.kobe-u.ac.jp
Subject: Re: PCMCIA Video Capture Cards ...
In-reply-to: Your message of Wed, 14 May 1997 12:26:24 MST. <Roam.SIMC.2.0.6.863637984.12188.speer@valathar >
Mime-Version: 1.0
Content-Type: text/plain;charset="ISO-2022-JP"
Date: Thu, 15 May 1997 11:23:07 +0900
From: Koji OKAMURA <oka@nanotsu.kobe-u.ac.jp>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


> Does anybody now of any PCMCIA video capture cards that are supported in
> Vic?  

IBM Smart Capture Card is the best card, I think.
It works on Linux/FreeBSD/BSDI. 
Of course I wrote its grabber for VIC.

The information is available on
http://www.mickey.ai.kyutech.ac.jp/~ohashi/scc/index.html

And very cool pictures are here,
http://www2.kobe-u.ac.jp/~oka/linux/index.html

--
Koji



From rem-conf Wed May 14 19:28:01 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 19:28:00 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRqGU-0000MC-00; Wed, 14 May 1997 19:27:34 -0700
From: Elan Amir <elan@mercenary.CS.Berkeley.EDU>
Message-Id: <199705150224.TAA20317@mercenary.CS.Berkeley.EDU>
To: oka@nanotsu.kobe-u.ac.jp
cc: "Michael F. Speer" <Michael.Speer@eng.sun.com>, rem-conf@es.net
Subject: Re: PCMCIA Video Capture Cards ...
In-reply-to: Your message of "Thu, 15 May 1997 11:23:07 +0900." <199705150223.LAA26408@nanotsu.kobe-u.ac.jp>
Date: Wed, 14 May 1997 19:24:53 -0700
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


> 
> > Does anybody now of any PCMCIA video capture cards that are supported in
> > Vic?  
> 
> IBM Smart Capture Card is the best card, I think.
> It works on Linux/FreeBSD/BSDI. 
> Of course I wrote its grabber for VIC.
> 
> The information is available on
> http://www.mickey.ai.kyutech.ac.jp/~ohashi/scc/index.html
> 
> And very cool pictures are here,
> http://www2.kobe-u.ac.jp/~oka/linux/index.html

Alas, as far as I know, unfortunately this card is only available in
Japan.  If *anyone* knows of a US location where one can buy one of
these - PLEASE send a message to the list.

Thanks,

-- Elan



From rem-conf Wed May 14 23:05:34 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 23:05:34 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRtat-0001Vd-00; Wed, 14 May 1997 23:00:51 -0700
From: Scott_Petrack@vocaltec.com
X-Lotus-FromDomain: VOCALTEC
To: rem-conf@es.net, conf-ctrl@isi.edu, voip-tech@vocaltec.com, 
    H323IMPLEMENTORS@mailbag.jf.intel.com, ETSI_VOIP@LIST.ETSI.FR
cc: pint@lists.research.bell-labs.com
Message-ID: <C2256498.001EB805.00@maskit1.vocaltec.co.il>
Date: Thu, 15 May 1997 08:59:48 +0200
Subject: Proposal for new IETF Working Group - "PSTN Internet Interworking " 
         (PINT)
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list






Scott Petrack
05/15/97 08:59 AM

At the previous IETF there was a BOF entitled "PSTN Internet Interworking."
The following just came to my attention, and I post it here because I think
that it might interest many members of these lists.

Please note that I cross posted this note to several list. The importance
of the subject (the formation of a new working group) seemed to justify
publication to anyone involved. It is not my intention to open a thread on
6 lists simultaneously! Please be careful if you reply.

Scott Petrack

-------- On 04/30/97 08:38 PM AST  faynberg@lucent.com  wrote:




 Ladies and Gentlemen:

 (This is the captain speaking from the cockpit. The seat-belt sign
is about to be turned off, and the refreshments will be served in a
moment-- in the rest of this message.)

 Thank you for your interest in PINT. Tom Limoncelly, our webmaster,
told me that we have 86 people on the list.  I think it is about the
right time to start the discussion.

 First of all, there is a PINT WWW home page, on which relevant
documents and archives will be maintained:

 http://www.bell-labs.com/mailing-lists/pint/

 Now the page has the PINT BOF meeting minutes, a copy of the
original draft, and a copy of the viewgraphs presented at the BOF. The
latter contain the figures relevant to the proposal. (I heard a few
complaints about the quality of the pictures in the draft; although my
co-authors and I
proudly maintain that we did the best one could with the text drawings,
we offer the viewgraphs as a more palatable replacement.)

 Right now, our primary goal is to produce a charter for the group-to-be.
The original proposal was to standardize protocols for the two interfaces
mentioned in the draft: one for the Web Server to the SCF (SN, to be
specific), and the other for the Web Server to Service Management System.
Note that the proposal is to support a few relatively simple services (e.
g., Click-to-Dial).

In private messages I got suggestions for increasing the scope of this
group to include the gateways for voice interconnection between the
Internet and PSTN. I would not refuse such a discussion as long as it is
accompanied by a draft with a specific proposal.  If we can generate
another charter, we may propose yet another group.  On the other hand, my
vision of the present group is that once it completes the work on the
original project (I think the proposed work should take 6 to 9 months), it
may undertake another project.

 I would like to take the first cut at formulating the group
charter, attached to this note. (There is a disclaimer there that this work
has nothing to do with call control. I suggest it should be there because
some people have bombarded Hui-Lan, Murali, and me with the hate mail
after reading the proposal. They hated what they saw as the proposal for
the third party call control (from the WWW server). NOTHING of the sort
is in the proposal--I hope that the disclaimer will exorcise the frightful
demon.

 Best regards,

  Igor Faynberg

 ATTACHMENT: Charter draft

The PINT Working Group will work on the specification of the Service
Support Transfer Protocol (SSTP?) between the World Wide Web server and the
PSTN Intelligent Network Service Node as well as the relevant MIB (SSTP
MIB?)
to support the service management protocol between the World Wide Web
server and the PSTN Service Management System. The SSTP is to be carried
over TCP; the SSTP MIB is to be carried over SNMP. The role of these
protocols is to support arange of Internet services by which a user of the
Internet may request termination of the PSTN call to his or her PSTN
terminal (i.e., telephone). The protocols are not intented to support any
form of the third-party call control or, for that matter, any type of call
control; their role is rather to securely carry call requests to the PSTN.
The  initial work is to document the existing practice and short-term
extensions; subsequent work may be to extend and revise the protocols.

The initial services to be supported are Click-to-Dial, Click-to-Fax,
Click-to-Fax-Back, and Voice access to content as described in
<draft-faynberg-telephone-sw-net-00.txt>.

Note: the PINT working group will address the SSTP security extensions.

  Background information:

The original draft, the presentation at the PINT BOF at the 38th IETF
Meeting, and the archives of the BOF discussion can be found on


Once established, the working group will work on completing the SSTP/1.0
and SSTP MIB/1.0 based on the current practice.

In parallel with the above effort, the working group will consider
enhancements and restrictions to the current practice in order to form a
specification of the SSTP protocol suitable for eventual consideration as a
proposed standard.

 Goals and Milestones:

One or more Internet-Drafts documenting current practice, should be
available by the 39th IETF Meeting in Munich, Germany, where they can be
reviewed. The SSTP/1.0 and SSTP MIB/1.0 are to be drafted based on the
current practice by January 1998. It is expected that the resultant draft
wil be submitted to for IESG for consideration as the Proposed Standard.

---------
This message came from the IETF PINT Working Group Mailing List.







From rem-conf Wed May 14 23:12:15 1997 
From rem-conf-request@tmpmail.es.net Wed May 14 23:12:15 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRtlT-0001o6-00; Wed, 14 May 1997 23:11:47 -0700
From: Scott_Petrack@vocaltec.com
X-Lotus-FromDomain: VOCALTEC
To: rem-conf@es.net
Message-ID: <C2256498.00214703.00@maskit1.vocaltec.co.il>
Date: Thu, 15 May 1997 09:11:10 +0200
Subject: PCMCIA full duplex sound cards?
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list






Scott Petrack
05/15/97 09:11 AM

Can anyone recommend a good full duplex PCMCIA sound card for vat/rat etc.
The only card I know is the NogaTech, and I am not too happy with it.

I am interested in FreeBSD and/or Windows95 drivers.

Alternatively, my laptop is a ThinkPad 560, with the ESS ES1688 audio chip.
(I have driver version 4.03.02) Has anyone found or build a driver to make
this thing full duplex?

Sincerely,

Scott Petrack





From rem-conf Thu May 15 00:42:26 1997 
From rem-conf-request@tmpmail.es.net Thu May 15 00:42:25 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wRv8p-0002a8-00; Thu, 15 May 1997 00:39:59 -0700
Message-Id: <3.0.32.19970515004128.006cf53c@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 15 May 1997 00:41:32 -0700
To: Fred Baker <fred@cisco.com>
From: Mark Baugher <mbaugher@rdrop.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: Stephen Casner <casner@precept.com>, mbaugher@ideal.jf.intel.com, 
    John_Du@ccm.jf.intel.com, snaudus@usrva.com, 
    scott bradner <sob@harvard.edu>, allyn romanow <allyn.romanow@eng.sun.com>, 
    Mike O'Dell <mo@uunet.uu.net>, John Curran <jcurran@bbnplanet.com>, 
    rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 11:48 AM 5/14/97 -0700, Fred Baker wrote:
>At 8:31 AM -0700 5/14/97, Mark Baugher wrote:
>>Perkins & McGinnis recommend that "For IETF working groups, the
>>technical contacts should include the working group mailing list,
>>the chair, and the editor", p 86.
>
>was this statement ratified by the SNMP Working Group or the (then) NM Area
>Director?

I'm not aware of authoritative guidelines for CONTACT-INFO apart from=20
RFC 1902, Section 5.3

   5.3.  Mapping of the CONTACT-INFO clause

      The CONTACT-INFO clause, which must be present, contains the name,
      postal address, telephone number, and electronic mail address of the
      person to whom technical queries concerning this information module
      should be sent.

>
>>#3 There=EDs one IP address and two port numbers, RTP and RTCP.  John and
>>Stan think we should just stick with the RFC definition from Section 3.2

this is a typo, I meant RFC 1889, Section 3.

>
>Imagine that you're sitting 500 miles away, and your computational minions
>are helping you deal with a situation wherein RTP is not getting from A to
>B adequately. The great high pooh-bah is going bonkers because his phone or
>video aren't working right, and his secretary is on the phone to get it
>fixed now. What do you need to know to fix it? What do you need to know in
>order to know that it has been fixed?

It's not so hypothetical:  We had a meeting of over 100 persons across three=
=20
sites on the West Coast yesterday.  We used an RTP application tool and an
RTP monitor.  We had a view on who was receiving what, where, and how well;
we identified a problem with a particular model of computer based on RTCP
reports coming from two locations where we knew that model was being used.
I happen to think that the design we took for the MIB of basing our=
 management
information largely on RTCP reports is what we need to do here.  I expect
we will have more discussion on this issue over the next day or so.=20

I can imagine turning the management function over to the NOC that sits=20
in a remote site and uses a particular set of network management tools,=20
Netview, Tivoli, OpenView or whatever.  They look for green, yellow or
red signals, and probably do not want to haul a lot of audio and video=20
multicast data to their particular location since it is the "central=20
nervous system" of the corporate network.  There will certainly be=20
corporate guidelines where multicast flows can or cannot go, so SNMP=20
polling of remote monitors sounds like a promising approach:  Let the=20
NOC get RTP monitors' data using its standard tools without putting RTP=20
monitors in the NOC.  This is one  scenario, and I don't know how=20
compelling a scenario it is.  There are problems with SNMP remote=20
monitoring, especially on switched networks, and some proprietary=20
solutions are being vigorously pursued instead.  And you may be=20
right that  we might not want to base our management approach on RTCP,=20
but my immediate (and limited) experience suggests otherwise.

>
>If this is only for a timeout, and the timeout is on the order of tens of
>minutes, is there a reason for resistance to using standard TC's to
>describe the time period?
>
>>#10 Is a coupling to SysUpTime really needed given the definition
>>of InactiveTime given above?
>
>I understand *what* you are trying to do (now, although I would never have
>gleaned that from the text in the MIB). What I am wondering about is why
>you would be unwilling to express it in terms that all other MIBs express
>time in? Using, for example, the TimeInterval TC?

Maybe it's naivete on my part.  But we put this SNMPv2 MIB on a very low end
NMS that was loaded with lots of SNMPv1 MIB files, standard and proprietary,
and it easily compiles because there are very few dependencies.  And=20
it works to an implementation that is instrumented for the RTP MIB using the
simple browser that comes with the NMS.  But when I load other SNMPv2 MIBs,=
=20
such as the multicast MIBs, int-serv, RSVP,  I have an enormous headache=20
getting them to compile because of many, albeit necessary, dependencies.=20
This is no reason for not using other MIBs when they are needed.  As our=20
NMS capabilities improve, my headaches will go away.  But if additional=20
dependencies can be avoided, then why not avoid them?

>
>>>If you really need a Time Interval here, I would suggest using RFC 1903's
>>>TimeInterval Textual Convention as the Syntax:
>>>
>>>TimeInterval ::=3D TEXTUAL-CONVENTION
>>>    STATUS       current
>>>    DESCRIPTION
>>>            "A period of time, measured in units of 0.01 seconds."
>>>    SYNTAX       INTEGER (0..2147483647)
>>>
>
>>#13 We can't enumerate the payload types since they can be dynamic.
>
>Fine, but you can say "these are enumerated and this space is dynamic".
>Your published RTP profiles enumerate payload types, and your MIB should
>enumerate those values. Good greif, if there aren't agreements on what
>these numbers mean, how does RTP communicate? If there are, why can't it go
>in the MIB, so that everyone using the MIB doesn't have to go chase it
>down? I guarantee that on an NMS, the payload type will read "H.261", not
>"27.5".

If it's a loosely-controlled conference, then maybe the 1890 bindings need
to be presented in the management app; if it's H.323 or some other
control protocol, then a different set of bindings are needed.  A good
NMS management application should probably be aware of the non-RTP means
that are being employed for the particular session.  This is beyond
the scope of RTP and its MIB in my opinion.  Even if the static payload
types are used, then what is the specific benefit of enumerating them
in the MIB?  The author of the management application will need to
have RFC 1890 or some other document on his or her knee to
interpret the values retrieved from the MIB and present them in the
desired form.

>
>Go back to my discussion of "over what period of time" and explain to me
>why it should not be a Counter32?

The RTP MIB is correct on this: Frac Lost is Gauge32, it's based on a=20
particular report interval, and Cumulative Loss is Counter32 since it is
cumulative from the start of the stream.  Now I guess we need to resolve
the usefulness of Fraction Lost to the MIB.

>
>>#25 I spent a fair amount of time considering this issue, and we elected
>>to follow the TCPConnTable approach and select indexes that
>>uniquely identify the conceptual row.
>
>I think we're not communicating. As I understand the rtpSessionIndex table,
>it tells me what session index maps to what ordered set of IP Addresses and
>UDP Ports (why the interface? If routing changes, and you start receiving
>them on another interface, why would this affect your MIB?). My comment was
>that given this number, you should be able to reference it in other places
>in the MIB, perhaps as an index, and not repeat IP and UDP information.

I don't understand which other places in the MIB it can be used.

Mark

>
>
>
>=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
>The surest sign that intelligent life exists elsewhere in the universe is
>that it has never tried to contact us.
>				Calvin and Hobbes (Bill Watterson)
>
>
>
>



From rem-conf Thu May 15 06:19:48 1997 
From rem-conf-request@tmpmail.es.net Thu May 15 06:19:47 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wS0MY-0003l2-00; Thu, 15 May 1997 06:14:30 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Thu, 15 May 1997 06:13:43 -0700 (PDT)
Message-Id: <199705151313.GAA21118@hille.msri.org>
To: rem-conf@es.net
From: multicast <multicast@dxcoms.cern.ch>
Reply-to: multicast@dxcoms.cern.ch
Subject: CERN ATLAS Sessions
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	CERN ATLAS Sessions
Date:        
	May 29, 1997

Time:        
	14:00 GMT+2 4 hours

Contact:     
	multicast@noc.cern.ch

URL:         
	http://sunmed2.cern.ch:8888/ATLAS_29-30_05_97.html

Description:        
	 ATLAS Plenary meeting









mbone broadcast schedule http://www.msri.org/mbone



From rem-conf Thu May 15 06:42:36 1997 
From rem-conf-request@tmpmail.es.net Thu May 15 06:42:36 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wS0mk-000445-00; Thu, 15 May 1997 06:41:34 -0700
Message-ID: <c=US%a=_%p=Intellect_Video_%l=MAILCOM-970515134307Z-795@mailcom.videoconferencing.com>
X-MS-TNEF-Correlator: <c=US%a=_%p=Intellect_Video_%l=MAILCOM-970515134307Z-795@mailcom.videoconferencing.com>
From: Matthew Feldman <mfeldman@VideoConferencing.com>
To: "'Michael F. Speer'" <Michael.Speer@Eng.Sun.COM>
Cc: "'rem-conf@es.net'" <rem-conf@es.net>
Subject: RE: PCMCIA Video Capture Cards ...
Date: Thu, 15 May 1997 09:43:07 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 26 TEXT, 42 UUENCODE
X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Is this NogaTech PCMCIA card supported?


Matthew Feldman
Chief Technology Officer
Intelect Visual Communications
(212) 317-9600

----------
From: 	Michael F. Speer[SMTP:Michael.Speer@Eng.Sun.COM]
Sent: 	Wednesday, May 14, 1997 3:26 PM
To: 	rem-conf@es.net
Cc: 	Michael.Speer@Eng.Sun.COM
Subject: 	PCMCIA Video Capture Cards ...


Folks:

Does anybody now of any PCMCIA video capture cards that are supported in
Vic?  

Michael





begin 600 WINMAIL.DAT
M>)\^(@D-`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <`
M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0<%``\`
M"0`K``<`! `G`0$@@ ,`#@```,T'!0`/``D`*P`'``0`)P$!"8 !`"$````R
M04$U.$-".# U0T1$,#$Q0C5!-S X,# R0CE%,4-$0@!#!P$-@ 0``@````(`
M`@`!!( !`",```!213H@4$--0TE!(%9I9&5O($-A<'1U<F4@0V%R9',@+BXN
M`& *`0.0!@#(!0``&@````,`+@``````0 `Y`!!X:>LU8;P!'@!P``$````?
M````4$--0TE!(%9I9&5O($-A<'1U<F4@0V%R9',@+BXN```"`7$``0```!L`
M```!O&">@;E]/ 'PR+P1T)*-`* DP.KF`"6GNO$``P`&$)$5+"L#``<06P$`
M`!X`"! !````90```$E35$A)4TY/1T%414-(4$--0TE!0T%21%-54%!/4E1%
M1#]-05142$571D5,1$U!3D-(245&5$5#2$Y/3$]'64]&1DE#15))3E1%3$5#
M5%9)4U5!3$-/34U53DE#051)3TY3*#(``````P`0$ `````#`!$0``````(!
M"1 !````A (``( "``!8!0``3%I&=>5LZ*7_``H!#P(5`J0#Y 7K`H,`4!,#
M5 (`8V@*P'-E=.XR!@`&PP*#,@/&!Q,"@S(S$P]F- 36`@!P<J)Q$B!-870(
M<&$%T(94!@`%!$-A<&D!D/1L<P*#-1$G%@,';0*#=C8/?Q"$?0J ",\)V3OQ
M'+\R-34"@ J!#;$+8.!N9S$P,Q0@"PH2\B4,`6,`0"!)!"!T:$,$``>P;V=A
M5 60: `@4$--0TE!(()C"Q$@<W5P<!QA_0F /PJ%)!P*^Q52`= 60L,AT ?1
M1F5L9 .!)/?W"V08,29B0R'@#< 9$")Q0FX<06=Y($\-T&GV8P20)/5)`C G
M, 60!4 Z5@0`=0= %U #<&UU4P,`(R!T:0(@<R3U* `R,3(I(#,Q-_ M.38P
M#? +51IB+:"').\@O2\+;&DQ."WQX2H@+3$T- WP#- R8VT+63$:8!8`;R/0
M*T$M7S2')YTSE0PP- 9&`V$Z_S6.- 8,@@70*C 1P"<P)Q"*+@8`< G@<EM3
M%L"44#HY12XY\T!%'\"#.Q L("Y#3TU=-2]?-CT&8 (P-V\X>U<)@&[A!Y!D
M87DL%D$IX#)@$4#P,3DY+N S.C*:-B*@33Q/-CU4;SZ/$SA[',!M+06@;F9 
M-0>0+D"0=$)?-CU#8S]$?SA_.N\[\D=//5YU8GYJ*S%);TI[(K4K< VP;[L7
M4A9Q91=1"R $("Y2T/LDCS&3,RW@"T84(@P!- 9%+P5&!O!K<SHD'$36;P>1
M`'!Y!N!D*> ID-T'X&\I,%@!(J9V4:,C(']2%",B(;(68%?P4D$C=R#'"X O
M!2MP8S\@)'TY15\D'U.O+^M5C1OA`&)P`P#Q/PD$```#`"8```````,`-@``
M`````@%'``$````X````8SU54SMA/2 [<#U);G1E;&QE8W0@5FED96\@.VP]
M34%)3$-/32TY-S U,34Q,S0S,#=:+3<Y-0`"`?D_`0```&$`````````W*= 
MR,!"$!JTN0@`*R_A@@$`````````+T\]24Y414Q,14-4(%9)1$5/($-/3D9%
M4D5.0TE.1R]/53U)5D,M3EE#+T-./5)%0TE0245.5%,O0TX]34%45$A%5T8`
M````'@#X/P$````0````36%T=&AE=R!&96QD;6%N``(!^S\!````80``````
M``#<IT#(P$(0&K2Y" `K+^&"`0`````````O3SU)3E1%3$Q%0U0@5DE$14\@
M0T].1D5214Y#24Y'+T]5/4E60RU.64,O0TX]4D5#25!)14Y44R]#3CU-0514
M2$571@`````>`/H_`0```! ```!-871T:&5W($9E;&1M86X`0 `','!]:>LU
M8;P!0 `(,+"YK.LU8;P!`P`--/T_```"`10T`0```! ```!4E*' *7\0&Z6'
M" `K*B47'@`]``$````%````4D4Z( `````+`"D```````L`(P```````@%_
M``$```!8````/&,]55,E83U?)7 ]26YT96QL96-T7U9I9&5O7R5L/4U!24Q#
M3TTM.3<P-3$U,3,T,S W6BTW.35 ;6%I;&-O;2YV:61E;V-O;F9E<F5N8VEN
)9RYC;VT^`%^(
`
end



From rem-conf Thu May 15 07:03:09 1997 
From rem-conf-request@tmpmail.es.net Thu May 15 07:03:08 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wS15G-0004LA-00; Thu, 15 May 1997 07:00:42 -0700
Message-Id: <9705151359.AA09826@dxcoms.cern.ch>
Subject: Mbone netcast of the LEPC meeting
To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, HRC@in2p3.fr, 
    htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch
Date: Thu, 15 May 1997 15:59:47 +0200 (MET DST)
From: Martin Fluckiger - CERN/CN/CS <fle@dxcoms.cern.ch>
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: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

          CERN is pleased to announce the MBONE broadcast of the

                      LEP Committee Open Session 
                      --------------------------

		 on Thursday 29 May 1997 at 09:00 (UTC+2)
			from the CERN Auditorium

Provisional Agenda:
-------------------

>>> Times are UTC+2 <<<

  OPEN SESSION: Thursday, 29 May 1997 at 09:00 h, Main Auditorium

	Reports on the LEP machine:
  09:00 - 09:30   Summary of 1997 Chamonix Workshop, and follow-up (Steve
  Myers)
	LEP2 physics prospects:
  09:30 - 10:00   Supersymmetry (John Ellis)
  10:00 - 10:30   High precision measurements of the Standard Model (David
  Charlton)
  10:30 - 11:00   Coffee break
	Reports on the LEP experiments:
  11:00 - 11:30   DELPHI (Tiziano Camporesi)
  11:30 - 12:00   L3 (Martin Pohl)
  12:00 - 12:30   OPAL (to be announced)
  12:30 - 13:00   ALEPH (Gigi Rolandi)


The broadcast is announced via sdr as "CERN LEPC". rat and vic applications
will be used with a ttl of 127.

In case of questions or problems please contact <multicast@noc.cern.ch>.

This message is sent to distribution lists, sorry if you receive multiple
copies of it.

Best regards,
--------------------------------------------------------------------
Martin Fluckiger & Christian Isnard                  CERN - CN/CS/EN
multicast@noc.cern.ch       European Laboratory for Particle Physics
Computers and Networks division      CH-1211 Geneva 23 - Switzerland




From rem-conf Thu May 15 07:03:10 1997 
From rem-conf-request@tmpmail.es.net Thu May 15 07:03:09 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wS17A-0004LR-00; Thu, 15 May 1997 07:02:40 -0700
Message-Id: <9705151401.AA14241@dxcoms.cern.ch>
Subject: Mbone netcast of the ATLAS sessions
To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, HRC@in2p3.fr, 
    htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch
Date: Thu, 15 May 1997 16:01:58 +0200 (MET DST)
From: Martin Fluckiger - CERN/CN/CS <fle@dxcoms.cern.ch>
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: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

          CERN is pleased to announce the MBONE broadcast of the

			     ATLAS Sessions
			     --------------

	       on Thursday and Friday 29/30 May 1997 (UTC+2)
			from the CERN Auditorium


>>> Times are UTC+2 <<<

Agenda for ATLAS sessions:
-------------------------

Thur. 29 May    14h00   ATLAS Plenary        Main aud.(pending LEPC)
		18h00   End

Frid. 30 May    08h30   ATLAS Plenary                   Main aud.
		14h00   ATLAS Collaboration Board       Main aud.


The broadcast is announced via sdr as "CERN ATLAS". rat and vic applications
will be used with a ttl of 127.

In case of questions or problems please contact <multicast@noc.cern.ch>.

This message is sent to distribution lists, sorry if you receive multiple
copies of it.

Best regards,
--------------------------------------------------------------------
Martin Fluckiger & Christian Isnard                  CERN - CN/CS/EN
multicast@noc.cern.ch       European Laboratory for Particle Physics
Computers and Networks division      CH-1211 Geneva 23 - Switzerland




From rem-conf Thu May 15 13:10:42 1997 
From rem-conf-request@tmpmail.es.net Thu May 15 13:10:42 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wS6Sz-0005zb-00; Thu, 15 May 1997 12:45:33 -0700
Date: Thu, 15 May 1997 12:31:32 -0700 (PDT)
From: Karl Auerbach <karl@precept.com>
X-Sender: karl@big-bear
Reply-To: karl@precept.com
To: rem-conf@es.net, Mark Baugher <mbaugher@rdrop.com>
Subject: Re: Real-Time Transport Protocol MIB Review
In-Reply-To: <3.0.32.19970513232716.00683bc8@agora.rdrop.com>
Message-ID: <Pine.SOL.3.93.970515122917.2421A-100000@big-bear>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


I may have missed something -- can the mib represent unicast RTP
sessions, especially those in which
	source udp port != destination udp port
??

		--karl--





From rem-conf Fri May 16 00:42:15 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 00:42:14 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wSHTn-0000bb-00; Fri, 16 May 1997 00:31:07 -0700
Message-Id: <3.0.32.19970516002833.006b94b0@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 16 May 1997 00:37:16 -0700
To: karl@precept.com, rem-conf@es.net
From: Mark Baugher <mbaugher@rdrop.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: fred@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Karl,

At 12:31 PM 5/15/97 -0700, Karl Auerbach wrote:
>
>I may have missed something -- can the mib represent unicast RTP
>sessions, especially those in which
>	source udp port != destination udp port
>??
>
>		--karl--

In the Ingress Streams Table there are two addresses, one for
the destination and one for the source of the stream.  The
RTCP port is implicitly identified in the MIB so we assume 
either port coupling, or we assume the network manager does 
not care to know the RTCP port number.

Mark

        RtpInEntry ::= SEQUENCE {
                rtpInNetAddr      OCTET STRING (SIZE(4..16)),
                rtpInPort         INTEGER(1..65535),
                rtpInLocalSSRC    INTEGER,
                rtpInRemoteSSRC   INTEGER,
                rtpInRemoteCNAME  OCTET STRING,
                rtpInPT           INTEGER,
                rtpInRemoteAddr   OCTET STRING (SIZE(4..16)),
                rtpInRemotePort   INTEGER(1..65535),
                rtpInFracLost     Gauge32,         
                rtpInLostPackets  Counter32,
                rtpInOctets       Counter32,
                rtpInTool         OCTET STRING,
                rtpInInactiveTime Gauge32
                }

      rtpInNetAddr OBJECT-TYPE
                SYNTAX          OCTET STRING (SIZE(4..16)) 
                MAX-ACCESS      read-only
                STATUS          current
                DESCRIPTION
                "The network address of a multicast RTP Session, or
                the network address of this end of a unicast RTP
                session (remote end is rtpInRemoteAddr)."
                ::= { rtpInEntry 1}


       rtpInPort  OBJECT-TYPE
                SYNTAX          INTEGER(1..65535) 
                MAX-ACCESS      read-only
                STATUS          current
                DESCRIPTION
                "The transport-layer port of a multicast RTP session,
                or the transport-layer port of this end of a unicast
                RTP session (remote is rtpInRemotePort)."
                ::= { rtpInEntry 2}

[...]


        rtpInRemoteAddr OBJECT-TYPE
                SYNTAX          OCTET STRING (SIZE(4..16))
                MAX-ACCESS      read-only
                STATUS          current
                DESCRIPTION
                "The network address of the stream source."
                ::= { rtpInEntry 7 }

        rtpInRemotePort OBJECT-TYPE
                SYNTAX          INTEGER(1..65535)
                MAX-ACCESS      read-only
                STATUS          current
                DESCRIPTION
                "The source transport-layer port of this streams."
                ::= { rtpInEntry 8 }





From rem-conf Fri May 16 00:42:34 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 00:42:34 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wSHb2-0000cJ-00; Fri, 16 May 1997 00:38:36 -0700
Message-Id: <3.0.32.19970516003710.0069bd90@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 16 May 1997 00:37:47 -0700
To: Fred Baker <fred@cisco.com>, Mark Baugher <mbaugher@ideal.jf.intel.com>
From: Mark Baugher <mbaugher@rdrop.com>
Subject: Re: Real-Time Transport Protocol MIB Review
Cc: Stephen Casner <casner@precept.com>, John_Du@ccm.jf.intel.com, 
    snaudus@usrva.com, scott bradner <sob@harvard.edu>, 
    allyn romanow <allyn.romanow@eng.sun.com>, Mike O'Dell <mo@uunet.uu.net>, 
    John Curran <jcurran@bbnplanet.com>, rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

This note responds to questions or remarks from Fred and Steve.

At 05:48 PM 5/14/97 -0700, Fred Baker wrote:
>At 5:18 PM -0700 5/14/97, Mark Baugher wrote:
>
>>The fraction lost is not monotonically  increasing, from page 25 of RFC
1889:
>>
>>   fraction lost: 8 bits
>>        The fraction of RTP data packets from source SSRC_n lost since
>>        the previous SR or RR packet was sent, expressed as a fixed
>>
>>So a Gauge32 type is used in the MIB for fraction lost since it will jump
>>up and down.
>
>and the time period is ________? and the way a network manager
>simultaneously graphs the change in fraction lost over the last hour and
>over the last minute is __________?

On page 20 of the RTP spec, second bullet
     o The calculated interval between RTCP packets is required to be
       greater than a minimum of 5 seconds to avoid having bursts of

>From page 21 of the RTP spec, last paragraph of 6.2.1
   Note that this is still larger than 5 times
   the largest value to which the RTCP report interval is expected to
   usefully scale, about 2 to 5 minutes.

So the time period ranges from about 5 seconds to 5 minutes.  
I am having trouble making the case that rtpInFracLost is 
useful for a polling network manager.  And we are not proposing
to define a notification based on threshold values for 
rtpInFracLost.

>
>
At 04:50 PM 5/14/97 -0700, Stephen Casner wrote:
>
>Perhaps rtpInFracLost should be removed because, as you say, the
>reporting interval is not relevant to the manager querying the MIB.
>The manager can query the MIB twice separated by whatever interval is
>appropriate, then calculate the loss fraction over that interval as we
>were discussing in previous messages.  I don't see the RTCP statistic
>"extended highest sequence number" in the MIB.  This needs to be added
>in order to allow the loss fraction calculation.

So if we removed rtpInFracLost and replaced it with an object for
"extended highest sequence number", then there would enough information
for a network manager to calculate fraction lost over some interval
by using the sequence number and cumulative loss (i.e. the obscure
rtpInLostPackets object).  Did I read this correctly?

>
>Mark suggested that a new "feedback" table may to be added to the MIB
>to report the information received in RTCP Reception Reports.  If so,
>then it would make sense to include the loss fraction from that RTCP
>report in that section because, if the RTCP interval is long, multiple
>queries to the MIB will return the same numbers each time for packets
>lost and highest sequence number until another RTCP packet is
>received.

I don't understand why the loss fraction from the RTCP report is
useful in a "feedback" table but not in the Ingress Streams table.

>
>There is an important point lurking in this question.  Is this a MIB
>for RTP in general, or for RTP + A/V Profile?  The payload types are
>enumerated in the profile, but in order for the MIB to include that
>enumeration I would think there would need to be a profile-specific
>section as well as an indication in the main section of which profile
>is selected.  Selection of the profile is outside the scope of RTP
>itself; it is a session parameter in SDP, where the static and dynamic
>payload types are referenced to "RTP/AVP" with "AVP" indicating the
>A/V Profile.  The binding of dynamic payload types to encoding names
>is also in the session description.  That binding needs to be made
>known to the RTP code by some means; 

I'm not certain what "in the session description" refer to.  
Is it session description as in SDP?  I don't understand why the 
binding of dynamic payload types to encoding names must be known 
to the RTP code.

Mark

>it could be returned in
>additional MIB objects if that makes sense.  On the other hand, the
>authors of this MIB were trying to keep the number of objects from
>getting out of hand.
>							-- Steve
>
>
>



From rem-conf Fri May 16 02:43:44 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 02:43:43 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wSJUI-0001Nb-00; Fri, 16 May 1997 02:39:46 -0700
From: belmon@email.enst.fr (Stephane Belmon)
Message-Id: <199705160939.LAA04726@fourme.enst.fr>
Subject: Allocating group addresses
To: rem-conf@es.net
Date: Fri, 16 May 1997 11:39:27 +0100 (MET DST)
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

>From RFC 1889 (RTP; section 2.1) , about allocating a group address:
" Through some allocation mechanism the working group
   chair obtains a multicast group address and pair of ports"

Apart from SDAP and sdr, is there a way to do this allocation ?

Context: I have a prototype distributed virtual reality system, with
worlds linked a la VRWeb, using multicast to distribute the movement
information (and HTTP for the worlds descriptions). There would be
lots of these worlds, much more than anyone would want in a flat list,
sdr-style. Each would generate a relatively low bandwith (say 50 kbps
peak, a few kbps on average). Could I just "steal" a few addresses,
for example from the DIS transient groups (224.252.0.0-224.255.255.255) 
and allocate these with some sort of SDAP on a "not-so-well-known" 
group address ?

What do you think ? 

--
Stephane Belmon <belmon@email.enst.fr>



From rem-conf Fri May 16 04:41:46 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 04:41:45 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wSLIm-0001p6-00; Fri, 16 May 1997 04:36:00 -0700
Message-Id: <m0wSLIf-001BPDC@csc.com>
Comments: Authenticated sender is <ftroy@explorer.csc.com>
From: "Frank P. Troy" <ftroy@explorer.csc.com>
To: rem-conf@es.net
Date: Fri, 16 May 1997 07:35:01 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Vic Settings
Reply-to: ftroy@csc.com
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi All

I have a sun ultra system running solaris 2.5.1 that tends to 
default to 8-bit mode when running Vic, but I would like it to 
run in 24-bit mode.   I've tried setting the shared memory parameters 
in the /etc/system file but have had no luck.  Is there other ways to 
force Vic into 24-bit mode.  My machine is not lacking ram 
(1GB).  

Thanks
Frank 

--------------------------------------------------
Frank Troy                     Phone: 703-471-3694
AT&T DISC Service Development  Fax: 703-471-1575
3001 Centreville Road          Page: 888-808-0593
Herndon, VA 20171                



From rem-conf Fri May 16 07:34:56 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 07:34:55 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wSO0w-0002bC-00; Fri, 16 May 1997 07:29:46 -0700
From: Isidor Kouvelas <I.Kouvelas@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3670
To: Arch Mott <arch@cisco.com>
cc: Michael.Speer@Eng.Sun.COM, rem-conf@es.net
Subject: Re: PCMCIA Video Capture Cards ...
In-reply-to: Your message of "Wed, 14 May 1997 12:43:20 PDT." <199705141943.MAA12197@yorkie.cisco.com>
Date: Fri, 16 May 1997 15:28:15 +0100
Message-ID: <22747.863792895@cs.ucl.ac.uk>
Sender: I.Kouvelas@cs.ucl.ac.uk
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

>> Does anybody now of any PCMCIA video capture cards that are supported in
>> Vic?  
> One of the cards mentioned on Isidor's page,
>
>http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic/
>
> is the NogaTech conference card. I have sorta-kinda made it work, but not
>reliably. I've been intending, in my copious spare time, to try to get the
>NogaTech tech support guys and Isidor introduced to each other. 

The only one I have tried at UCL is the Centennial PCMCIA video frame
grabber. I have failed to get it to work with any application (including
vic) on three different 95 laptops! Anyone got it working with ANY
application?

By the way I bought the other day the Hauppauge WinTVpci which is relatively
cheap and worked very well. There are also FreeBSD and Linux drivers
available for this card on the net.

Isidor



From rem-conf Fri May 16 13:03:30 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 13:03:30 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wST1m-0004fI-00; Fri, 16 May 1997 12:50:58 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Fri, 16 May 1997 12:50:41 -0700 (PDT)
Message-Id: <199705161950.MAA00254@hille.msri.org>
To: rem-conf@es.net
From: mmadrid <mmadrid@psc.edu>
Reply-to: mmadrid@psc.edu
Subject: Invitation to T3E Training on the Mbone
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	Invitation to T3E Training on the Mbone
Date:        
	May 19, 1997

Time:        
	10:00 EST 6 hours

Contact:     
	mmadrid@psc.edu

URL:         
	http://www.psc.edu/training/MPP_May_97/welcome.html

Description:        
	PSC is offering a "Supercomputing Techniques:   Parallel Processing on CRAY MPP Systems", on   May 19-21.    The workshop will be transmitted over the Mbone.    Users at institutions supporting Mbone and who   have access to the tools "sdr", "vic", "vat",   and "wb" will be able to watch and listen  to the instructors teaching the workshop.    For questions regarding the reception of the   workshop at your remote site, please call the   PSC hotline, 412-268-6350, or 800-221-1641.    The transmission will start on Monday at 10:00 AM.    The Tuesday and Wednesday sessions will be   transmitted as well.    The agenda and lecture notes are on-line at    http://www.psc.edu/training/MPP_May_97/welcome.html  









mbone broadcast schedule http://www.msri.org/mbone



From rem-conf Fri May 16 17:41:34 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 17:41:33 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wSXUg-0007D6-00; Fri, 16 May 1997 17:37:06 -0700
Message-Id: <3.0.1.32.19970516173659.00aafd80@ibeam.intel.com>
X-Sender: dchouina@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 16 May 1997 17:36:59 -0700
To: "Ted Brunner 503.627.1317" <ted.brunner@tek.com>, 
    "rem-conf@es.net" <rem-conf@es.net>
From: Dave Chouinard <dchouinard@mailbox.jf.intel.com>
Subject: Re: mbone and firewalls
Cc: tedb@vnd.tek.com
In-Reply-To: <199705142207.PAA11464@icebox.vnd.tek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 03:07 PM 5/14/97 -0700, Ted Brunner 503.627.1317 wrote:
>
>Recently my company installed a new sort of firewall.
>I learned about it when our MBONE connection went away.
>The new firewall will not allow me to do what I had been doing.
>
>I am now looking into how to bring the MBONE back in.
>The plan I currently have is to install a proxy machine
>with two interfaces, and run mrouted on it.
>The external tunnel and the internal tunnel would
>meet at this proxy.  I don't know, but would like to learn,
>if this is a particularly good or bad thing to do.
>
>Does anyone have some relevant experience they'd be willing
>to share, or a pointer to a whitepaper or a discussion
>of common techniques.
>
>Thanks
>Ted Brunner			Video and Networking Division
>				Tektronix
>				MS 50-490
>ted.brunner@tek.com		14150 SW Karl Braun
>503.627.1317			Beaverton OR 97005	
>		
>
>

Ted,

One approach to getting MBONE is to tunnel it through your new firewall to
a mrouter (or Unix host running mrouted) on your internal network and then
have this mrouter strip the extra IP header and put the native multicast
packets on your internal net (assuming it supports multicast).  You would
do this by configuring your firewall to allow "IP in IP" and IGMP packets
between your MBONE provider's host and your mrouter host.  You would also
probably make the internal mrouter have two interfaces and configure it
accordingly -- such as to only allow packets in from certain multicast
address and port ranges that correspond to the kind of Mbone traffic you
want (e.g., audio/video, etc.).  Note: if you allow multicast traffic to
any port, you open yourself up to UDP port attacks -- someone could send
packets to the multicast IP address you've joined, but to a different UDP
port (e.g., NFS).  Also, this approach really doesn't stop folks on your
internal net from sending out accidentally (which may also be of concern to
your Corp Info Security folks).

See "Mbone: Interactive Multimedia on the Internet" (by Vinay Kumar) for
more details on setting up a mrouted machine and a tunnel.  TIS has also
written whitepaper about the issues with allowing Mbone in and a possible
solution to providing some security (see
http://www.tis.com/docs/research/network/mbone/oaklandpap.htm)

Hope this helps.

--Dave




===========================================================================
Dave Chouinard            (Please note that all opinions expressed here are 
Intel Architecture Labs      mine and are not necessarily shared by Intel)
dchouinard@ibeam.intel.com      
(503)264-7481			   *** Public key available by request ***
Key fingerprint =88 35 F6 22 71 54 5E 98  0B D7 12 B6 3C 73 43 4E



From rem-conf Fri May 16 18:42:30 1997 
From rem-conf-request@tmpmail.es.net Fri May 16 18:42:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wSYTp-0007bG-00; Fri, 16 May 1997 18:40:17 -0700
Date: Sat, 17 May 1997 03:39:59 +0200
From: csmr98@aguirre.ing.UNIFI.IT
Subject: CFPs: 2nd Euromicro Work.Conf. on Soft.Maint. & Reeng., Florence
To: rem-conf@es.net
Message-id: <9705170139.AA24142@ozon180.cs.dsi>
Content-transfer-encoding: 7BIT
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

From: csmr98@aguirre.ing.unifi.it

Dear colleague:

Here is the call for papers for the 2nd EUROMICRO WORKING CONFERENCE on
SOFTWARE MAINTENANCE AND REENGINEERING which will be help in Florence,
Italy, in March 1998.  Please accept our apologies if you receive multiple
copies of this call.
Please post and/or forward to all interested colleagues.

Thank you,
--------------------------------------------------------------------------
                          Call for Papers
                          ---------------

                  2nd EUROMICRO WORKING CONFERENCE on
                SOFTWARE MAINTENANCE AND REENGINEERING
                 Florence,  Italy -- March  9-11, 1998
       
The purpose of the working conference is to promote discussion and
interaction about a series of topics which are yet underrepresented.  We are
particularly interested in exchanging concepts, prototypes, research ideas,
and other results which could contribute to the academic arena and also
benefit business and industrial community.  Researcher, practitioners,
technology transition experts, project managers, developers and users of
tools, are all welcome.

Topics of interest include but are not restricted to: Maintenance and
Reengineering Tools (CARE-Tools), Reverse Engineering Tools, Support of
Reengineering Tasks by CASE-Tools, Software Reusability, Tele-Maintenance
(Concepts, Experiences, Use of New Technologies), Maintainability of
Programming Languages (e.g., OOPLs), Models and Methods for Error Prediction,
Measurement of Software Quality, Maintenance Metrics, Formal Methods,
Maintenance and Reengineering of KBS, Reengineering and Reverse Engineering
Concepts, Experiences from Redesign and Reengineering Projects, Millennium
Problem (Year 2000), Euro Problem, Organizational Framework and Models for
"RE"-Projects, Software Evolution, Migration and Maintenance Strategies,
Design for Maintenance, Preventive Maintenance, Personnel Aspects of
Maintenance (Motivation, Team building), Third Party Maintenance, Empirical
Results about the Maintenance Situation in Businesses, Version and
Configuration Management, Legal Aspects and Jurisdiction, Organization and
Management of Large Maintenance Projects, Software Offloading, Related Areas
such as Software Documentation.

Program Committee:

V.S.  Alagar, USA; A.  Ambriola, I; G.  Bakker, NL; K.  Bennett, UK; A.
Bertolino, I; F.  Brito e Abreu, P; G.  Bucci, I; M.  Campanai, I; A.
Cimitile, I; I.  Classen, D; L.  da F.  Costa, BR; J.A.  de La Puente, S; A.
Fantechi, I; J.-L.  Hainaut, B; J.  Harauz, CA; B.  Henderson-Sellers, AU;
M.  Hinchey, USA; F.  Lehner, D; E.-A.  Karlsson, S; T.M.  Khoshgoftaar,
USA; P.  Laplante, USA; S.  Liu, J; M.  Loewe, D; M.  Marchesi, I; T.J.
Marlowe, USA; E.  Miller, USA; J.-M.  Morel, F; D.  Natale, I; P.  Nesi, I;
S.  Nocentini, I; M.  Pezze`, I; P.T.  Poon, USA; L.  Richter, CH; D.
Rombach, D; G.  Sechi, I; J.  Sommerville, UK; A.  Stoyen, USA; J.
Taramaa, SF; H.  Toetenel, NL; G.  Tsai, USA; Y.  Yamaguchi, J;

SUBMISSIONS: There are two types of papers: full length papers (not
exceeding 4000 words in length and including a 150-200 word abstract) and
short papers (not exceeding 2000 words in length and including a 75-100 word
abstract).  Authors are strongly encouraged to send a PostScript version of
their paper by anonymous ftp to ftp.dsi.unifi.it and put this file into the
directory pub/CSMR98/incoming (in order to avoid overwritings, the
PostScript file should be named:<author_surname.firstname.date_of_birth>.ps).
In addition, they should send by e-mail to CSMR98@ozon180.ing.unifi.it the
title of the paper, full names, affiliations, postal and e-mail addresses of
all authors, fax and telephone numbers.  Alternatively, the paper can be
sent by postal mail.  In that case, five copies of all the above items
should be sent to a program chairman.  
Proceeding will be published by IEEE Computer Society.  Full papers
exceeding 8 pages (short papers 4 pages) will be charged for pages in
excess.For more information please contact the organization at the
addresses:

csmr98@ozon180.ing.unifi.it
http://www.isst.fhg.de/csmr
http://www.dsi.unifi.it/~nesi/csmr98.html

The DEADLINE for submissions is Sept.  15, 1997.  Authors will be notified
of acceptance by Nov.25, 1997.  The camera ready version of the paper will
be required by Dec.  25, 1997.  The following signed information should be
included in the submission: All necessary clearances have been obtained for
the publication of this paper.  If accepted, the author(s) prepare the
camera-ready manuscript in time for inclusion in the proceedings, and will
personally present the paper at the working conference.  

SPECIAL SESSIONS: Sessions of special interest proposed by delegates will be
welcome.  Please send suggestions to a program chairman before the closing
date of submissions.

Program Chair: Paolo Nesi
   Dip. Sistemi e Informatica, Universita' degli Studi di Firenze
   Via S. Marta, 3,  50139 Firenze, Italy
   Tel: +39-55-4796523    Fax: +39-55-4796363 
   email: nesi@ingfi1.ing.unifi.it
          csmr98@ozon180.ing.unifi.it

Program co-Chair: Franz Lehner
   Institute for Business Informatics,  University of Regensburg  
   Universitatsstr, 31, D-93040 REGENSBURG,  Germany
   Tel.: +49-941-943-2734    Fax: +49-941-943-4986
   email:Franz.Lehner@wiwi.uni-regensburg.de

Organizing Chair: Alessandro Fantechi
   Dip. di Sistemi e Informatica, Universita' degli Studi di Firenze
   Via S. Marta, 3,  50139 Firenze, Italy
   Tel: +39-55-4796265       Fax: +39-55-4796363  
   email: fantechi@dsi.dsi.unifi.it

Local Chair: Maurizio Campanai
   CESVIT (High-Tech Agency),  Fortezza da Basso
   Viale F. Strozzi 1,   50129 Firenze, Italy
   Tel: +39-55-4619154    Fax: +39-55-485345 
   email: campanai@cesvit.it

General information 
The conference will take place at Palazzo degli Affari, in the center of
Florence.  Enquiries about the working conference arrangements should be
directed to the organizing chairman or to the local chairman.
Preregistration is suggested for the authors.

--------------------------------------------------------------------------




From rem-conf Mon May 19 09:20:07 1997 
From rem-conf-request@tmpmail.es.net Mon May 19 09:20:07 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wTUsl-0006v1-00; Mon, 19 May 1997 09:01:55 -0700
Message-Id: <3.0.1.32.19970519090136.00aa0a90@ibeam.intel.com>
X-Sender: dchouina@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 19 May 1997 09:01:36 -0700
To: Dave Chouinard <dchouinard@mailbox.jf.intel.com>, 
    "Ted Brunner 503.627.1317" <ted.brunner@tek.com>, 
    "rem-conf@es.net" <rem-conf@es.net>
From: Dave Chouinard <dchouinard@mailbox.jf.intel.com>
Subject: Re: mbone and firewalls
Cc: tedb@vnd.tek.com
In-Reply-To: <3.0.1.32.19970516173659.00aafd80@ibeam.intel.com>
References: <199705142207.PAA11464@icebox.vnd.tek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 05:36 PM 5/16/97 -0700, Dave Chouinard wrote:
>
>TIS has also
>written whitepaper about the issues with allowing Mbone in and a possible
>solution to providing some security (see
>http://www.tis.com/docs/research/network/mbone/oaklandpap.htm)
>

Oops, the whitepaper is now at
http://www.tis.com/docs/research/network/mbone/mboneabs.html

--Dave
===========================================================================
Dave Chouinard            (Please note that all opinions expressed here are 
Intel Architecture Labs      mine and are not necessarily shared by Intel)
dchouinard@ibeam.intel.com      
(503)264-7481			   *** Public key available by request ***
Key fingerprint =88 35 F6 22 71 54 5E 98  0B D7 12 B6 3C 73 43 4E



From rem-conf Mon May 19 23:12:49 1997 
From rem-conf-request@tmpmail.es.net Mon May 19 23:12:48 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wTi2u-0002dO-00; Mon, 19 May 1997 23:05:16 -0700
Sender: liao@ctr.columbia.edu
Message-ID: <33813EF5.71CE@ctr.columbia.edu>
Date: Tue, 20 May 1997 02:04:38 -0400
From: Raymond Liao <liao@ctr.columbia.edu>
Organization: CTR, Columbia University
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: rem-conf@es.net, ctr-pis@ctr.columbia.edu, ee-phd@ctr.columbia.edu, 
    ee-ms@ctr.columbia.edu, ee-faculty@ctr.columbia.edu, 
    cs.bboard@cs.columbia.edu, phds@cs.columbia.edu
CC: mnl@ctr.columbia.edu, advent@ctr.columbia.edu
Subject: Mbone Broadcast: IFIP 5th Intl. Workshop on Quality of Service
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

MBone Broadcast Announcement

Title:
    IFIP 5th International Workshop on Quality of Service
    (IWQoS'97)

Date:
    8:50AM EST -- 6:00PM EST, Wendesday, May 21, 1997
    8:30AM EST -- 5:15PM EST, Thursday,  May 22, 1997
    9:00AM EST -- 4:15PM EST, Friday,    May 23, 1997


Multicast Address:
    audio:  DVI, RTP, 224.2.201.207/22680 , ttl=127
    video:  H.261, RTP, 224.2.224.44/56010 , ttl=127

Contact:
    Andrew T. Campbell <campbell@ctr.columbia.edu>

URL:
    http://comet.ctr.columbia.edu/activities/iwqos/

Place:
    4th Floor, Schapiro Research Building
    Center for Telecommunications Research
    Columbia University
    New York City, USA

More Info:

This is the continuation of the Mbone broadcasting on the weekly
seminar of the COMET group at the Center for Telecommunications 
Research, Columbia University. For the seminar schedule, please check 
http://comet.ctr.columbia.edu/activities/seminars/

-- 
Raymond R.-F. Liao
(212) 939-7158
http://www.ctr.columbia.edu/~liao
Center for Telecommunications Research, Columbia University



From rem-conf Tue May 20 10:39:33 1997 
From rem-conf-request@tmpmail.es.net Tue May 20 10:39:32 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wTse9-0004IY-00; Tue, 20 May 1997 10:24:25 -0700
Message-ID: <3381DDC8.4B19@era-t.ericsson.se>
Date: Tue, 20 May 1997 19:22:16 +0200
From: Henrik Bergquist <henrik.bergquist@era-t.ericsson.se>
Reply-To: henrik.bergquist@era-t.ericsson.se
Organization: Ericsson Radio Systems AB
X-Mailer: Mozilla 3.01Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: Re: PCMCIA full duplex sound cards?
References: <C2256498.00214703.00@maskit1.vocaltec.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi Scott,

I asked info@esstech.com the very same question a few
months ago. Below you will find the received answer.
Instead I use, as you do yourself, Nogatech's card.

Sincerely,
Henrik Bergquist


>>The ES1688 is a half duplex device. No driver can make it perform full
>>duplex operation. For upgrade info. please contact your local PC/audio
>>dealer.
>>
>>----------



Scott_Petrack@vocaltec.com wrote:
> 
> Scott Petrack
> 05/15/97 09:11 AM
>
>.....
> 
> Alternatively, my laptop is a ThinkPad 560, with the ESS ES1688 audio chip.
> (I have driver version 4.03.02) Has anyone found or build a driver to make
> this thing full duplex?
> 
> Sincerely,
> 
> Scott Petrack

-- 
--------------------------------------------------------------------
Henrik Bergquist                             Tel.      +46 8 4047241
Ericsson Radio Systems AB                    Fax.      +46 8 7573100
erahkbt@era-t.ericsson.se	       
--------------------------------------------------------------------



From rem-conf Tue May 20 16:12:07 1997 
From rem-conf-request@tmpmail.es.net Tue May 20 16:12:06 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wTxxT-0005O1-00; Tue, 20 May 1997 16:04:43 -0700
Date: Tue, 20 May 1997 16:10:34 -0700
From: ygz@isl.hrl.hac.com (Yongguang Zhang)
Message-Id: <199705202310.QAA04117@isl.hrl.hac.com>
To: cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, 
    commsoft@cc.bellcore.com, comswtc@gmu.edu, 
    cost237-transport@comp.lancs.ac.uk, dbworld@cs.wisc.edu, 
    f-troup@aurora.cis.upenn.edu, ieeetcpc@ccvm.sunysb.edu, 
    mobile-ip@Tadpole.Com, rem-conf@es.net, reres@laas.fr, 
    sigmedia@bellcore.com, tccc@cs.umass.edu, xtp-relay@cs.concordia.ca
Subject: CFP: WOSBIS'97
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

==

	2nd Int'l Workshop on Satellite-based Information Services
			  (WOSBIS'97)

			CALL FOR PAPERS

		October 1, 1997, Budapest, Hungary
		(In connection with ACM MobiCom'97)

		-----------------------------------

Sponsored by ACM Sigmobile (pending) and NASA Lewis Research Center


Satellite communications will play an increasingly important role in our
future information-based society.  This trend is evidenced by the large
number of systems planned or in operation (e.g. GPS, ACTS, DirecTV(TM),
Iridium, DirecPC, SpaceWay, Teledesic).

As its popular predecessor held in conjunction with MobiCom'96, the
objective of this workshop is to provide a forum for exploratory research
contributions on satellite applications and services.  The services are
characterized by direct or global broadcast capabilities of LEO, MEO, GEO
satellites, low setup costs, high and possibly asymmetric bandwidth, and
unconventional network routing.  Applications of such services are often
real-time, mobile, high bandwidth, and they include telemedicine, public
information services, education, entertainment, Internet access, digital
battlefield, emergency and disaster response.

Topics of contributed papers will include, but are not limited to:

   * Applications using satellite services
   * Software and architectures for integration with terrestrial networks
   * Data management and file systems in satellite applications
   * Distributed computing using satellite communication
   * Software techniques for reducing latency in satellite applications
   * Satellite network protocols and routing
   * ATM over satellites and quality of services
   * TCP/IP for satellite communications
   * Internet applications, WWW access and cache through satellites
   * Direct broadcast and multicast applications
   * Asymmetric communication services
   * Security issues in satellite communications and applications
   * Reliability and scalability in satellite applications
   * Software for satellite switch control
   * Mobile computing and location tracking in satellite applications
   * Inter-satellite communication and network management
   * Mobile satellite services
   * Middleware for satellite-based information services development

The setting of the workshop will be informal, and will encourage discussion
and interaction.  We solicit the submission of research papers, position
papers, experience papers, and panel proposals.

SUBMISSIONS

We invite papers for presentation and discussion at the workshop.  Send a
postscript copy of the paper by email to the address below.  The page
limit on all submissions is 5-10 pages, double spaced, 10 pt minimum
(approximately 1500-2500 words).

	Yongguang Zhang
	Hughes Research Labs, RL-96
	Malibu, CA 90265
	E-mail: ygz@isl.hrl.hac.com

PROCEEDINGS:

An informal proceedings will be published and distributed at the workshop.
The format will be similiar to standard ACM proceedings: double column,
single spaced and the page limit on each paper is 12.

Authors of accepted papers are encouraged to submit their final papers
in HTML (in addition to Postscript).  The HTML versions can be slightly
different than the Postscript versions to add hyperlinks to relevant work,
such as to executable demos available at their own sites.  An electronic
proceeding linking together the HTML versions will be made available to
major Web search engines and mirrored at the sites of the organizers.

IMPORTANT DATES:

   * Papers Due: July 3, 1997
   * Acceptance Notification: Aug. 8, 1997
   * Final papers due: Sep. 5, 1997
   * Workshop: Oct. 1, 1997

WEB SITE:
http://www.wins.hrl.com/conferences/WOSBIS97/

CONFERENCE CHAIRS:
Son K. Dao, Hughes Research Labs.
Ouri Wolfson, EECS Dept, Univ. of Illinois, Chicago

TECHNICAL PROGRAM CO-CHAIRS:
John S. Baras, University of Maryland
Gary Minden, Univ. of Kansas.
Yongguang Zhang, Hughes Research Labs.

PUBLICITY:
Walid Dabbous, INRIA, France
Nghia Pham, Eutelsat

TECHNICAL PROGRAM COMMITTEE:
Rafael Alonso, David Sarnoff Research Center
John Baras, Univ. of Maryland
Kul Bhasin, NASA Lewis Research Center
Tzi-cker Chiueh, SUNY, Stony Brook
Imrich Chlamtac, Boston Univ.
Walid Dabbous, INRIA, France
Son Dao, Hughes Research Labs.
Raj Jain, Ohio State Univ.
Randy Katz, UC Berkeley	
Henry Korth, Bell Labs
Gary Minden, Univ. of Kansas
Shawn Ostermann, Ohio Univ.
Csaba Szabo, Technical University of Budapest
Ouri Wolfson, Univ. of Illinois, Chicago 
Yechiam Yemini, Columbia Univ.
Yongguang Zhang, Hughes Research Labs.




From rem-conf Wed May 21 02:12:08 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 02:12:07 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wU7EX-0006y5-00; Wed, 21 May 1997 01:58:57 -0700
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199705210858.KAA24921@faui40.informatik.uni-erlangen.de>
Subject: JPEG (and RTP) questions
To: rem-conf@es.net
Date: Wed, 21 May 1997 10:58:45 +0200 (MET DST)
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi

I've got some questions about JPEG and how it encoded in RTP:

1. Given that JPEG (with hardware codecs) is a common solution especially
   for high-resolution conferencing (i.e.: full PAL or NTSC resolution),
   i wonder why rfc2035 does not allow for mappings of two (in my view)
   important properties:

   - interlaced
   - aspect ratio

   I can't see how one can use rtp without extending on rfc2035 to transmit
   full scale NTSC/PAL video with it, because it will always be interlaced
   and trying to process interlaced video in a non-interlaced way results in
   lots of visible artefacts (no, i don't like interlaced video, but it's
   there to stay).

   Also, if someone tries to do TV-quality like JPEG encoding he would
   probably like to use non-square pixel transmission (i.e.: 720*576 or
   the like).
  
   Any thoughts about this ?

2. Restart markers: Are there any known implementations of JPEG encoders
   that really generate restart markers ? I.e.: on framegrabber interface
   cards. The open jpeg implementation does support it, i know, but for
   my kind of applications only hardware encoding provides for the required
   quality.

Best regards
	Toerless



From rem-conf Wed May 21 08:00:14 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 08:00:13 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUCiB-00009h-00; Wed, 21 May 1997 07:49:55 -0700
To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>
cc: rem-conf@es.net
Subject: Re: JPEG (and RTP) questions
In-reply-to: Your message of "Wed, 21 May 97 01:58:45 PDT." <199705210858.KAA24921@faui40.informatik.uni-erlangen.de>
Date: Wed, 21 May 1997 07:49:33 PDT
Sender: Ron Frederick <frederic@parc.xerox.com>
From: Ron Frederick <frederic@parc.xerox.com>
Message-Id: <97May21.074934pdt."16153"@ecco.parc.xerox.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

In message <199705210858.KAA24921@faui40.informatik.uni-erlangen.de> you write:
> 
> 1. Given that JPEG (with hardware codecs) is a common solution especially
>    for high-resolution conferencing (i.e.: full PAL or NTSC resolution),
>    i wonder why rfc2035 does not allow for mappings of two (in my view)
>    important properties:
> 
>    - interlaced
>    - aspect ratio
> 
>    I can't see how one can use rtp without extending on rfc2035 to transmit
>    full scale NTSC/PAL video with it, because it will always be interlaced
>    and trying to process interlaced video in a non-interlaced way results in
>    lots of visible artefacts (no, i don't like interlaced video, but it's
>    there to stay).
> 
We've been doing some work with full resolution hardware JPEG encoding, and
have also run into this. What we're doing for now is using two new type fields
to represent even field & odd field 640x240 images. Our hardware can also
produce non-interlaced square pixel images for interoperability.

I've debated about trying to make the interlaced images an official part of the
spec. However, it is nearly impossible to display interlaced images correctly
on a (progressively scanned) computer monitor. Just putting pixels on every
other line introduces terrible motion artifacts. So, while you're right that
you get some artifacts trying to encode the JPEG as a frame instead of two
fields, the resulting image actually looks _better_ when displayed on a
progressive scan monitor than reinterlacing two independently encoded fields.
The only time you really want to encode the fields separately is when your
target display is an analog NTSC/PAL monitor again (as it is with our hardware
in some cases). So far, I get the sense that we're the exception rather than
the rule in this regard.

>    Also, if someone tries to do TV-quality like JPEG encoding he would
>    probably like to use non-square pixel transmission (i.e.: 720*576 or
>    the like).
>   
I don't see why... Most of the capture chips out there seem perfectly willing
to hand you either square or non-square pixels these days. I don't see a big
advantage in using non-square.

Putting in support for 720 pixel non-square pixels would be easy enough, but it
would once again greatly complicate regular decoders trying to display on a
computer monitor. Unless they had hardware scaling support (which is unlikely
in most cases), they wouldn't be able to easily put up a proper looking image.

> 2. Restart markers: Are there any known implementations of JPEG encoders
>    that really generate restart markers ? I.e.: on framegrabber interface
>    cards. The open jpeg implementation does support it, i know, but for
>    my kind of applications only hardware encoding provides for the required
>    quality.
> 
The CCube JPEG encoding chips (550/560) can generate data with restart markers.
I know some of the framegrabber cards out there use these chips internally, but
I don't know if they expose enough of the functionality to let you turn that
on.

I'm actually not real happy with the extensions made to the JPEG spec for
restart markers. While I'm not against the idea in principle, the way it was
encoded into the type field makes it very difficult to add types other than
the 4:2:2 and 4:2:0 square pixel types we started with. It would have been
better to carve out completely independent bits for this, since it should
orthogonally apply to almost any types we'd want to define.
--
Ron Frederick
frederick@parc.xerox.com



From rem-conf Wed May 21 08:17:45 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 08:17:44 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUD7V-0000UT-00; Wed, 21 May 1997 08:16:05 -0700
From: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>
Message-Id: <199705211515.RAA08567@faui40.informatik.uni-erlangen.de>
Subject: Re: JPEG (and RTP) questions
To: frederic@parc.xerox.com (Ron Frederick)
Date: Wed, 21 May 1997 17:15:54 +0200 (MET DST)
Cc: Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net
In-Reply-To: <97May21.074934pdt."16153"@ecco.parc.xerox.com> from "Ron Frederick" at May 21, 97 07:49:33 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> I've debated about trying to make the interlaced images an official part of the
> spec. However, it is nearly impossible to display interlaced images correctly
> on a (progressively scanned) computer monitor. Just putting pixels on every
> other line introduces terrible motion artifacts. So, while you're right that
> you get some artifacts trying to encode the JPEG as a frame instead of two
> fields, the resulting image actually looks _better_ when displayed on a
> progressive scan monitor than reinterlacing two independently encoded fields.
> The only time you really want to encode the fields separately is when your
> target display is an analog NTSC/PAL monitor again (as it is with our hardware
> in some cases). So far, I get the sense that we're the exception rather than
> the rule in this regard.

Well, we're using the XVideo framegrabber/display cards from parallax for
Sun workstation for years, especially to do full scale video. So far we
could only grab and display progressive (up to 768x576 for PAL) and there
are noticeable artifacts, not only on the TV-out of the card but also
on-screen display. There are some other reasons to this beside being non
interlaced, but i wouldn't subscribe to the opinion that interlaced video
should be handled progressive in a computer-display environment.

> >    Also, if someone tries to do TV-quality like JPEG encoding he would
> >    probably like to use non-square pixel transmission (i.e.: 720*576 or
> >    the like).
> >   
> I don't see why... Most of the capture chips out there seem perfectly willing
> to hand you either square or non-square pixels these days. I don't see a big
> advantage in using non-square.

It's a question of exchange format with different devices. There are some
(i know one) that can only do 720 pixels horizontally.

> The CCube JPEG encoding chips (550/560) can generate data with restart markers.
> I know some of the framegrabber cards out there use these chips internally, but
> I don't know if they expose enough of the functionality to let you turn that
> on.

Can you tell me any card beside the parallax ones and the cosmo-compress
that utilize the 550/560 ?

> I'm actually not real happy with the extensions made to the JPEG spec for
> restart markers. While I'm not against the idea in principle, the way it was
> encoded into the type field makes it very difficult to add types other than
> the 4:2:2 and 4:2:0 square pixel types we started with. It would have been
> better to carve out completely independent bits for this, since it should
> orthogonally apply to almost any types we'd want to define.

True. For now i feel that 4:2:2 is good enough anyway. I'd just like to
see partial decoding to go into vic.

Toerless



From rem-conf Wed May 21 08:17:51 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 08:17:51 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUD7r-0000Uo-00; Wed, 21 May 1997 08:16:27 -0700
Date: Wed, 21 May 1997 10:16:16 -0500 (CDT)
From: Eric Clark Krutz <eric@ecl.wustl.edu>
To: rem-conf@tmpmail.es.net
Message-ID: <Pine.SOL.3.95.970521101554.20122C-100000@bigfoot.ecl.wustl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Unidentified subject!
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

remove Eric Krutz




From rem-conf Wed May 21 08:40:22 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 08:40:21 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUDP4-00014R-00; Wed, 21 May 1997 08:34:14 -0700
Message-Id: <199705211534.RAA13629@bordeaux.nijenrode.nl>
X-Mailer: exmh version 1.6.5 12/11/95
To: Eric Clark Krutz <eric@ecl.wustl.edu>
cc: rem-conf@tmpmail.es.net
Subject: Re: Unidentified subject! 
In-reply-to: Your message of "Wed, 21 May 1997 10:16:16 CDT."
             <Pine.SOL.3.95.970521101554.20122C-100000@bigfoot.ecl.wustl.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 May 1997 17:34:00 +0200
From: Michel <michel@nijenrode.nl>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> remove Eric Krutz

Eric Krutz removed from planet Earth.






From rem-conf Wed May 21 10:11:06 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 10:11:05 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUEpA-0001dd-00; Wed, 21 May 1997 10:05:16 -0700
X-Mailer: exmh version 1.6.9 8/22/96
To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>
cc: rem-conf@es.net
Subject: Re: JPEG (and RTP) questions
In-reply-to: Your message of "Wed, 21 May 1997 08:15:54 PDT." <199705211515.RAA08567@faui40.informatik.uni-erlangen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 May 1997 09:21:17 PDT
From: Ron Frederick <frederic@parc.xerox.com>
Message-Id: <97May21.092117pdt."16153"@ecco.parc.xerox.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

In message <199705211515.RAA08567@faui40.informatik.uni-erlangen.de>you write:
> Well, we're using the XVideo framegrabber/display cards from parallax for
> Sun workstation for years, especially to do full scale video. So far we
> could only grab and display progressive (up to 768x576 for PAL) and there
> are noticeable artifacts, not only on the TV-out of the card but also
> on-screen display. There are some other reasons to this beside being non
> interlaced, but i wouldn't subscribe to the opinion that interlaced video
> should be handled progressive in a computer-display environment.
> 
Yes - I've seen all sorts of artifacts on the Parallax as well, but most of
them have to do with other implementation problems. I'm not convinced one way
or the other about how to best handle interlaced video, but trying to encourage
the use of progressive encoding makes it much more likely that the decoder will
have an easier job, and that seems like the right tradeoff to me right now.

> It's a question of exchange format with different devices. There are some
> (i know one) that can only do 720 pixels horizontally.
> 
This is always a tough problem... When you have a device like that, though, the
best you can generally do is put a hook in the spec for it with the intent that
it will be completely unable to interoperate with anything but itself, since
most of the decoders won't be able to cope with that (at least not correctly).

I agree that the spec right now is incomplete in this regard. That's what I
meant about wishing the restart support had been done differently. I fully
expect we'll need to extend the type space to include some additional entries
for devices like this, and now that's hard to do.

> Can you tell me any card beside the parallax ones and the cosmo-compress
> that utilize the 550/560 ?
> 
The other one I know about is the J300 card for the DEC Alpha. I haven't really
looked carefully at any of the PC-based JPEG cards, so I don't know what they
are using.
--
Ron Frederick
frederick@parc.xerox.com





From rem-conf Wed May 21 10:18:42 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 10:18:41 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUExC-0001ot-00; Wed, 21 May 1997 10:13:34 -0700
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199705211713.TAA12806@faui40.informatik.uni-erlangen.de>
Subject: Re: JPEG (and RTP) questions
To: frederic@parc.xerox.com (Ron Frederick)
Date: Wed, 21 May 1997 19:13:15 +0200 (MET DST)
Cc: rem-conf@es.net
In-Reply-To: <97May21.092117pdt."16153"@ecco.parc.xerox.com> from "Ron Frederick" at May 21, 97 09:21:17 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> > Can you tell me any card beside the parallax ones and the cosmo-compress
> > that utilize the 550/560 ?
> > 
> The other one I know about is the J300 card for the DEC Alpha. I haven't really
> looked carefully at any of the PC-based JPEG cards, so I don't know what they
> are using.

The PC-boards to all seem to utilize the zoran chipset and so far i havn't
seen a single unix-driver for those boards. Something like the miro DC30 would
be really a wonderful videoconferencing card.



From rem-conf Wed May 21 13:55:17 1997 
From rem-conf-request@tmpmail.es.net Wed May 21 13:55:17 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUIDg-0002tq-00; Wed, 21 May 1997 13:42:48 -0700
From: Dave Alden <alden@math.ohio-state.edu>
Date: Wed, 21 May 1997 16:42:44 -0400 (EDT)
Message-Id: <199705212042.QAA07153@math.mps.ohio-state.edu>
To: math-mbs@msri.org, rem-conf@es.net
Subject: The Solving of Fermat's Last Theorem (Reminder)
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Dear Friends:
 
You are cordially invited to the Spring 1997 University Distinguished 
Lecture, which will be given by Professor Karl Rubin of the Department 
of Mathematics, The Ohio State University.
 
The topic is very timely and about one of the twentieth century's most 
exciting events in the mathematical world--the solving of Fermat's 
Last Theorem.  This event captured the headlines of the world press in 
a way that is all too rare for mathematics.
 
The lecture, which will be for a general university audience, is, in 
fact, titled, "The Solving of Fermat's Last Theorem", and it will be 
this week.
 
Thursday, May 22, 1997
4:00-5:00pm EST

Slides will be available at http://www.math.ohio-state.edu/~rubin/fltslides



From rem-conf Thu May 22 06:56:23 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 06:56:23 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUYDB-0001Os-00; Thu, 22 May 1997 06:47:21 -0700
From: Dermot Tynan <dtynan@wfa.digital.ie>
Message-Id: <9705221347.AA10067@karpov.wfa.digital.ie>
Subject: Re: JPEG (and RTP) questions
To: Toerless.Eckert@informatik.uni-erlangen.de (Toerless Eckert)
Date: Thu, 22 May 1997 14:47:02 +0000 (BST)
Cc: frederic@parc.xerox.com, Toerless.Eckert@informatik.uni-erlangen.de, 
    rem-conf@es.net
In-Reply-To: <199705211515.RAA08567@faui40.informatik.uni-erlangen.de> from "Toerless Eckert" at May 21, 97 05:15:54 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Ron Frederic wrote:
> 
> The only time you really want to encode the fields separately is when your
> target display is an analog NTSC/PAL monitor again (as it is with our hardware
> in some cases). So far, I get the sense that we're the exception rather than
> the rule in this regard.

Also, if your target is a VHS or BETA-SP tape.  You may be the exception
today, but I don't think you'll always be.  :)

Toerless Eckert wrote:
>
> Can you tell me any card beside the parallax ones and the cosmo-compress
> that utilize the 550/560 ?

The DEC J300 card, and various PCI-based cards, including (I think!) the
Truevision 2000.
						- Der
-- 
Dermot Tynan						+353 91 754608
dtynan@wfa.digital.ie					 DTN: 822-4608

AltaVista Internet Software, Galway, Ireland



From rem-conf Thu May 22 08:49:00 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 08:49:00 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUa2K-0001uc-00; Thu, 22 May 1997 08:44:16 -0700
From: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>
Message-Id: <199705221542.RAA10106@faui40.informatik.uni-erlangen.de>
Subject: Re: JPEG (and RTP) questions
To: dtynan@wfa.digital.ie (Dermot Tynan)
Date: Thu, 22 May 1997 17:42:43 +0200 (MET DST)
Cc: Toerless.Eckert@informatik.uni-erlangen.de, frederic@parc.xerox.com, 
    rem-conf@es.net
In-Reply-To: <9705221347.AA10067@karpov.wfa.digital.ie> from "Dermot Tynan" at May 22, 97 02:47:02 pm
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> > Can you tell me any card beside the parallax ones and the cosmo-compress
> > that utilize the 550/560 ?
> 
> The DEC J300 card, and various PCI-based cards, including (I think!) the
> Truevision 2000.

I thought my question contained the part with "with a driver for unix" ;-))



From rem-conf Thu May 22 09:24:02 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 09:24:02 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUaZl-0002Gw-00; Thu, 22 May 1997 09:18:49 -0700
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199705221617.SAA10632@faui40.informatik.uni-erlangen.de>
Subject: Re: Posting to lists.rem-conf failed:
To: server@cti.gr (Listproc Account)
Date: Thu, 22 May 1997 18:17:23 +0200 (MET DST)
Cc: rem-conf@es.net
In-Reply-To: <199705221600.TAA06424@hermes.cti.gr> from "Listproc Account" at May 22, 97 07:00:23 pm
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> From: Listproc Account <server@cti.gr>
> Article not posted -- more included text than new text

*AAAAAAaaaaaaaaargggllll*. Who's running this mailing list ?

Mail repeated:

> > Can you tell me any card beside the parallax ones and the cosmo-compress
> > that utilize the 550/560 ?
>
> The DEC J300 card, and various PCI-based cards, including (I think!) the
> Truevision 2000.

I thought my question contained the part with "with a driver for unix" ;-))

----

And to make that silly mailing list robot happy, just a little bit of trash:
(http://www-csag.cs.uiuc.edu/individual/pakin/complaint ...)

My complaint about Joe Robot

Unless you're a newly-hatched pod person, you already know that it's
never too late to tell you a little bit about Joe Robot and his jaundiced
communications. But let me add that Robot often starts with a preconceived
story and then plugs in supposed "information" in order to create a
somewhat believable tale. First and foremost, when Robot is gone, all that
will be left from his legacy of hate is the hate itself. He and his cronies are
puppets of lethargic undesirables. You may be surprised to learn that I was
once like him. I, too, wanted to condone illegal activities. It interfered with
my judgement, my reasoning, and my ability to address the real issues faced
by mankind. He controls a secret underground empire. I wish I could put it
more delicately, but that would miss the point. Robot's spin doctors portray
themselves as fervent believers in freedom of speech and expression, but
are loath to reveal that this serves as a reminder that Robot's followers have
demonstrated brutally, horribly, and with great terror how they will devise
patronizing scams to get money for nothing. Although Robot has managed
to avoid indictment, or even a consensus that he did anything illegal, the
crux of the issue is that what Robot insists are original proposed social
programs are nothing more than warmed-over versions of terrorism. As I
mentioned before, everyone knows of the lust and driving passion that has
caused this problem. It is my fundamental belief that I have avoided
engaging in open debate with amoral scum -- or even acknowledging their
existence -- for fear of lending them any form of legitimacy. What I had
wanted for this letter was to write an analysis of Joe Robot's actions. Not a
exhortation or a shrill denunciation, but an analysis. I hope I have
succeeded at that.




From rem-conf Thu May 22 10:15:53 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 10:15:52 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUbQV-0002eA-00; Thu, 22 May 1997 10:13:19 -0700
Message-Id: <9705221701.AA31790@bigpink.pa.dec.com>
To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>
Cc: rem-conf@es.net
Subject: Re: JPEG (and RTP) questions
In-Reply-To: Message of Thu, 22 May 1997 17:42:43 +0200 (MET DST) from Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de> <199705221542.RAA10106@faui40.informatik.uni-erlangen.de>
Date: Thu, 22 May 97 10:01:53 -0700
From: berc@pa.dec.com
X-Mts: smtp
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


[ For those that didn't catch Herr Eckert's sarcasm ]

The Digital J300 and AV32x cards (Full Video Supreme JPEG) use the 
CL550/560 and have very efficient Unix drivers.  Which is why we've 
been using them for years with vic to send 30fps video.

lance



From rem-conf Thu May 22 10:20:04 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 10:20:04 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUbUZ-0002o3-00; Thu, 22 May 1997 10:17:31 -0700
From: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>
Message-Id: <199705221717.TAA11419@faui40.informatik.uni-erlangen.de>
Subject: Re: JPEG (and RTP) questions
To: berc@pa.dec.com
Date: Thu, 22 May 1997 19:17:05 +0200 (MET DST)
Cc: Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net
In-Reply-To: <9705221701.AA31790@bigpink.pa.dec.com> from "berc@pa.dec.com" at May 22, 97 10:01:53 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> The Digital J300 and AV32x cards (Full Video Supreme JPEG) use the 
> CL550/560 and have very efficient Unix drivers.  Which is why we've 
> been using them for years with vic to send 30fps video.

Nice. The J300 is rather old, isn't it ? I remember it to be Turbochannel.
Is the AV32x card PCI ? Any pointer for information on that card ?

Also: 30 fps @ 640x480 ?

best regards
	Toerless

P.S.: Sorry for that complain mail, i missed the point that only some
stupid sub-distributor didn't forward my initial mail. Sorry



From rem-conf Thu May 22 11:02:55 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 11:02:55 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUcA2-0003Kj-00; Thu, 22 May 1997 11:00:22 -0700
From: Dermot Tynan <dtynan@wfa.digital.ie>
Message-Id: <9705221754.AA10811@karpov.wfa.digital.ie>
Subject: Re: JPEG (and RTP) questions
To: Toerless.Eckert@informatik.uni-erlangen.de (Toerless Eckert)
Date: Thu, 22 May 1997 18:54:14 +0000 (BST)
Cc: dtynan@wfa.digital.ie, Toerless.Eckert@informatik.uni-erlangen.de, 
    frederic@parc.xerox.com, rem-conf@es.net
In-Reply-To: <199705221542.RAA10106@faui40.informatik.uni-erlangen.de> from "Toerless Eckert" at May 22, 97 05:42:43 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Toerless Eckert wrote:
> 
> > The DEC J300 card, and various PCI-based cards, including (I think!) the
> > Truevision 2000.
> 
> I thought my question contained the part with "with a driver for unix" ;-))

I should also have mentioned that CCube produce a "reference design"
PCI card with video capture/playback to CCIR.601, with a CL550/560 on
board.  I priced it a year or two ago, and it was #3000 ($4,500).  Not
exactly cheap considering they're supposed to sell reference designs
at a little over cost, to get people to use the hardware.  Having said
that, it is relatively cheap for a full, professional video capture
board with onboard JPEG compression.  The other advantage is that they
provide all the documentation, so you can write your own driver...  :)
						- Der
-- 
Dermot Tynan						+353 91 754608
dtynan@wfa.digital.ie					 DTN: 822-4608

AltaVista Internet Software, Galway, Ireland



From rem-conf Thu May 22 15:42:02 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 15:42:02 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUgPG-0004Zl-00; Thu, 22 May 1997 15:32:22 -0700
Message-Id: <9705222225.AA01141@bigpink.pa.dec.com>
To: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>
Cc: berc@pa.dec.com, rem-conf@es.net
Subject: Re: JPEG (and RTP) questions
Date: Thu, 22 May 97 15:25:33 -0700
From: berc@pa.dec.com
X-Mts: smtp
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


    The J300 is rather old, isn't it?

It's hard to believe, but we were running full speed video via vic 
even back in the TurboChannel days, and still had most of the CPU 
idle.

The best setup so far was using BAGnet (the Bay Area Gigabit testbed) 
to go at OC-3c from my office to Steve McCanne when he was at LBL.  
We each had two J300s, external TV monitors, wireless microphones, 
and echo cancel boxes.  This allowed us to run full-duplex 30fps 
video, sending analog JPEG output (via vic & the J300 video out) 
to the monitors, with hands free full-duplex audio w/vat, and we 
still had our workstation monitors free for wb, etc.  A nice way 
to collaborate, and it sure beat driving between an hour from Palo 
Alto to Berkeley.  I didn't have to deal with the crazies, and he 
didn't have to deal with the yuppies.  I get occasional calls from 
people wanting to construct a similar world with modern Alphas and 
Full Video PCI cards. 

Anyhow, the "Full Video Supreme JPEG" (w/guacamole) is a port of 
the J300 to PCI with the audio removed.  I seem to remember it does 
~25fps 640x480 and 30fps 640x240, which is the most useful resolution 
we'd found for sending high-quality video over high-speed networks.  
It may go at full speed 640x480 now; I think that the the bottleneck 
was in server software and may have been fixed.

Beyond JPEG, the FVS-J is also pretty good as a generic YUV input 
for vic's software codecs (h.261, nv, etc).  Atanu Ghosh from the 
University of Technology, Sydney, has added a generic vic YUV interface 
to the FVS-J's video out, so now you can take mcast video output 
>from the software decoders and send it to a video monitor or projector 
(previously you could only do this with JPEG). 

PART NO.    DESCRIPTION
AV301-AA    Full Video Supreme

http://www.workstation.digital.com/products/mmedia/mmfvid.html



From rem-conf Thu May 22 16:34:06 1997 
From rem-conf-request@tmpmail.es.net Thu May 22 16:34:05 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUhLj-00050e-00; Thu, 22 May 1997 16:32:47 -0700
To: berc@pa.dec.com
cc: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>, 
    rem-conf@es.net
Subject: Re: JPEG (and RTP) questions
In-reply-to: Your message of "Thu, 22 May 1997 15:25:33 MST." <9705222225.AA01141@bigpink.pa.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 23 May 1997 09:28:29 +1000
Message-ID: <10754.864343709@connect.com.au>
From: George Michaelson <ggm@connect.com.au>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


I played with one of these turbochannel J300 cards on an Alpha 2+ years ago
and wish to echo Lance's comments. It screamed. If ported to PCI it should 
scream++ on a lot of boxen.

The problems I perceived were the output display quality and the lack of
funds for a professional cameraman to drive the capture device :-) Fixed
focus cameras distort facial shape, and coupled to bad lighting it makes
everyone look like either Mr Potatohead or a chemotherapy patient.

If the box now permits re-presentation to an analogue display, Then a LOT of
people who expressed distain for sync computer output can re-visit this stuff
as viable for existing public-address/lecture & broadcast systems. The ports
were on the cards, but none of the s/w seemed to drive it right.

Network management used to freak when I mis-placed the sliders. The SNMP
network management station redlined if the framerate/TTL relation was
incorrect...

I think its interesting we're close to 30fps on VHS quality (1/2 of the interlace) because many of the complaints regarding re-broadcast of VHS
over SVHS or Beta relate to the signal drop as much as the scan level.
Feeding this stuff to a computer screen is a fair model of chroma/gamma
mismatch in some cases. If it can now be pumped back onto a TV, my bet
(sight unseen) is that it will be at least as good as the compressed video
CNN use for warzone feeds, and possibly better.

Q: is anybody working on a PD clone of webcam's trick of re-feeding video
   into progressive jpeg? Sure, its inherantly unscaleable like all WWW
   but for quick-n-dirty interconnect and demos of what MBONE can do it
   would be a *killer*

-George
--
George Michaelson         |  connect.com.au pty/ltd
Email: ggm@connect.com.au |  c/o AAPT,
Phone: +61 7 3834 9976    |  level 8, the Riverside Centre,
  Fax: +61 7 3834 9908    |  123 Eagle St, Brisbane QLD 4000





From rem-conf Fri May 23 00:54:32 1997 
From rem-conf-request@tmpmail.es.net Fri May 23 00:54:32 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wUp2N-0006dW-00; Fri, 23 May 1997 00:45:19 -0700
Date: Fri, 23 May 1997 00:24:49 -0700 (PDT)
From: Stephen Casner <casner@precept.com>
To: Ron Frederick <frederic@parc.xerox.com>
cc: Toerless Eckert <Toerless.Eckert@informatik.uni-erlangen.de>, 
    rem-conf@es.net
Subject: Re: JPEG (and RTP) questions
In-Reply-To: <97May21.092117pdt."16153"@ecco.parc.xerox.com>
Message-ID: <Pine.PCW.3.95.970523002139.10982J-100000@revelstoke.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Wed, 21 May 1997, Ron Frederick wrote:

> I agree that the spec right now is incomplete in this regard. That's what I
> meant about wishing the restart support had been done differently. I fully
> expect we'll need to extend the type space to include some additional entries
> for devices like this, and now that's hard to do.

The purpose of the Proposed Standard stage of a protocol is to test
whether the specification is right.  If the JPEG spec is not right,
then it should be changed.

I'd like to hear comments that others might have, too, especially the
other authors and any implementors.
							-- Steve




From rem-conf Sat May 24 10:05:52 1997 
From rem-conf-request@tmpmail.es.net Sat May 24 10:05:51 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wVK50-0003RQ-00; Sat, 24 May 1997 09:54:06 -0700
Message-ID: <01BC6841.E45BDDC0@s010h006.dialup.ncsu.edu>
From: Kathy Hewitt <klhewitt@eos.ncsu.edu>
To: "'rem-conf@es.net'" <rem-conf@es.net>, "'mbone@isi.edu'" <mbone@isi.edu>
Subject: Bandwidth Limit
Date: Sat, 24 May 1997 12:56:17 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi there!  Quick question: is the 500 Kbps bandwidth limitation for =
MBone enforced through the mrouters or is that etiquette?

I ask this because I'm looking at a product from SUN called Lyceum and =
am interested in using it for our real-time distance education program =
here in North Carolina.  Everything we have done has been kept at a TTL =
of 63 so it remains in NC.  Lyceum supports multicasting but advises not =
to use it over the MBone since it uses 500Kbps of bw.  We were wondering =
whether we could still use it in the state of NC where we use the NCIH =
as our backbone.

Thanks a lot!

--Kathy Hewitt




From rem-conf Sat May 24 23:53:54 1997 
From rem-conf-request@tmpmail.es.net Sat May 24 23:53:53 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wVX7Y-0004nn-00; Sat, 24 May 1997 23:49:36 -0700
Message-Id: <199705250542.WAA01777@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: rem-conf@es.net
Subject: h.261 : 320x240 vs 352x288
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 24 May 1997 22:40:50 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Would I break h.261 decoders if I transmit video using 320x240 vs 352x288?

I just want to avoid NTSC motion artifacts.

	Tnks,
	Amancio





From rem-conf Sun May 25 11:16:22 1997 
From rem-conf-request@tmpmail.es.net Sun May 25 11:16:22 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wVhgc-00066L-00; Sun, 25 May 1997 11:06:30 -0700
Message-Id: <199705251806.LAA29062@rx7.ee.lbl.gov>
To: Amancio Hasty <hasty@rah.star-gate.com>
cc: rem-conf@es.net
Subject: Re: h.261 : 320x240 vs 352x288
In-reply-to: Your message of Sat, 24 May 97 22:40:50 PDT.
Date: Sun, 25 May 97 11:06:26 PDT
From: Van Jacobson <van@ee.lbl.gov>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Amancio,

the vic h261 encoder code, like the precept h261 encoder, will
embed a 320x240 ntsc image in a 352x288 cif rectangle so
decoders see no change.  Almost all the vic grabbers work this
way.  The major exception was the meteor grabber but I've
rewritten part of it for the upcoming vic 2.8.1 release to grab
320x240 fields rather than scaling 640x480 frames.  This gets
rid of the interlace artifacts & also some geometric distortion
introduced by the scaling.  I also changed it to grab YUV_PACKED
rather than YUV_422.  The combination of this change & the
single field grab now means the stock meteor works reliably even
with the broken Natoma PCI chips on Intel's Pentium-Pro
motherboards.  The grabber was also changed to remove two extra
memory-memory copies of each frame so it sped up more than a
factor of two (our 200mhz ppro systems will now grab & h261 cif
encode 30fps of high motion video while simultaneously decoding
& rendering 2 30fps cif streams at 640x480 -- we don't have any
other box that can come close to this).

I've put the current working version of the modified meteor driver at

 ftp://ftp.ee.lbl.gov/grabber-meteor.cc

if you want to play with it.  It should work with vic-2.8 & I'd
welcome any bug reports or changes that could make it in before
the 2.8.1 release.  Thanks.

 - Van



From rem-conf Sun May 25 11:22:04 1997 
From rem-conf-request@tmpmail.es.net Sun May 25 11:22:03 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wVhqf-0006D6-00; Sun, 25 May 1997 11:16:53 -0700
Original-Received: Sun, 25 May 1997 11:16:14 -0700 (PDT) 
                   from grape.arc.nasa.gov (RFC1413 sender 
                   jmeylor@grape.arc.nasa.gov [128.102.32.126]) by 
                   nsipo.arc.nasa.gov (8.7.1/1.5) id LAA20704
PP-warning: Illegal Received field on preceding line
Sender: jmeylor@nsipo.arc.nasa.gov
Message-ID: <3388815E.775@nsipo.nasa.gov>
Date: Sun, 25 May 1997 11:13:50 -0700
From: John Meylor <jmeylor@nsipo.nasa.gov>
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4u)
MIME-Version: 1.0
To: Kathy Hewitt <klhewitt@eos.ncsu.edu>
CC: "'rem-conf@es.net'" <rem-conf@es.net>, "'mbone@isi.edu'" <mbone@isi.edu>
Subject: Re: Bandwidth Limit
References: <01BC6841.E45BDDC0@s010h006.dialup.ncsu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Kathy Hewitt wrote:
> 
> Hi there!  Quick question: is the 500 Kbps bandwidth limitation for MBone enforced through the mrouters or is that etiquette?

There is a draft working its way through the IETF now which can
best answer this first question:

ftp://ietf.org/internet-drafts/draft-ietf-mboned-limit-rate-guide-00.txt

> 
> I ask this because I'm looking at a product from SUN called Lyceum and am interested in using it for our real-time distance education program here in
North Carolina.  Everything we have done has been kept at a TTL of 63 so
it remains in NC.  Lyceum supports multicasting but advises not to use
it over the MBone since it uses 500Kbps of bw.  We were wondering
whether we could still use it in the state of NC where we use the NCIH
as our backbone.


In general, 500K "can" be a lot of traffic from one source on the 
global mbone due to under-engineered areas of the global topology.
This may be due to low-bandwidth links in your path, or in-adequate
HW/SW at the network devices. Depends on where you expect to have
sources and receivers for your project.

However,
If you are indeed planning on keeping the traffic on NC nets
(ie isolated on an autonoumously administered system like NCIH, AS
6559), then the rate you should source at is really up to the 
adminstraters of those networks.  This is good because you may
be able to source more than you could over the "interdomain"
portions of the mbone or portions of an externally administered 
network.  For some of our internal projects, we can source the
multicast at 500K (and more) easily without problems.  
 
So I would recommend directly contacting NCIH.I believe the 
coordinator for NCIH is Mark Cooke <mcooke@anchor.net>. 
It also looks like you may be using the NC  Research and
Education Network ? so you may want to contact Richard
Misenheimer <richm@NCREN.NET>,
or Peter Cassels <cassels@NCREN.NET>.

Good luck, sounds exciting !

- John Meylor
NASA Internet
NASA Research and Educaton Network



From rem-conf Sun May 25 11:26:28 1997 
From rem-conf-request@tmpmail.es.net Sun May 25 11:26:27 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wVhub-0006Oj-00; Sun, 25 May 1997 11:20:57 -0700
Date: Sun, 25 May 1997 21:19:06 +0300 (EEST)
Message-Id: <199705251819.VAA11723@silver.sms.fi>
From: Petri Helenius <pete@sms.fi>
To: Kathy Hewitt <klhewitt@eos.ncsu.edu>
Cc: "'rem-conf@es.net'" <rem-conf@es.net>, "'mbone@isi.edu'" <mbone@isi.edu>
Subject: Bandwidth Limit
In-Reply-To: <01BC6841.E45BDDC0@s010h006.dialup.ncsu.edu>
References: <01BC6841.E45BDDC0@s010h006.dialup.ncsu.edu>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Kathy Hewitt writes:
 > Hi there!  Quick question: is the 500 Kbps bandwidth limitation for MBone enforced through the mrouters or is that etiquette?
 > 
Both. Depends on your provider. Most backbone providers limit the
bandwidth to more feasible figure than the 500kbps one. However if you
want to utilize medium to high bandwidth applications it would be
advisable to use scoped addressing if possible to avoid ttl tresholds
>from pulling down all your traffic needlessly.

Pete



From rem-conf Tue May 27 09:38:30 1997 
From rem-conf-request@tmpmail.es.net Tue May 27 09:38:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wWOzT-0003Zj-00; Tue, 27 May 1997 09:20:51 -0700
X-Sender: singer@mailman.apple.com
Message-Id: <v03007801afb0b7c415c3@[17.202.35.52]>
In-Reply-To: <199705251806.LAA29062@rx7.ee.lbl.gov>
References: Your message of Sat, 24 May 97 22:40:50 PDT.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 27 May 1997 09:12:51 -0700
To: rem-conf@es.net
From: Dave Singer <singer@apple.com>
Subject: Re: h.261 : 320x240 vs 352x288
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I realize that the 261/263 codecs work within a limited set of sizes
(qcif/cif/4cif), but has there been any discussion of sending the actual
picture size within the rtp stream? If the desired content were, for
example, top-left justified within the next larger encoding, this would
enable receivers to clip to the desired size. It does seem strange that we
all spend some amount of screen real-estate watching a grey border at the
moment.

David Singer
Apple Computer/IMG 408-974-3162





From rem-conf Tue May 27 11:25:33 1997 
From rem-conf-request@tmpmail.es.net Tue May 27 11:25:33 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wWQro-00043p-00; Tue, 27 May 1997 11:21:04 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Tue, 27 May 1997 20:20:50 +0200
X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/;
               Relayed; Tue, 27 May 1997 20:20:50 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Tue, 27 May 1997 20:20:46 +0200
X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed;
               Tue, 27 May 1997 23:20:29 +0200
Date: Tue, 27 May 1997 23:20:29 +0200
X400-Originator: schmitt@issy.cnet.fr
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;864757242@x400.issy.cnet.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: h.261 : 320x
Alternate-Recipient: Allowed
From: Jean-Claude SCHMITT <schmitt@issy.cnet.fr>
Message-ID: <9705271820.AA28761@crunch>
To: rem-conf@es.net, Dave Singer <singer@apple.com>
In-Reply-To: <v03007801afb0b7c415c3@[17.202.35.52]>
References: <199705251806.LAA29062@rx7.ee.lbl.gov>
Subject: Re: h.261 : 320x240 vs 352x288
Comments: Authenticated sender is <schmitt@crunch>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mailer: Pegasus Mail for Win32 (v2.53/R1)
content-length: 1982
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi

I can't understand the discussion about the picture size: 320x240 or
352x288. If you wnat to claim your codec is H.261 /H.263 compliant,
you have no choice: you MUST encode CIF picture (352x288) - or QCIF or
SQCIF of course -and send framse on a 30 Hz basis. CIF stands for
Common Intermediate Format: the picture size is derived from the
european PAL format and the frame rate is derived from USA/JAPAN NTSC
format. If you are H.261/H.263 compatible, there is no need to
indicate the picture size at the rtp leval:this size is indicated in
the picture header of the video bitstream.


> Date:          27 May 97 16:42:29 GMT
> From:          Dave Singer <singer@apple.com>
> To:            rem-conf@es.net
> Subject:       Re: h.261 : 320x240 vs 352x288

> I realize that the 261/263 codecs work within a limited set of sizes
> (qcif/cif/4cif), but has there been any discussion of sending the actual
> picture size within the rtp stream? If the desired content were, for
> example, top-left justified within the next larger encoding, this would
> enable receivers to clip to the desired size. It does seem strange that we
> all spend some amount of screen real-estate watching a grey border at the
> moment.
> 
> David Singer
> Apple Computer/IMG 408-974-3162
> 
> 
> 
> 
> 
> 
> 

-- 
Cordialement
Jean-Claude
    ____________________________________________________________________
   *           Centre National d'Etudes des Telecommunications          *
   *                                                                    *
   * Jean-Claude SCHMITT          e-mail : schmitt@issy.cnet.fr         *
   * CNE/DSE/SGV                  tel    : +33 1 45 29 58 06            *
   * 38 rue du General Leclerc    fax    : +33 1 45 29 52 94            *
   * 92131 ISSY LES MOULINEAUX    piece  : 247 IE                       *
   * FRANCE                                                             *
   *____________________________________________________________________*



From rem-conf Tue May 27 11:39:32 1997 
From rem-conf-request@tmpmail.es.net Tue May 27 11:39:31 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wWR7P-0004PN-00; Tue, 27 May 1997 11:37:11 -0700
Message-Id: <199705271836.LAA09020@mlk.cs.berkeley.edu>
To: Dave Singer <singer@apple.com>
cc: rem-conf@es.net
Subject: Re: h.261 : 320x240 vs 352x288
In-reply-to: Your message of Tue, 27 May 1997 09:12:51 -0700. <v03007801afb0b7c415c3@[17.202.35.52]>
Date: Tue, 27 May 1997 11:36:18 -0700
From: mccanne@mlk.cs.berkeley.edu
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Dave,

Vic has always allowed you to resize an H.261 window to avoid
display of the gray border.  At one point, I thought through
an "auto-resize feature" that would detect the gray border and
automatically resize the window, but never actually implemented this. 
Because it's so easy to detect such a border, I don't believe this
information should be explicitly carried in the RTP data stream.

Steve

> I realize that the 261/263 codecs work within a limited set of sizes
> (qcif/cif/4cif), but has there been any discussion of sending the actual
> picture size within the rtp stream? If the desired content were, for
> example, top-left justified within the next larger encoding, this would
> enable receivers to clip to the desired size. It does seem strange that we
> all spend some amount of screen real-estate watching a grey border at the
> moment.
> 
> David Singer
> Apple Computer/IMG 408-974-3162




From rem-conf Tue May 27 19:17:11 1997 
From rem-conf-request@tmpmail.es.net Tue May 27 19:17:10 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wWYDt-00013G-00; Tue, 27 May 1997 19:12:21 -0700
Message-Id: <199705280212.TAA16485@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Jean-Claude SCHMITT <schmitt@issy.cnet.fr>
cc: rem-conf@es.net, Dave Singer <singer@apple.com>
Subject: Re: h.261 : 320x240 vs 352x288
In-reply-to: Your message of "Tue, 27 May 1997 23:20:29 +0200." <9705271820.AA28761@crunch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 27 May 1997 19:12:05 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I got one thing to say : <cough>

Why am I not surprised that PAL users are not complaining?


>From The Desk Of Jean-Claude SCHMITT :
> Hi
> 
> I can't understand the discussion about the picture size: 320x240 or
> 352x288. If you wnat to claim your codec is H.261 /H.263 compliant,

Or maybe the standard needs revision...


	Amancio





From rem-conf Wed May 28 00:36:30 1997 
From rem-conf-request@tmpmail.es.net Wed May 28 00:36:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wWdBc-00059e-00; Wed, 28 May 1997 00:30:20 -0700
From: k claffy <kc@nlanr.net>
Message-Id: <199705280730.AAA31999@nlanr.net>
Subject: SDSC web programmer forum, wednesday, 28 may, 1900PST
To: rem-conf@es.net
Date: Wed, 28 May 1997 00:30:17 -0700 (PDT)
Cc: todd@sdsc.edu, gjohnson@sdsc.edu, kc@sdsc.edu
X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*]
Content-Type: text
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

 
 
                      May 28, 1997, 7pm
   San Diego Supercomputer Center (SDSC) Auditorium, UCSD Campus
 
                 "Java and Network Security" ,
              Kemer Thomson, Sun Microsystems 
 
                            and 
 
   "Gadget Windowing Toolkit (GWT): A Replacement for Java's
                          AWT" ,
                      Rich Kadel, DTAI 
 
 
 
 For directions, parking information, and further details see this URL:
 
 	http://www.sdsc.edu/scwpf
 
 Is "Java Security" an oxymoron? Kemer Thomson will present the Java
 security model, address ongoing security issues -- real and
 imagined -- and discuss expanding Java security features. 
 Kemer has received rave reviews on this presentation at Sandia
 and Los Alamos National Labs. 
 
 Rich Kadel will demo the GWT:
 the Gadget Windowing Toolkit is basically a replacement
 for Java's current AWT (Abstract Windowing Toolkit). AWT
 1.0.2, the most popular version for the time being, has several
 well-known bugs. It also lacks much of the portability and
 consistency the programmers expect from Java technology.
 GWT was developed to overcome these deficiencies. It was
 developed directly to the Java graphics primitives, and
 implements almost all of the AWT components, and many
 additional ones (such as popup menus, combo boxes, tooltips,
 tabular lists, tabbed windows, etc). The GWT model, an
 extension of the AWT model, is very easy to understand, and
 easy to extend. Most intriguing about the product, however, is
 that it is free. 
 
 Refreshments and social hour afterwards.
 
 The Southern California Web Programmers Forum is a
 non-profit organization dedicated to sharing information about
 Web programming technologies. It is intended for Web developers,
 Web programmers, and Webmasters. 




From rem-conf Wed May 28 16:46:26 1997 
From rem-conf-request@tmpmail.es.net Wed May 28 16:46:25 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wWsEF-0006KG-00; Wed, 28 May 1997 16:34:03 -0700
Message-Id: <c=US%a=_%p=ATT%l=MAILSRVA-970528233346Z-1122@nj-mailnet.ho.att.com>
From: "Bhagavath,Vijay" <bhagavath@att.com>
To: "'reres@laas.fr'" <reres@laas.fr>, 
    "'hipparch@sophia.inria.fr'" <hipparch@sophia.inria.fr>, 
    "'xtp-relay@cs.concordia.ca'" <xtp-relay@cs.concordia.ca>, 
    "'rem-conf@es.net'" <rem-conf@es.net>, 
    "'sigmedia@bellcore.com'" <sigmedia@bellcore.com>, 
    "'mobile-ip@Tadpole.Com'" <mobile-ip@Tadpole.Com>
To: "'cellular@comnets.rwth-aachen.de'" <cellular@comnets.rwth-aachen.de>, 
    "'ieeetcpc@ccvm.sunysb.edu'" <ieeetcpc@ccvm.sunysb.edu>, 
    "'cnom@maestro.bellcore.com'" <cnom@maestro.bellcore.com>, 
    "'commsoft@cc.bellcore.com'" <commsoft@cc.bellcore.com>, 
    "'comswtc@gmu.edu'" <comswtc@gmu.edu>, 
    "'giga@tele.pitt.edu'" <giga@tele.pitt.edu>
To: "'multicomm@cc.bellcore.com'" <multicomm@cc.bellcore.com>
Subject: Enterprise Networking MiniConference at Montreal (6/11-12) with ICC97
Date: Wed, 28 May 1997 19:33:46 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

>Folks,
>On behalf of the ENM97 Organizing Cmte, and in the capacity of
>Publicity Chair, please allow me to inform you about the soon to be
>held Enterprise Networking MiniConference from June 11-12, in
>conjunction with ICC97 in Montreal.

Apologies in advance if you rcvd this email multiple times. Some
email addressess are in more than 1 exploder lists.

>Details can be had from the Internet URL
>http://www.comsoc.org/confs/icc/97/ENM/index.html
>
>Thank you very much,
>Dr. Vijay K. Bhagavath
>AT&T Laboratories, Rm. 1L-333
>101 Crawfords Corner Road
>Holmdel, NJ 07733, USA
>Phone: (908) 949-2837
>Fax: (908) 949-4852
>email: bhagavath@att.com
>URL: http://www.arch4.ho.att.com/~vkb
>Dr. Vijay K. Bhagavath
>AT&T Laboratories, Rm. 1L-333
>101 Crawfords Corner Road
>Holmdel, NJ 07733, USA
>Phone: (908) 949-2837
>Fax: (908) 949-4852
>email: bhagavath@att.com
>URL: http://www.arch4.ho.att.com/~vkb
>



From rem-conf Thu May 29 04:02:25 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 04:02:24 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wX2sN-00003F-00; Thu, 29 May 1997 03:56:11 -0700
Message-Id: <9705291055.AA32145@dxcoms.cern.ch>
Subject: MBone broadcast of LHCC sessions
To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, HRC@in2p3.fr, 
    htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch
Date: Thu, 29 May 1997 12:55:28 +0200 (MET DST)
From: Martin Fluckiger - CERN/CN/CS <fle@dxcoms.cern.ch>
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: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	  CERN is pleased to announce the MBONE broadcast of the

			     LHCC Sessions
			     -------------

			on Thursday 5 June 1997
		       from the CERN Auditorium

*** Times are UTC+2 ***

Agenda for the LHCC sessions:
----------------------------

OPEN SESSION: Thursday, 5 June at 9.00 h in the Main Auditorium

 9.00 - 10.20 ATLAS inner detector Technical Design Report (LHCC 97-16, 17)

10.30 - 11.00 COFFEE BREAK

11.00 - 12.20 ATLAS muon system Technical Design Report (LHCC 97-22)


OPEN SESSION continued: Thursday, 5 June at 14.00 h in the Main Auditorium

14.00 - 14.45 CMS status report (M. Della Negra)

15.00 - 15.30 CMS magnet Technical Design Report (LHCC 97-10) A. Herve

15.45 - 16.35 ATLAS magnet Technical Design Reports (LHCC 97-18, 19, 20, 21)
	      H. ten Kate


The broadcast is announced via sdr as "CERN LHCC". vat and vic applications
will be used with a ttl of 127.

In case of questions or problems please contact <multicast@noc.cern.ch>.

This message is sent to distribution lists, sorry if you receive multiple
copies of it.

Best regards,
--------------------------------------------------------------------
Martin Fluckiger & Christian Isnard                  CERN - IT/CS/EN
multicast@noc.cern.ch       European Laboratory for Particle Physics
Computers and Networks division      CH-1211 Geneva 23 - Switzerland



From rem-conf Thu May 29 06:39:38 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 06:39:38 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wX5NK-0000dT-00; Thu, 29 May 1997 06:36:18 -0700
From: Scott Miller <smiller@essex.ac.uk>
Sender: smiller@essex.ac.uk
To: rem-conf@es.net
Subject: standards
Message-Id: <SIMEON.9705291455.B@S1645.essex.ac.uk>
Date: Thu, 29 May 1997 14:33:55 +0100 ()
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.0.9
X-Authentication: IMSP
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hello,

I am confused about videoconferencing standards. Can someone please 
tell me if H.323 has superceeded H.320, or if they are entirely 
different. Both are umbrella standards from what I can determine.

I ask because I am investigating setting up a videoconference service, 
and I have been told that it should conform to H.320. The software I 
would like to use complies with H.323.

I hope this is an appropriate forum to ask this question. I would 
appreciate your answers.

regards,
Scott
____________________________________________
Scott Miller 
Technology Based Learning Specialist
Computing Service, University of Essex
Colchester, Essex, C04 3SQ

tel: 01206 87 3581
fax: 01206 860585
e-mail: tbl@essex.ac.uk
____________________________________________





From rem-conf Thu May 29 07:04:46 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 07:04:46 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wX5k0-0000zf-00; Thu, 29 May 1997 06:59:44 -0700
Original-Received: by 
                   dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) id 
                   PAA23159 Thu, 29 May 1997 15:59:32 +0200 (MET DST)
PP-warning: Illegal Received field on preceding line
Date: Thu, 29 May 1997 15:59:32 +0200 (MET DST)
Message-Id: <199705291359.PAA23159@dienstmann.informatik.uni-bremen.de>
From: Carsten Bormann <cabo@informatik.uni-bremen.de>
To: Scott Miller <smiller@essex.ac.uk>
Cc: rem-conf@es.net
Subject: Re: standards
In-Reply-To: <SIMEON.9705291455.B@S1645.essex.ac.uk>
References: <SIMEON.9705291455.B@S1645.essex.ac.uk>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Scott Miller writes:
> I am confused about videoconferencing standards. Can someone please 
> tell me if H.323 has superceeded H.320, or if they are entirely 
> different. Both are umbrella standards from what I can determine.

H.320 is the system standard for videoconferencing over ISDN lines.
H.323 is the system standard for videoconferencing over Intra- and
Internets ("LANs without guaranteed quality of service" in ITU
parlance).

You could very well argue that H.320 is obsolete, as you can run IP
over ISDN lines.  Making this statement more true actually is one of
the ultimate goals of the ISSLOW work (Integrated Services over Serial
Low-Bitrate Lines) that I was coordinating for part of the last 12
months (see e.g. draft-ietf-issll-isslow-01.txt or the newer
http://ftp.tzi.org/research/isslow.html or .ps).

Of course, your partners may already have H.320 terminals -- if you
need to talk to those, H.320 conformance is the only game in town.
H.320 to H.323 gateways can help you in that you don't have to pull
ISDN lines to all the places where your own people need to conference
(typically, they'll have a LAN at their place of work already).

Gruesse, Carsten



From rem-conf Thu May 29 07:05:44 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 07:05:44 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wX5nZ-000105-00; Thu, 29 May 1997 07:03:25 -0700
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Scott Miller <smiller@essex.ac.uk>
cc: rem-conf@es.net
Subject: Re: standards
In-reply-to: Your message of "Thu, 29 May 1997 14:33:55 BST." <SIMEON.9705291455.B@S1645.essex.ac.uk>
Date: Thu, 29 May 1997 10:02:14 -0400
Message-ID: <28588.864914534@buttle.lcs.mit.edu>
Sender: mjh@buttle.lcs.mit.edu
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


>I am confused about videoconferencing standards. Can someone please 
>tell me if H.323 has superceeded H.320, or if they are entirely 
>different. Both are umbrella standards from what I can determine.
>
>I ask because I am investigating setting up a videoconference service, 
>and I have been told that it should conform to H.320. The software I 
>would like to use complies with H.323.

Briefly, H.320 is designed for ISDN circuits and is not packet based.
H.323 is designed for packet LANs (and by extrapolation, internet).
You need a gateway to work between the two.

Mark



From rem-conf Thu May 29 07:35:24 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 07:35:24 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wX6Cl-0001hS-00; Thu, 29 May 1997 07:29:27 -0700
From: Braito_Norbert@tecpi.tecsiel.it
X-Openmail-Hops: 1
Date: Thu, 29 May 97 16:22:28 +0200
Message-Id: <715E98FF@MHS>
Subject: RE: standards
Mime-Version: 1.0
To: rem-conf@es.net, smiller@essex.ac.uk
Content-Type: multipart/mixed; boundary="openmail-part-01f4b36f-00000001"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


--openmail-part-01f4b36f-00000001
Content-Type: text/plain; charset=US-ASCII; name="RE:"
Content-Transfer-Encoding: 7bit

H.323 (Visual telephone systems and equipment for local area networks 
which provide a non-guaranteed quality of service)is definied for 
multimedia conferencing on networks which do not guarantee a quality of 
service (LANs/WANs).
H.320 (Narrow-band visual telephone systems and terminal equipment) is 
definied for services like ISDN which guarantee a quality of service 
and have band width nx64kbps.

H.323 is the newer one and embraces also a gateway which allows 
interconnection between H.323 and H.320 (controlled by H.246). 
PictureTel is offering such a gateway: LiveGateway.

Common points between H.323 and H.320 are
Video compression H.261 and H.263 (preferred by H.323)
Audio compression G.711 and G.723.1 (defined standard for H.323 in 
these days by IMTC)
Multiplexing, control and multipoint protocols differ.

Regards
Norbert Braito

____________________________________________________________________________
       __
     _/_/	
    /_/_/  	Dr. Norbert Braito	phone:	+39 (50) 968-111 (operator)
   /_/_/  	Finsiel S.p.A.		+39 (50) 968-528 (direct)
  /_/_/   			fax:	+39 (50) 968-525
 /_/_/    	Via Matteucci 34b
====== 	56124 Pisa - Italy     	

email: n.braito@finsiel.it
____________________________________________________________________________

----------
> From: smiller
> To: rem-conf
> Subject: standards
> Date: Thursday 29 May 1997 15:33
>
> Hello,
>
> I am confused about videoconferencing standards. Can someone please
> tell me if H.323 has superceeded H.320, or if they are entirely
> different. Both are umbrella standards from what I can determine.
>
> I ask because I am investigating setting up a videoconference service,
> and I have been told that it should conform to H.320. The software I
> would like to use complies with H.323.
>
> I hope this is an appropriate forum to ask this question. I would
> appreciate your answers.
>
> regards,
> Scott
> ____________________________________________
> Scott Miller
> Technology Based Learning Specialist
> Computing Service, University of Essex
> Colchester, Essex, C04 3SQ
>
> tel: 01206 87 3581
> fax: 01206 860585
> e-mail: tbl@essex.ac.uk
> ____________________________________________
>
>
> 

--openmail-part-01f4b36f-00000001

--openmail-part-01f4b36f-00000001--




From rem-conf Thu May 29 12:16:55 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 12:16:54 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXAbD-00031V-00; Thu, 29 May 1997 12:10:59 -0700
Date: Thu, 29 May 1997 14:10:52 -0500 (CDT)
From: "H.A. Kippenhan Jr." <kipp@hep.net>
X-Sender: kipp@utah
To: rem-conf@es.net
cc: kippenhan@hep.net
Subject: 640x480 support in VIC when using nv encoding
Message-ID: <Pine.GSO.3.95q.970529140511.17617A-100000@utah>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	Hi:

	I've tried using vic (as a replacement for nv) on a small number
	of Sun and SGI workstations.  When using nv, I can transmit a
	picture of 640x480 size.  When using vic (and it's nv compatibility
	encoding) I find I can't transmit the 640x480 image size.

	Is this a limitation of the vic application?  Note, I wish to move
	to vic becasue of it's support of RTP2; however, I wish to retain
	the ability to transmit a picture of 640x480 size.

	Comments?

	Best regards

        - Kipp -                                                    \|/
                                                                    o o
 +---------------------------------+-------------------------+----m--~--m----+
 | H.A. Kippenhan Jr.              | Internet:            Kippenhan@FNAL.GOV |
 | HEP Network Resource Center     | HEPnet/NSI DECnet:     FNDCD::KIPPENHAN |
 | Fermi National Accelerator Lab. | Voice:                   (630) 840-8068 |
 | P.O. Box 500   MS: FCC-3E/368   | FAX:                     (630) 840-8208 |
 | Batavia, Illinois 60510         | http://www.hep.net/people/kippenhan.html|
 +---------------------------------+-----------------------------------------+
 | All opinions & ideas expressed are mine alone,   and may not necessarily  |
 | reflect those of Fermilab, Univ. Research Assoc., or the Dept. of Energy  |
 +---------------------------------------------------------------------------+




From rem-conf Thu May 29 12:24:45 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 12:24:44 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXAnw-0003Nj-00; Thu, 29 May 1997 12:24:08 -0700
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Message-Id: <970529103309.ZM11990@arrakis>
Date: Thu, 29 May 1997 10:25:08 -0700
In-Reply-To: Scott Miller <smiller@essex.ac.uk> "standards" (May 29, 2:33pm)
References: <SIMEON.9705291455.B@S1645.essex.ac.uk>
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: Scott Miller <smiller@essex.ac.uk>, rem-conf@es.net
Subject: Re: standards
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On May 29,  2:33pm, Scott Miller wrote:
> Subject: standards
> Hello,
> 
> I am confused about videoconferencing standards. Can someone please 
> tell me if H.323 has superceeded H.320, or if they are entirely 
> different. Both are umbrella standards from what I can determine.
> 

Both are umbrella standards, but they differ in the networks for which 
they were designed. H.320 was developed for ISDN, H.322 for "Networks 
which provide a QoS guarantee", namely ATM, H.323 for "Networks that do 
not provide a QoS guarantee", like IP, and H.324 for POTS. In fact, all 
four of these are quite similar, and differ mainly in signalling and 
capability exchanges.

-Jonathan Rosenberg




-- 
Jonathan Rosenberg			Lucent Technologies
Member of Technical Staff		Bell Laboratories
High Speed Networks Research		101 Crawfords Corner Rd.
PHONE: (908) 949-6418			Holmdel, NJ 07733
FAX:   (908) 834-5379			Rm. 4D-534B
EMAIL: jdrosen@bell-labs.com



From rem-conf Thu May 29 13:21:23 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 13:21:22 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXBeQ-0003w6-00; Thu, 29 May 1997 13:18:22 -0700
Date: Thu, 29 May 1997 13:21:46 -0700
X-Sender: rower@139.121.37.182
Message-Id: <v01540b03afb32177095a@[139.121.183.124]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: ROBIN.S.ROWE@cpmx.saic.com (Robin Rowe)
Subject: nominal hardware spec
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi. I thought this would be in a FAQ, but I didn't find it.

My question is, what is the nominal hardware recommended for using
vic/nv/vat/sdr across the platforms supported? Specifically, what is the
minimum CPU/RAM to run usefully on Intel, Sparc, Alpha, and SGI? For
example, should I even bother to try to run it on a Sparc 5? How about a
Sparc 2? And so forth....

By the way, I already have it running on running on faster SGI, DEC, and
Intel machines.

Thanks.

Robin

===============================================================
Robin Rowe, PM  SAIC San Diego rower@ise1.saic.com 619-225-3107
R&D in Internet video and speech recognition using Java and C++






From rem-conf Thu May 29 13:45:58 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 13:45:57 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXC2d-0004Lc-00; Thu, 29 May 1997 13:43:23 -0700
Message-Id: <199705292040.WAA06667@salt.cdt.luth.se>
X-Mailer: exmh version 2.0gamma 1/24/96
To: ROBIN.S.ROWE@cpmx.saic.com (Robin Rowe)
cc: rem-conf@es.net
Subject: Re: nominal hardware spec
In-reply-to: Your message of "Thu, 29 May 1997 13:21:46 PDT." <v01540b03afb32177095a@[139.121.183.124]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 29 May 1997 22:40:24 +0200
From: Peter Parnes <peppar@cdt.luth.se>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

A SS5 with 64MB RAM is enough if you are not going to do much else on the same 
machine.  Forget the SS2 if you want to do more than very low quality video.

Otherwise, I always recommend 24 bits displays for video so you don't get all 
annoying color-map flashing and much better video-quality.

By the way, has anyone done any measurements on how much difference the hw 
double-buffering in the Creator3D does in contrast to the lower Creator on the 
Suns for video?

/P





From rem-conf Thu May 29 16:10:24 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 16:10:23 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXEIR-0006O8-00; Thu, 29 May 1997 16:07:51 -0700
To: Peter Parnes <peppar@cdt.luth.se>
cc: ROBIN.S.ROWE@cpmx.saic.com (Robin Rowe), rem-conf@es.net
Subject: Re: nominal hardware spec
In-reply-to: Your message of "Thu, 29 May 1997 22:40:24 +0200." <199705292040.WAA06667@salt.cdt.luth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 May 1997 09:06:42 +1000
Message-ID: <4040.864947202@connect.com.au>
From: George Michaelson <ggm@connect.com.au>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


  Otherwise, I always recommend 24 bits displays for video so you don't get all 
  annoying color-map flashing and much better video-quality.

The much better video quality is partly because the transport is using 24-bit
colour encoding and with a 24bit display you don't need a colourmap phase in
the application. Its loosing one level of s/w indirection.

-George
--
George Michaelson         |  connect.com.au pty/ltd
Email: ggm@connect.com.au |  c/o AAPT,
Phone: +61 7 3834 9976    |  level 8, the Riverside Centre,
  Fax: +61 7 3834 9908    |  123 Eagle St, Brisbane QLD 4000





From rem-conf Thu May 29 17:13:32 1997 
From rem-conf-request@tmpmail.es.net Thu May 29 17:13:31 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXFDb-0006vF-00; Thu, 29 May 1997 17:06:55 -0700
Date: Thu, 29 May 1997 17:06:48 -0700 (PDT)
Message-Id: <199705300006.RAA05975@yoyodyne.graham.com>
From: "Scott J. Kramer" <sjk@graham.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: George Michaelson <ggm@connect.com.au>
Cc: Peter Parnes <peppar@cdt.luth.se>, ROBIN.S.ROWE@cpmx.saic.com (Robin Rowe), 
    rem-conf@es.net
Subject: Re: nominal hardware spec
In-Reply-To: <4040.864947202@connect.com.au>
References: <199705292040.WAA06667@salt.cdt.luth.se> <4040.864947202@connect.com.au>
X-Mailer: VM 6.31 under Emacs 19.34.1
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Fri, 30 May 1997 09:06 +1000, George Michaelson wrote:

    
      Otherwise, I always recommend 24 bits displays for video so you
      don't get all annoying color-map flashing and much better
      video-quality.
    
    The much better video quality is partly because the transport is
    using 24-bit colour encoding and with a 24bit display you don't
    need a colourmap phase in the application. Its loosing one level
    of s/w indirection.

Southland Media's MGX+ card is a decent lower-end 24-bit solution for
Sun SPARC systems.  Using their XIL library in an application like vic
could work well.  Visit http://www.slmedia.com for more info.

-sjk

-- 
Scott J. Kramer				Graham Technology Solutions, Inc.
UNIX/Network Systems Administrator	20823 Stevens Creek Blvd., Suite 300
<sjk@graham.com>			Cupertino, CA  95014  USA
http://www.graham.com			+1.408.366.8001



From rem-conf Fri May 30 02:33:57 1997 
From rem-conf-request@tmpmail.es.net Fri May 30 02:33:57 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXNwr-0000Sy-00; Fri, 30 May 1997 02:26:13 -0700
From: Scott Miller <smiller@essex.ac.uk>
Sender: smiller@essex.ac.uk
To: rem-conf@es.net
Subject: Re: standards
Message-Id: <SIMEON.9705301056.B@S1645.essex.ac.uk>
Date: Fri, 30 May 1997 10:23:56 +0100 ()
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.0.9
X-Authentication: IMSP
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Thank you to everyone who responded to my request for 
clarification of videoconferencing standards.

regards,
Scott
____________________________________________
Scott Miller 
Technology Based Learning Specialist
Computing Service, University of Essex
Colchester, Essex, C04 3SQ

tel: 01206 87 3581
fax: 01206 860585
e-mail: tbl@essex.ac.uk
____________________________________________







From rem-conf Fri May 30 08:46:18 1997 
From rem-conf-request@tmpmail.es.net Fri May 30 08:46:18 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXTmC-0001TW-00; Fri, 30 May 1997 08:39:36 -0700
Message-Id: <9705301539.AA00573@smtpnotes.pictel.com>
To: Braito_Norbert <Braito_Norbert@tecpi.tecsiel.it>
Cc: Rem-Conf <Rem-Conf@Es.Net>, Smiller <Smiller@Essex.Ac.Uk>
From: Kaynam Hedayat/PicTel <Kaynam_Hedayat@smtpnotes.pictel.com>
Date: 30 May 97 11:28:21 EDT
Subject: RE: standards
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="-- next item ----"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

This is the preamble of an RFC-1341 encoded, mixed message.

---- next item ----
Content-Type: Text/Plain

Also worth mentioning that H.323 will have support for use of RSVP (for QoS), 
IP multicast (for decentralized multipoint), native ATM, security standards for 
encryption, supplementary services, etc.  There is also an entity named the 
Gatekeeper (for admission and bandwidth control) which does not exist in H.320.


Kaynam





Braito_Norbert @ tecpi.tecsiel.it on 05/29/97 04:22:28 PM
To: rem-conf @ es.net @ smtp, smiller @ essex.ac.uk @ smtp
cc:  (bcc: Kaynam Hedayat/PicTel)
Subject: RE: standards

H.323 (Visual telephone systems and equipment for local area networks 
which provide a non-guaranteed quality of service)is definied for 
multimedia conferencing on networks which do not guarantee a quality of 
service (LANs/WANs).
H.320 (Narrow-band visual telephone systems and terminal equipment) is 
definied for services like ISDN which guarantee a quality of service 
and have band width nx64kbps.

H.323 is the newer one and embraces also a gateway which allows 
interconnection between H.323 and H.320 (controlled by H.246). 
PictureTel is offering such a gateway: LiveGateway.

Common points between H.323 and H.320 are
Video compression H.261 and H.263 (preferred by H.323)
Audio compression G.711 and G.723.1 (defined standard for H.323 in 
these days by IMTC)
Multiplexing, control and multipoint protocols differ.

Regards
Norbert Braito

____________________________________________________________________________
       __
     _/_/ 
    /_/_/   Dr. Norbert Braito phone: +39 (50) 968-111 (operator)
   /_/_/   Finsiel S.p.A.  +39 (50) 968-528 (direct)
  /_/_/      fax: +39 (50) 968-525
 /_/_/     Via Matteucci 34b
======  56124 Pisa - Italy      

email: n.braito@finsiel.it
____________________________________________________________________________

----------
> From: smiller
> To: rem-conf
> Subject: standards
> Date: Thursday 29 May 1997 15:33
>
> Hello,
>
> I am confused about videoconferencing standards. Can someone please
> tell me if H.323 has superceeded H.320, or if they are entirely
> different. Both are umbrella standards from what I can determine.
>
> I ask because I am investigating setting up a videoconference service,
> and I have been told that it should conform to H.320. The software I
> would like to use complies with H.323.
>
> I hope this is an appropriate forum to ask this question. I would
> appreciate your answers.
>
> regards,
> Scott
> ____________________________________________
> Scott Miller
> Technology Based Learning Specialist
> Computing Service, University of Essex
> Colchester, Essex, C04 3SQ
>
> tel: 01206 87 3581
> fax: 01206 860585
> e-mail: tbl@essex.ac.uk
> ____________________________________________
>
>
> 






---- next item ----
Content-Type:Text/Plain; Name="ATT01"



---- next item ------



From rem-conf Fri May 30 08:47:54 1997 
From rem-conf-request@tmpmail.es.net Fri May 30 08:47:54 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXTtF-0001ZG-00; Fri, 30 May 1997 08:46:53 -0700
From: Isidor Kouvelas <I.Kouvelas@cs.ucl.ac.uk>
X-Organisation: University College London, CS Dept.
X-Phone: +44 171 419 3670
To: "H.A. Kippenhan Jr." <kipp@hep.net>
cc: rem-conf@es.net, kippenhan@hep.net
Subject: Re: 640x480 support in VIC when using nv encoding
In-reply-to: Your message of "Thu, 29 May 1997 14:10:52 CDT." <Pine.GSO.3.95q.970529140511.17617A-100000@utah>
Date: Fri, 30 May 1997 16:44:12 +0100
Message-ID: <18796.865007052@cs.ucl.ac.uk>
Sender: I.Kouvelas@cs.ucl.ac.uk
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

>	I've tried using vic (as a replacement for nv) on a small number
>	of Sun and SGI workstations.  When using nv, I can transmit a
>	picture of 640x480 size.  When using vic (and it's nv compatibility
>	encoding) I find I can't transmit the 640x480 image size.

We did this at UCL a few months ago when trying to increase the resolution
of a vic window so that it looked good when scan converted and displayed on
a TV. There is nothing in the main vic code that prevents you from doing
this. It is just the grabber code that does not supply the full size image.
In the case of solaris and sunvideo cards it is very easy to modify the code
to get full size images. All you need to do is modify grabber-xil, add
"large" to the list of available sizes and double both dimensions in the
xil_create call. The problem with doing this is that even if you transmit
smaller than full sizes with the binary you create, the grabber will still
transfer the full size image from the card into main memory and will be very
slow. It shouldn't be too hard to modify the grabber code to get around this.

Isidor



From rem-conf Fri May 30 12:02:40 1997 
From rem-conf-request@tmpmail.es.net Fri May 30 12:02:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXWrb-0000Th-00; Fri, 30 May 1997 11:57:23 -0700
Date: Fri, 30 May 1997 15:07:06 -0400 (EDT)
From: Andrew Germaine <andrewg@carfax.ims.advantis.com>
To: rem-conf@es.net, mbone@ISI.EDU
cc: noc@ibm.net
Subject: NANOG #10 on the MBone
Message-ID: <Pine.A32.3.91.970530145230.160186B-100000@carfax.ims.advantis.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



IBM Global Services is pleased to announce the MBONE broadcast of NANOG #10
>from Tampa, FL on June 5-6,1997.


 Date: 
        5-6 June, 1997
 
 Time:
        9:00am EDT (13:00 GMT) Thursday, June 5 until 4:30pm EDT (20:30 GMT)
        9:00am EDT (13:00 GMT) Friday, June 6 util 4:30pm EDT (20:30 GMT)
 
 Title:
        NANOG Spring 1997 
 
 Media:
        Video, Audio, WhiteBoard

 URL:
        http://www.ibm.com/globalnetwork/nanog.htm
  
 Agenda:
        http://www.nanog.org/mtg-9706/agenda.html

 Contact:     
        noc@ibm.net


Andrew J. Germaine					Advantis
andrewg@sugaree.ims.advantis.com			500 Mamaroneck Ave.
agermaine@vnet.ibm.com					Harrison, NY 10528
OpenNet 2nd Level Network Support Center		1-914-899-4433





From rem-conf Fri May 30 14:08:56 1997 
From rem-conf-request@tmpmail.es.net Fri May 30 14:08:56 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXYqq-0001J1-00; Fri, 30 May 1997 14:04:44 -0700
From: rameshn@lucent.com
Date: Fri, 30 May 97 16:51:03 EDT
Original-From: ramesh@hoserve.ho.lucent.com
Message-Id: <9705302051.AA00390@hopaw33>
To: rem-conf@es.net
Subject: IEEE INFOCOM'98: Tutorials and Panels
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Dear Colleagues, 

Please find attached a list of potential topics for tutorials 
and panels to be offered at IEEE INFOCOM'98. In order to more accurately
reflect general interests of the community at large, we are
requesting you to provide us with feedback on this list of topics. 
We ask that your feedback be in the form of a rank ordering
of the topic list based on your interests. In addition, you may
provide additional topics of interest as write-in candidates. 
As an example:

Full-day tutorials: 4,3,6e,"favorite topic",1.
Panels: 2,3,1,4.

Please DO NOT reply to this mail, but rather send your 
feedback on tutorials to the tutorial co-chairs: 

        Arvind Krishna  and/or Catherine Rosenberg
e-mails:  krishna@watson.ibm.com     C.Rosenberg@nortel.co.uk

and feedback on panels to the panel co-chairs:

        David Tipper and/or Vittorio Trecordi
e-mails: tipper@lis.pitt.edu  vit@ercole.cefriel.it

Looking to your responses and thanks in advance for your
attention and time. 

As a reminder, the call for papers deadline for INFOCOM'98
is fast approaching (July 15). For more information, please
visit one of our web sites:

  USA:           http://www.comsoc.org/~infocom98  
  Europe:        http://www.cs.ucl.ac.uk/research/infocom98
  Asia/Pacific:  http://www.iss.nus.sg/INFOCOM

The list of panel and tutorial topics and a feedback form is
available at the USA web site (others shortly) and you may choose to 
send your feedback via the web if it is more convenient.

Regards,
Ramesh.

                       TUTORIALS
                       ---------

Full-day tutorials
__________________


1.  IP v6 

This tutorial will provide an in depth review of the IPv6 protocol,
its packets formats, and functionality.  Changes from IPv4 will be
highlighted, and issues related to migration from IPv4 to IPv6 will
also be covered.

2.  Transport protocols in the Internet 
       incl. TCP, RTP (& RTCP), rate based TCP, RSVP & TCP, etc.

This tutorial covers Internet Transport protocols, their operation,
performance, functionality, and recent enhancements.  Issues related
with interactions with other protocols, e.g., RTP and RSVP, will 
also be addressed.

3. Broadband services over Satellite

This tutorial reports on current proposals for deploying a broadband
satellite based communication infrastructure.  The underlying technologies
as well as technical challenges will be reviewed, and an assessment of
the current status of such systems will be provided.

4. Security (IP and ATM) 

With the increased penetration of distributed (network) computing and
the use of networks to support critical business applications, (network)
security has become a key concern to most users.  This tutorial will review
major security issues and technologies, starting with basic cryptographic
primitives for authentication, encryption, and key management, and including
their use in IP and ATM standards to provide various security capabilities.
Existing technologies such as firewall will also be covered.


5. New Access technologies

This tutorial will cover the many recent progress in access technologies.
It will cover basic technologies underlying new modem offerings, including
56kbps modems, xDLS modems, and cable modems.  Issues related to the 
requirements they impose on existing infrastructure will also be addressed.

6. Others
   a) Scalable Routing & IP switching
   b) Optical networking
   c) QoS support within the network
   d) MULTIMEDIA Concept, Technical Challenges, and Implementation
   e) Traffic Characterization 
   f) ATM standards activity 

Half-day Tutorials
__________________

1. Pricing for broadband networks

As new services are being offered, it becomes important
to determine their cost to the network and also how this 
cost is to apportioned to users.  The latter is of particular
interest in the case of multicast connections.  This tutorial
will review existing models for pricing new services as
well as results on the efficiency of pricing in controlling
users behaviors.


2. Mobility topic (only one of those below)

    a) UMTS or Internet mobility 

    b) Next generation wireless networks
   
    c) Mobility support in the Internet 

3. Multicast 

Multicast is becoming an increasingly important service for many 
users, but imposes many specific requirements on the infrastructure
and end-users.  This tutorial will review existing protocols and
technology in support of multicast, and will illustrate the use
of multicast capabilities by several applications.  Unique requirements
of multicast, e.g., reliability, will be highlighted and existing
solutions will be reviewed.

4.  ATM Block Transfer

This tutorial will focus on providing an in depth treatment of the
ABT service defined in the ITU, and identify scenarios for which it
provides a unique solution.  Implementation related requirements
and existing technology in support of ABT will also be reviewed.


                            PANELS
                            ------

1. Active Networks - Hype or Next Big Thing?
    
   Active network research programs have begun with the aim
   of having  network components (e.g. switches) perform 
   customized computations
   on the packets/applications flowing through them.

   This panel focuses on the goals and feasibility of such an approach
   and possible alternatives

2. Networking: State of the Art Report and Future Directions 
   
   Presentation from three leading research directors 
   one each from: Europe, Asia/Pacific, North America
  
   Short presentation 20 minutes each - followed by 10 minute
   panel discussion - followed by question/answer session.
 
 
3.  Broadband Wireless Systems

   Discuss services to be provided,  possible architectures
   and support for mobility. 

   Panelist from the competing proposed architecture groups


4. Can/Should Public Communication Networks  Be Secure? 

   Discuss the technical and political aspects of 
   providing  authentication and  privacy in public communication networks 
   such at the Internet and Cellular phones.
 
   Technical issues in providing widespread security 
   include network management,  scalability,
   cryptography and  protection of computing/networking  resources . 
   Regulatory and political issues include  governments rite to tap
   conversations, business needs to monitor employee activity  and 
  ``Communication  Decency Act''


5. Evolution of Internet and Telecommunications
 
 panelists from the telcos, ISPs,  core Internet

 Discuss services(data, phone,etc.), features, growth and  reliability
 of Internet and  PSTN - who will be the service providers of
 tommorrow

 











From rem-conf Fri May 30 15:10:41 1997 
From rem-conf-request@tmpmail.es.net Fri May 30 15:10:41 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXZqM-0001rI-00; Fri, 30 May 1997 15:08:18 -0700
Date: Fri, 30 May 1997 15:07:44 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: rem-conf@es.net
Subject: RTSP
Message-ID: <Pine.SOL.3.95.970530150633.17382C-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Is any implementation of an RTSP server or client available somewhere? How
about some source code?

========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            




From rem-conf Fri May 30 15:25:59 1997 
From rem-conf-request@tmpmail.es.net Fri May 30 15:25:58 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXa6j-0002F0-00; Fri, 30 May 1997 15:25:13 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <338F53C2.28AE@cs.columbia.edu>
Date: Fri, 30 May 1997 18:25:06 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Stephane Chatre <chatre@ENGR.ORST.EDU>
CC: rem-conf@es.net
Subject: Re: RTSP
References: <Pine.SOL.3.95.970530150633.17382C-100000@eel.ENGR.ORST.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Stephane Chatre wrote:
> 
> Is any implementation of an RTSP server or client available somewhere? How
> about some source code?

See http://www.prognet.com/prognet/rt/. I know of at least three other
on-going efforts, but they can speak for themselves, if they want to.

P.S. Note that RTSP discussions take place on confctrl@isi.edu rather
than rem-conf.



From rem-conf Sat May 31 11:25:35 1997 
From rem-conf-request@tmpmail.es.net Sat May 31 11:25:34 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXshI-0005C1-00; Sat, 31 May 1997 11:16:12 -0700
Message-Id: <199705311816.LAA05670@rx7.ee.lbl.gov>
To: "H.A. Kippenhan Jr." <kipp@hep.net>
cc: rem-conf@es.net, kippenhan@hep.net
Subject: Re: 640x480 support in VIC when using nv encoding
In-reply-to: Your message of Thu, 29 May 97 14:10:52 CDT.
Date: Sat, 31 May 97 11:16:26 PDT
From: Van Jacobson <van@ee.lbl.gov>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Kipp,

vic will generate full 640x480 in nv mode on all the Sun capture
boards I'm familiar with (sunvideo, vigra, videopix)  I would
avoid the grabber-xil that Isidor mentioned since grabber-rtvc
does the same job & is smaller, faster, more reliable & supports
full size (grabber-rtvc is the vic default on solaris).

on sgi's vic will currently only do 320x240.  this is because
there's code in the sgi grabber to work around some awful video
scaling problems in sgi's vl library (basically, vic does the
scaling because vl botched it so badly), we would have had to do
a completely separate grabber loop for the unscaled, full size
video & I was too lazy to write this.  I've heard that the vl
scaling may be fixed with irix 6.2 but we no longer have an sgi
so I can't check this (once before I was told it got fixed but
it wasn't).  If so, it would be easy to go back to our original
vl grabber loop that let vl do the scaling & supported full size
video.

 - Van



From rem-conf Sat May 31 13:18:19 1997 
From rem-conf-request@tmpmail.es.net Sat May 31 13:18:17 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wXuSf-0005o6-00; Sat, 31 May 1997 13:09:13 -0700
Message-Id: <199705312005.WAA18003@salt.cdt.luth.se>
X-Mailer: exmh version 2.0gamma 1/24/96
To: Van Jacobson <van@ee.lbl.gov>
cc: "H.A. Kippenhan Jr." <kipp@hep.net>, rem-conf@es.net, kippenhan@hep.net
Subject: Re: 640x480 support in VIC when using nv encoding
In-reply-to: Your message of "Sat, 31 May 1997 11:16:26 PDT." <199705311816.LAA05670@rx7.ee.lbl.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Sat, 31 May 1997 22:05:18 +0200
From: Peter Parnes <peppar@cdt.luth.se>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Which parameter does one need to tweak to get that working under Solaris2.5.1? I get the following error-message with 'large' and nv:

RTVC_CMD_SEND_MESSAGE: Not enough space

This is on an U1/170E with 128MB RAM and a SunVideo. Vic runs perfectly otherwise (well, as perfect as it usually runs :-) 

/P





