RFC5093 日本語訳

5093 BT's eXtended Network Quality RTP Control Protocol ExtendedReports (RTCP XR XNQ). G. Hunt. December 2007. (Format: TXT=15110 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                            G. Hunt
Request for Comments: 5093                                            BT
Category: Informational                                    December 2007

コメントを求めるワーキンググループG.狩り要求をネットワークでつないでください: 5093年のBTカテゴリ: 情報の2007年12月

  BT's eXtended Network Quality RTP Control Protocol Extended Reports
                             (RTCP XR XNQ)

BTの拡大ネットワーク品質RTP制御プロトコルはレポートを広げました。(RTCP XR XNQ)

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.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

IESG Note

IESG注意

   The IESG has concerns about vendor code points allocation in this
   small namespace and might not approve similar documents in the
   future.

IESGはこの小さい名前空間における業者コード・ポイント配分に関する心配を持って、将来、同様のドキュメントを承認しないかもしれません。

Abstract

要約

   This document describes an RTCP XR report block, which reports packet
   transport parameters.  The report block was developed by BT for pre-
   standards use in BT's next-generation network.  This document has
   been produced to describe the report block in sufficient detail to
   register the block type with IANA in accordance with the
   Specification Required policy of RFC 3611.  This specification does
   not standardise the new report block for use outside BT's network.

このドキュメントはRTCP XRレポートブロックについて説明します。(それは、パケット輸送パラメタを報告します)。 レポートブロックはBTの次世代のネットワークにおけるプレ規格使用のためにBTによって発生されました。 このドキュメントは、RFC3611のSpecification Required方針に従ってゴシック体をIANAに示すことができるくらい詳細にレポートブロックについて説明するために製作されました。 この仕様はBTのネットワークの外で使用のための最新の報告ブロックを標準化しません。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
   3.  Extended Network Quality (XNQ) Report Block . . . . . . . . . . 2
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件記法. . . . . . . . . . . . . . . . . . . . . 2 3 拡大ネットワーク品質(XNQ)はブロック. . . . . . . . . . 2 4を報告します。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 6 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 6 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 6

Hunt                         Informational                      [Page 1]

RFC 5093            RTCP XR eXtended Network Quality       December 2007

2007年12月に情報[1ページ]のRFC5093RTCP XR拡大ネットワーク品質を捜してください。

1.  Introduction

1. 序論

   A set of metrics of packet-transport quality has been defined by BT
   for pre-standards use in its network.  These metrics are known as
   "XNQ" for "eXtended Network Quality".  This document defines an
   RTCP-XR Report Block to transport the XNQ measures from an RTP end
   system to its peer, using the extension mechanism defined in [1].

パケット輸送品質の測定基準のセットはネットワークにおけるプレ規格使用のためにBTによって定義されました。 これらの測定基準は「拡大ネットワーク品質」のための"XNQ"として知られています。 このドキュメントはRTPエンドシステムから同輩までXNQ測定を輸送するためにRTCP-XR Report Blockを定義します、[1]で定義された拡大メカニズムを使用して。

   The metrics are designed to supplement the packet-loss metric in RTCP
   [2] and the roundtrip delay measurement provided by RTCP.  They
   provide metrics for IP Packet Delay Variation based on the IPDV
   metric defined in [3], metrics reporting the activity of the RTP end
   system's receiver's jitter buffer, and metrics reporting "errored"
   and "severely errored" seconds.

測定基準は、RTCP[2]のメートル法のパケット損失とRTCPによって供給された往復の遅れ測定を補うように設計されています。 彼らは[3]、RTPエンドシステムの受信機のジターバッファの活動を報告する測定基準、および"erroredする"である、「厳しくerroredされた」秒を報告する測定基準で定義されていた状態でIPDVにメートル法であることで基づくIP Packet Delay Variationのための測定基準を提供します。

   This document has been produced to describe the report block in
   sufficient detail to register the block type with IANA in accordance
   with the Specification Required policy of [1].  This specification
   does not standardise the new report block for use outside BT's
   network.

このドキュメントは、[1]のSpecification Required方針に従ってゴシック体をIANAに示すことができるくらい詳細にレポートブロックについて説明するために製作されました。 この仕様はBTのネットワークの外で使用のための最新の報告ブロックを標準化しません。

   Work in progress on RTCP HR [5] is likely to obsolete these metrics
   and the RTCP-XR Report Block defined here.

RTCP HR[5]の進行中の仕事はこれらの測定基準とここで定義されたRTCP-XR Report Blockを時代遅れにしそうです。

2.  Requirements Notation

2. 要件記法

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [4].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[4]で説明されるように本書では解釈されることであるべきですか?

3.  Extended Network Quality (XNQ) Report Block

3. 拡大ネットワーク品質(XNQ)レポートブロック

   A set of metrics of packet-transport quality has been defined by BT
   for pre-standards use in its network.  These metrics are known as
   "XNQ" for "eXtended Network Quality".

パケット輸送品質の測定基準のセットはネットワークにおけるプレ規格使用のためにBTによって定義されました。 これらの測定基準は「拡大ネットワーク品質」のための"XNQ"として知られています。

   This document defines an RTCP-XR Report Block using the extension
   mechanism defined in [1].  The new Report Block provides transport of
   the XNQ measures from an RTP end system to its peer.

このドキュメントは、[1]で定義された拡大メカニズムを使用することでRTCP-XR Report Blockを定義します。 新しいReport BlockはXNQ測定のRTPエンドシステムから同輩までの輸送を提供します。

   The metrics are described in the following text.  However, some
   additional explanation is required for the metrics vmaxdiff, vrange,
   vsum, and c, which measure aspects of packet delay variation.  The
   metrics are based on the measure known as IP Packet Delay Variation
   (IPDV) defined in [3].  The IPDV of a packet is the amount by which
   the packet was delayed in the network, minus the amount a reference
   packet was delayed in the network.  The reference packet is usually
   the first packet of the connection.  IPDV is a signed quantity.

測定基準は以下のテキストで説明されます。 しかしながら、何らかの追加説明が測定基準vmaxdiff、vrange、vsum、およびcに必要です。(測定基準はパケット遅れ変化の局面を測定します)。 測定基準は[3]で定義されたIP Packet Delay Variation(IPDV)として知られている測定に基づいています。 パケットのIPDVがパケットがネットワークで遅れた量である、量を引いて、参照パケットはネットワークで遅れました。 通常、参照パケットは接続の最初のパケットです。 IPDVはサインされた量です。

Hunt                         Informational                      [Page 2]

RFC 5093            RTCP XR eXtended Network Quality       December 2007

2007年12月に情報[2ページ]のRFC5093RTCP XR拡大ネットワーク品質を捜してください。

   The metric vrange is the difference (longest minus shortest) between
   the longest and shortest network packet delays seen over the duration
   of the connection to date.  The metric vrange is usually a positive
   quantity, but may be zero if the packet delay is exactly constant
   over the lifetime of the connection to date.

メートル法のvrangeは最も長くてこれまでの接続の持続時間の上で見られる中で最も少しなネットワークパケット遅れの違い(最も短いことを引いて最も長い)です。 メートル法のvrangeは通常正数ですが、パケット遅れがまさにこれまでの接続の生涯一定であるなら、ゼロであるかもしれません。

   The metric vmaxdiff is found as follows.  For each RTCP measurement
   cycle, find the difference (longest minus shortest) between the
   longest and shortest network packet delays within that measurement
   cycle.  These differences are usually all positive quantities, but a
   difference may be zero if the packet delay is exactly constant
   throughout the measurement cycle.  Take the set of these differences
   and find the maximum, which is vmaxdiff.  The metric vmaxdiff is also
   usually a positive quantity, but will be zero if all the members of
   the set of per-cycle differences are zero.

メートル法のvmaxdiffは以下の通りであるのがわかります。 それぞれのRTCP測定サイクルの間、その測定サイクルの中に最も長くて最も少しなネットワークパケット遅れの違い(最も短いことを引いて最も長い)を見つけてください。 これらの違いはすべて、通常正数ですがパケット遅れが測定サイクルの間中まさに一定であるなら、違いはゼロであるかもしれません。 これらの違いのセットを取ってください、そして、最大を見つけてください。(それは、vmaxdiffです)。 メートル法のvmaxdiffは通常も正数ですが、1サイクルあたりの違いのセットのすべてのメンバーがゼロであるならゼロになるでしょう。

   The metric vsum is simply the sum of the per-RTCP-cycle differences,
   which were obtained to find vmaxdiff as described above.  The metric
   c is the number of per-RTCP-cycle differences, that is, the
   cardinality of the set of differences.  The two metrics vsum and c
   allow calculation of vsum/c, the average IPDV per RTCP measurement
   cycle.

メートル法のvsumは単にRTCP単位で循環している違いの合計です。(違いは、上で説明されるようにvmaxdiffを見つけるために得られました)。 メートル法のcはすなわち、違い、違いのセットのRTCPサイクルあたりの基数の数です。 2つの測定基準vsumとcがvsum/cの計算を許容して、RTCP測定あたりの平均したIPDVは循環します。

   The format of the report is as shown in Figure 1.

レポートの形式が図1に示されるようにあります。

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     BT=8      |   reserved    |      block length = 8         |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |          begin_seq            |             end_seq           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           vmaxdiff            |             vrange            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              vsum                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               c               |            jbevents           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                     tdegnet                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                     tdegjit                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                        es                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                       ses                     |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=8| 予約されます。| ブロック長=8| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | _seqを始めてください。| 終わり_seq| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vmaxdiff| vrange| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vsum| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c| jbevents| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| tdegnet| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| tdegjit| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| es| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| ses| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

                                 Figure 1

図1

Hunt                         Informational                      [Page 3]

RFC 5093            RTCP XR eXtended Network Quality       December 2007

2007年12月に情報[3ページ]のRFC5093RTCP XR拡大ネットワーク品質を捜してください。

   The report consists of an RTCP-XR block header and a single 8-word
   sub-block.

レポートはRTCP-XRブロックヘッダーと1つの8単語のサブブロックから成ります。

   block type (BT): 8 bits

タイプ(BT)を妨げてください: 8ビット

      An XNQ Metrics Report Block is identified by the constant 8.

XNQ Metrics Report Blockは一定の8時までに特定されます。

   reserved: 8 bits

予約される: 8ビット

      These fields are reserved for future definition.  In the absence
      of such a definition, the bits in these fields MUST be set to zero
      and MUST be ignored by the receiver.

これらの分野は今後の定義のために予約されます。 そのような定義がないとき、これらの分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。

   block length: 16 bits

ブロック長: 16ビット

      Defined in Section 3 of [1].

[1]のセクション3では、定義されます。

   begin_seq: 16 bits

_seqを始めてください: 16ビット

      As defined in Section 4.1 of [1].

[1]のセクション4.1で定義されるように。

   end_seq: 16 bits

_seqを終わらせてください: 16ビット

      As defined in Section 4.1 of [1].

[1]のセクション4.1で定義されるように。

   vmaxdiff: 16 bits unsigned

vmaxdiff: 16ビット、無記名

      Largest IPDV difference seen to date within a single RTCP
      measurement cycle, measured in RTP timestamp units.  If the
      measured value exceeds 0xFFFE, the value 0xFFFF should be reported
      to indicate an over-range measurement.

RTPタイムスタンプユニットで測定された1RTCP測定サイクルの以内にこれまでであるのが見られた中で最も大きいIPDV差。 測定値が0xFFFEを超えているなら、値の0xFFFFがオーバーレンジ測定を示すと報告されるべきです。

   vrange: 16 bits unsigned

vrange: 16ビット、無記名

      Largest IPDV difference over the lifetime of the RTP flow to date,
      measured in RTP timestamp units.  If the measured value exceeds
      0xFFFE, the value 0xFFFF should be reported to indicate an over-
      range measurement.

RTPタイムスタンプユニットでこれまでの、そして、測定されたRTP流動の生涯の間の最も大きいIPDV差。 測定値が0xFFFEを超えているなら、値の0xFFFFが過剰範囲測定を示すと報告されるべきです。

   vsum: 32 bits unsigned

vsum: 32ビット、無記名

      Sum of the peak IPDV difference values within each RTCP cycle,
      summed over RTCP cycles over the lifetime of the RTP flow to date.
      If the measured value exceeds 0xFFFFFFFE, the value 0xFFFFFFFF
      should be reported to indicate an over-range measurement.

これまでRTCPサイクルの間にRTP流動の生涯の上へまとめられたそれぞれのRTCPサイクルの以内のピークIPDV違いの値の合計。 測定値が0xFFFFFFFEを超えているなら、値の0xFFFFFFFFがオーバーレンジ測定を示すと報告されるべきです。

Hunt                         Informational                      [Page 4]

RFC 5093            RTCP XR eXtended Network Quality       December 2007

2007年12月に情報[4ページ]のRFC5093RTCP XR拡大ネットワーク品質を捜してください。

   c: 16 bits unsigned

c: 16ビット、無記名

      Number of RTCP cycles over which vsum was accumulated.  If the
      measured value exceeds 0xFFFE, the value 0xFFFF should be reported
      to indicate an over-range measurement.

どのvsumが蓄積されたかの上をRTCPの数は循環します。 測定値が0xFFFEを超えているなら、値の0xFFFFがオーバーレンジ測定を示すと報告されるべきです。

   jbevents: 16 bits unsigned

jbevents: 16ビット、無記名

      Cumulative number of jitter buffer adaptation events over the
      lifetime of the RTP flow to date.  If the measured value exceeds
      0xFFFE, the value 0xFFFF should be reported to indicate an over-
      range measurement.

RTPの生涯の間の累積している数のジターバッファ適合イベントがこれまで流れます。 測定値が0xFFFEを超えているなら、値の0xFFFFが過剰範囲測定を示すと報告されるべきです。

   tdegnet: 24 bits unsigned

tdegnet: 24ビット、無記名

      The total time in sample periods affected either by packets
      unavailable due to network loss, or late delivery of packets,
      since the start of transmission.  If the measured value exceeds
      0xFFFFFE, the value 0xFFFFFF should be reported to indicate an
      over-range measurement.

サンプルの期間の合計時はネットワークの損失、または遅いパケットの配信で入手できないパケットでどちらかに影響しました、トランスミッションの始まり以来。 測定値が0xFFFFFEを超えているなら、値の0xFFFFFFがオーバーレンジ測定を示すと報告されるべきです。

   tdegjit: 24 bits unsigned

tdegjit: 24ビット、無記名

      The total time in sample periods degraded by jitter buffer
      adaptation events, e.g., where the jitter buffer either plays out
      a sample sequence not originating at the transmitter, repeats
      samples, or chooses not to play out a sample sequence that was
      sent by the transmitter.  If the measured value exceeds 0xFFFFFE,
      the value 0xFFFFFF should be reported to indicate an over-range
      measurement.

サンプルの期間の合計時はジターバッファ適合イベントで退行しました、例えば、ジターバッファが、送信機で由来しないサンプル系列を展開するか、サンプルを繰り返すか、または送信機によって送られたサンプル系列を展開しないのを選ぶところで。 測定値が0xFFFFFEを超えているなら、値の0xFFFFFFがオーバーレンジ測定を示すと報告されるべきです。

   es: 24 bits unsigned

es: 24ビット、無記名

      cumulative seconds affected by "unavailable packet" events over
      the lifetime of this ephemeral, to date.  If the measured value
      exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to
      indicate an over-range measurement.

はかなくて、これまでのこの生涯の間の「入手できないパケット」出来事で影響を受ける累積している秒。 測定値が0xFFFFFEを超えているなら、値の0xFFFFFFがオーバーレンジ測定を示すと報告されるべきです。

   ses: 24 bits unsigned

ses: 24ビット、無記名

      cumulative seconds affected by severe "unavailable packet" events
      over the lifetime of this ephemeral, to date.  If the measured
      value exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to
      indicate an over-range measurement.

はかなくて、これまでのこの生涯の間の厳しい「入手できないパケット」イベントで影響を受ける累積している秒。 測定値が0xFFFFFEを超えているなら、値の0xFFFFFFがオーバーレンジ測定を示すと報告されるべきです。

Hunt                         Informational                      [Page 5]

RFC 5093            RTCP XR eXtended Network Quality       December 2007

2007年12月に情報[5ページ]のRFC5093RTCP XR拡大ネットワーク品質を捜してください。

4.  IANA Considerations

4. IANA問題

   IANA has allocated the number 8 within the registry "RTP Control
   Protocol Extended Reports (RTCP XR) Block Types" to the RTCP XR
   report block described here.  This registry is defined in [1].

IANAは登録「RTP制御プロトコルの拡張レポート(RTCP XR)ゴシック体」の中にここで説明されたRTCP XRレポートブロックにNo.8を割り当てました。 この登録は[1]で定義されます。

5.  Security Considerations

5. セキュリティ問題

   It is believed that this proposed RTCP XR report block introduces no
   new security considerations beyond those described in [1].  Some of
   the considerations in [1] do not apply to this report block.
   Specifically, XNQ does not provide per-packet statistics so the risk
   to confidentiality documented in Section 7, paragraph 3 of [1] does
   not apply, and XNQ packets cannot be very large so the risk of denial
   of service documented in Section 7, paragraph 7 of [1] does not
   apply.

この提案されたRTCP XRレポートブロックが[1]で説明されたものを超えてどんな新しいセキュリティ問題も紹介しないと信じられています。 [1]の問題のいくつかがこのレポートブロックに適用されません。 サービスの否定のリスクがセクションに7を記録して、XNQは、セクション7に記録された秘密性へのリスク、[1]のパラグラフ3が適用されないで、XNQパケットがそれほど大きいはずがないように[1]のパラグラフ7が明確に適用されないのを1パケットあたりの統計を前提としません。

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [1]  Friedman, T., "RTP Control Protocol Extended Reports (RTCP XR)",
        RFC 3611, November 2003.

[1] フリードマン、T.、「RTP制御プロトコルの拡張レポート(RTCP XR)」、RFC3611 2003年11月。

   [2]  Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
        Applications", RFC 3550, July 2003.

[2]Schulzrinne、H.、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。

   [3]  ITU-T, "Recommendation Y.1540, Internet protocol data
        communication service -- IP packet transfer and availability
        performance parameters", December 2002.

[3] 2002年12月のITU-Tと、「Y.1540、インターネットはデータ通信サービスについて議定書の中で述べます--IPパケットが移されるという推薦と有用性性能パラメタ」

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。

6.2.  Informative References

6.2. 有益な参照

   [5]  Clark, A., "RTCP HR - High Resolution VoIP Metrics Report
        Blocks", Work in Progress, November 2007.

[5] クラーク、A.、「RTCP時間--高画質VoIP測定基準はブロックを報告する」、進歩、2007年11月に、働いてください。

Hunt                         Informational                      [Page 6]

RFC 5093            RTCP XR eXtended Network Quality       December 2007

2007年12月に情報[6ページ]のRFC5093RTCP XR拡大ネットワーク品質を捜してください。

Author's Address

作者のアドレス

   Geoff Hunt
   BT
   Orion 1 PP9
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk  IP5 3RE
   United Kingdom

PP9 Adastral公園Martlesham Heathイプスウィッチ、ジェフ狩りBTオリオン1サフォークIP5 3REイギリス

   Phone: +44 1473 608325
   EMail: geoff.hunt@bt.com

以下に電話をしてください。 +44 1473 608325はメールされます: geoff.hunt@bt.com

Hunt                         Informational                      [Page 7]

RFC 5093            RTCP XR eXtended Network Quality       December 2007

2007年12月に情報[7ページ]のRFC5093RTCP XR拡大ネットワーク品質を捜してください。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を記述してください。

Hunt                         Informational                      [Page 8]

狩り情報です。[8ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

-単項演算子 負号

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る