*start*
00496 00024 US 
Date: 29 Oct. 1982 10:41 am PDT (Friday)
From: Swinehart.PA
Subject: More Progress
To: Stewart
cc: Swinehart

[Indigo]<Voice>Top>Agent.df is new.  The Names interface exported by AgentPkg
now includes the functions that you were obtaining from ThrushNet.  Nothing
in Agent.df or LarkRPC.df (still on [Ivy]<Swinehart>Top> until you incorporate
that version) depends in any way on Thrush.bcd or other Thrush files.

All .dfs have complete path names and are verified.

Dan

*start*
00502 00024 US 
Date: 29 Oct. 1982 5:26 pm PDT (Friday)
From: Swinehart.PA
Subject: LarkComm.df
To: Stewart
cc: Swinehart

I started CoralSea loading Lark and left.  You'll have to do the SModel.  Doubtless
this will cure the 4001 problems, but will probably just reveal another -- that a
process has died while expecting a packet -- funny, since RPC processes tend to
idle while expecting a packet.  Or maybe lots of bogus RPC packets (ERROR
pups?) were impinging in the queuer.  More later.

*start*
00274 00024 US 
From: swinehart.pa
Date: 29-Oct-82 21:05:35 PDT
Subject: Oops
To: Stewart
cc: Swinehart

Sent last message before really doing the work.  I have
produced a new LarkComm but did not load a Lark.obj on CoralSea.
Now will the REEAL bug please stand up?
*start*
00231 00024 US 
Date: 30 Oct. 1982 11:53 am PDT (Saturday)
From: Swinehart.PA
Subject: spoO
To: Stewart
cc: Swinehart

Unexpectedly found myself here and did the load -- the SModel too.  Will now
test and possibly report.

*start*
02490 00024 US 
Date: 31 Oct. 1982 5:14 pm PST (Sunday)
From: Stewart.PA
Subject: Cleanup of Voice sil files
To: VoiceProject^.pa
cc: Stewart
Reply-To: Stewart.PA

I have made a survey and cleanup of all .sil files on [Indigo]<Voice>.

The results are two dump files, which reside on

[Indigo]<Voice>History>EANSil.dm
[Indigo]<Voice>History>EPCartSil.dm

These dump files are also archived from [Maxc]<Voice>.

EANSil.dm

contains all sil files I could find which began with EAN.  It has the original analog drawings made by Severo, which reflected the SDD voice box, plus a number of interesting documentation drawings.  More on that later.  To look at the analog circuit drawings you must set up User.cm per EANSilUserCmSlice.txt.  There is also a press file of all the sil files in the .dm.  (To look at the "documentation" files does NOT need a special User.cm)

EPCartSil.dm

Contains stuff done in the fall of 1981 for the voice project proposal, and some documentation done by Ornstein, Swinehart, and Stewart with a non-standard User.cm.  There is an EPCartSilUserCmSlice.txt and an EPCartSil.press.

I also cleaned up [Indigo]<Voice>Sil> slightly.

I presume this is where Severo keeps the 'official' libraries used by both digital and analog board drawings.  I have added VoiceSilUserCMSlice.txt and VoiceLB9Pictures.press to this directory.  [Severo: please check the accuracy of [Indigo]<Voice>Sil>VoiceSilUserCMSlice.txt]

I then deleted nearly all individual .sil files from [Indigo]<Voice>  (except from the <Voice>Sil> directory and a couple of others.)

What I consider interesting:

Using VoiceSilUserCMSlice:

From [Indigo]<Voice>ETP>ETT-Rev-Ai.dm

ETT40.sil	a digital board block diagram
ETT41.sil	a block diagram of the slave CPU program
ETT43.sil	digital board clock and reset nets

From [Indigo]<Voice>History>EANSil.dm

EAN30.sil	an old analog board block diagram
EAN34.sil	block diagram of external cabling
EAN36.sil	physical perspective drawing

Using EPCartSilUserCMSlice:

From [Indigo]<Voice>History>EPCartSil.dm

