RFC 6035
Session Initiation Protocol Event Package for Voice Quality Reporting
RFC 6035: Session Initiation Protocol Event Package for Voice Quality Reporting 🎀✨
okay bestie, let's start with the title block so you know who made this and what it's about 💅
- RFC number: 6035 🦋
- Title: Session Initiation Protocol Event Package for Voice Quality Reporting 📞
- Authors: A. Pendleton and A. Clark (both from Telchemy Incorporated), A. Johnston (Avaya), and H. Sinnreich (Unaffiliated) 👯♀️
- Category: Standards Track 👑
- ISSN: 2070-1721 🌸
- Date: November 2010 📅
The title block doesn't list anything this document obsoletes or updates 🧚
Abstract 💜
okay so this doc defines a SIP event package (SIP is the signaling protocol that sets up calls) that lets you collect and report metrics measuring how good a VoIP call sounds 🎧 It's giving "I need to know how my call went" energy. The voice call quality info comes from RTCP-XR (the extended reports that ride along with media), and the call details come from SIP. Both get sent from a User Agent (UA) in the session, called the reporter, over to a third party called the collector 🫶 The doc also registers the application/vq-rtcpxr media type, so the data has an official label 🌈
Status of This Memo 🌷
this is an Internet Standards Track document, so it's officially a standard, not just an idea 💅 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more on Internet Standards, check Section 2 of RFC 5741.
info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6035 🔗
Copyright Notice 🧾
bestie, the legal part matters, so listen up 👂 The copyright is Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date it was published. Read those carefully, because they spell out your rights and restrictions. Any Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🫶
Some of this document may contain material from IETF Documents or IETF Contributions that was published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 Unless you get an adequate license from them, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍
Table of Contents 📚
1. Introduction ....................................................4
1.1. Applicability Statement ....................................4
1.2. Use of the Mechanism .......................................4
2. Terminology .....................................................6
3. SIP Events for VoIP Quality Reporting ...........................6
3.1. SUBSCRIBE NOTIFY Method ....................................6
3.2. PUBLISH Method .............................................7
3.3. Multi-Party and Multi-Segment Calls ........................7
3.4. 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. Subscribe Duration .........................................8
4.5. NOTIFY Bodies ..............................................8
4.6. Voice Quality Event and Semantics .........................10
4.6.1. ABNF Syntax Definition .............................10
4.6.2. Parameter Definitions and Mappings .................21
4.7. Message Flow and Syntax Examples ..........................29
4.7.1. End of Session Report Using NOTIFY .................29
4.7.2. Midsession Threshold Violation Using NOTIFY ........32
4.7.3. End of Session Report Using PUBLISH ................35
4.7.4. Alert Report Using PUBLISH .........................37
4.8. Configuration Dataset for vq-rtcpxr Events ................39
5. IANA Considerations ............................................39
5.1. SIP Event Package Registration ............................39
5.2. application/vq-rtcpxr Media Type Registration .............39
6. Security Considerations ........................................40
7. Contributors ...................................................40
8. References .....................................................40
8.1. Normative References ......................................40
8.2. Informative References ....................................411. Introduction 🚀
real-time comms over IP networks use SIP for signaling and RTP/RTCP for media transport and reporting 🎶 These protocols are super flexible and can handle a wild range of usage scenarios, so extensions to them need to be specified in the context of a specific usage scenario. In this memo, extensions to SIP are proposed to support reporting of RTP Control Protocol Extended Reports [4] metrics 💕
1.1. Applicability Statement 🧁
RTP shows up in lots of different architectures and topologies 🕸️ RFC 5117 [13] lists and describes these: point-to-point, point-to-multipoint using multicast, point-to-multipoint using the translator from RFC 3550, point-to-multipoint using the mixer model from RFC 3550, point-to-multipoint using video-switching Multipoint Control Units (MCUs), point-to-multipoint using RTCP-terminating MCU, and non-symmetric mixer/translators.
As the Abstract points out, this spec is for reporting the quality of VoIP sessions 🎧 So only the first topology, point to point, is currently supported. That reflects where VoIP is right now (mostly point-to-point unicast) and where quality research is at 🔬
how to accurately report the quality of a multipart conference, or a session with multiple hops through translators and mixers, is still an area of research in the industry 🤓 BUT this mechanism can easily be used for centrally mixed conference calls, where each leg is just a point-to-point call 🙌 It could be extended to cover more RTP topologies later, once those topics move out of research and into real Internet deployments 🌸
1.2. Use of the Mechanism 💌
RTCP reports usually go to the other participating endpoints in a session, which makes it pretty complicated for an administrator or management system to collect performance info 😩 In the scenarios this memo covers, the data in RTCP XR VoIP metrics reports (RFC 3611 [4]) gets forwarded to a central collection server using SIP 📨
apps on the server (or elsewhere) can help with network management, like easing bandwidth constraints, and they can support customer service by spotting and acknowledging calls with poor quality 💁♀️ Specifying those apps is beyond the scope of this paper, though.
there's a huge portfolio of quality parameters you can tie to VoIP, but only a minimal necessary set goes in the RTCP-XR reports 🧠
- The codec type, as resulting from the Session Description Protocol (SDP) offer-answer negotiation in SIP,
- The burst gap loss density and max gap duration, since voice cut-outs are the most annoying quality impairment in VoIP,
- Round-trip delay, because it is critical to conversational quality,
- Conversational quality as a catch-all for other voice quality impairments, such as randomly distributed packet loss, jitter, annoying silent suppression effects, etc.
in specific scenarios where other parameters are required, designers can include others beyond the scope of this paper 🎀
RTCP reports are best effort only. They're super useful, but they have limitations, as discussed in [3] 🫠 That has to be considered when you use RTCP reports in managed networks.
this document defines a new SIP event package, vq-rtcpxr, and a new MIME type, application/vq-rtcpxr 🦋 Together they enable collecting and reporting metrics that measure quality for RTP [3] sessions. The metric definitions in the event package are based on RTCP Extended Reports [4] and RTCP [3], and the mapping between the SIP event parameters and the parameters in those RFCs is defined in Section 4.6.2 🗺️
monitoring voice quality is believed to be the highest priority for this mechanism, so the event package metrics are mostly tailored for voice quality 🎙️ The package is designed to be extensible, but the negotiation of those extensions is not defined here 🔧
the event package supports reporting voice quality metrics for both the inbound and outbound directions 💫 Inbound metrics can generally be computed locally by the reporting endpoint. Outbound metrics are computed by the remote endpoint and sent back to the reporting endpoint using the RTCP Extended Reports [4] 🔄
how you configure this event package isn't covered here. This doc recommends the SIP configuration framework [15], which gets discussed in Section 4.8 ⚙️
the event package SHOULD be used with the SUBSCRIBE/NOTIFY method 💌 It MAY also be used with the PUBLISH method [8] for backward compatibility with some existing implementations 🤝 Message flow examples for both methods are 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 BCP 14, RFC 2119 [1] 🧐
3. SIP Events for VoIP Quality 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 that makes the info available to other apps. To keep things clear, the entities in SIP vq-rtcpxr event reporting get these names 🫶
- REPORTER: an entity involved in measuring and reporting media quality, i.e., the SIP UA involved in a media session. 🎤
- COLLECTOR: 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 💖
okay so the COLLECTOR SHALL send a SUBSCRIBE to the REPORTER so the relationship gets set up on purpose 💅 The REPORTER SHOULD send the voice quality metric reports with NOTIFY 🦋 The REPORTER MUST NOT send any vq-rtcpxr events if no COLLECTOR address has been configured 🙈 The REPORTER fills in the Request-URI following the rules for an in-dialog request ✨ And the COLLECTOR MAY send a SUBSCRIBE to a SIP Proxy that's acting on behalf of the reporting SIP UAs 🎀
3.2. PUBLISH Method 🌸
a SIP UA that supports this specification MAY also send the service quality metric reports with the PUBLISH method [8], but this approach SHOULD NOT be used, in general, on the public Internet 😬 The PUBLISH method MAY be supported for backward compatibility with existing implementations, so older stuff still works 🫶
The REPORTER MAY therefore fill in the Request-URI of the PUBLISH method with the address of the COLLECTOR. To keep SIP proxies and the COLLECTOR secure, the REPORTER MUST be configured with the address of the COLLECTOR, preferably using the SIP UA configuration framework [15], as described in Section 5.8. Security is not optional, bestie 🔒
It is RECOMMENDED that the REPORTER send an OPTIONS message to the COLLECTOR to check that PUBLISH is supported 🧚
If PUBLISH is not supported, then the REPORTER can only wait for a SUBSCRIBE request from the COLLECTOR and then deliver the information in NOTIFYs. If a REPORTER sends a PUBLISH to a COLLECTOR that does not support or allow this method, a 501 Not Implemented or a 405 Method Not Allowed response will be received, and the REPORTER will stop publication 💀
3.3. Multi-Party and Multi-Segment Calls 📞
a voice quality metric report may be sent for each session terminating at the REPORTER, and it 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 that had an RTP session during the call 🎀
multi-party stuff like call hold and call transfer can mean the user is in a series of concatenated sessions, maybe with different codecs or sample rates, even though it feels like one single call to them 🦋 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 an application/vq-rtcpxr body for each segment of the call 💅
3.4. Overload Avoidance 🚦
okay, users of this extension should make sure they use general SIP mechanisms for avoiding overload 🫶 For instance, an overloaded proxy or COLLECTOR MUST send a 503 Service Unavailable or another 5xx response with an appropriate Retry-After time specified. REPORTERs MUST act on these responses and respect the Retry-After time interval 🙌 Also, future SIP extensions for handling overload better, as covered in [14], should be followed as they get standardized 👑
to avoid overloading SIP Proxies or COLLECTORS, it's important to do capacity planning and to minimize the number of reports that get 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.
4. Event Package Formal Definition 🎀
4.1. Event Package Name 🦋
this document defines a SIP Event Package. SIP Event Packages were originally defined in RFC 3265 [5] 💖
4.2. Event Package Parameters 🌈
no event package parameters are defined, so there's nothing to set here 🙈
4.3. SUBSCRIBE Bodies 💅
SUBSCRIBE bodies are described by this specification ✨
4.4. Subscribe 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 Bodies 🔥
there are three notify bodies: a Session report, an Interval report, and an Alert report 👑
the Session report SHOULD be used for reporting when a voice media session terminates, when a media change happens (like a codec change or a session fork), or when a session terminates because no media packets were received. It 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 the report is generated 📈
the Interval report SHOULD be used for periodic or interval reporting, and it MUST NOT be used for reporting on the complete media session. This report is meant 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 that an Alert report relates to MAY be a short time interval, or it can run from the start of the call to the point the alert is generated. This time window SHOULD be selected to give the most useful info for 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 ⏱️
voice quality summary reports reference only one codec (payload type) 🎶 This payload type SHOULD be the main voice payload, not comfort noise or telephone event payloads. For apps that switch codecs consistently and rapidly, the most used codec should be reported. All values in the report, like IP addresses, synchronization source (SSRC), etc., represent those values as received by the REPORTER. In some scenarios these may not match on either end of the session, so the COLLECTOR will need logic to put these sessions together 🧩 The values of parameters like sample rate, frame duration, frame octets, packets per second, round-trip delay, etc., depend on the type of report they're in. If they show up in a Session or an Interval report, they're average values over the session or interval. If they show up in an Alert report, they're instantaneous values ⚡
the REPORTER always includes local quality reporting information and should, if possible, share remote quality reporting information with the COLLECTOR 🫶 This remote quality could come from received RTCP-XR reports or other sources. It's useful when the other end might support RTCP-XR but not this voice quality reporting 💜
this specification defines a new MIME type, application/vq-rtcpxr, which is a text encoding of the RTCP and RTCP-XR statistics with some extra metrics and correlation info 🧚
4.6. Voice Quality Event and Semantics 💖
this section covers the syntax extensions needed for event publication in SIP 🌸 The formal syntax definitions here are written in the Augmented BNF [6] format used in SIP [2] and reference elements defined there 🎀
the definition of the timestamp format is provided in [7]. Most of the parameters are optional, and in practice most implementations will send a subset of them 🫶 It's not this document's job to decide which parameters are useful for monitoring voice session quality. Its job is to enable reporting of voice quality, so the syntax lets the implementer choose which metrics fit their solution best ✨ Since there are no "invalid", "unknown", or "not applicable" values in the syntax, the intent is to leave out any parameters whose values are not available, not applicable, or unknown 🙈
the authors know implementers may need to add new parameter lines to the reports and new metrics to the existing parameter lines. The extension tokens are meant to cover that need 🦋
4.6.1. ABNF Syntax Definition 🔥
VQReportEvent = AlertReport / SessionReport / IntervalReport
SessionReport = "VQSessionReport" [ HCOLON "CallTerm" ] CRLF
SessionInfo CRLF
LocalMetrics [ CRLF RemoteMetrics ]
[ CRLF DialogID ]
; CallTerm indicates the final report of a session.
IntervalReport = "VQIntervalReport" [ HCOLON "CallTerm" ] CRLF
SessionInfo CRLF
LocalMetrics [ CRLF RemoteMetrics ]
[ CRLF DialogID ]
LocalMetrics = "LocalMetrics" HCOLON CRLF Metrics
RemoteMetrics = "RemoteMetrics" HCOLON CRLF Metrics
AlertReport = "VQAlertReport" HCOLON
MetricType WSP Severity WSP Direction CRLF
SessionInfo CRLF
LocalMetrics [ CRLF RemoteMetrics ]
[ DialogID ]
SessionInfo =
CallID CRLF
LocalID CRLF
RemoteID CRLF
OrigID CRLF
LocalAddr CRLF
RemoteAddr CRLF
LocalGroupID CRLF
RemoteGroupID CRLF
[ LocalMACAddr CRLF ]
[ RemoteMACAddr CRLF ]
Metrics = TimeStamps CRLF
[ SessionDescription 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 RFC 3339,
; "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.
; Time zones other than "Z" are not allowed.
TimeStamps = "Timestamps" HCOLON 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" HCOLON
[ PayloadType WSP ]
[ PayloadDesc WSP ]
[ SampleRate WSP ]
[ PacketsPerSecond WSP ]
[ FrameDuration WSP ]
[ FrameOctets WSP ]
[ FramesPerPacket WSP ]
[ FmtpOptions WSP ]
[ PacketLossConcealment WSP ]
[ SilenceSuppressionState ]
*(WSP Extension)
; PayloadType provides the PT parameter used in the RTP packets.
PayloadType = "PT" EQUAL (1*3DIGIT)
; PayloadDesc provides a text description of the codec.
; This parameter SHOULD use the IANA registry for
; media-type names defined by RFC 4855 where it unambiguously
; defines the codec. Refer to the "Audio Media Types"
; registry on http://www.iana.org.
PayloadDesc = "PD" EQUAL (word / DQUOTE word-plus DQUOTE)
; SampleRate reports the rate at which a 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. NOTE: for frame-based codecs,
; each frame constitutes a single frame; for sample-based codecs,
; a "frame" refers to the set of samples carried in an RTP packet.
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.
; NOTE: for frame-based codecs, each frame constitutes a single frame;
; for sample-based codecs, a "frame" refers to the set of samples
; carried in an RTP packet.
FrameOctets = "FO" EQUAL (1*5DIGIT)
; FramesPerPacket provides the number of frames in each RTP; packet at the time the report is generated. ; NOTE: for frame-based codecs, each frame constitutes a single frame; ; for sample-based codecs, a "frame" refers to the set of samples ; carried in an RTP packet.
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 ; 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" HCOLON Call-ID-Parm
; LocalID identifies the reporting endpoint for the media session [2].
LocalID = "LocalID" HCOLON (name-addr/addr-spec)
; RemoteID identifies the remote endpoint of the media session [2].
RemoteID = "RemoteID" HCOLON (name-addr/addr-spec)
; OrigID identifies the endpoint which originated the session.
OrigID = "OrigID" HCOLON (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" HCOLON IPAddress WSP Port WSP Ssrc ; RemoteAddr provides the IP address, port, and SSRC of the ; the source of the stream being measured.
RemoteAddr = "RemoteAddr" HCOLON IPAddress WSP Port WSP Ssrc
; LocalMACAddr provides the Media Access Control (MAC) address ; of the local SIP device.
LocalMACAddr = "LocalMAC" HCOLON hex2 *(":" hex2)
; RemoteMACAddr provides the MAC address ; of the remote SIP device.
RemoteMACAddr = "RemoteMAC" HCOLON hex2 *(":" hex2)
; LocalGroupID provides the identification for the purposes ; of aggregation for the local endpoint.
LocalGroupID = "LocalGroup" HCOLON word-plus
; RemoteGroupID provides the identification for the purposes ; of aggregation for the remote endpoint.
RemoteGroupID = "RemoteGroup" HCOLON word-plus
; 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 ( %x30.78 1*8HEXDIG)
JitterBuffer = "JitterBuffer" HCOLON [ JitterBufferAdaptive WSP ] [ JitterBufferRate WSP ] [ JitterBufferNominal WSP ] [ 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 RFC 3611 [4]. ; 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 RFC 3611 [4].
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 RFC 3611 [4].
PacketLoss = "PacketLoss" HCOLON [ 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 RFC 3611 [4].
BurstGapLoss = "BurstGapLoss" HCOLON [ BurstLossDensity WSP ] [ BurstDuration WSP ] [ GapLossDensity WSP ] [ GapDuration WSP ] [ MinimumGapThreshold ] *(WSP Extension)
BurstLossDensity = "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" HCOLON [ RoundTripDelay WSP ] [ EndSystemDelay WSP ] [ OneWayDelay WSP ] [ SymmOneWayDelay WSP ] [ InterarrivalJitter WSP ] [ MeanAbsoluteJitter ] *(WSP Extension)
; RoundTripDelay SHALL be measured as defined in RFC 3550 [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 RFC 2679 [12].
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 calculated as defined RFC 3550 [3] ; and converted into milliseconds.
InterarrivalJitter = "IAJ" EQUAL (1*5DIGIT) ;0-65535 ms
; Mean Absolute Jitter is measured as defined ; by ITU-T G.1020 [9] where it is known as MAPDV.
MeanAbsoluteJitter = "MAJ" EQUAL (1*5DIGIT);0-65535
; Signal metrics definitions are provided in RFC 3611 [4].
Signal = "Signal" HCOLON [ 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) is 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.
QualityEstimates = "QualityEst" HCOLON [ 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" [10], 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 the "other" side of this endpoint. For example, ; 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 the RTCP XR message received from the ; remote endpoint on the "other" side of this endpoint. For example, ; 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
MOSCQEstAlg = "MOSCQEstAlg" EQUAL word ; "P.564" or other
; QoEEstAlg provides an 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, using the ; character encoding that represents the parameter in ; this ABNF. The Extension parameter can be used to provide ; metrics that are not defined by this document.
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 RFC 5234.
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 RFC 3261.
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 HCOLON = *( SP / HTAB ) ":" SWS
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 hex2 = 2HEXDIG
; ABNF notation from RFC 3339.
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 / "-" / "." / "!" / "%" / "*" /
"_" / "+" / "`" / "'" / "~" /
"(" / ")" / "<" / ">" / ":" /
"\" / "/" / "[" / "]" / "?" /
"{" / "}" / "=" / " ")okay so word-plus is the "anything goes" cousin of word 💅 it's one or more of all those characters, including the space 🫶
4.6.2. Parameter Definitions and Mappings ✨
okay bestie, the parameter values, codec types, and other endpoint details can totally shift mid-call 🦋 so the reported values of metrics and configuration parameters SHALL be the current value at the time the report is generated. no cap, it's always the now value 🕰️
the Packet Loss Rate and Packet Discard Rate are worked out over the window between the starting and ending timestamps for the report. usually that's the count of lost or discarded packets divided by the count of all packets, so they're based on whatever those counters say at the moment the report gets made 💀
packet delay variation, signal level, noise level, and echo level are running or interval averages, computed with the right standard. for example, RFC 3550 is the one for Packet Delay Variation (PDV) 📈 and the sampled value of those running averages is what gets reported. delay, packet size, jitter buffer size, and codec-related data can change during a session too, and the current value is reported as sampled when the report is generated 🎀
4.6.2.1. General Mapping Percentages from 8-bit, Fixed-Point Numbers 🍓
RFC 3611 uses an 8-bit, fixed-point number with the binary point at the left edge of the field. the value gets calculated by dividing the total number of packets lost by the total number of packets expected, multiplying that by 256, and then taking the integer part 🧮
for any RTCP XR parameter in this format, mapping it to the equivalent SIP vq-rtcpxr parameter is just reversing the equation. so divide by 256 and take the integer part ✨
4.6.2.2. Timestamps ⏰
following SIP and other IETF conventions, timestamps are provided in Coordinated Universal Time (UTC) using the ABNF format from RFC 3339 [7]. these timestamps SHOULD reflect, as closely as possible, the actual time the media session was running 💖 that way they can be matched up with related events in the network and with accounting or billing records 🧾
4.6.2.3. SessionDescription 🎧
the parameters in this field are a shortened version of the session SDP(s), with only the stuff that matters for session quality reporting 💜 if a value can change during a session (like a codec changing its rate), then the most-recent value is the one that gets reported 🦋
4.6.2.3.1. Payload Type 🎵
this is the "payload type" parameter used in the RTP packets, aka the codec. it can also be mapped from the SDP "rtpmap" attribute field "payload type". IANA-registered types SHOULD be used 🌸
4.6.2.3.2. Payload Desc 📝
this parameter is a text description of the codec. it SHOULD use the IANA registry for media-type names wherever that registry unambiguously defines the codec. refer to the "Audio Media Types" registry on http://www.iana.org 🔍
4.6.2.3.3. Sample Rate 🎚️
this parameter is mapped from the SDP "rtpmap" attribute field "clock rate". it tells you the rate at which a voice was sampled, measured in Hertz (Hz) 🎶
4.6.2.3.4. Packets Per Second 📦
this one isn't in RTP or SDP, but you can usually grab it from the device codec 🧚 it's the (rounded) number of RTP packets transmitted per second 💅
4.6.2.3.5. Frame Duration ⏱️
again, not in RTP or SDP, but usually available from the device codec ✨ this field shows how much voice content is in each frame within the RTP payload, measured in milliseconds. fun fact: this value can be combined with the FramesPerPacket to figure out the packetization rate 🫶 also, when a sample-based codec is used, a "frame" means the set of samples carried in an RTP packet 🌈
4.6.2.3.6. Frame Octets 🔢
not in RTP or SDP, but the device codec usually provides it 💜 this field gives the number of octets in each frame within the RTP payload. it's usually not provided when FrameDuration is provided 🙈 and for sample-based codecs, "frame" again means the set of samples carried in an RTP packet 🎀
4.6.2.3.7. Frames Per Packet 📬
not in RTP or SDP, but you can usually get it from the device codec 🦋 this field gives the number of frames in each RTP packet. this value can be combined with the FrameDuration to determine the packetization rate 🍓 and yep, with sample-based codecs, a "frame" is the set of samples carried in an RTP packet 💖
4.6.2.3.8. FMTP Options 🎼
this one comes straight from the SDP attribute "fmtp", defined in RFC 4566 👑
4.6.2.3.9. Silence Suppression State 🤫
this parameter has no SDP, RTP, or RTCP XR counterpart. it shows whether silence suppression (also known as Voice Activity Detection (VAD)) is enabled for the identified session 🌙
4.6.2.3.10. Packet Loss Concealment 🫥
this value corresponds to "PLC" in the VoIP Metrics Report Block from RFC 3611. the values RFC 3611 defines are reused here, so no mapping is required 🩷
4.6.2.4. LocalAddr 📍
this field gives the IP address, port, and synchronization source (SSRC) for the session, from the point of view of the endpoint doing the measuring. the IPAddress MAY be in IPv4 or IPv6 format 🌐 the SSRC comes from SDP, RTCP, or RTCP XR input parameters 🫶
with NAT in the picture, and a NAT-traversal mechanism like Session Traversal Utilities for NAT (STUN) [16] being used, the external IP address can be reported 🕵️♀️ the internal one isn't visible to the network operator, so that's the tea ☕
4.6.2.5. RemoteAddr 🛰️
this field gives the IP address, port, and SSRC of the session peer, from the point of view of the remote endpoint doing the measuring. same deal as before: with NAT and a NAT-traversal mechanism such as STUN [16], the external IP address can be reported, because the internal IP address isn't visible to the network operator 🦋
4.6.2.6. Jitter Buffer Parameters 🫧
4.6.2.6.1. Jitter Buffer Adaptive 🌊
this value corresponds to "JBA" in the VoIP Metrics Report Block from RFC 3611. those values are unchanged, so no mapping is required ✨
4.6.2.6.2. Jitter Buffer Rate 🎈
this value corresponds to "JB rate" in the VoIP Metrics Report Block from RFC 3611. it doesn't need any conversion 💅
4.6.2.6.3. Jitter Buffer Nominal 🎯
this value corresponds to "JB nominal" in the VoIP Metrics Report Block from RFC 3611. no conversion needed 🌸
4.6.2.6.4. Jitter Buffer Max 🔝
this value corresponds to "JB maximum" in the VoIP Metrics Report Block from RFC 3611. no conversion needed 💖
4.6.2.6.5. Jitter Buffer Abs Max 🚀
this value corresponds to "JB abs max" in the VoIP Metrics Report Block from RFC 3611. no conversion needed 👑
4.6.2.7. Packet Loss Parameters 📉
4.6.2.7.1. Network Loss Rate 🕳️
this value corresponds to "loss rate" in the VoIP Metrics Report Block from RFC 3611. for the conversion, check Section 4.6.2.1 🔁 a loss rate of 100% MAY be reported if media packets were expected but none had been received at the time of session termination 😭 that's a whole mood
4.6.2.7.2. Jitter Buffer Discard Rate 🗑️
this value corresponds to "discard rate" in the VoIP Metrics Report Block from RFC 3611. for the conversion, see Section 4.6.2.1 💅
4.6.2.8. Burst/Gap Parameters 💥
4.6.2.8.1. Burst Loss Density 🌩️
this value corresponds to "burst density" in the VoIP Metrics Report Block from RFC 3611. for the conversion, see Section 4.6.2.1 ✨
4.6.2.8.2. Burst Duration ⏳
this value corresponds to "burst duration" in the VoIP Metrics Report Block from RFC 3611. it needs no conversion, since the exact value sent in an RTCP XR VoIP Metrics Report Block can be included in the SIP vq-rtcpxr parameter 🦋
4.6.2.8.3. Gap Loss Density 🕊️
this value corresponds to "gap density" in the VoIP Metrics Report Block from RFC 3611 🫶
4.6.2.8.4. Gap Duration 🌙
this value corresponds to "gap duration" in the VoIP Metrics Report Block from RFC 3611. it needs no conversion, since the exact value sent in an RTCP XR VoIP Metrics Report Block can be reported 🍓
4.6.2.8.5. Minimum Gap Threshold 🚧
this value corresponds to "Gmin" in the VoIP Metrics Report Block from RFC 3611. it needs no conversion, since the exact value sent in an RTCP XR VoIP Metrics Report Block can be reported 💜
4.6.2.9. Delay Parameters ⏰
4.6.2.9.1. Round-Trip Delay 🏓
this value corresponds to "round trip delay" in the VoIP Metrics Report Block from RFC 3611. it can be measured using the method defined in RFC 3550 🔄 the parameter is expressed in milliseconds ⏱️
4.6.2.9.2. End System Delay 🖥️
this value corresponds to "end system delay" in the VoIP Metrics Report Block from RFC 3611. no conversion needed, and the parameter is expressed in milliseconds 🌸
4.6.2.9.3. Symmetric One-Way Delay ⚖️
this value is computed by adding the Round-Trip Delay to the local and remote End System Delay, then dividing by two 🧮
4.6.2.9.4. One-Way Delay ➡️
this value SHOULD be measured using the methods defined in IETF RFC 2679 [12] 💖 the parameter is expressed in milliseconds ⏱️
4.6.2.9.5. Inter-Arrival Jitter 🎢
inter-arrival jitter is calculated as defined in RFC 3550 and then converted into milliseconds ✨
4.6.2.9.6. Mean Absolute Jitter 📊
it is recommended that MAJ be measured as defined in ITU-T G.1020 [9] 🫶 this parameter is often called MAPDV (Mean Absolute Packet Delay Variation). it's expressed in milliseconds 🌈
4.6.2.10. Signal-Related Parameters 📡
4.6.2.10.1. Signal Level 🔊
this field corresponds to "signal level" in the VoIP Metrics Report Block from RFC 3611. it provides the voice signal relative level, defined as the ratio of the signal level to a 0 dBm0 reference, expressed in decibels 🎚️ the value can be used directly, no extra conversion needed 💅
4.6.2.10.2. Noise Level 🤍
this field corresponds to "noise level" in the VoIP Metrics Report Block from RFC 3611. it provides the ratio of the silent-period background noise level to a 0 dBm0 reference, expressed in decibels 🌙 the value can be used directly without extra conversion ✨
4.6.2.10.3. Residual Echo Return Loss (RERL) 🔁
this field corresponds to "RERL" in the VoIP Metrics Report Block from RFC 3611. it provides the ratio between the original signal and the echo level in decibels, measured after echo cancellation or suppression has been applied 🦋 the value can be used directly without extra conversion 💖
4.6.2.11. Quality Scores 🏆
4.6.2.11.1. ListeningQualityR 👑
this field reports the listening quality as an R factor (per G.107). it 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 [10] and G.107 [11] 🫶
4.6.2.11.2. RLQEstAlg 🧠
this field provides a text name for the algorithm used to estimate ListeningQualityR 💅 it's free-form text and isn't necessarily reflective of any standards or recommendations, so read it as a vibe check, not a guarantee 🙈
4.6.2.11.3. ConversationalQualityR ✨
okay so this field is literally the "R factor" from RFC 3611's VoIP Metrics Report Block 🎀 it's a running score of how the voice sounded from the very start of the session up until the moment someone reports it 🫶 for narrowband calls R goes from 0-95, and for wideband calls it goes 0-120. the algorithms that work this out SHOULD be compliant with ITU-T Recommendations P.564 and G.107 💅 now here's the tea: in RFC 3611, a reported R factor of 127 means "this isn't available," so if you see that, the ConversationalQualityR parameter MUST be omitted from the vq-rtcpxr event 🙈 no fake numbers allowed, bestie
4.6.2.11.4. RCQEstAlg 🦋
this one gives the algorithm used to estimate ConversationalQualityR a text name 💖 it's free-form text, so it doesn't have to match any standard or recommendation. just vibes, basically 🌸
4.6.2.11.5. ExternalR-In 🧚
this field corresponds to "ext. R factor" in the VoIP Metrics Report Block from RFC 3611 🎀 it shows the voice quality the local endpoint measured for the incoming connection on the "other" side (go check RFC 3611 for the full explanation, it goes deeper). R is 0-95 for narrowband calls and 0-120 for wideband calls, and the algorithms SHOULD be compliant with ITU-T Recommendations P.564 and G.107 ✨ same deal with 127: RFC 3611 uses it to mean unavailable, and then the ConversationalQualityR parameter MUST be omitted from the vq-rtcpxr event 🙈
4.6.2.11.6. ExtRInEstAlg 💜
this is the text name for the algorithm used to estimate ExternalR-In 🫶 also free-form text, so it doesn't have to match any standards or recommendations, periodt 💅
4.6.2.11.7. ExternalR-Out 🌈
this one is also "ext. R factor" from RFC 3611's VoIP Metrics Report Block 🎀 the twist is that the value is copied from the RTCP XR message that came in from the remote endpoint on the "other" side of this endpoint (see RFC 3611 for the detailed version) 👑 R is 0-95 for narrowband and 0-120 for wideband, and the algorithms SHOULD be compliant with ITU-T Recommendations P.564 and G.107. and if RFC 3611 reports a factor of 127 (unavailable), then the ConversationalQualityR parameter SHALL be omitted from the vq-rtcpxr event 🙈 ngl this is the one with the "SHALL" instead of "MUST," so keep that in mind
4.6.2.11.8. ExtROutEstAlg 🍓
this gives the text name for the algorithm used to estimate ExternalR-Out ✨ free-form text again, so no need to match any standard or recommendation 🌸
4.6.2.11.9. MOS Reporting 💖
okay this part is important! converting the RFC 3611 reported mean opinion scores (MOSs) for use in reporting MOS-LQ and MOS-CQ MUST be done by dividing the RFC 3611 value by 10 if it's less than or equal to 50 🔥 or you omit the MOS-xQ parameter if the RFC 3611 value is 127, which means unavailable 🙈 no cap, the math is the main character here
4.6.2.11.9.1. MOS-LQ 🎀
this corresponds to "MOSLQ" in the VoIP Metrics Report Block from RFC 3611 🦋 it's the estimated mean opinion score for listening voice quality, on a scale from 1 to 5, where 5 is "Excellent" and 1 is "Unacceptable" 😭 the algorithms for computing it SHOULD be compliant with ITU-T Recommendation P.564 [10]. and this field also gives a text name for the algorithm used to estimate MOS-LQ 💅
4.6.2.11.9.2. MOS-CQ 💜
this one corresponds to "MOSCQ" in the VoIP Metrics Report Block from RFC 3611 ✨ it's the estimated mean opinion score for conversation voice quality, on a scale from 1 to 5, where 5 is excellent and 1 is unacceptable (lowercase this time, same idea 🌸). algorithms for computing it SHOULD be compliant with ITU-T Recommendation P.564, specifically for the listening quality element of the computed MOS score 🫶
4.6.2.11.9.3. MOSCQEstAlg 🧚
this provides a text name for the algorithm used to estimate MOS-CQ 💖 it's free-form text, so it doesn't have to line up with any standards or recommendations, iykyk 🙈
4.6.2.11.10. QoEEstAlg 👑
this field is a text description of the algorithm used to estimate all voice quality metrics 🌈 it's an alternative to the separate estimation algorithm fields, for when one algorithm is used for every measurement ✨ also free-form text, not necessarily reflective of any standards or recommendations 💅
4.7. Message Flow and Syntax Examples 🦋
this section shows a bunch of message flow examples so you can see how the event package actually 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 | |
| |<----------------------------------------|
| 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 in Figure 1, this is the message format that gets 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: <sip:collector@example.org>;tag=43524545
From: Alice <sip:alice@example.org>;tag=a3343df32
Call-ID: 1890463548
CSeq: 4321 NOTIFY
Contact: <sip:alice@pc22.example.org>
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
CallID: 6dg37f1890463
LocalID: Alice <sip:alice@example.org>
RemoteID: Bill <sip:bill@example.net>
OrigID: Alice <sip:alice@example.org>
LocalGroup: example-phone-55671
RemoteGroup: example-gateway-09871
LocalAddr: IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d
LocalMAC: 00:1f:5b:cc:21:0f
RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd
RemoteMAC: 00:26:08:8e:95:02
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
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=-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
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=9123dh3114.7.2. Midsession Threshold Violation Using NOTIFY 🦋
Okay bestie, this one is the "something went wrong MID-call" moment 😭 Alice registers with Allow-Event:vq-rtcpxr, the collector subscribes to that event, and then Alice and Bob get on a call. The alert shows up while the call is still going, so the collector hears about it right away 🚨
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 | |
|<============================================================>|
| NOTIFY Event:vq-rtcpxr F13 | |
|------------------->| | |
| | NOTIFY Event:vq-rtcpxr F14 |
| |------------------->| |
| | 200 OK F15 | |
| |<-------------------| |
| 200 OK F16 | | |
|<-------------------| | |
| | | |
| BYE F17 | | |
|------------------->| BYE F18 | |
| |---------------------------------------->|
| | 200 OK F19 | |
| |<----------------------------------------|
| 200 OK F20 | | |
|<-------------------| | |
| NOTIFY Event:vq-rtcpxr F21 | |
|------------------->| | |
| | NOTIFY Event:vq-rtcpxr F22 |
| |------------------->| |
| | 200 OK F23 | |
| |<-------------------| |
| 200 OK F24 | | |
|<-------------------| | |Figure 2. An alert report is sent during the session. 💖
In the call flow in Figure 2, the NOTIFY in F13 carries this message. It's giving full alert report energy 🔥
NOTIFY sip:collector@example.org SIP/2.0
Via: SIP/2.0/UDP pc22.example.org;branch=z9hG4bK3343d7
Max-Forwards: 70
To: <sip:proxy@example.org>
From: Alice <sip:alice@example.org>;tag=a3343df32
Call-ID: 1890463548
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: ...
VQAlertReport: Type=NLR Severity=Critical Dir=local
CallID: 6dg37f1890463
LocalID: Alice <sip:alice@example.org>
RemoteID: Bill <sip:bill@example.org>
OrigID: Alice <sip:alice@example.org>
LocalGroup: example-phone-55671
RemoteGroup: example-gateway-09871
LocalAddr:IP=10.10.1.100 PORT=5000 SSRC=0x2468abcd
LocalMAC: 00:1f:5b:cc:21:0f
RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=1357efff
RemoteMAC: 00:26:08:8e:95:02
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
JitterBuffer:JBA=3 JBR=2 JBN=40 JBM=80 JBX=120
PacketLoss:NLR=10.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=80 RCQ=85 EXTRI=90 MOSLQ=3.5 MOSCQ=3.7
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
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=9123dh3114.7.3. End of Session Report Using PUBLISH 🌈
Now the "call's over, here's the recap" version 💅 This time there's no alert in the middle. Alice and Bob talk, hang up, and then the report gets PUBLISHed after the BYE. Main character energy for end-of-call stats 🎀
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. 🧚
In the message flow in Figure 3, the following message is sent in F13. Cute, right? 🍓
PUBLISH sip:collector@example.org SIP/2.0
Via: SIP/2.0/UDP pc22.example.org;branch=z9hG4bK3343d7
Max-Forwards: 70
To: <sip:proxy@example.org>
From: Alice <sip:alice@example.org>;tag=a3343df32
Call-ID: 1890463548
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
CallID: 6dg37f1890463
LocalID: Alice <sip:alice@example.org>
RemoteID: Bill <sip:bill@example.net>
OrigID: Alice <sip:alice@example.org>
LocalGroup: example-phone-55671
RemoteGroup: example-gateway-09871
LocalAddr: IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d
LocalMAC: 00:1f:5b:cc:21:0f
RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd
RemoteMAC: 00:26:08:8e:95:02
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
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
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=9123dh3114.7.4. Alert Report Using PUBLISH ✨
okay so this one is the alert report flow 🚨 Alice, the proxy/registrar, the collector, and Bob all get involved, and the report gets sent with a PUBLISH once the call is already going. ngl the diagram is kinda iconic 💅
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 F11 | | |
|------------------->| BYE F12 | |
| |---------------------------------------->|
| | 200 OK F13 | |
| |<----------------------------------------|
| 200 OK F14 | | |
|<-------------------| | |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: <sip:collector@example.org>
From: Alice <sip:alice@example.org>;tag=a3343df32
Call-ID: 1890463548
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
CallID: 6dg37f1890463
LocalID: Alice <sip:alice@example.org>
RemoteID: Bill <sip:bill@example.org>
OrigID: Alice <sip:alice@example.org>
LocalGroup: example-phone-55671
RemoteGroup: example-gateway-09871
LocalAddr: IP=10.10.1.100 PORT=5000 SSRC=1a3b5c7d
LocalMAC: 00:1f:5b:cc:21:0f
RemoteAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd
RemoteMAC: 00:26:08:8e:95:02
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
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
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=9123dh31114.8. Configuration Dataset for vq-rtcpxr Events 🎀
The authors suggest using the SIP configuration framework [15] to set up the parameters needed for vq-rtcpxr events. A dataset for this purpose should be designed and documented in a separate document once the framework is done 🧚
5. IANA Considerations 📋
This document registers a new SIP Event Package and a new media type. Slay the registry 💅
5.1. SIP Event Package Registration
Package name: vq-rtcpxr
Type: package
Contact: Amy Pendleton <aspen@telchemy.com>
Published Specification: This document5.2. application/vq-rtcpxr Media Type Registration
Type name: application
Subtype name: vq-rtcpxr
Required parameters: none
Optional parameters: none
Encoding considerations: 7 bit
Security considerations: See next section.
Interoperability considerations: none.
Published specification: This document.
Applications that 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"
Person and email address for further information: Amy Pendleton
<aspen@telchemy.com>
Intended usage: COMMON
Author / Change controller: The IETF.6. Security Considerations 🔐
Okay this part is serious bestie 😭 RTCP reports can contain sensitive information, since they can tell you about the nature and duration of a session between two or more endpoints. So any third party that wants this information SHOULD be properly authenticated by the SIP UA, using standard SIP mechanisms and following the recommendations in [5]. Also, the event content MAY be encrypted to keep it confidential, and the mechanisms for that are detailed in [2]. Lock it down 🔒✨
7. Contributors 🫶
The authors would like to thank Rajesh Kumar, Dave Oran, Tom Redman, Shane Holthaus, and Jack Ford for their comments and input. Iconic squad 👑
8. References 📚
8.1. 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, "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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[7] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[8] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[9] ITU-T G.1020, "Performance parameter definitions for quality of speech and other voiceband applications utilizing IP networks".
[10] ITU-T P.564, "Conformance testing for voice over IP transmission quality assessment models".
[11] ITU-T G.107, "The E-model, a computational model for use in transmission planning".
[12] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
8.2. Informative References
[13] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[14] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design Considerations for Session Initiation Protocol (SIP) Overload Control", Work in Progress, July 2009.
[15] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, October 2010.
[16] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
Authors' Addresses 💌
Amy Pendleton
Telchemy Incorporated
EMail: aspen@telchemy.com
Alan Clark
Telchemy Incorporated
EMail: alan.d.clark@telchemy.com
Alan Johnston
Avaya
St. Louis, MO 63124
EMail: alan.b.johnston@gmail.com
Henry Sinnreich
Unaffiliated
EMail: henry.sinnreich@gmail.comThat's the whole RFC, bestie! 🌈💖 Every spec detail is locked in and the vibes are immaculate 🦋
📦 where this page comes from
- ietf: rfc6035 2010-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms