[要約] RFC 6076は、SIPベースのテレフォニーのエンドツーエンドのパフォーマンスメトリクスに関する基本的な情報を提供する。このRFCの目的は、SIPベースのテレフォニーシステムのパフォーマンスを評価し、改善するための指標を提供することである。
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
基本的なテレフォニーSIPエンドツーエンドのパフォーマンスメトリック
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
エンドツーエンド - これは、リクエストを開始し、リクエストを受信し、リクエストに応答するために使用される2つ以上の要素として説明されています。必要に応じて、発信元のユーザーエージェントクライアント（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ダイアログに関連するパフォーマンスを測定します。したがって、それらはセッション要求の遅延、セッション切断の遅延などと呼ばれます。多くのメトリックのタイトルにはこの用語が含まれていますが、シグナルの側面のみを具体的に測定しています。各セッションは、一意の「Call-Id」、「to」、および「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の発信元の招待セットアップリクエストに応じて、セッションのセットアップリクエストが成功したことを示しています。
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.
このメモで定義されているメトリックの多くは、2つのイベント間の時間間隔を評価するために時計を利用しています。このセクションでは、時間関連の用語とレポート要件を定義します。
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).
これは、連続時間間隔を開始する時間瞬間（リクエストが送信されるとき）です。T1は、指定されたリクエストがSIPアプリケーションによって処理され、リクエストパケットの最初のビットがUAまたはプロキシから送信されたときに発生します（また、一部の論理または物理インターフェイスで外部的に観察可能です）。
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は、各リクエスト応答テストが開始される時間を表し、特定の測定が行われた時刻を指定するために使用されます（たとえば、「T1」（特定のUAインターフェイス）でのセッション要求遅延が測定されました。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).
これは、関連するリクエストが送信されたときに開始された連続時間間隔を締めくくる時期です。T4は、指定された応答の最後のビットが、要求デバイスのSIPアプリケーションによって受信されたときに発生します（そして、いくつかの論理または物理インターフェイスで外部的に観察可能です）。
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]は、UTC（Offset = T1 -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でのクロックのオフセットの違いは、測定の1つのエラーの原因であり、クロックのスキュー[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秒の間隔で1分の100パーセントの周波数精度を意味します。これは、エラーを /-1 ms未満に制限するために、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. 同期プロトコルには、ローカルクロックを調整する能力が必要です。ただし、これらの調整（クロックステップまたはスリーニング）は、T1〜T4測定間隔中に発生すると大きなエラーを引き起こす可能性があります。上記の時間間隔の精度要件が満たされない限り、T1からT4測定間隔中にクロック補正を中断する必要があります。あるいは、上記の時間間隔の精度要件が満たされない限り、クロック修正中に測定を実行しないでください。
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.
2. フリーランニングクロックを使用して時間間隔測定を行う場合、測定値（通常はタイムスタンプ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 Digest認証は、たとえば目的で使用されました。
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]は、1時間ごと、毎日、毎週、または毎月の時間枠で入力を収集することを選択できますが、別の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レジスタリクエストへの応答の遅延の測定です。RRDは測定され、登録要求が成功した場合にのみ報告されますが、無効な登録試行（セクション4.2）は障害について報告されます。このメトリックは、発生するUAで測定されます。このメトリックの出力値は数値であり、ミリ秒単位で記載する必要があります。RRDは、次の式を使用して計算されます。
RRD = Time of Final Response - Time of REGISTER Request
rrd =最終応答の時間 - 登録リクエストの時間
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は、必要な情報を含む最初のレジスタメッセージの最初のビットが、発信された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レジスタリクエストを受け取ることができないことを引き起こす障害または障害を検出するために利用されます。このメトリックは、発生するUAで測定されます。このメトリックの出力値は数値であり、登録試行の割合として報告する必要があります。
This metric is calculated as a percentage of total REGISTER requests. The IRA percentage is calculated using the following formula:
このメトリックは、総レジスタリクエストの割合として計算されます。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.
失敗した登録試行は、最初のレジスタリクエストに対する最終的な失敗応答として定義されます。通常、宛先レジストラまたは暫定委任者から受け取った失敗、または発信元のUAでのレジスタリクエストのタイムアウトによる障害を示します。障害応答は、4xx（401、402、および407の非潜入課題の応答コードを除く）、5xx、または可能な6xxメッセージとして説明されています。タイムアウトの障害は、タイマーFの期限切れによって識別されます。IRAは、下流のシグナル伝達関数の問題を検出するために使用される場合があります。または、レジストラが過負荷になり、リクエストに応答できないことを示している場合があります。
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はタイマーの有効期限が切れる前にレジスタリクエストを複数回取得し、障害を示します。計算とIRAへの入力には、最初のレジスタリクエストのみを使用する必要があります。後続のレジスタレトリは、同じトランザクション識別子（ヘッダーフィールドブランチパラメーター値を介して最上部）によって識別され、メトリック計算の目的で無視する必要があります。これにより、メトリック出力の正確な表現が保証されます。
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 =ステータスの時間指示応答 - 招待時間
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は、必要な情報を含む最初の招待メッセージの最初のビットから、発信者エージェントによって意図した調停または宛先エージェントに最初の暫定的なビットまで送信されるときの時間間隔として定義されます。応答が受信され、初期セッションセットアップリクエストの可聴または視覚的ステータスを示します。（注：場合によっては、最初の招待状が分岐する場合があります。セクション5.4は、フォーキングに関する考慮事項を提供します。）SIPでは、招待状リクエストに応じて受信した暫定的なメッセージを示すメッセージが表示されます。場合によっては、100以外の試行暫定メッセージは受信されませんが、代わりに最初のステータスメッセージとして200メッセージが受信されます。これらの状況では、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):
次のメッセージ交換は、リダイレクトなしのセッションセットアップリクエストの成功中にSRDを計算する際の入力に必要な識別可能なイベントの例を提供します（つまり、3xxメッセージ）：
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):
次のメッセージ交換は、リダイレクトを使用したセッションセットアップの成功中にSRDを計算する際の入力に必要な識別可能なイベントの例を提供します（たとえば、302が一時的に移動しました）：
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は、必要な情報を含む最初の招待メッセージの最初のビットから、発信元のエージェントまたはユーザーによって、最初のメディエーションまたは宛先エージェントに送信されるときの時間間隔として定義されます。暫定的な応答または障害表示応答。障害応答は、4xx（401、402、および407の非潜入課題の応答コードを除く）、5xx、または可能な6xxメッセージとして説明されています。メトリック出力の変化は、下流のシグナル伝達関数の問題を示している可能性があります。これは、意図したUAに到達することから招待メッセージを損なう可能性があるか、エンドポイント挙動の変化を示す可能性があります。このメトリックは、セッションリクエストの失敗に関連する遅延を計算しますが、メトリックの無効なセッション試行（セクション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):
次のメッセージ交換は、リダイレクトを使用したセッションセットアップの失敗試行中にSRDの計算際の入力に必要な識別可能なイベントの例を提供します（たとえば、302が一時的に移動しました）：
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またはタイムアウトの時間 - 完了メッセージ（さようなら）
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のテレフォニーアプリケーションで平均コールホールド時間（ACHT）として計算されています。このメトリックの出力値は数値であり、秒単位で記載する必要があります。SDTは、次の式を使用して計算されます。
SDT = Time of BYE or Timeout - Time of 200 OK response to INVITE
SDT =さようならまたはタイムアウトの時間 - 招待への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.
このメトリックは、初期のメディアを活用するセッションの期間を計算しません。たとえば、一部の自動化された応答システムは、SIP 183セッションの進行メッセージで応答して、セッション説明プロトコル（SDP）を使用して、発信元のUAを自動化されたメッセージと接続することにより、早期メディアのみを使用します。通常、これらのセッションでは、発生するUAが200 OKを受信することはなく、メッセージ交換はキャンセルを送信する発信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は平均として計算され、招待に対する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.): Measuring SDT at the originating UA (UA1) -
次のメッセージ交換は、セッション完了の成功中にSDTを計算する際の入力に必要な識別可能なイベントの例を提供します。（メッセージ交換は、さまざまな例を提供するために発信元とターゲットUAの間で変更されます。）：発信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を測定する場合、招待に200 OK応答の最初のビットを送信する間の間隔と、ダイアログ完了を示す関連するBYEメッセージの最後のビットの受領との間隔によって定義されます。UA2がBYEを開始する場合、招待に最初のビットの200 OK応答を送信することと、ダイアログの完了を示す関連付属のメッセージの最初のビットを送信する間の間隔によって定義されます。これは、次の例のメッセージ交換に示されています。
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.)
（これらの2つの例では、いずれかのUAが送信する代わりにさようならを受け取ったとしても、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は、招待に対する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は、招待に200 OK応答の最初のビットを送信する間の間隔として定義されます。これは、次の例のメッセージ交換に示されています。
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で測定されたこのメトリックの値は、UA2で測定された値からタイマーFの値まで異なる場合があることに注意してください。
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:
このメトリックは、新しいセッションの招待リクエストごとにセッションを正常に確立するための終了UAまたは下流のプロキシの能力を検出するために使用されます。SERは、200のOK応答をもたらす新しいセッションの招待リクエストの数の比として定義されます。これは、3xx応答をもたらす招待リクエストの少ない招待リクエストの合計数に定義されます。このメトリックは、[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応答と招待リクエストをもたらします。試行された招待リクエストの総数に対して、3xxの応答をもたらす招待リクエストが少なくなります。応答コード480、486、600、および603は、UAの個々のユーザーの効果を明確に示しているため、選択されました。個々のユーザーがUAに悪影響を与える可能性があります。たとえば、彼らはUAを誤って構成し、SSPに直接関係しない応答コードを引き起こした可能性がありますが、これは、発信元と終了のUAの間の中間B2BUAから簡単に決定することはできません。これを考慮して、401、407、420（網羅的なリストではない）などの応答コードは、メトリックの分子に含まれていませんでした。このメトリックは、[e.411]で定義されているネットワーク有効性比（NER）に似ています。発生するUAでのみ測定されます。このメトリックの出力値は数値であり、正常に確立されたセッションの割合が少ない一般的なUAS障害を示すように調整する必要があります。
The SEER is calculated using the following formula:
先見者は、次の式を使用して計算されます。
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 [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のテレフォニーアプリケーションにおける効果のないマシンの試み（IMAS）に似ており、Telcordia GR-512-CORE [GR-512]から採用されました。このメトリックの出力値は数値であり、効果のないセッションの試行の割合を示すように調整する必要があります。次の障害応答は、この基準のガイドラインを提供します。
o 408 Request Timeout
o 408リクエストタイムアウト
o 500 Server Internal Error
o 500サーバー内部エラー
o 503 Service Unavailable
o 503サービスは利用できません
o 504 Server Time-out
o 504サーバーのタイムアウト
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またはプロキシがメッセージを分岐している場合、メトリックへの入力に必要なメッセージ交換を解析する必要があります。たとえば、送信された最初の招待状または招待メッセージのセットを使用し、最初に受け入れられた200 OKを利用する場合があります。タグは、このダイアログを他の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).
目的地に到達する前に招待状が分岐した場合、複数の早期ダイアログが可能性が高く、複数の確認されたダイアログが可能である可能性が高いことに注意してください。これが発生した場合、作成されるダイアログごとに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.
この情報は、Simple Network Management Protocol（SNMP）などのネットワーク管理プロトコルの使用や、SIP管理情報ベース（MIB）モジュール[RFC4780]、または潜在的な未定義の新しいパフォーマンスメトリックイベントパッケージへの将来の拡張を介して送信される場合があります。[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
キャロル・デイビッドイリノイ工科大学マリアン・デルキノフ・エリクソン・アダム・ウゼラック・グローバル・クロッシングジャン・フランソワ・ミュール・ケイブルラブリッチ・テルプストラレベル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.
ドキュメントをレビューし、文書全体で説明されている特定の側面の明確化に関する洞察を提供してくれたRobert Sparks、John Hearty、Dean Baylessに感謝します。また、Dan Romascanuの洞察に満ちたコメントとVijay GurbaniがDocument Shepherdの役割を果たしてくれたことに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定応答の信頼性」、RFC 3262、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（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.、Mule、J-F。、Maeng、J。、およびD. Walker、「セッション開始プロトコルの管理情報基盤（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-コア号2、1998年1月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486] Malas、D。およびD. Meyer、「Multimedia Interconnect（Speermint）用語のセッションピアリング」、RFC 5486、2009年3月。
Authors' Addresses
著者のアドレス
Daryl Malas CableLabs 858 Coal Creek Circle Louisville, CO 80027 US
Daryl Malas CableLabs 858 Coal Creek Circle Louisville、Co 80027 US
Phone: +1 303 661 3302
EMail: d.malas@cablelabs.com
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 US
Al Morton AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748 US
Phone: +1 732 420 1571
EMail: acmorton@att.com