Internet Engineering Task Force (IETF) D. Malas
Request for Comments: 6076 CableLabs
Category: Standards Track A. Morton
ISSN: 2070-1721 AT&T Labs
January 2011
Basic Telephony SIP End-to-End Performance Metrics
Abstract
抽象
This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations.
この文書では、メトリックのセットとの両方の生産およびテスト環境での電話サービスのためのエンドツーエンドのセッション開始プロトコル（SIP）の性能を評価するためのそれらの使用法を定義します。このドキュメントの目的は、業界の実装の比較を容易に、相互運用可能なパフォーマンス測定をできるように、一般的なメトリックの標準セットを組み合わせることです。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6076.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6076で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction and Scope ..........................................3
2. Terminology .....................................................4
3. Time Interval Measurement and Reporting .........................5
4. SIP Performance Metrics .........................................7
4.1. Registration Request Delay (RRD) ...........................8
4.2. Ineffective Registration Attempts (IRAs) ...................9
4.3. Session Request Delay (SRD) ...............................10
4.3.1. Successful Session Setup SRD .......................11
4.3.2. Failed Session Setup SRD ...........................12
4.4. Session Disconnect Delay (SDD) ............................13
4.5. Session Duration Time (SDT) ...............................15
4.5.1. Successful Session Duration SDT ....................15
4.5.2. Failed Session Completion SDT ......................17
4.6. Session Establishment Ratio (SER) .........................18
4.7. Session Establishment Effectiveness Ratio (SEER) ..........19
4.8. Ineffective Session Attempts (ISAs) .......................20
4.9. Session Completion Ratio (SCR) ............................21
5. Additional Considerations ......................................23
5.1. Metric Correlations .......................................23
5.2. Back-to-Back User Agent (B2BUA) ...........................23
5.3. Authorization and Authentication ..........................23
5.4. Forking ...................................................24
5.5. Data Collection ...........................................24
5.6. Testing Documentation .....................................25
6. Conclusions ....................................................25
7. Security Considerations ........................................25
8. Contributors ...................................................26
9. Acknowledgements ...............................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
SIP has become a widely used standard among many service providers, vendors, and end users in the telecommunications industry. Although there are many different standards for measuring the performance of telephony signaling protocols, such as Signaling System 7 (SS7), none of the metrics specifically address SIP.
SIPは、通信業界での多くのサービスプロバイダー、ベンダー、エンドユーザーの間で広く使われている標準となっています。そのようなシグナリングシステム7（SS7）のような電話シグナリングプロトコルの性能を測定するための多くの異なる規格があるが、メトリックのいずれも、具体的にSIPに対処しません。
The scope of this document is limited to the definitions of a standard set of metrics for measuring and reporting SIP performance from an end-to-end perspective in a telephony environment. The metrics introduce a common foundation for understanding and quantifying performance expectations between service providers, vendors, and the users of services based on SIP. The intended audience for this document can be found among network operators, who often collect information on the responsiveness of the network to customer requests for services.
この文書の範囲は、テレフォニー環境におけるエンド・ツー・エンドの観点からSIP性能を測定し、報告するための測定基準の標準セットの定義に制限されています。メトリックは、理解のための共通基盤を導入し、SIPに基づくサービスプロバイダー、ベンダー、およびサービスのユーザー間のパフォーマンスの期待を定量化します。このドキュメントの対象読者は、多くの場合、サービスに対する顧客の要求に対するネットワークの応答性に関する情報を収集するネットワークオペレータ、中から見出すことができます。
Measurements of the metrics described in this document are affected by variables external to SIP. The following is a non-exhaustive list of examples:
この文書で説明メトリックの測定は、SIPに外部変数の影響を受けています。以下は、例の非網羅的なリストであります：
o Network connectivity
Oネットワーク接続
o Switch and router performance
Oスイッチとルータのパフォーマンス
o Server processes and hardware performance
Oサーバー・プロセスおよびハードウェアのパフォーマンス
This document defines a list of pertinent metrics for varying aspects of a telephony environment. They may be used individually or as a set based on the usage of SIP within the context of a given telecommunications service.
この文書では、電話環境の変化点について適切なメトリックのリストを定義します。これらは、個別に、または所定の電気通信サービスのコンテキスト内でSIPの使用に基づいてセットとして使用することができます。
The metrics defined in this document DO NOT take into consideration the impairment or failure of actual application processing of a request or response. The metrics do not distinguish application processing time from other sources of delay, such as packet transfer delay.
この文書で定義されたメトリックを考慮に要求または応答の実際のアプリケーション処理の障害や故障を取ることはありません。メトリックは、パケット転送遅延のような遅延の他のソースからアプリケーション処理時間を区別しません。
Metrics designed to quantify single device application processing performance are beyond the scope of this document.
単一デバイスアプリケーション処理性能を定量化するために設計されたメトリックは、この文書の範囲を超えています。
This document does not provide any numerical objectives or acceptance threshold values for the SIP performance metrics defined below, as these items are beyond the scope of IETF activities, in general.
これらの項目は、一般的に、IETF活動の範囲を超えているとして、この文書では、以下に定義されたSIPパフォーマンスメトリックのための任意の数値目標や受入れしきい値を提供していません。
The metrics defined in this document are applicable in scenarios where the SIP messages launched (into a network under test) are dedicated messages for testing purposes, or where the messages are user-initiated and a portion of the live is traffic present. These two scenarios are sometimes referred to as active and passive measurement, respectively.
この文書で定義されたメトリックは、（テスト中のネットワークに）起動SIPメッセージは、テスト目的のための専用のメッセージであるか、またはメッセージがユーザーによって開始され、ライブの部分は、トラフィックが存在する場合のシナリオに適用可能です。これら2つのシナリオは、しばしば、それぞれ、アクティブおよびパッシブ測定と呼ばれます。
The following terms and conventions will be used throughout this document:
次の用語と規則は、この文書全体で使用されます。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
End-to-End - This is described as two or more elements utilized for initiating a request, receiving the request, and responding to the request. It encompasses elements as necessary to be involved in a session dialog between the originating user agent client (UAC), destination user agent server (UAS), and any interim proxies (may also include back-to-back user agents (B2BUAs)). This may be relative to a single operator's set of elements or may extend to encompass all elements (if beyond a single operator's network) associated with a session.
エンドツーエンド - これは、要求を開始する要求を受信し、その要求に応答するために利用される二つ以上の要素として記載されています。それは必要に応じて要素が元のユーザエージェントクライアント（UAC）、宛先ユーザエージェントサーバ（UAS）との間のセッションダイアログに関与することを包含する、任意の中間プロキシが（またバックツーバックユーザエージェント（型B2BUAを含んでいてもよいです））。これは、要素の単一のオペレータのセットに対してであってもよく、または（単一事業者のネットワークを越えている場合）セッションに関連付けられたすべての要素を包含するように延びていてもよいです。
Session - As described in RFC 3261 [RFC3261], SIP is used primarily to request, create, and conclude sessions. "These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences". The metrics within this document measure the performance associated with the SIP dialogs necessary to establish these sessions; therefore, they are titled as Session Request Delay, Session Disconnect Delay, etc. Although the titles of many of the metrics include this term, they are specifically measuring the signaling aspects only. Each session is identified by a unique "Call-ID", "To", and "From" header field tag.
セッションは、 - RFC 3261 [RFC3261]に記載されているように、SIPは、要求作成し、セッションを終了するために主に使用されます。 「これらのセッションは、インターネット電話、マルチメディア配信、およびマルチメディア会議が含まれます」。このドキュメント内のメトリックは、これらのセッションを確立するために必要なSIPダイアログに関連したパフォーマンスを測定します。そのため、彼らは、メトリックの多くのタイトルは、この用語が含まれますが、彼らはのみ特異的シグナル伝達側面を測定しているなど、セッション要求遅延、セッションの切断遅延、と題されています。各セッションはユニークな「-IDを呼び出し」、「へ」、およびヘッダフィールドの「From」タグで識別されます。
Session Establishment - Session establishment occurs when a 200 OK response from the target UA has been received, in response to the originating UA's INVITE setup request, indicating the session setup request was successful.
セッション確立 - ターゲットUAから200 OK応答は、セッション・セットアップ要求が成功したことを示し、元のUAのINVITEセットアップ要求に応答して、受信した場合、セッション確立が起こります。
Session Setup - As referenced within the sub-sections of Section 4.2 in this document, session setup is the set of messages and included parameters directly related to the process of a UA requesting to establish a session with a corresponding UA. This is also described as a set of steps in order to establish "ringing" [RFC3261].
セッションのセットアップ - この文書のセクション4.2のサブセクション内で参照されるように、セッションセットアップメッセージの集合であり、対応するUAとのセッションを確立することを要求直接UAのプロセスに関連するパラメータを含んでいました。これは、[RFC3261]を「リンギング」を確立するために、一連のステップとして記述されています。
Many of the metrics defined in this memo utilize a clock to assess the time interval between two events. This section defines time-related terms and reporting requirements.
このメモで定義されたメトリックの多くは、二つの事象間の時間間隔を評価するためにクロックを利用しています。このセクションでは、時間に関連した用語と報告要件を定義します。
t1 - start time
T1 - 開始時間
This is the time instant (when a request is sent) that begins a continuous time interval. t1 occurs when the designated request has been processed by the SIP application and the first bit of the request packet has been sent from the UA or proxy (and is externally observable at some logical or physical interface).
これは、連続的な時間間隔を開始します（リクエストが送信された）時点です。指定された要求は、SIPアプリケーションによって処理された要求パケットの最初のビットがUAまたはプロキシから送信された（及びいくつかの論理的または物理的インタフェースで外部から観察可能である）されたときにt1が生じます。
t1 represents the time at which each request-response test begins, and SHALL be used to designate the time of day when a particular measurement was conducted (e.g., the Session Request Delay at "t1" (at some specific UA interface) was measured to be X ms).
T1は、各要求 - 応答試験が始まる時間を表し、特定の測定を行った時刻を指定するために使用されなければならない（例えば、（）いくつかの特定のUAの界面における「T1」におけるセッション要求遅延が測定されました）XのMSこと。
t4 - end time
T4 - 終了時間
This is the time instant that concludes the continuous time interval begun when the related request is sent. t4 occurs when the last bit of the designated response is received by the SIP application at the requesting device (and is externally observable at some logical or physical interface).
これは、関連するリクエストが送信されたときに始まった連続時間間隔を終了時刻です。指定された応答の最後のビットが要求デバイスにSIPアプリケーションによって受信（及びいくつかの論理的または物理的なインタフェースで外部から観察可能である）である場合、T4が生じます。
Note: The designations t2 and t3 are reserved for future use at another interface involved in satisfying a request.
注：記号T2及びT3は、要求を満たすに関与する別のインタフェースで将来の使用のために予約されています。
Section 10.1 of [RFC2330] describes time-related issues in measurements, and defines the errors that can be attributed to the clocks themselves. These definitions are used in the material below.
[RFC2330]のセクション10.1は、測定に時間に関連する問題について説明し、クロック自体に起因する誤差を定義します。これらの定義は、以下の材料に使用されています。
Time-of-Day Accuracy
時間帯精度
As defined above, t1 is associated with the start of a request and also serves as the time-of-day stamp associated with a single specific measurement. The clock offset [RFC2330] is the difference between t1 and a recognized primary source of time, such as UTC (offset = t1 - UTC).
上記で定義され、T1は要求の開始と関連しており、また、単一の特定の測定に関連した時刻スタンプとして機能します。クロックオフセットは[RFC2330]は、T1と、そのようなUTC（ - UTC = T1オフセット）などの時間の認識されたプライマリソースとの間の差です。
When measurement results will be correlated with other results or information using time-of-day stamps, then the time clock that supplies t1 SHOULD be synchronized to a primary time source, to minimize the clock's offset. The clocks used at the different measurement points SHOULD be synchronized to each other, to minimize the relative offset (as defined in RFC2330). The clock's offset and the relative offset MUST be reported with each measurement.
測定結果を他の結果または時刻スタンプを使用して、情報に関連付けされたとき、その後、T1を供給するリアルタイムクロックは、クロックのオフセットを最小化するために、一次タイムソースに同期させるべきです。異なる測定点で使用されるクロックは、（RFC2330で定義されるように）相対オフセットを最小にするために、互いに同期されるべきです。クロックのオフセットと相対オフセットは、各測定と報告しなければなりません。
Time Interval Accuracy
時間間隔の精度
The accuracy of the t4-t1 interval is also critical to maintain and report. The difference between a clock's offsets at t1 and t4 is one source of error for the measurement and is associated with the clock's skew [RFC2330].
T4-T1間隔の精度も維持し、レポートすることが重要です。 t1とt4におけるクロックのオフセットの差は測定の誤差の一つのソースであり、クロックのスキュー[RFC2330]に関連しています。
A stable and reasonably accurate clock is needed to make the time interval measurements required by this memo. This source of error SHOULD be constrained to less than +/- 1 ms, implying 1-part-per-1000 frequency accuracy for a 1-second interval. This implies that greater stability is required as the length of the t4-t1 increases, in order to constrain the error to be less than +/- 1 ms.
安定的かつ合理的に正確なクロックは、このメモが必要とする時間間隔の測定を行うために必要とされます。エラーのこのソースは、1秒間隔で1部あたり-1000周波数精度を意味未満+/- 1ミリ秒に制限されるべきです。これは、より高い安定性がより少ない+/- 1ミリ秒であることがエラーを抑制するために、T4-T1の長さが増加するように要求されることを意味します。
There are other important aspects of clock operation:
クロック動作の他の重要な側面があります。
1. Synchronization protocols require some ability to make adjustments to the local clock. However, these adjustments (clock steps or slewing) can cause large errors if they occur during the t1 to t4 measurement interval. Clock correction SHOULD be suspended during a t1 to t4 measurement interval, unless the time interval accuracy requirement above will be met. Alternatively, a measurement SHOULD NOT be performed during clock correction, unless the time interval accuracy requirement above will be met.
1.同期プロトコルは、ローカルクロックの調整を行うためにいくつかの機能が必要とされます。彼らはT4の測定間隔にt1の間に発生した場合ただし、これらの調整（クロックステップやスルーは）大きな誤差が発生する可能性があります。クロック補正は、時間間隔精度要件は、上記満たされる場合を除き、測定間隔をt4までt1の間に中断されるべきです。時間間隔精度要件は、上記満たされる場合を除き代替として、測定は、クロック補正中に行われるべきではありません。
2. If a free-running clock is used to make the time interval measurement, then the time of day reported with the measurement (which is normally timestamp t1) SHOULD be derived from a different clock that meets the time-of-day accuracy requirements described above.
前記自走クロックが時間間隔の測定を行うために使用される場合、（通常はタイムスタンプT1）で測定して報告された時刻が時刻精度要件を満たす異なるクロックから導出されてください前述。
The physical operation of reading time from a clock may be constrained by the delay to service the interrupt. Therefore, if the accuracy of the time stamp read at t1 or t4 includes the interrupt delay, this source of error SHOULD be known and included in the error assessment.
クロックから時間を読み出す物理的な操作は、割り込みをサービスする遅延によって制約されてもよいです。 T1またはT4で読み出されたタイムスタンプの精度は、割り込み遅延を含む場合したがって、エラーのこのソースは知られており、エラーの評価に含まれるべきです。
In regard to all of the following metrics, t1 begins with the first associated SIP message sent by either UA, and is not reset if the UA must retransmit the same message, within the same transaction, multiple times. The first associated SIP message indicates the t1 associated with the user or application expectation relative to the request.
次のメトリックの全てに関して、t1はUAのいずれかによって送信された最初の関連するSIPメッセージで始まり、UAは、同じトランザクション、複数回の内、同じメッセージを再送信しなければならない場合にリセットされません。最初の関連のSIPメッセージは、ユーザまたは要求に対してアプリケーション期待に関連付けられたT1を示しています。
Some metrics are calculated using messages from different transactions in order to measure across actions such as redirection and failure recovery. The end time is typically based on a successful end-to-end provisional response, a successful final response, or a failure final response for which there is no recovery. The individual metrics detail which message to base the end time on.
いくつかのメトリックは、このようなリダイレクトや障害復旧などのアクション間で測定するために、異なるトランザクションからのメッセージを使用して計算されています。終了時間は、典型的には、成功したエンドツーエンドの暫定応答、成功した最終応答、または全く回復がないいる故障最終応答に基づいています。上の終了時間を基になるメッセージ個々のメトリック詳細。
The authentication method used to establish the SIP dialog will change the message exchanges. The example message exchanges used do not attempt to describe all of the various authentication types. Since authentication is frequently used, SIP Digest authentication was used for example purposes.
SIPダイアログを確立するために使用される認証方法は、メッセージ交換を変更します。使用例のメッセージ交換には、さまざまな認証タイプのすべてを説明しようとしないでください。認証が頻繁に使用されているため、SIPダイジェスト認証は、例示目的のために使用しました。
In regard to all of the metrics, the accuracy and granularity of the output values are related to the accuracy and granularity of the input values. Some of the metrics below are defined by a ratio. When the denominator of this ratio is 0, the metric is undefined.
メトリクスの全てに関して、出力値の精度と粒度は、入力値の精度と粒度に関連しています。以下のメトリックのいくつかは、比で定義されています。この比の分母が0である場合、メトリックは未定義です。
While these metrics do not specify the sample size, this should be taken into consideration. These metrics will provide a better indication of performance with larger sample sets. For example, some SIP Service Providers (SSPs) [RFC5486] may choose to collect input over an hourly, daily, weekly, or monthly timeframe, while another SSP may choose to perform metric calculations over a varying set of SIP dialogs.
これらのメトリックは、サンプルサイズを指定していないが、これは考慮すべきです。これらのメトリックは、より大きなサンプルセットとパフォーマンスのより良い指標を提供します。例えば、いくつかのSIPサービスプロバイダ（SSP）[RFC5486]は別のSSPは、SIPダイアログの変化セットに対してメトリック計算を実行することを選択するかもしれないが、毎時、毎日、毎週、または毎月の期間にわたって入力を収集することを選択することができます。
Registration Request Delay (RRD) is a measurement of the delay in responding to a UA REGISTER request. RRD SHALL be measured and reported only for successful REGISTER requests, while Ineffective Registration Attempts (Section 4.2) SHALL be reported for failures. This metric is measured at the originating UA. The output value of this metric is numerical and SHOULD be stated in units of milliseconds. The RRD is calculated using the following formula:
登録要求の遅延（RRD）は、UAのREGISTER要求への対応に遅れを測定することです。無効な登録の試み（4.2節）は故障のために報告しなければならない一方でRRDは、唯一成功したREGISTER要求のために測定し、報告しなければなりません。このメトリックは、発信UAで測定されます。このメトリックの出力値は、数値であり、ミリ秒単位で記載すべき。 RRDは、以下の式を用いて計算されます。
RRD = Time of Final Response - Time of REGISTER Request
最終回答のRRD =時間 - REGISTER要求の時間
In a successful registration attempt, RRD is defined as the time interval from when the first bit of the initial REGISTER message containing the necessary information is passed by the originating UA to the intended registrar, until the last bit of the 200 OK is received indicating the registration attempt has completed successfully. This dialog includes an expected authentication challenge prior to receiving the 200 OK as described in the following registration flow examples.
登録成功の試行で、RRDを示す200 OKの最後のビットが受信されるまで、必要な情報を含む最初のREGISTERメッセージの最初のビットは、意図されたレジストラへ発信UAによって渡されたときからの時間間隔として定義されます登録の試みが正常に完了しました。このダイアログは、以下の登録フロー例で説明したように200 OKを受信する前に、予想される認証チャレンジを含みます。
The following message exchange provides an example of identifiable events necessary for inputs in calculating RRD during a successful registration completion:
次のメッセージ交換が成功した登録完了時RRDを計算に入力するために必要な識別可能なイベントの例を提供します。
UA1 Registrar
| |
|REGISTER |
t1---->|--------------------->|
/\ | 401|
|| |<---------------------|
RRD |REGISTER |
|| |--------------------->|
\/ | 200|
t4---->|<---------------------|
| |
Note: Networks with elements using primarily Digest authentication will exhibit different RRD characteristics than networks with elements primarily using other authentication mechanisms (such as Identity). Operators monitoring RRD in networks with a mixture of authentication schemes should take note that the RRD measurements will likely have a multimodal distribution.
注：主にダイジェスト認証を使用して要素を有するネットワークは、主に（例えばIDとして）他の認証メカニズムを使用して要素とネットワークとは異なるRRD特性を示すであろう。認証方式の混合物とのネットワークのオペレータ監視RRD RRDは、測定は可能性の高いマルチモーダル分布を持つことになりますことにご注意ください。
Ineffective registration attempts are utilized to detect failures or impairments causing the inability of a registrar to receive a UA REGISTER request. This metric is measured at the originating UA. The output value of this metric is numerical and SHOULD be reported as a percentage of registration attempts.
無効登録の試みは、UA REGISTER要求を受信するように登録できないことを引き起こす故障や障害を検出するために利用されています。このメトリックは、発信UAで測定されます。このメトリックの出力値は、数値であり、登録の試みの百分率として報告されるべきです。
This metric is calculated as a percentage of total REGISTER requests. The IRA percentage is calculated using the following formula:
このメトリックは、総REGISTER要求の割合として計算されます。 IRAの割合は、以下の式を用いて計算されます。
# of IRAs
IRA % = ----------------------------- x 100
Total # of REGISTER Requests
A failed registration attempt is defined as a final failure response to the initial REGISTER request. It usually indicates a failure received from the destination registrar or interim proxies, or failure due to a timeout of the REGISTER request at the originating UA. A failure response is described as a 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or possible 6XX message. A timeout failure is identified by the Timer F expiring. IRAs may be used to detect problems in downstream signaling functions, which may be impairing the REGISTER message from reaching the intended registrar; or, it may indicate a registrar has become overloaded and is unable to respond to the request.
失敗した登録の試みは、初期REGISTERリクエストに対する最終的な失敗応答として定義されます。これは通常起因発信UAにおけるREGISTER要求のタイムアウト先レジストラまたは中間プロキシから受信した障害、または失敗を示します。失敗応答は（401、402、及び407の非故障チャレンジレスポンスコードを除く）4XX、5XX、または可能6XXメッセージとして記載されています。タイムアウトエラーは、タイマFの満了によって識別されます。 IRASは、意図レジストラに到達するREGISTERメッセージを損なうことができる下流のシグナル伝達機能に問題を検出するために使用することができます。または、それはレジストラが過負荷になり、要求に応答することができませんになったことを示すことがあります。
The following message exchange provides a timeout example of an identifiable event necessary for input as a failed registration attempt:
次のメッセージ交換が失敗した登録の試みとして入力するために必要な識別可能なイベントのタイムアウトの例を提供します。
UA1 Registrar
| |
|REGISTER |
|--------------------->|
|REGISTER |
|--------------------->|
|REGISTER |
|--------------------->|
| |
Failure ---->|***Timer F Expires |
| |
In the previous message exchange, UA1 retries a REGISTER request multiple times before the timer expires, indicating the failure. Only the first REGISTER request MUST be used for input to the calculation and an IRA. Subsequent REGISTER retries are identified by the same transaction identifier (the same topmost Via header field branch parameter value) and MUST be ignored for purposes of metric calculation. This ensures an accurate representation of the metric output.
前のメッセージ交換において、UA1は、タイマーが満了する前に登録が失敗したことを示す、複数回要求再試行します。最初のREGISTER要求を計算し、IRAへの入力のために使用されなければなりません。後続REGISTER再試行は、同じトランザクション識別子（ヘッダフィールド分岐パラメータ値経由同じ最上位）によって識別され、メトリック計算の目的のために無視しなければなりません。これは、メトリック出力の正確な表現を保証します。
The following message exchange provides a registrar servicing failure example of an identifiable event necessary for input as a failed registration attempt:
次のメッセージ交換が失敗した登録の試みとして入力するために必要な識別可能なイベントの登録サービス失敗例を提供します。
UA1 Registrar
| |
|REGISTER |
|--------------------->|
| |
| |
| |
| |
| 503|
Failure ---->|<---------------------|
| |
Session Request Delay (SRD) is utilized to detect failures or impairments causing delays in responding to a UA session request. SRD is measured for both successful and failed session setup requests as this metric usually relates to a user experience; however, SRD for session requests ending in a failure MUST NOT be combined in the same result with successful requests. The duration associated with success and failure responses will likely vary substantially, and the desired output time associated with each will be significantly different in many cases. This metric is similar to Post-Selection Delay defined in [E.721], and it is measured at the originating UA only. The output value of this metric MUST indicate whether the output is for successful or failed session requests and SHOULD be stated in units of seconds. The SRD is calculated using the following formula:
セッション要求遅延（SRD）は、UAセッション要求への応答の遅延を引き起こす故障や障害を検出するために利用されます。このメトリックは、通常、ユーザーエクスペリエンスに関連するSRDは、成功および失敗したセッション・セットアップ要求の両方について測定します。しかし、失敗に終わるセッション要求のためのSRDは、成功した要求と同じ結果に組み合わせてはなりません。成功と失敗の応答に関連する持続時間は、おそらく実質的に変化し、それぞれに関連付けられた所望の出力時間は、多くの場合有意に異なるであろう。このメトリックは、[E.721]で定義されたポストセレクション遅延に類似しており、それが唯一の発信元UAで測定されます。このメトリックの出力値は、出力が成功したか失敗したセッション要求のためのものであり、秒単位で記載すべきかどうかを指定する必要があります。 SRDは、以下の式を用いて計算されます。
SRD = Time of Status Indicative Response - Time of INVITE
ステータス意味するレスポンスのSRD =時間 - INVITEの時間
In a successful request attempt, SRD is defined as the time interval from when the first bit of the initial INVITE message containing the necessary information is sent by the originating user agent to the intended mediation or destination agent, until the last bit of the first provisional response is received indicating an audible or visual status of the initial session setup request. (Note: In some cases, the initial INVITE may be forked. Section 5.4 provides information for consideration on forking.) In SIP, the message indicating status would be a non-100 Trying provisional message received in response to an INVITE request. In some cases, a non-100 Trying provisional message is not received, but rather a 200 message is received as the first status message instead. In these situations, the 200 message would be used to calculate the interval. In most circumstances, this metric relies on receiving a non-100 Trying message. The use of the Provisional Response ACKnowledgement (PRACK) method [RFC3262] MAY improve the quality and consistency of the results.
成功した要求の試みにおいて、SRDは、第一の仮の最後のビットまで、初期の最初のビットが意図調停または宛先エージェントへの発信ユーザエージェントによって送信される必要な情報を含むINVITEメッセージときからの時間間隔として定義されます応答は、初期セッションセットアップ要求の可聴または視覚的ステータスを示す受信されます。 （注：いくつかのケースでは、最初のINVITEが二股されてもよいセクション5.4フォークに検討のための情報を提供する）SIPでは、ステータスを示すメッセージは、INVITE要求に応答して受信された非100試行仮メッセージであろう。いくつかの場合において、非100試行仮メッセージが受信されず、200メッセージではなく第1のステータスメッセージとして受信されます。これらの状況では、200メッセージは、間隔を計算するために使用されるであろう。ほとんどの状況では、このメトリックは、非100しようとメッセージを受信するに依存しています。暫定応答確認（PRACK）法[RFC3262]を使用することは、結果の品質と一貫性を改善することができます。
The following message exchange provides an example of identifiable events necessary for inputs in calculating SRD during a successful session setup request without a redirect (i.e., 3XX message):
次のメッセージ交換は、リダイレクト（すなわち、3XXメッセージ）なしで成功したセッション設定要求中SRDの計算に入力するために必要な識別可能なイベントの例を提供します。
UA1 UA2
| |
|INVITE |
t1---->|--------------------->|
/\ | |
|| | |
SRD | |
|| | |
\/ | 180|
t4---->|<---------------------|
| |
The following message exchange provides an example of identifiable events necessary for inputs in calculating SRD during a successful session setup with a redirect (e.g., 302 Moved Temporarily):
次のメッセージ交換は、リダイレクト（例えば、302は、一時的に移動）で成功したセッションセットアップ中SRDの計算に入力するために必要な識別可能なイベントの例を提供します。
UA1 Redirect Server UA2
| | |
|INVITE | |
t1---->|--------------------->| |
/\ | 302| |
|| |<---------------------| |
|| |ACK | |
SRD |--------------------->| |
|| |INVITE |
|| |------------------------------------------->|
\/ | 180|
t4---->|<-------------------------------------------|
In a failed request attempt, SRD is defined as the time interval from when the first bit of the initial INVITE message containing the necessary information is sent by the originating agent or user to the intended mediation or destination agent, until the last bit of the first provisional response or a failure indication response. A failure response is described as a 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or possible 6XX message. A change in the metric output might indicate problems in downstream signaling functions, which may be impairing the INVITE message from reaching the intended UA or may indicate changes in end-point behavior. While this metric calculates the delay associated with a failed session request, the metric Ineffective Session Attempts (Section 4.8) is used for calculating a ratio of session attempt failures.
失敗した要求の試みにおいて、SRDは、最初の最後のビットまで、初期の最初のビットが意図調停または宛先エージェントへの発信エージェントまたはユーザによって送信される必要な情報を含むINVITEメッセージときからの時間間隔として定義されます暫定応答または失敗の指示応答。失敗応答は（401、402、及び407の非故障チャレンジレスポンスコードを除く）4XX、5XX、または可能6XXメッセージとして記載されています。メトリック出力の変化は、意図UAに到達するINVITEメッセージを損なうことができる下流のシグナル伝達機能に問題を示すかもしれないまたはエンドポイントの動作の変化を示すことができます。このメトリックは、失敗したセッション要求に関連する遅延を計算しながら、メトリック無効なセッションの試み（セクション4.8）は、セッションの試みの失敗の割合を計算するために使用されます。
The following message exchange provides an example of identifiable events necessary for inputs in calculating SRD during a failed session setup attempt without a redirect (i.e., 3XX message):
次のメッセージ交換をリダイレクトせずに失敗したセッションのセットアップの試行中SRDの計算に入力するために必要な識別可能なイベントの例を提供する（すなわち、3XXメッセージ）：
UA1 UA2
| |
|INVITE |
t1---->|--------------------->|
/\ | |
|| | |
SRD | |
|| | |
\/ | 480|
t4---->|<---------------------|
| |
The following message exchange provides an example of identifiable events necessary for inputs in calculating SRD during a failed session setup attempt with a redirect (e.g., 302 Moved Temporarily):
次のメッセージ交換は、リダイレクト（例えば、302は、一時的に移動）との失敗したセッションのセットアップの試行中SRDの計算に入力するために必要な識別可能なイベントの例を提供します。
UA1 Redirect Server UA2
| | |
|INVITE | |
t1---->|--------------------->| |
/\ | 302| |
|| |<---------------------| |
|| |ACK | |
SRD |--------------------->| |
|| |INVITE |
|| |------------------------------------------->|
\/ | 480|
t4---->|<-------------------------------------------|
This metric is utilized to detect failures or impairments delaying the time necessary to end a session. SDD is measured for both successful and failed session disconnects; however, SDD for session disconnects ending in a failure MUST NOT be combined in the same result with successful disconnects. The duration associated with success and failure results will likely vary substantially, and the desired output time associated with each will be significantly different in many cases. It can be measured from either end-point UA involved in the SIP dialog. The output value of this metric is numerical and SHOULD be stated in units of milliseconds. The SDD is calculated using the following formula:
このメトリックは、セッションを終了するのに必要な時間を遅延故障や障害を検出するために利用されます。 SDDは、成功および失敗したセッションが切断の両方について測定します。しかし、失敗に終わるセッションが切断のためのSDDは、成功した切断と同じ結果に組み合わせてはなりません。成功と失敗の結果に関連付けられた持続時間は、おそらく実質的に変化し、それぞれに関連付けられた所望の出力時間は、多くの場合有意に異なるであろう。これは、SIPダイアログに関与いずれかのエンドポイントUAから測定することができます。このメトリックの出力値は、数値であり、ミリ秒単位で記載すべき。 SDDは、以下の式を用いて計算されます。
SDD = Time of 2XX or Timeout - Time of Completion Message (BYE)
SDDは= 2XXの時間やタイムアウト - 完了メッセージの時間（BYE）
SDD is defined as the interval between the first bit of the sent session completion message, such as a BYE, and the last bit of the subsequently received 2XX response. In some cases, a recoverable error response, such as a 503 Retry-After, may be received. In such situations, these responses should not be used as the end time for this metric calculation. Instead, the successful (2XX) response related to the recovery message is used. The following message exchanges provide an example of identifiable events necessary for inputs in calculating SDD during a successful session completion:
SDDは、BYEなどの送信セッション終了メッセージ、続いて受信した2xx応答の最後のビットの最初のビットとの間の間隔として定義されます。いくつかのケースでは、例えば503のような回復可能なエラー応答、再試行は、後に、受信されてもよいです。このような状況では、これらの応答は、このメトリックの計算の終了時刻として使用すべきではありません。代わりに、回復のメッセージに関連し成功した（2XX）応答が使用されています。次のメッセージ交換が成功し、セッション終了時にSDDを計算に入力するために必要な識別可能なイベントの例を提供します。
Measuring SDD at the originating UA (UA1) -
元のUA（UA1）でのSDDの測定 -
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|
|ACK |
|--------------------->|
|BYE |
t1---->|--------------------->|
/\ | |
|| | |
SDD | |
|| | |
\/ | 200|
t4---->|<---------------------|
Measuring SDD at the target UA (UA2) -
ターゲットUA（UA2）でのSDDの測定 -
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|
|ACK |
|--------------------->|
| BYE|
|<---------------------|<----t1
| | /\
| | ||
| | SDD
| | ||
|200 | \/
|--------------------->|<----t4
In some cases, no response is received after a session completion message is sent and potentially retried. In this case, the completion message, such as a BYE, results in a Timer F expiration. Sessions ending in this manner SHOULD be excluded from the metric calculation.
セッション終了メッセージが送信され、潜在的に再試行された後、いくつかのケースでは、応答が受信されません。この場合、完了メッセージは、例えばBYEように、タイマF満了になります。このように終わるのセッションは、メトリック計算から除外すべきです。
This metric is used to detect problems (e.g., poor audio quality) causing short session durations. SDT is measured for both successful and failed session completions. It can be measured from either end-point UA involved in the SIP dialog. This metric is similar to Call Hold Time, and it is traditionally calculated as Average Call Hold Time (ACHT) in telephony applications of SIP. The output value of this metric is numerical and SHOULD be stated in units of seconds. The SDT is calculated using the following formula:
このメトリックは、短いセッション期間を引き起こす問題（例えば、乏しい音質）を検出するために使用されます。 SDTは、成功および失敗したセッションの完了の両方について測定されます。これは、SIPダイアログに関与いずれかのエンドポイントUAから測定することができます。このメトリックは、ホールド時間コールに類似しており、それは伝統的にSIPの電話アプリケーションでの平均コール保留時間（アハト）として計算されます。このメトリックの出力値は、数値であり、秒単位で記載すべき。 SDTは、以下の式を用いて計算されます。
SDT = Time of BYE or Timeout - Time of 200 OK response to INVITE
SDT BYEまたはタイムアウトの時間= - INVITEに対する200 OK応答の時間
This metric does not calculate the duration of sessions leveraging early media. For example, some automated response systems only use early media by responding with a SIP 183 Session Progress message with the Session Description Protocol (SDP) connecting the originating UA with the automated message. Usually, in these sessions the originating UA never receives a 200 OK, and the message exchange ends with the originating UA sending a CANCEL.
このメトリックは、早期のメディアを活用したセッションの期間を計算しません。例えば、いくつかの自動応答システムは、自動化されたメッセージで発信UAを接続セッション記述プロトコル（SDP）とSIP 183 Session Progressメッセージで応答することにより、初期メディアを使用します。通常、これらのセッションに起因するUAは、200 OKを受けたことがない、とのメッセージ交換には、CANCELを送信元のUAで終わります。
In a successful session completion, SDT is calculated as an average and is defined as the duration of a dialog defined by the interval between receipt of the first bit of a 200 OK response to an INVITE, and receipt of the last bit of an associated BYE message indicating dialog completion. Retransmissions of the 200 OK and ACK messages due to network impairments do not reset the metric timers.
成功したセッション終了において、SDTは、平均として計算され、INVITEに対する200 OK応答の最初のビットの受信との間の間隔によって定義されたダイアログの継続時間、及び関連BYEの最後のビットを受信するように定義されますダイアログの完了を示すメッセージ。ネットワーク障害のために200のOKとACKメッセージの再送は、メトリックタイマーをリセットしません。
The following message exchanges provide an example of identifiable events necessary for inputs in calculating SDT during a successful session completion. (The message exchanges are changed between the originating and target UAs to provide varying examples.):
次のメッセージ交換が成功し、セッション終了時にSDTの計算に入力するために必要な識別可能なイベントの例を提供します。 （メッセージ交換は、様々な実施例を提供するために、発信元とターゲットのUA間で変化しています。）。
Measuring SDT at the originating UA (UA1) -
元のUA（UA1）でSDTの測定 -
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
t1---->|<---------------------|
/\ |ACK |
|| |--------------------->|
|| | |
SDT | |
|| | |
|| | |
\/ | BYE|
t4---->|<---------------------|
| |
When measuring SDT at the target UA (UA2), it is defined by the interval between sending the first bit of a 200 OK response to an INVITE, and receipt of the last bit of an associated BYE message indicating dialog completion. If UA2 initiates the BYE, then it is defined by the interval between sending the first bit of a 200 OK response to an INVITE, and sending the first bit of an associated BYE message indicating dialog completion. This is illustrated in the following example message exchange:
ターゲットUA（UA2）でSDTを測定する場合は、INVITE、200 OK応答の最初のビットを送信し、そしてダイアログ完了を示す関連したBYEメッセージの最後のビットの受信との間の間隔によって規定されます。 UA2は、BYEを開始する場合、それは、INVITEに対する200 OK応答の最初のビットを送信し、そしてダイアログ完了を示す関連したBYEメッセージの最初のビットの送信間隔によって定義されます。これは以下の例のメッセージ交換に示されています。
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|<----t1
|ACK | /\
|--------------------->| ||
| | ||
| | SDT
| | ||
| | ||
| BYE| \/
|<---------------------|<----t4
| |
(In these two examples, t1 is the same even if either UA receives the BYE instead of sending it.)
（いずれかのUAはそれを送信するのではなく、BYEを受信した場合でも、これらの2つの例では、t1は同じです。）
In some cases, no response is received after a session completion message is sent and potentially retried. In this case, SDT is defined as the interval between receiving the first bit of a 200 OK response to an INVITE, and the resulting Timer F expiration. The following message exchanges provide an example of identifiable events necessary for inputs in calculating SDT during a failed session completion attempt:
セッション終了メッセージが送信され、潜在的に再試行された後、いくつかのケースでは、応答が受信されません。この場合には、SDTは、INVITEに対する200 OK応答の最初のビットを受信し、そして得られたタイマFの有効期限の間隔として定義されます。次のメッセージ交換が失敗したセッション終了の試行中にSDTの計算に入力するために必要な識別可能なイベントの例を提供します。
Measuring SDT at the originating UA (UA1) -
元のUA（UA1）でSDTの測定 -
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
t1---->|<---------------------|
/\ |ACK |
|| |--------------------->|
|| |BYE |
SDT |--------------------->|
|| |BYE |
|| |--------------------->|
\/ | |
t4---->|***Timer F Expires |
When measuring SDT at UA2, SDT is defined as the interval between sending the first bit of a 200 OK response to an INVITE, and the resulting Timer F expiration. This is illustrated in the following example message exchange:
UA2でSDTを測定する場合、SDTは、INVITEに対する200 OK応答し、得られたタイマFの有効期限の最初のビットの送信間隔として定義されます。これは以下の例のメッセージ交換に示されています。
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|<----t1
| ACK| /\
|--------------------->| ||
| BYE| ||
|<---------------------| SDT
| BYE| ||
|<---------------------| ||
| | \/
| Timer F Expires***|<----t4
Note that in the presence of message loss and retransmission, the value of this metric measured at UA1 may differ from the value measured at UA2 up to the value of Timer F.
メッセージ損失および再送の存在下で、UA1で測定し、このメトリックの値は、タイマFの値までUA2で測定した値と異なる場合があります
This metric is used to detect the ability of a terminating UA or downstream proxy to successfully establish sessions per new session INVITE requests. SER is defined as the ratio of the number of new session INVITE requests resulting in a 200 OK response, to the total number of attempted INVITE requests less INVITE requests resulting in a 3XX response. This metric is similar to the Answer Seizure Ratio (ASR) defined in [E.411]. It is measured at the originating UA only. The output value of this metric is numerical and SHOULD be adjusted to indicate a percentage of successfully established sessions. The SER is calculated using the following formula:
このメトリックは、INVITE要求に成功し、新しいセッションごとのセッションを確立するために、終了UAの能力や下流のプロキシを検出するために使用されます。新たなセッションの数の比が試み要求が少ない3xx応答を生じるINVITE要求INVITEの総数に、200 OK応答を生じるINVITE要求としてSERが定義されます。このメトリックは、[E.411]で定義された回答発作比（ASR）と同様です。これは、唯一の元のUAで測定されます。このメトリックの出力値は、数値であり、正常に確立されたセッションのパーセンテージを示すように調整されるべきです。 SERは、以下の式を用いて計算されます。
# of INVITE Requests w/ associated 200 OK
SER = --------------------------------------------------------- x 100
(Total # of INVITE Requests) -
(# of INVITE Requests w/ 3XX Response)
The following message exchange provides an example of identifiable events necessary for inputs in determining session establishment as described above:
次のメッセージ交換は、上記のようにセッション確立を決定する際に入力するために必要な識別可能なイベントの例を提供します。
UA1 UA2
| |
|INVITE |
+----------->|------------------>|
| | 180|
| |<------------------|
Session Established | |
| | |
| | 200|
+----------->|<------------------|
| |
The following is an example message exchange including a SIP 302 Redirect response.
以下は、SIP 302リダイレクト応答を含む例示的なメッセージ交換です。
UA1 UA2 UA3
| | |
|INVITE | |
+----------->|------------------>| |
| | | |
INVITE w/ 3XX Response | | |
| | 302| |
+----------->|<------------------| |
| | |
|INVITE |
+----------->|-------------------------------------->|
| | |
| | 180|
Session Established |<--------------------------------------|
| | |
| | 200|
+----------->|<--------------------------------------|
| |
This metric is complimentary to SER, but is intended to exclude the potential effects of an individual user of the target UA from the metric. SEER is defined as the ratio of the number of INVITE requests resulting in a 200 OK response and INVITE requests resulting in a 480, 486, 600, or 603; to the total number of attempted INVITE requests less INVITE requests resulting in a 3XX response. The response codes 480, 486, 600, and 603 were chosen because they clearly indicate the effect of an individual user of the UA. It is possible an individual user could cause a negative effect on the UA. For example, they may have misconfigured the UA, causing a response code not directly related to an SSP, but this cannot be easily determined from an intermediary B2BUA somewhere between the originating and terminating UAs. With this in consideration, response codes such as 401, 407, and 420 (not an exhaustive list) were not included in the numerator of the metric. This metric is similar to the Network Effectiveness Ratio (NER) defined in [E.411]. It is measured at the originating UA only. The output value of this metric is numerical and SHOULD be adjusted to indicate a percentage of successfully established sessions less common UAS failures.
このメトリックは、SERに無料ですが、メトリックからターゲットUAの個々のユーザーの潜在的な影響を排除することを意図しています。 SEERは480、486、600、または603で得られた200 OK応答を生じるINVITE要求し、INVITEリクエストの数の比として定義されます。試みの総数に対する要求がより少ない3xx応答を生じるINVITE要求INVITE。彼らは明らかUAの個々のユーザの効果を示すため、応答コード480、486、600、及び603を選択しました。個々のユーザーがUAに悪影響を引き起こす可能性が可能です。例えば、それらは直接SSPに関連しない応答コードを引き起こし、UAを誤って設定している場合があり、これは、容易に発信と着信のUA間のどこか中間B2BUAから決定することができません。考慮しこれにより、応答コードは、401、407、420（非網羅的リスト）としてメトリックの分子に含まれていませんでした。このメトリックは、[E.411]で定義されたネットワーク効果比（NER）に類似しています。これは、唯一の元のUAで測定されます。このメトリックの出力値は、数値であり、正常に確立されたセッションあまり一般的UASの失敗のパーセンテージを示すように調整されるべきです。
The SEER is calculated using the following formula:
SEERは、以下の式を用いて計算されます。
SEER =
SEER =
# of INVITE Requests w/ associated 200, 480, 486, 600, or 603
------------------------------------------------------------- x 100
(Total # of INVITE Requests) -
(# of INVITE Requests w/ 3XX Response)
Reference the example flows in Section 4.6.
例を参照4.6節に流れます。
Ineffective session attempts occur when a proxy or agent internally releases a setup request with a failed or overloaded condition. This metric is similar to Ineffective Machine Attempts (IMAs) in telephony applications of SIP, and was adopted from Telcordia GR-512-CORE [Section 12"">GR-512]. The output value of this metric is numerical and SHOULD be adjusted to indicate a percentage of ineffective session attempts. The following failure responses provide a guideline for this criterion:
プロキシまたはエージェントが内部的に失敗したか、過負荷状態でのセットアップ要求を離したときに、無効セッションの試行が発生します。このメトリックは、SIPの電話アプリケーションにおいて無効マシン試み（のIMA）と同様であり、のTelcordia GR-512-CORE [セクション12「」> GR-512]から採用しました。このメトリックの出力値は、数値であり、無効セッションの試行の割合を示すように調整されるべきです。次の障害応答は、この基準のためのガイドラインを提供します。
o 408 Request Timeout
408要求タイムアウトO
o 500 Server Internal Error
500 O Serverの内部エラー
o 503 Service Unavailable
503サービスを使用できませんO
o 504 Server Time-out
504 Oサーバーのタイムアウト
This set was derived in a similar manner as described in Section 4.7. In addition, 408 failure responses may indicate an overloaded state with a downstream element; however, there are situations other than overload that may cause an increase in 408 responses.
セクション4.7で説明したように、このセットは、同様の方法で得られました。また、408の失敗応答は、下流要素との過負荷状態を示すことができます。しかし、408の応答の増加を引き起こす可能性があり、過負荷以外の状況があります。
This metric is calculated as a percentage of total session setup requests. The ISA percentage is calculated using the following formula:
このメトリックは、全セッションセットアップ要求の割合として計算されます。 ISAの割合は、以下の式を用いて計算されます。
# of ISAs
ISA % = ----------------------------- x 100
Total # of Session Requests
The following dialog [RFC3665] provides an example describing message exchanges of an ineffective session attempt:
次のダイアログ[RFC3665]は無効セッションの試みのメッセージ交換を説明する例を提供します。
UA1 Proxy 1 Proxy 2 UA2
| | | |
|INVITE | | |
|--------------->| | |
| 407| | |
|<---------------| | |
|ACK | | |
|--------------->| | |
|INVITE | | |
|--------------->|INVITE | |
| 100|--------------->|INVITE |
|<---------------| 100|--------------->|
| |<---------------| |
| | |INVITE |
| | |--------------->|
| | | |
| | |INVITE |
| | |--------------->|
| | | |
| | 408| |
| 408|<---------------| |
|<---------------|ACK | |
| |--------------->| |
|ACK | | |
|--------------->| | |
A session completion is defined as a SIP dialog, which completes without failing due to a lack of response from an intended proxy or UA. This metric is similar to the Call Completion Ratio (CCR) in telephony applications of SIP. The output value of this metric is numerical and SHOULD be adjusted to indicate a percentage of successfully completed sessions.
セッション終了は意図プロキシまたはUAからの応答の欠如に起因する失敗せずに完了SIPダイアログ、として定義されます。このメトリックは、SIPの電話アプリケーションでの通話完了率（CCR）に似ています。このメトリックの出力値は、数値であり、正常に完了したセッションの割合を示すように調整されるべきです。
This metric is calculated as a percentage of total sessions completed successfully. The SCR percentage is calculated using the following formula:
このメトリックは、正常に完了し、全セッションの割合として計算されます。 SCRの割合は、以下の式を用いて計算されます。
# of Successfully Completed Sessions
SCR % = --------------------------------------- x 100
Total # of Session Requests
The following dialog [RFC3665] provides an example describing the necessary message exchanges of a successful session completion:
次のダイアログ[RFC3665]は成功したセッション終了の必要なメッセージ交換を説明する例を提供します。
UA1 Proxy 1 Proxy 2 UA2
| | | |
|INVITE | | |
|--------------->| | |
| 407| | |
|<---------------| | |
|ACK | | |
|--------------->| | |
|INVITE | | |
|--------------->|INVITE | |
| 100|--------------->|INVITE |
|<---------------| 100|--------------->|
| |<---------------| |
| | | 180|
| | 180 |<---------------|
| 180|<---------------| |
|<---------------| | 200|
| | 200|<---------------|
| 200|<---------------| |
|<---------------| | |
|ACK | | |
|--------------->|ACK | |
| |--------------->|ACK |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE|
| | BYE|<---------------|
| BYE|<---------------| |
|<---------------| | |
|200 | | |
|--------------->|200 | |
| |--------------->|200 |
| | |--------------->|
| | | |
These metrics may be used to determine the performance of a domain and/or user. The following is an example subset of dimensions for providing further granularity per metric:
これらのメトリックは、ドメインおよび/またはユーザの性能を決定するために使用することができます。以下は、メトリックごとにさらに細分性を提供するための寸法の一例のサブセットです。
o To "user"
「ユーザー」へO
o From "user"
「ユーザー」からO
o Bi-direction "user"
O双方向「ユーザー」
o To "domain"
「ドメイン」にO
o From "domain"
「ドメイン」からO
o Bi-direction "domain"
O双方向「ドメイン」
A B2BUA may impact the ability to collect these metrics with an end-to-end perspective. It is necessary to realize that a B2BUA may act as an originating UAC and terminating UAS, or it may act as a proxy. In some cases, it may be necessary to consider information collected from both sides of the B2BUA in order to determine the end-to-end perspective. In other cases, the B2BUA may act simply as a proxy allowing data to be derived as necessary for the input into any of the listed calculations.
B2BUAは、エンドツーエンドの視点でこれらのメトリックを収集する能力に影響を与える可能性があります。 B2BUAは、発信UACとUAS終端として作用することができる、またはそれはプロキシとして作用し得ることを理解する必要があります。いくつかの場合において、エンド・ツー・エンドの視点を決定するために、B2BUAの両側から収集された情報を検討する必要があるかもしれません。他の場合では、B2BUAは、単にデータが記載されている計算のいずれかに入力するために必要なように導出されることを可能にするプロキシとして作用することができます。
During the process of setting up a SIP dialog, various authentication methods may be utilized. These authentication methods will add to the duration as measured by the metrics, and the length of time will vary based on those methods. The failures of these authentication methods will also be captured by these metrics, since SIP is ultimately used to indicate the success or failure of the authorization and/or authentication attempt. The metrics in Section 3 are inclusive of the duration associated with this process, even if the method is external to SIP. This was included purposefully, due to its inherent impact on the protocol and the subsequent SIP dialogs.
SIPダイアログをセットアップするプロセスの間に、様々な認証方法を利用することができます。メトリックによって測定される、これらの認証方法は、持続時間に追加され、時間の長さは、それらの方法に基づいて変化するであろう。 SIPは、最終的に認可および/または認証の試行の成功または失敗を示すために使用されているので、これらの認証方法の失敗はまた、これらのメトリックによって捕獲されます。第3のメトリックは、方法は、SIPの外部にある場合であっても、このプロセスに関連付けられた期間が含まれています。これは、プロトコルとそれに続くSIPダイアログに固有の影響により、意図的に含まれていました。
Forking SHOULD be considered when determining the messages associated with the input values for the described metrics. If all of the forked dialogs were used in the metric calculations, the numbers would skew dramatically. There are two different points of forking, and each MUST be considered. First, forking may occur at a proxy downstream from the UA that is being used for metric input values. The downstream proxy is responsible for forking a message. Then, this proxy will send provisional (e.g., 180) messages received from the requests and send the accepted (e.g., 200) response to the UA.
説明メトリックの入力値に関連するメッセージを決定するときにフォークを考慮すべきです。フォークのダイアログのすべてがメトリック計算に使用された場合は、数字が劇的にスキューでしょう。フォーク、そしてそれぞれが考慮されなければならないの異なる2点があります。まず、フォークは、メトリック入力値に使用されているUAから下流代理で行うことができます。下流のプロキシはメッセージをフォークする責任があります。次いで、このプロキシは、要求から仮（例えば、180）メッセージを受信送信し、UAに受け入れられる（例えば、200）レスポンスを送信します。
Second, in the cases where the originating UA or proxy is forking the messages, then it MUST parse the message exchanges necessary for input into the metrics. For example, it MAY utilize the first INVITE or set of INVITE messages sent and the first accepted 200 OK. Tags will identify this dialog as distinct from the other 200 OK responses, which are acknowledged, and an immediate BYE is sent. The application responsible for capturing and/or understanding the input values MUST utilize these tags to distinguish between dialog requests.
第二に、発信UAまたはプロキシがメッセージを分岐される場合には、それはメトリックに入力するために必要なメッセージ交換を解析する必要があります。例えば、それは、INVITE最初または送信され、最初の200 OKを受け入れたINVITEメッセージのセットを利用することができます。タグが承認されると、すぐにBYEが送信され、他の200のOK応答、と区別して、このダイアログを識別します。キャプチャおよび/または入力値を理解するための責任アプリケーションは、ダイアログの要求を区別するために、これらのタグを利用しなければなりません。
Note that if an INVITE is forked before reaching its destination, multiple early dialogs are likely, and multiple confirmed dialogs are possible (though unlikely). When this occurs, an SRD measurement should be taken for each dialog that is created (early or confirmed).
その目的地に到達する前にフォークされたINVITE場合、複数の早期ダイアログがそうである、と（そうが）複数の確認のダイアログが可能であることに注意してください。これが発生すると、SRDの測定は、（早期または確認）が作成され、各ダイアログのために取られるべきです。
The input necessary for these calculations may be collected in a number of different manners. It may be collected or retrieved from call detail records (CDRs) or raw signaling information generated by a proxy or UA. When using records, time synchronization MUST be considered between applicable elements.
これらの計算に必要な入力は、多くの異なる方法で収集することができます。これは、呼詳細レコード（CDR）を、またはプロキシまたはUAによって生成された生シグナリング情報から収集または取得されてもよいです。レコードを使用する場合は、時刻の同期は、該当する要素の間に考えなければなりません。
If these metrics are calculated at individual elements (such as proxies or endpoints) instead of by a centralized management system, and the individual elements use different measurement sample sizes, then the metrics reported for the same event at those elements may differ significantly.
これらの指標は、（例えばプロキシまたはエンドポイントのような）個々の要素で代わりに集中管理システムによって計算され、個々の要素は、異なる測定試料サイズを使用している場合は、それらの要素で同じイベントに関して報告メトリックは著しく異なっていてもよいです。
The information may also be transmitted through the use of network management protocols like the Simple Network Management Protocol (SNMP) and via future extensions to the SIP Management Information Base (MIB) modules [RFC4780], or through a potential undefined new performance metric event package [RFC3265] retrieved via SUBSCRIBE requests.
情報は、簡易ネットワーク管理プロトコル（SNMP）のようなネットワーク管理プロトコルを使用して、およびSIP管理情報ベース（MIB）のモジュールへの将来の拡張[RFC4780]を経由して、または潜在的な未定義の新しいパフォーマンスメトリックイベントパッケージを介して送信することができますSUBSCRIBEリクエストを介して取得[RFC3265]。
Data may be collected for a sample of calls or all calls, and may also be derived from test call scenarios. These metrics are flexible based on the needs of the application.
データは、通話またはすべての通話のサンプルのために収集することができ、また、試験コールシナリオに由来してもよいです。これらのメトリックは、アプリケーションのニーズに基づいて柔軟です。
For consistency in calculation of the metrics, elements should expect to reveal event inputs for use by a centralized management system, which would calculate the metrics based on a varying set sample size of inputs received from elements compliant with this specification.
メトリックの計算における一貫性のために、要素は、この仕様に準拠要素から受信した入力の変化設定サンプルサイズに基づいてメトリックを計算することになる、集中管理システムにより使用するためのイベント入力を明らかにすることを期待すべきです。
In some cases, these metrics will be used to provide output values to signify the performance level of a specific SIP-based element. When using these metrics in a test environment, the environment MUST be accurately documented for the purposes of replicating any output values in future testing and/or validation.
いくつかのケースでは、これらのメトリックは、特定のSIPベースの素子の性能レベルを示すために出力値を提供するために使用されます。テスト環境でこれらの指標を使用する場合、環境を正確に将来の試験および/または検証に任意の出力値を複製する目的のために文書化されなければなりません。
This document provides a description of common performance metrics and their defined use with SIP. The use of these metrics will provide a common viewpoint across all vendors, service providers, and users. These metrics will likely be utilized in production telephony SIP environments for providing input regarding Key Performance Indicators (KPI) and Service Level Agreement (SLA) indications; however, they may also be used for testing end-to-end SIP-based service environments.
この文書では、一般的なパフォーマンスメトリックの説明とSIPとの定義された使用を提供します。これらのメトリックを使用すると、すべてのベンダー、サービスプロバイダー、およびユーザーに共通の視点を提供します。これらのメトリックは、おそらく主要業績指標（KPI）とサービスレベル契約（SLA）の適応症に関する入力を提供するための生産テレフォニーSIP環境で利用されるであろう。しかし、それらはまた、エンドツーエンドのSIPベースのサービス環境をテストするために使用することができます。
Security should be considered in the aspect of securing the relative data utilized in providing input to the above calculations. All other aspects of security should be considered as described in RFC 3261 [RFC3261].
セキュリティは、上記の計算への入力を提供するのに利用される相対的なデータを確保する態様で考慮されるべきです。 RFC 3261 [RFC3261]に記載されているようにセキュリティのすべての他の側面を考慮すべきです。
Implementers of these metrics MUST realize that these metrics could be used to describe characteristics of customer and user usage patterns, and privacy should be considered when collecting, transporting, and storing them.
これらのメトリックの実装者は、これらの指標は、顧客やユーザーの使用パターンの特性を記述するために使用することができ、プライバシーは、収集運搬、及びそれらを格納するときに考慮すべきことを認識しなければなりません。
The following people made substantial contributions to this work:
次の人は、この仕事にかなりの貢献をしました。
Carol Davids Illinois Institute of Technology Marian Delkinov Ericsson Adam Uzelac Global Crossing Jean-Francois Mule CableLabs Rich Terpstra Level 3 Communications
技術マリアンDelkinovエリクソンアダムUzelacグローバル・クロッシングジャン=フランソワラバCableLabsのリッチテルプストラレベル3コミュニケーションズのキャロル・ダービッツイリノイ大学
We would like to thank Robert Sparks, John Hearty, and Dean Bayless for their efforts in reviewing the document and providing insight regarding clarification of certain aspects described throughout the document. We also thank Dan Romascanu for his insightful comments and Vijay Gurbani for agreeing to perform the role of document shepherd.
私たちは、ドキュメントをレビューし、文書全体で説明した特定の側面の明確化についての洞察を提供する彼らの努力のためにロバート・スパークス、ジョン・ハーティ、およびディーンBaylessに感謝したいと思います。また、文書の羊飼いの役割を実行することに同意のための彼の洞察に満ちたコメントのダンRomascanuとビジェイGurbaniに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[RFC3665]ジョンストン、A.、ドノバン、S.、スパークス、R.、カニンガム、C.、およびK.サマーズ、 "セッション開始プロトコル（SIP）の基本的なコールフローの例"、BCP 75、RFC 3665、2003年12月。
[RFC4780] Lingle, K., Mule, J-F., Maeng, J., and D. Walker, "Management Information Base for the Session Initiation Protocol (SIP)", RFC 4780, April 2007.
[RFC4780] Lingle、K.、ラバ、J-F。、Maeng、J.、およびD.ウォーカー、 "セッション開始プロトコル（SIP）のための管理情報ベース"、RFC 4780、2007年4月。
[E.411] ITU-T, "Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors", E.411 , March 2000.
[E.411] ITU-T、 "シリーズE：総合ネットワークオペレーション、電話サービス、サービスオペレーションとヒューマンファクター"、E.411、2000年3月。
[E.721] ITU-T, "Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors", E.721 , May 1999.
[E.721] ITU-T、 "シリーズE：総合ネットワークオペレーション、電話サービス、サービスオペレーションとヒューマンファクター"、E.721、1999年5月。
[GR-512] Telcordia, "LSSGR: Reliability, Section 12", GR-512- CORE Issue 2, January 1998.
[GR-512]のTelcordia、 "LSSGR：信頼性、第12"、GR-512- CORE発行2、1998年1月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]マラス、D.とD.マイヤー、 "マルチメディアインターコネクトのためのセッションピアリング（SPEERMINT）用語"、RFC 5486、2009月。
Authors' Addresses
著者のアドレス
Daryl Malas CableLabs 858 Coal Creek Circle Louisville, CO 80027 US
ダリル・マラスCableLabsの858コールクリークサークルルイビル、CO 80027米国
Phone: +1 303 661 3302 EMail: d.malas@cablelabs.com
電話：+1 303 661 3302 Eメール：d.malas@cablelabs.com
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 US
アルモートンAT＆T Labsの200ローレルアベニュー南ミドルタウン、NJ 07748米国
Phone: +1 732 420 1571 EMail: acmorton@att.com
電話：+1 732 420 1571 Eメール：acmorton@att.com