EPSystem.sil		Network picture of etherphone system components
EPIcons.sil		Font 4 macros used by EPSystem.sil (which includes them!)
		The telephone macro is pretty good
EtherphoneProtocols.sil	Severo's drawing of the call setup process,
					from proposal
Thrush1.sil, Thrush2.sil	DCS drawings for proposal, perhaps still relevant
ETPSlvAddressing.sil	A dense picture of addressing "modes" in the slave

EPCart#.sil	The cartoons

	-Larry
*start*
00417 00024 US 
Date: 31 Oct. 1982 5:22 pm PST (Sunday)
From: Stewart.PA
Subject: EAP-Rev-AA.dm
To: Ornstein
cc: Stewart

There are two versions of this file:

[Indigo]<Voice>eap-rev-aa.dm	19-Oct-82

and

[Indigo]<Voice>ETP>eap-rev-aa.dm	28-oct-82

I presume the second one is the right one.  Is that right?

I do not have a press file copy of the analog stuff right now.  Could you print one for me?
	-Larry
*start*
00879 00024 US 
Date: 31 Oct. 1982 11:58 pm PST (Sunday)
From: Swinehart.PA
Subject: This -- and That
To: Stewart
cc: Swinehart

This:
	I was testing only the ability to set up and take down connections -- was
not watching the traffic on the net or talking down either end or anything
(need an echoing version of the program, so that talking down one end is
enough?)   Broke with new 7003 (lost transmit buffer) when I tried to
disconnect.  Your current code doesn't appear to deactivate the sockets or check
active in the VCB, so one way this could happen is for more than one
Disconnect command to specify the same ID.  I don't think I'm doing that, but
I'm not sure.  So I quit working on it.

That:
	Bringover CFiles to get the latest DoCC.  Passes /Z (but not /L!!) through
to error compilations, and tries to do a better job with .AERR files.  See what you
think.

*start*
00356 00024 US 
Date: 1 Nov. 1982 12:04 pm PST (Monday)
From: ornstein.PA
Subject: Re: EAP-Rev-AA.dm
In-reply-to: Your message of 31 Oct. 1982 5:22 pm PST (Sunday)
To: Stewart
cc: Ornstein

[Indigo]<Voice>ETP>eap-rev-aa.dm	28-oct-82 is the right one.  


A copy of the analog stuff drawings is forthcoming. You should have gotten one
Thursday.

S.
*start*
00906 00024 US 
Date: 1 Nov. 1982 4:17 pm PST (Monday)
From: ornstein.PA
Subject: Re: Cleanup of Voice sil files
In-reply-to: Your message of 31 Oct. 1982 5:14 pm PST (Sunday)
To: Stewart
cc: ornstein

N.B. I make no guarantee that using VoiceSilUserCMSlice works OK with files
from [Indigo]<Voice>ETP>ETT-Rev-Ai.dm. In fact I think the SIP macro will be
wrong.

There were useage conflicts and so my message said:  "These libraries will NOT
work for earlier rev's of the drawings as there are conflicting uses of a couple of
the macros in font 8. However they WILL work for the current EPC (PC version
of Digital board) and EAP (analog board) files. I expect to use them as these
boards go through further revs."

They may work OK for the specific files you listed but won't work in general
for all files in that dump file.

I checked [Indigo]<Voice>Sil>VoiceSilUserCMSlice.txt; it's fine.

S.



*start*
01134 00024 US 
Date: 4 Nov. 1982 11:44 am PST (Thursday)
From: Swinehart.PA
Subject: EOS request for Etherphone documentation
To: Ornstein, Stewart

Any problem pointing this guy at our tome of last September?

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

Date: 3 Nov. 1982 1:12 pm PST (Wednesday)
From: Bohlmann.EOS
Subject: Re: A modest milestone
In-reply-to: Swinehart.PA's message of 22 Oct. 1982 11:55 am PDT (Friday)
To: Swinehart.PA
cc: Bohlmann

