📄 rfc741.txt
字号:
NWG/RFC 741 DC 22 Nov 77 42444
SPECIFICATIONS FOR THE
NETWORK VOICE PROTOCOL (NVP)
and
Appendix 1: The Definition of Tables-Set-#1 (for LPC)
Appendix 2: Implementation Recommendations
NSC NOTE 68
(Revision of NSC Notes 26, 40, and 43)
Danny Cohen, ISI
January 29, 1976
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
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 30
Cohen [Page ii]
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
PREFACE
The major objective of ARPA's Network Secure Communications (NSC)
project is to develop and demonstrate the feasibility of secure,
high-quality, low-bandwidth, real-time, full-duplex (two-way) digital
voice communications over packet-switched computer communications
networks. This kind of communication is a very high priority
military goal for all levels of command and control activities.
ARPA's NSC projrct will supply digitized speech which can be secured
by existing encryption devices. The major goal of this research is
to demonstrate a digital high-quality, low-bandwidth, secure voice
handling capability as part of the general military requirement for
worldwide secure voice communication. The development at ISI of the
Network Voice Protocol described herein is an important part of the
total effort.
Cohen [Page iii]
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
ACKNOWLEDGMENTS
The Network Voice Protocol (NVP), implemented first in December 1973,
and has been in use since then for local and transnet real-time voice
communication over the ARPANET at the following sites:
o Information Sciences Institute, for LPC and CVSD, with a
PDP-11/45 and an SPS-41.
o Lincoln Laboratory, for LPC and CVSD, with a TX2 and the
Lincoln FDP, and with a PDP-11/45 and the LDVT.
o Culler-Harrison, Inc., for LPC, with the Culler-Harrison
MP32A and AP-90.
o Stanford Research Institute, for LPC, with a PDP-11/40 and an
SPS-41.
The NVP's success in bridging the differences between the above
systems is due mainly to the cooperation of many people in the
ARPA-NSC community, including Jim Forgie (Lincoln Laboratory), Mike
McCammon (Culler-Harrison), Steve Casner (ISI) and Paul Raveling
(ISI), who participated heavily in the definition of the control
protocol; and John Markel (Speech Communications Research
Laboratory), John Makhoul (Bolt Beranek & Newman, Inc.) and Randy
Cole (ISI), who participated in the definition of the data protocol.
Many other people have contributed to the NVP-based effort, in both
software and hardware support.
Cohen [Page iv]
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
1. INTRODUCTION
Currently, computer communication networks are designed for data
transfer. Since there is a growing need for communication of
real-time interactive voice over computer networks, new communication
discipline must be developed. The current HOST-to-HOST protocol of
the ARPANET, which was designed (and optimized) for data transfer,
was found unsuitable for real-time network voice communication.
Therefore this Network Voice Protocol (NVP) was designed and
implemented.
Important design objectives of the NVP are:
- 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 consists of two parts:
(1) The control protocol,
(2) The data protocol.
Control messages are sent as controlled (TYPE 0/0) messages, and data
messages may be sent as either controlled (TYPE 0/0) or uncontrolled
(TYPE 0/3) messages (see BBN Report 1822 for definition of
MESSAGE-TYPE).
Throughout this document a "word" means a "16-bit quantity".
Cohen [Page 1]
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
2. THE CONTROL PROTOCOL
Throughout this document the 12-bit MESSAGE-ID (see BBN Report 1822)
is referred to as LINK (its 8 MSBs) and SUB-LINK (its 4 LSBs).
The control protocol starts with an initial connection phase on link
377 and continues on other links assigned at run time.
Four links are used for each voice communication:
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 indicates which
user wants to talk to whom and specifies K. As a response (on K), the
ANSWERER either refuses the call or accepts it and assigns L.
The CALLER then calls again (this time on link L). The ANSWERER
initiates a negotiation session to verify the compatibility of the
two parties.
The negotiation consists of suggestions put forth by one of the
parties, which are either accepted or rejected by the other party.
The suggesting party in the negotiation is called the NEGOTIATION
MASTER. The other party is called the NEGOTIATION SLAVE. Usually the
ANSWERER is the negotiation master, unless agreed otherwise by the
method described later.
If the negotiation fails, either party may terminate the call by
sending a "GOODBYE". If the negotiation is successfully ended, the
ANSWERER rings bells to draw human attention and sends "RINGING" to
the CALLER. When the call is answered (by a human), a "READY" is sent
to the CALLER and the data starts flowing (on L+1 and K+1). However,
a "READY" can be sent without a preceeding "RINGING".
This bell ringing occurs only 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. Extra bits
needed to fill the network-message are ignored.
Cohen [Page 2]
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
The length of control messages should never exceed a single-packet
(i.e., 1,007 data bits).
Control messages not recognized by their receiver should be ignored
and should not cause any error condition resuting in termination of
the connection. These messages may result 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>"
Cohen [Page 3]
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
DEFINITION OF THE CONTROL MESSAGES
#1 CALLING (on 377 and L)
This call is issued first on link 377 and later on link L. Its
format is "1,<WHO>,<WHOM>,K", where <WHO> and <WHOM> are words
which identify respectively the calling party and the party
that is being called, and K is as defined above. The format of
the <WHO> and <WHOM> is:
(HHIIIIIIXXXXXXXX)
where 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 which 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 has the purpose of terminating calls at any stage.
ICP can be terminated (on K) either negatively by sending
either 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.
Cohen [Page 4]
NWG/RFC 741 DC 22 Nov 77 42444
Specifications for the Network Voice Protocol (NVP)
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>", meaning
"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>", meaning: "I-CAN-DO,<WHAT>,<HOW>".
#5 NEGATIVE NEGOTIATION RESPONSE (on L or K)
Sent by the NEGOTIATION SLAVE in response to a NEGOTIATION
INQUIRY. The format is either:
"5,<WHAT>,0", meaning "I-CAN'T-DO-<WHAT>-IN-ANY-OF-THESE-WAYS",
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -