SIPPING Working Group A. Pendleton
Internet Draft Nortel
A. Clark
Telchemy
A. Johnston
Avaya
H. Sinnreich
Adobe
Intended status: Informational October 7, 2008
Expires: April 11, 2009
Session Initiation Protocol Package for Voice Quality Reporting
Event
draft-ietf-sipping-rtcp-summary-05
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 11, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
Pendleton [Page 1]
draft-ietf-sipping-rtcp-summary 7 October 2008
Table of Contents
1. Introduction...................................................2
1.1. Usage Scenarios...........................................2
2. Terminology....................................................4
3. SIP Events for Voice over IP Performance Reporting.............5
3.1. SUBSCRIBE/NOTIFY method...................................5
3.2. PUBLISH method............................................5
3.3. Multi-Party and Multi-Segment Calls.......................5
3.4. Overload Avoidance........................................6
4. Event Package Formal Definition................................6
4.1. Event Package Name........................................6
4.2. Event Package Parameters..................................6
4.3. SUBSCRIBE Bodies..........................................6
4.4. Subscription Duration.....................................6
4.5. NOTIFY and PUBLISH Bodies.................................6
4.6. Voice Quality Event Syntax and Semantics..................7
4.6.1. ABNF Syntax Definition...............................8
4.6.2. Parameter Definitions and Mappings..................16
4.7. Message Flow and Syntax Examples.........................24
4.7.1. End of Session Report using NOTIFY..................24
4.7.2. Mid Session Threshold Violation using NOTIFY........26
4.7.3. End of Session Report using PUBLISH.................28
4.7.4. Alert Report using PUBLISH..........................30
4.8. Configuration Dataset for vq-rtcpxr Events...............31
5. IANA Considerations...........................................32
5.1. SIP Event Package Registration...........................32
5.2. application/vq-rtcp-xr MIME Registration.................32
6. Security Considerations.......................................33
7. Contributors..................................................33
8. Normative References..........................................33
Author's Addresses...............................................34
Intellectual Property Statement..................................35
Disclaimer of Validity...........................................35
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. Usage Scenarios
Pendleton [Page 2]
draft-ietf-sipping-rtcp-summary 7 October 2008
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.
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
Pendleton [Page 3]
draft-ietf-sipping-rtcp-summary 7 October 2008
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.
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 forementioned 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 [Page 4]
draft-ietf-sipping-rtcp-summary 7 October 2008
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 SHALL populate the Request-URI of the NOTIFY method
with the address of the COLLECTOR.
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.
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
Pendleton [Page 5]
draft-ietf-sipping-rtcp-summary 7 October 2008
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.4. Overload Avoidance
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
Limit the number of alerts that can be sent to a maximum of one per
call
Additionally, it is recommended that COLLECTORS that receive these
reports use the 503 ''Service Unavailable'' error response code to
limit unwanted reports and include the Retry-after header with an
appropriate time delay, depending on the needs of the COLLECTOR.
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
No 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
Pendleton [Page 6]
draft-ietf-sipping-rtcp-summary 7 October 2008
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.
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.
Additionally, 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.
Pendleton [Page 7]
draft-ietf-sipping-rtcp-summary 7 October 2008
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]
[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
Pendleton [Page 8]
draft-ietf-sipping-rtcp-summary 7 October 2008
; 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
; 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*5DIGIT) *(SEMI (1*5DIGIT))
; FrameDuration can be combined with the FramesPerPacket
; to determine the packetization rate; the units for
; FrameDuration are milliseconds.
FrameDuration = "FD" EQUAL (1*3DIGIT)
; FrameOctets provides the number of octets in each frame
; This MAY be used where FrameDuration is not available
FrameOctets = "FO" EQUAL (1*4DIGIT)
; FramesPerPacket provides the number of frames in each RTP
; packet
FramesPerPacket = "FPP" EQUAL (1*2DIGIT)
; Packets per second provides the average number of packets
Pendleton [Page 9]
draft-ietf-sipping-rtcp-summary 7 October 2008
; that are transmitted per second.
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 header
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.
Pendleton [Page 10]
draft-ietf-sipping-rtcp-summary 7 October 2008
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]
[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]
Pendleton [Page 11]
draft-ietf-sipping-rtcp-summary 7 October 2008
[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" COLON
[RoundTripDelay WSP]
[EndSystemDelay WSP]
[OneWayDelay WSP]
[SymmOneWayDelay WSP]
[InterarrivalJitter WSP]
[MeanAbsoluteJitter]
*(WSP Extension)
; RoundTripDelay is recommended to 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
Pendleton [Page 12]
draft-ietf-sipping-rtcp-summary 7 October 2008
; by ITU-T G.1020 [10] where it is known as MAPDV
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
QualityEstimates = "QualityEst" COLON
[ListeningQualityR WSP]
[RLQEstAlg WSP]
Pendleton [Page 13]
draft-ietf-sipping-rtcp-summary 7 October 2008
[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
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
Pendleton [Page 14]
draft-ietf-sipping-rtcp-summary 7 October 2008
; 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
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 / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
Pendleton [Page 15]
draft-ietf-sipping-rtcp-summary 7 October 2008
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 / "-" / "." / "!" / "%" / "*" /
"_" / "+" / "`" / "'" / "~" /
"(" / ")" / "<" / ">" / ":" /
"\" / "/" / "[" / "]" / "?" /
"{" / "}" / "=" / " ")
4.6.2. Parameter Definitions and Mappings
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.
Pendleton [Page 16]
draft-ietf-sipping-rtcp-summary 7 October 2008
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.
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.
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
FrameDuration is provided.
Frames Per Packet
Pendleton [Page 17]
draft-ietf-sipping-rtcp-summary 7 October 2008
This parameter is not contained in RTP or SDP but can usually be
obtained from the device codec. This field provides the number of
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.
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.
Pendleton [Page 18]
draft-ietf-sipping-rtcp-summary 7 October 2008
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
Network Packet Loss Rate
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
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
Pendleton [Page 19]
draft-ietf-sipping-rtcp-summary 7 October 2008
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.
One Way Delay
This value SHOULD be measured using the methods defined in IETF
RFC2679. The parameter is expressed in milliseconds.
Interarrival 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.
4.6.2.10. Signal-related Parameters
Signal Level
Pendleton [Page 20]
draft-ietf-sipping-rtcp-summary 7 October 2008
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 provide 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
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.
Pendleton [Page 21]
draft-ietf-sipping-rtcp-summary 7 October 2008
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
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].
MOSLQEstAlg
Pendleton [Page 22]
draft-ietf-sipping-rtcp-summary 7 October 2008
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
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.
Pendleton [Page 23]
draft-ietf-sipping-rtcp-summary 7 October 2008
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 | |
| |<----------------------------------------|
| 200 OK F16 | | |
|<-------------------| | |
| NOTIFY Event:vq-rtcpxr F17 | |
|------------------->| | |
| | NOTIFY Event:vq-rtcpxr F18 |
| |------------------->| |
| | 200 OK F19 | |
Pendleton [Page 24]
draft-ietf-sipping-rtcp-summary 7 October 2008
| |<-------------------| |
| 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: <sip:collector@example.org>;tag=43524545
From: Alice <sip:alice@example.org>;tag=a3343df32
Call-ID: 1890463548@alice.example.org
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
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:1890463548@alice.example.org
FromID: Alice <sip:alice@example.org>
ToID: Bill <sip:bill@elpmaxe.org>
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
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:1890463548@alice.example.org
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
Pendleton [Page 25]
draft-ietf-sipping-rtcp-summary 7 October 2008
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 | | |
|------------------->| | |
| | 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 | |
| |<----------------------------------------|
Pendleton [Page 26]
draft-ietf-sipping-rtcp-summary 7 October 2008
| 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:
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>
From: Alice <sip:alice@example.org>;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:1890463548@alice.example.org
FromID: Alice <sip:alice@example.org>
ToID: Bill <sip:bill@elpmaxe.org>
LocalAddr:IP=10.10.1.100 PORT=5000 SSRC=0x1a3b5c7d
RemoteAddr:IP=11.1.1.150 PORT=5002 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=-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
CallID:1890463548@alice.example.org
LocalAddr:IP=11.1.1.150 PORT=5002 SSRC=0x2468abcd
Pendleton [Page 27]
draft-ietf-sipping-rtcp-summary 7 October 2008
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=10
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.1
QoEEstAlg=P.564
DialogID:1890463548@alice.example.org;to-tag=8472761;
from-tag=9123dh31111
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 | | |
|<-------------------| | |
Pendleton [Page 28]
draft-ietf-sipping-rtcp-summary 7 October 2008
Figure 3. End of session report sent after session termination.
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: <sip:proxy@example.org>
From: Alice <sip:alice@example.org>;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:1890463548@alice.example.org
FromID: Alice <sip:alice@example.org>
ToID: Bill <sip:bill@elpmaxe.org>
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:1890463548@alice.example.org
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
Pendleton [Page 29]
draft-ietf-sipping-rtcp-summary 7 October 2008
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 | | |
|<-------------------| | |
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@alice.example.org
CSeq: 4321 PUBLISH
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Pendleton [Page 30]
draft-ietf-sipping-rtcp-summary 7 October 2008
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:1890463548@alice.example.org
FromID: Alice <sip:alice@example.org>
ToID: Bill <sip:bill@elpmaxe.org>
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
CallID:1890463548@alice.example.rog
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 is provided
below:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:vqrtcpxrdataset"
xmlns:tns="urn:ietf:params:xml:ns:vqrtcpxrdataset"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
Pendleton [Page 31]
draft-ietf-sipping-rtcp-summary 7 October 2008
<xs:element name="rtcpxr-collector">
<xs:complexType>
<xs:sequence>
<xs:element name="address" type="xs:string"/>
<xs:element name="port" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="threshold-parameter-list">
<xs:complexType>
<xs:sequence>
<xs:element name="threshold-parameter">
<xs:sequence>
<xs:element name="parameter-name" type="xs:string"/>
<xs:element name="warning-level" type="xs:integer"/>
<xs:element name="excessive-level"
type="xs:integer"/>
</xs:sequence>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="session-report-settings">
<xs:complexType>
<xs:sequence>
<xs:element name="enable" type="xs:boolean"/>
<xs:element name="remote-report" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="interval-report-settings">
<xs:complexType>
<xs:sequence>
<xs:element name="enable" type="xs:boolean"/>
<xs:element name="remote-report" type="xs:boolean"/>
<xs:element name="timer" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
5. IANA Considerations
This document registers a new SIP Event Package and a new MIME type.
5.1. SIP Event Package Registration
Pendleton [Page 32]
draft-ietf-sipping-rtcp-summary 7 October 2008
Package name: vq-rtcpx
Type: package
Contact: Amy Pendleton <aspen@nortel.com>
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.
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
<aspen@nortel.com>
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.
Pendleton [Page 33]
draft-ietf-sipping-rtcp-summary 7 October 2008
[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] 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
Author's Addresses
Amy Pendleton
Nortel
2380 Performance Drive
Richardson, TX 75081, USA
Email: aspen@nortel.com
Pendleton [Page 34]
draft-ietf-sipping-rtcp-summary 7 October 2008
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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Pendleton [Page 35]
draft-ietf-sipping-rtcp-summary 7 October 2008
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pendleton [Page 36]
Datatracker
Report a datatracker bug
draft-ietf-sipping-rtcp-summary-05
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6035.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| Replaces | draft-johnston-sipping-rtcp-summary | ||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |