RFC 741
Specifications for the Network Voice Protocol (NVP)
NWG/RFC 741 🎀 Title Block Tea ☕
Okay bestie, let's start at the top. This is NWG/RFC 741, filed as DC 22 Nov 77 42444 and dated 22 Nov 77. The title is Specifications for the Network Voice Protocol (NVP), with Appendix 1: The Definition of Tables-Set-#1 (for LPC) and Appendix 2: Implementation Recommendations 💖. It's labelled NSC NOTE 68 and is a revision of NSC Notes 26, 40, and 43 📝. The author is Danny Cohen of ISI, and the note is dated January 29, 1976 🧚. Nothing is listed as obsoleted or updated, so it's a clean slate ✨.
CONTENTS
PREFACE iii
ACKNOWLEDGMENTS iv
INTRODUCTION 2
THE CONTROL PROTOCOL 2
Summary of the CONTROL Messages 3
Definition of the CONTROL Messages 4
Definition of the <WHAT> and <HOW>
Negotiation Tables 8
On RENEGOTIATION 10
The Header of Data Messages 10
THE LPC DATA PROTOCOL 13
EXAMPLES FOR THE CONTROL PROTOCOL 15
APPENDIX 1: THE DEFINITION OF TABLES-SET-#1 18
General Comments 20
Comments on the PITCH Table 20
Comments on the GAIN Table 21
Comments on the INDEX7 Table 21
Comments on the INDEX6 Table 21
Comments on the INDEX5 Table 21
The PITCH Table 22
The GAIN Table 24
The INDEX7 Table 25
The INDEX6 Table 26
The INDEX5 Table 27
APPENDIX 2: IMPLEMENTATION RECOMMENDATIONS 28
REFERENCES 30Preface 💜
So the big goal of ARPA's Network Secure Communications (NSC) project is to prove that secure, high-quality, low-bandwidth, real-time, full-duplex (two-way) digital voice can actually work over packet-switched computer communications networks 🔥. This is a super high-priority military goal for every level of command and control, and it's giving serious responsibility 🫡.
The NSC project supplies digitized speech that existing encryption devices can secure 🔐. The whole research point is showing that digital, high-quality, low-bandwidth, secure voice handling works as part of the general military need for worldwide secure voice communication 🌍. ISI's development of the Network Voice Protocol described in this document is a key piece of the whole effort 🎀.
Acknowledgments 🫶
The Network Voice Protocol (NVP) got implemented first in December 1973 🍓. It has been in use ever since for local and transnet real-time voice communication over the ARPANET at these sites:
- Information Sciences Institute, for LPC and CVSD, with a PDP-11/45 and an SPS-41.
- Lincoln Laboratory, for LPC and CVSD, with a TX2 and the Lincoln FDP, and with a PDP-11/45 and the LDVT.
- Culler-Harrison, Inc., for LPC, with the Culler-Harrison MP32A and AP-90.
- Stanford Research Institute, for LPC, with a PDP-11/40 and an SPS-41.
The NVP's success at bridging the differences between all those systems is mainly thanks to a ton of people in the ARPA-NSC community 🙌. Jim Forgie (Lincoln Laboratory), Mike McCammon (Culler-Harrison), Steve Casner (ISI) and Paul Raveling (ISI) were heavily involved in defining the control protocol 💅. John Markel (Speech Communications Research Laboratory), John Makhoul (Bolt Beranek & Newman, Inc.) and Randy Cole (ISI) worked on defining the data protocol 🦋. Many other people contributed to the NVP-based effort with software and hardware support, so thank you all 💖.
1. Introduction ✨
Okay so computer communication networks are currently designed for data transfer 💻. But there's a growing need for real-time interactive voice over computer networks, so a new communication discipline had to be developed 🌈. The current HOST-to-HOST protocol of the ARPANET was designed (and optimized) for data transfer, and it was found unsuitable for real-time network voice communication 🙈. That's literally why this Network Voice Protocol (NVP) was designed and implemented 🧚.
These are the important design objectives of the NVP, and they're giving main character energy:
- Recovery of loss of any message without catastrophic effects. Therefore all answers have to be unambiguous, in the sense that it must be clear to which inquiry a reply refers 🫶.
- Design such that no system can tie up the resources of another system unnecessarily 💜.
- Avoidance of end-to-end retransmission 🔥.
- Separation of control signals from data traffic 🎀.
- Separation of vocoding-dependent parts from vocoding-independent parts 🦋.
- Adaptation to the dynamic network performance 🌸.
- Optimal performance, i.e. guaranteed required bandwidth, and minimized maximum delay ⭐.
- Independence from lower level protocols 👑.
The protocol has two parts 💅:
- The control protocol,
- The data protocol.
Control messages are sent as controlled (TYPE 0/0) messages. Data messages may be sent as either controlled (TYPE 0/0) or uncontrolled (TYPE 0/3) messages (see BBN Report 1822 for the definition of MESSAGE-TYPE) 🍓.
Throughout this document, a "word" means a "16-bit quantity" 🔢.
2. The Control Protocol 📞
Throughout this document, the 12-bit MESSAGE-ID (see BBN Report 1822) is called LINK (its 8 MSBs) and SUB-LINK (its 4 LSBs) 🧠.
The control protocol kicks off with an initial connection phase on link 377, and then keeps going on other links that get assigned at run time 🚀. Each voice communication uses four links 💖:
Link L will be used for control, from CALLER to ANSWERER.
Link K will be used for control, from ANSWERER to CALLER.
Link L+1 will be used for data, from CALLER to ANSWERER.
Link K+1 will be used for data, from ANSWERER to CALLER.Both L and K should be between 340 and 375 (octal). L and K need not differ 🙃.
The first message (CALLER to ANSWERER) on link 377 says which user wants to talk to whom, and it specifies K 📱. As a response (on K), the ANSWERER either refuses the call or accepts it and assigns L ✅.
Then the CALLER calls again, this time on link L 🔁. The ANSWERER starts a negotiation session to check that the two parties are compatible 🤝.
The negotiation is made of suggestions put forth by one of the parties, which the other party either accepts or rejects 💬. The party making the suggestion is called the NEGOTIATION MASTER, and the other party is called the NEGOTIATION SLAVE 🧑🤝🧑. Usually the ANSWERER is the negotiation master, unless they agree otherwise using the method described later 🌈.
If the negotiation fails, either party can end the call by sending a "GOODBYE" 👋. If the negotiation ends successfully, the ANSWERER rings bells to get human attention and sends "RINGING" to the CALLER 🔔. When a human answers the call, a "READY" is sent to the CALLER and the data starts flowing on L+1 and K+1 🎶. But heads up, a "READY" can be sent without a preceding "RINGING" 👀.
The bell ringing only happens after the initial call, not after renegotiation 🙅♀️.
The assignment of L and K cannot be changed after the initial connection phase 🔒.
Only one control message can be sent in a network-message. Any extra bits needed to fill the network-message are ignored 🧹.
The length of control messages should never exceed a single packet (i.e., 1,007 data bits) 📦.
Control messages that their receiver doesn't recognize should be ignored, and they should not cause any error condition that ends the connection. These messages may come from differences in implementation level between systems 🫠.
Summary of the Control Messages 📋
#1 "1,<WHO>,<WHOM>,K"
#2 "2,<CODE>" or only "2"
#3 "3,<WHAT>,<N>,<HOW(1),...HOW(N)>"
#4 "4,<WHAT>,<HOW>"
#5 "5,<WHAT>,<HOW>" or only "5,<WHAT>"
#6 "6,L" or only "6"
#7 "7"
#8 "8"
#9 "9"
#10 "10,<ID>"
#11 "11,<ID>"
#12 "12,<IM>"
#13 "13,<YM>,<OK>"Definition of the Control Messages 📖
#1 CALLING (on 377 and L) 📞
This call goes out first on link 377, and later on link L. Its format is "1,<WHO>,<WHOM>,K", where <WHO> and <WHOM> are words that identify the calling party and the party being called, respectively. K is as defined above. The format of <WHO> and <WHOM> is:
(HHIIIIIIXXXXXXXX)HH are 2 bits identifying the HOST, followed by 6 bits identifying the IMP, followed by 8 bits identifying the extension (needed because there may be more than one communication unit on the same HOST) 🖥️.
The system that sends this message is defined as the CALLER, and the other system is defined as the ANSWERER 🙋♀️.
#2 GOODBYE (TERMINATION, on L or K) 👋
This message exists to terminate calls at any stage 🛑.
ICP can be terminated (on K) either negatively, by sending a single word "2" ("GOODBYE") or the two words "2,<CODE>", or positively, by sending the two words "6,L", as described later 🙃.
After the initial connection phase, calls can be terminated by either the CALLER (on L) or the ANSWERER (on K). This termination has two words: "2,<CODE>", where <CODE> is the reason for the termination, as specified here 💅:
0. Other than the following.
1. I am busy.
2. I am not authorized to talk with you.
3. Request of my user.
4. We believe you are down.
5. Systems incompatibility (NEGOTIATION failure).
6. We have problems.
7. I am in a conference now.8. You made a protocol error. 🚫
#3 NEGOTIATION INQUIRY (on L or K) 🔍
Sent by the NEGOTIATION MASTER for compatibility verification. The format is:
3,<WHAT>,<LIST-LENGTH>,<HOW-LIST>which means CAN-YOU-DO,<WHAT>,<LIST-LENGTH>,<HOW-LIST>. The <HOW-LIST> is a list of pointers into agreed-upon tables, as shown below. 💅
#4 POSITIVE NEGOTIATION RESPONSE (on L or K) 💖
Sent by the NEGOTIATION SLAVE in response to a NEGOTIATION INQUIRY. The format is:
4,<WHAT>,<HOW>which means: I-CAN-DO,<WHAT>,<HOW> ✨
#5 NEGATIVE NEGOTIATION RESPONSE (on L or K) 🙅♀️
Sent by the NEGOTIATION SLAVE in response to a NEGOTIATION INQUIRY. There are two possible formats.
The first is:
5,<WHAT>,0which means I-CAN'T-DO-<WHAT>-IN-ANY-OF-THESE-WAYS.
The second is:
5,<WHAT>,NThis means the slave can't accept any of the options offered in the INQUIRY, but uses "N" as a suggestion to the ANSWERER about another possibility. Examples are presented later in this report. 🔮
#6 READY (on L or K) 🟢
Sent by either party to say it's ready to accept data. The format is 6,L in the reply to the initial call, and 6 after that. 🎀
#7 NOT READY (on L or K) 🛑
Sent by either party to say it's not ready to accept data. It's always a single word: 7. 🥲
#8 INQUIRY (on L or K) 👀
Sent by either party to ask about the status of the other. It's always a single word: 8. It gets answered by #6, #7, or #9. 💬
#9 RINGING (on K) 📞
Sent by the ANSWERER after the negotiations have been successfully terminated and a human's permission is needed to go further. The ringing keeps going for 10 seconds and then stops, UNLESS a #8 is received. This message is always a single word: 9. 🔔
#10 ECHO REQUEST (on L or K) 🏓
Sent by whichever party wants to measure the network delays. Its only job is to be echoed back immediately. The format is 10,<ID>, where <ID> is any word used to identify the ECHO. 🧚
#11 ECHO (on L or K) 🏓
Sent in response to an ECHO REQUEST. The format is 11,<ID>, where <ID> is the word specified by #10. Implementing this feature is not compulsory, and no connection should be terminated due to lack of response to ECHO-REQUEST. No drama allowed, bestie. 🫶
#12 RENEGOTIATION REQUEST (on L or K) 🔁
Either party can send this at ANY stage after LINKS are agreed upon. The message is just two words: 12,<IM>. If <IM> (for I MASTER) is non-zero, the sender is asking to become the NEGOTIATION MASTER. If it's zero, the receiver is being asked to become the NEGOTIATION MASTER. Renegotiation is described later. 👑
#13 RENEGOTIATION APPROVAL (on L or K) ✅
Either party can send this in response to a RENEGOTIATION REQUEST. It's three words: 13,<YM>,<OK>. If <OK> is non-zero, it's a positive acknowledgment (approval). If it's zero, it's a negative acknowledgment (a refusal). <YM> is set equal to the <IM> of #12, so everyone knows which request it's answering. 🦋
Messages #7, #8, and #9 are always a single word. Messages #1, #3, #4, and #5 are several words long. Messages #2 and #6 are either one word or two words. #10, #11, and #12 are always 2 words long. Message #13 is always 3 words long. Message #1 is always 4 words long. 📏
Message #1 is only sent by the CALLER. #3 is only sent by the NEGOTIATION MASTER. #4 and #5 are only sent by the NEGOTIATION SLAVE. Message #9 is only sent by the ANSWERER. All the other control messages can be sent by either party. 🌈
The last <HOW> that was both suggested by the NEGOTIATION MASTER (in #3) and accepted by the NEGOTIATION SLAVE (in #4) for each <WHAT> is assumed to be in use. 🧠
DEFINITION OF THE <WHAT> AND <HOW> NEGOTIATION TABLES: 📋
These are the agreed-upon tables. Options marked with * are the recommended ones for LPC, and options marked with + are the recommended ones for CVSD.
<WHAT> <HOW>
1. VOCODING * 1. LPC
+ 2. CVSD
3. RELP
4. DELCO
2. SAMPLE PERIOD
(in microseconds) N. N (*150) (+62)
3. VERSION
* 1. V1 (see definition below)
+ 2. V2 (see definition below)
4. MAX MSG LENGTH (in bits)
NVP header included N. N (*976 and +976)
(32 bits) but not HOST/IMP
leader and not HOST/IMP padding
5. If LPC:
Degree N. For N coefficients (*10)
If CVSD:
Time Constant
(in milliseconds) N. N (+50)
6. Samples per Parcel N. N (*128) (+224)
7. If LPC:
Acoustic Coding * 1. SIMPLE (see below)
2. OPTIMIZED
8. If LPC:
Info Coding * 1. SIMPLE (see below)
2. OPTIMIZED
9. If LPC:
Pre-emphasis N. N (*58, for
1 - mu x [Z**-1] mu = 58/64 = 0.90625)
N = 64 x mu
10. If LPC:
Table-set N. N (*1)
See definition of Set #1
in Appendix 1
(* indicates recommended options for LPC)
(+ indicates recommended options for CVSD)No parameter (<WHAT>) should be asked about by the NEGOTIATION MASTER if the SLAVE has already accepted some option (<HOW>) for it implicitly in the "VERSION". The reason for this rule is to avoid a possible clash between individual parameters and the VERSION option. 🙈
Version 1 (V1) is defined as:
1-1 LPC
2-150 150 microseconds sampling
3-1 V1
5-10 10 coefficients
6-128 128 samples per parcel
7-1 SIMPLE acoustic coding
8-1 SIMPLE information coding
9-58 mu = 58/64 = 0.90625
10-1 Tables set #1Version 2 (V2) is defined as:
1-2 CVSD
2-62 62 microseconds sampling (16 KHz sampling)
3-2 V2
5-50 50 msec time constant
6-192 192 samples per parcelHeads up: this defines every negotiated parameter EXCEPT MAX MSG LENGTH. 👀
SIMPLE and OPTIMIZED codings will be described below in Section 3. 🔜
All the negotiation is run by the NEGOTIATION MASTER. It decides how much negotiation is needed, and what to do if an incompatibility is found: either try other options or abort the connection. Once the negotiation succeeds, the NEGOTIATION MASTER sends #9 (RINGING) only if it's the ANSWERER and this is an initial connection. Otherwise it sends #6 (READY-FOR-DATA). It'll probably also ask with #8 whether the other party is ready. Inquiries (#8) sent before the negotiation succeeds get ignored. But inquiries sent after the first RINGING (#9) and before the first READY (#6) are needed to keep the ANSWERER ringing. 🔔
The negotiation can be made shorter by using the VERSION option, like in the examples that follow. ⚡
ON RENEGOTIATION 🔁✨
At any stage after links are agreed upon, either party might request a RENEGOTIATION. If the other party approves, either party might become the NEGOTIATION MASTER, depending on the type of renegotiation request. When renegotiation starts, no previously negotiated agreements hold (except LINK numbers), and everything has to be renegotiated from scratch. Renegotiation can replace the whole negotiation phase, and it lets the CALLER be the NEGOTIATION MASTER. 💅
When a RENEGOTIATION REQUEST is sent or received, all data messages are ignored until the positive indication that renegotiation has finished (#6). 🙉
After renegotiation completes, the frame-count (see the section on MESSAGE-HEADER) may be reset to zero. 🌸
THE HEADER OF DATA MESSAGES 🎶
Data messages are the messages that carry vocoded speech. The first 32 bits of each data message are the MESSAGE-HEADER, which carries sequence and timing info, as described below. 🎤
For each vocoding scheme, a "FRAME" is defined as the transmission interval (as agreed upon at the negotiation stage in <WHAT#6>). Because this interval is defined by a number of samples, its duration is found by multiplying the sampling period <WHAT#2> by the interval length (in samples) <WHAT#6>. For example, in V1 the sampling period is 150 microseconds and the transmission interval is 128 samples, which gives:
128*150 microseconds = 19.2 milliseconds.The data describing a FRAME is called a PARCEL. Each parcel has a serial number. The first parcel created after the negotiation completes (or after every RENEGOTIATION) has the serial number zero. Each message contains a whole number of parcels. 🧩
The serial number of the first parcel in the message goes in the first 16 bits of the message, and it's called the MESSAGE-TIME-STAMP. This time stamp is synced with the data stream. Also, those 16 bits are actually the third word of the message, coming after the 2 words used as the IMP-to-HOST leader (see BBN Report 1822). ⏰
The next bit in the header is the WE-SKIPPED-PARCELS bit, which gets explained later. The next 7 bits say how many parcels are in the message. This number is called the COUNT, or the PARCEL-COUNT. 🔢
If message number N has the time stamp T(N) and the count C(N), then T(N+1) must be greater than or equal to T(N)+C(N). Usually T(N+1) = T(N)+C(N), unless the XMTR chose not to send some parcels because of silence. When that happens, the WE-SKIPPED-PARCELS bit is set to ONE. Otherwise it's set to ZERO. So if the RCVR finds that T(N+1) is greater than T(N)+C(N) and WE-SKIPPED-PARCELS is zero, some message must have been lost. 🕵️♀️
By definition, the time stamps on messages monotonically increase, except for wrap-around. 🔄
The message header structure is shown in this diagram: 🖼️
WORD 1 WORD 2 WORD 3 WORD 4
!................!................!................!................!...
!P000TTTTHHIIIIII!LLLLLLLLZZZZZZZZ!TTTTTTTTTTTTTTTT!WCCCCCCCSSSSSSSS!DDD
!................!................!................!^...............!...Okay bestie, the header layout is the last piece of the control message format, so here it is 🎀
!<--HOST/IMP-OR-IMP/HOST-LEADER-->!<--TIME-STAMP-->!^<COUNT><-SAVE->!<-D
^
WE-SKIPPED-PARCELS
P = PRIORITY (one bit = 1)
T = MESSAGE TYPE (4 bits = 0011)
L = link ("L" OR "K", 8 bits, greater than 337 octal)
D = data bits (from here to the end of the message)
ZZZZZZZZ = 8 ZERO bits
HHIIIIII = HOST (8 bits, destination or source)
CCCCCCC = parcel COUNT (7 bits)
SSSSSSSS = 8 bits saved for future applications
TTTTTTTTTTTTTTTT = TIME STAMP (16 bits)The first parcel sent by either party after the NEGOTIATION or RENEGOTIATION should have the serial number set to zero. Main character move, honestly 💅
During silence periods, the XMTR might send a 6 or 7 message periodically 🌸. If it doesn't, the RCVR might check on the livelihood of the XMTR by sending periodically 8 ("ARE-YOU-THERE?") or #10 (ECHO-REQUEST) messages. Like, checking in on your bestie so she knows you're still there 🫶
3. THE LPC DATA PROTOCOL ✨
The DATA sent at each transmission interval is called a PARCEL 🦋
Network messages always contain an integral number of PARCELs. No half parcels, periodt 💖
There are two independent issues in the coding. One is, obviously, the acoustic coding, i.e., which parameters have to be transmitted. SIMPLE acoustic coding is sending all the parameters at every transmission interval. OPTIMIZED acoustic coding sends only as little as acoustically needed. DELCO is an example of OPTIMIZED acoustic coding. So DELCO is the lowkey efficient one 🧚
In this document only the format of the SIMPLE acoustic coding is defined 🍓
All the transmitted parameters are sent as pointers into agreed-upon tables. These tables are defined as two lists of values. The transmitter table {X(J)} is used in the following way: the value V is coded as the code J if X(J-1) < V =< X(J). The receiver table {R(J) is used to retrieve the value R(J) if the code J was received. X(-1) is implicitly defined as minus-infinity, and X(Jmax) is explicitly defined as plus-infinity. It's giving pointer energy, no cap ✨
For each parameter, {X(J)} and {R(J) may be defined independently. Mix and match, iykyk 🌈
The second coding issue is the information coding technique. The SIMPLE (information-wise) way of sending the information is to use binary coding for the codes representing the parameters. The OPTIMIZED way is to compute distributions for each parameter and to define the appropriate coding. It is very probable that the PITCH and GAIN will be decoded absolutely in the first PARCEL of each message, and incrementally thereafter 👑
At present, only the SIMPLE (information-wise) coding is used 💜
The details of the LPC data protocol and its Tables-Set-#1 can be found in Appendix 1. Go check it, it's iconic 🎀
Following is the definition for the format of the SIMPLE-SIMPLE coding, according to Tables-Set-#1:
For each parcel:
PITCH 6 bits (PITCH=0 for UNVOICED)
GAIN 5 bits
I(1) 7 bits
I(2) 7 bits
I(3) 6 bits
I(4) 6 bits
I(5) 5 bits
I(6) 5 bits
I(7) 5 bits
I(8) 5 bits
I(9) 5 bits
I(10) 5 bitsEach of the I(j) is an index for inverse sine coding. If K(j)=arcsin(Theta(j)) and N bits are assigned for its transmission, then I(j)=(Theta(j)/Pi)*2**N. Math bestie, we love to see it 🙈
Hence at each transmission interval (128 samples times 150 microseconds) 67 bits are sent, which results in a data rate of 3490 bps. Since this bandwidth is well within the capabilities of the network, SIMPLE-SIMPLE coding is used, which requires the least computation by the hosts. Note that this data rate is a peak rate, without the use of silence. So it's the worst-case vibe, but still totally fine 💅✨
4. EXAMPLES FOR THE CONTROL PROTOCOL 🌈
Here's an example for a connection. Watch the whole call go from "hey, talk to me" to "bye" 📞
(377) C: 1,<WHO>,<WHOM>,340 Please talk to me on 340/341.
(340) A: 2,1 I refuse, since I'm busy.Another example, and this one has a full negotiation arc. Major plot twist moment 😭
(377) C: 1,<WHO>,<WHOM>,360 Please talk to me on 360/361.
(360) A: 6,350 OK. You talk to me on 350/351.
(350) C: 1,<WHO>,<WHOM> I want to talk to you.
(360) A: 3,1,1,2 Can you do CVSD? (ANSWERER tries
to be the NEGOTIATION MASTER)
(350) C: 12,1 I want to be it.
(360) A: 13,1 That's OK with me.
(350) C: 3,1,1,2 Can you do CVSD?
(360) A: 5,1,1 No, but I can do LPC.
(350) C: 3,1,1,3 Can you do RELP?
(360) A: 5,1,1 No, but I can do LPC.
(350) C: 3,1,1,1 How about LPC?
(360) A: 4,1,1 LPC is fine with me.
(350) C: 3,2,1,150 Can you use 150 microseconds
sampling?
(360) A: 4,2,150 I can use 150 microseconds.
(350) C: 3,4,3,976,1040,2016 Can you use 976, 1040, or 2016
bits/msg?
(360) A: 4,4,976 I can use 976.
(350) C: 3,5,1,10 Can you send 10 coefficients?
(360) A: 4,5,10 I can send 10.
(350) C: 3,6,1,64 Can you use a 64 sample
transmission?
(360) A: 4,6,64 I can use 64.
(350) C: 3,7,2,1,2 SIMPLE or OPTIMIZED acoustic
coding?
(360) A: 4,7,2 OPTIMIZED!
(350) C: 3,8,1,1 Can you do SIMPLE info coding?
(360) A: 4,8,1 I can do SIMPLE.
(350) C: 3,9,1,58 mu = 0.90625?
(360) A: 4,9,58 Fine with me.
(350) C: 3,10,1 Table set #1?
(360) A: 4,10,1 Of course!
(350) C: 6 I am ready. (Note: No "RINGING"
sent)
(350) C: 8 And you?
(360) A: 6 I am ready, too.
....... Data is exchanged now,
....... on 351 and 361.
(350) C: 10,1234 Echo it, please.
(360) A: 11,1234 Here it comes!
.......
(360) A: 10,3333 Now ANSWERER wants to measure
(350) C: 11,3333 ...the delays, too.
.......
(???) X: 2,3 Termination by either user.Another example, where the answerer does the ringing thing and the caller eventually gives up 💀
(377) C: 1,<WHO>,<WHOM>,360 Please talk to me on 360/361.
(360) A: 6,340 Fine. You send on 340/341.
(340) C: 1,<WHO>,<WHOM> I want to talk to you.
(360) A: 3,3,1,1 Can you use V1?
(340) C: 4,3,1 Yes, V1 is OK.
(360) A: 3,4,1,1984 Can you use up to 1984 bits/msg?
(340) C: 5,4,976 No, but I can use 976.
(360) A: 3,4,1,976 Can you use up to 976 bits/msg?
(340) C: 4,4,976 I can use 976.
(360) A: 9 Ringing (note how short this
negotiation is!!).
.......
(340) C: 8 Still there?
(360) A: 9 Still ringing.
.......
(340) C: 8 Still there?
(360) A: 9 Still ringing.
.......
(340) C: 8 How about it?
(360) A: 9 Still ringing.
(340) C: 2 Forget it! (No reason given.)APPENDIX 1 🦋
THE DEFINITION OF:
TABLES-SET-#1
by
John D. Markel
Speech Communication Research Laboratory
Santa Barbara, California
TABLES-SET-#1This appendix is by John D. Markel, from the Speech Communication Research Laboratory in Santa Barbara, California, and it's the tea on all the tables 🍵
This set includes tables for:
PITCH - 64 values, PITCH table
GAIN - 32 values, GAIN table
I( 1) - 128 values, INDEX7 table
I( 2) - 128 values, INDEX7 table
I( 3) - 64 values, INDEX6 table
I( 4) - 64 values, INDEX6 table
I( 5) - 32 values, INDEX5 table
I( 6) - 32 values, INDEX5 table
I( 7) - 32 values, INDEX5 table
I( 8) - 32 values, INDEX5 table
I( 9) - 32 values, INDEX5 table
I(10) - 32 values, INDEX5 tableThese tables are defined specifically for a sampling period of 150 microseconds ⏱️
GENERAL COMMENTS ✨
The following tables are arranged in three columns, {X(j)}, {j}, and {R(j)}. Note that the entries in the {X(j)} column are half a step off the other columns. This is to indicate that INTERVALS from the X-domain (pitch, gain, and the Ks) are mapped into CODES {j}, which are transmitted over the network, to be translated by the receiver into the {R(j)}. These intervals are defined as OPEN-CLOSE intervals. For example, the PITCH value (at the transmitter) of 4131 belongs to the interval (4024,4131], hence it is coded as j=6 which is mapped by the receiver to the value 21. Similarly, the value of 2400 for INDEX7 is found to belong to the interval (2009,2811], coded into the CODE 3 and mapped back into 2411. Interval math with a little drama 🎀
Note that if N bits are used by a certain CODE, then there are 2**N+1 entries in the X-table, but only 2**N entries in the R-table 🧮
The transformation values used for PITCH, GAIN, and the K-parameters (in the X- and R-tables) are as defined in NSC Note 42 📝
Values above and below the range of the X-table are mapped into the maximum and minimum table indices, respectively. Edge cases, handled 💅
Note that R(J) of INDEX5 is identical to R(2J) of INDEX6, and that R(J) of INDEX6 is identical to R(2J) of INDEX7. Therefore, it is possible to store only the R-table of INDEX7, without the R-tables of INDEX5 and INDEX6. Storage glow-up unlocked 🌸
In the SPS-41 implementation there is no need to store any R-table for the K-parameters. The transmitted index can be used directly (with the appropriate scaling) as an index into the SPS built-in TRIG tables. Literally no extra table needed, the vibes are immaculate ✨
COMMENTS ON THE PITCH TABLE 🎵
The level J=0 defines the UNVOICED condition. The receiver maps it into the number of samples per frame (here 128).
This PITCH table differs significantly from previous tables and supersedes the table published in NSC Note 36. Details of the calculation of the table can be found in NSC Note 42. Immediate questions should be referred to John Markel. Go ask the expert, babe 🫶
COMMENTS ON THE GAIN TABLE 🌈
The level J=0 defines absolute silence. Shhh 🤫
This table is designed for a maximum of 12-bit A/D input, and allows for a dynamic range of 43.5 dB.
NSC Notes 36, 45, 56 and 58 supply background for the GAIN table. Gain is the energy of the pre-emphasized, windowed signal.
This table is the NEW GAIN table. NSC Notes 56 and 58 explain the reasoning behind the NEW GAIN. The name is giving "new and improved" energy 💖
COMMENTS ON THE INDEX7 TABLE 🍓
Positive values are coded into the range [0-63, decimal]. Negative values are coded into the 7-bits two's complement of the codes of their absolute value [65-127, decimal]. Bit-level brain teaser, and we're still obsessed 🧠✨
Okay bestie, so every value from -403 to 403 (that's -403 < V < 403) gets coded as 0 and mapped right into it 💅 Also the code -64 (that's 100 in octal 🍓) is never used, so don't go looking for it ✨
In the SPS-41 implementation, you don't even need the R-table 🙅♀️ because TRIG(2J) is already the value R(J) you want 💖
COMMENTS ON THE INDEX6 TABLE 🦋
Positive values get packed into [0-31, decimal]. Negative values get the 6-bits two's complement of their absolute values' codes, which lands in [33-63, decimal] 💜
Every value from -805 to 805 (that's -805 < V < 805) gets coded as 0 and mapped into it 🌸 The code -32 (that's 40 in octal) is never used, lowkey iconic 👑
In the SPS-41 implementation, the R-table is not needed, since TRIG(4J) is the value R(J) 🧚
COMMENTS ON THE INDEX5 TABLE 🌈
Positive numbers get coded into the range [0-15, decimal] 🍓 Negative numbers get the 5-bits two's complement of their absolute values, which is [17-31, decimal] ✨
Every value from -1609 to 1609 (that's -1609 < V < 1609) gets coded as 0 and mapped into it 💀 The code -16 (that's 20 in octal) is never used, so skip it 🙈
In the SPS-41 implementation, the R-table is not needed, since TRIG(8J) is the value R(J) 🫶
THE PITCH TABLE (as of 10-29-74) 🎀
X(J) J R(J) X(J) J R(J) X(J) J R(J)
0 6002 10770
0 128* 21 33 42 61
0 6168 11080
1 18 22 34 43 63
3630 6338 11399
2 19 23 35 44 65
3724 6515 11728
3 19 24 36 45 67
3821 6696 12067
4 20 25 37 46 69
3921 6883 12417
5 20 26 38 47 71
4024 7075 12776
6 21 27 39 48 73
4131 7274 13147
7 22 28 40 49 75
4240 7478 13529
8 22 29 41 50 77
4353 7689 13922
9 23 30 43 51 80
4469 7905 14327
10 24 31 44 52 82
4588 8129 14745
11 24 32 45 53 85
4711 8359 15175
12 25 33 47 54 87
4838 8596 15618
13 26 34 48 55 90
4969 8840 16075
14 27 35 50 56 93
5104 9092 16545
15 27 36 51 57 95
5242 9351 17029
16 28 37 53 58 98
5385 9618 17529
17 29 38 54 59 101
5533 9894 18043
18 30 39 56 60 104
5684 10177 18572
19 31 40 57 61 107
5841 10469 19118
20 32 41 59 62 111
6002 10770 19681
63 114
infinityHeads up, this table only has 58 different intervals defined 🧐 That's because 5 values are repeated in the R(j) table 💅
* This value is the "Transmission Interval" (measured in samples) as defined in item #6 of the NEGOTIATION. 🎀
THE GAIN TABLE (as of 9-17-75) 📈
X(J) J R(J) X(J) J R(J)
0 225
0 0 16 245
20 266
1 20 17 289
22 315
2 24 18 342
26 372
3 28 19 404
30 439
4 33 20 478
36 519
5 39 21 565
42 614
6 46 22 667
50 725
7 54 23 789
59 857
8 64 24 932
70 1013
9 76 25 1101
83 1197
10 90 26 1301
98 1415
11 106 27 1538
116 1672
12 126 28 1818
137 1976
13 148 29 2148
161 2335
14 175 30 2539
191 2760
15 207 31 3000
255 infinityINDEX7 TABLE (as of 9-23-74) 🌸
X(J) J R(J) X(J) J R(J) X(J) J R(J)
0 15800 27897
0 0 21 16151 42 28106
402 16500 28311
1 804 22 16846 43 28511
1206 17190 28707
2 1608 23 17531 44 28899
2009 17869 29086
3 2411 24 18205 45 29269
2811 18538 29448
4 3212 25 18868 46 29622
3612 19195 29792
5 4011 26 19520 47 29957
4410 19841 30118
6 4808 27 20160 48 30274
5205 20475 30425
7 5602 28 20788 49 30572
5998 21097 30715
8 6393 29 21403 50 30853
6787 21706 30986
9 7180 30 22006 51 31114
7571 22302 31238
10 7962 31 22595 52 31357
8351 22884 31471
11 8740 32 23170 53 31581
9127 23453 31686
12 9512 33 23732 54 31786
9896 24008 31881
13 10279 34 24279 55 31972
10660 24548 32058
14 11039 35 24812 56 32138
11417 25073 32214
15 11793 36 25330 57 32286
12167 25583 32352
16 12540 37 25833 58 32413
12910 26078 32470
17 13279 38 26320 59 32522
13646 26557 32568
18 14010 39 26791 60 32610
14373 27020 32647
19 14733 40 27246 61 32679
15091 27467 32706
20 15447 41 27684 62 32729
15800 27897 32746
63 32758
infinityINDEX6 TABLE (as of 9-23-74) 🍓
X(J) J R(J) X(J) J R(J)
0 22595
0 0 16 23170
804 23732
1 1608 17 24279
2411 24812
2 3212 18 25330
4011 25833
3 4808 19 26320
5602 26791
4 6393 20 27246
7180 27684
5 7962 21 28106
8740 28511
6 9512 22 28899
10279 29269
7 11039 23 29622
11793 29957
8 12540 24 30274
13279 30572
9 14010 25 30853
14733 31114
10 15447 26 31357
16151 31581
11 16846 27 31786
17531 31972
12 18205 28 32138
18868 32286
13 19520 29 32413
20160 32522
14 20788 30 32610
21403 32679
15 22006 31 32729
22595 infinityINDEX5 TABLE (as of 9-23-74) 💜
X(J) J R(J) X(J) J R(J)
0 22006
0 0 8 23170
1608 24279
1 3212 9 25330
4808 26320
2 6393 10 27246
7962 28106
3 9512 11 28899
11039 29622
4 12540 12 30274
14010 30853
5 15447 13 31357
16846 31786
6 18205 14 32138
19520 32413
7 20788 15 32610
22006 infinityAPPENDIX 2 🎀
IMPLEMENTATION RECOMMENDATIONS ✨
- It is recommended that the priority-bit be turned ON in the HOST/IMP header. 💖
- It is recommended that in all abbreviations, "R" be used for Receiver and "X" for Transmitter. 🫶
(3) okay so bestie, these are the identifiers and values that are recommended for implementations 💖 Here's the whole squad:
SLNCTH30🎀 SILENCE-THRESHOLD. This one's for the LONG-SILENCE definition (more on that below). It's measured in the same units as GAIN, in its X-table, so keep those units straight 📏TBS1.000 sec⏳ TIME-BEGIN-SILENCE. A LONG-SILENCE gets declared ifGAIN<SLNCTHfor more thanTBS. Basically, the quiet has to last a while before it counts 🤫TAS0.500 sec🌸 TIME-AFTER-SILENCE. The receiver adds this little delay after the end of a LONG-SILENCE and before it restarts playback. A pause before the vibe comes back 🦋TES0.150 sec🧚 TIME-END-SILENCE. This is how far the transmitter backs up at the end of a LONG-SILENCE, so the transition back into speech is smooth and not choppy 🫶TRI2.000 sec📞 TIME-RESPONSE-INITIAL. How long to wait for a response to an initial call (#1 and #3). The initial call gets repeated everyTRIuntil an answer shows up, or untilTRIGUexpires. Persistence is a whole mood 💅TRIGU20.000 sec💀 TIME-RESPONSE-INITIAL-GIVEUP. If nothing comes back to an initial call withinTRIGUafter the FIRST initial call, the system gives up and assumes the other system is down. Rest in peace, other system 🕊️TRQ1.000 sec🔁 TIME-RESPONSE-INQUIRY. If no response to an inquiry (#8) comes in withinTRQ, the inquiry gets repeated 🍓TRQGU10.000 sec😭 TIME-RESPONSE-INQUIRY-GIVEUP. If no response to an inquiry arrives withinTRQGUfrom the FIRST inquiry, the system gives up and assumes the other system is down. Ghosted, fr fr 👻TBDA3.000 sec🌈 TIME-BETWEEN-DATA-ARRIVAL. If no data shows up withinTBDA, an INQUIRY (#8) gets sent. This repeats everyTBDA⭐TNR2.000 sec🙈 TIME-NOT-READY. If the other system has been in the NOT-READY (#7) state for more thanTNR, an INQUIRY (#8) gets sent. This repeats everyTNR💜TNRGU10.000 sec🥀 TIME-NOT-READY-GIVEUP. If the other system stays in the NOT-READY (#7) state for more thanTNRGU, the system gives up and assumes the other system is down. It's giving "I've waited long enough" 🙄TBIN3.000 sec🪣 TIME-BUFFER-IN. The input buffer size is equivalent to the time periodTBIN, and its size is the DATA-RATE multiplied by the periodTBIN. If the INPUT QUEUE ever gets longer thanTBIN, data gets discarded. Overflow, not it 💅TBOUT3.000 sec🪣 TIME-BUFFER-OUT. The output buffer size is equivalent to the time periodTBOUT, and its size is the DATA-RATE multiplied by the periodTBOUT. If the OUTPUT QUEUE ever gets longer thanTBOUT, data gets discarded. Same energy, other direction 🔥
References 📚
- Bolt Beranek & Newman, Inc., Report No. 1822, Interface Message Processor: Specifications for the Interconnection of a Host and an IMP. 🧾
- NSC Note 42 (in progress). 🚧
- NSC Note 36, Proposal for NSC-LPC Coding/Decoding Tables, by J. D. Markel, Speech Communications Research Laboratory, Inc., July 20, 1974. 🎙️
- NSC Note 45, Everything You Always Wanted to Know about Gain, by E. Randolph Cole, USC/Information Sciences Institute, October 11, 1974. 📈
- NSC Note 56, Nothing to Lose, but Lots to Gain, by John Makhoul and Lynn Cosell, Bolt Beranek & Newman, Inc., March 10, 1975. 💖
- NSC Note 58, Gain Again, by Randy Cole, USC/Information Sciences Institute, March 12, 1975. ✨
📦 where this page comes from
- ietf: rfc741 1977-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms