Network Working Group J. Lazzaro
Request for Comments: 4696 J. Wawrzynek
Category: Informational UC Berkeley
November 2006
An Implementation Guide for RTP MIDI
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications.
このメモは、リアルタイムプロトコル（RTP）MIDI（楽器のディジタルインタフェース）ペイロード形式のための非標準実装のガイダンスを提供しています。メモは、ネットワークのミュージカル・パフォーマンス・アプリケーションのコンテキストでそのアドバイスを提示しています。このアプリケーションでは物理的に異なる場所にある2人のミュージシャンは、それらが同じ部屋にあるかのように実行するために、ネットワークを介して対話します。公演根底にユニキャストUDP上のRTP MIDIセッションがあります。回復ジャーナル（ペイロード形式の弾性構造）を送信および受信するためのアルゴリズムについて詳細に説明します。メモはネットワークのミュージカルのパフォーマンスに焦点を当てているが、提示実装のアドバイスは、他のRTP MIDIアプリケーションに関連しています。
Table of Contents
目次
1. Introduction ....................................................2
2. Starting the Session ............................................3
3. Session Management: Session Housekeeping ........................6
4. Sending Streams: General Considerations .........................7
4.1. Queuing and Coding Incoming MIDI Data .....................11
4.2. Sending Packets with Empty MIDI Lists .....................12
4.3. Congestion Control and Bandwidth Management ...............13
5. Sending Streams: The Recovery Journal ..........................14
5.1. Initializing the RJSS .....................................16
5.2. Traversing the RJSS .......................................19
5.3. Updating the RJSS .........................................19
5.4. Trimming the RJSS .........................................20
5.5. Implementation Notes ......................................21
6. Receiving Streams: General Considerations ......................21
6.1 The NMP Receiver Design ....................................22
6.2 High-Jitter Networks, Local Area Networks ..................24
7. Receiving Streams: The Recovery Journal ........................25
7.1. Chapter W: MIDI Pitch Wheel (0xE) .........................30
7.2. Chapter N: MIDI NoteOn (0x8) and NoteOff (0x9) ............30
7.3. Chapter C: MIDI Control Change (0xB) ......................32
7.4. Chapter P: MIDI Program Change (0xC) ......................34
8. Security Considerations ........................................35
9. IANA Considerations ............................................35
10. Acknowledgements ..............................................35
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................36
[RFC4695] normatively defines a Real-time Transport Protocol (RTP, [RFC3550]) payload format for the MIDI (Musical Instrument Digital Interface) command language [MIDI], for use under any applicable RTP profile, such as the Audio/Visual Profile (AVP, [RFC3551]).
[RFC4695]は規範的なオーディオ/ビジュアルプロファイルとして適用可能なRTPプロファイルの下で使用するためのMIDI（楽器のディジタルインタフェース）コマンド言語[MIDI]のためのリアルタイムトランスポートプロトコル（RTP、[RFC3550]）ペイロード形式を定義します（AVP、[RFC3551]）。
However, [RFC4695] does not define algorithms for sending and receiving MIDI streams. Implementors are free to use any sending or receiving algorithm that conforms to the normative text in [RFC4695], [RFC3550], [RFC3551], and [MIDI].
しかしながら、[RFC4695]はMIDIストリームを送受信するためのアルゴリズムを定義していません。実装は、[RFC4695]に規定テキストに準拠任意送信または受信のアルゴリズムを使用して自由であり、[RFC3550]、[RFC3551]、および[MIDI]。
In this memo, we offer implementation guidance on sending and receiving MIDI RTP streams. Unlike [RFC4695], this memo is not normative.
このメモでは、我々は、MIDI RTPストリームを送受信するには、実装ガイダンスを提供します。 [RFC4695]とは異なり、このメモは規範的ではありません。
RTP is a mature protocol, and excellent RTP reference materials are available [RTPBOOK]. This memo aims to complement the existing literature by focusing on issues that are specific to the MIDI payload format.
RTPは、成熟したプロトコルであり、優れたRTPの参考資料は、[RTPBOOK】利用可能です。このメモはMIDIペイロード形式に固有の問題に焦点を当てることによって既存の文献を補完することを目指しています。
The memo focuses on one application: two-party network musical performance over wide-area networks, following the interoperability guidelines in Appendix C.7.2 of [RFC4695]. Underlying the performances are RTP MIDI sessions over unicast UDP transport. Resiliency is provided by the recovery journal system [RFC4695]. The application also uses the RTP Control Protocol (RTCP, [RFC3550]).
広域ネットワーク上の2つのパーティのネットワークミュージカルのパフォーマンス、[RFC4695]の付録C.7.2における相互運用性のガイドライン以下：メモは、一つのアプリケーションに焦点を当てています。公演根底にユニキャストUDPトランスポート上のRTP MIDIセッションがあります。復元力は回復ジャーナルシステム[RFC4695]で提供されます。アプリケーションはまた、RTP制御プロトコル（RTCP、[RFC3550]）を使用します。
The application targets a network with a particular set of characteristics: low nominal jitter, low packet loss, and occasional outlier packets that arrive very late. However, in Section 6.2 of this memo, we discuss adapting the application to other network environments.
低公称ジッタ、低パケット損失、および非常に遅れて到着時折外れ値パケット：アプリケーションは、特性の特定のセットとのネットワークを対象としています。しかし、このメモのセクション6.2で、我々は他のネットワーク環境にアプリケーションを適応話し合います。
As defined in [NMP], a network musical performance occurs when musicians located at different physical locations interact over a network to perform as they would if located in the same room.
[NMP]で定義されるように異なる物理的位置に配置ミュージシャンは、それらが同じ部屋に位置するかのように実行するためにネットワークを介して対話するときに、ネットワーク・ミュージカルのパフォーマンスが発生します。
Sections 2-3 of this memo describe session startup and maintenance. Sections 4-5 cover sending MIDI streams, and Sections 6-7 cover receiving MIDI streams.
このメモのセクション2-3は、セッションの起動および保守について説明します。セクション4-5カバーMIDIストリームの送信、およびセクションは6-7カバーMIDIストリームを受信します。
In this section, we describe how the application starts a two-player session. We assume that the two parties have agreed on a session configuration, embodied by a pair of Session Description Protocol (SDP, [RFC4566]) session descriptions.
このセクションでは、アプリケーションが二人のセッションを開始する方法について説明します。我々は2人の当事者がセッション記述プロトコル（SDP、[RFC4566]）のペアによって具体セッション設定、セッション記述に合意したことを想定しています。
One session description (Figure 1) defines how the first party wishes to receive its stream. The other session description (Figure 2) defines how the second party wishes to receive its stream.
1つのセッション記述（図1）は、第一当事者がそのストリームを受信することを望む方法を定義します。他のセッション記述（図2）は、第2の当事者がそのストリームを受信することを望む方法を定義します。
The session description in Figure 1 codes that the first party intends to receive a MIDI stream on IP4 number 192.0.2.94 (coded in the c= line) at UDP port 16112 (coded in the m= line). Implicit in the SDP m= line syntax [RFC4566] is that the first party also intends to receive an RTCP stream on 192.0.2.94 at UDP port 16113 (16112 + 1). The receiver expects that the PT field of each RTP header in the received stream will be set to 96 (coded in the m= line).
第一当事者がUDPポート16112で（C =ラインで符号化された）IP4番号192.0.2.94にMIDIストリームを受信しようとする図1のコードのセッション記述は、（M =ラインで符号化されました）。 SDP mの暗黙=ライン構文[RFC4566]は最初の当事者もUDPポート16113（16112 + 1）で192.0.2.94にRTCPストリームを受信しようとしていることです。受信機は、受信したストリームにおける各RTPヘッダのPTフィールドは（M =ラインで符号化された）96に設定されることを期待します。
Likewise, the session description in Figure 2 codes that the second party intends to receive a MIDI stream on IP4 number 192.0.2.105 at UDP port 5004 and intends to receive an RTCP stream on 192.0.2.105 at
同様に、第2の当事者はUDPポート5004でIP4番号192.0.2.105のMIDIストリームを受けようとすると意図し、図2のコードでのセッション記述がで192.0.2.105にRTCPストリームを受信します
UDP port 5005 (5004 + 1). The second party expects that the PT RTP header field of received stream will be set to 101.
UDPポート5005（+ 1 5004）。第二当事者は、受信したストリームのPT RTPヘッダフィールドは101に設定されることを期待します。
v=0
o=first 2520644554 2838152170 IN IP4 first.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.94
m=audio 16112 RTP/AVP 96
b=AS:20
b=RS:0
b=RR:400
a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
cm_unused=ABFGHJKMQTVXYZ; cm_unused=C120-127; ch_never=ADEFMQTVX;
tsmode=buffer; linerate=320000; octpos=last; mperiod=44; rtp_ptime=0;
rtp_maxptime=0; guardtime=44100; render=synthetic; rinit="audio/asc";
url="http://example.net/sa.asc";
cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"
(The a=fmtp line has been wrapped to fit the page to accommodate memo formatting restrictions; it constitutes a single line in SDP.)
（A =のfmtpラインは、メモの書式の制限に対応するために、ページに収まるようにラップされています。それはSDP内の1行を構成しています。）
Figure 1. Session description for first participant
最初の参加者については、図1のセッションの説明
v=0
o=second 2520644554 2838152170 IN IP4 second.example.net
s=Example
t=0 0
c=IN IP4 192.0.2.105
m=audio 5004 RTP/AVP 101
b=AS:20
b=RS:0
b=RR:400
a=rtpmap:101 mpeg4-generic/44100
a=fmtp:101 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
cm_unused=ABFGHJKMQTVXYZ; cm_unused=C120-127; ch_never=ADEFMQTVX;
tsmode=buffer; linerate=320000;octpos=last;mperiod=44; guardtime=44100;
rtp_ptime=0; rtp_maxptime=0; render=synthetic; rinit="audio/asc";
url="http://example.net/sa.asc";
cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"
(The a=fmtp line has been wrapped to fit the page to accommodate memo formatting restrictions; it constitutes a single line in SDP.)
（A =のfmtpラインは、メモの書式の制限に対応するために、ページに収まるようにラップされています。それはSDP内の1行を構成しています。）
Figure 2. Session description for second participant
2番目の参加については、図2のセッションの説明
The session descriptions use the mpeg4-generic media type (coded in the a=rtpmap line) to specify the use of the MPEG 4 Structured Audio renderer [MPEGSA]. The session descriptions also use parameters to customize the stream (Appendix C of [RFC4695]). The parameter values are identical for both parties, yielding identical rendering environments for the two client hosts.
セッション記述は、MPEG 4構造化オーディオレンダラ[MPEGSA]の使用を指定するための（a = rtpmap線で符号化され）、MPEG4-ジェネリックメディアタイプを使用します。セッション記述はまた、ストリーム（[RFC4695]の付録C）をカスタマイズするためのパラメータを使用します。パラメータ値は、2つのクライアントのホストに対して同一のレンダリング環境を得、両当事者のために同じです。
The bandwidth (b=) AS parameter [RFC4566] [RFC3550] indicates that the total RTP session bandwidth is 20 kbs. This value assumes that the two players send 10 kbs streams concurrently. To derive the 10 kbs value, we begin with the analysis of RTP MIDI payload bandwidth in Appendix A.4 of [NMP] and add in RTP and IP4 packet overhead and a small safety factor.
パラメータ[RFC4566]、[RFC3550]と帯域幅（Bは=）総RTPセッション帯域幅が20のKBSであることを示しています。この値は、2人のプレーヤーが同時に10個のKBSのストリームを送信することを前提としています。 10のKBS値を導出するために、我々は、[NMP]の付録A.4でRTP MIDIペイロード帯域幅の分析から始まり、RTPとIP4パケットオーバーヘッドと小さな安全係数に追加します。
The bandwidth RR parameter [RFC3556] indicates that the shared RTCP session bandwidth for the two parties is 400 bps. We set the bandwidth SR parameter to 0 bps, to signal that sending parties and non-sending parties equally share the 400 bps of RTCP bandwidth. (Note that in this particular example, the guardtime parameter value of 44100 ensures that both parties are sending for the duration of the session.) The 400 bps RTCP bandwidth value supports one RTCP packet per 5 seconds from each party, containing a Sender Report and CNAME information [RFC3550].
帯域幅RRパラメータ[RFC3556]は両者の共有RTCPセッション帯域幅が400ベーシス・ポイントであることを示しています。我々は、送信パーティーや非送信当事者が均等にRTCP帯域幅の400ベーシス・ポイントを共有していることを知らせるために、0 bpsに帯域幅のSRパラメータを設定します。 （この特定の例では、44100のguardtimeパラメータの値は、両方の当事者がセッションの間、送信されることを保証することに注意してください。）400 bpsのRTCP帯域幅の値は、各当事者から5秒に1つのRTCPパケットをサポートし、送信者レポートを含むとCNAME情報[RFC3550]。
We now show an example of code that implements the actions the parties take during the session. The code is written in C and uses the standard network programming techniques described in [STEVENS]. We show code for the first party (the second party takes a symmetric set of actions).
私たちは今、当事者がセッション中に取るアクションを実装するコードの例を示しています。コードは、Cで書かれており、[STEVENS]に記載の標準的なネットワークプログラミング技術を使用しています。私たちは、（第二者がアクションの対称セットを取る）最初のパーティーのためのコードを示します。
Figure 3 shows how the first party initializes a pair of socket descriptors (rtp_fd and rtcp_fd) to send and receive UDP packets. After the code in Figure 3 runs, the first party may check for new RTP or RTCP packets by calling recv() on rtp_fd or rtcp_fd.
図3は、第1の当事者がUDPパケットを送信および受信するソケット記述子（rtp_fdとrtcp_fd）のペアを初期化する方法を示します。図3の実行中にコードの後、最初のパーティがrtp_fdまたはrtcp_fd上のrecv（）を呼び出すことによって、新たなRTPまたはRTCPパケットをチェックすることがあります。
Applications may use recv() to receive UDP packets on a socket using one of two general methods: "blocking" or "non-blocking".
「ブロッキング」または「非ブロック」：アプリケーションは、2つの一般的な方法のいずれかを使用してソケットにUDPパケットを受信する）（RECVを使用することができます。
A call to recv() on a blocking UDP socket puts the calling thread to sleep until a new packet arrives.
新しいパケットが到着するまでブロックUDPソケット上のrecv（）の呼び出しでは、スリープ状態に呼び出し元のスレッドを置きます。
A call to recv() on a non-blocking socket acts to poll the device: the recv() call returns immediately, with a return value that indicates the polling result. In this case, a positive return value signals the size of a new received packet, and a negative return value (coupled with an errno value of EAGAIN) indicates that no new packet was available.
非ブロッキングソケットでのrecv（）の呼び出しは、デバイスをポーリングするように作用する：RECV（）コールは、ポーリング結果を示す戻り値を用いて、直ちに返します。この場合には、正の戻り値は、新たな受信したパケットのサイズを通知し、（EAGAINのerrno値と結合された）負の戻り値は、新たなパケットが利用可能でなかったことを示しています。
The choice of blocking or non-blocking sockets is a critical application choice. Blocking sockets offer the lowest potential latency (as the OS wakes the caller as soon as a packet has arrived). However, audio applications that use blocking sockets must adopt a multi-threaded program architecture, so that audio samples may be generated on a "rendering thread" while the "network thread" sleeps, awaiting the next packet. The architecture must also support a thread communication mechanism, so that the network thread has a mechanism to send MIDI commands the rendering thread.
ソケットをブロックまたは非ブロックの選択は重要なアプリケーションの選択です。 （OSは、パケットが到着しているとすぐに、発信者をウェイクとして）ブロッキングソケットは最低電位のレイテンシを提供します。 「網糸」は、次のパケットを待つ、睡眠中のオーディオサンプルは、「レンダリングスレッド」を生成することができるように、しかし、ブロッキングソケットを使用するオーディオアプリケーションは、マルチスレッドプログラムのアーキテクチャを採用しなければなりません。ネットワークスレッドは、MIDIはレンダリングスレッドをコマンドを送信するためのメカニズムを持っているように、アーキテクチャは、スレッド間通信メカニズムをサポートしている必要があります。
In contrast, audio applications that use non-blocking sockets may be coded using a single thread, that alternates between audio sample generation and network polling. This architecture trades off increased network latency (as a packet may arrive between polls) for a simpler program architecture. For simplicity, our example uses non-blocking sockets and presumes a single run loop. Figure 4 shows how the example configures its sockets to be non-blocking.
対照的に、非ブロッキングソケットを使用するオーディオアプリケーションは、単一スレッドを使用して符号化することができる、オーディオサンプルの生成およびネットワーク・ポーリングの間に交互。このアーキテクチャは、単純なプログラムアーキテクチャの（パケットがポーリングの間に到着することができるように）増加ネットワーク遅延をトレードオフします。簡単にするために、私たちの例では、非ブロッキングソケットを使用して、単一の実行ループを前提とします。図4は、例えば、非ブロッキングであるために、そのソケットを構成する方法を示しています。
Figure 5 shows how to use recv() to check a non-blocking socket for new packets.
図5は、新しいパケットのための非ブロッキングソケットをチェックするためにrecv（）を使用する方法を示しています。
The first party also uses rtp_fd and rtcp_fd to send RTP and RTCP packets to the second party. In Figure 6, we show how to initialize socket structures that address the second party. In Figure 7, we show how to use one of these structures in a sendto() call to send an RTP packet to the second party.
最初のパーティもrtp_fdを使用し、第二のパーティにRTPとRTCPパケットを送信するためにrtcp_fd。図6では、我々は、第二党に対処ソケット構造を初期化する方法を示しています。図7では、我々は、第二者にRTPパケットを送信するためにはsendto（）の呼び出しでこれらの構造のいずれかを使用する方法を示しています。
Note that the code shown in Figures 3-7 assumes a clear network path between the participants. The code may not work if firewalls or Network Address Translation (NAT) devices are present in the network path.
図3-7に示すコードは、参加者間の明確なネットワークパスを想定しています。ファイアウォールまたはネットワークアドレス変換（NAT）デバイスは、ネットワーク経路内に存在する場合、コードが機能しない場合があります。
After the two-party interactive session is set up, the parties begin to send and receive RTP packets. In Sections 4-7, we discuss RTP MIDI sending and receiving algorithms. In this section, we describe session "housekeeping" tasks that the participants also perform.
二者対話型のセッションがセットアップされた後、当事者は、RTPパケットを送受信し始めます。セクション4-7で、我々はアルゴリズムを送受信するRTP MIDIを議論します。このセクションでは、参加者はまた、実行セッション「ハウスキーピング」タスクについて説明します。
One housekeeping task is the maintenance of the 32-bit Synchronization Source (SSRC) value that uniquely identifies each party. Section 8 of [RFC3550] describes SSRC issues in detail, as does Section 2.1 in [RFC4695]. Another housekeeping task is the sending and receiving of RTCP. Section 6 of [RFC3550] describes RTCP in detail.
一つのハウスキーピングタスクを一意各当事者を識別する32ビットの同期ソース（SSRC）値の維持です。 [RFC4695]セクション2.1と同様に、[RFC3550]のセクション8は、詳細にSSRC問題について説明します。他のハウスキーピング・タスクは、送信およびRTCPの送受信です。 [RFC3550]のセクション6を詳細にRTCPを記載しています。
Another housekeeping task concerns security. As detailed in the Security Considerations section of [RFC4695], per-packet authentication is strongly recommended for use with MIDI streams, because the acceptance of rogue packets may lead to the execution of arbitrary MIDI commands.
他のハウスキーピング・タスクは、セキュリティに関係します。 [RFC4695]のSecurity Considerations部で詳述したように、不正なパケットの受け入れは、任意のMIDIコマンドの実行につながる可能性があるため、パケットごとの認証が強く、MIDIストリームの使用をお勧めします。
A final housekeeping task concerns the termination of the session. In our two-party example, the session terminates upon the exit of one of the participants. A clean termination may require active effort by a receiver, as a MIDI stream stopped at an arbitrary point may cause stuck notes and other indefinite artifacts in the MIDI renderer.
最後のハウスキーピング・タスクは、セッションの終了に関するものです。我々の2つのパーティの例では、セッションは、参加者の1の終了時に終了します。 MIDIストリームはMIDIレンダラーに固着ノートや他の不定アーチファクトを引き起こす可能性が任意の時点で停止したように清浄な終端は、受信機によってアクティブな努力を必要とするかもしれません。
The exit of a party may be signalled in several ways. Session management tools may offer a reliable signal for termination (such as the SIP BYE method [RFC3261]). The (unreliable) RTCP BYE packet [RFC3550] may also signal the exit of a party. Receivers may also sense the lack of RTCP activity and timeout a party or may use transport methods to detect an exit.
党の出口は、いくつかの方法で通知することができます。セッション管理ツールを終了するための信頼できるシグナルを提供することができる（例えば、SIPのBYE方法として[RFC3261]）。 （信頼できない）RTCP BYEパケット[RFC3550]もパーティの終了をシグナリングすることができます。受信機はまた、RTCPの活性の欠如を感知し、党をタイムアウトまたは終了を検出するためのトランスポート・メソッドを使用する場合があります。
In this section, we discuss sender implementation issues.
このセクションでは、送信側の実装上の問題を議論します。
The sender is a real-time data-driven entity. On an ongoing basis, the sender checks to see if the local player has generated new MIDI data. At any time, the sender may transmit a new RTP packet to the remote player for the reasons described below:
送信者は、リアルタイムのデータ駆動型の実体です。地元のプレイヤーが新しいMIDIデータを生成した場合、継続的に、送信者かどうかを確認します。任意の時点で、送信者は、以下の理由のためにリモートプレイヤーに新たなRTPパケットを送信することがあります。
1. New MIDI data has been generated by the local player, and the sender decides that it is time to issue a packet coding the data.
1.新しいMIDIデータはローカルプレイヤーによって生成され、送信者は、データの符号化パケットを発行する時であると判断されました。
2. The local player has not generated new MIDI data, but the sender decides that too much time has elapsed since the last RTP packet transmission. The sender transmits a packet in order to relay updated header and recovery journal data.
2.ローカルプレーヤーは、新たなMIDIデータを生成していないが、送信者があまりにも多くの時間が最後のRTPパケットの送信から経過したと判断しました。送信者は、更新ヘッダーと回復ジャーナルデータを中継するためにパケットを送信します。
In both cases, the sender generates a packet that consists of an RTP header, a MIDI command section, and a recovery journal. In the first case, the MIDI list of the MIDI command section codes the new MIDI data. In the second case, the MIDI list is empty.
両方の場合において、送信側は、RTPヘッダ、MIDIコマンド部、及び回復ジャーナルから成るパケットを生成します。最初のケースで、MIDIコマンドセクションコード新しいMIDIデータのMIDIリスト。後者の場合には、MIDIリストは空です。
#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h>
#includeは<sys / types.h>にする#includeは<sys / socket.h>にする#include <netinetの/ in.h>
int rtp_fd, rtcp_fd; /* socket descriptors */
struct sockaddr_in addr; /* for bind address */
/*********************************/
/* create the socket descriptors */
/*********************************/
if ((rtp_fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) ERROR_RETURN("Couldn't create Internet RTP socket");
もし（（rtp_fd =ソケット（AF_INET、SOCK_DGRAM、0））<0）ERROR_RETURN（ "インターネットRTPソケットを作成できませんでした"）;
if ((rtcp_fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) ERROR_RETURN("Couldn't create Internet RTCP socket");
もし（（rtcp_fd =ソケット（AF_INET、SOCK_DGRAM、0））<0）ERROR_RETURN（ "インターネットRTCPソケットを作成できませんでした"）;
/**********************************/
/* bind the RTP socket descriptor */
/**********************************/
memset(&(addr.sin_zero), 0, 8);
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(16112); /* port 16112, from SDP */
if (bind(rtp_fd, (struct sockaddr *)&addr, sizeof(struct sockaddr)) < 0) ERROR_RETURN("Couldn't bind Internet RTP socket");
もし（バインド（rtp_fd、（sockaddr構造体*）＆addrは、はsizeof（sockaddr構造体））<0）ERROR_RETURN（ "インターネットRTPソケットをバインドできませんでした"）;
/***********************************/
/* bind the RTCP socket descriptor */
/***********************************/
memset(&(addr.sin_zero), 0, 8);
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(16113); /* port 16113, from SDP */
if (bind(rtcp_fd, (struct sockaddr *)&addr, sizeof(struct sockaddr)) < 0) ERROR_RETURN("Couldn't bind Internet RTCP socket");
もし（バインド（rtcp_fd、（sockaddr構造体*）＆addrは、はsizeof（sockaddr構造体））<0）ERROR_RETURN（ "インターネットRTCPソケットをバインドできませんでした"）;
Figure 3. Setup code for listening for RTP/RTCP packets
RTP / RTCPパケットを聞くための図3.セットアップコード
#include <unistd.h> #include <fcntl.h>
書式#include <unistd.h>書式#include <fcntl.h>
/***************************/
/* set non-blocking status */
/***************************/
if (fcntl(rtp_fd, F_SETFL, O_NONBLOCK)) ERROR_RETURN("Couldn't unblock Internet RTP socket");
（とfcntl（rtp_fd、F_SETFL、O_NONBLOCK））ERROR_RETURN場合（ "インターネットRTPソケットのブロックを解除できませんでした"）;
if (fcntl(rtcp_fd, F_SETFL, O_NONBLOCK)) ERROR_RETURN("Couldn't unblock Internet RTCP socket");
（とfcntl（rtcp_fd、F_SETFL、O_NONBLOCK））ERROR_RETURN場合（ "インターネットRTCPソケットのブロックを解除できませんでした"）;
Figure 4. Code to set socket descriptors to be non-blocking
非ブロックするソケット記述子を設定するための図4.コード
#include <errno.h>
#define UDPMAXSIZE 1472 /* based on Ethernet MTU of 1500 */
unsigned char packet[UDPMAXSIZE+1];
int len, normal;
while ((len = recv(rtp_fd, packet, UDPMAXSIZE + 1, 0)) > 0)
{
/* process packet[]. If (len == UDPMAXSIZE + 1), recv()
* may be returning a truncated packet -- process with care
*/
}
/* line below sets "normal" to 1 if the recv() return */
/* status indicates no packets are left to process */
normal = (len < 0) && (errno == EAGAIN);
=正常&&（errnoに== EAGAIN）（<0と呼ばれます）。
if (!normal)
{
/*
* recv() return status indicates an empty UDP payload
* (len == 0) or an error condition (coded by (len < 0)
* and (errno != EAGAIN)). Examine len and errno, and
* take appropriate recovery action.
*/
}
Figure 5. Code to check rtp_fd for new RTP packets
図5.コードは、新たなRTPパケットのrtp_fdチェックします
#include <arpa/inet.h> #include <netinet/in.h>
書式#include <ARPA / inet.h>の#include <netinetの/ in.h>
struct sockaddr_in * rtp_addr; /* RTP destination IP/port */
struct sockaddr_in * rtcp_addr; /* RTCP destination IP/port */
/* set RTP address, as coded in Figure 2's SDP */
rtp_addr = calloc(1, sizeof(struct sockaddr_in));
rtp_addr->sin_family = AF_INET;
rtp_addr->sin_port = htons(5004);
rtp_addr->sin_addr.s_addr = inet_addr("192.0.2.105");
/* set RTCP address, as coded in Figure 2's SDP */
rtcp_addr = calloc(1, sizeof(struct sockaddr_in));
rtcp_addr->sin_family = AF_INET;
rtcp_addr->sin_port = htons(5005); /* 5004 + 1 */
rtcp_addr->sin_addr.s_addr = rtp_addr->sin_addr.s_addr;
Figure 6. Initializing destination addresses for RTP and RTCP
RTPとRTCPの宛先アドレスの初期化6図
unsigned char packet[UDPMAXSIZE]; /* RTP packet to send */
int size; /* length of RTP packet */
/* first fill packet[] and set size ... then: */
if (sendto(rtp_fd, packet, size, 0, rtp_addr,
sizeof(struct sockaddr)) == -1)
{
/*
* try again later if errno == EAGAIN or EINTR
*
* other errno values --> an operational error
*/
}
Figure 7. Using sendto() to send an RTP packet
図7のsendto（）を使用してRTPパケットを送信します
Figure 8 shows the 5 steps a sender takes to issue a packet. This algorithm corresponds to the code fragment for sending RTP packets shown in Figure 7 of Section 2. Steps 1, 2, and 3 occur before the sendto() call in the code fragment. Step 4 corresponds to the sendto() call itself. Step 5 may occur once Step 3 completes.
図8は、送信側がパケットを発行するのにかかる5つのステップを示しています。このアルゴリズムは、2ステップ1、2、及び3は、コードフラグメントでのsendto（）呼び出しの前に発生するセクションの図7に示されているRTPパケットを送信するためのコードフラグメントに対応します。ステップ4のsendto（）呼び出し自体に相当します。ステップ5ステップ3の完了後に発生する可能性があります。
The algorithm for Sending a Packet is as follows:
次のようにパケットを送信するためのアルゴリズムは次のとおりです。
1. Generate the RTP header for the new packet. See Section 2.1 of [RFC4695] for details.
1.新しいパケットのRTPヘッダを生成します。詳細については、[RFC4695]のセクション2.1を参照してください。
2. Generate the MIDI command section for the new packet. See Section 3 of [RFC4695] for details.
2.新しいパケットのためのMIDIコマンドのセクションを生成します。詳細については、[RFC4695]のセクション3を参照してください。
3. Generate the recovery journal for the new packet. We discuss this process in Section 5.2. The generation algorithm examines the Recovery Journal Sending Structure (RJSS), a stateful coding of a history of the stream.
3.新しいパケットの回復ジャーナルを生成します。私たちは、5.2節では、このプロセスを議論します。生成アルゴリズムは、構造を送る回復ジャーナル（RJSS）、ストリームの歴史のステートフルなコーディングを調べます。
5. Update the RJSS to include the data coded in the MIDI command section of the packet sent in step 4. We discuss the update procedure in Section 5.3.
5.私たちは、5.3節での更新手順を議論ステップ4で送信されたパケットのMIDIコマンドのセクションで符号化されたデータを含めるようにRJSSを更新します。
Figure 8. A 5 step algorithm for sending a packet
図8パケットを送信するための5ステップのアルゴリズム
In the sections that follow, we discuss specific sender implementation issues in detail.
以下のセクションでは、我々は詳細に、特定の送信者の実装上の問題を議論します。
Simple senders transmit a new packet as soon as the local player generates a complete MIDI command. The system described in [NMP] uses this algorithm. This algorithm minimizes the sender queuing latency, as the sender never delays the transmission of a new MIDI command.
単純な送信者は、すぐに地元のプレイヤーが完全なMIDIコマンドを生成して、新たなパケットを送信します。 [NMP]に記載されたシステムは、このアルゴリズムを使用します。送信者が新しいMIDIコマンドの送信を遅らせることはありませんので、このアルゴリズムは、送信者のキューイング遅延を最小限に抑えることができます。
In a relative sense, this algorithm uses bandwidth inefficiently, as it does not amortize the overhead of a packet over several commands. This inefficiency may be acceptable for sparse MIDI streams (see Appendix A.4 of [NMP]). More sophisticated sending algorithms [GRAME] improve efficiency by coding small groups of commands into a single packet, at the expense of increasing the sender queuing latency.
それはいくつかのコマンドを介してパケットのオーバーヘッドを償却しないよう相対的な意味では、このアルゴリズムは、非効率的な帯域幅を使用しています。この非効率性は、スパースMIDIストリーム（付録A.4 [NMP]を参照）のために許容され得ます。より洗練された送信アルゴリズムは[GRAME】送信側キューイング遅延を増加さを犠牲にして、単一のパケットにコマンドの小さなグループを符号化効率を向上させます。
Senders assign a timestamp value to each command issued by the local player (Appendix C.3 of [RFC4695]). Senders may code the timestamp value of the first MIDI list command in two ways. The most efficient method is to set the RTP timestamp of the packet to the timestamp value of the first command. In this method, the Z bit of the MIDI command section header (Figure 2 of [RFC4695]) is set to 0, and the RTP timestamps increment at a non-uniform rate.
送信者は、ローカルプレーヤー（[RFC4695]の付録C.3）によって発行された各コマンドにタイムスタンプ値を割り当てます。送信者は、2つの方法で最初のMIDI listコマンドのタイムスタンプ値をコードすることができます。最も効率的な方法は、最初のコマンドのタイムスタンプ値にパケットのRTPタイムスタンプを設定することです。この方法では、MIDIコマンドセクションヘッダのZビット（[RFC4695]の図2）が0に設定され、RTPは、非均一速度で増分をタイムスタンプ。
However, in some applications, senders may wish to generate a stream whose RTP timestamps increment at a uniform rate. To do so, senders may use the Delta Time MIDI list field to code a timestamp for the first command in the list. In this case, the Z bit of the MIDI command section header is set to 1.
ただし、一部のアプリケーションでは、送信者は、そのRTPタイムスタンプ一定の速度で増分ストリームを生成することを望むかもしれません。そうするために、送信者は、リスト内の最初のコマンドのタイムスタンプをコーディングするデルタタイムMIDIリストフィールドを使用することができます。この場合、MIDIコマンドのセクションヘッダのZビットが1に設定されています。
Senders should strive to maintain a constant relationship between the RTP packet timestamp and the packet sending time: if two packets have RTP timestamps that differ by 1 second, the second packet should be sent 1 second after the first packet. To the receiver, variance in this relationship is indistinguishable from network jitter. Latency issues are discussed in detail in Section 6.
送信者は、RTPパケットのタイムスタンプおよびパケット送信時との間に一定の関係を維持するために努力すべきである：2つのパケットが1秒だけ異なるRTPタイムスタンプを持っている場合、第2のパケットが第一パケットの後に1秒を送信すべきです。受信機には、この関係の変動は、ネットワークジッタと区別できません。待ち時間の問題は、第6節で詳しく説明されています。
Senders may alter the running status coding of the first command in the MIDI list, in order to comply with the coding rules defined in Section 3.2 of [RFC4695]. The P header bit (Figure 2 of [RFC4695]) codes this alteration of the source command stream.
送信者は、[RFC4695]のセクション3.2で定義されたコーディング規則に準拠するために、MIDIリストの最初のコマンドの実行のステータスコードを変更することができます。 Pヘッダービットコードソース命令ストリームのこの変化（[RFC4695]の図2）。
During a session, musicians might refrain from generating MIDI data for extended periods of time (seconds or even minutes). If an RTP stream followed the dynamics of a silent MIDI source and stopped sending RTP packets, system behavior might be degraded in the following ways:
セッション中に、ミュージシャンは、長期間（秒あるいは分）のMIDIデータを生成控えるかもしれません。 RTPストリームはサイレントMIDIソースのダイナミクスを踏襲し、RTPパケットの送信を停止した場合、システムの動作は、次の方法で分解されることがあります。
o The receiver's model of network performance may fall out of date.
Oネットワークパフォーマンスのレシーバのモデルが古くなって落ちることがあります。
o Network middleboxes (such as Network Address Translators) may "time-out" the silent stream and drop the port and IP association state.
Oネットワークの中間装置かもしれない「タイムアウト」サイレントストリームを（例えばネットワークとしては、トランスレータをアドレス）とポートとIPの会合状態をドロップ。
o If the session does not use RTCP, receivers may misinterpret the silent stream as a dropped network connection.
セッションは、RTCPを使用していない場合は、O、受信機はドロップネットワーク接続などのサイレントストリームを誤って解釈することがあります。
Senders avoid these problems by sending "keep-alive" RTP packets during periods of network inactivity. Keep-alive packets have empty MIDI lists.
送信者は、ネットワークの非活動期間中に「キープアライブ」RTPパケットを送信することにより、これらの問題を回避します。キープアライブパケットは、空のMIDIリストを持っています。
Session participants may specify the frequency of keep-alive packets during session configuration with the MIME parameter "guardtime" (Appendix C.4.2 of [RFC4695]). The session descriptions shown in Figures 1-2 use guardtime to specify a keep-alive sending interval of 1 second.
セッション参加者は、MIMEパラメータ「guardtime」（[RFC4695]の付録C.4.2）とのセッションの設定時にキープアライブパケットの頻度を指定することもできます。図1-2利用guardtimeに示すセッション記述は、1秒のキープアライブ送信間隔を指定します。
Senders may also send empty packets to improve the performance of the recovery journal system. As we describe in Section 6, the recovery process begins when a receiver detects a break in the RTP sequence number pattern of the stream. The receiver uses the recovery journal of the break packet to guide corrective rendering actions, such as ending stuck notes and updating out-of-date controller values.
送信者はまた、回復ジャーナルシステムのパフォーマンスを向上させるために、空のパケットを送信することができます。我々は第6節で説明したよう受信機は、ストリームのRTPシーケンス番号パターンの断線を検出した場合には、回復プロセスが開始されます。受信機は、このようなスタックのノートを終了し、期限切れのコントローラ値を更新するなどの是正レンダリングアクションを導くためにブレークパケットの回復ジャーナルを使用しています。
Consider the situation where the local player produces a MIDI NoteOff command (which the sender promptly transmits in a packet) but then 5 seconds pass before the player produces another MIDI command (which the sender transmits in a second packet). If the packet coding the NoteOff is lost, the receiver is not aware of the packet loss incident for 5 seconds, and the rendered MIDI performance contains a note that sounds for 5 seconds too long.
地元のプレイヤーが（送信者が速やかにパケットで送信）MIDI NoteOffコマンドを生成しますが、プレイヤーが（送信者が第2のパケットで送信）他のMIDIコマンドを生成する前に、その後5秒が通過状況を考えてみましょう。 NoteOffコーディングパケットが失われた場合、受信機は、5秒間パケット損失事件を認識していない、とレンダリングされたMIDI性能が長すぎる5秒間鳴りノートが含まれています。
To handle this situation, senders may transmit empty packets to "guard" the stream during silent sections. The guard packet algorithm defined in Section 7.3 of [NMP], as applied to the situation described above, sends a guard packet after 100 ms of player inactivity, and sends a second guard packet 100 ms later. Subsequent guard packets are sent with an exponential backoff, with a limiting period of 1 second (set by the "guardtime" parameter in Figures 1-2). The algorithm terminates once MIDI activity resumes, or once RTCP receiver reports indicate that the receiver is up to date.
このような状況に対処するために、送信者は「ガード」無音区間中にストリームに空パケットを送信してもよいです。 [NMP]のセクション7.3で定義されたガード・パケット・アルゴリズムは、上述の状況に適用される、プレイヤーが非アクティブの100ミリ秒後にガードパケットを送信し、100 ms後に第2のガードパケットを送信します。後続のガードパケットは、（図1-2に「guardtime」パラメータで設定）1秒の制限期間を用いて、指数バックオフを用いて送信されます。 MIDI活動が再開したら、アルゴリズムは終了、またはRTCPいったん受信機レポートは、受信機が最新であることを示しています。
The perceptual quality of guard packet-sending algorithms is a quality of implementation issue for RTP MIDI applications. Sophisticated implementations may tailor the guard packet sending rate to the nature of the MIDI commands recently sent in the stream, to minimize the perceptual impact of moderate packet loss.
ガードパケット送信アルゴリズムの知覚品質はRTP MIDIアプリケーションの実装の質の問題です。洗練された実装では、MIDIの性質のために率を送るガードパケットを合わせることが、最近、中程度のパケット損失の知覚的影響を最小限に抑えるために、ストリームで送信されたコマンド。
As an example of this sort of specialization, the guard packet algorithm described in [NMP] protects against the transient artifacts that occur when NoteOn commands are lost. The algorithm sends a guard packet 1 ms after every packet whose MIDI list contains a NoteOn command. The Y bit in Chapter N note logs (Appendix A.6 of [RFC4695]) supports this use of guard packets.
専門のこの種の例として、[NMP]に記載のガード・パケット・アルゴリズムはNoteOnコマンドが失われたときに発生する過渡的アーチファクトから保護します。このアルゴリズムは、1ミリ秒、そのMIDIリストNoteOnコマンドを含むすべてのパケットの後にガードパケットを送信します。章Nノートログ（[RFC4695]の付録A.6）におけるYビットはガードパケットのこの使用をサポートしています。
Congestion control and bandwidth management are key issues in guard packet algorithms. We discuss these issues in the next section.
輻輳制御と帯域幅管理は、ガードパケットアルゴリズムの重要な問題です。私たちは、次のセクションで、これらの問題を議論します。
The congestion control section of [RFC4695] discusses the importance of congestion control for RTP MIDI streams and references the normative text in [RFC3550] and [RFC3551] that concerns congestion control. To comply with the requirements described in those normative documents, RTP MIDI senders may use several methods to control the sending rate: o As described in Section 4.1, senders may pack several MIDI commands into a single packet, thereby reducing stream bandwidth (at the expense of increasing sender queuing latency).
[RFC4695]の輻輳制御部は、RTP MIDIストリームと参照輻輳制御に関する[RFC3550]及び[RFC3551]に規定テキストのための輻輳制御の重要性を論じています。これらの規範文書に記載されている要件に準拠するため、RTP MIDIの送信者は、送信レートを制御するために、いくつかの方法を使用することができる：4.1節で述べたように、送信者は、それによって犠牲にして、ストリームの帯域幅を（還元、いくつかのMIDIは、単一のパケットにコマンドを詰めることoを送信者のキューイングの待ち時間）を増加させます。
o Guard packet algorithms (Section 4.2) may be designed in a parametric way, so that the tradeoff between artifact reduction and stream bandwidth may be tuned dynamically.
アーティファクト低減ストリーム帯域幅の間のトレードオフを動的に調整することができるように、Oガードパケットアルゴリズム（セクション4.2）は、パラメトリックな方法で設計することができます。
o The recovery journal size may be reduced by adapting the techniques described in Section 5 of this memo. Note that in all cases, the recovery journal sender must conform to the normative text in Section 4 of [RFC4695].
O回復ジャーナルのサイズは、このメモのセクション5に記載された技術を適応させることによって減少させることができます。すべての場合には、回復ジャーナル送信者は[RFC4695]のセクション4で規範的なテキストに適合しなければならないことに注意してください。
o The incoming MIDI stream may be modified to reduce the number of MIDI commands without significantly altering the performance. Lossy "MIDI filtering" algorithms are well developed in the MIDI community and may be directly applied to RTP MIDI rate management.
O着信MIDIストリームは、MIDIのパフォーマンスを大幅に変えることなく、コマンドの数を減少させるために修飾することができます。ロッシー「MIDIのフィルタリング」アルゴリズムはうまくMIDIコミュニティで開発され、直接RTP MIDI率管理に適用することができます。
RTP MIDI senders incorporate these rate control methods into feedback systems to implement congestion control and bandwidth management. Sections 10 and 6.4.4 of [RFC3550] and Section 2 in [RFC3551] describe feedback systems for congestion control in RTP, and Section 6 of [RFC4566] describes bandwidth management in media sessions.
RTP MIDIの送信者は輻輳制御と帯域幅の管理を実装するためにフィードバックシステムにこれらのレート制御方式を採用しています。 [RFC3551]のセクション10及び[RFC3550]の6.4.4及びセクション2は、RTPにおける輻輳制御のためのフィードバックシステムを記述して、[RFC4566]のセクション6は、メディアセッションに帯域幅管理を説明しています。
In this section, we describe how senders implement the recovery journal system. The implementation we describe uses the default "closed-loop" recovery journal semantics (Appendix C.2.2.2 of [RFC4695]).
このセクションでは、送信者が回復ジャーナルシステムを実装する方法について説明します。私たちが説明実装は、デフォルトの「クローズドループ」回復ジャーナル意味論（[RFC4695]の付録C.2.2.2）を使用しています。
We begin by describing the Recovery Journal Sending Structure (RJSS). Senders use the RJSS to generate the recovery journal section for RTP MIDI packets.
私たちは、回復ジャーナル送信構造（RJSS）を記述することから始めます。送信者は、RTP MIDIパケットの回復ジャーナルセクションを生成するためにRJSSを使用しています。
The RJSS is a hierarchical representation of the checkpoint history of the stream. The checkpoint history holds the MIDI commands that are at risk to packet loss (Appendix A.1 of [RFC4695] precisely defines the checkpoint history). The layout of the RJSS mirrors the hierarchical structure of the recovery journal bitfields.
RJSSは、ストリームのチェックポイント歴史の階層表現です。チェックポイント歴史は、パケットロス（[RFC4695]の付録A.1を正確にチェックポイント歴史を定義する）へのリスクにさらされているMIDIコマンドを保持しています。 RJSSのレイアウトは回復ジャーナルビットフィールドの階層構造を反映しています。
Figure 9 shows an RJSS implementation for a simple sender. The leaf level of the RJSS hierarchy (the jsend_chapter structures) corresponds to channel chapters (Appendices A.2-9 in [RFC4695]). The second level of the hierarchy (jsend_channel) corresponds to the channel journal header (Figure 9 in [RFC4695]). The top level of the hierarchy (jsend_journal) corresponds to the recovery journal header (Figure 8 in [RFC4695]).
図9は、単純な送信者のRJSSの実装を示しています。 RJSS階層（jsend_chapter構造）のリーフレベルは章（[RFC4695]で付録A.2-9）をチャネルに対応します。階層の第二レベル（jsend_channel）は、チャネルジャーナルヘッダ（[RFC4695]で図9）に対応します。階層の最上位レベル（jsend_journal）が回復ジャーナルヘッダ（[RFC4695]で図8）に相当します。
Each RJSS data structure may code several items:
各RJSSデータ構造は、複数の項目をコードし得ます。
1. The current contents of the recovery journal bitfield associated with the RJSS structure (jheader[], cheader[], or a chapter bitfield).
1.回復ジャーナルの現在の内容はRJSS構造（jheader []、cheader []、またはチャプタビットフィールド）に関連付けられたビットフィールド。
2. A seqnum variable. Seqnum codes the extended RTP sequence number of the most recent packet that added information to the RJSS structure. If the seqnum of a structure is updated, the seqnums of all structures above it in the recovery journal hierarchy are also updated. Thus, a packet that caused an update to a specific jsend_chapter structure would update the seqnum values of this structure and of the jsend_channel and jsend_journal structures that contain it.
2. SEQNUM変数。 SEQNUMコードRJSS構造に情報を追加しました最新のパケットの拡張されたRTPシーケンス番号。構造のSEQNUMが更新されている場合は、回復ジャーナル階層でその上にあるすべての構造体のseqnumsも更新されます。したがって、このような構造の、それを含んでjsend_channelとjsend_journal構造のSEQNUM値を更新してしまう特定jsend_chapter構造への更新を引き起こしたパケット。
A seqnum variable for a level is set to zero if the checkpoint history contains no information at the level of the seqnum variable, and no information at any level below the level of the seqnum variable. This coding scheme assumes that the first sequence number of a stream is normalized to 1, and limits the total number of stream packets to 2^32 - 1.
チェックポイント履歴がSEQNUM変数のレベルで何の情報、及びSEQNUM変数のレベル以下の任意のレベルで情報が含まれていない場合はレベルのためSEQNUM変数はゼロに設定されます。 1 - この符号化方式は、ストリームの最初のシーケンス番号が1に正規化され、そして2 ^ 32にストリームパケットの総数を制限することを前提としています。
The cm_unused and ch_never parameters in Figures 1-2 define the subset of MIDI commands supported by the sender (see Appendix C.2.3 of [RFC4695] for details). The sender transmits most voice commands but does not transmit system commands. The sender assumes that the MIDI source uses note commands in the typical way. Thus, the sender does not use the Chapter E note resiliency tools (Appendix A.7 of [RFC4695]). The sender does not support Control Change commands for controller numbers with All Notes Off (123-127), All Sound Off (120), and Reset All Controllers (121) semantics and does not support enhanced Chapter C encoding (Appendix A.3.3 of [RFC4695]).
図1-2 cm_unusedとch_neverパラメータは、MIDIのサブセットは送信者がサポートするコマンド定義（詳細については[RFC4695]の付録C.2.3を参照）。送信者は、ほとんどの音声コマンドを送信しますが、システムのコマンドを送信しません。送信者は、MIDIソースは、一般的な方法で、ノートのコマンドを使用していることを前提としています。したがって、送信者は章Eノート弾力性ツール（[RFC4695]の付録A.7）を使用していません。送信者は、コントロールチェンジは、すべてのノート・オフ（123-127）と、コントローラ番号、オール・サウンド・オフ（120）するためのコマンド、およびすべてのコントローラ（121）セマンティクスをリセットしての高められた章Cコード化（付録A.3.3をサポートしていませんサポートしていません。 [RFC4695]）。
We chose this subset of MIDI commands to simplify the example. In particular, the command restrictions ensure that all commands are active, that all note commands are N-active, and that all Control Change commands are C-active (see Appendix A.1 of [RFC4695] for definitions of active, N-active, and C-active).
私たちは、MIDIのこのサブセットは、例を単純化するためにコマンドを選択しました。具体的には、コマンドの制限は、すべてのノートコマンドがN-アクティブであることを、すべてのコマンドがアクティブであることを確認し、すべてのコントロールチェンジコマンドはC活性は（N-アクティブ、アクティブの定義については、[RFC4695]の付録A.1を参照していること、およびC-アクティブ）。
In the sections that follow, we describe the tasks a sender performs to manage the recovery journal system.
以下のセクションでは、送信者が回復ジャーナルシステムを管理するために実行するタスクについて説明します。
At the start of a stream, the sender initializes the RJSS. All seqnum variables are set to zero, including all elements of note_seqnum[] and control_seqnum[].
ストリームの開始時に、送信者はRJSSを初期化します。全てSEQNUM変数はnote_seqnum []とcontrol_seqnum []の全ての要素を含む、ゼロに設定されます。
The sender initializes jheader[] to form a recovery journal header that codes an empty journal. The S bit of the header is set to 1, and the A, Y, R, and TOTCHAN header fields are set to zero. The checkpoint packet sequence number field is set to the sequence number of the upcoming first RTP packet (per Appendix A.1 of [RFC4695]).
送信者はjheader []そのコード空ジャーナル回復ジャーナルヘッダーを形成するように初期化します。ヘッダのSビットが1に設定され、A、Y、R、及びTOTCHANヘッダフィールドはゼロに設定されています。チェックポイントパケットシーケンス番号フィールドは、（[RFC4695]の付録A.1当たり）今後の第一のRTPパケットのシーケンス番号に設定されています。
typedef unsigned char uint8; /* must be 1 octet */
typedef unsigned short uint16; /* must be 2 octet */
typedef unsigned long uint32; /* must be 4 octets */
/**************************************************************/
/* leaf level hierarchy: Chapter W, Appendix A.5 of [RFC4695] */
/**************************************************************/
typedef struct jsend_chapterw { /* Pitch Wheel (0xE) */
uint8 chapterw[2]; /* bitfield Figure A.5.1 [RFC4695] */
uint32 seqnum; /* extended sequence number, or 0 */
} jsend_chapterw;
/**************************************************************/
/* leaf level hierarchy: Chapter N, Appendix A.6 of [RFC4695] */
/**************************************************************/
typedef struct jsend_chaptern { /* Note commands (0x8, 0x9) */
/* chapter N maximum size is 274 octets: a 2 octet header, */
/* and a maximum of 128 2-octet logs and 16 OFFBIT octets */
uint8 chaptern[274]; /* bitfield Figure A.6.1 [RFC4695] */
uint16 size; /* actual size of chaptern[] */
uint32 seqnum; /* extended seq number, or 0 */
uint32 note_seqnum[128]; /* most recent note seqnum, or 0 */
uint32 note_tstamp[128]; /* NoteOn execution timestamp */
uint32 bitfield_ptr[128]; /* points to a chapter log, or 0 */
} jsend_chaptern;
/**************************************************************/
/* leaf level hierarchy: Chapter C, Appendix A.3 of [RFC4695] */
/**************************************************************/
typedef struct jsend_chapterc { /* Control Change (0xB) */
/* chapter C maximum size is 257 octets: a 1 octet header */
/* and a maximum of 128 2-octet logs */
uint8 chapterc[257]; /* bitfield Figure A.3.1 [RFC4695] */
uint16 size; /* actual size of chapterc[] */
uint32 seqnum; /* extended sequence number, or 0 */
uint32 control_seqnum[128]; /* most recent seqnum, or 0 */
uint32 bitfield_ptr[128]; /* points to a chapter log, or 0 */
} jsend_chapterc;
Figure 9. Recovery Journal Sending Structure (part 1)
構造を送信する図9.リカバリー・ジャーナル（パート1）
/**************************************************************/
/* leaf level hierarchy: Chapter P, Appendix A.2 of [RFC4695] */
/**************************************************************/
typedef struct jsend_chapterp { /* MIDI Program Change (0xC) */
uint8 chapterp[3]; /* bitfield Figure A.2.1 [RFC4695] */
uint32 seqnum; /* extended sequence number, or 0 */
} jsend_chapterp;
} jsend_chapterp。
/***************************************************/
/* second-level of hierarchy, for channel journals */
/***************************************************/
typedef struct jsend_channel {
typedefは構造体jsend_channel {
uint8 cheader[3]; /* header Figure 9 [RFC4695]) */
uint32 seqnum; /* extended sequence number, or 0 */
jsend_chapterp chapterp; /* chapter P info */
jsend_chapterc chapterc; /* chapter C info */
jsend_chapterw chapterw; /* chapter W info */
jsend_chaptern chaptern; /* chapter N info */
} jsend_channel;
} jsend_channel。
/*******************************************************/
/* top level of hierarchy, for recovery journal header */
/*******************************************************/
typedef struct jsend_journal {
typedefは構造体jsend_journal {
uint8 jheader[3]; /* header Figure 8, [RFC4695] */
/* Note: Empty journal has a header */
uint32 seqnum; /* extended sequence number, or 0 */
/* seqnum = 0 codes empty journal */
jsend_channel channels[16]; /* channel journal state */
/* index is MIDI channel */
} jsend_journal;
} jsend_journal。
Figure 9. Recovery Journal Sending Structure (part 2)
構造を送信する図9.リカバリー・ジャーナル（パート2）
In jsend_chaptern, elements of note_tstamp[] are set to zero. In jsend_chaptern and jsend_chapterc, elements of bitfield_ptr[] are set to the null pointer index value (bitfield_ptr[] is an array whose elements point to the first octet of the note or control log associated with the array index).
jsend_chapternにおいて、note_tstamp []の要素がゼロに設定されます。 jsend_chapternとjsend_chaptercにおいて、bitfield_ptrの要素[]がNULLポインタインデックス値に設定される（bitfield_ptr []その要素が配列インデックスに関連付けられたメモ又は制御ログの最初のオクテットを指し配列です）。
Whenever an RTP packet is created (Step 3 of the algorithm defined in Figure 8), the sender traverses the RJSS to create the recovery journal for the packet. The traversal begins at the top level of the RJSS. The sender copies jheader[] into the packet and then sets the S bit of jheader[] to 1.
RTPパケットが（図8で定義されたアルゴリズムのステップ3）作成されるたびに、送信者は、パケットの回復ジャーナルを作成するためのRJSSを横断します。トラバーサルはRJSSのトップレベルで始まります。次いで、1 jheader []のSビットを設定パケットにjheader []と、送信者コピー。
The traversal continues depth-first, visiting every jsend_channel whose seqnum variable is non-zero. The sender copies the cheader[] array into the packet and then sets the S bit of cheader[] to 1. After each cheader[] copy, the sender visits each leaf-level chapter, in the order of its appearance in the chapter journal Table of Contents (first P, then C, then W, then N, as shown in Figure 9 of [RFC4695]).
トラバーサルは、そのSEQNUM可変非ゼロであるすべてのjsend_channelを訪問し、深さ優先続けます。送信者コピーパケットにcheader []配列し、各cheader []コピー後1に[] cheaderのSビットをセットし、送信者の訪問章ジャーナルにおけるその出現順に各リーフレベルの章、目次（最初のP、次いでC、次いで、W、次いでN、[RFC4695]の図9に示すように）。
If a chapter has a non-zero seqnum, the sender copies the chapter bitfield array into the packet and then sets the S bit of the RJSS array to 1. For chaptern[], the B bit is also set to 1. For the variable-length chapters (chaptern[] and chapterc[]), the sender checks the size variable to determine the bitfield length.
章では、パケットに非ゼロSEQNUM、送信者コピー章ビットフィールドの配列を有して、[]、Bビットは、可変の場合1に設定されchapternについて1にRJSSアレイのSビットを設定した場合-length章（chaptern []とchapterc []）、送信者は、ビットフィールドの長さを決定するために、サイズの変数をチェックします。
Before copying chaptern[], the sender updates the Y bit of each note log to code the onset of the associated NoteOn command (Figure A.6.3 in [RFC4695]). To determine the Y bit value, the sender checks the note_tstamp[] array for note timing information.
chapternをコピーする前に[]、送信者は、関連NoteOnコマンド（[RFC4695]で図A.6.3）の発症を符号化するために、各音符ログのYビットを更新します。 Yビット値を決定するために、送信者は、音符のタイミング情報のためnote_tstamp []配列を確認します。
After an RTP packet is sent, the sender updates the RJSS to refresh the checkpoint history (Step 5 of the sending algorithm defined in Figure 8). For each command in the MIDI list of the sent packet, the sender performs the update procedure we now describe.
RTPパケットが送信された後、送信側は、チェックポイント履歴（図8で定義された送信アルゴリズムのステップ5）をリフレッシュするRJSSを更新します。送信されたパケットのMIDIリスト内の各コマンドのために、送信者は、私たちが今説明更新手順を実行します。
The update procedure begins at the leaf level. The sender generates a new bitfield array for the chapter associated with the MIDI command using the chapter-specific semantics defined in Appendix A of [RFC4695].
更新手順は、リーフレベルで開始されます。送信者は[RFC4695]の付録Aで定義された章固有のセマンティクスを使用して、MIDIコマンドに関連付けられた章のための新しいビットフィールドの配列を生成します。
For Chapter N and Chapter C, the sender uses the bitfield_ptr[] array to locate and update an existing log for a note or controller. If a log does not exist, the sender adds a log to the end of the chaptern[] or chapterc[] bitfield and changes the bitfield_ptr[] value to point to the log. For Chapter N, the sender also updates note_tstamp[].
章N及び章Cのために、送信者はbitfield_ptr []配列は、音符またはコントローラの既存のログを検索し、更新するために使用します。ログが存在しない場合、送信者はchaptern []またはchapterc []ビットフィールドの末尾にログを追加し、ログを指すようにbitfield_ptr []の値を変更します。章Nのために、送信者はまた、[] note_tstamp更新します。
The sender also clears the S bit of the chapterp[], chapterw[], or chapterc[] bitfield. For chaptern[], the sender clears the S bit or the B bit of the bitfield, as described in Appendix A.6 of [RFC4695].
送信者はまたchapterp []、chapterw []、又はchapterc []ビットフィールドのSビットをクリアします。 [RFC4695]の付録A.6に記載されているように[] chapternため、送信者は、SビットまたはビットフィールドのBビットをクリアします。
Next, the sender refreshes the upper levels of the RJSS hierarchy. At the second level, the sender updates the cheader[] bitfield of the channel associated with the command. The sender sets the S bit of cheader[] to 0. If the new command forced the addition of a new chapter or channel journal, the sender may also update other cheader[] fields. At the top level, the sender updates the top-level jheader[] bitfield in a similar manner.
次に、送信者はRJSS階層の上位レベルを更新します。第二のレベルでは、送信者がコマンドに関連付けられたチャネルのcheader []ビットフィールドを更新します。送信者は、新しいコマンドが新たな章またはチャンネルジャーナルの添加を強制した場合、送信者は、他のcheader []フィールドを更新することが0に[] cheaderのSビットをセットします。トップレベルでは、送信者は、同様にビットフィールド最上位jheader []を更新します。
Finally, the sender updates the seqnum variables associated with the changed bitfield arrays. The sender sets the seqnum variables to the extended sequence number of the packet.
最後に、送信者が変更されたビットフィールドの配列に関連したSEQNUM変数を更新します。送信者は、パケットの拡張シーケンス番号にSEQNUM変数を設定します。
At regular intervals, receivers send RTCP receiver reports to the sender (as described in Section 6.4.2 of [RFC3550]). These reports include the extended highest sequence number received (EHSNR) field. This field codes the highest sequence number that the receiver has observed from the sender, extended to disambiguate sequence number rollover.
（[RFC3550]のセクション6.4.2で説明したように）定期的に、受信機は、送信者にRTCPレシーバレポートを送信します。これらのレポートは、拡張された最大のシーケンス番号は（EHSNR）フィールドを受けています。受信機は、送信者から見たこのフィールドコード最高シーケンス番号は、シーケンス番号ロールオーバを明確にするために拡張しました。
When the sender receives an RTCP receiver report, it runs the RJSS trimming algorithm. The trimming algorithm uses the EHSNR to trim away parts of the RJSS. In this way, the algorithm reduces the size of recovery journals sent in subsequent RTP packets. The algorithm conforms to the closed-loop sending policy defined in Appendix C.2.2.2 of [RFC4695].
送信者がRTCPの受信レポートを受信すると、それはRJSSトリミングアルゴリズムを実行します。トリミングアルゴリズムはRJSSの部分を切り取るためにEHSNRを使用しています。このように、このアルゴリズムは、後続のRTPパケットで送信され、回復ジャーナルのサイズが小さくなります。アルゴリズムは、[RFC4695]の付録C.2.2.2で定義された閉ループ送信ポリシーに準拠します。
The trimming algorithm relies on the following observation: if the EHSNR indicates that a packet with sequence number K has been received, MIDI commands sent in packets with sequence numbers J <= K may be removed from the RJSS without violating the closed-loop policy.
トリミングアルゴリズムは、以下の観察に依存する：EHSNRシーケンス番号Jのパケットで送信されたMIDIコマンドは、<= Kが閉ループポリシーに違反することなくRJSSから除去することができる、配列番号Kを有するパケットを受信したことを示している場合。
To begin the trimming algorithm, the sender extracts the EHSNR field from the receiver report and adjusts the EHSNR to reflect the sequence number extension prefix of the sender. Then, the sender compares the adjusted EHSNR value with seqnum fields at each level of the RJSS, starting at the top level.
トリミングアルゴリズムを開始するには、送信者は受信レポートからEHSNRフィールドを抽出し、送信者のシーケンス番号の拡張子のプレフィックスを反映するためにEHSNRを調整します。次に、送信者は、最上位レベルで開始し、RJSSの各レベルでSEQNUMフィールドで調整EHSNR値とを比較します。
Levels whose seqnum is less than or equal to the adjusted EHSNR are trimmed, by setting the seqnum to zero. If necessary, the jheader[] and cheader[] arrays above the trimmed level are adjusted to match the new journal layout. The checkpoint packet sequence number field of jheader[] is updated to match the EHSNR.
そのSEQNUM以下調整EHSNRに等しいレベルがゼロにSEQNUMを設定することで、トリミングされます。必要に応じて、トリミングされたレベル以上jheader []とcheader []アレイは、新しいジャーナル・レイアウトと一致するように調整されます。 jheader []のチェックポイントパケットシーケンス番号フィールドはEHSNRと一致するように更新されます。
At the leaf level, the sender trims the size of the variable-length chaptern[] and chapterc[] bitfields. The sender loops through the note_seqnum[] or control_seqnum[] array and removes chaptern[] or chapterc[] logs whose seqnum value is less than or equal to the adjusted EHSNR. The sender sets the associated bitfield_ptr[] to null and updates the LENGTH field of the associated cheader[] bitfield.
リーフ・レベルでは、送信者は、可変長chaptern []の大きさをトリムし、[]ビットフィールドをchapterc。送信者は、[]またはcontrol_seqnum []配列note_seqnumをループし、そのSEQNUM値未満又は調整EHSNRに等しいchaptern []またはchapterc []ログを除去します。送信者は、関連bitfield_ptr []はnullに設定し、関連cheader []ビットフィールドの長さフィールドを更新します。
Note that the trimming algorithm does not add information to the checkpoint history. As a consequence, the trimming algorithm does not clear the S bit (and for chaptern[], the B bit) of any recovery journal bitfield. As a second consequence, the trimming algorithm does not set RJSS seqnum variables to the EHSNR value.
トリミングアルゴリズムはチェックポイント歴史に情報を追加しないことに注意してください。その結果、トリミングアルゴリズムは、任意の回復ジャーナルビットフィールドのSビット（及びchaptern []、Bビットのための）をクリアしません。二その結果、トリミングアルゴリズムはEHSNR値にRJSS SEQNUM変数を設定しません。
For pedagogical purposes, the recovery journal sender we describe has been simplified in several ways. In practice, an implementation would use enhanced versions of the traversing, updating, and trimming algorithms presented in Sections 5.2-5.4.
教育的な目的のために、我々は記述回復ジャーナル送信者は、いくつかの方法で簡素化されました。実際には、実装がトラバース、更新の強化バージョン、およびセクション5.2から5.4に提示トリミングアルゴリズムを使用します。
In this section, we discuss receiver implementation issues.
このセクションでは、受信機実装上の問題を議論します。
To begin, we imagine that an ideal network carries the RTP stream. Packets are never lost or reordered, and the end-to-end latency is constant. In addition, we assume that all commands coded in the MIDI list of a packet share the same timestamp (an assumption coded by the "rtp_ptime" and "rtp_maxptime" values in Figures 1-2; see Appendix C.4.1 of [RFC4695] for details).
開始するには、我々は理想的なネットワークがRTPストリームを運ぶことを想像してみてください。パケットは失われていないか、並べ替え、およびエンドツーエンドの待ち時間は一定であるん。以下のために[RFC4695]の付録C.4.1を参照;また、我々は、（図1-2に「rtp_ptime」および「rtp_maxptime」値によって符号化された仮定すべてのコマンドは、パケットシェアのMIDIリスト同じタイムスタンプに符号化されたと仮定します詳細）。
Under these conditions, a simple algorithm may be used to render a high-quality performance. Upon receipt of an RTP packet, the receiver immediately executes the commands coded in the MIDI command section of the payload. Commands are executed in the order of their appearance in the MIDI list. The command timestamps are ignored.
これらの条件下では、単純なアルゴリズムは、高品質のパフォーマンスをレンダリングするために使用することができます。 RTPパケットを受信すると、受信機は直ちにペイロードのMIDIコマンドのセクションでコード化されたコマンドを実行します。コマンドはMIDIリストでの出現順に実行されます。コマンドのタイムスタンプは無視されます。
Unfortunately, this simple algorithm breaks down once we relax our assumptions about the network and the MIDI list:
我々はネットワークとMIDIのリストについて、当社の仮定を緩和たら残念ながら、この単純なアルゴリズムが破綻します：
1. If we permit lost and reordered packets to occur in the network, the algorithm may produce unrecoverable rendering artifacts, violating the mandate defined in Section 4 of [RFC4695].
1.私たちは、ネットワークで発生することが失われたと並べ替えパケットを許可する場合、アルゴリズムは[RFC4695]のセクション4で定義された任務に違反し、回復不能なレンダリングアーティファクトを生成することができます。
2. If we permit the network to exhibit variable latency, the algorithm modulates the network jitter onto the rendered MIDI command stream.
2.私たちは、可変遅延を発揮するためにネットワークを許可した場合、アルゴリズムは、レンダリングされたMIDIコマンドストリームにネットワークジッタを変調します。
3. If we permit a MIDI list to code commands with different timestamps, the algorithm adds temporal jitter to the rendered performance, as it ignores MIDI list timestamps.
3.私たちは、異なるタイムスタンプでコードコマンドにMIDIリストを許可する場合は、MIDIリストのタイムスタンプを無視して、アルゴリズムは、レンダリングパフォーマンスに時間的ジッタを追加します。
In this section, we discuss interactive receiver design techniques under these relaxed assumptions. Section 6.1 describes a receiver design for high-performance Wide Area Networks (WANs), and Section 6.2 discusses design issues for other types of networks.
このセクションでは、我々はこれらのリラックスした仮定の下で、対話型の受信機設計技術を議論します。 6.1節では、高性能ワイドエリアネットワーク（WAN）のための受信機の設計について説明し、6.2節は、他のタイプのネットワークのための設計上の問題について説明します。
The Network Musical Performance (NMP) system [NMP] is an interactive performance application that uses an early version of the RTP MIDI payload format. NMP is designed for use between universities within the State of California, which use the high-performance CalREN2 network.
ネットワーク演奏（NMP）システム[NMP]はRTP MIDIペイロード形式の初期のバージョンを使用する対話型パフォーマンス・アプリケーションです。 NMPは、高性能CalREN2ネットワークを使用し、カリフォルニア州内の大学との間の使用のために設計されています。
In the NMP system, network artifacts may affect how a musician hears the performances of remote players. However, the network does not affect how a musician hears his own performance.
NMPシステムでは、ネットワークのアーティファクトは、ミュージシャンがリモートプレーヤーの演奏を聞いてどのように影響する場合があります。しかし、ネットワークは、ミュージシャンが自分のパフォーマンスを聞く方法には影響しません。
Several aspects of CalREN2 network behavior (as measured in 2001 timeframe, as documented in [NMP]) guided the NMP system design:
CalREN2ネットワーク動作のいくつかの側面は、（[NMP]に記載されているように、2001時間枠内で測定される）NMPシステムの設計を導きました。
o The median symmetric latency (1/2 the round-trip time) of packets sent between network sites is comparable to the acoustic latency between two musicians located in the same room. For example, the latency between Berkeley and Stanford is 2.1 ms, corresponding to an acoustic distance of 2.4 feet (0.72 meters). These campuses are 40 miles (64 km) apart. Preserving the benefits of the underlying network latency at the application level was a key NMP design goal.
ネットワークサイト間で送信されるパケットのメジアン対称レイテンシ（1/2ラウンドトリップ時間）O同じ部屋にある2人のミュージシャンの間の音響待ち時間と同等です。例えば、バークレーとスタンフォード大学との間の待ち時間は、2.4フィート（0.72メートル）の音響距離に相当する、2.1ミリ秒です。これらのキャンパスは40マイル（64キロ）離れています。アプリケーションレベルでの基盤となるネットワーク遅延の利点を維持することが重要なNMPの設計目標でした。
o For most times of day, the nominal temporal jitter is quite short. For Berkeley-Stanford, the standard deviation of the round-trip time was under 200 microseconds.
O一日のほとんどの時間については、公称時間的ジッタはかなり短いです。バークレー - スタンフォードの場合、往復時間の標準偏差は200マイクロ秒未満でした。
o For most times of day, a few percent (0-4%) of the packets sent arrive significantly late (> 40 ms), probably due to a queuing transient somewhere in the network path. More rarely (< 0.1%), a packet is lost during the transient.
O一日のほとんどの時間のために、送信されたパケットの数パーセント（0-4％）は、ネットワーク経路のどこかにおそらくキューイング過渡に、大幅に遅れて（> 40ミリ秒）に到着します。より稀（<0.1％）、パケットは過渡時に失われることはありません。
o At predictable times during the day (before lunchtime, at the end of the workday, etc.), network performance deteriorates (10-20% late packets) in a manner that makes the network unsuitable for low-latency interactive use.
日中の予測可能な時間においてO（昼食前、等、就業日の終了時に）、ネットワーク性能は、低遅延インタラクティブ使用のためのネットワークが不適当な方法で（10-20％遅いパケット）を劣化させます。
o CalREN2 has deeply over-provisioned bandwidth, relative to MIDI bandwidth usage.
O CalREN2は深くMIDI帯域幅の使用量に比べて帯域幅を、オーバープロビジョニングされています。
The NMP sender freely uses network bandwidth to improve the performance experience. As soon as a musician generates a MIDI command, an RTP packet coding the command is sent to the other players. This sending algorithm reduces latency at the cost of bandwidth. In addition, guard packets (described in Section 4.2) are sent at frequent intervals to minimize the impact of packet loss.
NMPの送信者が自由にパフォーマンス体験を改善するために、ネットワーク帯域幅を使用しています。すぐにミュージシャンはMIDIコマンドを生成して、コマンドをコーディングRTPパケットは、他のプレイヤーに送信されます。この送信アルゴリズムは、帯域幅のコストで待ち時間を短縮します。また、（4.2節を参照）ガード・パケットは、パケットロスの影響を最小化するために頻繁に送信されます。
The NMP receiver maintains a model of the stream and uses this model as the basis of its resiliency system. Upon receipt of a packet, the receiver predicts the RTP sequence number and the RTP timestamp (with error bars) of the packet. Under normal network conditions, about 95% of received packets fit the predictions [NMP]. In this common case, the receiver immediately executes the MIDI command coded in the packet.
NMP受信機は、ストリームのモデルを維持し、その弾性システムの基礎としてこのモデルを使用します。パケットを受信すると、受信機は、パケットの（エラーバー付き）RTPシーケンス番号及びRTPのタイムスタンプを予測します。通常のネットワーク条件の下で、受信したパケットの約95％が予測[NMP]に合います。この一般的な場合では、受信機は直ちにパケットに符号化されたMIDIコマンドを実行します。
Note that the NMP receiver does not use a playout buffer; the design is optimized for lowest latency at the expense of command jitter. Thus, the NMP receiver design does not completely satisfy the interoperability text in Appendix C.7.2 of [RFC4695], which requires that receivers in network musical performance applications be capable of using a playout buffer.
NMP受信機が再生バッファを使用しないことに留意されたいです。デザインは、コマンドジッタを犠牲にして最小の遅延のために最適化されています。したがって、NMP受信機の設計は、完全にネットワークの音楽パフォーマンスアプリケーションにおける受信機が再生バッファを使用することが可能であることを必要とする、[RFC4695]の付録C.7.2における相互運用性のテキストを満たしていません。
Occasionally, an incoming packet fits the sequence number prediction, but falls outside the timestamp prediction error bars (see Appendix B of [NMP] for timestamp model details). In most cases, the receiver still executes the command coded in the packet. However, the receiver discards NoteOn commands with non-zero velocity. By discarding late commands that sound notes, the receiver prevents "straggler notes" from disturbing a performance. By executing all other late commands, the receiver quiets "soft stuck notes" immediately and updates the state of the MIDI system.
時々、着信パケットは、シーケンス番号の予測に適合するが、（タイムスタンプモデルの詳細については、[NMP]の付録Bを参照）、タイムスタンプの予測誤差バーから外れます。ほとんどの場合、受信機は、まだパケットでコード化されたコマンドを実行します。しかしながら、受信機は、NoteOnがゼロ速度でコマンドを破棄する。音符を鳴らす後半のコマンドを破棄することにより、受信機は、性能を乱すから「落伍者の注意」を防ぐことができます。他のすべての後半のコマンドを実行することにより、受信機はすぐに「ソフトスタックの注意事項」をquietsとMIDIシステムの状態を更新します。
More rarely, an incoming packet does not fit the sequence number prediction. The receiver keeps track of the highest sequence number received in the stream and predicts that an incoming packet will have a sequence number one greater than this value. If the sequence number of an incoming packet is greater than the prediction, a packet loss has occurred. If the sequence number of the received packet is less than the prediction, the packet has been received out of order. All sequence number calculations are modulo 2^16 and use standard methods (described in [RFC3550]) to avoid tracking errors during rollover.
まれに、着信パケットは、シーケンス番号予測に適合しません。受信機は、ストリームで受信された最大のシーケンス番号を追跡し、着信パケットシーケンス番号この値よりも大きいものを持っているだろうと予測しています。着信パケットのシーケンス番号が予測よりも大きい場合、パケットロスが発生しています。受信したパケットのシーケンス番号が予測よりも小さい場合は、パケットの順序が受信されています。すべてのシーケンス番号の計算は、モジュロ2 ^ 16であり、ロールオーバー時にトラッキングエラーを回避するために、（[RFC3550]に記載されている）標準的な方法を使用します。
If a packet loss has occurred, the receiver examines the journal section of the received packet and uses it to gracefully recover from the loss episode. We describe this recovery procedure in Section 7 of this memo. The recovery process may result in the execution of one or more MIDI commands. After executing the recovery commands, the receiver processes the MIDI command encoded in the packet using the timestamp model test described above.
パケットロスが発生した場合、受信機は、受信したパケットのジャーナル部を調べて、優雅に損失エピソードから回復するためにそれを使用しています。私たちは、このメモのセクション7で、この回復手順を説明します。回復プロセスは、1つまたは複数のMIDIコマンドの実行をもたらすことができます。回復コマンドを実行した後、受信機は、上述したタイムスタンプモデルの試験を使用してパケットに符号化されたMIDIコマンドを処理します。
If a packet is received out of order, the receiver ignores the packet. The receiver takes this action because a packet received out of order is always preceded by a packet that signalled a loss event. This loss event triggered the recovery process, which may have executed recovery commands. The MIDI command coded in the out-of-order packet might, if executed, duplicate these recovery commands, and this duplication might endanger the integrity of the stream. Thus, ignoring the out-of-order packet is the safe approach.
パケットの順序が受信された場合、受信機はパケットを無視します。順不同で受信したパケットは、常に損失イベントを合図パケットが先行しているので、受信機は、このアクションを実行します。この損失イベントは、回復コマンドを実行している可能性が回復プロセスをトリガしました。アウトオブオーダーパケットにコード化されたMIDIコマンドは、実行された場合、これらの回復コマンドを複製するかもしれないし、この重複は、ストリームの整合性を危険にさらす可能性があります。このように、アウトオブオーダーパケットを無視することは安全なアプローチです。
The NMP receiver targets a network with a particular set of characteristics: low nominal jitter, low packet loss, and occasional outlier packets that arrive very late. In this section, we consider how networks with different characteristics impact receiver design.
低い公称ジッタ、低パケット損失、および非常に遅れて到着する時折異常値パケット：NMP受信機は、特性の特定のセットを有するネットワークを標的とします。このセクションでは、異なる特性を持つネットワークが受信機の設計に与える影響を検討します。
Networks with significant nominal jitter cannot use the buffer-free receiver design described in Section 6.1. For example, the NMP system performs poorly for musicians that use dial-up modem connections, because the buffer-free receiver design modulates modem jitter onto the performances. Receivers designed for high-jitter networks should use a substantial playout buffer. References [GRAME] and [CCRMA] describe how to use playout buffers in latency-critical applications.
大きな公称ジッタとのネットワークは、6.1節で説明したバッファのない受信機の設計を使用することはできません。バッファを含まない受信機設計は、性能上のモデム・ジッタを調節するため、例えば、NMPシステムは、ダイヤルアップモデム接続を使用ミュージシャンのために不十分行います。高ジッタ・ネットワーク用に設計された受信機はかなりの再生バッファを使用する必要があります。参考文献[GRAME]と[CCRMA]レイテンシークリティカルなアプリケーションにプレイアウト・バッファを使用する方法について説明します。
Receivers intended for use on Local Area Networks (LANs) face a different set of issues. A dedicated LAN fabric built with modern hardware is in many ways a predictable environment. The network problems addressed by the NMP receiver design (packet loss and outlier late packets) might only occur under extreme network overload conditions.
ローカルエリアネットワーク（LAN）上での使用を目的とレシーバは、問題の異なるセットに直面しています。最新のハードウェアで構築された専用LANファブリックは、多くの方法で予測可能な環境です。 NMPの受信機設計（パケット損失や外れ値の遅いパケット）によって対処ネットワークの問題は、極端なネットワークの過負荷条件下で発生する可能性があります。
Systems designed for this environment may choose to configure streams without the recovery journal system (Appendix C.2.1 of [RFC4695]). Receivers may also wish to forego or simplify the detection of outlier late packets. Receivers should monitor the RTP sequence numbers of incoming packets to detect network unreliability.
このような環境のために設計されたシステムは回復ジャーナルシステム（[RFC4695]の付録C.2.1）せずにストリームを設定することもできます。受信機はまた、見合わせるか、外れ値後半パケットの検出を簡素化することを望むかもしれません。レシーバは、ネットワークの信頼性の欠如を検出するために、着信パケットのRTPシーケンス番号を監視する必要があります。
However, in some respects, LAN applications may be more demanding than WAN applications. In LAN applications, musicians may be receiving performance feedback from audio that is rendered from the stream. The tolerance a musician has for latency and jitter in this context may be quite low.
しかし、いくつかの点で、LANアプリケーションは、WANアプリケーションよりも厳しいかもしれません。 LANアプリケーションでは、音楽家は、ストリームからレンダリングされたオーディオからの性能フィードバックを受信することができます。ミュージシャンは、この文脈での遅延とジッタを持っ公差はかなり低いかもしれません。
To reduce the perceived jitter, receivers may use a small playout buffer (in the range of 100us to 2ms). The buffer adds a small amount of latency to the system, which may be annoying to some players. Receiver designs should include buffer tuning parameters to let musicians adjust the tradeoff between latency and jitter.
知覚されるジッタを低減するために、受信機は、（2ミリ秒の100USの範囲の）小再生バッファを使用することができます。バッファは、いくつかのプレイヤーに迷惑かもしれシステムにレイテンシーの少量を追加します。受信機設計は、ミュージシャンが、待ち時間とジッタとの間のトレードオフを調整できるように、バッファのチューニングパラメータを含める必要があります。
In this section, we describe the recovery algorithm used by the NMP receiver [NMP]. In most ways, the recovery techniques we describe are generally applicable to interactive receiver design. However, a few aspects of the design are specialized for the NMP system:
このセクションでは、我々は、NMP受信[NMP]で使用される回復アルゴリズムを記述する。ほとんどの方法では、我々は記述回復技術は、一般的に対話型の受信機の設計にも適用可能です。しかし、設計のいくつかの側面はNMPシステムに特化されています。
o The recovery algorithm covers a subset of the MIDI command set. MIDI Systems (0xF), Poly Aftertouch (0xA), and Channel Aftertouch (0xD) commands are not protected, and Control Change (0xB) command protection is simplified. Note commands for a particular note number are assumed to follow the typical NoteOn->NoteOff->NoteOn ->NoteOff pattern. The cm_unused and ch_never parameters in Figures 1-2 specify this coverage.
O回復アルゴリズムは、MIDIコマンドセットのサブセットをカバーしています。 MIDIシステム（0xFの）、ポリアフタータッチ（0xAが）、およびチャンネル・アフタータッチ（0xDの）コマンドが保護されていない、とコントロールチェンジ（0xB）コマンド保護が簡素化されます。 > NoteOffパターン - 特定のノートナンバーのためのメモコマンドは典型的NoteOn-> NoteOff-> NoteOnに従うものとします。図1-2 cm_unusedとch_neverパラメータがこの範囲を指定します。
o The NMP system does not use a playout buffer. Therefore, the recovery algorithm does not address interactions with a playout buffer.
O NMPシステムは、再生バッファを使用しません。したがって、回復アルゴリズムは、再生バッファとの相互作用には対応していません。
At a high level, the receiver algorithm works as follows. Upon detection of a packet loss, the receiver examines the recovery journal of the packet that ends the loss event. If necessary, the receiver executes one or more MIDI commands to recover from the loss.
次のようにハイレベルでは、受信機アルゴリズムが動作します。パケットロスを検出すると、受信機は、損失イベントを終了し、パケットの回復ジャーナルを調べます。必要であれば、受信機は、一つ以上のMIDIが損失から回復するためのコマンドを実行します。
To prepare for recovery, a receiver maintains a data structure, the Recovery Journal Receiver Structure (RJRS). The RJRS codes information about the MIDI commands the receiver executes (both incoming stream commands and self-generated recovery commands). At the start of the stream, the RJRS is initialized to code that no commands have been executed. Immediately after executing a MIDI command, the receiver updates the RJRS with information about the command.
回復のために準備するために、受信機はデータ構造を維持し、回復ジャーナルレシーバ構造（RJRS）。 MIDI約RJRSコード情報は、受信機を実行する（着信ストリームコマンドと自己生成復旧コマンドの両方）を指示します。ストリームの開始時に、RJRSには、コマンドが実行されていないことをコーディングする初期化されます。すぐにMIDIコマンドを実行した後、受信機は、コマンドに関する情報をRJRSを更新します。
We now describe the recovery algorithm in detail. We begin with two definitions that classify loss events. These definitions assume that the packet that ends the loss event has RTP sequence number I.
私たちは今、詳細に回復アルゴリズムを記述します。当社は、損失事象を分類する二つの定義で始まります。これらの定義は、損失イベントを終了したパケットは、RTPシーケンス番号Iを持っていることを前提としてい
o Single-packet loss. A single-packet loss occurs if the last packet received before the loss event (excluding out-of-order packets) has the sequence number I-2 (modulo 2^16).
Oシングルパケット損失。最後のパケットが（アウトオブオーダーパケットを除く）損失イベントの前に受信された場合、単一のパケット損失が発生するシーケンス番号I-2（モジュロ2 ^ 16）を有しています。
o Multi-packet loss. A multi-packet loss occurs if the last packet received before the loss event (excluding out-of-order packets) has a sequence number less than I-2 (modulo 2^16).
Oマルチパケット損失。最後のパケットが受信された場合、マルチパケット損失は、（アウトオブオーダーパケットを除く）損失イベントの前に発生したI-2（モジュロ2 ^ 16）よりも小さいシーケンス番号を有します。
Upon detection of a packet loss, the recovery algorithm examines the recovery journal header (Figure 8 of [RFC4695]) to check for special cases:
パケットロスを検出すると、回復アルゴリズムは、特別な場合をチェックするために回復ジャーナルヘッダ（[RFC4695]の図8）を調べます。
o If the header field A is 0, the recovery journal has no channel journals, so no action is taken.
ヘッダフィールドAが0の場合、O、回復ジャーナルにはチャンネルジャーナルを有していないので、何もしません。
o If a single-packet loss has occurred, and if the header S bit is 1, the lost packet has a MIDI command section with an empty MIDI list. No action is taken.
O場合、単一のパケット損失が発生し、ヘッダのSビットが1である場合、失われたパケットが空のMIDIリストとMIDIコマンド部を有しています。アクションはとられません。
If these checks fail, the algorithm parses the recovery journal body. For each channel journal (Figure 9 in [RFC4695]) in the recovery journal, the receiver compares the data in each chapter journal (Appendix A of [RFC4695]) to the RJRS data for the chapter. If the data are inconsistent, the algorithm infers that MIDI commands related to the chapter journal have been lost. The recovery algorithm executes MIDI commands to repair this loss and updates the RJRS to reflect the repair.
これらのチェックが失敗した場合、アルゴリズムは回復ジャーナル本体を解析します。回復ジャーナル内の各チャネルジャーナル（[RFC4695]で図9）の場合、受信機は、章のためRJRSデータに各章ジャーナル（[RFC4695]の付録A）のデータを比較します。データが矛盾している場合、アルゴリズムはMIDIが失われた章ジャーナルに関連するコマンドと推定します。回復アルゴリズムは、MIDIはこの損失を修復するコマンドや修理を反映するためにRJRSを更新し実行します。
For single-packet losses, the receiver skips channel and chapter journals whose S bits are set to 1. For multi-packet losses, the receiver parses each channel and chapter journal and checks for inconsistency.
単一パケット損失のために、受信機は、そのSビットがマルチパケット損失のために1に設定されているチャネルと章ジャーナルをスキップし、受信機は、矛盾のために各チャネルと章ジャーナルとチェックを解析します。
In the sections that follow, we describe the recovery steps that are specific to each chapter journal. We cover 4 chapter journal types: P (Program Change, 0xC), C (Control Change, 0xB), W (Pitch Wheel, 0xE), and N (Note, 0x8 and 0x9). Chapters are parsed in the order of their appearance in the channel journal (P, then W, then N, then C).
以下のセクションでは、各章のジャーナルに固有の回復手順を説明します。 P（プログラムチェンジ、から0xC）、C（コントロールチェンジ、0xB）、W（ピッチホイール、0xEの）、およびN（注、0x8のと0x9）：私たちは、4章ジャーナルの種類をカバーしています。チャプタは、チャネルジャーナル（P、次いで、W、次いでN、次にC）におけるそれらの出現順に解析されます。
The sections below reference the C implementation of the RJRS shown in Figure 10. This structure is hierarchical, reflecting the recovery journal architecture. At the leaf level, specialized data structures (jrec_chapterw, jrec_chaptern, jrec_chapterc, and jrec_chapterp) code state variables for a single chapter journal type. A mid-level structure (jrec_channel) represents a single MIDI channel, and a top-level structure (jrec_stream) represents the entire MIDI stream.
基準以下のセクションでは、この構造を図10に示すRJRSのC実装は回復ジャーナル・アーキテクチャを反映して、階層的です。リーフレベルで、専門的なデータ構造（jrec_chapterw、jrec_chaptern、jrec_chapterc、およびjrec_chapterp）単一の章ジャーナルタイプのコードの状態変数。中間レベルの構造（jrec_channel）は、単一のMIDIチャネルを表し、そしてトップレベル構造（jrec_stream）は全体のMIDIストリームを表します。
typedef unsigned char uint8; /* must be 1 octet */
typedef unsigned short uint16; /* must be 2 octets */
typedef unsigned long uint32; /* must be 4 octets */
/*****************************************************************/
/* leaf level of hierarchy: Chapter W, Appendix A.5 of [RFC4695] */
/*****************************************************************/
typedef struct jrec_chapterw { /* MIDI Pitch Wheel (0xE) */
uint16 val; /* most recent 14-bit wheel value */
} jrec_chapterw;
} jrec_chapterw。
/*****************************************************************/
/* leaf level of hierarchy: Chapter N, Appendix A.6 of [RFC4695] */
/*****************************************************************/
typedef struct jrec_chaptern { /* Note commands (0x8, 0x9) */
/* arrays of length 128 --> one for each MIDI Note number */
uint32 time[128]; /* exec time of most recent NoteOn */
uint32 extseq[128]; /* extended seqnum for that NoteOn */
uint8 vel[128]; /* NoteOn velocity (0 for NoteOff) */
} jrec_chaptern;
} jrec_chaptern。
/*****************************************************************/
/* leaf level of hierarchy: Chapter C, Appendix A.3 of [RFC4695] */
/*****************************************************************/
typedef struct jrec_chapterc { /* Control Change (0xB) */
/* array of length 128 --> one for each controller number */
uint8 value[128]; /* Chapter C value tool state */
uint8 count[128]; /* Chapter C count tool state */
uint8 toggle[128]; /* Chapter C toggle tool state */
} jrec_chapterc;
} jrec_chapterc。
Figure 10. Recovery Journal Receiving Structure (part 1)
図10.回復ジャーナル受け構造（パート1）
/*****************************************************************/
/* leaf level of hierarchy: Chapter P, Appendix A.2 of [RFC4695] */
/*****************************************************************/
typedef struct jrec_chapterp { /* MIDI Program Change (0xC) */
uint8 prognum; /* most recent 7-bit program value */
uint8 prognum_qual; /* 1 once first 0xC command arrives */
uint8 bank_msb; /* most recent Bank Select MSB value */
uint8 bank_msb_qual; /* 1 once first 0xBn 0x00 arrives */
uint8 bank_lsb; /* most recent Bank Select LSB value */
uint8 bank_lsb_qual; /* 1 once first 0xBn 0x20 arrives */
} jrec_chapterp;
} jrec_chapterp。
/***************************************************/
/* second-level of hierarchy, for MIDI channels */
/***************************************************/
typedef struct jrec_channel {
typedefは構造体jrec_channel {
jrec_chapterp chapterp; /* Program Change (0xC) info */
jrec_chapterc chapterc; /* Control Change (0xB) info */
jrec_chapterw chapterw; /* Pitch Wheel (0xE) info */
jrec_chaptern chaptern; /* Note (0x8, 0x9) info */
} jrec_channel;
} jrec_channel。
/***********************************************/
/* top level of hierarchy, for the MIDI stream */
/***********************************************/
typedef struct jrec_stream {
typedefは構造体jrec_stream {
jrec_channel channels[16]; /* index is MIDI channel */
} jrec_stream;
} jrec_stream。
Figure 10. Recovery Journal Receiving Structure (part 2)
図10.回復ジャーナル受け構造（パート2）
Chapter W of the recovery journal protects against the loss of MIDI Pitch Wheel (0xE) commands. A common use of the Pitch Wheel command is to transmit the current position of a rotary "pitch wheel" controller placed on the side of MIDI piano controllers. Players use the pitch wheel to dynamically alter the pitch of all depressed keys.
回復ジャーナルのW章は、MIDIピッチホイール（から0xE）コマンドの損失を防ぐことができます。ピッチホイール命令の一般的な用途は、MIDIピアノコントローラの側に配置されたロータリー「ピッチホイール」コントローラの現在位置を送信することです。プレイヤーは、すべて動的押下されたキーのピッチを変更するピッチホイールを使用しています。
The NMP receiver maintains the jrec_chapterw structure (Figure 10) for each voice channel in jrec_stream to code pitch wheel state information. In jrec_chapterw, val holds the 14-bit data value of the most recent Pitch Wheel command that has arrived on a channel. At the start of the stream, val is initialized to the default pitch wheel value (0x2000).
NMP受信機は、コードピッチ車輪状態情報にjrec_streamにおける各音声チャンネルのためjrec_chapterw構造（図10）を維持します。 jrec_chapterwでは、valがチャネルに到着した最新のピッチホイール命令の14ビットのデータ値を保持しています。ストリームの開始時に、valが、デフォルトのピッチホイール値（0x2000番地）に初期化されます。
At the end of a loss event, a receiver may find a Chapter W (Appendix A.5 in [RFC4695]) bitfield in a channel journal. This chapter codes the 14-bit data value of the most recent MIDI Pitch Wheel command in the checkpoint history. If the Chapter W and jrec_chapterw pitch wheel values do not match, one or more commands have been lost.
損失事象の終了時に、受信機は、チャネルジャーナルにビットフィールド章W（[RFC4695]の付録A.5）を見つけることができます。チェックポイント歴史の中でこの章では、コードの最新のMIDIピッチホイール命令の14ビットのデータ値を。章のWとjrec_chapterwピッチ・ホイールの値が一致しない場合は、1つ以上のコマンドが失われています。
To recover from this loss, the NMP receiver immediately executes a MIDI Pitch Wheel command on the channel, using the data value coded in the recovery journal. The receiver then updates the jrec_chapterw variables to reflect the executed command.
この損失から回復するために、NMP受信機は直ちに回復ジャーナルで符号化されたデータ値を使用して、チャネル上でMIDIピッチホイール命令を実行します。受信機は、その後、実行したコマンドを反映するためにjrec_chapterw変数を更新します。
Chapter N of the recovery journal protects against the loss of MIDI NoteOn (0x9) and NoteOff (0x8) commands. If a NoteOn command is lost, a note is skipped. If a NoteOff command is lost, a note may sound indefinitely. Recall that NoteOn commands with a velocity value of 0 have the semantics of NoteOff commands.
回復ジャーナルの章Nは、MIDI NoteOn（0x9）とNoteOff（0x8の）コマンドの損失を防ぐことができます。 NoteOnコマンドが失われた場合、ノートはスキップされます。 NoteOffコマンドが失われた場合、ノートは無限に聞こえるかもしれません。 0のベロシティ値を持つことNoteOnコマンドを思い出しNoteOffコマンドの意味を持っています。
The recovery algorithms in this section only work for MIDI sources that produce NoteOn->NoteOff->NoteOn->NoteOff patterns for a note number. Piano keyboard and drum pad controllers produce these patterns. MIDI sources that use NoteOn->NoteOn->NoteOff->NoteOff patterns for legato repeated notes, such as guitar and wind controllers, require more sophisticated recovery strategies. Chapter E (not used in this example) supports recovery algorithms for atypical note command patterns (see Appendix A.7 of [RFC4695] for details).
このセクションの回復アルゴリズムは、ノート番号のパターンNoteOff NoteOn-> NoteOff-> NoteOn->を生成MIDIソースのために働きます。ピアノ、キーボード、ドラムパッドコントローラは、これらのパターンを作り出します。レガートのためのパターンNoteOff NoteOn-> NoteOn-> NoteOff->を使用してMIDI源は、ギターや風コントローラなどの注意事項を、繰り返し、より高度な回復戦略が必要。章Eは、（この例では使用されません）（詳細については、[RFC4695]の付録A.7を参照）非定型ノートコマンドパターンの回復アルゴリズムをサポートしています。
The NMP receiver maintains a jrec_chaptern structure (Figure 10) for each voice channel in jrec_stream to code note-related state information. State is kept for each of the 128 note numbers on a channel, using three arrays of length 128 (vel[], seq[], and time[]). The arrays are initialized to zero at the start of a stream.
NMP受信機は、コードノート関連状態情報にjrec_streamにおける各音声チャンネルのためjrec_chaptern構造（図10）を維持します。状態は、長さ128の3つの配列（VEL []、配列[]、及び時間[]）を使用して、チャネル128のノートナンバのそれぞれに保持されます。アレイは、ストリームの開始時にゼロに初期化されます。
The vel[n] array element holds information about the most recent note command for note number n. If this command is a NoteOn command, vel[n] holds the velocity data for the command. If this command is a NoteOff command, vel[n] is set to 0.
VEL [n]は、配列の要素は、ノート番号nの最新のノートコマンドに関する情報を保持しています。このコマンドはNoteOnコマンドである場合、VEL [n]はコマンドの速度データを保持します。このコマンドは、NoteOffコマンドである場合、VEL [n]は0に設定されています。
The time[n] and extseq[n] array elements code information about the most recently executed NoteOn command. The time[n] element holds the execution time of the command, referenced to the local timebase of the receiver. The extseq[n] element holds the RTP extended sequence number of the packet associated with the command. For incoming stream commands, extseq[n] codes the packet of the associated MIDI list. For commands executed to perform loss recovery, extseq[n] codes the packet of the associated recovery journal.
時間[n]と直前に実行NoteOnコマンドについてextseq [n]の配列要素コード情報。時間[n]の要素は、受信機のローカルタイムベースを基準に、コマンドの実行時間を保持します。 extseq [n]の要素は、コマンドに関連するパケットのRTP拡張シーケンス番号を保持します。着信ストリームコマンドの、extseq [n]の符号関連MIDIリストのパケット。損失回復を実行するために実行したコマンドのため、extseq [n]の符号関連回復ジャーナルのパケット。
The Chapter N recovery journal bitfield (Figure A.6.1 in [RFC4695]) consists of two data structures: a bit array coding recently sent NoteOff commands that are vulnerable to packet loss, and a note log list coding recently sent NoteOn commands that are vulnerable to packet loss.
章N回復ジャーナルビットフィールド（[RFC4695]で図A.6.1）は、2つのデータ構造からなる：最近パケット損失を受けやすいコマンドNoteOff送信符号化ビット列、及び最近受けやすいコマンドNoteOn送信ノートログリストコーディングをパケットロスへ。
At the end of a loss event, Chapter N recovery processing begins with the NoteOff bit array. For each set bit in the array, the receiver checks the corresponding vel[n] element in jrec_chaptern. If vel[n] is non-zero, a NoteOff command or a NoteOff->NoteOn->NoteOff command sequence has been lost. To recover from this loss, the receiver immediately executes a NoteOff command for the note number on the channel and sets vel[n] to 0.
損失イベントの最後には、章N回復処理はNoteOffビット列で始まります。アレイ内の各セットのビットのために、受信機は、対応するVEL [N] jrec_chapternの要素をチェックします。 VEL場合コマンドシーケンスNoteOff [n]は、NoteOffコマンド非ゼロであるか、またはA NoteOff-> NoteOn->が失われています。この損失から回復するために、受信機は直ちにチャネル上のノート番号のNoteOffコマンドを実行し、0にVEL [n]を設定します。
The receiver then parses the note log list, using the S bit to skip over "safe" logs in the single-packet loss case. For each at-risk note log, the receiver checks the corresponding vel[n] element.
次に、受信機は、単一のパケット損失の場合には「安全」なログをスキップするためにSビットを使用して、ノートログリストを解析します。各リスクのあるノートログため、受信機は、対応するVEL [n]の要素をチェックします。
If vel[n] is zero, a NoteOn command or a NoteOn->NoteOff->NoteOn command sequence has been lost. The receiver may execute the most recent lost NoteOn (to play the note) or may take no action (to skip the note), based on criteria we describe at the end of this section. Whether the note is played or skipped, the receiver updates the vel[n], time[n], and extseq[n] elements as if the NoteOn executed.
VEL [n]がゼロであれば、NoteOnコマンドまたはNoteOn-> NoteOff-> NoteOnコマンドシーケンスが失われています。受信機は、我々は、このセクションの最後に説明した基準に基づいて、（ノートを再生するために）最新の失われたNoteOnを実行したり、（ノートをスキップする）何もアクションを起こさないことがあります。音符が演奏またはスキップされたか否かを、受信機がvel [n]は、時間[N]、及びextseq NoteOnを実行した場合のように[n]の要素を更新します。
If vel[n] is non-zero, the receiver performs several checks to test if a NoteOff->NoteOn sequence has been lost.
VEL [n]は非ゼロである場合、受信機はNoteOff-> NoteOn配列が失われたかどうかをテストするために、いくつかのチェックを行います。
o If vel[n] does not match the note log velocity, the note log must code a different NoteOn command, and thus a NoteOff->NoteOn sequence has been lost.
VEL [n]は、ノートログ速度と一致しない場合はO、ノートログは異なるNoteOnコマンドをコーディングする必要があり、したがってNoteOff-> NoteOn配列が失われています。
o If extseq[n] is less than the (extended) checkpoint packet sequence numbed coded in the recovery journal header (Figure 8 of [RFC4695]), the vel[n] NoteOn command is not in the checkpoint history, and thus a NoteOff->NoteOn sequence has been lost.
O場合extseq [n]は、VEL [n]はNoteOnコマンドがチェックポイント履歴に回復ジャーナルヘッダ（[RFC4695]の図8）で符号化麻痺（拡張）チェックポイントパケットシーケンス未満ではないので、NoteOff - > NoteOnシーケンスが失われました。
o If the Y bit is set to 1, the NoteOn is musically "simultaneous" with the RTP timestamp of the packet. If time[n] codes a time value that is clearly not recent, a NoteOff->NoteOn sequence has been lost.
Yビットが1に設定されている場合は、O、NoteOnはパケットのRTPタイムスタンプと音楽「同時」です。時間[n]はコードはっきり最近でない時間値ならば、NoteOff-> NoteOnシーケンスが失われました。
If these tests indicate a lost NoteOff->NoteOn sequence, the receiver immediately executes a NoteOff command. The receiver decides if the most graceful action is to play or to skip the lost NoteOn, using the criteria we describe at the end of this section. Whether or not the receiver issues a NoteOn command, the vel[n], time[n], and extseq[n] arrays are updated as if it did.
これらのテストは失わNoteOff-> NoteOnシーケンスを示している場合、受信機はすぐにNoteOffコマンドを実行します。最も優雅なアクションがプレーするか、私たちは、このセクションの最後で説明した基準を使用して、失われたNoteOnをスキップする場合、受信機は、決定します。それがなかったかのように、受信機がNoteOnコマンドを発行するか否か、VEL [n]は、時間[N]、及びextseq [n]は配列が更新されます。
Note that the tests above do not catch all lost NoteOff->NoteOn commands. If a fast NoteOn->NoteOff->NoteOn sequence occurs on a note number with identical velocity values for both NoteOn commands, a lost NoteOff->NoteOn does not result in the recovery algorithm generating a NoteOff command. Instead, the first NoteOn continues to sound, to be terminated by the future NoteOff command. In practice, this (rare) outcome is not musically objectionable.
上記のテストはすべて失わNoteOff-> NoteOnコマンドをキャッチしていないことに注意してください。速いNoteOn-> NoteOff-> NoteOnシーケンスは両方NoteOnコマンドの同じ速度値でノートナンバーで発生した場合、失われたNoteOff-> NoteOnはNoteOffコマンドを生成回復アルゴリズムにはなりません。代わりに、最初のNoteOnコマンドNoteOff将来で終了する、音を続けています。実際には、この（まれ）な結果は、音楽的に不快ではありません。
The number of tests in this resiliency algorithm may seem excessive. However, in some common cases, a subset of the tests is not useful. For example, MIDI streams that assigns the same velocity value to all note events are often produced by inexpensive keyboards. The vel[n] tests are not useful for these streams.
この弾力性アルゴリズムにおけるテストの数が過剰に見えるかもしれません。しかし、いくつかの一般的な例では、テストのサブセットは有用ではありません。多くの場合、安価なキーボードによって生成されるすべてのノートイベントに同じ速度値を割り当て、例えば、MIDIストリーム。 VEL [n]の試験は、これらのストリームのために有用ではありません。
Finally, we discuss how the receiver decides whether to play or to skip a lost NoteOn command. The note log Y bit is set if the NoteOn is "simultaneous" with the RTP timestamp of the packet holding the note log. If Y is 0, the receiver does not execute a NoteOn command. If Y is 1, and if the packet has not arrived late, the receiver immediately executes a NoteOn command for the note number, using the velocity coded in the note log.
最後に、我々は、受信機がプレーするか、失われたNoteOnコマンドをスキップするかどうかを決定する方法について説明します。ノートログのYビットはNoteOnノート・ログを保持しているパケットのRTPタイムスタンプとの「同時」である場合に設定されています。 Yが0の場合、受信機は、NoteOnコマンドを実行しません。 Yは1であり、パケットが遅れて到着していない場合、受信機は直ちにノートログで符号化速度を使用して、ノートナンバためNoteOnコマンドを実行した場合。
Chapter C (Appendix A.3 in [RFC4695]) protects against the loss of MIDI Control Change commands. A Control Change command alters the 7-bit value of one of the 128 MIDI controllers.
章C（[RFC4695]の付録A.3）は、MIDIコントロールチェンジコマンドの損失を防ぐことができます。コントロールチェンジのコマンドは、128のMIDIコントローラーの1の7ビットの値を変更します。
Chapter C offers three tools for protecting a Control Change command: the value tool (for graded controllers such as sliders), the toggle tool (for on/off switches), and the count tool (for momentary-contact switches). Senders choose a tool to encode recovery information for a controller and encode the tool type along with the data in the journal (Figures A.3.2 and A.3.3 in [RFC4695]).
値のツール（オン/オフスイッチ用）（例えばスライダーなど段階的なコントローラ用）、トグルツール、および（瞬間的な接点スイッチ用）カウントツール：章Cはコントロールチェンジコマンドを保護するための3つのツールを提供しています。送信者は、コントローラの復旧情報を符号化し、ジャーナル（[RFC4695]で図A.3.2とA.3.3）におけるデータと共にツールタイプをエンコードするツールを選択します。
A few uses of Control Change commands are not solely protected by Chapter C. The protection of controllers 0 and 32 (Bank Select MSB and Bank Select LSB) is shared between Chapter C and Chapter P (Section 7.4).
コントロールチェンジコマンドのいくつかの用途はもっぱら章C.によってコントローラ0および32（バンクセレクトMSBとバンクセレクトLSB）章Cおよび章P（7.4節）の間で共有されているの保護を保護されていません。
Chapter M (Appendix A.4 of [RFC4695]) also protects the Control Change command. However, the NMP system does not use this chapter, because MPEG 4 Structured Audio [MPEGSA] does not use the controllers protected by this chapter.
章M（[RFC4695]の付録A.4）もコントロールチェンジコマンドを保護します。 MPEG 4は、構造化されたオーディオは、[MPEGSA]この章で保護されたコントローラを使用しないためしかし、NMPシステムは、この章を使用していません。
The Chapter C bitfield consists of a list of controller logs. Each log codes the controller number, the tool type, and the state value for the tool.
章Cのビットフィールドは、コントローラログのリストで構成されています。各ログコードコントローラ番号、ツールのタイプ、およびツールの状態値。
The NMP receiver maintains the jrec_chapterc structure (Figure 10) for each voice channel in jrec_stream to code Control Change state information. The value[] array holds the most recent data values for each controller number. At the start of the stream, value[] is initialized to the default controller data values specified in [MPEGSA].
NMP受信機は、コントロールチェンジ状態情報を符号化するためにjrec_streamに各音声チャンネルのためjrec_chapterc構造（図10）を維持します。値[]配列は、各コントローラ番号の最新のデータ値を保持します。ストリームの開始時に、値が[] [MPEGSA]で指定されたデフォルトの制御データ値に初期化されます。
The count[] and toggle[] arrays hold the count tool and toggle tool state values. At the start of a stream, these arrays are initialized to zero. Whenever a Control Command executes, the receiver updates the count[] and toggle[] state values, using the algorithms defined in Appendix A.3 of [RFC4695].
カウント[]および[]トグルアレイは、カウントツールとトグルツールの状態値を保持します。ストリームの開始時に、これらの配列はゼロに初期化されています。制御コマンドを実行するたびに、受信機は、付録A.3 [RFC4695]で定義されたアルゴリズムを使用して、カウント[]トグル[]状態値を更新します。
At the end of a loss event, the receiver parses the Chapter C controller log list, using the S bit to skip over "safe" logs in the single-packet loss case. For each at-risk controller number n, the receiver determines the tool type in use (value, toggle, or count) and compares the data in the log to the associated jrec_chapterc array element (value[n], toggle[n], or count[n]). If the data do not match, one or more Control Change commands have been lost.
損失事象の終了時に、受信機は、単一パケット損失の場合に「安全な」ログをスキップするためにSビットを使用して、章Cコントローラログリストを解析します。各リスクのあるコントローラ番号のN個の受信機が使用されているツールの種類（値、トグル、またはカウント）を決定し、関連jrec_chapterc配列要素（値[N]にログ内のデータを比較し、[n]の切り替え、又はカウント[N]）。データが一致しない場合は、一つ以上のコントロールチェンジコマンドが失われています。
The method the receiver uses to recover from this loss depends on the tool type and the controller number. For graded controllers protected by the value tool, the receiver executes a Control Change command using the new data value.
受信機はこの損失から回復するために使用する方法は、工具タイプとコントローラの数に依存します。値ツールにより保護段階的コントローラの場合、受信機は、新しいデータ値を使用してコントロールチェンジコマンドを実行します。
For the toggle and count tools, the recovery action is more complex. For example, the Damper Pedal (Sustain) controller (number 64) is typically used as a sustain pedal for piano-like sounds and is typically coded using the toggle tool. If Damper Pedal (Sustain)
トグルカウントツールについては、回復動作はより複雑です。例えば、ダンパーペダル（サスティン）コントローラ（数64）は、典型的にはピアノのような音のためのサステインペダルとして使用され、典型的には、トグルツールを使用して符号化されます。もしダンパー・ペダル（サスティン）
Control Change commands are lost, the receiver takes different actions depending on the starting and ending state of the lost sequence, to ensure that "ringing" piano notes are "damped" to silence.
コントロールチェンジコマンドが失われ、受信機は、ピアノのノートを「リンギングが」沈黙に「減衰」されることを保証するために、さまざまなアクションの開始に応じて、失われたシーケンスの状態を終了になります。
After recovering from the loss, the receiver updates the value[], toggle[], and count[] arrays to reflect the Chapter C data and the executed commands.
損失から回復した後、受信機は、値は[]、[]を切り替える更新し、章Cのデータ及び実行されたコマンドを反映するために[]アレイを数えます。
Chapter P of the recovery journal protects against the loss of MIDI Program Change (0xC) commands.
回復ジャーナルの章Pは、MIDIプログラムチェンジ（から0xC）コマンドの損失を防ぐことができます。
The 7-bit data value of the Program Change command selects one of 128 possible timbres for the channel. To increase the number of possible timbres, Control Change (0xB) commands may be issued prior to the Program Change command to select a "program bank". The Bank Select MSB (number 0) and Bank Select LSB (number 32) controllers specify the 14-bit bank number that subsequent Program Change commands reference.
プログラムチェンジコマンドの7ビットのデータ値は、チャネル128件の可能な音色のいずれかを選択します。可能な音色の数を増やすには、コントロールチェンジ（0xB）コマンドは、前にプログラムチェンジを発行することができる「プログラムバンク」を選択するように命じます。バンクセレクトMSB（番号0）とバンクセレクトLSB（数32）のコントローラは、その後のプログラムチェンジを基準コマンド14ビットのバンク番号を指定します。
The NMP receiver maintains the jrec_chapterp structure (Figure 10) for each voice channel in jrec_stream to code Program Change state information.
NMP受信機は、プログラムチェンジ状態情報を符号化するためにjrec_streamに各音声チャンネルのためjrec_chapterp構造（図10）を維持します。
The prognum variable of jrec_chapterp holds the data value for the most recent Program Change command that has arrived on the stream. The bank_msb and bank_lsb variables of jrec_chapterp code the Bank Select MSB and Bank Select LSB controller data values that were in effect when that Program Change command arrived. The prognum_qual, bank_msb_qual, and bank_lsb_qual variables are initialized to 0 and are set to 1 to qualify the associated data values.
jrec_chapterpのたprognum変数は、ストリームに到着した最新のプログラムチェンジコマンドのデータ値を保持しています。 jrec_chapterpコードバンクセレクトMSBおよびそのプログラムチェンジコマンドが到着したときに有効であったバンクセレクトLSBコントローラデータ値のbank_msbとbank_lsb変数。 prognum_qual、bank_msb_qual、及びbank_lsb_qual変数が0に初期化されると、関連するデータ値を修飾するために1に設定されています。
Chapter P fields code the data value for the most recent Program Change command, and the MSB and LSB bank values in effect for that command.
章Pフィールドは、最新のプログラムチェンジコマンドのデータ値をコーディングし、そのコマンドの効果でMSBとLSB銀行の値。
At the end of a loss event, the receiver checks Chapter P to see if the recovery journal fields match the data stored in jrec_chapterp. If these checks fail, one or more Program Change commands have been lost.
損失事象の終了時に、受信機は回復ジャーナルフィールドはjrec_chapterpに格納されたデータと一致するかどうかを確認するために章Pをチェックします。これらのチェックが失敗した場合、一つ以上のプログラム・チェンジ・コマンドが失われています。
To recover from this loss, the receiver takes the following steps. If the B bit in Chapter P is set (Figure A.2.1 in [RFC4695]), Control Change bank commands have preceded the Program Change command. The receiver compares the bank data coded by Chapter P with the current bank data for the channel (coded in jrec_channelc).
この損失から回復するには、受信機は以下の手順を実行します。章PのBビットがセットされている場合（[RFC4695]で図A.2.1）を、コントロールチェンジバンクコマンドは、プログラム変更コマンドに先行しています。受信機は、（jrec_channelcで符号化された）チャネルのための現在のバンクデータと章Pにより符号化バンクデータとを比較します。
If the bank data do not agree, the receiver issues Control Change commands to align the stream with Chapter P. The receiver then updates jrec_channelp and jrec_channelc variables to reflect the executed command(s). Finally, the receiver issues a Program Change command that reflects the data in Chapter P and updates the prognum and qual_prognum fields in jrec_channelp.
銀行のデータが一致しない場合、受信機は、コントロールチェンジが受信機はその後、更新jrec_channelpとjrec_channelc変数が実行されたコマンド（複数可）を反映するために章P.でストリームを整列させるコマンドを発行します。最後に、受信機は、章P内のデータを反映し、jrec_channelpでのprognumとqual_prognumフィールドを更新プログラムチェンジコマンドを発行します。
Note that this method relies on Chapter P recovery to precede Chapter C recovery during channel journal processing. This ordering ensures that lost Bank Select Control Change commands that occur after a lost Program Change command in a stream are handled correctly.
この方法は、チャネルジャーナル処理中章Cの回復の前に章Pの回復に依存していることに注意してください。ストリームで失われたプログラムチェンジコマンドが正しく処理された後に発生するバンクセレクトコントロールチェンジコマンドを失った。この順序が保証されます。
Security considerations for the RTP MIDI payload format are discussed in the Security Considerations section of [RFC4695].
RTP MIDIペイロード形式のためのセキュリティ問題は[RFC4695]のセキュリティの考慮事項のセクションで説明されています。
IANA considerations for the RTP MIDI payload format are discussed in the IANA Considerations section of [RFC4695].
RTP MIDIペイロード形式のためのIANA問題は[RFC4695]のIANA Considerations部に記載されています。
This memo was written in conjunction with [RFC4695], and the Acknowledgements section of [RFC4695] also applies to this memo.
このメモは、[RFC4695]に関連して記述された、および[RFC4695]の謝辞セクションは、このメモに適用されました。
[RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for MIDI", RFC 4695, November 2006.
[RFC4695]ラザロ、J.とJ. Wawrzynek、 "MIDIのためのRTPペイロードフォーマット"、RFC 4695、2006年11月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 Detailed Specification", 1996.
[MIDI] MIDI製造者協会。 "コンプリートMIDI 1.0の詳細な仕様書"、1996年。
[MPEGSA] International Standards Organization. "ISO/IEC 14496 MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio), 2001.
[MPEGSA]国際標準化機構。 "ISO / IEC 14496、MPEG-4"、第3部（オーディオ）、サブパート5（構造化オーディオ）、2001。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556] Casner、S.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、RFC 3556、2003年7月。
[NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network Musical Performance", 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) June 25-26, 2001, Port Jefferson, New York.
[NMP]ラザロ、J.およびJ. Wawrzynek。 、ネットワーク上の第11回国際ワークショップとデジタルオーディオとビデオのためのオペレーティングシステムのサポート（NOSSDAV 2001）6月25-26日、2001、ポートジェファーソン、ニューヨークの「ネットワーク演奏用ケース」。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical Events Streaming over Internet", Proceedings of the International Conference on WEB Delivering of Music 2001, pages 147-154.
【GRAME] Fober、D.、Orlarey、Y.およびS. Letz。ミュージック2001年届けるWEB上の「インターネット上でリアルタイムストリーミング音楽会」、国際会議の議事録、ページ147-154。
[CCRMA] Chafe C., Wilson S., Leistikow R., Chisholm D., and G. Scavone. "A simplified approach to high quality music and sound over IP", COST-G6 Conference on Digital Audio Effects (DAFx-00), Verona, Italy, December 2000.
【CCRMA】擦れC.、ウィルソンS.、Leistikow R.、チザムD.、およびG. Scavone。 「単純化された高品質の音楽へのアプローチとIPを介して音」、デジタル・オーディオ・エフェクト（DAFx-00）、ヴェローナ、イタリア、2000年12月にCOST-G6会議。
[RTPBOOK] Perkins, C. "RTP: Audio and Video for the Internet", Addison-Wesley, ISBN 0-672-32249-8, 2003.
[RTPBOOK]パーキンス、C. "RTP：インターネットのためのオーディオとビデオ"、アディソン・ウェズリー、ISBN 0-672-32249-8、2003。
[STEVENS] Stevens, R. W, Fenner, B., and A. Rudoff. "Unix Network Programming: The Sockets Networking API", Addison-Wesley, 2003.
【STEVENS】スティーブンス、R. W、フェナー、B.、およびA. Rudoff。 「UNIXネットワークプログラミング：ソケットネットワーキングAPI」、アディソン・ウェズリー、2003。
Authors' Addresses
著者のアドレス
John Lazzaro (corresponding author) UC Berkeley CS Division 315 Soda Hall Berkeley CA 94720-1776
ジョン・ラザロ（相当著者）UCバークレーCS課315ソーダホールバークレーCA 94720から1776
EMail: lazzaro@cs.berkeley.edu
メールアドレス：lazzaro@cs.berkeley.edu
John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley CA 94720-1776
ジョン・ウォウリネックUCバークレーCS課631ソーダホールバークレーCA 94720から1776
EMail: johnw@cs.berkeley.edu
メールアドレス：johnw@cs.berkeley.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。