Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-37

Internet Engineering Task Force (IETF)                      A. Pendleton
Request for Comments: 6035                                      A. Clark
Category: Standards Track                          Telchemy Incorporated
ISSN: 2070-1721                                              A. Johnston
                                                                   Avaya
                                                            H. Sinnreich
                                                            Unaffiliated
                                                           November 2010

 Session Initiation Protocol Event Package for Voice Quality Reporting

Abstract

   This document defines a Session Initiation Protocol (SIP) event
   package that enables the collection and reporting of metrics that
   measure the quality for Voice over Internet Protocol (VoIP) sessions.
   Voice call quality information derived from RTP Control Protocol
   Extended Reports (RTCP-XR) and call information from SIP is conveyed
   from a User Agent (UA) in a session, known as a reporter, to a third
   party, known as a collector.  A registration for the application/ vq-
   rtcpxr media type is also included.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6035.

Pendleton, et al.            Standards Track                    [Page 1]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Pendleton, et al.            Standards Track                    [Page 2]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

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 ....................................41

Pendleton, et al.            Standards Track                    [Page 3]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

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 RTP Control Protocol Extended Reports [4] metrics.

1.1.  Applicability Statement

   RTP is utilized in many different architectures and topologies.  RFC
   5117 [13] lists and describes the following topologies: point-to-
   point, point-to-multipoint using multicast, point-to-multipoint using
   the 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 of this document points out, this specification is for
   reporting quality of Voice over Internet Protocol (VoIP) sessions.
   As such, only the first topology, point to point, is currently
   supported by this specification.  This reflects both current VoIP
   deployments, which are predominantly point to point using unicast,
   and the state of research in the area of quality.

   How to accurately report the quality of a multipart conference or a
   session involving multiple hops through translators and mixers is
   currently an area of research in the industry.  However, this
   mechanism can easily be used for centrally mixed conference calls, in
   which each leg of the conferences is just a point-to-point call.
   This mechanism could be extended to cover additional RTP topologies
   in the future once these topics progress out of the realm of research
   and into actual Internet deployments.

1.2.  Use of the Mechanism

   RTCP reports are usually sent to other participating endpoints in a
   session.  This can make the collection of performance information by
   an administrator or management system quite complex to implement.  In
   the usage scenarios addressed in this memo, the data contained in
   RTCP XR VoIP metrics reports (RFC 3611 [4]) are forwarded to a
   central collection server systems using SIP.

Pendleton, et al.            Standards Track                    [Page 4]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

   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.  However, specifying such applications is beyond the scope
   of this paper.

   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 Session Description
       Protocol (SDP) offer-answer negotiation in SIP,

   2.  The burst gap loss density and max gap duration, since voice cut-
       outs are the most annoying quality impairment in VoIP,

   3.  Round-trip delay, because it is critical to conversational
       quality,

   4.  Conversational quality as a catch-all for other voice quality
       impairments, such as randomly 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 they are very useful,
   they have a number of limitations as discussed in [3].  This must be
   considered when using RTCP reports in managed networks.

   This document defines a new SIP event package, vq-rtcpxr, and a new
   MIME type, application/vq-rtcpxr, that enable the collection and
   reporting of metrics that measure quality for RTP [3] sessions.  The
   definitions of the metrics used in the event package are based on
   RTCP Extended Reports [4] and RTCP [3]; a mapping between the SIP
   event parameters and the parameters within the aforementioned RFCs 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 the voice quality metrics for
   both the inbound and outbound directions.  Voice quality metrics for
   the inbound direction can generally be computed locally by the

Pendleton, et al.            Standards Track                    [Page 5]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

   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].

   The configuration of the usage of this event package is not covered
   in this document.  It is the recommendation of this document that the
   SIP configuration framework [15] be used.  This is discussed in
   Section 4.8.

   The event package SHOULD be used with the SUBSCRIBE/NOTIFY method;
   however, it MAY also be used with the PUBLISH method [8] 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 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 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: an entity involved in the measurement and reporting of
      media quality, i.e., the SIP UA involved in a media session.

   o  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

   The COLLECTOR SHALL send a SUBSCRIBE to the REPORTER to explicitly
   establish the relationship.  The REPORTER SHOULD send the voice
   quality metric reports using the NOTIFY method.  The REPORTER MUST
   NOT send any vq-rtcpxr events if a COLLECTOR address has not been
   configured.  The REPORTER populates the Request-URI according to the
   rules for an in-dialog request.  The COLLECTOR MAY send a SUBSCRIBE
   to a SIP Proxy acting on behalf of the reporting SIP UAs.

Pendleton, et al.            Standards Track                    [Page 6]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

3.2.  PUBLISH Method

   A SIP UA that supports this specification MAY also send the service
   quality metric reports using the PUBLISH method [8]; however, this
   approach SHOULD NOT be used, in general, on the public Internet.  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 [15], 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.

      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 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 an application/
   vq-rtcpxr body for each segment of the call.

3.4.  Overload Avoidance

   Users of this extension should ensure that they implement general SIP
   mechanisms for avoiding overload.  For instance, an overloaded proxy
   or COLLECTOR MUST send a 503 Service Unavailable or other 5xx
   response with an appropriate Retry-After time specified.  REPORTERs
   MUST act on these responses and respect the Retry-After time

Pendleton, et al.            Standards Track                    [Page 7]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

   interval.  In addition, future SIP extensions to better handle
   overload as covered in [14] should be followed as they are
   standardized.

   To avoid overload of SIP Proxies or COLLECTORS, it is important to do
   capacity planning and to minimize the number of reports that are
   sent.

   Approaches to avoiding overload include:

   a.  Send only one report at the end of each call.

   b.  Use interval reports only on "problem" calls that are being
       closely monitored.

   c.  Limit the number of alerts that can be sent to a maximum of one
       per call.

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.

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 occurs, such as a codec
   change or a session fork, or when a session terminates due to no
   media packets being received and MUST NOT be used for reporting at

Pendleton, et al.            Standards Track                    [Page 8]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

   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 of 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.

   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 applications that
   consistently and rapidly switch codecs, the most used codec should be
   reported.  All values in the report, such as IP addresses,
   synchronization source (SSRC), etc., represent those values as
   received by the REPORTER.  In some scenarios, these may not be the
   same on either end of the session -- the COLLECTOR will need logic to
   be able to put these sessions together.  The values of parameters
   such as sample rate, frame duration, frame octets, packets per
   second, round-trip delay, etc., depend on the type of report in which
   they are present.  If present in a Session or an Interval report,
   they represent average values over the session or interval.  If
   present in an Alert report, they represent instantaneous values.

   The REPORTER always includes local quality reporting information and
   should, if possible, share remote quality reporting information to
   the COLLECTOR.  This remote quality could be available from received
   RTCP-XR reports or other sources.  Reporting this is useful in cases
   where 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
   additional metrics and correlation information.

Pendleton, et al.            Standards Track                    [Page 9]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

4.6.  Voice Quality Event 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 contain references to elements defined therein.

   Additionally, the definition of the timestamp format is provided in
   [7].  Note that most of the parameters are optional.  In practice,
   most implementations will send a subset of the parameters.  It is not
   the intention of this document to define what parameters may or may
   not be useful for monitoring the quality of a voice session, but to
   enable reporting of voice quality.  As such, the syntax allows the
   implementer to choose which metrics are most appropriate for their
   solution.  As there are no "invalid", "unknown", or "not applicable"
   values in the syntax, the intention is to exclude any parameters for
   which values are not available, not applicable, or unknown.

   The authors recognize that implementers may need to add new parameter
   lines to the reports and new metrics to the existing parameter lines.
   The extension tokens are intended to fulfill this need.

4.6.1.  ABNF Syntax Definition

VQReportEvent  =  AlertReport /  SessionReport / IntervalReport

SessionReport = "VQSessionReport" [ 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 ]

