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
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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
本文档的范围仅限于从电话环境中的端到端角度测量和报告SIP性能的一组标准度量标准的定义。这些度量为理解和量化服务提供者、供应商和基于SIP的服务用户之间的性能期望提供了一个共同的基础。预定的
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.
本文档的读者可以在网络运营商中找到，他们通常收集网络对客户服务请求的响应信息。
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.
本文件不提供下文定义的SIP性能指标的任何数字目标或接受阈值，因为这些项目一般不在IETF活动范围内。
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消息（进入被测网络）是用于测试目的的专用消息，或者消息是用户启动的，并且存在部分实时流量。这两种情况有时分别称为主动测量和被动测量。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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”、“到”和“从”头字段标记标识。
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).
这是开始连续时间间隔的时间瞬间（发送请求时）。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]是t1和公认的主要时间源（如UTC）之间的差值（偏移量=t1-UTC）。
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.
需要一个稳定且合理准确的时钟来进行本备忘录要求的时间间隔测量。该误差源应限制在+/-1ms以内，这意味着1秒间隔内的频率精度为每1000个频率的1个部分。这意味着随着t4-t1长度的增加，需要更大的稳定性，以便将误差限制在+/-1 ms以内。
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必须在同一事务中多次重新传输同一消息，则不会重置t1。第一个相关联的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注册请求响应延迟的度量。只有成功的注册请求才应测量和报告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的最后一位的时间间隔。如以下注册流示例所述，此对话框包括在接收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---->|<---------------------|
| |
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.
注意：与元素主要使用其他身份验证机制（如身份验证）的网络相比，元素主要使用摘要身份验证的网络将表现出不同的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
# 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 expiring标识。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 |
| |
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 ---->|<---------------------|
| |
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
会话请求延迟（SRD）用于检测导致UA会话请求响应延迟的故障或损伤。SRD针对成功和失败的会话设置请求进行测量，因为该指标通常与用户体验有关；但是，以失败结束的会话请求的SRD不能组合在同一个会话中
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:
以成功请求为结果。与成功和失败响应相关的持续时间可能会有很大的不同，并且在许多情况下，与每个响应相关的期望输出时间会有很大的不同。该指标类似于[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被定义为从原始用户代理将包含必要信息的初始INVITE消息的第一位发送到预期的中介或目标代理的时间间隔，直到收到指示初始会话设置请求的音频或视频状态的第一个临时响应的最后一位。（注意：在某些情况下，初始INVITE可能会被分叉。第5.4节提供了有关分叉的考虑信息。）在SIP中，指示状态的消息将是响应INVITE请求而收到的非100次尝试的临时消息。在某些情况下，不接收非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):
以下消息交换提供了在无重定向（即3XX消息）的成功会话设置请求期间计算SRD所需输入的可识别事件示例：
UA1 UA2
| |
|INVITE |
t1---->|--------------------->|
/\ | |
|| | |
SRD | |
|| | |
\/ | 180|
t4---->|<---------------------|
| |
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---->|<-------------------------------------------|
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消息的第一位发送到预期的中介或目标代理的时间间隔，直到第一个临时响应或故障指示响应的最后一位。故障响应被描述为4XX（不包括401、402和407非故障质询响应代码）、5XX或可能的6XX消息。度量输出中的变化可能指示下游信令功能中的问题，这可能妨碍INVITE消息到达预期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):
以下消息交换提供了在没有重定向（即3XX消息）的失败会话设置尝试期间计算SRD时输入所需的可识别事件的示例：
UA1 UA2
| |
|INVITE |
t1---->|--------------------->|
/\ | |
|| | |
SRD | |
|| | |
\/ | 480|
t4---->|<---------------------|
| |
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---->|<-------------------------------------------|
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
SDD定义为发送的会话完成消息（如BYE）的第一位与随后收到的2XX响应的最后一位之间的间隔。在某些情况下，可恢复的
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:
可能会收到错误响应，例如503重试后。在这种情况下，这些响应不应用作此度量计算的结束时间。而是使用与恢复消息相关的成功（2XX）响应。以下消息交换提供了在成功完成会话期间计算SDD输入所需的可识别事件示例：
Measuring SDD at the originating UA (UA1) -
在始发UA（UA1）处测量SDD-
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|
|ACK |
|--------------------->|
|BYE |
t1---->|--------------------->|
/\ | |
|| | |
SDD | |
|| | |
\/ | 200|
t4---->|<---------------------|
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
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.
此指标不计算利用早期媒体的会话持续时间。例如，一些自动响应系统仅通过使用会话描述协议（SDP）的SIP 183会话进度消息进行响应来使用早期媒体，该会话描述协议（SDP）将发起UA与自动消息连接起来。通常，在这些会话中，始发UA从未收到200 OK，消息交换以始发UA发送CANCEL结束。
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时输入所需的可识别事件的示例。（原始UAs和目标UAs之间的消息交换已更改，以提供不同的示例。）：
Measuring SDT at the originating UA (UA1) -
在始发UA（UA1）处测量SDT-
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
t1---->|<---------------------|
/\ |ACK |
|| |--------------------->|
|| | |
SDT | |
|| | |
|| | |
\/ | BYE|
t4---->|<---------------------|
| |
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，则它由向INVITE发送200 OK响应的第一位与发送指示对话完成的相关BYE消息的第一位之间的间隔来定义。下面的消息交换示例说明了这一点：
UA1 UA2
| |
|INVITE |
|--------------------->|
| 180|
|<---------------------|
| 200|
|<---------------------|<----t1
|ACK | /\
|--------------------->| ||
| | ||
| | SDT
| | ||
| | ||
| BYE| \/
|<---------------------|<----t4
| |
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.)
（在这两个示例中，t1是相同的，即使任一UA收到BYE而不是发送BYE。）
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 |
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
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响应的新会话INVITE请求数与尝试INVITE请求总数减去导致3XX响应的INVITE请求数之比。该指标类似于[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)
# 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|
+----------->|<------------------|
| |
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|
+----------->|<--------------------------------------|
| |
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
该指标是对SER的补充，但旨在从指标中排除目标UA的单个用户的潜在影响。SEER定义为导致200 OK响应的INVITE请求数与导致480、486、600或603的INVITE请求数之比；尝试的INVITE请求总数减去导致3XX响应的INVITE请求。选择响应代码480、486、600和603是因为它们清楚地指示了UA的单个用户的影响。个人用户可能会对UA造成负面影响。例如，他们可能对UA进行了错误配置，导致响应代码与SSP没有直接关系，但这无法从用户之间的某个中介B2BUA轻松确定
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.
发起和终止UAs。考虑到这一点，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)
# 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电话应用中的无效机器尝试（IMA），并从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
# 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 | | |
|--------------->| | |
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.
会话完成被定义为SIP对话，该对话完成时不会由于缺少来自预期代理或UA的响应而失败。该指标类似于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
# 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 |
| | |--------------->|
| | | |
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.
在确定与所述度量的输入值相关联的消息时，应考虑分叉。如果在度量计算中使用了所有分叉对话框，则数字将显著倾斜。分叉有两个不同的点，每个点都必须考虑。首先，分叉可能发生在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或一组INVITE消息和第一个接受的200 OK。标签会将此对话框标识为与其他200个确认的OK响应不同，并立即发送BYE。负责捕获和/或理解输入值的应用程序必须利用这些标记来区分对话框请求。
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.
信息还可以通过使用网络管理协议（如简单网络管理协议（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中的定义用途。这些指标的使用将为所有供应商、服务提供商和用户提供一个共同的视角。这些指标可能会在生产电话SIP环境中用于提供有关关键性能指标（KPI）和服务级别协议（SLA）指示的输入；然而，它们也可用于测试端到端基于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
卡罗尔·戴维斯伊利诺伊理工学院玛丽安·德尔基诺夫·爱立信·亚当·乌泽拉克全球穿越让·弗朗索瓦·穆勒电缆实验室里希·特普斯特拉三级通信
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同意担任文档守护者的角色。
[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：会话启动协议”，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 32622，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，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 36652003年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 47802007年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.41119000年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.7211999年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，“多媒体互连的会话对等（SPEERMINT）术语”，RFC 54862009年3月。
Authors' Addresses
作者地址
Daryl Malas CableLabs 858 Coal Creek Circle Louisville, CO 80027 US
Daryl Malas CableLabs 858美国科罗拉多州路易斯维尔市煤溪圈80027
Phone: +1 303 661 3302
EMail: d.malas@cablelabs.com
Phone: +1 303 661 3302
EMail: d.malas@cablelabs.com
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 US
美国新泽西州劳雷尔大道南米德尔顿200号阿尔莫顿AT&T实验室，邮编：07748
Phone: +1 732 420 1571
EMail: acmorton@att.com
Phone: +1 732 420 1571
EMail: acmorton@att.com