Internet DRAFT - draft-scholz-ipfix-rtp-msg
draft-scholz-ipfix-rtp-msg
Network Working Group H. Scholz
Internet-Draft VOIPFUTURE GmbH
Intended status: Informational March 5, 2012
Expires: September 6, 2012
RTP Stream Information Export using IPFIX
draft-scholz-ipfix-rtp-msg-00
Abstract
This draft defines a set of Information Elements and matching
Templates to convey RTP media stream information in IPFIX packets.
The Information Elements describe the RTP header and payload
characteristics of the RTP stream either for the entire duration of
the monitored stream or for a smaller time slice.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 6, 2012.
Copyright Notice
Copyright (c) 2012 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.
Scholz Expires September 6, 2012 [Page 1]
Internet-Draft RTP Streams in IPFIX March 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1. Quality of Service (QoS) Monitoring . . . . . . . . . 5
1.1.2. Service Level Agreement (SLA) . . . . . . . . . . . . 5
1.1.3. Troubleshooting . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Base RTP Information Elements . . . . . . . . . . . . . . . . 6
3.1. rtpObservationType . . . . . . . . . . . . . . . . . . . . 6
3.2. rtpFlowId . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. rtpStartTime . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. rtpEndTime . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. rtpSampleOffset . . . . . . . . . . . . . . . . . . . . . 8
3.6. rtpSampleTime . . . . . . . . . . . . . . . . . . . . . . 8
3.7. rtpStreamState . . . . . . . . . . . . . . . . . . . . . . 8
3.8. rtpProtocolVersion . . . . . . . . . . . . . . . . . . . . 9
3.9. rtpPayloadType . . . . . . . . . . . . . . . . . . . . . . 9
3.10. rtpMediaType . . . . . . . . . . . . . . . . . . . . . . . 10
3.11. rtpMediaSubType . . . . . . . . . . . . . . . . . . . . . 10
3.12. rtpIsSRTP . . . . . . . . . . . . . . . . . . . . . . . . 11
3.13. rtpSSRC . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.14. rtpCSRC . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.15. rtpTimestamp . . . . . . . . . . . . . . . . . . . . . . . 11
4. RTP Payload Information Elements . . . . . . . . . . . . . . . 12
4.1. rtpPacketCount . . . . . . . . . . . . . . . . . . . . . . 12
4.2. rtpPacketCountLoss . . . . . . . . . . . . . . . . . . . . 12
4.3. rtpPacketCountDiscarded . . . . . . . . . . . . . . . . . 13
4.4. rtpCodecChange . . . . . . . . . . . . . . . . . . . . . . 13
4.5. rtpMarkerBit . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. rtpComfortNoise . . . . . . . . . . . . . . . . . . . . . 14
4.7. rtpDTMFTones . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. rtpPacketization . . . . . . . . . . . . . . . . . . . . . 14
4.9. rtpPacketizationChange . . . . . . . . . . . . . . . . . . 14
4.10. rtpDSCPChange . . . . . . . . . . . . . . . . . . . . . . 15
Scholz Expires September 6, 2012 [Page 2]
Internet-Draft RTP Streams in IPFIX March 2012
5. Quality of Service Information Elements . . . . . . . . . . . 15
5.1. rtpSenderSynchronization . . . . . . . . . . . . . . . . . 15
5.2. rtpSenderRestart . . . . . . . . . . . . . . . . . . . . . 15
5.3. rtpSenderJitter . . . . . . . . . . . . . . . . . . . . . 15
5.4. rtpNetworkOverload . . . . . . . . . . . . . . . . . . . . 15
5.5. rtpOverloadWithPacketLoss . . . . . . . . . . . . . . . . 15
5.6. rtpTolerableJitter . . . . . . . . . . . . . . . . . . . . 15
5.7. rtpCriticalJitter . . . . . . . . . . . . . . . . . . . . 16
5.8. rtpVeryLargeJitter . . . . . . . . . . . . . . . . . . . . 16
5.9. rtpTolerablePacketLoss . . . . . . . . . . . . . . . . . . 17
5.10. rtpCriticalPacketLoss . . . . . . . . . . . . . . . . . . 17
5.11. rtpCriticalLossDensity . . . . . . . . . . . . . . . . . . 18
5.12. rtpOverloadWithPacketOrder . . . . . . . . . . . . . . . . 18
5.13. rtpDuplicates . . . . . . . . . . . . . . . . . . . . . . 18
5.14. rtpPacketOrder . . . . . . . . . . . . . . . . . . . . . . 18
5.15. rtpSequenceError . . . . . . . . . . . . . . . . . . . . . 18
5.16. rtpLowPacketInterval . . . . . . . . . . . . . . . . . . . 19
5.17. rtpNoPacketInterval . . . . . . . . . . . . . . . . . . . 19
5.18. rtpBadRTPTimestamp . . . . . . . . . . . . . . . . . . . . 19
5.19. rtpMinJitter . . . . . . . . . . . . . . . . . . . . . . . 19
5.20. Average Jitter . . . . . . . . . . . . . . . . . . . . . . 19
5.20.1. rtpJitterCount . . . . . . . . . . . . . . . . . . . 20
5.20.2. rtpJitterSum . . . . . . . . . . . . . . . . . . . . 20
5.21. rtpMaxJitter . . . . . . . . . . . . . . . . . . . . . . . 20
5.22. Jitter histogram . . . . . . . . . . . . . . . . . . . . . 20
5.22.1. rtpJitterBucket0 . . . . . . . . . . . . . . . . . . 21
5.22.2. rtpJitterBucket5 . . . . . . . . . . . . . . . . . . 21
5.22.3. rtpJitterBucket10 . . . . . . . . . . . . . . . . . . 21
5.22.4. rtpJitterBucket15 . . . . . . . . . . . . . . . . . . 22
5.22.5. rtpJitterBucket20 . . . . . . . . . . . . . . . . . . 22
5.22.6. rtpJitterBucket25 . . . . . . . . . . . . . . . . . . 22
5.22.7. rtpJitterBucket30 . . . . . . . . . . . . . . . . . . 22
5.22.8. rtpJitterBucket35 . . . . . . . . . . . . . . . . . . 23
5.22.9. rtpJitterBucket40 . . . . . . . . . . . . . . . . . . 23
5.22.10. rtpJitterBucket45 . . . . . . . . . . . . . . . . . . 23
5.22.11. rtpJitterBucket50 . . . . . . . . . . . . . . . . . . 24
5.22.12. rtpJitterBucket55 . . . . . . . . . . . . . . . . . . 24
5.22.13. rtpJitterBucket60 . . . . . . . . . . . . . . . . . . 24
5.22.14. rtpJitterBucket65 . . . . . . . . . . . . . . . . . . 24
5.22.15. rtpJitterBucket70 . . . . . . . . . . . . . . . . . . 25
5.22.16. rtpJitterBucket75 . . . . . . . . . . . . . . . . . . 25
5.22.17. rtpJitterBucket80 . . . . . . . . . . . . . . . . . . 25
5.22.18. rtpJitterBucket85 . . . . . . . . . . . . . . . . . . 26
5.22.19. rtpJitterBucket90 . . . . . . . . . . . . . . . . . . 26
5.22.20. rtpJitterBucket95 . . . . . . . . . . . . . . . . . . 26
5.22.21. rtpJitterBucket100 . . . . . . . . . . . . . . . . . 26
5.23. rtpDelayType . . . . . . . . . . . . . . . . . . . . . . . 27
5.24. rtpDelayOneWay . . . . . . . . . . . . . . . . . . . . . . 27
Scholz Expires September 6, 2012 [Page 3]
Internet-Draft RTP Streams in IPFIX March 2012
6. MOS measurement . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. rtpMOSCAlg . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. rtpMOSClass1 . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. rtpMOSClass2 . . . . . . . . . . . . . . . . . . . . . . . 29
6.4. rtpMOSClass3 . . . . . . . . . . . . . . . . . . . . . . . 29
6.5. rtpMOSClass4 . . . . . . . . . . . . . . . . . . . . . . . 30
6.6. rtpMOSClass5 . . . . . . . . . . . . . . . . . . . . . . . 30
6.7. rtpMinMOS . . . . . . . . . . . . . . . . . . . . . . . . 30
6.8. rtpAvgMOS . . . . . . . . . . . . . . . . . . . . . . . . 31
6.9. rtpMaxMOS . . . . . . . . . . . . . . . . . . . . . . . . 31
6.10. rtpMinRFactor . . . . . . . . . . . . . . . . . . . . . . 31
6.11. rtpAvgRFactor . . . . . . . . . . . . . . . . . . . . . . 31
6.12. rtpMaxRFactor . . . . . . . . . . . . . . . . . . . . . . 32
7. Recommended Templates . . . . . . . . . . . . . . . . . . . . 32
7.1. Entire stream . . . . . . . . . . . . . . . . . . . . . . 32
7.2. Time slice . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
Scholz Expires September 6, 2012 [Page 4]
Internet-Draft RTP Streams in IPFIX March 2012
1. Introduction
IPFIX [RFC5101] and [RFC5102] defines a framework allowing to export
arbitrary data from so called IPFIX exporters. One type of IPFIX
exporter may be co-located or passively observe Session Initiation
Protocol (SIP) [RFC3261] based VoIP calls. The signaling messages
can be exported using [I-D.trammell-ipfix-sip-msg] which leaves the
Real Time Protocol (RTP) [RFC3550] media streams unmonitored. This
document defines a set of additional IPFIX Information Elements (IEs)
to describe RTP streams on various levels. These layers include the
IP transport, RTP header information as well as Quality of Service
(QoS) information of monitored streams.
1.1. Use Cases
RTP stream flow information contained in IPFIX flow records can be
used for various tasks such as Quality of Service (QoS) monitoring,
Service Level Agreement (SLA) validation and general troubleshooting
of VoIP networks.
1.1.1. Quality of Service (QoS) Monitoring
Aggregated to higher-level metrics the in-depth information provided
by the RTP (and optionally SIP) flow records allows service providers
to gauge the overall quality of their network in terms of the quality
of experience (QoE). On this level an individual call is less
important but the overall quality (e.g. amount of minutes meeting
certain quality standards) can be used to get a quick overview on the
network and service performance.
1.1.2. Service Level Agreement (SLA)
SLAs are typically used as part of contracts between two network
operators. The requirements on the reliability of the data may be
higher compared to QoS Monitoring as the failure to meet
contractually agreed quality standards often has a direct commercial
impact.
1.1.3. Troubleshooting
An active network component (SIP proxy, B2BUA, media server) may not
have the capabilities to store session related information for a long
time to facilitate troubleshooting capabilities (e.g. due to missing
harddisk). Such a system or a group of systems may run the metering
process and export the data to a collector for processing or
troubleshooting purposes.
Scholz Expires September 6, 2012 [Page 5]
Internet-Draft RTP Streams in IPFIX March 2012
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Base RTP Information Elements
The base RTP Information Elements cover information transported
outside the Real Time Protocol [RFC3550] or defined by the Metering
Process.
3.1. rtpObservationType
Description: The rtpObservationType is similar to the
sipObservationType from [I-D.trammell-ipfix-sip-msg].
0: unknown: The Metering Process does not specify the observation
type
1: receiver: The Metering Process is, or is co-located with, the
receiver of the RTP stream.
2: sender: The Metering Process is, or is co-located with, the
sender of the RTP stream.
3: passive: The Metering Process passively observed the RTP
stream.
4: rtcp: TBD
Data Type: unsigned8
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.2. rtpFlowId
The rtpFlowId field is used to identify the RTP stream covered in
this flow record. It shall be used to correlate the RTP stream to
IPFIX SIP sessions. The rtpFlowId is calculated using a 5-tuple of
source IP, source port, destination IP, destination port and
transport protocol. Additionally the RTP SSRC is added. The exact
calculation method is up for discussion. VOIPFUTURE uses a 64Bit
Scholz Expires September 6, 2012 [Page 6]
Internet-Draft RTP Streams in IPFIX March 2012
hash value.
Description: Hash value identifying the observed RTP stream.
Data Type: unsigned64
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.3. rtpStartTime
Description: Start time of the RTP stream in milliseconds since 0000
UTC Jan 1, 1970. The time is taken from the local clock and not
from the RTP stream timestamp field. The local clock SHALL be NTP
synchronized. If this flow record covers only part of an RTP
stream the start time must be set to the start time of the
observation time/interval.
Data Type: dateTimeMilliseconds
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.4. rtpEndTime
Description: End time of the RTP stream in milliseconds since 0000
UTC Jan 1, 1970. The time is taken from the local clock and not
from the RTP stream timestamp field. The local clock SHALL be NTP
synchronized. If this flow record covers only part of an RTP
stream the end time must be set to the end time of the observation
time/interval.
Data Type: dateTimeMilliseconds
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
Scholz Expires September 6, 2012 [Page 7]
Internet-Draft RTP Streams in IPFIX March 2012
3.5. rtpSampleOffset
Description: Offset of the observation interval contained in this
flow record. The value is measured in milliseconds and contains
the offset of the beginning of the flow record from the beginning
of the RTP stream.
Data Type: unsigned32
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.6. rtpSampleTime
An IPFIX observer may generate and export a flow record for the
entire duration of an RTP stream or for a specific part, e.g. a fixed
time slice of 10 seconds. In case a single flow record is created
the rtpSampleTime equals the RTP stream duration in milliseconds. In
either case the rtpStreamState IE should be set to true if this flow
record describes an ended RTP stream.
Description: Duration of the observation time of this flow record
measured in milliseconds.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
3.7. rtpStreamState
Using the rtpSampleOffset and rtpSampleTime IEs flow entries may be
generated which describe only part of an RTP stream. This IE is used
to describe the state of the observed stream, e.g. to indicate the
reception of the last flow record belonging to a single RTP stream.
Description:
0: undefined: The state of the stream is not known.
Scholz Expires September 6, 2012 [Page 8]
Internet-Draft RTP Streams in IPFIX March 2012
1: running: The Metering Process expects more RTP packets or has
already received packets for this RTP stream which are outside
the scope of this flow record.
2: ended: The Metering Process determined that the RTP stream
ended. Information sources could be signaling information or
the fact that no RTP media has been received for a longer
period of time.
3: no packets: The Metering Process has not received any RTP
packets for this RTP stream in the observation interval but the
stream has not ended. A VoIP endpoint may have requested the
media stream to be suspended, i.e. put 'on hold' (tbd:reference
to sendonly ..)
Data Type: unsigned8
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.8. rtpProtocolVersion
Description: Value of the RTP version taken from the RTP header.
For RFC 3550 [RFC3550] RTP packets this will typically be set to
2.
Data Type: unsigned8
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.9. rtpPayloadType
Description: Payload Type (PT) as conveyed in RTP header
Data Type: unsigned8
Data Type Semantics: identifier
Scholz Expires September 6, 2012 [Page 9]
Internet-Draft RTP Streams in IPFIX March 2012
PEN (provisional): xxx
ElementId (provisional): xxx
3.10. rtpMediaType
Every RTP stream falls into a certain category, e.g. audio or video.
These RTP media types have been defined in [RFC4566] and are carried
in this Information Element. A Metering Process may learn these
based on the information in the RTP stream alone or (e.g. when co-
located with a SIP Metering Process) based on signaling information.
New media types may be defined in the registry created by [RFC3840].
Description:
0: unknown: unknown media type
1: audio: audio RTP stream
2: video: video RTP stream
3: text: text session
4: application: tbd
5: message: tbd
Data Type: unsigned8
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.11. rtpMediaSubType
The string value for this IE can be found in the IANA registry for
'RTP Payload Format MIME types' on
http://www.iana.org/assignments/rtp-parameters
Description: Media subtype based on IANA registry
Data Type: string
Scholz Expires September 6, 2012 [Page 10]
Internet-Draft RTP Streams in IPFIX March 2012
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.12. rtpIsSRTP
tbd: The tri-state rtpIsSRTP will be set if SRTP is used/not used or
the content is not known. Might require the RTP Metering Process to
be co-located with a signaling process.
3.13. rtpSSRC
Description: SSRC field as conveyed in RTP header. The SSRC field
identifies the synchronization source.
Data Type: unsigned32
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.14. rtpCSRC
Description: Convey the CSRCs as RFC6313 basicList? To be discussed
Data Type: basicList
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
3.15. rtpTimestamp
Description: Timestamp value as conveyed in RTP header. The
timestamp is taken from the first RTP packet if multiple RTP
packets are covered in this flow record.
Data Type: unsigned32
Scholz Expires September 6, 2012 [Page 11]
Internet-Draft RTP Streams in IPFIX March 2012
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
4. RTP Payload Information Elements
This section defines additional Information Elements which describe
RTP streams based on their IP transport and RTP header parameters.
Complicated metrics may be subject to different measurement methods.
In order to prevent data from being unusable due to incompatible
formats or measurement methods most Information Elements are counter
values which allow calculation of metrics on mediator or collector
systems. Additionally this allows matching flow records to be
aggregatd by addition, e.g. addition of the rtpPacketCount values of
multiple observation intervals.
4.1. rtpPacketCount
Description: Number of RTP packets covered in this flow record.
This includes observed duplicate packets.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
4.2. rtpPacketCountLoss
Description: Number of RTP packets lost in the duration covered by
this flow record. The number of lost packets SHOULD be calculated
using the RTP sequence numbers.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
Scholz Expires September 6, 2012 [Page 12]
Internet-Draft RTP Streams in IPFIX March 2012
4.3. rtpPacketCountDiscarded
Passive monitoring equipment shall assume a fixed 40 millisecond
jitter buffer (TODO: add reference to TM Forum/ITU). A packet
observed later than the expected packet inter-arrival time plus the
40ms is assumed to be received by the RTP receiver too late to be
played out. Even though the packet may be received by the RTP
receiver it will be discarded which has the same effect as packet
loss.
Description: Number of RTP packets discarded in the duration covered
by this flow record.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
4.4. rtpCodecChange
Description: The codec used in the observed RTP stream may change
throughout an observation interval. This value indicates the
number of changes identified by changing RTP header Payload Type
(PT) values.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
4.5. rtpMarkerBit
Description: The RTP Marker Bit may be set on one or more packets
within the observation interval. This value indicates the number
of unique packets which had the Marker Bit set. Duplicate packets
MUST be ignored for this calculation.
Data Type: unsigned32
Scholz Expires September 6, 2012 [Page 13]
Internet-Draft RTP Streams in IPFIX March 2012
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
4.6. rtpComfortNoise
Description: RTP packets of the observed RTP stream may be Comfort
Noise packets. This value indicates the number of unique Comfort
Noise packets in this observation interval. Duplicate packets
MUST be ignored for this calculation.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
4.7. rtpDTMFTones
tbd: # of DTMF tones observed in interval, e.g. PT 101. May also
include in-band if possible by observation method.
4.8. rtpPacketization
Description: The packetization time of the data contained in the RTP
packets in milliseconds. If a packetization time change occured
during the monitoring interval described by this flow record the
rtpPacketization value SHALL be set to the interval used for most
of the packets. If no packetization time can be determined the
value MUST be set to 0.
Data Type: unsigned8
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
4.9. rtpPacketizationChange
Scholz Expires September 6, 2012 [Page 14]
Internet-Draft RTP Streams in IPFIX March 2012
Description: The packetization time of RTP packets may change
throughout a single RTP stream. Endpoints may use the ptime SDP
parameter to indicate/request changes or change the packetization
time without advance notice if allowed by the codec. This value
indicates the number of packetization time changes in this
observation interval.
Data Type: unsigned8
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
4.10. rtpDSCPChange
tbd: should be transport based - # of changes of DSCP/ToS bits on IP
layer. Alternative: basicList of seen DSCP classes.
5. Quality of Service Information Elements
5.1. rtpSenderSynchronization
tbd: VOIPFUTURE specific
5.2. rtpSenderRestart
tbd: VOIPFUTURE specific, can be incorporated into rtpSequenceError
5.3. rtpSenderJitter
tbd: VOIPFUTURE specific
5.4. rtpNetworkOverload
tbd: VOIPFUTURE specific
5.5. rtpOverloadWithPacketLoss
tbd: VOIPFUTURE specific
5.6. rtpTolerableJitter
TM Forum and ITU recommend that monitoring equipment such as the
IPFIX Metering Process should assume a jitter buffer with a fixed
size of 40 milliseconds. Based on this value we consider jitter as
Scholz Expires September 6, 2012 [Page 15]
Internet-Draft RTP Streams in IPFIX March 2012
tolerable if the inter-arrival time between to packets does not
exceed these 40 milliseconds. Based on a 20 millisecond
packetization time (as conveyed in rtpPacketInterval) a jitter of
less than 20 milliseconds can be considered as tolerable. TBD:
define jitter measurement method, most likely something better than
RFC3550.
Description: The number of RTP packets with a tolerable jitter as
defined above. Duplicate packets MUST be ignored for this
calculation.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.7. rtpCriticalJitter
Based on the rtpTolerableJitter definition this Information Element
describes the number of RTP packets which arrived with a critical
value for the packet inter-arrival time, i.e. more than 40
milliseconds after the previous packet.
Description: The number of RTP packets with a critical jitter as
defined above. Duplicate packets MUST be ignored for this
calculation.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.8. rtpVeryLargeJitter
RTP packets observed with a packet inter-arrival time of more than 80
milliseconds above the indicated packetization time (e.g. >100ms in
case of a 20ms packetization time) are counted in this very large
jitter category. Often RTP packets will match this property if
network buffering occurred during the observation interval.
Scholz Expires September 6, 2012 [Page 16]
Internet-Draft RTP Streams in IPFIX March 2012
Description: The number of RTP packets with a very large jitter as
defined above. Duplicate packets MUST be ignored for this
calculation.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.9. rtpTolerablePacketLoss
RTP packet loss can be detected using the RTP sequence number. A
loss event is considered tolerable if only one packet is lost before
the RTP stream continues.
Description: The number of tolerable packet loss events as defined
above observed in the observation interval.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.10. rtpCriticalPacketLoss
RTP packet loss can be detected using the RTP sequence number. A
loss event is considered critical if more than one packet is lost
before the RTP stream continues.
Description: The number of critical packet loss events as defined
above observed in the observation interval.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
Scholz Expires September 6, 2012 [Page 17]
Internet-Draft RTP Streams in IPFIX March 2012
5.11. rtpCriticalLossDensity
VOIPFUTURE needs to describe, should be kept in. We need to cover
burst-loss
5.12. rtpOverloadWithPacketOrder
VOIPFUTURE needs to describe, optional
5.13. rtpDuplicates
Description: Duplicate RTP packets may be observed and identified
based on the RTP sequence number. This counter indicates the
number of observed duplicate packets in the observation interval.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.14. rtpPacketOrder
RTP packets may be re-ordered during transmission, e.g. due to
routing changes. This Information Element indicates the number of
RTP packets which are received out of order during the observation
interval.
Description: Number of out-of-order RTP packets observed. Duplicate
packets must not count towards this value.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.15. rtpSequenceError
The RTP header sequence numbers increases monotonically throughout an
RTP session. A forward or backward jump in sequence numbers or a
reset of the sequence number observed indicates problems on the
sender side. Additionally the receiver of the RTP stream may suffer
as handling these situations is not defined.
Scholz Expires September 6, 2012 [Page 18]
Internet-Draft RTP Streams in IPFIX March 2012
Description: Number of RTP sequence error events observed.
Duplicate packets must not count towards this value.
Data Type: unsigned32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.16. rtpLowPacketInterval
to be defined by VOIPFUTURE
5.17. rtpNoPacketInterval
to be defined by VOIPFUTURE
5.18. rtpBadRTPTimestamp
to be defined by VOIPFUTURE
5.19. rtpMinJitter
Description: The minimum jitter value is defined as the minimal
packet inter-arrival time in milliseconds in the observation
interval.
Data Type: unsigned8
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
5.20. Average Jitter
Calculating and transporting an average jitter value makes little
sense if the data should be aggregated at a later stage, e.g. by a
mediator, collector or an application processing the data. To remedy
this both the number of packet inter-arrival times and the sum of the
packet inter-arrival times in milliseconds are counted.
The average jitter value can be calculated by dividing rtpJitterSum
by rtpJitterCount.
Scholz Expires September 6, 2012 [Page 19]
Internet-Draft RTP Streams in IPFIX March 2012
An average jitter value for multiple flow records can be calculated
by dividing the sum of all rtpJitterSum values by the sum of all
rtpJitterCount values.
5.20.1. rtpJitterCount
Description: The number of packet inter-arrival times observed.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.20.2. rtpJitterSum
Description: The sum of all packet inter-arrival times in
milliseconds.
Data Type: unsigned32
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
5.21. rtpMaxJitter
Description: The maximum jitter value is defined as the maximal
packet inter-arrival time in milliseconds in the observation
interval.
Data Type: unsigned8
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
5.22. Jitter histogram
In order to display and aggregate detailed jitter information of the
observed RTP stream additional Information Elements are required.
The Metering Process observing an RTP stream analyses the packet
Scholz Expires September 6, 2012 [Page 20]
Internet-Draft RTP Streams in IPFIX March 2012
inter-arrival times without needing to know the agreed packetiziation
time. The following calculations are only made for packets with
consecutive RTP sequence numbers. From 250 received RTP packets in
an observation interval a Metering Process can calculate 249 packet
inter-arrival times. In case of packet loss (i.e. missing sequence
number in the packet stream) no packet inter-arrival time is
calculated. Based on the calculated inter-arrival time the counters
in the buckets listed below are increased. All counters start at
zero per observation interval. Inter-arrival times have a
millisecond granularity.
5.22.1. rtpJitterBucket0
Description: Number of packet inter-arrival times between 0 and
lower than 2.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.2. rtpJitterBucket5
Description: Number of packet inter-arrival times starting at 2.5
and lower than 7.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.3. rtpJitterBucket10
Description: Number of packet inter-arrival times starting at 7.5
and lower than 12.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
Scholz Expires September 6, 2012 [Page 21]
Internet-Draft RTP Streams in IPFIX March 2012
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.4. rtpJitterBucket15
Description: Number of packet inter-arrival times starting at 12.5
and lower than 17.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.5. rtpJitterBucket20
Description: Number of packet inter-arrival times starting at 17.5
and lower than 22.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.6. rtpJitterBucket25
Description: Number of packet inter-arrival times starting at 22.5
and lower than 27.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.7. rtpJitterBucket30
Scholz Expires September 6, 2012 [Page 22]
Internet-Draft RTP Streams in IPFIX March 2012
Description: Number of packet inter-arrival times starting at 27.5
and lower than 32.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.8. rtpJitterBucket35
Description: Number of packet inter-arrival times starting at 32.5
and lower than 37.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.9. rtpJitterBucket40
Description: Number of packet inter-arrival times starting at 37.5
and lower than 37.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.10. rtpJitterBucket45
Description: Number of packet inter-arrival times starting at 42.5
and lower than 47.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
Scholz Expires September 6, 2012 [Page 23]
Internet-Draft RTP Streams in IPFIX March 2012
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.11. rtpJitterBucket50
Description: Number of packet inter-arrival times starting at 47.5
and lower than 52.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.12. rtpJitterBucket55
Description: Number of packet inter-arrival times starting at 52.5
and lower than 57.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.13. rtpJitterBucket60
Description: Number of packet inter-arrival times starting at 57.5
and lower than 62.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.14. rtpJitterBucket65
Scholz Expires September 6, 2012 [Page 24]
Internet-Draft RTP Streams in IPFIX March 2012
Description: Number of packet inter-arrival times starting at 62.5
and lower than 67.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.15. rtpJitterBucket70
Description: Number of packet inter-arrival times starting at 67.5
and lower than 72.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.16. rtpJitterBucket75
Description: Number of packet inter-arrival times starting at 72.5
and lower than 77.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.17. rtpJitterBucket80
Description: Number of packet inter-arrival times starting at 77.5
and lower than 82.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
Scholz Expires September 6, 2012 [Page 25]
Internet-Draft RTP Streams in IPFIX March 2012
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.18. rtpJitterBucket85
Description: Number of packet inter-arrival times starting at 82.5
and lower than 87.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.19. rtpJitterBucket90
Description: Number of packet inter-arrival times starting at 87.5
and lower than 92.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.20. rtpJitterBucket95
Description: Number of packet inter-arrival times starting at 92.5
and lower than 97.5 milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.22.21. rtpJitterBucket100
Scholz Expires September 6, 2012 [Page 26]
Internet-Draft RTP Streams in IPFIX March 2012
Description: Number of packet inter-arrival times starting at 97.5
milliseconds.
Data Type: unsigned16
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
5.23. rtpDelayType
The RTP one-way delay is the time RTP packets need to travel from the
source (RTP sender) to the destination (RTP receiver). This value
may be obtained from RTCP reports generated by RTP receivers or by
actively using ICMP ping requests to obtain a rough approximation of
the delay. ICMP based delay calculation is not encouraged. In any
use case the observed or measured one-way delay is only a single data
point which does not match the observation interval defined by the
rtpSampleTime and rtpSampleOffset. TBD: discuss this, esp whether to
move this in a separate section.
Description:
0: unknown: unknown delay measurement
1: rtcp: delay value taken from RTCP report
2: rtcp-xr: delay value taken from RTCP-XR report
3: ping: active ICMP ping
4: endpoint: mouth to ear delay
Data Type: unsigned8
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
5.24. rtpDelayOneWay
Scholz Expires September 6, 2012 [Page 27]
Internet-Draft RTP Streams in IPFIX March 2012
Description: One way RTP delay in milliseconds.
Data Type: unsigned16
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
6. MOS measurement
A multitude of Mean opinion score (MOS) assessment algorithms have
been defined of which only one or few may be available to an IPFIX
Metering Process. The quality (i.e. accuracy) of these algorithms
varies and has to be noted when transporting MOS values.
An IPFIX Metering Process may use these Information Elements to
convey information on the duration of the stream in which the quality
fell into the respective category as well as the measurement
algorithm used to obtain the information.
6.1. rtpMOSCAlg
The values carried in this IE are taken from the "RTCP XR QoE metric
block - Calculation Algorithm" sub-registry of the "RTP Control
Protocol Extended Reports (RTCP XR) Block Type Registry" as defined
in [I-D.wu-xrblock-rtcp-xr-quality-monitoring].
Description: The calculation algorithm (CAlg) used by the Metering
Process to calculate the MOS value.
0: undefined: The algorithm is not known/specified.
1: ITU-T P.564
2: G.107
3: G.107 / ETSI TS 101 329-5 Annex E
4: ITU-T P.NAMS
5: ITU-T P.NBAMS
Scholz Expires September 6, 2012 [Page 28]
Internet-Draft RTP Streams in IPFIX March 2012
6: RTCP - Real Time Control Protocol (not defined in registry!)
Data Type: unsigned8
Data Type Semantics: identifier
PEN (provisional): xxx
ElementId (provisional): xxx
The MOS values calculated are separated into MOS classes based on the
ITU-T G.107 classes.
6.2. rtpMOSClass1
Description: Number of seconds the monitored stream had a MOS
quality lower than 3.10
Data Type: float32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
6.3. rtpMOSClass2
Description: Number of seconds the monitored stream had a MOS
quality larger than or equal 3.10 and lower than 3.60
Data Type: float32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
6.4. rtpMOSClass3
Description: Number of seconds the monitored stream had a MOS
quality larger than or equal 3.60 and lower than 4.03
Data Type: float32
Scholz Expires September 6, 2012 [Page 29]
Internet-Draft RTP Streams in IPFIX March 2012
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
6.5. rtpMOSClass4
Description: Number of seconds the monitored stream had a MOS
quality larger than or equal 4.03 and lower than 4.34
Data Type: float32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
6.6. rtpMOSClass5
Description: Number of seconds the monitored stream had a MOS
quality larger than or equal 4.34
Data Type: float32
Data Type Semantics: deltaCounter
PEN (provisional): xxx
ElementId (provisional): xxx
6.7. rtpMinMOS
Description: Minimum MOS value measured in the monitoring interval.
Data Type: float32
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
Scholz Expires September 6, 2012 [Page 30]
Internet-Draft RTP Streams in IPFIX March 2012
6.8. rtpAvgMOS
Description: Average MOS value measured in the monitoring interval.
Data Type: float32
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
6.9. rtpMaxMOS
Description: Maximum MOS value measured in the monitoring interval.
Data Type: float32
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
6.10. rtpMinRFactor
Description: Minimum R-Factor measured in the monitoring interval.
Data Type: float32
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
6.11. rtpAvgRFactor
Description: Average R-Factor measured in the monitoring interval.
Data Type: float32
Data Type Semantics: quantity
PEN (provisional): xxx
Scholz Expires September 6, 2012 [Page 31]
Internet-Draft RTP Streams in IPFIX March 2012
ElementId (provisional): xxx
6.12. rtpMaxRFactor
Description: Maximum R-Factor measured in the monitoring interval.
Data Type: float32
Data Type Semantics: quantity
PEN (provisional): xxx
ElementId (provisional): xxx
7. Recommended Templates
The defined RTP stream IPFIX templates must support both IPv4 and
IPv6 transport. They need to carry either flow information regarding
the entire duration of an RTP stream or specific to a shorter
observation interval.
7.1. Entire stream
tbd
7.2. Time slice
tbd, based on previous template. Split a single RTP stream in three
flow records as example including (empty) 'RTP stream ended' flow
record.
8. Examples
9. Acknowledgements
tbd
10. IANA Considerations
tbd
Scholz Expires September 6, 2012 [Page 32]
Internet-Draft RTP Streams in IPFIX March 2012
11. Security Considerations
tbd
12. TODO
QUESTION-1: Should we try to take a biflow approach and join both
stream directions of a call in a single flow record? I assume this
would not give any big advantage and complicates scenarios in which
Service Level Agreements are done on a per direction basis.
QUESTION-2: Should we define the CSRCs as RFC6313 basicList?
QUESTION-3: Should we degrade rtpPacketOrder or rtpSequenceError to a
boolean?
QUESTION-4: Should rtpPacketCount include duplicate packets?
QUESTION-5: How about 'packet errors', e.g. packets which could not
be processed properly?
QUESTION-6: Should we include a standard deviation value for
rtpAvgJitter and other average values?
QUESTION-7: (from MK@VOIPFUTURE): It has to be possible to send an
empty flow record indicating the end of an RTP stream.
QUESTION-8: should we reduce these deltaCounters to 16 Bit (now:
32Bit)? rtpCodecChange, rtpMarkerBit, rtpComfortNoise,
rtpPacketIntervalChange, rtpSequenceError, rtp*Jitter
QUESTION-9: should we add direction indicators? E.g. caller-to-
callee or callee-to-caller?
QUESTION-10: should we use milliseconds or seconds for the MOS class
slots?
13. References
13.1. Normative References
[I-D.trammell-ipfix-sip-msg]
Claise, B., Trammell, B., Kaplan, H., and S. Niccolini,
"SIP Message Information Export using IPFIX",
draft-trammell-ipfix-sip-msg-02 (work in progress),
October 2011.
Scholz Expires September 6, 2012 [Page 33]
Internet-Draft RTP Streams in IPFIX March 2012
[I-D.wu-xrblock-rtcp-xr-quality-monitoring]
Hunt, G., Clark, A., Wu, W., Schott, R., and G. Zorn,
"RTCP XR Blocks for QoE metric reporting",
draft-wu-xrblock-rtcp-xr-quality-monitoring-06 (work in
progress), December 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008.
13.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Author's Address
Hendrik Scholz
VOIPFUTURE GmbH
Wendenstrasse 4
Hamburg 20097
Germany
Phone: +49 40 688 900 100
Email: hscholz@voipfuture.com
URI: http://www.voipfuture.com/
Scholz Expires September 6, 2012 [Page 34]