Pendleton, et al.            Standards Track                   [Page 10]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

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 ]

Pendleton, et al.            Standards Track                   [Page 11]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

   [ 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)

Pendleton, et al.            Standards Track                   [Page 12]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

; 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

Pendleton, et al.            Standards Track                   [Page 13]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

; 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

Pendleton, et al.            Standards Track                   [Page 14]
RFC 6035         SIP Package for Voice Quality Reporting   November 2010

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 [ ".

      56:d=4  hl=4 l= 873 cons: cont [ 0 ]
      60:d=5  hl=4 l= 869 prim: OCTET STRING      :{"ietf-voucher:voucher":
     933:d=3  hl=4 l= 483 cons: cont [ 0 ]
     937:d=4  hl=4 l= 479 cons: SEQUENCE
     941:d=5  hl=4 l= 356 cons: SEQUENCE
     945:d=6  hl=2 l=   3 cons: cont [ 0 ]
     947:d=7  hl=2 l=   1 prim: INTEGER           :02
     950:d=6  hl=2 l=   4 prim: INTEGER           :1B995F54
     956:d=6  hl=2 l=  10 cons: SEQUENCE
     958:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
     968:d=6  hl=2 l=  93 cons: SEQUENCE
     970:d=7  hl=2 l=  15 cons: SET
     972:d=8  hl=2 l=  13 cons: SEQUENCE
     974:d=9  hl=2 l=   3 prim: OBJECT            :countryName
     979:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
     987:d=7  hl=2 l=  16 cons: SET
     989:d=8  hl=2 l=  14 cons: SEQUENCE
     991:d=9  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
     996:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
    1005:d=7  hl=2 l=  18 cons: SET
    1007:d=8  hl=2 l=  16 cons: SEQUENCE
    1009:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
    1014:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
    1025:d=7  hl=2 l=  36 cons: SET
    1027:d=8  hl=2 l=  34 cons: SEQUENCE
    1029:d=9  hl=2 l=   3 prim: OBJECT            :commonName
    1034:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
    1063:d=6  hl=2 l=  30 cons: SEQUENCE
    1065:d=7  hl=2 l=  13 prim: UTCTIME           :190212222241Z
    1080:d=7  hl=2 l=  13 prim: UTCTIME           :210211222241Z
    1095:d=6  hl=2 l=  95 cons: SEQUENCE
    1097:d=7  hl=2 l=  15 cons: SET
    1099:d=8  hl=2 l=  13 cons: SEQUENCE
    1101:d=9  hl=2 l=   3 prim: OBJECT            :countryName
    1106:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
    1114:d=7  hl=2 l=  16 cons: SET
    1116:d=8  hl=2 l=  14 cons: SEQUENCE
    1118:d=9  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
    1123:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
    1132:d=7  hl=2 l=  18 cons: SET
    1134:d=8  hl=2 l=  16 cons: SEQUENCE
    1136:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
    1141:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
    1152:d=7  hl=2 l=  38 cons: SET
    1154:d=8  hl=2 l=  36 cons: SEQUENCE
    1156:d=9  hl=2 l=   3 prim: OBJECT            :commonName
    1161:d=9  hl=2 l=  29 prim: UTF8STRING        :highway-test.example.com
    1192:d=6  hl=2 l=  89 cons: SEQUENCE

Pritikin, et al.         Expires 29 August 2020               [Page 119]
Internet-Draft                    BRSKI                    February 2020

    1194:d=7  hl=2 l=  19 cons: SEQUENCE
    1196:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
    1205:d=8  hl=2 l=   8 prim: OBJECT            :prime256v1
    1215:d=7  hl=2 l=  66 prim: BIT STRING
    1283:d=6  hl=2 l=  16 cons: cont [ 3 ]
    1285:d=7  hl=2 l=  14 cons: SEQUENCE
    1287:d=8  hl=2 l=  12 cons: SEQUENCE
    1289:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
    1294:d=9  hl=2 l=   1 prim: BOOLEAN           :255
    1297:d=9  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000
    1301:d=5  hl=2 l=  10 cons: SEQUENCE
    1303:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
    1313:d=5  hl=2 l= 105 prim: BIT STRING
    1420:d=3  hl=4 l= 316 cons: SET
    1424:d=4  hl=4 l= 312 cons: SEQUENCE
    1428:d=5  hl=2 l=   1 prim: INTEGER           :01
    1431:d=5  hl=2 l= 101 cons: SEQUENCE
    1433:d=6  hl=2 l=  93 cons: SEQUENCE
    1435:d=7  hl=2 l=  15 cons: SET
    1437:d=8  hl=2 l=  13 cons: SEQUENCE
    1439:d=9  hl=2 l=   3 prim: OBJECT            :countryName
    1444:d=9  hl=2 l=   6 prim: PRINTABLESTRING   :Canada
    1452:d=7  hl=2 l=  16 cons: SET
    1454:d=8  hl=2 l=  14 cons: SEQUENCE
    1456:d=9  hl=2 l=   3 prim: OBJECT            :stateOrProvinceName
    1461:d=9  hl=2 l=   7 prim: UTF8STRING        :Ontario
    1470:d=7  hl=2 l=  18 cons: SET
    1472:d=8  hl=2 l=  16 cons: SEQUENCE
    1474:d=9  hl=2 l=   3 prim: OBJECT            :organizationalUnitName
    1479:d=9  hl=2 l=   9 prim: UTF8STRING        :Sandelman
    1490:d=7  hl=2 l=  36 cons: SET
    1492:d=8  hl=2 l=  34 cons: SEQUENCE
    1494:d=9  hl=2 l=   3 prim: OBJECT            :commonName
    1499:d=9  hl=2 l=  27 prim: UTF8STRING        :highway-test.example.com
    1528:d=6  hl=2 l=   4 prim: INTEGER           :1B995F54
    1534:d=5  hl=2 l=  11 cons: SEQUENCE
    1536:d=6  hl=2 l=   9 prim: OBJECT            :sha256
    1547:d=5  hl=2 l= 105 cons: cont [ 0 ]
    1549:d=6  hl=2 l=  24 cons: SEQUENCE
    1551:d=7  hl=2 l=   9 prim: OBJECT            :contentType
    1562:d=7  hl=2 l=  11 cons: SET
    1564:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
    1575:d=6  hl=2 l=  28 cons: SEQUENCE
    1577:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
    1588:d=7  hl=2 l=  15 cons: SET
    1590:d=8  hl=2 l=  13 prim: UTCTIME           :200225213312Z
    1605:d=6  hl=2 l=  47 cons: SEQUENCE
    1607:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest

Pritikin, et al.         Expires 29 August 2020               [Page 120]
Internet-Draft                    BRSKI                    February 2020

    1618:d=7  hl=2 l=  34 cons: SET
    1620:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:146846F9F378D9
    1654:d=5  hl=2 l=  10 cons: SEQUENCE
    1656:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
    1666:d=5  hl=2 l=  72 prim: OCTET STRING      [HEX DUMP]:30460221008ECD

Appendix D.  Additional References

   RFC EDITOR Please remove this section before publication.  It exists
   just to include references to the things in the YANG descriptions
   which are not otherwise referenced in the text so that xml2rfc will
   not complain.

   [ITU.X690.1994]

Authors' Addresses

   Max Pritikin
   Cisco

   Email: pritikin@cisco.com

   Michael C. Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca
   URI:   http://www.sandelman.ca/

   Toerless Eckert
   Futurewei Technologies Inc.  USA
   2330 Central Expy
   Santa Clara,  95050
   United States of America

   Email: tte+ietf@cs.fau.de

   Michael H. Behringer

   Email: Michael.H.Behringer@gmail.com

   Kent Watsen
   Watsen Networks

   Email: kent+ietf@watsen.net

Pritikin, et al.         Expires 29 August 2020               [Page 121]