Congratulations, Dan, on your "modest milestone" with Etherphone.  It seems
very exciting to me.

Could you please point me to any documentation (internal reports, preliminary
drafts, etc.) on your work.   I have read R.W. Taylor's 1.5-page write-up on the
Voice Project in the "PARC Mid-Year Status Report 1982", but would like a closer
look at the details.

As you know, we provide custom special systems for Xerox and need to keep
abreast of technology trends and progress at PARC.  Therefore, I certainly would
appreciate an opportunity to get better educated on Etherphone/Lark technology.

Thanks in advance,
			Max



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

*start*
00536 00024 US 
Date: 4 Nov. 1982 12:09 pm PST (Thursday)
From: ornstein.PA
Subject: Re: EOS request for Etherphone documentation
In-reply-to: Swinehart's message of 4 Nov. 1982 11:44 am PST (Thursday)
To: Swinehart
cc: Ornstein, Stewart

I'm not really sure. That's a VERY informal pile of stuff and I'd hardly want it to
get out. If this guy is a friend of yours, then maybe OK - with the caveat of not
copying or showing it around. Otherwise I'd tell him we don't yet have anything
except internal notes written down. 

S. 

*start*
02627 00024 US 
Date: 4 Nov. 1982 3:05 pm PST (Thursday)
From: Stewart.PA
Subject: Analog board control
To: VoiceProject^.pa
cc: Stewart
Reply-To: Stewart.PA

The crossbar switch has 8 inputs and 8 outputs:

Number	In			Out
---------------------------------------------
0		Codec1		Codec1
1		TeleSet		TeleSet
2		TeleWall		TeleWall
3		Mike			Speaker
4		Codec1+3dB		DTMF decoder
5		Codec2		Codec2
6		Line1			Line1
7		Line2			Line2

Codec1+3dB is a 3 dB louder version of Codec1, (for "screamer"?)

Caveats:

A single source can drive multiple sinks, with little performance penalty.  

Multiple sources can also drive a single sink, they will mix, but each source will lose 6 dB.  Three sources mixing will each lose 9.5 dB.

The crossbar will work both ways, so that if A & B drive C, and A also drives D, then B will drive D by running through the BC crosspoint, backwards through the AC crosspoint and forwards through the AD crosspoint.

Other "outputs"

There are individual control bits for:

Fallback relay	(TeleSet connected directly to line or to Analog board)
OffHook relay	(activate TeleWall)
SideTone		(Teleset local feedback - reduced level)
RingEnable		(bypass speaker volume control)

Inputs:

There is an interrupt handler that provides up and down transitions for

RingDetect 			(indipendent of fallback relay)
Teleset Switchhook		(Fallback relay must energized, to connect Teleset)
Switch			(on speaker box)
DTMF detector codes 0-9,*,#,a-d, also the button up transitions

There is additional low level analog related software of interest:

The slave processor at present has two modes, called O3I1 and O2I2, which are, repectively, "out 3 in 1" and "out 2 in 2".  O3I1 uses output buffers 1, 2, and 3, merges their contents, and plays the result through Codec 1.  Input buffer 1 is used for voice being digitized.  O2I2 uses Input buffers 1 and 2, and output buffers 1 and 2.  Input and output buffer 1 play via Codec 1 and Input and output buffer 2 play through codec 2.

My inclination is to add a third mode, which connects Codec1 In to Codec2 out and vice versa, with memory, and which perhaps copies both to memory.

Codec 2 has a programmable timeslot.  It should always be set to timeslot C.  There is a possibility that it is interesting to set Codec 2 to timeslot 0, (Codec 1 is permanently assigned timeslot 0), but I don't know.)

The slave CPU has various gain adjustments (done by table lookup)  The two inoput buffers have independent input gains, from 0 to -20 dB in 5 dB steps.

There is a common output gain, in mode O3I1 only, of 0, -3, or -6 dB.  It is not clear that this is useful.
*start*
00586 00024 US 
Date: 4 Nov. 1982 5:24 pm PST (Thursday)
From: Stewart.PA
Subject: DTMF data
To: Stewart

