SIPPING Working Group A. Pendleton Nortel A.Clark Telchemy A. Johnston Avaya H. Sinnreich Adobe Internet Draft Intended status: Informational March 5, 2009 Expires: September 2009 RTCP-XR Summary draft-ietf-sipping-rtcp-summary-06 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 14, 2009. Copyright and License Notice Copyright (c) 2009 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 Pendleton Expires September 2009 [Page 1] Internet-Draft RTCP-XR Summary March 2009 Documents in effect on the date of publication of this document (http://trustee.ietf.org/licenseinfo). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. Table of Contents 1. Introduction...................................................3 1.1. Applicability Statement...................................3 1.2. Usage Scenarios...........................................3 2. Terminology....................................................5 3. SIP Events for Voice over IP Performance Reporting.............6 3.1. SUBSCRIBE/NOTIFY method...................................6 3.2. PUBLISH method............................................6 3.3 Multi-Party and Multi-Segment Calls......................7 3.3. Overload Avoidance........................................7 4. Event Package Formal Definition................................8 4.1. Event Package Name........................................8 4.2. Event Package Parameters..................................8 4.3. SUBSCRIBE Bodies..........................................8 4.4. Subscription Duration.....................................8 4.5. NOTIFY and PUBLISH Bodies.................................8 4.6. Voice Quality Event Syntax and Semantics..................9 4.6.1. ABNF Syntax Definition...............................9 4.6.2. Parameter Definitions and Mappings..................19 4.7. Message Flow and Syntax Examples.........................27 4.7.1. End of Session Report using NOTIFY..................27 4.7.2. Mid Session Threshold Violation using NOTIFY........29 4.7.3. End of Session Report using PUBLISH.................32 4.7.4. Alert Report using PUBLISH..........................34 4.8. Configuration Dataset for vq-rtcpxr Events...............36 5. IANA Considerations...........................................36 5.1. SIP Event Package Registration...........................36 5.2. application/vq-rtcp-xr MIME Registration.................36 6. Security Considerations.......................................37 7. Contributors..................................................37 8. Normative References..........................................37 Pendleton Expires September 2009 [Page 2] Internet-Draft RTCP-XR Summary March 2009 1. Introduction Real time communications over IP networks use SIP for signaling with RTP/RTCP for media transport and reporting respectively. These protocols are very flexible and can support an extremely wide spectrum of usage scenarios. For this reason, extensions to these protocols must be specified in the context of a specific usage scenario. In this memo, extensions to SIP are proposed to support the reporting of Real-Time Control Protocol Extended Reports [4] metrics. 1.1. Applicability Statement RTP is utilized in many different architectures and topologies. RFC 5117 [13] lists and describes the following topologies: point to point, point to multipoint using multicast, point to multipoint using the RFC 3550 translator, point to multipoint using the RFC 3550 mixer model, point to multipoint using video switching MCUs, point to multipoint using RTCP-terminating MCU, and non-symmetric mixer/translators. As the abstract to this document points out, this specification is for reporting quality of Voice over Internet Protocol(VoIP) sessions. As such, only the first topology, point to point, is currently supported by this specification. This reflects both current VoIP deployments which are predominantly point to point using unicast, and also the state of research in the area of quality. How to accurately report the quality of a multipart conference or a session involving multiple hops through translators and mixers is currently an area of research in the industry. This mechanism could be extended to cover additional RTP topologies in the future once these topics progress out of the realm of research and into actual Internet deployments. 1.2. Usage Scenarios The usage scenarios addressed in this memo are situations where a SIP user agent can easily report the voice quality since it communicates with a small number of other endpoints: 1. Point-to-point VoIP conversations. These can include small telephony type multiparty scenarios, such as when using call transfer. 2. Conference calls using a central conferencing server when each SIP endpoint can report on the quality of their leg to the central conferencing server. Pendleton Expires September 2009 [Page 3] Internet-Draft RTCP-XR Summary March 2009 3. Multicast VoIP calls using source specific multicast (SSM). This is somewhat similar to the central conferencing scenario. Distributed conferences with audio mixing in the endpoints may require reporting on too many call legs and may be therefore less practical if there are more than 3-4 participants. The usage scenarios 1, 2, and 3 provide voice quality reports that are most closely related to the user experience, since the reporting application resides in the endpoints, such as in SIP UAs (UA). Many SIP UAs however may have limitations as to the footprint of the software and as a result frugal reporting capabilities are preferable. RTCP reports are usually sent to other participating endpoints in a session which can make collection of performance information by administration or management systems too complex. In the usage scenarios addressed in this memo, the data contained in RTCP XR VoIP metrics reports (RFC3611 [4]) are forwarded to a central collection server systems using SIP. Applications residing in the server or elsewhere can aid in network management to alleviate bandwidth constraints and also to support customer service by identifying and acknowledging calls of poor quality. Specifying such applications are however beyond the scope of this paper. Keeping it Simple There is a large portfolio of quality parameters that can be associated with VoIP, but only a minimal necessary number of parameters are included on the RTCP-XR reports: 1. The codec type, as resulting from the SDP offer-answer negotiation in SIP, 2. The burst gap loss density and max gap duration, since voice cut-outs are the most annoying quality impairment in VoIP, 3. Round trip delay because it is critical to conversational quality, 4. Conversational quality as a catch-all for other voice quality impairments, such as random distributed packet loss, jitter, annoying silent suppression effects, etc. Pendleton Expires September 2009 [Page 4] Internet-Draft RTCP-XR Summary March 2009 In specific usage scenarios where other parameters are required, designers can include other parameters beyond the scope of this paper. RTCP reports are best effort only, and though very useful have a number of limitations as discussed in [3]. This must be considered when using RTCP reports in managed networks. This document defines a new SIP event package, vq-rtcpxr, and a new MIME type, application/vq-rtcpxr, that enable the collection and reporting of metrics that measure quality for RTP [3] sessions. The definitions of the metrics used in the event package are based on RTCP Extended Reports [4] and RTCP [3]; a mapping between the SIP event parameters and the parameters within the aforementioned RFC's is defined within this document in section 4.6.2. Monitoring of voice quality is believed to be the highest priority for usage of this mechanism and as such, the metrics in the event package are largely tailored for voice quality measurements. The event package is designed to be extensible. However the negotiation of such extensions is not defined in this document. The event package supports reporting both the voice quality metrics for both inbound and outbound directions. Voice quality metrics for the inbound direction can generally be computed locally by the reporting endpoint however voice quality metrics for the outbound direction are computed by the remote endpoint and sent to the reporting endpoint using the RTCP Extended Reports [4]. Configuration of usage of the event package is not covered in this document. It is the recommendation of this document that the SIP configuration framework [8] be used. The authors have defined a configuration dataset that would facilitate this support in section 5.8. The event package SHOULD be used with the SUBSCRIBE/NOTIFY method however it MAY be also used with the PUBLISH method for backward compatibility with some existing implementations. Message flow examples for both methods are provided in this document. 2. Terminology 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 [1]. Pendleton Expires September 2009 [Page 5] Internet-Draft RTCP-XR Summary March 2009 3. SIP Events for Voice over IP Performance Reporting This document defines a SIP events package [5] for Voice over IP performance reporting. A SIP UA can send these events to an entity which can make the information available to other applications. For purposes of illustration, the entities involved in SIP vq-rtcpxr event reporting will be referred to as follows: o REPORTER is an entity involved in the measurement and reporting of media quality i.e. the SIP UA involved in a media session. o COLLECTOR is an entity that receives SIP vq-rtcpxr events. A COLLECTOR may be a proxy server or another entity that is capable of supporting SIP vq-rtcpxr events. 3.1. SUBSCRIBE/NOTIFY method The REPORTER SHOULD send the voice quality metric reports using the NOTIFY method. The COLLECTOR SHALL send a SUBSCRIBE to the REPORTER to explicitly establish the relationship. Configuration of an address of the COLLECTOR is not needed as explained below. The REPORTER MUST NOT send any vq-rtcpxr events if a COLLECTOR address has not been configured. The REPORTER populates the Request-URI according to the rules for an in-dialog request. The COLLECTOR MAY send a SUBSCRIBE to a SIP Proxy acting on behalf of the reporting SIP UA's. 3.2. PUBLISH method A SIP UA that supports this specification MAY also send the service quality metric reports using the PUBLISH method, however this approach SHOULD NOT be used in unmanaged Internet services. The Publish method MAY be supported for backward compatibility with existing implementations. The REPORTER MAY therefore populate the Request-URI of the PUBLISH method with the address of the COLLECTOR. To ensure security of SIP proxies and the COLLECTOR, the REPORTER MUST be configured with the address of the COLLECTOR, preferably using the SIP UA configuration framework [8], as described in section 5.8. Pendleton Expires September 2009 [Page 6] Internet-Draft RTCP-XR Summary March 2009 It is recommended that the REPORTER send an OPTIONS message to the COLLECTOR to ensure support of the PUBLISH message. 3.3 Multi-Party and Multi-Segment Calls A voice quality metric report may be sent for each session terminating at the REPORTER and may contain multiple report bodies. For a multi-party call the report MAY contain report bodies for the session between the reporting endpoint and each remote endpoint for which there was an RTP session during the call. Multi-party services such as call hold and call transfer can result in the user participating in a series of concatenated sessions, potentially with different choices of codec or sample rate, although these may be perceived by the user as a single call. A REPORTER MAY send a voice quality metric report at the end of each session or MAY send a single voice quality metric report containing a report body for each segment of the call. 3.3. Overload Avoidance Users of this extension should ensure they implement general SIP mechanisms for avoiding overload. For instance, an overloaded proxy or COLLECTOR MUST send a 503 Service Unavailable or other 5xx esponse with an appropriate Retry-After time specified. REPORTERs MUST act on these responses and respect the retry after time interval. In addition, future SIP extensions to better handle overload as covered in [14] should be followed as they are standardized. To avoid overload of SIP Proxies or COLLECTORS it is important to do capacity planning and to minimize the number of reports that are sent. Approaches to avoiding overload include: a. Send only one report at the end of each call b. Use interval reports only on "problem" calls that are being closely monitored c. Limit the number of alerts that can be sent to a maximum of one per call. Pendleton Expires September 2009 [Page 7] Internet-Draft RTCP-XR Summary March 2009 4. Event Package Formal Definition 4.1. Event Package Name This document defines a SIP Event Package as defined in RFC 3265 [5]. 4.2. Event Package Parameters No event package parameters are defined. 4.3. SUBSCRIBE Bodies SUBSCRIBE bodies are described by this specification. 4.4. Subscription Duration Subscriptions to this event package MAY range from minutes to weeks. Subscriptions in hours or days are more typical and are RECOMMENDED. The default subscription duration for this event package is one hour. 4.5. NOTIFY and PUBLISH Bodies There are three notify bodies: a Session report, an Interval session report, and an Alert report. The Session report SHOULD be used for reporting when a voice media session terminates or when a media change occurs, such as a codec change or a session forks and MUST NOT be used for reporting at arbitrary points in time. This report MUST be used for cumulative metric reporting and the report timestamps MUST be from the start of a media session to the time at which the report is generated. The Interval report SHOULD be used for periodic or interval reporting and MUST NOT be used for reporting for the complete media session. This report is intended to capture short duration metric reporting and the report intervals SHOULD be non-overlapping time windows. The Alert report MAY be used when voice quality degrades during a session. The time window to which an Alert report relates MAY be a short time interval or from the start of the call to the point the alert is generated; this time window SHOULD be selected to provide the most useful information to support problem diagnosis. Session, Interval and Alert reports MUST populate the metrics with values that are measured over the interval explicitly defined by the "start" and "stop" timestamps. Pendleton Expires September 2009 [Page 8] Internet-Draft RTCP-XR Summary March 2009 This specification defines a new MIME type application/vq-rtcpxr which is a text encoding of the RTCP and RTCP-XR statistics with some additional metrics and correlation information. 4.6. Voice Quality Event Syntax and Semantics This section describes the syntax extensions required for event publication in SIP. The formal syntax definitions described in this section are expressed in the Augmented BNF [6] format used in SIP [2], and contains references to elements defined therein. Additionally, the definition of the timestamp format is provided in [7]. Note that most of the parameters are optional. In practice, most implementations will send a subset of the parameters. It is not the intention of this document to define what parameters may or may not be useful for monitoring the quality of a voice session, but to enable reporting of voice quality. As such, the syntax allows the implementer to choose which metrics are most appropriate for their solution. As there are no "invalid", "unknown", or "not applicable" values in the syntax, the intention is to exclude any parameters for which values are not available, not applicable, or unknown. The authors recognize that implementers may need to add new parameter lines to the reports and new metrics to the existing parameter lines. The extension tokens are intended to fulfill this need. 4.6.1. ABNF Syntax Definition VQReportEvent = AlertReport / SessionReport / IntervalReport SessionReport = "VQSessionReport" [COLON CallTerm] CRLF LocalMetrics [CRLF RemoteMetrics] [DialogID] ; CallTerm indicates the final report of a session. IntervalReport = "VQIntervalReport" CRLF LocalMetrics [CRLF RemoteMetrics] [DialogID] LocalMetrics = "LocalMetrics" COLON CRLF Metrics RemoteMetrics = "RemoteMetrics" COLON CRLF Metrics AlertReport = "VQAlertReport" COLON MetricType WSP Severity WSP Direction CRLF "Metrics:" CRLF Metrics [CRLF "RemoteMetrics:" CRLF Metrics] Pendleton Expires September 2009 [Page 9] Internet-Draft RTCP-XR Summary March 2009 [DialogID] Metrics = TimeStamps CRLF [SessionDescription CRLF] CallID CRLF FromID CRLF ToID CRLF LocalAddr CRLF RemoteAddr CRLF [JitterBuffer CRLF] [PacketLoss CRLF] [BurstGapLoss CRLF] [Delay CRLF] [Signal CRLF] [QualityEstimates CRLF] *(Extension CRLF) ; Timestamps are provided in Coordinated Universal Time (UTC) ; using the ABNF format provided in RFC3339, ; "Date and Time on the Internet: Timestamps" ; These timestamps SHOULD reflect, as closely as ; possible, the actual time during which the media session ; was running to enable correlation to events occurring ; in the network infrastructure and to accounting records TimeStamps = "Timestamps" COLON StartTime WSP StopTime StartTime = "START" EQUAL date-time StopTime = "STOP" EQUAL date-time ; SessionDescription provides a shortened version of the ; session SDP but contains only the relevant parameters for ; session quality reporting purposes SessionDescription = "SessionDesc" COLON [PayloadType WSP] [PayloadDesc WSP] [SampleRate WSP] [FrameDuration WSP] [FrameOctets WSP] [FramesPerPacket WSP] [PacketsPerSecond WSP] [FmtpOptions WSP] [PacketLossConcealment WSP] [SilenceSuppressionState] *(WSP Extension) ; PayloadType provides the PT parameter used in the RTP packets ; i.e. the codec used for decoding received RTP packets Pendleton Expires September 2009 [Page 10] Internet-Draft RTCP-XR Summary March 2009 ; IANA registered values SHOULD be used where possible. PayloadType = "PT" EQUAL (1*3DIGIT) ; PayloadDesc provides a text description of the codec ; The abbreviated Standard name for the codec SHOULD be used ; (for example "G.729A") PayloadDesc = "PD" EQUAL (word / DQUOTE word-plus DQUOTE) ; SampleRate reports the rate at which voice was sampled ; in the case of narrowband codecs, this value will typically ; be 8000. ; For codecs that are able to change sample rates the lowest and ; highest sample rates MUST be reported (e.g. 8000;16000). SampleRate = "SR" EQUAL (1*6DIGIT) *(SEMI (1*66DIGIT)) ; FrameDuration can be combined with the FramesPerPacket ; to determine the packetization rate; the units for ; FrameDuration are milliseconds. FrameDuration = "FD" EQUAL (1*4DIGIT) ; FrameOctets provides the number of octets in each frame ; at the time the report is generated (i.e. last value) ; This MAY be used where FrameDuration is not available FrameOctets = "FO" EQUAL (1*5DIGIT) ; FramesPerPacket provides the number of frames in each RTP ; packet at the time the report is generated FramesPerPacket = "FPP" EQUAL (1*2DIGIT) ; Packets per second provides the average number of packets ; that are transmitted per second, as at the time the report is ; generated. PacketsPerSecond = "PPS" EQUAL (1*5DIGIT) ; FMTP options from SDP. Note that the parameter is delineated ; by " " to avoid parsing issues in transitioning between SDP and ; SIP parsing FmtpOptions = "FMTP" EQUAL DQUOTE word-plus DQUOTE ; PacketLossConcealment indicates whether a PLC algorithm was ; or is being used for the session. The values follow the same Pendleton Expires September 2009 [Page 11] Internet-Draft RTCP-XR Summary March 2009 ; numbering convention as RFC 3611[4]. ; 0 - unspecified ; 1 - disabled ; 2 - enhanced ; 3 - standard PacketLossConcealment = "PLC" EQUAL ("0" / "1" / "2" / "3") ; SilenceSuppressionState indicates whether silence suppression, ; also known as Voice Activity Detection (VAD) is enabled. SilenceSuppressionState = "SSUP" EQUAL ("on" / "off") ; CallId provides the call id from the SIP dialog CallID = "CallID" COLON Call-ID-Parm ; FromID provides the identification of the reporting endpoint ; of the media session [2]. FromID = "FromID" COLON from-spec ; ToID provides the identification of the remote endpoint ; of the media session [2]. ToID = "ToID" COLON (name-addr/addr-spec) ; LocalAddr provides the IP address, port and ssrc of the ; endpoint/UA which is the receiving end of the stream being ; measured. LocalAddr = "LocalAddr" COLON IPAddress WSP Port WSP Ssrc ; RemoteAddr provides the IP address, port and ssrc of the ; the source of the stream being measured. RemoteAddr = "RemoteAddr" COLON IPAddress WSP Port WSP Ssrc ; For clarification, the LocalAddr in the LocalMetrics report ; MUST be the RemoteAddr in the RemoteMetrics report. IPAddress = "IP" EQUAL IPv6address / IPv4address Port = "PORT" EQUAL 1*DIGIT Ssrc = "SSRC" EQUAL ( ''0x'' 1*8HEXDIG) JitterBuffer = "JitterBuffer" COLON [JitterBufferAdaptive WSP] [JitterBufferRate WSP] [JitterBufferNominal WSP] Pendleton Expires September 2009 [Page 12] Internet-Draft RTCP-XR Summary March 2009 [JitterBufferMax WSP] [JitterBufferAbsMax] *(WSP Extension) ; JitterBufferAdaptive indicates whether the jitter buffer in the ; endpoint is adaptive, static, or unknown. ; The values follow the same numbering convention as RFC3611. ; For more details, please refer to that document. ; 0 - unknown ; 1 - reserved ; 2 - non-adaptive ; 3 - adaptive JitterBufferAdaptive = "JBA" EQUAL ("0" / "1" / "2" / "3") ; JitterBuffer metric definitions are provided in RFC3611 JitterBufferRate = "JBR" EQUAL (1*2DIGIT) ;0-15 JitterBufferNominal = "JBN" EQUAL (1*5DIGIT) ;0-65535 JitterBufferMax = "JBM" EQUAL (1*5DIGIT) ;0-65535 JitterBufferAbsMax = "JBX" EQUAL (1*5DIGIT) ;0-65535 ; PacketLoss metric definitions are provided in RFC3611 PacketLoss = "PacketLoss" COLON [NetworkPacketLossRate WSP] [JitterBufferDiscardRate] *(WSP Extension) NetworkPacketLossRate = "NLR" EQUAL (1*3DIGIT ["." 1*2DIGIT]) ;percentage JitterBufferDiscardRate = "JDR" EQUAL (1*3DIGIT ["." 1*2DIGIT]) ;percentage ; BurstGapLoss metric definitions are provided in RFC3611 [4] BurstGapLoss = "BurstGapLoss" COLON [BurstLossDensity WSP] [BurstDuration WSP] [GapLossDensity WSP] [GapDuration WSP] [MinimumGapThreshold] *(WSP Extension) BurstLossDensity = Pendleton Expires September 2009 [Page 13] Internet-Draft RTCP-XR Summary March 2009 "BLD" EQUAL (1*3DIGIT ["." 1*2DIGIT]) ;percentage BurstDuration = "BD" EQUAL (1*7DIGIT) ;0-3,600,000 -- milliseconds GapLossDensity = "GLD" EQUAL (1*3DIGIT ["." 1*2DIGIT]) ;percentage GapDuration = "GD" EQUAL (1*7DIGIT) ;0-3,600,000 -- milliseconds MinimumGapThreshold = "GMIN" EQUAL (1*3DIGIT) ;1-255 Delay = "Delay" COLON [RoundTripDelay WSP] [EndSystemDelay WSP] [OneWayDelay WSP] [SymmOneWayDelay WSP] [InterarrivalJitter WSP] [MeanAbsoluteJitter] *(WSP Extension) ; RoundTripDelay SHALL be measured as defined in RFC3550 [3]. RoundTripDelay = "RTD" EQUAL (1*5DIGIT) ;0-65535 ; EndSystemDelay metric is defined in RFC 3611 [4] EndSystemDelay = "ESD" EQUAL (1*5DIGIT) ;0-65535 ; OneWayDelay is defined in RFC2679 OneWayDelay = "OWD" EQUAL (1*5DIGIT) ;0-65535 ; SymmOneWayDelay is defined as half the sum of RoundTripDelay ; and the EndSystemDelay values for both endpoints. SymmOneWayDelay = ''SOWD'' EQUAL (1*5DIGIT); 0-65535 ; Interarrival Jitter is measured as defined RFC 3550 InterarrivalJitter = "IAJ" EQUAL (1*5DIGIT) ;0-65535 ; Mean Absolute Jitter is measured as defined ; by ITU-T G.1020 [10] where it is known as MAPDV Pendleton Expires September 2009 [Page 14] Internet-Draft RTCP-XR Summary March 2009 MeanAbsoluteJitter = "MAJ" EQUAL (1*5DIGIT);0-65535 ; Signal metrics definitions are provided in RFC 3611 Signal = "Signal" COLON [SignalLevel WSP] [NoiseLevel WSP] [ResidualEchoReturnLoss] *(WSP Extension) ; SignalLevel will normally be a negative value ; the absence of the negative sign indicates a positive value ; where the signal level is negative, the sign MUST be included. ; This metric applies to the speech signal decoded from the ; received packet stream. SignalLevel = "SL" EQUAL (["-"] 1*2DIGIT) ; NoiseLevel will normally be negative and the sign MUST be ; explicitly included. ; The absence of a sign indicates a positive value ; This metric applies to the speech signal decoded from the ; received packet stream. NoiseLevel = "NL" EQUAL (["-"] 1*2DIGIT) ; Residual Echo Return Loss (RERL) the ratio between ; the original signal and the echo level as measured after ; echo cancellation or suppression has been applied. ; Expressed in decibels (dB). This is typically a positive ; value. ; This metric relates to the proportion of the speech signal ; decoded from the received packet stream that is reflected ; back in the encoded speech signal output in the transmitted ; packet stream (i.e. will affect the REMOTE user's conversational ; quality). To support the diagnosis of echo related problems ; experienced by the local user of the device generating a report ; according to this document, the value of RERL reported via ; the RTCP XR VoIP Metrics payload SHOULD be reported in the ; RemoteMetrics set of data. ResidualEchoReturnLoss = "RERL" EQUAL (1*3DIGIT) ; Voice Quality estimation metrics ; Each quality estimate has an optional associated algorithm. ; These fields permit the implementation to use a variety ; of different calculation methods for each type of metric Pendleton Expires September 2009 [Page 15] Internet-Draft RTCP-XR Summary March 2009 QualityEstimates = "QualityEst" COLON [ListeningQualityR WSP] [RLQEstAlg WSP] [ConversationalQualityR WSP] [RCQEstAlg WSP] [ExternalR-In WSP] [ExtRInEstAlg WSP] [ExternalR-Out WSP] [ExtROutEstAlg WSP] [MOS-LQ WSP] [MOSLQEstAlg WSP] [MOS-CQ WSP] [MOSCQEstAlg WSP] [QoEEstAlg] *(WSP Extension) ListeningQualityR = "RLQ" EQUAL (1*3DIGIT) ; 0 - 120 RLQEstAlg = "RLQEstAlg" EQUAL word ; "P.564", or other ConversationalQualityR = "RCQ" EQUAL (1*3DIGIT) ; 0 - 120 RCQEstAlg = "RCQEstAlg" EQUAL word ; "P.564", or other ; ExternalR-In is measured by the local endpoint for incoming ; connection on "other" side of this endpoint ; e.g. Phone A <---> Bridge <----> Phone B ; ListeningQualityR = quality for Phone A ----> Bridge path ; ExternalR-In = quality for Bridge <---- Phone B path ExternalR-In = "EXTRI" EQUAL (1*3DIGIT) ; 0 - 120 ExtRInEstAlg = "ExtRIEstAlg" EQUAL word ; "P.564" or other ; ExternalR-Out is copied from RTCP XR message received from the ; remote endpoint on "other" side of this endpoint ; e.g. Phone A <---> Bridge <----> Phone B ; ExternalR-Out = quality for Bridge -----> Phone B path ExternalR-Out = "EXTRO" EQUAL (1*3DIGIT) ; 0 - 120 ExtROutEstAlg = "ExtROEstAlg" EQUAL word ; "P.564" or other MOS-LQ = "MOSLQ" EQUAL (DIGIT ["." 1*3DIGIT]) ; 0.0 - 4.9 MOSLQEstAlg = "MOSLQEstAlg" EQUAL word ; "P.564" or other MOS-CQ = "MOSCQ" EQUAL (DIGIT ["." 1*3DIGIT]) ; 0.0 - 4.9 Pendleton Expires September 2009 [Page 16] Internet-Draft RTCP-XR Summary March 2009 MOSCQEstAlg = "MOSCQEstAlg" EQUAL word ; "P.564" or other ; alternative to the separate estimation algorithms ; for use when the same algorithm is used for all measurements QoEEstAlg = "QoEEstAlg" EQUAL word; "P.564" or other ; DialogID provides the identification of the dialog with ; which the media session is related. This value is taken ; from the SIP header. DialogID = "DialogID" COLON Call-ID-Parm *(SEMI did-parm) did-parm = to-tag / from-tag / word to-tag = "to-tag" EQUAL token from-tag = "from-tag" EQUAL token ; MetricType provides the metric on which a notification of ; threshold violation was based. The more commonly used metrics ; for alerting purposes are included here explicitly and the ; token parameter allows for extension MetricType = "Type" EQUAL "RLQ" / "RCQ" / "EXTR" / "MOSLQ" / "MOSCQ" / "BD" / "NLR" / "JDR" / "RTD" / "ESD" / "IAJ" / "RERL" / "SL" / "NL" / Extension Direction = "Dir" EQUAL "local" / "remote" Severity = "Severity" EQUAL "Warning" / "Critical" / "Clear" Call-ID-Parm = word [ "@" word ] ; General ABNF notation from RFC5234 CRLF = %x0D.0A DIGIT = %x30-39 WSP = SP / HTAB ; white space SP = " " HTAB = %x09 ; horizontal tab HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / "a" / "b" / "c" / "d" / "e" / "f" DQUOTE = %x22 ; " (Double Quote) ALPHA = %x41-5A / %x61-7A ; A-Z / a-z ; ABNF notation from RFC3261 Pendleton Expires September 2009 [Page 17] Internet-Draft RTCP-XR Summary March 2009 alphanum = ALPHA / DIGIT LWS = [*WSP CRLF] 1*WSP ; linear whitespace SWS = [LWS] ; sep whitespace SEMI = SWS ";" SWS ; semicolon EQUAL = SWS "=" SWS ; equal COLON = SWS ":" SWS ; colon token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6address = hexpart [ ":" IPv4address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG ; ABNF notation from RFC3339 date-fullyear = 4DIGIT ; e.g. 2006 date-month = 2DIGIT ; e.g. 01 or 11 date-mday = 2DIGIT ; e.g. 02 or 22 time-hour = 2DIGIT ; e.g. 01 or 13 time-minute = 2DIGIT ; e.g. 03 or 55 time-second = 2DIGIT ; e.g. 01 or 59 time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time ; ; Miscellaneous definitions ; Extension = word-plus word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" ) word-plus = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / "/" / "[" / "]" / "?" / "{" / "}" / "=" / " ") Pendleton Expires September 2009 [Page 18] Internet-Draft RTCP-XR Summary March 2009 4.6.2. Parameter Definitions and Mappings Parameter values, codec types and other aspects of the endpoints may change dynamically during a session. The reported values of metrics and configuration parameters SHALL be the current value at the time the report is generated. The Packet Loss Rate and Packet Discard Rate parameters are calculated over the period between the starting and ending timestamps for the report. These are normally calculated from a count of the number of lost or discarded packets divided by the count of the number of packets, and hence are based on the current values of these counters at the time the report was generated. Packet delay variation, signal level, noise level, echo level are computed as running or interval averages, based on the appropriate standard (e.g. RFC3550 for PDV) and the sampled value of these running averages is reported. Delay, packet size, jitter buffer size and codec related data may change during a session and the current value of these parameters is reported as sampled at the time the report is generated. 4.6.2.1. General mapping percentages from 8 bit, fixed point numbers RFC3611 uses an 8 bit, fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost by the total number of packets expected and multiplying the result by 256, and taking the integer part. For any RTCP XR parameter in this format, to map into the equivalent SIP vq-rtcpxr parameter, simply reverse the equation i.e. divide by 256 and taking the integer part. 4.6.2.2. Timestamps Following SIP and other IETF convention, timestamps are provided in Coordinated Universal Time (UTC) using the ABNF format provided in IETF RFC3339 [7]. These timestamps SHOULD reflect, as closely as possible, the actual time during which the media session was running to enable correlation to related events occurring in the network and to accounting or billing records. Pendleton Expires September 2009 [Page 19] Internet-Draft RTCP-XR Summary March 2009 4.6.2.3. SessionDescription The parameters in this field provide a shortened version of the session SDP(s), containing only the relevant parameters for session quality reporting purposes. Where values may change durina a session, for example a codec may change rate, then the most recent value of the parameter is reported. Payload Type This is the "payload type" parameter used in the RTP packets i.e. the codec. This field can also be mapped from the SDP "rtpmap" attribute field "payload type". IANA registered types SHOULD be used. Payload Desc This parameter provides a text name for the codec used in this session. Sample Rate This parameter is mapped from the SDP "rtpmap" attribute field "clock rate". The field provides the rate at which voice was sampled, measured in Hertz (Hz). Frame Duration This parameter is not contained in RTP or SDP but can usually be obtained from the device codec. The field reflects the amount of voice content in each frame within the RTP payload, measured in milliseconds. Note this value can be combined with the FramesPerPacket to determine the packetization rate. Frame Octets This parameter is not contained in RTP or SDP but is usually provided by the device codec. The field provides the number of octets in each frame within the RTP payload. This field is usually not provided when the FrameDuration is provided. Frames Per Packet This parameter is not contained in RTP or SDP but can usually be obtained from the device codec. This field provides the number of Pendleton Expires September 2009 [Page 20] Internet-Draft RTCP-XR Summary March 2009 frames in each RTP packet. Note this value can be combined with the FrameDuration to determine the packetization rate. Packets Per Second This parameter is not contained in RTP or SDP but can usually be obtained from the device codec. Packets per second provides the (rounded) number of RTP packets that are transmitted per second. FMTP Options This parameter is taken directly from the SDP attribute "fmtp". Silence Suppression State This parameter does not correspond to SDP, RTP, or RTCP XR. It indicates whether silence suppression, also known as Voice Activity Detection (VAD) is enabled for the identified session. Packet Loss Concealment This value corresponds to "PLC" in RFC3611 in the VoIP Metrics Report Block. The values defined by RFC3611 are reused by this recommendation and therefore no mapping is required. 4.6.2.4. LocalAddr This field provides the IP address, port and synchronization source (SSRC) for the session from the perspective of the endpoint that is measuring performance. The IPAddress can be IPv4 or IPv6 format. The SSRC is taken from SDP, RTCP, or RTCP XR input parameters. In the presence of NAT, the MAPPED-ADDRESS as reported by the STUN [9] server (RFC 3489) MUST be reported, since the internal IP address is not visible to the network operator. 4.6.2.5. RemoteAddr This field provides the IP address, port and ssrc of the session peer from the perspective of the remote endpoint measuring performance. In the presence of NAT, the MAPPED-ADDRESS as reported by the STUN [9] server (RFC 3489bis) MUST be reported, since the internal IP address is not visible to the network operator. Pendleton Expires September 2009 [Page 21] Internet-Draft RTCP-XR Summary March 2009 4.6.2.6. Jitter Buffer Parameters Jitter Buffer Adaptive This value corresponds to "JBA" in RFC3611 in the VoIP Metrics Report Block. The values defined by RFC3611 are unchanged and therefore no mapping is required. Jitter Buffer Rate This value corresponds to "JB rate" in RFC3611 in the VoIP Metrics Report Block. The parameter does not require any conversion. Jitter Buffer Nominal This value corresponds to "JB nominal" in RFC3611 in the VoIP Metrics Report Block. The parameter does not require any conversion. Jitter Buffer Max This value corresponds to "JB maximum" in RFC3611 in the VoIP Metrics Report Block. The parameter does not require any conversion. Jitter Buffer Abs Max This value corresponds to "JB abs max" in RFC3611 in the VoIP Metrics Report Block. The parameter does not require any conversion. 4.6.2.7. Packet Loss Parameters This value corresponds to "loss rate" in RFC3611 in the VoIP Metrics Report Block. For conversion, see "General mapping percentages from 8 bit, fixed point numbers". Jitter Buffer Discard Rate This value corresponds to "discard rate" in RFC3611 in the VoIP Metrics Report Block. For conversion, see "General mapping percentages from 8 bit, fixed point numbers". 4.6.2.8. Burst/Gap Parameters Burst Loss Density Pendleton Expires September 2009 [Page 22] Internet-Draft RTCP-XR Summary March 2009 This value corresponds to "burst density" in RFC3611 in the VoIP Metrics Report Block. For conversion, see "General mapping percentages from 8 bit, fixed point numbers". Burst Duration This value corresponds to "burst duration" in RFC3611 in the VoIP Metrics Report Block. This value requires no conversion; the exact value sent in an RTCP XR VoIP Metrics Report Block can be included in the SIP vq-rtcpxr parameter. Gap Loss Density This value corresponds to "gap density" in RFC3611 in the VoIP metrics Report Block. Gap Duration This value corresponds to "gap duration" in RFC3611 in the VoIP Metrics Report Block. This value requires no conversion; the exact value sent in an RTCP XR VoIP Metrics Report Block can be reported. Minimum Gap Threshold This value corresponds to "Gmin" in RFC3611 in the VoIP Metrics Report Block. This value requires no conversion; the exact value sent in an RTCP XR VoIP Metrics Report Block can be reported. 4.6.2.9. Delay Parameters Round Trip Delay This value corresponds to "round trip delay" in RFC3611 in the VoIP Metrics Report Block and may be measured using the method defined in RFC3550. The parameter is expressed in milliseconds. End System Delay This value corresponds to "end system delay" in RFC3611 in the VoIP Metrics Report Block. This parameter does not require any conversion. The parameter is expressed in milliseconds. Symmetric One Way Delay This value is computed by adding Round Trip Delay to the local and remote End System Delay and dividing by two. Pendleton Expires September 2009 [Page 23] Internet-Draft RTCP-XR Summary March 2009 One Way Delay This value SHOULD be measured using the methods defined in IETF RFC2679. The parameter is expressed in milliseconds. Inter-arrival Jitter Inter-arrival jitter is defined in RFC 3550. The parameter is expressed in milliseconds. Mean Absolute Jitter It is recommended that MAJ be measured as defined in ITU-T G.1020 [10]. This parameter is often referred to as MAPDV. The parameter is expressed in milliseconds. Signal-related Parameters Signal-related Parameters 4.6.2.10. Signal-related Parameters Signal Level This field corresponds to "signal level" in RFC3611 in the VoIP Metrics Report Block. This field provides the voice signal relative level is defined as the ratio of the signal level to a 0 dBm0 reference, expressed in decibels. This value can be used directly without extra conversion. Noise Level This field corresponds to "noise level" in RFC3611 in the VoIP Metrics Report Block. This field provides the ratio of the silent period background noise level to a 0 dBm0 reference, expressed in decibels. This value can be used directly without extra conversion. Residual Echo Return Loss (RERL) This field corresponds to "RERL" in RFC3611 in the VoIP Metrics Report Block. This field provides the ratio between the original signal and the echo level in decibels, as measured after echo cancellation or suppression has been applied. This value can be used directly without extra conversion. 4.6.2.11. Quality Scores ListeningQualityR Pendleton Expires September 2009 [Page 24] Internet-Draft RTCP-XR Summary March 2009 This field reports the listening quality expressed as an R factor (per G.107). This does not include the effects of echo or delay. The range of R is 0-95 for narrowband calls and 0-120 for wideband calls. Algorithms for computing this value SHOULD be compliant with ITU-T Recommendations P.564 [11] and G.107 [12]. RLQEstAlg This field provides a text name for the algorithm used to estimate ListeningQualityR. ConversationalQualityR This field corresponds to "R factor" in RFC3611 in the VoIP Metrics Report Block. This parameter provides a cumulative measurement of voice quality from the start of the session to the reporting time. The range of R is 0-95 for narrowband calls and 0-120 for wideband calls. Algorithms for computing this value SHOULD be compliant with ITU-T Recommendation P.564 and G.107. Within RFC3611 a reported R factor of 127 indicates that this parameter is unavailable; in this case the ConversationalQualityR parameter MUST be omitted from the vq-rtcpxr event. RCQEstAlg This field provides a text name for the algorithm used to estimate ConversationalQualityR. ExternalR-In This field corresponds to "ext. R factor" in RFC3611 in the VoIP Metrics Report Block. This parameter reflects voice quality as measured by the local endpoint for incoming connection on "other" side (refer to RFC3611 for a more detailed explanation). The range of R is 0-95 for narrowband calls and 0-120 for wideband calls. Algorithms for computing this value SHOULD be compliant with ITU-T Recommendation P.564 and G.107. Within RFC3611 a reported R factor of 127 indicates that this parameter is unavailable; in this case the ConversationalQualityR parameter MUST be omitted from the vq-rtcpxr event. ExtRInEstAlg This field provides a text name for the algorithm used to estimate ExternalR-In. ExternalR-Out Pendleton Expires September 2009 [Page 25] Internet-Draft RTCP-XR Summary March 2009 This field corresponds to "ext. R factor" in RFC3611 in the VoIP Metrics Report Block. Here, the value is copied from RTCP XR message received from the remote endpoint on "other" side of this endpoint refer to RFC3611 for a more detailed explanation). The range of R is 0-95 for narrowband calls and 0-120 for wideband calls. Algorithms for computing this value SHOULD be compliant with ITU-T Recommendation P.564 and G.107. Within RFC3611 a reported R factor of 127 indicates that this parameter is unavailable; in this case the ConversationalQualityR parameter SHALL be omitted from the vq-rtcpxr event. ExtROutEstAlg This field provides a text name for the algorithm used to estimate ExternalR-Out. Conversion of RFC3611 reported MOS scores for use in reporting MOS-LQ and MOS-CQ MUST be performed by dividing the RFC3611 reported value by 10 if this value is less than or equal to 50 or omitting the MOS-xQ parameter if the RFC3611 reported value is 127 (which indicates unavailable). MOS-LQ This field corresponds to "MOSLQ" in RFC3611 in the VoIP Metrics Report Block. This parameter is the estimated mean opinion score for listening voice quality on a scale from 1 to 5, in which 5 represents "Excellent" and 1 represents "Unacceptable". Algorithms for computing this value SHOULD be compliant with ITU-T Recommendation P.564 [11]. This field provides a text name for the algorithm used to estimate MOS-LQ. MOS-CQ This field corresponds to "MOSCQ" in RFC3611 in the VoIP Metrics Report Block. This parameter is the estimated mean opinion score for conversation voice quality on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. Algorithms for computing this value SHOULD be compliant with ITU-T Recommendation P.564 with regard to the listening quality element of the computed MOS score. MOSCQEstAlg This field provides a text name for the algorithm used to estimate MOS-CQ. QoEEstAlg Pendleton Expires September 2009 [Page 26] Internet-Draft RTCP-XR Summary March 2009 This field provides a text description of the algorithm used to estimate all voice quality metrics. This parameter is provided as an alternative to the separate estimation algorithms for use when the same algorithm is used for all measurements. 4.7. Message Flow and Syntax Examples This section shows a number of message flow examples showing how the event package works. 4.7.1. End of Session Report using NOTIFY Alice Proxy/Registrar Collector Bob | | | | | | | | | REGISTER Allow-Event:vq-rtcpxr F1 | | |------------------->| | | | 200 OK F2 | | | |<-------------------| | | | | SUBSCRIBE Event:vq-rtcpxr F3 | | |<-------------------| | | SUBSCRIBE Event:vq-rtcpxr F4 | | |<-------------------| | | | 200 OK F5 | | | |------------------->| | | | | 200 OK F6 | | | |------------------->| | | INVITE F7 | | | |------------------->| | | | | INVITE F8 | | | |---------------------------------------->| | | 200 OK F9 | | | |<----------------------------------------| | 200 OK F10 | | | |<-------------------| | | | ACK F11 | | | |------------------->| | | | | ACK F12 | | | |---------------------------------------->| | RTP | | | |<============================================================>| | RTCP, RTCP XR | | |<============================================================>| | | | | | BYE F13 | | | |------------------->| BYE F14 | | | |---------------------------------------->| | | 200 OK F15 | | | |<----------------------------------------| Pendleton Expires September 2009 [Page 27] Internet-Draft RTCP-XR Summary March 2009 | 200 OK F16 | | | |<-------------------| | | | NOTIFY Event:vq-rtcpxr F17 | | |------------------->| | | | | NOTIFY Event:vq-rtcpxr F18 | | |------------------->| | | | 200 OK F19 | | | |<-------------------| | | 200 OK F20 | | | |<-------------------| | | Figure 1. Summary report with NOTIFY sent after session termination. In the call flow depicted in Figure 1, the following message format is sent in F17: NOTIFY sip:collector@example.org SIP/2.0 Via: SIP/2.0/UDP pc22.example.org;branch=z9hG4bK3343d7 Max-Forwards: 70 To: ;tag=43524545 From: Alice ;tag=a3343df32 Call-ID: 1890463548@alice.example.org CSeq: 4321 NOTIFY Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: vq-rtcpxr Accept: application/sdp, message/sipfrag Subscription-State: active;expires=3600 Content-Type: application/vq-rtcpxr Content-Length: ... VQSessionReport : CallTerm LocalMetrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=0 PD=PCMU SR=8000 FD=20 FO=160 FPP=1 PPS=50 PLC=3 SSUP=on CallID: 6dg37f1890463 FromID: Alice ToID: Bill LocalAddr:IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 Pendleton Expires September 2009 [Page 28] Internet-Draft RTCP-XR Summary March 2009 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-18 NL=-50 RERL=55 QualityEst:RLQ=88 RCQ=85 EXTRI=90 MOSLQ=4.1 MOSCQ=4.0 QoEEstAlg=P.564 RemoteMetrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=0 PD=PCMU SR=8000 FD=20 FO=160 FPP=1 PPS=50 PLC=3 SSUP=on CallID:6dg37f1890463 LocalAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd RemoteAddr:IP=10.10.1.100 PORT=5000 SSRC=0x1a3b5c7d JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-21 NL=-45 RERL=55 QualityEst:RLQ=90 RCQ=85 EXTRI=90 MOSLQ=4.3 MOSCQ=4.2 QoEEstAlg=P.564 DialogID:1890463548@alice.example.org;to-tag=8472761; from-tag=9123dh311 4.7.2. Mid Session Threshold Violation using NOTIFY Alice Proxy/Registrar Collector Bob | | | | | | | | | REGISTER Allow-Event:vq-rtcpxr F1 | | |------------------->| | | | 200 OK F2 | | | |<-------------------| | | | | SUBSCRIBE Event:vq-rtcpxr F3 | | |<-------------------| | | SUBSCRIBE Event:vq-rtcpxr F4 | | |<-------------------| | | | 200 OK F5 | | | |------------------->| | | | | 200 OK F6 | | | |------------------->| | | INVITE F7 | | | |------------------->| | | Pendleton Expires September 2009 [Page 29] Internet-Draft RTCP-XR Summary March 2009 | | INVITE F8 | | | |---------------------------------------->| | | 200 OK F9 | | | |<----------------------------------------| | 200 OK F10 | | | |<-------------------| | | | ACK F11 | | | |------------------->| | | | | ACK F12 | | | |---------------------------------------->| | RTP | | | |<============================================================>| | RTCP, RTCP XR | | |<============================================================>| | NOTIFY Event:vq-rtcpxr F17 | | |------------------->| | | | | NOTIFY Event:vq-rtcpxr F18 | | |------------------->| | | | 200 OK F19 | | | |<-------------------| | | 200 OK F20 | | | |<-------------------| | | | | | | | BYE F13 | | | |------------------->| BYE F14 | | | |---------------------------------------->| | | 200 OK F15 | | | |<----------------------------------------| | 200 OK F16 | | | |<-------------------| | | | NOTIFY Event:vq-rtcpxr F17 | | |------------------->| | | | | NOTIFY Event:vq-rtcpxr F18 | | |------------------->| | | | 200 OK F19 | | | |<-------------------| | | 200 OK F20 | | | |<-------------------| | | Figure 2. Summary report sent during session with alert report. In the call flow depicted in Figure 2, the following message format is sent in F17: PUBLISH sip:collector@example.org SIP/2.0 Via: SIP/2.0/UDP pc22.example.org;branch=z9hG4bK3343d7 Max-Forwards: 70 To: Pendleton Expires September 2009 [Page 30] Internet-Draft RTCP-XR Summary March 2009 From: Alice ;tag=a3343df32 Call-ID: 1890463548@alice.example.org CSeq: 4331 PUBLISH Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: vq-rtcpxr Accept: application/sdp, message/sipfrag Content-Type: application/vq-rtcpxr Content-Length: ... VQSessionReport : CallTerm LocalMetrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=18 PD=G729 SR=8000 FD=20 FO=20 FPP=2 PPS=50 FMTP="annexb=no" PLC=3 SSUP=on CallID: 6dg37f1890463 FromID: Alice ToID: Bill LocalAddr:IP=10.10.1.100 PORT=5000 SSRC=0x2468abcd RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=1357efff JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-21 NL=-50 RERL=55 QualityEst:RLQ=90 RCQ=85 EXTRI=90 MOSLQ=4.2 MOSCQ=4.3 QoEEstAlg=P.564 RemoteMetrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=18 PD=G729 SR=8000 FD=20 FO=20 FPP=2 PPS=50 FMTP="annexb=no" PLC=3 SSUP=on CallID: 6dg37f1890463 LocalAddr:IP=11.1.1.150 PORT=5002 SSRC=1357efff RemoteAddr:IP=10.10.1.100 PORT=5000 SSRC=0x2468abcd JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-21 NL=-45 RERL=55 Pendleton Expires September 2009 [Page 31] Internet-Draft RTCP-XR Summary March 2009 QualityEst:RLQ=90 RCQ=85 MOSLQ=4.3 MOSCQ=4.2 QoEEstAlg=P.564 DialogID:1890463548@alice.example.org;to-tag=8472761; from-tag=9123dh311 4.7.3. End of Session Report using PUBLISH Alice Proxy/Registrar Collector Bob | | | | | | | | | REGISTER Allow-Event:vq-rtcpxr F1 | | |------------------->| | | | 200 OK F2 | | | |<-------------------| | | | INVITE F3 | | | |------------------->| | | | | INVITE F4 | | | |---------------------------------------->| | | 200 OK F5 | | | |<----------------------------------------| | 200 OK F6 | | | |<-------------------| | | | ACK F7 | | | |------------------->| | | | | ACK F8 | | | |---------------------------------------->| | RTP | | | |<============================================================>| | RTCP | | | |<============================================================>| | | | | | BYE F9 | | | |------------------->| BYE F10 | | | |---------------------------------------->| | | 200 OK F11 | | | |<----------------------------------------| | 200 OK F12 | | | |<-------------------| | | | PUBLISH Event:vq-rtcpxr F13 | | |------------------->| | | | | PUBLISH Event:vq-rtcpxr F14 | | |------------------->| | | | 200 OK F15 | | | |<-------------------| | | 200 OK F16 | | | |<-------------------| | | Figure 3. End of session report sent after session termination. Pendleton Expires September 2009 [Page 32] Internet-Draft RTCP-XR Summary March 2009 In the message flow depicted in Figure 3, the following message is sent in F13. PUBLISH sip:collector@example.org SIP/2.0 Via: SIP/2.0/UDP pc22.example.org;branch=z9hG4bK3343d7 Max-Forwards: 70 To: From: Alice ;tag=a3343df32 Call-ID: 1890463548@alice.example.org CSeq: 4331 PUBLISH Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: vq-rtcpxr Accept: application/sdp, message/sipfrag Content-Type: application/vq-rtcpxr Content-Length: ... VQSessionReport : CallTerm LocalMetrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=18 PD=G729 SR=8000 FD=20 FO=20 FPP=2 PPS=50 FMTP="annexb=no" PLC=3 SSUP=on CallID: 6dg37f1890463 FromID: Alice ToID: Bill LocalAddr:IP=10.10.1.100 PORT=5000 SSRC=0x2468abcd RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=1357efff JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-21 NL=-50 RERL=55 QualityEst:RLQ=90 RCQ=85 EXTRI=90 MOSLQ=4.2 MOSCQ=4.3 QoEEstAlg=P.564 RemoteMetrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=18 PD=G729 SR=8000 FD=20 FO=20 FPP=2 PPS=50 FMTP="annexb=no" PLC=3 SSUP=on CallID:6dg37f1890463 Pendleton Expires September 2009 [Page 33] Internet-Draft RTCP-XR Summary March 2009 LocalAddr:IP=11.1.1.150 PORT=5002 SSRC=1357efff RemoteAddr:IP=10.10.1.100 PORT=5000 SSRC=0x2468abcd JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-21 NL=-45 RERL=55 QualityEst:RLQ=90 RCQ=85 MOSLQ=4.3 MOSCQ=4.2 QoEEstAlg=P.564 DialogID:1890463548@alice.example.org;to-tag=8472761; from-tag=9123dh311 4.7.4. Alert Report using PUBLISH Alice Proxy/Registrar Collector Bob | | | | | INVITE F1 | | | |------------------->| | | | | INVITE F2 | | | |---------------------------------------->| | | 200 OK F3 | | | |<----------------------------------------| | 200 OK F4 | | | |<-------------------| | | | ACK F5 | | | |------------------->| | | | | ACK F6 | | | |---------------------------------------->| | RTP | | | |<============================================================>| | RTCP | | | |<============================================================>| | PUBLISH Event:vq-rtcpxr F7 | | |------------------->| | | | | PUBLISH Event:vq-rtcpxr F8 | | |------------------->| | | | 200 OK F9 | | | |<-------------------| | | 200 OK F10 | | | |<-------------------| | | | | | | | BYE F12 | | | |------------------->| BYE F13 | | | |---------------------------------------->| | | 200 OK F14 | | | |<----------------------------------------| | 200 OK F15 | | | |<-------------------| | | Pendleton Expires September 2009 [Page 34] Internet-Draft RTCP-XR Summary March 2009 Figure 4. Alert report message flow In the message flow depicted in Figure 4, the following message is sent in F7: PUBLISH sip:collector@example.org SIP/2.0 Via: SIP/2.0/UDP pc22.example.org;branch=z9hG4bK3343d7 Max-Forwards: 70 To: From: Alice ;tag=a3343df32 Call-ID: 1890463548@alice.example.org CSeq: 4321 PUBLISH Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: vq-rtcpxr Accept: application/sdp, message/sipfrag Content-Type: application/vq-rtcpxr Content-Length: ... VQAlertReport: Type=RLQ Severity=Warning Dir=local Metrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=0 PD=PCMU SR=8000 FD=20 FO=160 FPP=1 PPS=50 PLC=3 SSUP=on CallID: 6dg37f1890463 FromID: Alice ToID: Bill LocalAddr:IP=10.10.1.100 PORT=5000 SSRC=2a4b6c8d RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=9f7e5d3c JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-12 NL=-30 RERL=55 QualityEst:RLQ=60 RCQ=55 EXTR=90 MOSLQ=2.4 MOSCQ=2.3 QoEEstAlg=P.564 RemoteMetrics: Timestamps:START=2004-10-10T18:23:43Z STOP=2004-10-01T18:26:02Z SessionDesc:PT=0 PD=PCMU SR=8000 FD=20 FO=160 FPP=1 PPS=50 PLC=3 SSUP=on Pendleton Expires September 2009 [Page 35] Internet-Draft RTCP-XR Summary March 2009 CallID: 6dg37f1890463 LocalAddr:IP=11.1.1.150 PORT=5002 SSRC=9f7e5d3c RemoteAddr:IP=10.10.1.100 PORT=5000 SSRC=2a4b6c8d JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120 PacketLoss:NLR=5.0 JDR=2.0 BurstGapLoss:BLD=0 BD=0 GLD=2.0 GD=500 GMIN=16 Delay:RTD=200 ESD=140 SOWD=200 IAJ=2 MAJ=10 Signal:SL=-23 NL=-60 RERL=55 QualityEst:RLQ=90 RCQ=85 EXTRI=90 MOSLQ=4.2 MOSCQ=4.3 QoEEstAlg=P.564 DialogID:1890463548@alice.example.org;to-tag=8472761; from-tag=9123dh3111 4.8. Configuration Dataset for vq-rtcpxr Events It is the suggestion of the authors that the SIP configuration framework [8] be used to establish the necessary parameters for usage of vq-rtcpxr events. A dataset for this purpose should be designed and documented in a separate draft upon completion of the framework. 5. IANA Considerations This document registers a new SIP Event Package and a new MIME type. 5.1. SIP Event Package Registration Package name: vq-rtcpx Type: package Contact: Amy Pendleton Published Specification: This document 5.2. application/vq-rtcp-xr MIME Registration MIME media type name: application MIME subtype name: vq-rtcpxr Mandatory parameters: none Optional parameters: none Encoding considerations: text Security considerations: See next section. Interoperability considerations: none. Published specification: This document. Pendleton Expires September 2009 [Page 36] Internet-Draft RTCP-XR Summary March 2009 Applications which use this media type: This document type is being used in notifications of VoIP quality reports. Additional Information: Magic Number: None File Extension: None Macintosh file type code: "TEXT" Personal and email address for further information: Amy Pendleton Intended usage: COMMON Author/Change controller: The IETF. 6. Security Considerations RTCP reports can contain sensitive information since they can provide information about the nature and duration of a session established between two or more endpoints. As a result, any third party wishing to obtain this information SHOULD be properly authenticated by the SIP UA using standard SIP mechanisms and according to the recommendations in [5]. Additionally the event content MAY be encrypted to ensure confidentiality; the mechanisms for providing confidentiality are detailed in [2]. 7. Contributors The authors would like to thank Rajesh Kumar, Dave Oran, Tom Redman, Shane Holthaus and Jack Ford for their comments and input. 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, Pendleton Expires September 2009 [Page 37] Internet-Draft RTCP-XR Summary March 2009 "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [4] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [5] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [7] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [8] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-15, (work in progress), February 2008. [9] Rosenberg, J., J. Weinberger, C. Huitema, and R. Mahy, "STUN- Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)," RFC 3489, March 2003. [10] ITU-T Recommendation G.1020, Performance parameter definitions for quality of speech and other voiceband applications utilising IP networks [11] ITU-T Recommendation P.564, Conformance Testing for Voice over IP transmission quality assessment models [12] ITU-T Recommendation G.107, The E-model, a computational model for use in transmission planning. [13] M. Westerlund, S. Wenger, "RTP Topologies," RFC 5117, January 2008. [14] V. Hilt, "Design Considerations for Session Initiation Protocol (SIP) Overload Control," draft-ietf-sipping-overload-design-00, Pendleton Expires September 2009 [Page 38] Internet-Draft RTCP-XR Summary March 2009 (work in progress), October 2008. This document was prepared using 2-Word-v2.0.template.dot. Author's Addresses Amy Pendleton Nortel 2380 Performance Drive Richardson, TX 75081, USA Email: aspen@nortel.com Alan Clark Telchemy Incorporated 2905 Premiere Parkway, Suite 280 Duluth, GA 30097, USA Email: alan@telchemy.com Alan Johnston Avaya St. Louis, MO 63124, USA Email: alan@sipstation.com Henry Sinnreich Adobe Systems, Inc. 601 Townsend Street, San Francisco, CA 94103, USA Email: henrys@adobe.com Pendleton Expires September 2009 [Page 39]