RFC 741 (rfc741) - Page 1 of 30
Specifications for the Network Voice Protocol (NVP)
Alternative Format: Original Text Document
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 theand 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