Date: 27-SEP-1982 09:17  
From:	"EVE::VACON c/o" <Schriesheim at DEC-Marlboro>
Subject:	Question about DTMF CHIPS

We have had considerable success with a number of "standard" parts for
DTMF (TOUCHTONE) generation and detection from AMI.  I would suggest
than if someone wanted to design their own that they get the
"telecommunications design manual" from AMI.  AMI's phone is
(408)246-0330.  There are alos many standard parts for repertory
dialer design in this book.


*start*
00887 00024 US 
Date: 5 Nov. 1982 1:07 pm PST (Friday)
From: ornstein.PA
Subject: Eric Rawson
To: Swinehart, Stewart
cc: VoiceProject^, ornstein
Reply-To: ornstein

Eric was just by to fill me in on their plans for voice. They're thinking of
carrying voice and data on the same fiber - but at different frequencies. It's not
clear just what that means, but it seems we might all benefit from a joint
discussion before they go too far. It won't hurt us and maybe we can help them
to understand what we think the problems are (and aren't) - and, although they
don't appear to have thought really deeply about some of the traffic issues, we
might learn something too. Eric is going to arrange a meeting and I think we
should be cooperative and join in to exchange ideas and criticisms.

S.     

P.S. I know it will take some valuable time - but only a few hours and it's worth
it.
*start*
01177 00024 US 
Date: 8 Nov. 1982 3:01 pm PST (Monday)
From: Owicki.PA
Subject: Message system functions
To: voiceproject^
cc: 
Reply-To: Owicki

Here is a list of functions for the voice message system.  Do you see anything
wrong, or anything (important) that is left out?

To record a message, dial 9999.  There are four commands to the recorder
   a. Begin recording
   b. End recording
   c. Playback
   d. Send recording to destination 

   These commands allow the user to record a message, listen to it, and re-record
if it isn't OK.  The message is not actually sent until the "Send" command is
entered.  The normal sequence of commands would be a b c a b c . . . a b c d.

To retrieve your messages, dial 8888 and then login by providing your extension
or rname.  (For the moment we will ignore authentication.)  You can then issue
four commands.
   a. Play next message (or first message, if no messages played yet).
   b. Play message n.
   c. Discard last message heard (ignored if no message heard yet).
   d. Discard message n.

   Discarding a message does not change the number associated with remaining
messages until after the session is terminated.

*start*
01867 00024 US 
Date: 8 Nov. 1982 3:47 pm PST (Monday)
From: TonyWest.PA
Subject: IBM's Speech Filing System
In-reply-to: Your message of 8 Nov. 1982 3:01 pm PST (Monday)
To: Owicki
cc: VoiceProject^
Reply-To: TonyWest.PA

Sue:

I have had some very limited experience of using the experimental Speech Filing System built by IBM at Yorktown Heights.

The Director of the Zurich laboratory once spent an afternoon explaining how he was one of Yorktown's most prolific SFS clients because of the time difference making communications with the US difficult.  (Business opportunity for international markets here!).

Amongst the things that I found interesting about the system was the way in which the spoken user-interface was friendly and adaptive.

For example, SFS allows the distribution of messages to GV-like lists of people.  When logging in, you are told (audio) that there are messages for you from X, Y, and Z.  You then elect to hear them using facilities similar to the ones you described.

The sender could also elect to get confirmation that the messages have been heard.  For example: 

	"The message you sent to X, Y, and Z last Friday on the subject of
	mumble hasn't been heard by Y yet."

There were nice built-in notions of when to convert from yesterday, tomorrow, to day names and then dates.  

Another nice feature (which you could turn off), was that SFS would place phone calls to people messages were addressed to to deliver the messages.  This was soon restricted to the local dialling area of Yorktown!  (Another idea -- wakeup calls in the morning!)

Perhaps we should chat about this system sometime, and, since I think that large parts of it are now in the public domain, we could try to scare up some more information on it either from my contacts at Yorktown, or through IBM's Information Systems Division in Boca Raton.

Tony
*start*
00959 00024 US 
Date: 9 Nov. 1982 3:57 pm PST (Tuesday)
From: ornstein.PA
Subject: Info. on Registration of Etherphone
To: VoiceProject^
Reply-To: ornstein

Dan gave me several names:

Victor Toth (Registration Lawyer)
(703)476-5515

Wm. Von Alven (FCC)
(202)632-6440

Jim Simon (ATT registration guy)
???

I called Toth who said there is (as Dan remembered) a mechanism for "field trial"
of devices that will eventually want to be registered. Toth told me to call the
General Trades Product. Manager for PT&T. (That number is 542-4724 in San
Francisco). I did and they are sending me a packet that contains application
forms and information about procedures. It all sounds as though it will fit our
case. They give you a surrogate registration number good for 6 months
(apparently extendable by special application). I gather that ten or a dozen
devices are within the expected range so it sounds like we'll be OK.

More when I find out more.

S.  

*start*
01072 00024 US 
Date: 10 Nov. 1982 10:45 am PST (Wednesday)
From: Rawson.pa
Subject: Discussion: Voice and ENets
To: Gunning, Ornstein, RSchmidt, Stewart, Swinehart
cc: Rawson

In a recent discussion, Severo and I came to the conclusion that it would be
useful to all of us if we got together for an hour or two oneday soon to discuss
the pros and cons of two different approaches to providing voice service with
Ethernet service, and the impact of the medium (coax or optical fiber) on this
question.  The two approaches are: voice packetized and transmitted on an
Ethernet (both the coax and fiber versions); and 64kB/s digitized voice
multiplexed ("Voice Under ENet") on the same data channel which carries ENet
service in the new FNetII configuration we call NewNet.

Here are some possible dates; please let me know which dates are NOT possible
(and also perhaps which date or dates you prefer):

Fri Nov 12 10am, or 2pm
Tues Nov 16 10am
Wed Nov 17 10am, or 2pm
Thurs Nov 18 10am, or 2pm
Fri Nov 19 10am, or 2pm
Mon Nov 22 10am
Tues Nov 23 10am, or 2pm

Eric
*start*
00600 00024 US 
Date: 10 Nov. 1982 10:57 am PST (Wednesday)
From: Rawson.pa
Subject: Codecs
To: Stewart
cc: Rawson

Larry, the below request is independent of the 6-person meeting proposal
(concurrent msg); this msg is a request for me to meet with you to ask about
codecs and how they work.

Eric

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

Date: 5 Nov. 1982 10:16 am PST (Friday)
From: Rawson.pa
Subject: Codecs
To: Stewart
cc: Rawson

Larry,

When would be a good time for me to come and talk to you some more about
codecs and stuff?

Eric

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

*start*
00317 00024 US 
Date: 10 Nov. 1982 4:21 pm PST (Wednesday)
From: Rawson.pa
Subject: Re: Discussion: Voice and ENets
To: Gunning, Ornstein, RSchmidt, Stewart, Swinehart
cc: Rawson

We will meet next Tuesday, Nov. 16, at 10:00 AM, in the OSL conference room,
Rm. 1452.  Coffee and donuts.  See you then.

Eric

*start*
04255 00024 US 
Date: 15 Nov. 1982 5:17 pm PST (Monday)
From: ornstein.PA
Subject: Stuff for the Registration guy
To: Stewart
cc: Ornstein

Here is the cover letter I propose. Please comment, correct, etc.

----------------------------------------------------------------------------
Mr. J. P. Neil
2336 Hilo Ct.
Mountain View, CA 94040

Dear Phil:

Here are the drawings for the telephone connection of the Etherphone. After you
look them over, we would like to discuss with you the general registerability of
the design. We are applying for an interim registration for now, but will
eventually want to register it for real and want to be sure that we are not too far
off track with our prototypes.

A few words of explanation about the Etherphone. It is a microprocessor-based
device into which plug the following things:

		1. A slightly modified telephone instrument (the "Teleset")
		2. A cord to the telephone company's wall socket (the "Telewall")
		3. A connection to the Ethernet

plus assorted other gear (microphone, speaker, etc).

I've enclosed four drawings. EAP05.sil and EAP06.sil show the relevant parts of
the Etherphone. (I've outlined the particularly relevant parts in red). The
connections to the Teleset are labled P1 - P8 in (pointy boxes) and connections to
the Telewall are labled T1 - T4 (in rectangular boxes). The third drawing is a
copy of the manufacturer's wiring diagram for the telephone instrument we're
using. The fourth drawing, TEL01.sil, shows our modifications of that wiring. 

Note that, independent of everything else, the diode network used for Ring
detection (Dwg. EAP05.sil) is always connected to TipA and RingA - which are
the phone company's Tip and Ring lines seen through 100 uH Deci-Ductors.

Connection between the Etherphone electronics and the Telewall is provided via
the hybrid transformer shown at the bottom of Dwg. EAP05.sil. When the
"Offhook" relay (shown on the same drawing) is activated, TipA and RingA are
connected through the coils of the hybrid transformer. TeleWallSrc and
TeleWallSink are the Etherphone's received and driving signals for the Telewall.

Means are provided to connect the Etherphone electronics to either one or both
of the Teleset and the Telewall, or to connect the Teleset to the Telewall (as a
regular telephone). The Offhook relay and the middle one of the three "Revert"
relays on Dwg. EAP06.sil provide the control for these connections.

If both relays are in the relaxed state, the Revert relay connects the Teleset to
the Telewall as a regular telephone. With the Revert relay relaxed and the
Offhook relay activated, the Teleset and the Etherphone electronics are
(separately) connected to the Telewall - logically in parallel. With the Revert
relay activated and the Offhook relay relaxed, the Telewall is idle and the
Teleset is connected to the Etherphone electronics. With both relays activated,
the Telewall and the Teleset are both connected (separately) to the Etherphone
electronics. 

The signals that control the relays, Revert and GoOffhook, are computer
controlled. A watchdog timer, held off by periodic pokes from the program, will,
if the program fails to poke it, allow the Revert relay to relax. If power fails, of
course all relays relax (hence the term "Revert"). Although the three Revert
relays are driven by the same signal, we have taken no special precautions to
guarantee that they move together. In particular, the 75453B driver sections could
fail in such a way as to leave the three Revert relays in any combination of
states. Only the middle one connects to the phone company lines, but
presumably one must be sure that no matter what happens to the other two, the
Red and Green lines from the teleset won't bear any damaging signals, via the
middle Revert relay, to RingA and TipA. (Although the Red and Green lines
have signal names - HSXmtr1 and HSXmtr2 - they don't in fact go anywhere
except from the middle relay to the Teleset). 

Please call me if you have any questions about how things are supposed to work
and in any case, let us know when you are ready to comment on it. My phone
is (415) 494-4460.

Sincerely,

S.M. Ornstein

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

S.
*start*
00452 00024 US 
Date: 15 Nov. 1982 5:58 pm PST (Monday)
From: Stewart.PA
Subject: Busted Lark.obj
To: Swinehart
cc: Stewart

I seem to have broken Lark.obj by moving the statics.  It repeatedly gets a CallSwat 100E from Free in one of the RPC processes, while trying to Bind.  Coral Sea in the appropriate state, should you happen to look at it.

I wouldn't delete your old copy of Lark.*, meanwhile.  You have the only working copy.
	-Larry 

*start*
00749 00024 US 
Date: 16 Nov. 1982 12:21 am PST (Tuesday)
From: Stewart.PA
Subject: Symbol tables
To: Swinehart
cc: Stewart

I was in a hacking mood, /Ivy/Stewart/Temp/MapParseImpl.mesa is well along the way to symbol table construction, as this scrap indicates...

-- junk.txt
var:  99C2  obuf1
var:  99C4  obuf2
var:  99C6  obuf3
var:  9DD2  SSilThresh
proc: 8689  InitQueue
var:  9B7A  vcb
proc: 7927  CallSwat
proc: 20EF  StopNet
proc: 1E06  InitVCB
proc: 75ED  MoveBlock
proc: 75ED  MoveBlock
proc: 77E9  Swab

Next I'm going to plug in RedBlackTreeRef and eliminate duplicates, sort the things, etc.  Should be straightforward to plug into TDX.

Perhaps we can feed in a DEFS file for structs and handle fields...

This is fun.	-Larry
*start*
00414 00024 US 
Date: 16 Nov. 1982 9:12 am PST (Tuesday)
From: Swinehart.PA
Subject: Re: Symbol tables
In-reply-to: Your message of 16 Nov. 1982 12:21 am PST (Tuesday)
To: Stewart
cc: Swinehart

Yeah -- I started to do that part with edit tool macros, but needed an extra
feature to get the performance up to some acceptable point.  Looks good.  After
we do that, we can possibly avoid the statics table?

*start*
00564 00024 US 
Date: 18 Nov. 1982 9:53 pm PST (Thursday)
From: Stewart.PA
Subject: Line status detector
To: Swinehart
cc: Stewart

I think I've fixed it a different way.  I took another look at the way the telephone was rewired.  There are contacts in the dial which insert a resistor in series with the receiver when a pushbutton is pushed.  I have changed the rewiring so that the resistor still operates even when the Revert relay is energized.  Now the DTMF tones are muted even when running through the electronic hybrid.  Is that good enough?
	-Ly

*start*
01845 00024 US 
Date: 23 Nov. 1982 11:17 am PST (Tuesday)
From: ornstein.PA
Subject: Phone Guy consulting arrangement
To: Taylor, Mitchell
cc: Ornstein, VoiceProject^
Reply-To: ornstein

Bob,

We need some consulting regarding registering (getting phone company
approval) of the Etherphone.  SDD has retained a guy (one J.P. Neil) for this
purpose for their device.  Before we fabricate the Etherphone analog board, we
want some assurance that our design will pass the necessary tests.  Neil is an
expert in that area.  I've talked to Nancy Smith (the responsible SDD person) and
she is willing for us to use his services under their contract - and then pay SDD
back for whatever time we use. I talked to Eric Steffensen who says that to do
this we should issue (with your approval) roughly the following memo.  He's
already spoken to Ann Hickman. 

If you approve, I'll go ahead and prepare the memo. We've already got an
appointment with him for next Thursday so we should get this done ASAP.

Severo 

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

Subj:	The Services of Mr. J. P. Neil
To:	Ann Hickman - SDD
From:	Severo M. Ornstein - CSL

CSL would like to use the services of Mr. J. P. Neil for a small amount of
consulting - in the same vein that SDD has been using him. Rather than write a
separate contract, we would like to use him under SDD's contract, and then pay
SDD back for whatever time we use. At present we anticipate the charges for
CSL work will be under $2000. We will request that Mr. Neil clearly indicate any
CSL charges on his billing to you. You should then bill such charges in turn to
PARC-CSL, Budget Center 50.

cc:	Eric Steffensen
	Robert W. Taylor
	Nancy Smith
	Dan Swinehart
	Larry Stewart

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

*start*
01638 00024 US 
Date: 23 Nov. 1982 2:53 pm PST (Tuesday)
From: ornstein.PA
Subject: Highlight
To: Swinehart, Stewart
cc:  VoiceProject^
Reply-To: ornstein

How you like the following?

- - - - - - - - - - - - - - - - - - - - - - 
An Etherphone is an experimental microprocessor-based device designed to
connect between a telephone instrument, the telephone company's wall socket,
and the Ethernet.  It also includes a microphone and speaker.  Etherphones form
part of an Ethernet-based voice-system which includes one server type to assist
in the control of connections and another to store voice messages. The
Etherphone system can access the regular telephone network and vice-versa. Our
intention is to integrate the Etherphone system with the workstation environment
in such a way as to enable totally new methods of voice communication.  This
will include not only "comfortable" voice message systems, but exploration of
systems which allow people in separate locations to work together in real-time as
naturally as though they were in the same office.  Various elements of this
system have recently commenced working together to provide some basic
facilities:  phone calls can now be made between Etherphones and from an
Etherphone to a regular phone;  we can store and retrieve messages between an
Etherphone and the voice-file-server.  Several prototype copies of the
Etherphone hardware have been built and a dozen printed circuit versions are
presently being manufactured.  By next summer we expect to "outfit" some fifty
offices with Etherphones and to begin experimenting with several initial
applications.
          
*start*
01629 00024 US 
Date: 23 Nov. 1982 3:23 pm PST (Tuesday)
From: ornstein.PA
Subject: Highlight
To: Yao
cc:  VoiceProject^
Reply-To: ornstein


An Etherphone is an experimental microprocessor-based device designed to
connect between a telephone instrument, the telephone company's wall socket,
and the Ethernet.  It also includes a microphone and speaker.  Digitized,
encrypted voice travels between the Etherphones which form part of an
Ethernet-based voice system.  This system also includes two types of servers: one
to assist in the control of connections and another to store voice messages.  The
Etherphone system can access the regular telephone network and vice-versa.

Our intention is to integrate the Etherphone system with the workstation
environment in such a way as to enable totally new methods of voice
communication.  This will include not only "comfortable" voice message systems,
but exploration of systems which allow people in separate locations to work
together in real-time as naturally as though they were in the same office.

Various elements of the system have recently commenced working together to
provide some basic facilities:  phone calls can now be made between Etherphones
and from an Etherphone to a regular phone; we can store and retrieve messages
between an Etherphone and the voice-file-server.  Several prototype copies of
the Etherphone hardware have been built and a dozen packaged, printed-circuit
versions are presently being manufactured.  By next summer we expect to
"outfit" some fifty offices with Etherphones, and to begin experimenting with
initial applications.
          
*start*
01668 00024 US 
Date: 24 Nov. 1982 5:10 pm PST (Wednesday)
From: ornstein.PA
Subject: November CSL Highlight
To: VoiceProject^
Reply-To: ornstein

FYI

---------------------------
Date: 24 Nov. 1982 2:23 pm PST (Wednesday)
From: Mitchell.PA
Subject: November CSL Highlight
To: Spinrad
cc: Ornstein, Yao, Taylor, Mitchell

Bob,

Here is the November highlight from CSL.

Jim Mitchell

-------------------
An Etherphone is an experimental, microprocessor-based device that enables
voice communications over an Ethernet as well as over the public telephone
system.  The device attaches to a telephone, the telephone company's wall socket,
an Ethernet, and a microphone and speaker.  It transmits voice on the Ethernet
in digitized, encrypted form.  An Etherphone system also requires two servers,
one for controlling connections and one for storing and retrieving voice
messages.

Our intention is to integrate an Etherphone system with our workstation
environment to enable us to try new methods of voice communication.  These
will include not only "comfortable" voice message systems, but also systems
which allow people in separate locations to work together in real-time as
naturally as though they were in the same office. 

Parts of the system have recently begun to work together:  we can make calls
from one Etherphone to another or to a regular telephone; we can also store and
retrieve messages using an Etherphone and the voice file server.  By next
summer we expect to install about fifty Etherphones in offices and to begin
developing some experimental applications.
-------------------

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

*start*
00549 00024 US 
Date: 30 Nov. 1982 5:59 pm PST (Tuesday)
From: Stewart.PA
Subject: Data sheets?
To: NDSmith
cc: VoiceProject^.pa, Stewart

We've been talking to J. P. Neil today.  He says he haqs given you some information on gas filled protectors, possibly made by Cook Electric or TII.  Is this true?

I would like to look at the full catalog for the compandy (Midtex?) that makes the hybrid transformer.  have you got one?

You mentioned that you knew where the hybrid design originally came from, could you dig that up for me?

	-Larry