summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6076.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6076.txt')
-rw-r--r--doc/rfc/rfc6076.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc6076.txt b/doc/rfc/rfc6076.txt
new file mode 100644
index 0000000..c8bafc6
--- /dev/null
+++ b/doc/rfc/rfc6076.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Malas
+Request for Comments: 6076 CableLabs
+Category: Standards Track A. Morton
+ISSN: 2070-1721 AT&T Labs
+ January 2011
+
+
+ Basic Telephony SIP End-to-End Performance Metrics
+
+Abstract
+
+ This document defines a set of metrics and their usage to evaluate
+ the performance of end-to-end Session Initiation Protocol (SIP) for
+ telephony services in both production and testing environments. The
+ purpose of this document is to combine a standard set of common
+ metrics, allowing interoperable performance measurements, easing the
+ comparison of industry implementations.
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 1]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 2]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+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
+
+ 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.
+
+ 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
+
+
+
+Malas & Morton Standards Track [Page 3]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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:
+
+ o Network connectivity
+
+ o Switch and router performance
+
+ o Server processes and hardware performance
+
+ 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.
+
+ 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.
+
+ 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.
+
+2. Terminology
+
+ 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].
+
+
+
+
+Malas & Morton Standards Track [Page 4]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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].
+
+3. Time Interval Measurement and Reporting
+
+ 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
+
+ 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).
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 5]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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).
+
+ t4 - end time
+
+ 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).
+
+ Note: The designations t2 and t3 are reserved for future use at
+ another interface involved in satisfying a request.
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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].
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 6]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+4. SIP Performance Metrics
+
+ 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.
+
+ 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.
+
+
+
+
+
+Malas & Morton Standards Track [Page 7]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+4.1. Registration Request Delay (RRD)
+
+ 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 = Time of Final Response - Time of REGISTER Request
+
+ 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.
+
+ The following message exchange provides an example of identifiable
+ events necessary for inputs in calculating RRD during a successful
+ registration completion:
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 8]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+4.2. Ineffective Registration Attempts (IRAs)
+
+ 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.
+
+ This metric is calculated as a percentage of total REGISTER requests.
+ The IRA percentage is calculated using the following formula:
+
+ # 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.
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 9]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+ 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 ---->|<---------------------|
+ | |
+
+4.3. Session Request Delay (SRD)
+
+ 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
+
+
+
+Malas & Morton Standards Track [Page 10]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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 = Time of Status Indicative Response - Time of INVITE
+
+4.3.1. Successful Session Setup 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.
+
+ 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):
+
+ UA1 UA2
+ | |
+ |INVITE |
+ t1---->|--------------------->|
+ /\ | |
+ || | |
+ SRD | |
+ || | |
+ \/ | 180|
+ t4---->|<---------------------|
+ | |
+
+
+
+
+Malas & Morton Standards Track [Page 11]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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):
+
+ UA1 Redirect Server UA2
+ | | |
+ |INVITE | |
+ t1---->|--------------------->| |
+ /\ | 302| |
+ || |<---------------------| |
+ || |ACK | |
+ SRD |--------------------->| |
+ || |INVITE |
+ || |------------------------------------------->|
+ \/ | 180|
+ t4---->|<-------------------------------------------|
+
+4.3.2. Failed Session Setup SRD
+
+ 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.
+
+ 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):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 12]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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):
+
+ UA1 Redirect Server UA2
+ | | |
+ |INVITE | |
+ t1---->|--------------------->| |
+ /\ | 302| |
+ || |<---------------------| |
+ || |ACK | |
+ SRD |--------------------->| |
+ || |INVITE |
+ || |------------------------------------------->|
+ \/ | 480|
+ t4---->|<-------------------------------------------|
+
+4.4. Session Disconnect Delay (SDD)
+
+ 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 = Time of 2XX or Timeout - Time of Completion Message (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
+
+
+
+Malas & Morton Standards Track [Page 13]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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:
+
+ Measuring SDD at the originating UA (UA1) -
+
+ UA1 UA2
+ | |
+ |INVITE |
+ |--------------------->|
+ | 180|
+ |<---------------------|
+ | 200|
+ |<---------------------|
+ |ACK |
+ |--------------------->|
+ |BYE |
+ t1---->|--------------------->|
+ /\ | |
+ || | |
+ SDD | |
+ || | |
+ \/ | 200|
+ t4---->|<---------------------|
+
+ Measuring SDD at the target UA (UA2) -
+
+ UA1 UA2
+ | |
+ |INVITE |
+ |--------------------->|
+ | 180|
+ |<---------------------|
+ | 200|
+ |<---------------------|
+ |ACK |
+ |--------------------->|
+ | BYE|
+ |<---------------------|<----t1
+ | | /\
+ | | ||
+ | | SDD
+ | | ||
+ |200 | \/
+ |--------------------->|<----t4
+
+
+
+Malas & Morton Standards Track [Page 14]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+4.5. Session Duration Time (SDT)
+
+ 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 = Time of BYE or Timeout - Time of 200 OK response to INVITE
+
+ 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.
+
+4.5.1. Successful Session Duration SDT
+
+ 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.
+
+ 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.):
+
+
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 15]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ Measuring SDT at the originating UA (UA1) -
+
+ 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:
+
+ UA1 UA2
+ | |
+ |INVITE |
+ |--------------------->|
+ | 180|
+ |<---------------------|
+ | 200|
+ |<---------------------|<----t1
+ |ACK | /\
+ |--------------------->| ||
+ | | ||
+ | | SDT
+ | | ||
+ | | ||
+ | BYE| \/
+ |<---------------------|<----t4
+ | |
+
+
+
+
+
+Malas & Morton Standards Track [Page 16]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ (In these two examples, t1 is the same even if either UA receives the
+ BYE instead of sending it.)
+
+4.5.2. Failed Session Completion SDT
+
+ 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:
+
+ Measuring SDT at the originating UA (UA1) -
+
+ 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 17]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+4.6. Session Establishment Ratio (SER)
+
+ 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:
+
+ # 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:
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 18]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ UA1 UA2
+ | |
+ |INVITE |
+ +----------->|------------------>|
+ | | 180|
+ | |<------------------|
+ Session Established | |
+ | | |
+ | | 200|
+ +----------->|<------------------|
+ | |
+
+ The following is an example message exchange including a SIP 302
+ Redirect response.
+
+ UA1 UA2 UA3
+ | | |
+ |INVITE | |
+ +----------->|------------------>| |
+ | | | |
+ INVITE w/ 3XX Response | | |
+ | | 302| |
+ +----------->|<------------------| |
+ | | |
+ |INVITE |
+ +----------->|-------------------------------------->|
+ | | |
+ | | 180|
+ Session Established |<--------------------------------------|
+ | | |
+ | | 200|
+ +----------->|<--------------------------------------|
+ | |
+
+4.7. Session Establishment Effectiveness Ratio (SEER)
+
+ 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
+
+
+
+Malas & Morton Standards Track [Page 19]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+ The SEER is calculated using the following formula:
+
+ 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.8. Ineffective Session Attempts (ISAs)
+
+ 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:
+
+ o 408 Request Timeout
+
+ o 500 Server Internal Error
+
+ o 503 Service Unavailable
+
+ o 504 Server Time-out
+
+ 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.
+
+ This metric is calculated as a percentage of total session setup
+ requests. The ISA percentage is calculated using the following
+ formula:
+
+
+
+
+
+Malas & Morton Standards Track [Page 20]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ # of ISAs
+ ISA % = ----------------------------- x 100
+ Total # of Session Requests
+
+ The following dialog [RFC3665] provides an example describing message
+ exchanges of an ineffective session attempt:
+
+ UA1 Proxy 1 Proxy 2 UA2
+ | | | |
+ |INVITE | | |
+ |--------------->| | |
+ | 407| | |
+ |<---------------| | |
+ |ACK | | |
+ |--------------->| | |
+ |INVITE | | |
+ |--------------->|INVITE | |
+ | 100|--------------->|INVITE |
+ |<---------------| 100|--------------->|
+ | |<---------------| |
+ | | |INVITE |
+ | | |--------------->|
+ | | | |
+ | | |INVITE |
+ | | |--------------->|
+ | | | |
+ | | 408| |
+ | 408|<---------------| |
+ |<---------------|ACK | |
+ | |--------------->| |
+ |ACK | | |
+ |--------------->| | |
+
+4.9. Session Completion Ratio (SCR)
+
+ 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.
+
+ This metric is calculated as a percentage of total sessions completed
+ successfully. The SCR percentage is calculated using the following
+ formula:
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 21]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ # 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:
+
+ 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 |
+ | | |--------------->|
+ | | | |
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 22]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+5. Additional Considerations
+
+5.1. Metric Correlations
+
+ 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 From "user"
+
+ o Bi-direction "user"
+
+ o To "domain"
+
+ o From "domain"
+
+ o Bi-direction "domain"
+
+5.2. Back-to-Back User Agent (B2BUA)
+
+ 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.
+
+5.3. Authorization and Authentication
+
+ 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.
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 23]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+5.4. Forking
+
+ 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.
+
+ 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.
+
+ 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).
+
+5.5. Data Collection
+
+ 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.
+
+ 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.
+
+
+
+
+Malas & Morton Standards Track [Page 24]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+ 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.
+
+5.6. Testing Documentation
+
+ 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.
+
+6. Conclusions
+
+ 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.
+
+7. Security Considerations
+
+ 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].
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 25]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+8. Contributors
+
+ 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
+
+9. Acknowledgements
+
+ 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.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+ [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
+ Provisional Responses in Session Initiation Protocol
+ (SIP)", RFC 3262, June 2002.
+
+ [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
+ Event Notification", RFC 3265, June 2002.
+
+ [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.
+
+ [RFC4780] Lingle, K., Mule, J-F., Maeng, J., and D. Walker,
+ "Management Information Base for the Session Initiation
+ Protocol (SIP)", RFC 4780, April 2007.
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 26]
+
+RFC 6076 SIP End-to-End Performance Metrics January 2011
+
+
+10.2. Informative References
+
+ [E.411] ITU-T, "Series E: Overall Network Operation, Telephone
+ Service, Service Operation and Human Factors", E.411 ,
+ March 2000.
+
+ [E.721] ITU-T, "Series E: Overall Network Operation, Telephone
+ Service, Service Operation and Human Factors", E.721 ,
+ May 1999.
+
+ [GR-512] Telcordia, "LSSGR: Reliability, Section 12", GR-512-
+ CORE Issue 2, January 1998.
+
+ [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+ "Framework for IP Performance Metrics", RFC 2330,
+ May 1998.
+
+ [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
+ Interconnect (SPEERMINT) Terminology", RFC 5486,
+ March 2009.
+
+Authors' Addresses
+
+ 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
+
+ Phone: +1 732 420 1571
+ EMail: acmorton@att.com
+
+
+
+
+
+
+
+
+
+
+Malas & Morton Standards Track [Page 27]
+