RFC741 日本語訳
0741 Specifications for the Network Voice Protocol (NVP). D. Cohen. November 1977. (Format: TXT=57581 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG/RFC 741 DC 22 Nov 77 42444
NWG/RFC741DC1977年11月22日、42444
SPECIFICATIONS FOR THE
仕様
NETWORK VOICE PROTOCOL (NVP)
ネットワーク声のプロトコル(NVP)
and
そして
Appendix 1: The Definition of Tables-Set-#1 (for LPC)
付録1: テーブルで設定された#1の定義(LPCのための)
Appendix 2: Implementation Recommendations
付録2: 実現推薦
NSC NOTE 68
NSC注意68
(Revision of NSC Notes 26, 40, and 43)
(NSC注意26、40、および43の改正)
Danny Cohen, ISI
ダニー・コーエン、ISI
January 29, 1976 NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
1976年1月29日に、ネットワーク声のためのNWG/RFC741DC1977年11月22日の42444仕様は議定書を作ります。(NVP)
CONTENTS
コンテンツ
PREFACE iii
PREFACE iii
ACKNOWLEDGMENTS iv
ACKNOWLEDGMENTS iv
INTRODUCTION 2
序論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
<のコントロールメッセージ4定義のコントロールメッセージ3定義の制御プロトコル2概要は、>交渉がデータメッセージ10のRENEGOTIATION10ヘッダーの上に8を見送るどんな>と<であるか。
THE LPC DATA PROTOCOL 13
LPCデータプロトコル13
EXAMPLES FOR THE CONTROL PROTOCOL 15
制御プロトコル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
付録1: テーブル26 テーブル25 テーブル21INDEX5ピッチのINDEX6テーブル21コメントのINDEX7テーブル21コメントのテーブル21の利得コメントのテーブル20のピッチコメントの#1 18の概評20のコメントを設定しているテーブル22 利得を見送っているテーブル24 INDEX7INDEX6INDEX5テーブル27の定義
APPENDIX 2: IMPLEMENTATION RECOMMENDATIONS 28
付録2: 実現推薦28
REFERENCES 30
参照30
Cohen [Page ii]
コーエン[ページii]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(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.
ARPAのNetwork Secure Communications(NSC)プロジェクトの主要な目的は、安全で、高品質な低バンド幅に関する実現の可能性を開発して、示すことです、リアルタイムでです、パケットで切り換えられたコンピュータ通信網の上の全二重(ツーウェイ)のデジタル声のコミュニケーション。 この種類に関するコミュニケーションはすべてのレベルの指揮統制活動の非常に高い優先権軍事の目標です。 projrctが供給するARPAのNSCは既存の暗号化装置で保証できるスピーチをデジタル化しました。 この研究の主要な目標は世界的な秘密音声コミュニケーションのための一般的な軍事の要件の一部としてデジタル高品質で、低バンド幅の、そして、安全な声の取り扱い能力を示すことです。 ここに説明されたNetwork VoiceプロトコルのISIでの開発は総努力の重要な部分です。
Cohen [Page iii]
コーエン[ページiii]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(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:
Network Voiceプロトコル(NVP)、1973年12月に1番目を実行して、それ以来以下のサイトのアルパネットの上の地方の、そして、transnetなリアルタイムの声のコミュニケーションに中で以下を使用することでした。
o Information Sciences Institute, for LPC and CVSD, with a
PDP-11/45 and an SPS-41.
o 科学がLPCとCVSDのためにPDP-11/45と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 LPCとCVSD、TX2とリンカーンFDP、PDP-11/45、およびLDVTがあるリンカーン研究所。
o Culler-Harrison, Inc., for LPC, with the Culler-Harrison
MP32A and AP-90.
o 害獣駆除業者ハリソン、Inc.、LPCのための害獣駆除業者ハリソンMP32AとAP-90と共に。
o Stanford Research Institute, for LPC, with a PDP-11/40 and an
SPS-41.
o PDP-11/40とSPS-41とLPCのためのスタンフォード研究所。
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.
NVPの成功は上のシステムの違いに橋を架けるのを主にARPA-NSC共同体への多くの人々の協力のためです、大いに制御プロトコルの定義に参加したジムForgie(リンカーン研究所)、マイクMcCammon(害獣駆除業者ハリソン)、スティーブCasner(ISI)、およびポールRaveling(ISI)を含んでいて。 そして、ジョン・マーケル(Speech通信総合研究所)とジョンMakhoul(ボルトBeranekとニューマンInc.)とランディ・コール(ISI)は議定書を作ります。(彼はデータの定義に参加しました)。 多くの他の人々がソフトウェアとハードウェアサポートの両方でのNVPベースの努力に貢献しました。
Cohen [Page iv]
コーエン[ページiv]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
1. INTRODUCTION
1. 序論
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.
現在、コンピュータ通信ネットワークはデータ転送のために設計されます。 コンピュータネットワークの上にリアルタイムの対話的な声に関するコミュニケーションの増加している必要があるので、新しいコミュニケーション規律を開発しなければなりません。 リアルタイムのネットワーク声のコミュニケーションに、データ転送のために設計された(そして、最適化されます)アルパネットのHOSTからHOSTへの現在のプロトコルが不適当であることがわかりました。 したがって、このNetwork Voiceプロトコル(NVP)は、設計されて、実行されました。
Important design objectives of the NVP are:
NVPの重要な設計目標は以下の通りです。
- 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.
- vocodingから独立している部分からのvocoding依存する部品の分離。
- 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:
プロトコルは2つの部品から成ります:
(1) The control protocol,
(1) 制御プロトコル
(2) The data protocol.
(2) データは議定書を作ります。
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).
制御された(TYPE0/0)メッセージとしてコントロールメッセージを送ります、そして、どちらかが(TYPE0/0)か非制御(TYPE0/3)のメッセージを制御したので(MESSAGE-TYPEの定義に関してBBN Report1822を見てください)、データメッセージを送るかもしれません。
Throughout this document a "word" means a "16-bit quantity".
このドキュメント中では、「単語」は「16ビットの量」を意味します。
Cohen [Page 1]
コーエン[1ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
2. THE CONTROL PROTOCOL
2. 制御プロトコル
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).
このドキュメント中では、12ビットのMESSAGE-ID(BBN Report1822を見る)はLINK(8MSBs)とSUB-LINK(4LSBs)と呼ばれます。
The control protocol starts with an initial connection phase on link 377 and continues on other links assigned at run time.
制御プロトコルは、リンク377で初期の接続フェーズから始まって、ランタイムのときに割り当てられた他のリンクの上に続きます。
Four links are used for each voice communication:
4個のリンクがそれぞれの声のコミュニケーションに使用されます:
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.
リンクLはCALLERからANSWERERまでのコントロールに使用されるでしょう。 リンクKはANSWERERからCALLERまでのコントロールに使用されるでしょう。 L+1をリンクしてください。データのために、CALLERからANSWERERまで使用されるでしょう。 リンクK+1はデータにANSWERERからCALLERまで使用されるでしょう。
Both L and K should be between 340 and 375 (octal). L and K need not differ.
LとKの両方が、340〜375であるべきです(8進)。 LとKは異なる必要はありません。
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.
リンク377の(ANSWERERへのCALLER)が、どのユーザがだれと話したいか、そして、応答(Kの)、K.As ANSWERERを指定するかを示すという最初のメッセージは、呼び出しを拒否するか、それを受け入れて、または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.
そして、CALLERは、再び(リンクLの上の今回)と呼びます。 ANSWERERは、2回のパーティーの互換性について確かめるために交渉セッションを開始します。
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.
交渉は相手が受け入れるか、または拒絶するパーティーのひとりによって差し出された提案から成ります。 交渉における示唆パーティーはNEGOTIATION MASTERと呼ばれます。 相手はNEGOTIATION SLAVEと呼ばれます。 通常、別の方法で後で説明された方法によって同意されない場合、ANSWERERは交渉マスターです。
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".
交渉が失敗するなら、何れの当事者は、「さようなら」を送ることによって、呼び出しを終えるかもしれません。 交渉が首尾よく終わるなら、ANSWERERは人間の注意を引くためにベルを鳴らして、「鳴ること」を訪問者に送ります。 呼び出しに答えるとき(人間で)、「準備ができること」を訪問者に送ります、そして、データは流れ始めます(L+1とK+1で)。 しかしながら、preceedingが「鳴る」でなくて、「準備ができること」を送ることができます。
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.
初期の接続フェーズの後にLとKの課題を変えることができません。
Only one control message can be sent in a network-message. Extra bits needed to fill the network-message are ignored.
ネットワークメッセージで1つのコントロールメッセージしか送ることができません。 ネットワークメッセージをいっぱいにするのが必要である余分なビットは無視されます。
Cohen [Page 2]
コーエン[2ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
The length of control messages should never exceed a single-packet (i.e., 1,007 data bits).
コントロールメッセージの長さは単一のパケット(すなわち、1,007データ・ビット)を決して、超えるべきではありません。
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.
それらの受信機によって認識されなかったコントロールメッセージは、無視されるべきであり、接続の終了でresutingされるどんなエラー条件も引き起こすべきではありません。 これらのメッセージはシステムの間の実現レベルの違いから生じるかもしれません。
SUMMARY OF THE CONTROL MESSAGES
コントロールメッセージの概要
#1 "1,<WHO>,<WHOM>,K"
#1 「1、<WHO>、<、だれ、>、K」
#2 "2,<CODE>" or only "2"
#2 「2、<CODE>」、「2インチ」だけ
#3 "3,<WHAT>,<N>,<HOW(1),...HOW(N)>"
#3 「3、<、どんな>、<N>、<、どのように、」 (1)、…「(N) どのように>」
#4 "4,<WHAT>,<HOW>"
#4 「4、<、どんな>、<、どのように>、」
#5 "5,<WHAT>,<HOW>" or only "5,<WHAT>"
#5 「5、<WHAT>、<HOW>」、唯一、「5、<、どんな>、」
#6 "6,L" or only "6"
#6 「6、L」または「6インチ」だけ
#7 "7"
#7 "7"
#8 "8"
#8 "8"
#9 "9"
#9 "9"
#10 "10,<ID>"
#10 「10、<ID>」
#11 "11,<ID>"
#11 「11、<ID>」
#12 "12,<IM>"
#12 「12、<不->」
#13 "13,<YM>,<OK>"
#13 「13、<YM>、<OK>」
Cohen [Page 3]
コーエン[3ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
DEFINITION OF THE CONTROL MESSAGES
コントロールメッセージの定義
#1 CALLING (on 377 and L)
#1 呼びます。(377と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:
この呼び出しが最初に、リンク377の上に発行されて、後で、リンクL.Its形式が発行される、「1、<WHO>、<、だれ、どこ<WHOの>、K」、>、および<、だれに、>はそれぞれ職業パーティーと召集されているパーティーを特定する単語であり、Kが定義されるとしてありますか? <WHO>と<WHOM>の形式は以下の通りです。
(HHIIIIIIXXXXXXXX)
(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).
HHが2ビットであるところに、拡大(1コミュニケーションユニット以上が同じHOSTにあるかもしれないので、必要である)を特定する8ビットに応じて、IMPを特定する6ビットが支えたHOSTを特定するということになりました。
The system which sends this message is defined as the CALLER,
and the other system is defined as the ANSWERER.
このメッセージを送るシステムはCALLERと定義されます、そして、もう片方のシステムはANSWERERと定義されます。
#2 GOODBYE (TERMINATION, on L or K)
#2 さようなら(Lか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.
一語を送ることによって、否定的にICPを終えることができます(Kで)。「2インチ(「さようなら」)、2つの単語「2、<コード>」、または後で説明されるように明確に2つの知らせ「6、L」を送ること」。
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:
初期の接続フェーズの後に、CALLER(Lの)かANSWERER(Kの)のどちらかが呼び出しを終えることができます。 この終了には、2つの単語があります: 「2、<CODE>」:そこでは、<CODE>がここで指定されるとしての終了の理由です。
0. Other than the following.
0. 以下を除いて。
1. I am busy.
1. 私は忙しいです。
2. I am not authorized to talk with you.
2. 私があなたと話すのに権限を与えられません。
3. Request of my user.
3. 私のユーザの要求。
4. We believe you are down.
4. 私たちは、あなたが下がっていると信じています。
5. Systems incompatibility (NEGOTIATION failure).
5. システムの不一致(NEGOTIATIONの故障)。
6. We have problems.
6. 私たちには、問題があります。
7. I am in a conference now.
7. 私は現在、会議中です。
Cohen [Page 4]
コーエン[4ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
8. You made a protocol error.
8. あなたはプロトコル誤りをしました。
#3 NEGOTIATION INQUIRY (on L or K)
#3 交渉問い合せ(LかKの)
Sent by the NEGOTIATION MASTER for compatibility verification.
The format is:
NEGOTIATION MASTERで、互換性検証のために発信しました。 形式は以下の通りです。
"3,<WHAT>,<LIST-LENGTH>,<HOW-LIST>", meaning
「3、<WHAT>、<LIST-LENGTH>、<HOW-LIST>」、意味
"CAN-YOU-DO,<WHAT>,<LIST-LENGTH>,<HOW-LIST>".
「あなたがするCAN、<、どんな>、<リスト長さの>、<、どのように、->を記載してくださいか、」
The <HOW-LIST> is a list of pointers into agreed-upon tables,
as shown below.
<HOW-LIST>は以下に示されるように同意しているテーブルへのポインタのリストです。
#4 POSITIVE NEGOTIATION RESPONSE (on L or K)
#4 積極的な交渉応答(LかKの)
Sent by the NEGOTIATION SLAVE in response to a NEGOTIATION
INQUIRY. The format is:
NEGOTIATION SLAVEで、NEGOTIATION INQUIRYに対応して、発信しました。 形式は以下の通りです。
"4,<WHAT>,<HOW>", meaning: "I-CAN-DO,<WHAT>,<HOW>".
「4、<WHAT>、<HOW>」、意味: 「I意欲的である、<、どんな>、<、どのように>、」
#5 NEGATIVE NEGOTIATION RESPONSE (on L or K)
#5 否定的交渉応答(LかKの)
Sent by the NEGOTIATION SLAVE in response to a NEGOTIATION
INQUIRY. The format is either:
NEGOTIATION SLAVEで、NEGOTIATION INQUIRYに対応して、発信しました。 形式はどちらかです:
"5,<WHAT>,0", meaning "I-CAN'T-DO-<WHAT>-IN-ANY-OF-THESE-WAYS",
「5、<WHAT>、0インチが意味する、「私、-、-、<をする、いずれのどんな>-コネ、-、-、これら、-、道、」、」であることができる
or: "5,<WHAT>,N", meaning inability to accept any of the
options offered in the INQUIRY, but using "N" as a suggestion
to the ANSWERER about another possibility. Examples are
presented later in this report.
または、: 「5、<WHAT>、N」と、オプションのどれかを受け入れることができないことを意味するのは提案としてのINQUIRYの、しかし、使用している「N」で別の可能性に関してANSWERERに申し出ました。 例は後でこのレポートに提示されます。
#6 READY (on L or K)
#6 準備ができる(LかKの)
Sent by either party to indicate readiness to accept data. Its
format is "6,L" in the reply to the initial call, and "6"
thereafter.
データを受け入れる準備を示すために何れの当事者によって送られます。 そして、形式が回答で初期の呼び出しへの「6、L」である、「6インチ、その後」
#7 NOT READY (on L or K)
#7 準備ができない(LかKの)
Sent by either party to indicate unreadiness to accept data. It
is always a single word: "7".
データを受け入れるために非準備を示すために何れの当事者によって送られます。 いつもそれは一語です: "7".
#8 INQUIRY (on L or K)
#8 問い合せ(LかKの)
Sent by either party to inquire about the status of the other.
It is always a single word: "8". It is answered by #6, #7, or
#9.
もう片方の状態について問い合わせをするために何れの当事者によって送られます。 いつもそれは一語です: "8". それは#6、#7、または#9によって答えられます。
Cohen [Page 5]
コーエン[5ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
#9 RINGING (on K)
#9 鳴ります。(Kの)
Sent by the ANSWERER after the negotiations have been
successfully terminated and human permission is needed to
proceed further. The ringing will continue for 10 seconds, and
then stop, UNLESS a #8 is received. This message is always a
single word: "9".
ANSWERERで、交渉が首尾よく終えられて、人間の許可がさらに続くのに必要であった後に発信しました。 鳴るのは10秒、および次に、停止、UNLESSのために受け取られた#8、を続けるでしょう。 いつもこのメッセージは一語です: "9".
#10 ECHO REQUEST (on L or K)
#10 エコー要求(LかKの)
Sent by whichever party is interested in measuring the network
delays. Its only purpose is to be echoed immediately. The
format is "10,<ID>", where <ID> is any word used to identify
the ECHO.
ネットワーク遅延を測定したがっているどのパーティーで、発信したか。 唯一の目的はすぐに反響されることです。 形式は<ID>がエコーを特定するのに使用されるあらゆる単語である「10、<ID>」です。
#11 ECHO (on L or K)
#11 エコー(LかKの)
Sent in response to ECHO REQUEST. The format is "11,<ID>",
where <ID> is the word specified by #10. The implementation of
this feature is not compulsory, and no connection should be
terminated due to lack of response to ECHO-REQUEST.
ECHO REQUEST形式に対応して送るのは、「11、<ID>」(<ID>は#10によって指定された単語である)です。 この特徴の実現は強制的ではありません、そして、ECHO-REQUESTへの無反応のため接続を全く終えるべきではありません。
#12 RENEGOTIATION REQUEST (on L or K)
#12 RENEGOTIATION要求(LかKの)
Can be sent by either party at ANY stage after LINKS are agreed
upon. This message consists of the two words "12,<IM>". If the
word <IM> (for I MASTER) is non-zero, the sender of this
message requests to be the NEGOTIATION MASTER. If it is zero,
the receiver of this message is requested to be the NEGOTIATION
MASTER. Renegotiation is described later.
どちらかで送って、リンクスの後のどんな段階のパーティーも同意されるということであることができます。 このメッセージは2つの単語「12、<不->」から成ります。 <という単語であるなら、IM>(I MASTERのための)は非ゼロであり、このメッセージの送付者はNEGOTIATION MASTERであるという要求です。 それがゼロであるなら、このメッセージの受信機はNEGOTIATION MASTERであるよう要求されます。 Renegotiationは後で説明されます。
#13 RENEGOTIATION APPROVAL (on L or K)
#13 RENEGOTIATION承認(LかKの)
This message may be sent by either party in response to
RENEGOTIATION REQUEST. It consists of the three words
"13,<YM>,<OK>". If <OK> is non-zero, this is a positive
acknowledgment (approval). If it is zero, this is a negative
acknowledgment (i.e., refusal). <YM> is set to be equal to the
<IM> of #12, for identification purposes.
このメッセージはRENEGOTIATION REQUESTに対応して何れの当事者によって送られるかもしれません。それは3つの単語「13、<YM>、<OK>」から成ります。 <OK>が非ゼロであるなら、これは肯定応答(承認)です。 それがゼロであるなら、これは否定応答(すなわち、拒否)です。 <YM>は識別目的のための#12の<IM>と等しいように用意ができています。
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 a
single word or two words long. #10, #11 and #12 are always 2 words
long. Message #13 is always 3 words long. Message #1 is always 4
words long.
いつもメッセージ#7、#8、および#9は一語です。 長い間、メッセージ#1、#3、#4、および#5、はいくつかの単語です。 長い間、メッセージ#2、と#6は、一語か2つの単語のどちらかです。 #10 #長い間、いつも11と#12、は2つの単語です。 長い間、いつもメッセージ#13は3つの単語です。 長い間、いつもメッセージ#1は4つの単語です。
Message #1 is sent only by the CALLER, #3 only by the NEGOTIATION
MASTER, and #4 and #5 only by the NEGOTIATION SLAVE. Message #9 is
NEGOTIATION SLAVEだけによる1が単にCALLERによって送られるメッセージ#、NEGOTIATION MASTERだけによる#3、#4、および#5。 メッセージ#9はそうです。
Cohen [Page 6]
コーエン[6ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
sent only by the ANSWERER. All the other control messages may be
sent by either party.
ANSWERERだけで、発信しました。 他のすべてのコントロールメッセージが何れの当事者によって送られるかもしれません。
The last <HOW> which 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.
NEGOTIATION MASTER(#3の)によって勧められて、受け入れた最後の<HOW>が使用中であるとそれぞれの<WHAT>のためのNEGOTIATION SLAVE(#4の)によって思われます。
Cohen [Page 7]
コーエン[7ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
DEFINITION OF THE <WHAT> AND <HOW> NEGOTIATION TABLES:
<の定義は、>交渉が以下をテーブルの上に置くどんな>と<であるか。
<WHAT> <HOW>
<、どんな><、どのように>。
1. VOCODING * 1. LPC
+ 2. CVSD
3. RELP
4. DELCO
1. VOCODING*1。 LPC+2。 CVSD3。 RELP4。 DELCO
2. SAMPLE PERIOD
2. サンプルの期間
(in microseconds) N. N (*150) (+62)
(マイクロセカンドの) N.N(*150)(+62)
3. VERSION
3. バージョン
* 1. V1 (see definition below)
+ 2. V2 (see definition below)
* 1. V1(以下での定義を見る)+2。 V2(以下での定義を見ます)
4. MAX MSG LENGTH (in bits)
4. マックスエムエスジーの長さ(ビットの)
NVP header included N. N (*976 and +976)
(32 bits) but not HOST/IMP
leader and not HOST/IMP padding
NVPヘッダーはHOST/IMP詰め物ではなく、HOST/IMPリーダーではなく、N.N(*976と+976)(32ビット)を入れました。
5. If LPC:
5. LPCであるなら:
Degree N. For N coefficients (*10)
度N.For N係数(*10)
If CVSD:
CVSDであるなら:
Time Constant
(in milliseconds) N. N (+50)
時間Constant(ミリセカンドによる)N.N(+50)
6. Samples per Parcel N. N (*128) (+224)
6. 小包N.N(*128)あたりのサンプル(+224)
7. If LPC:
7. LPCであるなら:
Acoustic Coding * 1. SIMPLE (see below)
2. OPTIMIZED
音のコード化*1。 SIMPLE(以下を見る)2。 最適化されます。
8. If LPC:
8. LPCであるなら:
Info Coding * 1. SIMPLE (see below)
2. OPTIMIZED
インフォメーションコード化*1。 SIMPLE(以下を見る)2。 最適化されます。
Cohen [Page 8]
コーエン[8ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
9. If LPC:
9. LPCであるなら:
Pre-emphasis N. N (*58, for
1 - mu x [Z**-1] mu = 58/64 = 0.90625)
N = 64 x mu
プレ強調N.N(1のための*58--μx[Z**-1]μ=58/64 = 0.90625)Nは64xμと等しいです。
10. If LPC:
10. LPCであるなら:
Table-set N. N (*1)
See definition of Set #1
in Appendix 1
テーブルで設定されたN.N(*1)はAppendix1とのSet#1の定義を見ます。
(* indicates recommended options for LPC)
(+ indicates recommended options for CVSD)
(*はLPCのためにお勧めのオプションを示します)(+はCVSDのためにお勧めのオプションを示します)
No parameter (<WHAT>) should be inquired about by the NEGOTIATION
MASTER if some option (<HOW>) for it has been previously accepted
by the NEGOTIATION SLAVE implicitly in the "VERSION". The purpose
of this restriction is to avoid a possible conflict between
individual parameters and the VERSION-option.
NEGOTIATION SLAVEが以前に「バージョン」でそれとなく、それのための何らかのオプション(<HOW>)を受け入れたなら、NEGOTIATION MASTERはパラメタ(<WHAT>)について全く問い合わせをするはずがありません。 この制限の目的は個々のパラメタとバージョンオプションとの可能な闘争を避けることです。
Version 1 (V1) is defined as:
バージョン1(V1)は以下と定義されます。
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 #1
1-1 2-150 150マイクロセカンドの3-1 V1 5-10 10係数6-128 128を抽出するLPCが1小包7-1SIMPLEの音のコード化8-1SIMPLE情報コード化9-58μ=単位で58/64 = 0.90625 10-1 Tablesセット#1を抽出します。
Version 2 (V2) is defined as:
バージョン2(V2)は以下と定義されます。
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 parcel
1-2 2-62 62マイクロセカンドの3-2 1小包あたりのV2 5-50 50msecの時定数6-192 192サンプルを抽出する(16KHz標本抽出)CVSD
Note that this defines every negotiated parameter, except MAX
MSG LENGTH.
これがMAX MSG LENGTH以外のあらゆる交渉されたパラメタを定義することに注意してください。
SIMPLE and OPTIMIZED codings will be described below in Section
3.
SIMPLEとOPTIMIZEDコーディングはセクション3で以下で説明されるでしょう。
All the negotiation is managed by the NEGOTIATION MASTER, who
decides how much negotiation is needed, and what to do in case
すべての交渉がNEGOTIATION MASTERによって管理されます。(NEGOTIATION MASTERはどのくらいの交渉が必要であるか、そして、場合で何をしたらよいかを決めます)。
Cohen [Page 9]
コーエン[9ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
some discrepancy (incompatibility) is discovered: either to try
alternative options or to abort the connection. Upon completion
of successful negotiation, the NEGOTIATION MASTER sends either
#9 (RINGING) only if it is the ANSWERER and if this is an
initial connection, else it sends #6 (READY-FOR-DATA), and
probably inquires with #8 about the readiness of the other
party. The inquiries (#8) before the successful completion of
the negotiation are ignored. However, these inquiries after the
first RINGING (#9) and before the first READY (#6) are needed
to keep the ANSWERER ringing.
何らかの食い違い(不一致)が発見されます: 代替のオプションを試みるか、または接続を中止するどちらか。 うまくいっている交渉の完成のときに、NEGOTIATION MASTERがそれがANSWERERである場合にだけ#9(RINGING)を送って、これが初期の接続であるなら、それは、ほかに、6(READY-FOR-DATA)を#、に送って、たぶん#8で準備に関して相手に問い合わせます。 交渉の無事終了の前の問い合せ(#8)は無視されます。 しかしながら、最初のRINGING(#9)の後と最初のREADY(#6)の前のこれらの問い合せが、ANSWERERを鳴らせ続けるのに必要です。
Note that the negotiation process can be shortened by using the
VERSION option, as shown in the examples that follow.
従う例に示されるようにバージョンオプションを使用することによって交渉の過程を短くすることができることに注意してください。
ON RENEGOTIATION
RENEGOTIATIONに関して
At any stage after links are agreed upon, either party might
request a RENEGOTIATION. If the request is approved by the other
party, either party might become the NEGOTIATION MASTER, depending
on the type of renegotiation request. When renegotiation starts,
no previously negotiated agreements (except LINK numbers) hold,
and all items have to be renegotiated from scratch. Note that
renegotiation may entirely replace the negotiation phase and
allows the CALLER to be the NEGOTIATION MASTER.
どんな段階でも、リンクが同意された後に何れの当事者はRENEGOTIATIONを要求するかもしれません。 要求が相手によって承認されるなら、何れの当事者はNEGOTIATION MASTERになるかもしれません、再交渉要求のタイプに頼っていて。 再交渉が始動するとき、以前に交渉された協定(LINK番号を除いた)は全く成立しません、そして、すべての項目が最初から、再交渉されなければなりません。 再交渉が、交渉フェーズを完全に取り替えるかもしれなくて、CALLERがNEGOTIATION MASTERであることを許容することに注意してください。
Upon issuance (or reception) of RENEGOTIATION REQUEST, all data
messages are ignored until the positive indication of the
successful completion of the renegotiation (#6).
RENEGOTIATION REQUESTの発行(または、レセプション)では、すべてのデータメッセージが再交渉(#6)の無事終了の積極的なしるしまで無視されます。
After the completion of renegotiation, the frame-count (see the
section on MESSAGE-HEADER) may be reset to zero.
再交渉の完成の後に、フレームカウント(MESSAGE-HEADERの上のセクションを見る)はゼロにリセットされるかもしれません。
THE HEADER OF DATA MESSAGES
データメッセージのヘッダー
Data messages are the messages which contain vocoded speech. The
first 32 bits of each data message is the MESSAGE-HEADER, which
carries sequence and timing information as described below.
データメッセージはvocodedスピーチを含むメッセージです。 それぞれのデータメッセージの最初の32ビットはMESSAGE-HEADERです。(そのMESSAGE-HEADERは以下で説明されるように系列とタイミング情報を運びます)。
For each vocoding scheme a "FRAME" is defined as the transmission
interval (as agreed upon at the negotiation stage in <WHAT#6>).
Since this interval is defined by the number of samples, its
duration can be 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 yields:
それぞれのvocoding計画において、「フレーム」はトランスミッション間隔と定義されます(<の交渉段階のどんな#6>で同意されるように)。 この間隔がサンプルの数によって定義されるので、持続時間は以上、間隔の長さ(サンプルの)の<WHAT#6>による<WHAT#2>という標本抽出を掛けることによって見つけられて、ことであるかもしれません。 例えば、サンプリング周期はV1では150マイクロセカンドです、そして、トランスミッション間隔は128個のサンプルです(もたらされます):
128*150 microseconds = 19.2 milliseconds.
19.2 128*150マイクロセカンド=ミリセカンド。
The data describing a FRAME is called a PARCEL. Each parcel has a
FRAMEについて説明するデータはPARCELと呼ばれます。 各小包には、aがあります。
Cohen [Page 10]
コーエン[10ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
serial number. The first parcel created after the completion of
the negotiation (or every RENEGOTIATION) has the serial number
zero. Each message contains an integral number of parcels.
通し番号。 交渉(または、あらゆるRENEGOTIATION)の完成の後に作成された最初の小包は通し番号ゼロを持っています。 各メッセージは整数の小包を含んでいます。
The serial number of the first parcel in the message is put in the
first 16 bits of the message and is referred to as the
MESSAGE-TIME-STAMP. Note that this time stamp is synchronized with
the data stream. Note also that these 16 bits are actually the
third word of the message, following the 2 words used as
IMP-to-HOST leader (see BBN Report 1822).
メッセージにおける最初の小包の通し番号は、メッセージの最初の16ビットに入れられて、MESSAGEタイム誌STAMPと呼ばれます。 このタイムスタンプがデータ・ストリームに連動することに注意してください。 また、これらの16ビットが実際にメッセージの3番目の単語であることに注意してください、IMPからHOSTへのリーダーとして使用される2つの単語に従って(BBN Report1822を見てください)。
The next bit in the header is the WE-SKIPPED-PARCELS bit, which is
described later. The next 7 bits tell how many parcels there are
in the message; this number is called the COUNT, or the
PARCEL-COUNT.
ヘッダーの次のビットはWE-SKIPPED-PARCELSビットです。(そのビットは後で説明されます)。 次の7ビットは、いくつの小包がメッセージにあるかを言います。 この数はCOUNT、またはPARCEL-COUNTと呼ばれます。
Note that 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 decided not
to send some parcels due to silence. If this happens then the
WE-SKIPPED-PARCELS bit is set to ONE, else it is set to ZERO.
Hence, if T(N+1) is found by the RCVR to be greater than T(N)+C(N)
and the WE-SKIPPED-PARCELS is zero, some message must be lost.
メッセージ番号NにタイムスタンプT(N)とカウントC(N)があるならT(N+1)がそう以上であるに違いないことに注意してください。T(N)+C(N)。 通常、T(N+1)はT(N)+C(N)と等しく、XMTRが決めなかったなら、いくつかを送らないのは黙らせる支払われるべきものを包みにします。 これが起こるなら、WE-SKIPPED-PARCELSビットはONEに設定されて、ほかに、それはZEROに設定されます。 したがって、T(N+1)がT(N)+C(N)よりすばらしいのがRCVRによってわかられていて、WE-SKIPPED-PARCELSがゼロであるなら、何らかのメッセージを失わなければなりません。
Note that by definition the time stamps on messages monotonically
increase, except for wrap-around.
定義上、巻きつけて着るドレスを除いて、メッセージのタイムスタンプが単調に増加することに注意してください。
The message header structure is illustrated by the following
diagram:
メッセージヘッダー構造は以下のダイヤグラムで例証されます:
WORD 1 WORD 2 WORD 3 WORD 4
!................!................!................!................!...
!P000TTTTHHIIIIII!LLLLLLLLZZZZZZZZ!TTTTTTTTTTTTTTTT!WCCCCCCCSSSSSSSS!DDD
!................!................!................!^...............!...
!<--HOST/IMP-OR-IMP/HOST-LEADER-->!<--TIME-STAMP-->!^<COUNT><-SAVE->!<-D
^
WE-SKIPPED-PARCELS
Word1Word2は3言葉4を言い表します!!................!................!................!... P000TTTTHHIIIIII!LLLLLLLLZZZZZZZZ!TTTTTTTTTTTTTTTT!WCCCCCCCSSSSSSSS!DDD!!................!................!^...............!... 私たちが小包をスキップしていた状態で、<--悪童かホスト/悪童/リーダーホスト兼-->!<--タイムスタンプ-->!^<は>!<-Dを救っている><^を数えます。
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)
P=PRIORITY(1ビット=1)T=MESSAGE TYPE(4ビット=0011)L=リンク(337 8進より8ビットすばらしい「L」か「K」)D=データ・ビット(ここからメッセージの終わりまでの)
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)
HHIIIIII=HOST(8ビット、目的地またはソース)CCCCCCC=が8COUNT(7ビット)SSSSSSSS=ビット包みにする将来のアプリケーションTTTTTTTTTTTTTTTTのために節約された8ZERO ZZZZZZZZ=ビットはTIME STAMPと等しいです。(16ビット)
Cohen [Page 11]
コーエン[11ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
The first parcel sent by either party after the NEGOTIATION or
RENEGOTIATION should have the serial number set to zero.
NEGOTIATIONかRENEGOTIATIONに通し番号があったはずである後に何れの当事者によって送られた最初の小包はゼロにセットしました。
During silence periods, the XMTR might send a "6" or "7"
message periodically. If it does not do so, the RCVR might
interrogate the livelihood of the XMTR by sending periodically
"8" ("ARE-YOU-THERE?") or #10 (ECHO-REQUEST) messages.
沈黙の期間、XMTRがaを送るかもしれない、「6インチか「7インチは定期的に通信します」。 そうしないなら、RCVRは、定期的に「8インチ(「あなたはそこにいますか?」)か#の10(エコー要求)のメッセージ」を送ることによって、XMTRの暮らしを査問するかもしれません。
Cohen [Page 12]
コーエン[12ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
3. THE LPC DATA PROTOCOL
3. LPCデータプロトコル
The DATA sent at each transmission interval is called a PARCEL.
それぞれのトランスミッション間隔を置いて送られたDATAはPARCELと呼ばれます。
Network messages always contain an integral number of PARCELs.
ネットワークメッセージはいつもPARCELsの整数を含んでいます。
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.
コード化には独立している2冊があります。 1つは明らかに音のコード化です。(すなわち、そのパラメタはそのコード化のために伝えられなければなりません)。 SIMPLEの音のコード化はあらゆるトランスミッション間隔におけるすべてのパラメタを送ることです。 OPTIMIZEDの音のコード化は音響学上必要とされるのと同じくらい少なくだけ発信します。 DELCOはOPTIMIZEDの音のコード化に関する例です。
In this document only the format of the SIMPLE acoustic coding is defined.
本書ではSIMPLEの音のコード化の書式だけが定義されます。
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.
ポインタとしてすべての伝えられたパラメタを同意しているテーブルに送ります。 これらのテーブルは値の2つのリストと定義されます。 送信機テーブルX(J)は以下の方法で使用されます: X(J-1)<Vが<X(J)と等しいなら、値VはコードJとしてコード化されます。 コードJを受け取ったなら、値のR(J)を検索するのにR(J)を使用します。受信機テーブル、それとなくマイナス無限とX(-1)を定義して、明らかに、X(Jmax)をプラス無限と定義します。
For each parameter, {X(J)} and {R(J)} may be defined independently.
各パラメタに関しては、X(J)とR(J)は独自に定義されるかもしれません。
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.
2番目のコード化問題は情報コーディング技法です。 情報を送るSIMPLEの(情報的)の方法はパラメタを表すコードのための2進のコード化を使用することです。 OPTIMIZED道は、各パラメタのための配を計算して、適切なコード化を定義することです。 PITCHとGAINがその後それぞれのメッセージの最初のPARCELに、増加して絶対に解読されるのは、非常にありえそうです。
At present, only the SIMPLE (information-wise) coding is used.
現在のところ、SIMPLEの(情報的)のコード化だけが使用されています。
The details of the LPC data protocol and its Tables-Set-#1 can be found in Appendix 1.
Appendix1でLPCデータプロトコルとそのTables-セット#1の詳細を見つけることができます。
Cohen [Page 13]
コーエン[13ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
Following is the definition for the format of the SIMPLE-SIMPLE coding, according to Tables-Set-#1:
以下に、Tables-セット#1、に従って、SIMPLE-SIMPLEコード化の形式のための定義があります:
For each parcel:
それぞれに関しては、以下を包みにしてください。
PITCH 6 bits (PITCH=0 for UNVOICED)
PITCH6ビット(=0を売り込む、暗黙、)
GAIN 5 bits
GAIN5ビット
I(1) 7 bits
I(1)7ビット
I(2) 7 bits
I(2)7ビット
I(3) 6 bits
I(3)6ビット
I(4) 6 bits
I(4)6ビット
I(5) 5 bits
I(5)5ビット
I(6) 5 bits
I(6)5ビット
I(7) 5 bits
I(7)5ビット
I(8) 5 bits
I(8)5ビット
I(9) 5 bits
I(9)5ビット
I(10) 5 bits
I(10)5ビット
where each 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.
それぞれのI(j)が逆さの正弦コード化のためのインデックスであるところ。 (j)はKであるならarcsinと等しいです。(θ(j))とNビットはトランスミッションのために割り当てられて、次に、I(j)は*2**Nと等しいです(θ(j)/パイ)。
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.
したがって、67ビットが送られるそれぞれのトランスミッション間隔(150マイクロセカンドの128サンプル時間)を置いて、どれが3490年のビーピーエスのデータ信号速度をもたらしますか? ネットワークの能力のかなり中にこの帯域幅があるので、SIMPLE-SIMPLEコード化は使用されています(ホストによる最少の計算を必要とします)。 沈黙の使用なしでこのデータ信号速度がピークレートであることに注意してください。
Cohen [Page 14]
コーエン[14ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
4. EXAMPLES FOR THE CONTROL PROTOCOL
4. 制御プロトコルのための例
Here is an example for a connection:
ここに、接続への例があります:
(377) C: 1,<WHO>,<WHOM>,340 Please talk to me on 340/341.
(377)C: 1 <WHO>、<WHOM>、340Pleaseは340/341に関して私に話します。
(340) A: 2,1 I refuse, since I'm busy.
(340) A: 2 1 私は、忙しいので、拒否します。
Another example:
別の例:
(377) C: 1,<WHO>,<WHOM>,360 Please talk to me on 360/361.
(377)C: 1 <WHO>、<WHOM>、360Pleaseは360/361に関して私に話します。
(360) A: 6,350 OK. You talk to me on 350/351.
(360) A: 6,350 OK。 あなたは350/351に関して私に話します。
(350) C: 1,<WHO>,<WHOM> I want to talk to you.
(350)C: 1 <WHO>、あなたと話したいと思う<WHOM>。
(360) A: 3,1,1,2 Can you do CVSD? (ANSWERER tries
to be the NEGOTIATION MASTER)
(360) A: あなたがCVSDをする3、1、1、2Can? (NEGOTIATION MASTERであるANSWERERトライ)
(350) C: 12,1 I want to be it.
(350)C: 12 1 それになりたいと思います。
(360) A: 13,1 That's OK with me.
(360) A: 13 1 Thatは私と共にOKです。
(350) C: 3,1,1,2 Can you do CVSD?
(350)C: あなたがCVSDをする3、1、1、2Can?
(360) A: 5,1,1 No, but I can do LPC.
(360) A: 5 1 1 いいえ、私はLPCができます。
(350) C: 3,1,1,3 Can you do RELP?
(350)C: あなたがRELPをする3、1、1、3Can?
(360) A: 5,1,1 No, but I can do LPC.
(360) A: 5 1 1 いいえ、私はLPCができます。
(350) C: 3,1,1,1 How about LPC?
(350)C: 3 1 1 1 LPCはどうですか?
(360) A: 4,1,1 LPC is fine with me.
(360) A: 4 1 1 LPCは大丈夫です。
(350) C: 3,2,1,150 Can you use 150 microseconds
sampling?
(350)C: 3、2、1,150Can、あなたは、抽出しながら、150マイクロセカンドを使用しますか?
(360) A: 4,2,150 I can use 150 microseconds.
(360) A: 4 2,150 私は150マイクロセカンドを使用できます。
(350) C: 3,4,3,976,1040,2016 Can you use 976, 1040, or 2016
bits/msg?
(350)C: あなたが976ビットか1040ビットか2016ビット使用するか、またはmsgする3、4、3,976、1040、2016Can?
(360) A: 4,4,976 I can use 976.
(360) A: 4 4,976 私は976を使用できます。
(350) C: 3,5,1,10 Can you send 10 coefficients?
(350)C: あなたが10の係数を送る3、5、1、10Can?
(360) A: 4,5,10 I can send 10.
(360) A: 4 5 10 私は10を送ることができます。
Cohen [Page 15]
コーエン[15ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
(350) C: 3,6,1,64 Can you use a 64 sample
transmission?
(350)C: 3、6、1、64Can、あなたはa64サンプル送信を使用しますか?
(360) A: 4,6,64 I can use 64.
(360) A: 4 6 64 私は64を使用できます。
(350) C: 3,7,2,1,2 SIMPLE or OPTIMIZED acoustic
coding?
(350)C: 3、7、2、1、2SIMPLEかそれともOPTIMIZEDの音のコード化?
(360) A: 4,7,2 OPTIMIZED!
(360) A: 4、7、2は最適化されました!
(350) C: 3,8,1,1 Can you do SIMPLE info coding?
(350)C: 3 8 1 1 あなたがSIMPLEインフォメーションコード化をするCan?
(360) A: 4,8,1 I can do SIMPLE.
(360) A: 4 8 1 私はSIMPLEができます。
(350) C: 3,9,1,58 mu = 0.90625?
(350)C: 3、9、1、58μ=0.90625?
(360) A: 4,9,58 Fine with me.
(360) A: 4 9 58 私と共におかげさまで元気です。
(350) C: 3,10,1 Table set #1?
(350)C: 3 10 1 Tableセット#1?
(360) A: 4,10,1 Of course!
(360) A: 4 10 1 Ofは勢いよく流れます!
(350) C: 6 I am ready. (Note: No "RINGING"
sent)
(350)C: 6 私は準備ができています。 (注意: 送られた「鳴らないこと」)
(350) C: 8 And you?
(350)C: 8とあなた?
(360) A: 6 I am ready, too.
(360) A: 6 また、私は準備ができています。
....... Data is exchanged now,
....... 現在データを交換します。
....... on 351 and 361.
…… 351と361に関して。
(350) C: 10,1234 Echo it, please.
(350)C: 10、1234Echo、それをお願いします。
(360) A: 11,1234 Here it comes!
(360) A: 11、1234Here、それは来ます!
.......
.......
(360) A: 10,3333 Now ANSWERER wants to measure
(360) A: 10 現在のANSWERERが測定したがっている3333
(350) C: 11,3333 ...the delays, too.
(350)C: 11,3333 ...また、遅れ。
.......
.......
(???) X: 2,3 Termination by either user.
(???) X: 2 3 どちらかのユーザによるTermination。
Cohen [Page 16]
コーエン[16ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
Another example:
別の例:
(377) C: 1,<WHO>,<WHOM>,360 Please talk to me on 360/361.
(377)C: 1 <WHO>、<WHOM>、360Pleaseは360/361に関して私に話します。
(360) A: 6,340 Fine. You send on 340/341.
(360) A: 6,340 おかげさまで元気です。 あなたは340/341を転送します。
(340) C: 1,<WHO>,<WHOM> I want to talk to you.
(340)C: 1 <WHO>、あなたと話したいと思う<WHOM>。
(360) A: 3,3,1,1 Can you use V1?
(360) A: 3、3、1、1Can、あなたはV1?使用します。
(340) C: 4,3,1 Yes, V1 is OK.
(340)C: 4 3 1 はい、V1はOKです。
(360) A: 3,4,1,1984 Can you use up to 1984 bits/msg?
(360) A: あなたが1984ビット/msgまで使いきる3、4、1、1984Can?
(340) C: 5,4,976 No, but I can use 976.
(340)C: 5 4,976 いいえ、私は976を使用できます。
(360) A: 3,4,1,976 Can you use up to 976 bits/msg?
(360) A: あなたが976ビット/msgまで使いきる3、4、1,976Can?
(340) C: 4,4,976 I can use 976.
(340)C: 4 4,976 私は976を使用できます。
(360) A: 9 Ringing (note how short this
negotiation is!!).
(360) A: 9 鳴ること(この交渉がどれくらい短いかに注意してください!)。
.......
.......
(340) C: 8 Still there?
(340)C: 8 まだそこでは?
(360) A: 9 Still ringing.
(360) A: 9 まだ鳴っています。
.......
.......
(340) C: 8 Still there?
(340)C: 8 まだそこでは?
(360) A: 9 Still ringing.
(360) A: 9 まだ鳴っています。
.......
.......
(340) C: 8 How about it?
(340)C: 8 それはどうですか?
(360) A: 9 Still ringing.
(360) A: 9 まだ鳴っています。
(340) C: 2 Forget it! (No reason given.)
(340)C: 2はそれを忘れます! (あげられなかった理由。全く)
Cohen [Page 17]
コーエン[17ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
APPENDIX 1
付録1
THE DEFINITION OF:
以下の定義
TABLES-SET-#1
テーブルで設定された#1
by
by
John D. Markel
ジョン・D.マーケル
Speech Communication Research Laboratory
スピーチ・コミュニケーション研究所
Santa Barbara, California
サンタバーバラ(カリフォルニア)
Cohen [Page 18]
コーエン[18ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
TABLES-SET-#1
テーブルで設定された#1
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 table
PITCH--64の値、PITCHはGAINをテーブルの上に置きます--32の値、GAINはI( 1)をテーブルの上に置きます--128の値、INDEX7はI( 2)をテーブルの上に置きます--128の値、INDEX7はI( 3)をテーブルの上に置きます--64の値、INDEX6はI( 4)をテーブルの上に置きます--64の値、INDEX6はI( 5)をテーブルの上に置きます--32の値、INDEX5はI( 6)をテーブルの上に置きます--32の値、INDEX5はI( 7)をテーブルの上に置きます--32の値、INDEX5はI( 8)をテーブルの上に置きます--32の値、INDEX5はI( 9)--32の値、INDEX5テーブルI(10)--32の値を見送ります、INDEX5テーブル
These tables are defined specifically for a sampling period of 150 microseconds.
これらのテーブルは特に150マイクロセカンドのサンプリング周期の間、定義されます。
Cohen [Page 19]
コーエン[19ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
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 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.
以下のテーブルは3つのコラム、X(j)、j、およびR(j)に配置されます。 それに注意してください、エントリー、X(j)では、コラムは他のコラムでステップで半分です。 これは、X-ドメイン(ピッチ、利得、およびKs)からのINTERVALSがCODES jに写像されるのを示すためのものです(受信機によってR(j)に翻訳されるためにネットワークの上に伝えられます)。 これらの間隔はオープン-CLOSE間隔と定義されます。 例えば、4131年のPITCH値(送信機の)が「(4024、4131]」という間隔に属して、したがって、それが受信機によって同様に値21に写像されるj=6としてコード化されて、INDEX7のための2400年の値は、「(2009、2811]」という間隔に属するのがわかっていて、コード3にコード化されて、2411に写像して戻されます。
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.
Nビットが、あるCODEによって使用されるならX-テーブルの2**N+1エントリー、しかし、2**NエントリーしかR-テーブルにないことに注意してください。
The transformation values used for PITCH, GAIN, and the
K-parameters (in the X- and R-tables) are as defined in NSC Note
42.
PITCH、GAIN、およびKパラメタ(XとR-テーブルの)に使用される変化値がNSC Note42で定義されるようにあります。
Values above and below the range of the X-table are mapped into
the maximum and minimum table indices, respectively.
範囲とX-テーブルの範囲の下の値はそれぞれ最大の、そして、最小のテーブルインデックスリストに写像されます。
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.
INDEX5のR(J)がINDEX6のR(2J)と同じであり、INDEX6のR(J)がINDEX7のR(2J)と同じであることに注意してください。 したがって、INDEX5とINDEX6のR-テーブルなしでINDEX7のR-テーブルだけを収納するのは可能です。
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.
SPS-41実現には、KパラメタのためにどんなR-テーブルも収納する必要は全くありません。 直接(適切なスケーリングで)インデックスとしてSPSの内蔵のTRIGテーブルに伝えられたインデックスを使用できます。
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).
平らなJ=0はUNVOICED状態を定義します。 受信機が1フレームあたりのサンプルの数にそれを写像する、(ここ、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.
このPITCHテーブルは、前のテーブルから有意差があって、NSC Note36で発行されたテーブルに取って代わります。 NSC Note42でテーブルの計算の詳細を見つけることができます。 当面の問題はジョン・マーケルを参照されるべきです。
Cohen [Page 20]
コーエン[20ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
COMMENTS ON THE GAIN TABLE
利得テーブルにおけるコメント
The level J=0 defines absolute silence.
平らなJ=0は完全な沈黙を定義します。
This table is designed for a maximum of 12-bit A/D input, and
allows for a dynamic range of 43.5 dB.
このテーブルは、最大12ビットのA/D入力のために設計されていて、43.5dBのダイナミックレンジを考慮します。
NSC Notes 36, 45, 56 and 58 supply background for the GAIN table.
Gain is the energy of the pre-emphasized, windowed signal.
NSC Notes36、45、56、および58はGAINテーブルにバックグラウンドを供給します。 利得はあらかじめ強調されて、窓を付けられた信号のエネルギーです。
This table is the NEW GAIN table. NSC Notes 56 and 58 explain the
reasoning behind the NEW GAIN.
このテーブルはNEW GAINテーブルです。 NSC Notes56と58はNEW GAINの後ろで推理について説明します。
COMMENTS ON THE INDEX7 TABLE
INDEX7テーブルにおけるコメント
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].
正の数は範囲[0-63、小数]にコード化されます。 負の数はそれらの絶対値[65-127、小数]のコードの7ビットの2の補数にコード化されます。
Note that all values -403 < V < 403 are coded as (and mapped into)
0. Note also that the code -64 (100 octal) is never used.
そして、すべてがV<403がコード化される-403<を評価することに注意してください、(写像される、)、0 また、コード-64(100 8進)が決して使用されないことに注意してください。
In SPS-41 implementation, the R-table is not needed, since
TRIG(2J) is the needed value R(J).
SPS-41実現では、R-テーブルは、TRIG(2J)が必要な値のR(J)であるので、必要ではありません。
COMMENTS ON THE INDEX6 TABLE
INDEX6テーブルにおけるコメント
Positive values are coded into the range [0-31, decimal]. Negative
values are coded into the 6-bits two's complement of the codes of
their absolute values [33-63, decimal].
正の数は範囲[0-31、小数]にコード化されます。 負の数はそれらの絶対値[33-63、小数]のコードの6ビットの2の補数にコード化されます。
Note that all values -805 < V < 805 are coded as (and mapped into)
0. Note also that the code -32 (40 octal) is never used.
そして、すべてがV<805がコード化される-805<を評価することに注意してください、(写像される、)、0 また、コード-32(40 8進)が決して使用されないことに注意してください。
In SPS-41 implementation, the R-table is not needed, since
TRIG(4J) is the needed value R(J).
SPS-41実現では、R-テーブルは、TRIG(4J)が必要な値のR(J)であるので、必要ではありません。
COMMENTS ON THE INDEX5 TABLE
INDEX5テーブルにおけるコメント
Positive numbers are coded into the range [0-15, decimal].
Negative numbers are coded into the 5-bits two's complement of
their absolute values, i.e., [17-31, decimal].
正の数は範囲[0-15、小数]にコード化されます。 すなわち、負数はそれらの絶対値の5ビットの2の補数にコード化されます[17-31、小数]。
Note that all values -1609 < V < 1609 are coded as (and mapped
into) 0. Note also that the code -16 (20 octal) is never used.
そして、すべてが1609がコード化される-1609<V<を評価することに注意してください、(写像される、)、0 また、コード-16(20 8進)が決して使用されないことに注意してください。
In SPS-41 implementation, the R-table is not needed, since
TRIG(8J) is the needed value R(J).
SPS-41実現では、R-テーブルは、TRIG(8J)が必要な値のR(J)であるので、必要ではありません。
Cohen [Page 21]
コーエン[21ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
THE PITCH TABLE (as of 10-29-74)
ピッチテーブル(10-29-74現在)
X(J) J R(J) X(J) J R(J) X(J) J R(J)
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
infinity
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無限
Cohen [Page 22]
コーエン[22ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
Note: This table has only 58 different intervals defined, since 5
values are repeated in the R(j) table.
以下に注意してください。 このテーブルで、5つの値がR(j)テーブルで繰り返されるので、58回の異なった間隔だけを定義します。
* This value is the "Transmission Interval" (measured in samples)
as defined in item #6 of the NEGOTIATION.
* この値は6項目#NEGOTIATIONで定義されるように「トランスミッション間隔」(サンプルでは、測定される)です。
Cohen [Page 23]
コーエン[23ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
THE GAIN TABLE (as of 9-17-75)
利得テーブル(9-17-75現在)
X(J) J R(J) X(J) J R(J)
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 infinity
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 infinity
Cohen [Page 24]
コーエン[24ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
INDEX7 TABLE (as of 9-23-74)
INDEX7テーブル(9-23-74現在)
X(J) J R(J) X(J) J R(J) X(J) J R(J)
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
infinity
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
Cohen [Page 25]
コーエン[25ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
INDEX6 TABLE (as of 9-23-74)
INDEX6テーブル(9-23-74現在)
X(J) J R(J) X(J) J R(J)
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 infinity
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無限
Cohen [Page 26]
コーエン[26ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
INDEX5 TABLE (as of 9-23-74)
INDEX5テーブル(9-23-74現在)
X(J) J R(J) X(J) J R(J)
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 infinity
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無限
Cohen [Page 27]
コーエン[27ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
APPENDIX 2
付録2
IMPLEMENTATION RECOMMENDATIONS
実現推薦
(1) It is recommended that the priority-bit be turned ON in the HOST/IMP header.
(1) 優先権ビットがHOST/IMPヘッダーでつけられているのは、お勧めです。
(2) It is recommended that in all abbreviations, "R" be used for Receiver and "X" for Transmitter.
(2) それはすべての略語、「R」でそれに推薦されます。受信機と送信機のための「X」には、使用されてください。
(3) The following identifiers and values are recommended for implementations:
(3) 以下の識別子と値は実現のために推薦されます:
SLNCTH 30 SILENCE-THRESHOLD.
SLNCTH30沈黙敷居。
Used for LONG-SILENCE definition. See below. Measured in the
same units as GAIN, in its X-table.
LONG-SILENCE定義において、使用されています。 以下を見てください。 GAINと同じユニット、X-テーブルでは、測定されます。
TBS 1.000 sec TIME-BEGIN-SILENCE.
TBS、1.000秒、時間は沈黙を始めます。
LONG-SILENCE is declared if GAIN<SLNCTH for more than TBS.
LONG-SILENCEはTBS以上のためのGAIN<SLNCTHであるなら申告されます。
TAS 0.500 sec TIME-AFTER-SILENCE.
沈黙の後のTASの0.500秒の回。
A delay introduced by the receiver after the end of
LONG-SILENCE, before restarting the playback.
再生を再開する前にLONG-SILENCEの端の後の受信機によって導入された遅れ。
TES 0.150 sec TIME-END-SILENCE.
0.150秒の間のTES時間終わりの沈黙。
The amount of time the transmitter backs up at the end of a
LONG-SILENCE in order to ensure a smooth transition back to
speech.
送信機がスピーチへのスムーズな移行後部を確実にするためにLONG-SILENCEの端で支援する時間。
TRI 2.000 sec TIME-RESPONSE-INITIAL.
応答が頭文字をつける3-の2.000秒の回。
Time for waiting for response for an initial call (#1 and #3).
The initial call is repeated every TRI until an answer arrives,
or until TRIGU expires.
初期の要求(#1、と#3)のための応答を待つための時間。 初期の呼び出しは繰り返されて、あらゆる答えまでのTRIが到着するか、またはTRIGUまで期限が切れるということです。
TRIGU 20.000 sec TIME-RESPONSE-INITIAL-GIVEUP.
20.000秒のTRIGUのタイム誌の応答の初期のGIVEUP。
If no response to an initial call is received within TRIGU
after the FIRST initial call, the system gives up, assuming the
other system is down.
FIRSTの初期の呼び出しの後にTRIGUの中で初期の呼び出しへの応答を全く受けないなら、システムはあきらめます、もう片方のシステムがダウンしていると仮定して。
TRQ 1.000 sec TIME-RESPONSE-INQUIRY.
1.000秒の間のTRQ時間応答問い合せ。
If no response to an inquiry (#8) is received within TRQ, the
inquiry is repeated.
TRQの中で照会(#8)への応答を全く受けないなら、問い合せを繰り返します。
Cohen [Page 28]
コーエン[28ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
TRQGU 10.000 sec TIME-RESPONSE-INQUIRY-GIVEUP.
10.000秒のTRQGUタイム誌応答問い合せGIVEUP。
If no response to an inquiry is received within TRQGU from the
FIRST inquiry, the system gives up, assuming the other system
is down.
TRQGUの中でFIRST問い合せから照会への応答を全く受けないなら、システムはあきらめます、もう片方のシステムがダウンしていると仮定して。
TBDA 3.000 sec TIME-BETWEEN-DATA-ARRIVAL.
データ到着の間のTBDAの3.000秒の回。
If no data arrives within TBDA, an INQUIRY (#8) is sent. This
repeats every TBDA.
データが全くTBDAの中で到着しないなら、INQUIRY(#8)を送ります。 これはあらゆるTBDAを繰り返します。
TNR 2.000 sec TIME-NOT-READY.
NOTが準備するTNRの2.000秒の回。
If the other system is in the NOT-READY (#7) state for more
than TNR, an INQUIRY (#8) is sent. This repeats every TNR.
もう片方のシステムがTNR以上のためのREADY(#7)でない状態にあるなら、INQUIRY(#8)を送ります。 これはあらゆるTNRを繰り返します。
TNRGU 10.000 sec TIME-NOT-READY-GIVEUP.
10.000秒のTNRGUのタイム誌の持ち合わせでないGIVEUP。
If the other system is in the NOT-READY (#7) state for more
than TNRGU, then the system gives up, assuming the other
system is down.
もう片方のシステムがTNRGU以上のためのREADY(#7)でない状態にあるなら、システムはあきらめます、もう片方のシステムがダウンしていると仮定して。
TBIN 3.000 sec TIME-BUFFER-IN.
TBINの3.000秒の時間-BUFFER-IN。
The input buffer size is equivalent to the time period TBIN
(and its size is the DATA-RATE multiplied by the period
TBIN). If the INPUT QUEUE ever gets to be longer than TBIN,
data is discarded.
入力バッファサイズは期間のTBINに同等です(サイズは期間のTBINが掛けられたDATA-RATEです)。 INPUT QUEUEが、TBINより長いのを得るなら、データは捨てられます。
TBOUT 3.000 sec TIME-BUFFER-OUT.
3.000秒のTBOUT時間バッファアウト。
The output buffer size is equivalent to the time period TBOUT
(and its size is the DATA-RATE multiplied by the period
TBOUT). If the OUTPUT QUEUE ever gets to be longer than
TBOUT, data is discarded.
出力バッファサイズは期間のTBOUTに同等です(サイズは期間のTBOUTが掛けられたDATA-RATEです)。 OUTPUT QUEUEが、TBOUTより長いのを得るなら、データは捨てられます。
Cohen [Page 29]
コーエン[29ページ]
NWG/RFC 741 DC 22 Nov 77 42444 Specifications for the Network Voice Protocol (NVP)
ネットワーク声のプロトコルのためのNWG/RFC741DC1977年11月22日の42444仕様(NVP)
REFERENCES
参照
Bolt Beranek & Newman, Inc., Report No. 1822, Interface Message Processor: Specifications for the Interconnection of a Host and an IMP.
ボルトBeranekとニューマンInc.(レポートNo.1822)はメッセージプロセッサを連結します: ホストと悪童のインタコネクトのための仕様。
NSC Note 42 (in progress).
NSC Note42(進行中の)。
NSC Note 36, Proposal for NSC-LPC Coding/Decoding Tables, by J. D. Markel, Speech Communications Research Laboratory, Inc., July 20, 1974.
NSC注意36、1974年7月20日にJ.D.マーケル、スピーチ通信総合研究所Inc.でテーブルをコード化するか、または解読するNSC-LPCのための提案。
NSC Note 45, Everything You Always Wanted to Know about Gain, by E. Randolph Cole, USC/Information Sciences Institute, October 11, 1974.
NSCメモ45(USC/情報科学がE.ランドルフ・コールで設ける利得、1974年10月11日頃のあなたがいつも知りたかったすべて)。
NSC Note 56, Nothing to Lose, but Lots to Gain, by John Makhoul and Lynn Cosell, Bolt Beranek & Newman, Inc., March 10, 1975.
NSCメモ56(1975年3月10日にジョンMakhoul、リンコーセル、ボルトBeranek、およびニューマンInc.で獲得する多くのこと以外の失う無)。
NSC Note 58, Gain Again, by Randy Cole, USC/Information Sciences Institute, March 12, 1975.
NSCは再びランディ・コール、科学が1975年3月12日に設けるUSC/情報で58、利得に注意します。
Cohen [Page 30]
コーエン[30ページ]
一覧
スポンサーリンク
